[asterisk-dev] STUN support in chan_sip revisited

[Kevin P. Fleming]

On 08/09/2010 09:27 AM, Simon Perreault wrote:
> On 2010-08-09 10:14, Olle E. Johansson wrote:
>>>> And note that this is 100% compliant with RFC 3261. The only purpose of
>>>> the Expires header returned by the registrar is to inform the client of
>>>> the registration's life-time. The client is free to re-register (or not)
>>>> at any moment.
>>>>
>>>> The right value for the Expires header to be sent to the registrar could
>>>> be determined automatically from the Min-Expires header that the
>>>> registrar sends us when it rejects the initial REGISTER with a 423
>>>> (Interval Too Brief). Asterisk would send a new REGISTER request with
>>>> this value but the actual re-registration interval would be the one
>>>> configured statically in sip.conf. Would that work?
>>>
>>> I think yes. But IMO it is not elegant - using STUN or CRLF is more 
>>> elegant. Although not defined in RFC3261, CRLF as keep-alive for UDP is 
>>> well supported.
>>>
>> Adding REGISTER requests might add database lookups and load on 
>> the registrar server, which is not kindly seen...
> 
> Yes, that is the trade-off.
> 
> Does anyone have an idea how to detect when a registration no longer
> works because the NAT rebooted, got a new IP address, or other?

Nope; the only way to test it is to generate a request from somewhere in
the registrar's network, using the registered Contact URI for the AoR in
question, and monitor whether the request is received.

> Using STUN may give false positives and false negatives. For example, if
> the NAT reboots but gets the same IP address, STUN would generate a
> false negative. A false positive would be generated if the NAT uses an
> IP address pool and assigns a different IP address to the STUN binding
> and to the SIP binding.

The proposal here would place a strong preference on having the STUN
client be configured to point to the provider's SIP endpoint, if the
provider supports SIP/STUN multiplexing. In that scenario, the
STUN-discovered address will be the same as the one used for SIP
traffic, since they are going to the same endpoint.

If the SIP provider does not support SIP/STUN multiplexing, or multiple
SIP providers are in use, then yes, a NAT that has multiple external IP
addresses could break this model. However, in my experience that sort of
NAT does not generally have dynamic external addresses, and so this
entire discussion is not really relevant, as everything can be
statically mapped in the Asterisk configuration. If the NAT has multiple
external addresses and doesn't keep a binding persistently open on a
single address (i.e. successive outbound packets to the same endpoint
could originate from different addresses), then SIP behind that NAT is
not likely to work anyway, because the perceived address stored by the
registrar is not likely to accept incoming requests in the future.

> 
> Couldn't we perhaps test the registration by sending an OPTIONS request
> to the registered AOR and use the From tag as a cookie? If we receive
> our request from the registrar, it means the binding is still alive.
> Otherwise, we need to re-register. Also, the OPTIONS request could also
> act as a keep-alive. The trade-off would be additional database lookups.

That assumes that the SIP provider is operating a proxy at the edge that
will accept OPTIONS requests from random endpoints to its internal AoRs
and forward them; while this would be expected in a 'pure SIP
peer-to-peer' model, in the scenarios under discussion (where the
provider is actually a SIP-PSTN trunking provider, and the AoRs in
question are 'account names'), that is not likely to be the case.

> 
>> In this discussion we really need to separate Asterisk as a UA, connecting to services and Asterisk as a server - otherwise it gets too confusing for everyone.
> 
> Absolutely. I think so far we have only discussed the "Asterisk as a
> client" use case.

Yep.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org