PJSIP problem on Android over VPN?

Question

Android

Asterisk 13.12.2, PJSIP 2.5.5
The Asterisk server has an IP address of 192.168.100.223 and is connected to MikroTik.
MikroTik runs a PPTP server that distributes addresses from the 192.168.253.0 subnet, to which clients (smartphones) connect to use Asterisk.
A smartphone client connected via WiFi in another office (there is no routing between offices) has an IP address of 192.168.101.247, connects via PPTP to MikroTik and receives an IP address in the tunnel 192.168.253.2
SIP client on a smartphone successfully connects to Asterisk via IP 192.168 .100.223. In the Asterisk console:

pjsip show aors
Contact:  5001/sip:[email protected]:35028;transport= eef5336413 Avail        28.189

Problem RTP traffic from Asterisk towards the SIP client does not come to IP 192.168.253.2, but to IP 192.168.101.247, which is assigned to the WAN interface of the smartphone.
When studying traffic, it was found that SIP clients (all popular ones that we managed to test) substitute IP addresses from smartphone interfaces at random in SIP headers. One client substituted the WAN IP address (192.168.101.247) in the REGISTER message in the Sent-by Addres and Contact fields in the header. Another client substituted the correct addresses (192.168.253.2) in the REGISTER message, but after receiving the OPTIONS message from Asterisk in the response status message, substituted the WAN address (192.168.101.247) in the Contact field. In all cases, RTP traffic starts going to 192.168.101.247, i.e. flies towards the provider along the default route. When connecting not from a second office, but via a cellular network, the problem remains the same - the IP address assigned by the operator is substituted in the headers. Without using a VPN, there is no such problem. The voice comes from the server to clients without problems.
First client

Second client

Is there any way to "teach" pjsip to ignore the contact field? Or teach SIP clients to substitute the correct IP addresses in the headers?

Answer 1

I'll answer my own question.
The problem with incorrect filling of SDP headers by mobile SIP clients can be solved in two ways, namely, by enabling interaction through NAT, even if NAT does not actually exist:
1. If the client supports the RPORT (RPORT for media) option, enable it on client - everything should work.
2. If the client does not support RPORT, then enable the following options on Asterisk:
2.1. If we work via SIP, then add the nat = comemedia
2.2 option to the client settings in sip.conf . If we work through PJSIP, then add the option rtp_symmetric = yes
to the endpoint section in pjsip.conf. Thus, Asterisk ignores the SDP instructions and sends the RTP stream to where the packet came from.
For more information, see the document Migrating from chan_sip to res_pjsip (NAT) , where you can find NAT settings for both SIP and PJSIP