[asterisk-dev] STUN support in chan_sip revisited

[Klaus Darilion]

Am 09.08.2010 16:27, schrieb 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.

In this case I guess the public port changes too - so you might detect 
it by changed public port. If the port stays the same for the STUN 
lookup, then it probably will also stay the same for the SIP messages.

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

I think such a scenario happens only with "high-tech" firewalls like 
Cisco, Checkpoint .... IMO in such setups it is not Asterisk which has 
to deal with such a setup, but the "high-tech" firewall should handle 
this (e.g. configure on the firewall/NAT a static public IP address for 
the Asterisk server).

> 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

Probably this won't work if the proxy/registrar is something like Asterisk.

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

This is also my understanding.

regards
klaus