[Freeswitch-users] Bypass media succeeds from extension to gateway but fails from extension to extension

[Ken Rice]

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



On 5/10/12 9:38 AM, "Phil Quesinberry" <philq at qsystemsengineering.com>
wrote:

> Thanks Ken.  I¹m still learning here, so if that¹s the case then help me to
> understand why FS properly sends the external address when that same extension
> makes a call out through a gateway instead of to another extension.  Same
> settings, same originating extension.
> 
> I did try enabling ndlb-connectile-dysfunction to rewrite the contact IP on
> those calls but to no avail.
> 
> Thanks!
> 
> - Phil
> 
> ----------
> 
> Ken Rice
> Tue May 8 11:38:48 MSD 2012
> 
> This is not a bug in FreeSWITCH...
> 
> Bypass Media is a special mode to allow us to act as a psuedo proxy.
> 
> Other then possibly filtering some codecs the rest of the SDPs are simply
> 
> copied across the bridge. That means if your sip devices are sending RFC1918
> 
> IPs in their SDPs then FreeSWITCH will forward an RFC1918 SDP. Why is that?
> 
> Because FreeSWITCH has no way to know where the media is actually coming
> 
> from since FreeSWITCH is not in the media path.
> 
> K
> 
> _____________________________________________
> From: Phil Quesinberry
> 
> Sent: Monday, May 07, 2012 11:54 AM
> To: 'freeswitch-users at lists.freeswitch.org'
> Subject: Bypass media succeeds from extension to gateway but fails from
> extension to extension
> 
> I¹m not sure if this is a bug or just a NAT-related configurational problem.
> If it¹s truly a bug, let me know and I¹ll be happy to file a Jira.
> 
> I¹m trying to get bypass media to work with extension to extension calls.
> Both endpoint extensions are behind NAT in two different locations.  This
> looks like a possible bug because FS sends the internal IP address of one of
> the endpoints to the other for media, but when making a call from the same
> extension to an external gateway for PSTN termination, it sends the phone¹s
> external IP address as it should, and the call succeeds.
> 
> Everything works fine, of course, when ³proxy media² is used.
> 
> The SIP traffic for the failed call is here, look for the word ³WRONG!² to see
> the incorrect address being passed in the SDP:
> 
> http://pastebin.freeswitch.org/19003 <http://pastebin.freeswitch.org/19003>
> 
> Regards,
> 
> Phil Quesinberry
> 
> Q Systems Engineering, Inc.
> 
> Electronic Controls and Embedded Systems Development
> 
> (410) 969-8002
> 
> http://www.qsystemsengineering.com <http://www.qsystemsengineering.com>
> 
> 
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> 
> 
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120510/ac395c60/attachment.html