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