<HTML>
<HEAD>
<TITLE>Re: [Freeswitch-users] Bypass media succeeds from extension to gateway but fails from extension to extension</TITLE>
</HEAD>
<BODY>
<FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:11pt'>The contact IP has nothing to do with where the media goes... That&#8217;s entirely defined in the SDP... <BR>
<BR>
Consider this &nbsp;&nbsp;&nbsp;Endpoint A (192.168.100.100) -&gt; NAT A -&gt; &nbsp;FreeSWITCH (4.2.2.2) &nbsp;-&gt; NAT B -&gt; Endpoint B (192.168.100.200)<BR>
<BR>
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... &nbsp;&nbsp;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... <BR>
<BR>
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...<BR>
<BR>
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...<BR>
<BR>
The simple answer, don&#8217;t use bypass media in this situation, the complex answer I wont get into here... Stop by IRC and ask around... <BR>
<BR>
There is a 3rd option here you might want to consider, contact <a href="consulting@freeswitch.org">consulting@freeswitch.org</a> 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. <BR>
<BR>
Good Luck!<BR>
<BR>
<BR>
<BR>
On 5/10/12 9:38 AM, &quot;Phil Quesinberry&quot; &lt;<a href="philq@qsystemsengineering.com">philq@qsystemsengineering.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><SPAN STYLE='font-size:11pt'><FONT FACE="Calibri, Verdana, Helvetica, Arial">Thanks Ken. </FONT><FONT FACE="Monaco, Courier New"> </FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">I&#8217;m still learning here, so if that&#8217;s the case then help me to understand</FONT><FONT FACE="Monaco, Courier New"> </FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">why FS properly sends the external address when that same extension makes a call out through a gateway instead of to another extension. &nbsp;Same settings, same originating extension.<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">I</FONT><FONT FACE="Monaco, Courier New"> </FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">did try enabling</FONT><FONT FACE="Monaco, Courier New"> </FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">ndlb-connectile-dysfunction to rewrite the contact IP on those calls</FONT><FONT FACE="Monaco, Courier New"> </FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">but</FONT><FONT FACE="Monaco, Courier New"> </FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">to no avail.<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">Thanks!<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">- Phil<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><B>----------<BR>
</B></FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><B>Ken Rice<BR>
</B><I>Tue May 8 11:38:48 MSD 2012</I> <BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Courier New">This is not a bug in FreeSWITCH...<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Courier New">Bypass Media is a special mode to allow us to act as a psuedo proxy.<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Courier New">Other then possibly filtering some codecs the rest of the SDPs are simply<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Courier New">copied across the bridge. That means if your sip devices are sending RFC1918<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Courier New">IPs in their SDPs then FreeSWITCH will forward an RFC1918 SDP. Why is that?<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Courier New">Because FreeSWITCH has no way to know where the media is actually coming<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Courier New">from since FreeSWITCH is not in the media path.<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Courier New">K<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Tahoma, Verdana, Helvetica, Arial">_____________________________________________<BR>
<B>From:</B> Phil Quesinberry</FONT><FONT FACE="Monaco, Courier New"> <BR>
<BR>
</FONT><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><B>Sent:</B> Monday, May 07, 2012 11:54 AM<BR>
<B>To:</B> <a href="'freeswitch-users@lists.freeswitch.org">'freeswitch-users@lists.freeswitch.org</a>'<BR>
<B>Subject:</B> Bypass media succeeds from extension to gateway but fails from extension to extension<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">I&#8217;m not sure if this is a bug or just a NAT-related configurational problem. &nbsp;If it&#8217;s truly a bug, let me know and I&#8217;ll be happy to file a Jira.<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">I&#8217;m trying to get bypass media to work with extension to extension calls. &nbsp;Both endpoint extensions are behind NAT in two different locations. &nbsp;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&#8217;s external IP address as it should, and the call succeeds.<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">Everything works fine, of course, when &#8220;proxy media&#8221; is used.<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">The SIP traffic for the failed call is here, look for the word &#8220;WRONG!&#8221; to see the incorrect address being passed in the SDP:<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Calibri, Verdana, Helvetica, Arial"><U><a href="http://pastebin.freeswitch.org/19003">http://pastebin.freeswitch.org/19003</a></U></FONT></FONT><FONT FACE="Monaco, Courier New"> &lt;<a href="http://pastebin.freeswitch.org/19003">http://pastebin.freeswitch.org/19003</a>&gt; <BR>
<BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial">Regards,<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Times New Roman"><I>Phil Quesinberry<BR>
</I></FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Arial">Q Systems Engineering, Inc.<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Arial">Electronic Controls and Embedded Systems Development<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT FACE="Arial">(410) 969-8002<BR>
</FONT><FONT FACE="Monaco, Courier New"><BR>
</FONT><FONT COLOR="#0000FF"><FONT FACE="Arial"><U><a href="http://www.qsystemsengineering.com">http://www.qsystemsengineering.com</a></U></FONT></FONT><FONT FACE="Monaco, Courier New"> &lt;<a href="http://www.qsystemsengineering.com">http://www.qsystemsengineering.com</a>&gt; <BR>
<BR>
<BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"></FONT></SPAN><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>_________________________________________________________________________<BR>
Professional FreeSWITCH Consulting Services:<BR>
<a href="consulting@freeswitch.org">consulting@freeswitch.org</a><BR>
<a href="http://www.freeswitchsolutions.com">http://www.freeswitchsolutions.com</a><BR>
<BR>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<BR>
<a href="http://www.cudatel.com">http://www.cudatel.com</a><BR>
<BR>
Official FreeSWITCH Sites<BR>
<a href="http://www.freeswitch.org">http://www.freeswitch.org</a><BR>
<a href="http://wiki.freeswitch.org">http://wiki.freeswitch.org</a><BR>
<a href="http://www.cluecon.com">http://www.cluecon.com</a><BR>
<BR>
FreeSWITCH-users mailing list<BR>
<a href="FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><BR>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><BR>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><BR>
<a href="http://www.freeswitch.org">http://www.freeswitch.org</a><BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>