SIP Sessions

SIP and Transport Protocols: Do's and Don'ts

Session Initiation Protocol messages can be transported over several different protocols: UDP, TCP, SCTP; each of which has advantages and disadvantages. What  follows is an overview of them.

SIP over User Datagram Protocol (UDP)

UDP is the simplest way of transmitting chunks of data from one host to another in an IP network. Provided that the amount of data to be sent at once is not too big, UDP will do its best to accomplish the task. Pretty fast too. If the programmers did their job correctly, multi-process or multi-threaded applications do not require extra synchronization delay since the read/write operations are atomic when it comes to UDP sockets.

What you get is maximum throughput. However, this comes at a cost - it may trigger congestion.  Congestion means basically that the infrastructure cannot support the amount of traffic that is sent/received through it. Congestion can show up in different parts and layers of the infrastructure:

• it can happen on the way to the remote host - network congestion; in this case the network cannot route and transport at the expected rate.
• it can happen on the remote host itself - application congestion; the end host (a sip proxy for example) cannot process the packets as fast as they are received.

Since UDP and SIP do not provide any explicit mechanism for overcoming congestion, it has to be taken care of in the signaling application.

Here is an example of application congestion that can take place during a failover in an active/standby configuration of sip proxies. The active proxy fails and the standby one takes over after several seconds; due to the SIP retransmissions the newly active proxy will experience traffic spikes which persist for some seconds after the service functions again. In the case where the traffic rate both before and after the failover happened is close to the engineered calls-per-second (limit supported by the proxy), these spikes may lead to application congestion on the proxy which has just become active.

Another drawback of UDP is that it does not provide either acknowledgment of received datagrams or retransmission mechanisms; SIP takes care of this at application level by using a simple retransmission algorithm.

SIP over Transmission Control Protocol (TCP)

TCP offers a lot more than UDP when it comes to congestion, retransmission and error control. However, TCP is a stream oriented protocol which was designed for transferring reliable chunks of data from host A to host B. Signaling with real-time constraints was not one of the design requirements for TCP.

Conceptually, a TCP based application sees received or sent data as a continuous flow; and this is correct for applications that copy files from remote hosts. For protocols like SIP which is using delimited messages sent over the same TCP connections, things are getting more complicated. The reads and writes on the TCP socket have to be serialized and the reading of the SIP message from the stream is more complicated than in the case of UDP since it may arrive in different TCP segments whose payloads are not delivered all at once to the user space socket.

Standard TCP implementations do not allow configuration of internal timers. Timing is important for SIP based applications though. For example, in the telecom world you need to be able to tell pretty fast whether your peer is still there or not.

TCP subsystems on modern operating systems offer some support for that: keep-alives. These are basically empty TCP segments having the ACK flag set, which are sent periodically in case of idle intervals to monitored peers. If the peer is still running it answers back an ACK, otherwise there is no answer and the local application knows that either the remote peer has crashed or there are problems at lower layers. Again, modern operating systems like Linux offer the possibility to configure the timeouts for the keep-alive mechanism:

• for how long a connection should be idle before sending keep-alives; one drawback here is that the minimum value for this parameter is 1 second
• how often the keep-alives should be sent; again the minimum value is 1 second
• how many keep-alives are sent before the peer is declared dead

SIP over Stream Control Transmission Protocol (SCTP)

SCTP can be considered the Swiss army knife of transport protocols. It basically offers combined features of both UDP and TCP. UDP-like features are: message boundary preservation, unordered message delivery, one-to-many sockets at the application level. Among TCP-like features: positive (selective) acknowledgment, retransmission of lost data, windowed flow control, congestion control, one-to-one sockets at the application level. What makes SCTP unique are some features which do not appear in other transport protocols:

• multihoming
• multiple streams per connection
• built-in heartbeats
• much more flexible when it comes to configuring certain parameters - especially for controlling timing
• exposes asynchronously its internal states to the application level through the use of notifications

How much of this is useful for SIP? Message boundary preservation as in case of UDP will make reading/parsing of the SIP message easier; whereas unordered message delivery can help in case of head of line blocking.

What is really helpful for real time oriented applications is that SCTP sockets offer fine tuning of timer values and more details about what has happened on a certain association. The parameters that control the timers for association setup, retransmissions and heartbeats, are configurable per system and per socket. Transport layer failure detection can work fast when appropriate values for SCTP heartbeats are used.

Things get even simpler from the application layer programming perspective. The SCTP notifications provide the means of monitoring what happens with a certain SCTP socket and are standardized by the SCTP socket API. A broad range of asynchronous notifications are sent on the SCTP socket: association start-up, association setup attempt failure, transport-level events, remote operational errors, undeliverable messages.

There are of course pitfalls - SCTP is a relatively newcomer in the transport protocols ecosystem. The SCTP socket API is a moving target still under development. Due to novelty, the level of complexity of some of the SCTP stack implementations is inversely proportional with the time spent on testing them; sometimes their performance in terms of throughput is not on a par with the one offered by TCP.