[asterisk-dev] STUN support in chan_sip revisited

David Vossel dvossel at digium.com
Mon Aug 9 16:25:22 CDT 2010


----- Original Message -----
> From: "Simon Perreault" <simon.perreault at viagenie.ca>
> To: asterisk-dev at lists.digium.com
> Sent: Monday, August 9, 2010 9:42:38 AM
> Subject: Re: [asterisk-dev] STUN support in chan_sip revisited
> On 2010-08-09 10:39, Kevin P. Fleming wrote:
> > If the STUN requests are being sent often enough, the NAT binding
> > will
> > be kept open, and the IP address reported will not change.
> 
> Got it. As soon as you detect *any* change, not just IP address
> change,
> it means that something went wrong and you should re-register.
> 
> I like it a lot.
> 
> (Sorry for being so slow to understand...)
> 
> Simon


Based on our discussion so far, here is what action I am proposing we do now. 

1. Remove current STUN support in chan_sip.  More than likely we will decide to just depreciate it's use in sip.conf.sample but leave the code.  This means anyone using this broken implementation to do something they perceive as being useful will not lose the ability to do so, but the sip.conf options will be removed from the documentation.

2. Add STUN support for detecting external network changes.  This will include a new res module call something like "res_stun.c" which will act as a STUN client and update event listeners to any changes in the network's ip or port.  In chan_sip I propose we use the event generated by a network change to cause all sip registrations to renew... I suppose I could make chan_iax exhibit the same behavior.  In the future I'm sure other channel drivers will find implement usages of this event as well.

3. Continue discussions on what if any RFC compliant STUN support we should introduce into chan_sip and what use cases we want to solve.

Thanks for all your help so far!

David Vossel
Digium, Inc. | Software Developer, Open Source Software
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
The_Boy_Wonder in #asterisk-dev



More information about the asterisk-dev mailing list