Different IP in INVITE SIP payload and IP source

Hi all,

I’m struggling trying to have asterisk echo test working from my mobile (an iphone with Bria softphone app) to my home server (a linux machine running asterisk 11.21.1 and shorewall firewall).
If the mobile is connected with my wifi, everything works fine. If the mobile is connected with a mobile carrier, I can register, make the call but I cannot hear anything.
I dumped the ip traffic in both case and I compared them.
I found a difference in the INVITE message. In wifi connection, the IP of the sender and the “Sent-by address” is the same. In the mobile carrier connection, those values are different. Notably, the “Sent-By address” is 10.x.x.x ip class. There is and excerpt at the bottom of this message.
If I configure my mobile phone to use a SIP provider insted of my asterisk server, everything works fine even if it is connected with the mobile carrier so the problem is not related to the mobile carrier or the mobile app.
Can you have a suggestion in order to fix my asterisk configuration, please?

Thank you!

sacchi

Internet Protocol Version 4, Src: 62.19.21.158, Dst: 192.168.100.1
Transmission Control Protocol, Src Port: 19174 (19174), Dst Port: 5060 (5060), Seq: 9523, Ack: 6786, Len: 1059
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:400@xxxxxx.com:5060 SIP/2.0
Message Header
Via: SIP/2.0/TCP 10.72.94.250:62373;branch=z9hG4bK-524287-1—b801fd72c9931d01;rport
Transport: TCP
Sent-by Address: 10.72.94.250
Sent-by port: 62373
Branch: z9hG4bK-524287-1—b801fd72c9931d01
RPort: rport

Your mobile carrier is NATting you from a private ip/subnet (10.x.x.x), which is quite common, so the above is OK/expected, as long as Asterisk knows you’re behind NAT (nat=yes in the extension configuration?)
Instead of packet capturing, you should probably be doing
sip set debug peer 400
in asterisk, or something (you might want to google that syntax)

Thank you for your support.

400 is the echo test, the peer is 201.
I issued the command sip set debug peer 201 but I cannot see something strange.

– Registered SIP ‘201’ at 62.19.21.58:17435
== Using SIP VIDEO CoS mark 6
== Using SIP RTP CoS mark 5
– Executing [400@local:1] Answer(“SIP/201-00000004”, " ") in new stack
– Executing [400@local:2] Echo(“SIP/201-00000004”, " ") in new stack
== Spawn extension (local, 400, 2) exited non-zero on ‘SIP/201-00000004’

If I connect in LAN I get an extra line after the Echo command execution notification:

0x7f017a035f60 – Probation passed - setting RTP source address to 192.168.2.241:47228

Tried nat=yes, exterhost, localnet with no success. I’m really stuck since two month! ;-(

  1. **nat=**yes is deprecated, use nat=force_rport,comedia instead

  2. change exterhost is deprecated also chnange it by externaddr = your-public-ip

  3. **localnet=**192.168.0.0/255.255.255.0 ; you lan network address.

4-) **rtpkeepalive=**60 ; Send keepalives in the RTP stream to keep NAT open

6-) **keepalive=**60

7-)**qualify=**yes

8–)**directmedia=**no

On the Softhone you can specify the use of an stun sever it helps me to solve most of my nat problems.

stun.ekiga.net

nat=yes is deprecated and doesn’t mean you are behind NAT. It is mainly for the case where you are outside NAT and the peer is inside, although some options may be needed to work round broken NAT when you are inside and the peer is outside. Force rport is mainly for incoming requests (it makes Asterisk pretend that rport was present in the incoming Via header).

The rport parameter overrides the 10.x.x.x address and tells the remote side to reply to the address from which the request was received, not the address in the Via, which it has clearly done, as the INVITE has completed with 200 OK, which would not have been received if the response had been sent to 10.x.x.x.

Incidentally, the way that the header is presented is confusing. Transport looks like it header, but it is really the interpretation of the Via header by the protocol analyser. Similarly for the next four lines.

Looking at the logging, the INVITE was successful, so the problem is likely to be with media, but you have provided neither the SDP (both directions) nor the SIP exchange that closed the call down (in particular who closed it down, although I think it was probably the peer). It may be as simple as your firewall blocking the media, or the NAT failing to send it to the right place.