Brian West wrote:

I really find that one hard to believe.  

Hard to believe, but this is true:


I have made PURE experiment.
My friend has registered SIP-phone behind NAT in Ukraine.
His registration:

Call-ID:        4a978b30@192.168.10.103
User:           1012@192.168.1.5
Contact:        "user" <sip:1012@192.168.1.136:1024>
Agent:          AcctonVoIP/2.5
Status:         Registered(UDP)(unknown) EXP(2010-05-23 14:27:20)
Host:           olegh.ath.cx
IP:             91.207.244.1
Port:           1024
Auth-User:      1012
Auth-Realm:     olegh.ath.cx
MWI-Account:    1012@192.168.1.5


I tried call 1001 -> 1012, fs_cli prints:


2010-05-23 12:37:01.593320 [NOTICE] switch_channel.c:669 New Channel sofia/internal/sip:1012@192.168.1.136:1024 [2b79d969-8966-df11-ac63-005004c3cb7e]

I sniffed network traffic, FS tries connect to his LAN address from "Contact", not his real address:

olegh# tcpdump host'(192.168.1.136 or 91.207.244.1)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes
12:40:55.044208 arp who-has 192.168.1.136 tell deskpro.khovayko.com
12:40:55.544711 arp who-has 192.168.1.136 tell deskpro.khovayko.com
12:40:56.545145 arp who-has 192.168.1.136 tell deskpro.khovayko.com
12:40:58.546827 arp who-has 192.168.1.136 tell deskpro.khovayko.com

sofia profile xxx siptrace on

I will be you its NOT ignoring the fs_path you just can't see the packet leaving and since its TCP the far side nat I suspect has closed the nat translation thus you'll need to register more often or enable keep alives on the device.

/b

I tried to do this -- results as same as with tcpdump.
My local phone has number 1001, IP=192.168.1.130, try to call 1012 (behind NAT, see registration above):