Nevermind! As it turns out, FS does send the correct external/NAT IP addresses as long as BOTH extensions are set for bypass media. Forgive me for ever doubting... Of course it still doesn't work for reasons discussed earlier, although I think that it should work as long as there's no symmetric NAT involved. I'm guessing session border controller(s) will be the next step if we want to remove the endpoint to endpoint traffic from our network. Any suggestions? OpenSIPS certainly looks promising. Thanks, - Phil -----Original Message----- From: Phil Quesinberry Sent: Friday, May 11, 2012 2:41 PM To: 'freeswitch-users@lists.freeswitch.org' Subject: Bypass media succeeds from extension to gateway but fails from extension to extension 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. ...

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: ...

---------- 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!