[Serusers] NAT ping and consumer router

Jiri Kuthan jiri at iptel.org
Mon Aug 23 17:07:23 CEST 2004


At 04:30 PM 8/23/2004, John Todd wrote:

>The problem, as I see it from this discussion, is that some devices do not work correctly with the simple UDP packet sent to port 5060 of the remote UA, because there is no reply packet which is what keeps the NAT mapping of some NAT router/translators.  I don't see this as a UA problem; if there is no NAT translation, then even the best-programmed UA can't receive an inbound INVITE.

It is a UA problem. NATs are based on client-server paradigm, have been there for
a while, and applications desiring to receive packets out should first send some out.
This is a differentiator for many products today. There are such which work
(and have typically other shorctomings), there are broken implementations which
don't. That's just normal early-technology shopping process.

There is a NAT problem too -- NATs feature quite undeterministic behaviour. That's
something that needs to get fixed to and IETF behave effort is good for.

>The manner in which Asterisk handles this type of keepalive is somewhat simple but novel, and may be worth examination.   Every X seconds, an OPTIONS request is made to the remote UA by the server. Even if the UA does not support the OPTIONS query, it typically hands back a SIP error, which serves the purpose of keeping the NAT translations open.  If the device supports OPTIONS, then a "normal" SIP reply is sent, also serving the intended purpose.

Its great it mostly works but it is a hack. It introduces lot of brittlenes -- it will
fail whenever NAT bindings change: if NAT reboots, it will fail if NAT is not too 
deterministic, it will fail if forcible IP address change occurs, etc. Getting it 
robust is simply hard without client support. (Which is BTW a simple application of the e2e 
principle.)


>Perhaps instead of a UDP packet with no content, a SIP OPTIONS request could be sent by SER.  This could perhaps be an selective flag associated with the NAT support in SER, so that either the dummy packet or the OPTIONS packet could be transmitted by the module.
>
>There are other solutions here, like reducing the interval of REGISTER requests to serve the same purpose of refreshing NAT table mappings.  However, one could argue that this method has a much higher load than an OPTIONS packet, especially when scaling across thousands or tens of thousands of clients in an environment where external databases (i.e. Radius, SQL, etc) are used for authentication lookups.

I would like that better. We could perhaps mitigate the performance penalty by granting
re-REGISTERs which don't change too much -- that could be possible done as authentication-less
in-memory lookup.

>Note that there have been numerous examples of such poorly-written SIP stacks on UA devices that they would crash on an OPTIONS request. Their repair is outside the scope of SER or this discussion.

:) Well, broken end-devices are unfortunately a never-ending pain.

So on the to-do-list, I think there is an effort to educate UA vendors how to
get things right, and there is an option to force short re-registration interval
and try to invent some way which will reduced the performance penalty.

-jiri 




More information about the sr-users mailing list