[Freeswitch-users] Strategies for reliably detecting nat on B-leg?
Michael Jerris
mike at jerris.com
Sat Jan 30 18:35:14 PST 2010
There is no even remotely reliable way to tell. The only thing you can tell is for some devices you can know they ARE behind nat, you can't ever know reliably that they are not. That being said, I am not sure that is really the measure you are looking for. It may be enough to know that the devices reliably tell you their external ip and port in their sdp. For the a leg, you certainly know this before hand. For the b leg you would not at dialplan time. If you are looking to save bandwidth, the only real way of dealing with this would be to perform these actions at some point after the initial call is set up. This will allow freeswitch to handle any initial audio indications that may be necessary, and for you to definitively know that it has 2 remote endpoints capable of at least handling nat for rtp. You could do something from a monitoring application such as using uuid_media to trigger the freeswitch box out of the media path after the call has set up and you have confirmed the endpoints are well behaved. The one thing you should be careful of in this case would be if freeswitch ever has to do an auto-adjust when initially setting up the media, this means the other end lied about either its ip or port. This could be an indication of both software that can not report its remote IP in sdp or of a firewall that is changing the port. The firewall changing port scenario you can not use bypass media unless the other device uses an auto-adjust method like freeswitch. If it just lies about its IP, you could conceivably re-write the sdp with the correct ip and port, but freeswitch does not support this and I don't see it being likely that this would be added. For you to accomplish this, you likely wold need to add some events to better monitor auto-adjust in the rtp and have some application (either as a freeswitch module, script, or some app attached to event socket) monitor these events and take action.
Mike
On Jan 27, 2010, at 1:44 PM, Bill W wrote:
> Thanks for the reply!
>
> Just to make sure we're on the same page, my FreeSWITCH sesrver has a
> public IP, and I'm trying to bypass media whenever possible to reduce my
> bandwidth usage. My concern is trying to bypass media when one of the
> remote endpoints (b-leg) is behind NAT (since I can reliably detect nat
> with aggressive-nat on the A-leg).
>
> Isn't local-network-acl and autonat:x.x.x.x for FS behind nat?
>
> Does this new information change your responses?
>
> Thanks again!
> Bill
>
>
>
> Anthony Minessale wrote:
>> also you can set
>> sip_sticky_contact=true
>> channel var which will make that session turn on nat lock in the b leg
>> so they can't change the contact to a nat addr
>>
>> add it in {} to your dial string like
>>
>> {sip_sticky_contact=true}sofia/internal/foo at bar.com <mailto:foo at bar.com>
>>
>>
>>
>>
>> On Wed, Jan 27, 2010 at 11:50 AM, Brian West <brian at freeswitch.org
>> <mailto:brian at freeswitch.org>> wrote:
>>
>> update to trunk. and don't use agressive-nat, set
>> local-network-acl, set the ext-rtp-ip and ext-sip-ip to
>> autonat:x.x.x.x or if you're behind a natpmp or upnp router set it
>> to auto-nat.
>>
>> It should just work. Again you have no real way to know if the far
>> end client never lies to you. Which it should never do anyway.
>> Endpoints should know how to traverse their own nat and not leave
>> it up to the registrar to figure it out.
>>
>> /b
>>
>> On Jan 27, 2010, at 11:31 AM, Bill W wrote:
>>
>>> Thoughts? Suggestions?
>>
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> <mailto: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
>>
>>
>>
>>
>> --
>> Anthony Minessale II
>>
>> FreeSWITCH http://www.freeswitch.org/
>> ClueCon http://www.cluecon.com/
>> Twitter: http://twitter.com/FreeSWITCH_wire
>>
>> AIM: anthm
>> MSN:anthony_minessale at hotmail.com
>> <mailto:MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org
>> <mailto:sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888
>> <http://iax:guest@conference.freeswitch.org/888>
>> googletalk:conf+888 at conference.freeswitch.org
>> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:+19193869900
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
More information about the FreeSWITCH-users
mailing list