Ken, Thanks for taking the time to write that out. I understand that and that makes perfect sense, although the endpoints in this case are configured to report their external IP addresses, either through STUN or a static NAT IP entry. What still is unclear to me is why this failed when FS was able to successfully bridge the same extension directly to the PSTN gateway. As for my skill level before I continue - I’ve got years and years of advanced networking experience but I’ve only been running FS for a few months and I still have a lot to learn, so please forgive me if I’m still missing the point. I feel like I’m really starting to make sense of it all now though, which probably only serves to make me a danger to myself and others. I don’t want to waste your time with dumb questions, but I get the impression that there aren’t that many people out there with the level of understanding to be able to answer questions like this who are actually willing to do so. I REALLY appreciate your time, I want to be sure that I fully understand this. The situation here, endpoint A is a local extension on the same LAN as FS: Endpoint A (192.168.1.4) -> FS (192.168.1.6) -> NAT A -> Internet -> NAT B -> Endpoint B (10.0.0.x/24) Endpoint B’s WAN address is 71.179.xx.xx

From the traffic I pastebinned, we can see that Endpoint A is sending its external WAN address info to FS, right before FS sends Endpoint A’s internal LAN address to Endpoint B, so I would think that FS should be passing Endpoint A’s WAN address along instead of its LAN address for media:

recv 722 bytes from udp/[192.168.1.4]:5060 at 14:03:20.015051: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 71.179.xx.xx;rport=5060;branch=z9hG4bKgKQKBycpSp0XD;received=192.168.1.6 From: <sip:225@192.168.1.6:5060;user=phone>;tag=6F6tm8F5v3D5j To: "Phil" <sip:102@192.168.1.6:5060>;tag=fce60a24bc Call-ID: cabfc783414db5c6 CSeq: 27863635 UPDATE Contact: "Phil" <sip:102@192.168.1.4:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0 000-1000-8000-00085D296BF3>" Server: Aastra 9480i/3.2.2.2044 Session-Expires: 120;refresher=uas Supported: path, timer Content-Type: application/sdp Content-Length: 178 v=0 o=MxSIP 0 2 IN IP4 192.168.1.4 s=SIP Call c=IN IP4 71.179.xx.xx t=0 0 m=audio 16384 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv ------------------------------------------------------------------------ 2012-05-07 10:03:20.011485 [DEBUG] switch_core_session.c:900 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.011485 [DEBUG] switch_core_session.c:900 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.011485 [DEBUG] switch_core_session.c:900 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:754 Send signal sofia/internal/sip:225@74.93.xx.xx:1067 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] sofia.c:5628 Channel sofia/internal/102@192.168.1.6:5060 entering state [ready][200] 2012-05-07 10:03:20.039490 [DEBUG] sofia.c:5639 Remote SDP: v=0 o=MxSIP 0 2 IN IP4 192.168.1.4 s=SIP Call c=IN IP4 71.179.xx.xx t=0 0 m=audio 16384 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 send 1103 bytes to udp/[74.93.xx.xx]:1067 at 14:03:20.052233: ------------------------------------------------------------------------ INVITE sip:225@74.93.xx.xx:1067;transport=udp SIP/2.0 Via: SIP/2.0/UDP 71.179.xx.xx;rport;branch=z9hG4bKHvgcDSXSpZpgS Max-Forwards: 69 From: "Phil" <sip:102@192.168.1.6>;tag=7rZKp308Sc4Qe To: <sip:225@74.93.xx.xx:1067;transport=udp>;tag=1672444754 Call-ID: 3682faf7-12f0-1230-4bae-feffffffffff CSeq: 27863631 INVITE Contact: <sip:mod_sofia@71.179.xx.xx:5060> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06 11-27-00 +0000 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Require: timer Supported: timer, precondition, path, replaces Session-Expires: 120;refresher=uas Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 217 X-FS-Support: update_display,send_info Remote-Party-ID: "Phil" <sip:102@192.168.1.6>;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1336379701 1336379703 IN IP4 71.179.xx.xx s=FreeSWITCH c=IN IP4 192.168.1.4 WRONG! t=0 0 m=audio 1638 RTP/AVP 0 8 98 3 a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=30 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ 2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:4817 Our existing sdp is still good [PCMU 71.179.xx.xx:16384], let's keep it. 2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:5043 No 2833 in SDP. Disable 2833 dtmf and switch to INFO 2012-05-07 10:03:20.039490 [DEBUG] sofia.c:6212 Processing updated SDP 2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:3214 Audio params are unchanged for sofia/internal/102@192.168.1.6:5060. 2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:3224 sofia/internal/102@192.168.1.6:5060 Setting audio receive payload in Re-INVITE to 0 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:754 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:900 Send signal sofia/internal/sip:225@74.93.xx.xx:1067 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_ivr_bridge.c:1146 (sofia/internal/102@192.168.1.6:5060) State Change CS_EXECUTE -> CS_HIBERNATE 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:1205 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_ivr_bridge.c:1147 (sofia/internal/sip:225@74.93.xx.xx:1067) State Change CS_PARK -> CS_HIBERNATE 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:1205 Send signal sofia/internal/sip:225@74.93.xx.xx:1067 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:816 Send signal sofia/internal/sip:225@74.93.xx.xx:1067 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:816 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.053837 [DEBUG] sofia.c:5628 Channel sofia/internal/sip:225@74.93.xx.xx:1067 entering state [calling][0] 2012-05-07 10:03:20.053837 [DEBUG] mod_sofia.c:2191 Not sending same id again "Phil" <102> send 1006 bytes to udp/[192.168.1.4]:5060 at 14:03:20.054056: ------------------------------------------------------------------------ INVITE sip:102@192.168.1.4:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 71.179.xx.xx;rport;branch=z9hG4bKj594emeXK8c3m Max-Forwards: 70 From: <sip:225@192.168.1.6:5060;user=phone>;tag=6F6tm8F5v3D5j To: "Phil" <sip:102@192.168.1.6:5060>;tag=fce60a24bc Call-ID: cabfc783414db5c6 CSeq: 27863636 INVITE Contact: <sip:225@71.179.xx.xx:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06 11-27-00 +0000 2012-05-07 10:03:20.053837 [DEBUG] switch_core_state_machine.c:426 (sofia/internal/sip:225@74.93.xx.xx:1067) State PARK going to sleep Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Require: timer Supported: timer, precondition, path, replaces 2012-05-07 10:03:20.053837 [DEBUG] switch_core_state_machine.c:362 (sofia/internal/sip:225@74.93.xx.xx:1067) Running State Change CS_HIBERNATE Session-Expires: 120;refresher=uas Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 218 X-FS-Support: update_display,send_info v=0 o=FreeSWITCH 1336377747 1336377749 IN IP4 192.168.1.6 s=FreeSWITCH c=IN IP4 74.93.xx.xx t=0 0 m=audio 51720 RTP/AVP 0 8 98 3 a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=30 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ Call fails with no audio. Now, if I try to make a call from that same endpoint to the PSTN in bypass media mode, FS sends the endpoint’s WAN address like I would expect it to, and the call works... see below. I'm getting rid of a bunch of ACKs and such for brevity and clarity but the transaction goes like this: Endpoint A sends its invite, complete with WAN address info: ------------------------------------------------------------------------ recv 1279 bytes from udp/[192.168.1.4]:5060 at 18:00:37.133916: ------------------------------------------------------------------------ INVITE sip:94109693xxx@192.168.1.6:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.4;branch=z9hG4bK69b9ae7c0bd9ac684;rport Route: <sip:192.168.1.6:5060;lr> Proxy-Authorization: Digest username="102",realm="192.168.1.6",nonce="ecd26c6e-c2d9-4669-b842- 232e99abb7a2",uri="sip:94109693xxx@192.168.1.6:5060;user=phone",response="6e 2edf5ebde2d6eaae7dd46e73cf5f88",algorithm=MD5,qop=auth,cnonce="6defb5b4",nc= 00000001 Max-Forwards: 70 From: "Phil" <sip:102@192.168.1.6:5060>;tag=6de7cac307 To: <sip:94109693xxx@192.168.1.6:5060;user=phone> Call-ID: 8d9c7aa8f30bc1d3 CSeq: 30988 INVITE Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO Allow-Events: talk, hold, conference, LocalModeStatus Contact: "Phil" <sip:102@192.168.1.4:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0 000-1000-8000-00085D296BF3>" Min-SE: 120 Session-Expires: 120 Supported: path, 100rel, replaces, timer User-Agent: Aastra 9480i/3.2.2.2044 Content-Type: application/sdp Content-Length: 255 v=0 o=MxSIP 0 1 IN IP4 192.168.1.4 s=SIP Call c=IN IP4 71.179.xx.xx t=0 0 m=audio 16384 RTP/AVP 0 110 8 9 a=rtpmap:0 PCMU/8000 a=rtpmap:110 PCMU/16000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv Now FS sends the invite to the gateway, complete with proper info: send 1163 bytes to udp/[199.96.248.140]:5060 at 18:00:37.171788: ------------------------------------------------------------------------ INVITE sip:14109693xxx@199.96.248.140 SIP/2.0 Via: SIP/2.0/UDP 71.179.xx.xx:5080;rport;branch=z9hG4bKK20cSjr649cta Max-Forwards: 69 From: "QSystems" <sip:14109698xxx@71.179.xx.xx>;tag=m2Djgjet89Ztj To: <sip:14109693xxx@199.96.248.140> Call-ID: 0db1020c-1636-1230-a98d-feffffffffff CSeq: 28043554 INVITE Contact: <sip:gw+Alcazar_US@71.179.xx.xx:5080;transport=udp;gw=Alcazar_US> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06 11-27-00 +0000 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, hold, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 279 X-accountcode: 102 X-FS-Support: update_display,send_info Remote-Party-ID: "QSystems" <sip:14109698xxx@71.179.xx.xx>;party=calling;screen=yes;privacy=off v=0 o=MxSIP 3719756330637231183 2523006830856012877 IN IP4 192.168.1.4 s=SIP Call c=IN IP4 71.179.xx.xx t=0 0 m=audio 16384 RTP/AVP 0 110 8 9 a=rtpmap:0 PCMU/8000 a=rtpmap:110 PCMU/16000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ In the meantime, FS receives and passes along 180 - Ringing PSTN destination answers the call, gateway comes back with upstream provider's media address: ------------------------------------------------------------------------ recv 886 bytes from udp/[199.96.248.140]:5060 at 18:00:43.320321: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 71.179.xx.xx:5080;rport=5080;branch=z9hG4bKK20cSjr649cta Record-Route: <sip:199.96.248.140;lr=on> From: "QSystems" <sip:14109698xxx@71.179.xx.xx>;tag=m2Djgjet89Ztj To: <sip:14109693xxx@199.96.248.140>;tag=m3p9c1NF8UDyQ Call-ID: 0db1020c-1636-1230-a98d-feffffffffff CSeq: 28043554 INVITE Contact: <sip:14109693xxx@10.1.50.23:5004;transport=udp> User-Agent: AlcazarSBC 1.10 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, hold, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 193 X-FS-Support: update_display,send_info v=0 o=FreeSWITCH 1336742245 1336742246 IN IP4 208.103.143.3 s=FreeSWITCH c=IN IP4 208.103.143.3 t=0 0 m=audio 16998 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ FS passes upstream info to Endpoint A, and then sends an update (for the display, I think): send 1045 bytes to udp/[192.168.1.4]:5060 at 18:00:43.330695: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.4;branch=z9hG4bK69b9ae7c0bd9ac684;rport=5060 From: "Phil" <sip:102@192.168.1.6:5060>;tag=6de7cac307 To: <sip:94109693xxx@192.168.1.6:5060;user=phone>;tag=0BaHerZS08taQ Call-ID: 8d9c7aa8f30bc1d3 CSeq: 30988 INVITE Contact: <sip:94109693xxx@71.179.xx.xx:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06 11-27-00 +0000 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Require: timer Supported: timer, precondition, path, replaces Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Session-Expires: 120;refresher=uac Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 193 v=0 o=FreeSWITCH 1336742245 1336742246 IN IP4 208.103.143.3 s=FreeSWITCH c=IN IP4 208.103.143.3 t=0 0 m=audio 16998 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ 2012-05-11 14:00:27.083254 [DEBUG] switch_core_session.c:900 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] send 973 bytes to udp/[192.168.1.4]:5060 at 18:00:43.331578: ------------------------------------------------------------------------ UPDATE sip:102@192.168.1.4:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 71.179.xx.xx;rport;branch=z9hG4bKN3ej0NXFj8ayj Max-Forwards: 70 From: <sip:94109693xxx@192.168.1.6:5060;user=phone>;tag=0BaHerZS08taQ To: "Phil" <sip:102@192.168.1.6:5060>;tag=6de7cac307 Call-ID: 8d9c7aa8f30bc1d3 CSeq: 28043557 UPDATE Contact: <sip:94109693xxx@71.179.xx.xx:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06 11-27-00 +0000 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 193 P-Asserted-Identity: "Outbound Call" <sip:14109693xxx@192.168.1.6> v=0 o=FreeSWITCH 1336742245 1336742246 IN IP4 208.103.143.3 s=FreeSWITCH c=IN IP4 208.103.143.3 t=0 0 m=audio 16998 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ Call completes normally, and everything works. Help me to understand why FS can't do the same thing for extension to extension calls. Thanks again, - Phil ---------- Ken Rice Thu May 10 19:08:53 MSD 2012 The contact IP has nothing to do with where the media goes... That¹s entirely defined in the SDP... Consider this Endpoint A (192.168.100.100) -> NAT A -> FreeSWITCH (4.2.2.2) -> NAT B -> Endpoint B (192.168.100.200) Now lets assume that NAT A and NAT B are 2 separate nat gateways and that Endpoint A and Endpoint B are on 2 different physical LANs... Telling Endpoint A to talk directly to Endpoint B without proxying media will never work since the endpoints think they are on the same LAN. There is no mechanism there to allow for the redirection and automagic adjustments of ports etc so that they can talk directly to each other... Now lets change this slightly so that endpoint B is 192.168.200.200. Unless NAT A knows how to get to 192.168.200.0/24 (assuming class C sized block) and NAT B knows how to get to 192.168.100.0/24 they are both going to use their default routing which is to NAT the outgoing RTP, and forward it to the next hop... Again, RTP will not make it to other side in either direction... FreeSWITCH cant compensate due to a number of factors... Your Endpoints have to be smart enough to actually compensate for the NAT in this situation OR your NAT boxes have to compensate for it... The simple answer, don¹t use bypass media in this situation, the complex answer I wont get into here... Stop by IRC and ask around... There is a 3rd option here you might want to consider, contact consulting at freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> for some professional help... This may not be specifially what you need to get going as I have no clue what your skill level happens to be, and you did say you are still learning. Good Luck!