neutrino38's Journal: SIP over TCP - using it in NAT friendly way

I have recently browsed through the latest SIP RFC looking for ways to be more NAT friendly for VoIP.

What I found is not very conclusive: The latest RFC indeed tries to push TCP as default transport for SIP (Yessss signalling links are making a come back) but the use of TCP connection is left to a lot of ambiguities.

We will assume the following situation. User runs a SIP phone (User Agent is RFC terminology) on his internet connection at home or at the office. He is most likely behind a NAT / Firewall and connects to a SIP proxy located on the public Internet with a public IP address.

Specifying a NAT Friendly SIP behavior

In order to be NAT friendly, SIP behavior between User Agent and proxy should be the following:

• On registration, user agent shall initiate a TCP connection to the proxy. If the registration is successful, user agent and proxy MUST maintain TCP connection open.
• If TCP keepalive is supported, it SHOULD be used
• If TCP keepalive in unavailable, User Agent SHOULD send OPTION request to proxy regularily (every 30 seconds) and expect the answer 200 OK. These queries can be omitted if other SIP traffic occurs.
• In case answer is not 200 OK or not received after a timeout, connection shall be terminated and registration process restarted.
• Proxy MUST base User Agent availability upon TCP connection status and TCP or option keepalive.
• User agent MUST reuse connection when initiating and outgoing session.
• and the most important: proxy MUST reuse open inbound connection when signalling an incoming call to the User Agent.

This also addresses the case where a company would run an internal SIP proxy which in turn would connect to another public SIP proxy.

On the contrary, this is not adressing the RTP issue that is more of a headache for NAT traversal. This will be the topic of another article.

For reference, here is an abstract of the current RFC

18 Transport

The transport layer is responsible for the actual transmission of
requests and responses over network transports. This includes
determination of the connection to use for a request or response in
the case of connection-oriented transports.
The transport layer is responsible for managing persistent
connections for transport protocols like TCP and SCTP, or TLS over
those, including ones opened to the transport layer. This includes
connections opened by the client or server transports, so that
connections are shared between client and server transport functions.
These connections are indexed by the tuple formed from the address,
port, and transport protocol at the far end of the connection. When
a connection is opened by the transport layer, this index is set to
the destination IP, port and transport. When the connection is
accepted by the transport layer, this index is set to the source IP
address, port number, and transport. Note that, because the source
port is often ephemeral, but it cannot be known whether it is
ephemeral or selected through procedures in [4], connections accepted
by the transport layer will frequently not be reused. The result is
that two proxies in a "peering" relationship using a connection-
oriented transport frequently will have two connections in use, one
for transactions initiated in each direction.
It is RECOMMENDED that connections be kept open for some
implementation-defined duration after the last message was sent or
received over that connection. This duration SHOULD at least equal
the longest amount of time the element would need in order to bring a
transaction from instantiation to the terminated state. This is to
make it likely that transactions are completed over the same
connection on which they are initiated (for example, request,
response, and in the case of INVITE, ACK for non-2xx responses).
This usually means at least 64*T1 (see Section 17.1.1.1 for a
definition of T1). However, it could be larger in an element that
has a TU using a large value for timer C (bullet 11 of Section 16.6),
for example.

All SIP elements MUST implement UDP and TCP. SIP elements MAY
implement other protocols.

Making TCP mandatory for the UA is a substantial change from RFC
2543. It has arisen out of the need to handle larger messages,
which MUST use TCP, as discussed below. Thus, even if an element
never sends large messages, it may receive one and needs to be
able to handle them.