[asterisk-dev] STUN support in chan_sip revisited

[Simon Perreault]

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?

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.

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.

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

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org