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.

FAQ: What are the transport protocols for the Session Initiation Protocol?

SIP itself is not a transport protocol. It relies on other protocols to carry it from element to element. SIP was designed to allow almost any transport protocol to be used. Currently, the specifications define how to carry SIP using the User Datagram Protocol (UDP), the Transmission Control Protocol (TCP) (which is also used for SIP using Transport Layer Security (TLS)), and the Stream Control Transmission Protocol (SCTP). There are extension points built into the protocol that will allow new transports to be used as they become needed.

SIP transactions (request-response exchanges) use state machines to ensure the various transports get used correctly. These state machines are designed to take advantage of transport reliability when it exists, and to ensure reliable delivery of messages themselves when the underlying protocol does not offer that guarantee.

A given request may be carried over several different transports as it makes its way through SIP proxies towards its destination. A pair of state machines work in tandem along each SIP-stateful "hop" to ensure the message is transported successfully. In the following figure, a request starting at the caller traverses a UDP hop, an SCTP hop, and a TCP hop before reaching the callee. The callee's response is returned along the path the request created. The leftmost pair of state machines will use timers to periodically retransmit messages to protect against dropped packets over the UDP hop. The other state machine pairs will only run timers to measure how long to wait for a response and will not cause retransmission to happen.



The SIP messages exchanged by those state machines carry a record of what transport is being used. Each element sending a request adds information about itself to the Via header field by adding a value before any other values. The messages traversing the right-most hop in the figure would have a set of Via header field values similar to the following:

Via: SIP/2.0/TCP P2.tekelec.com;received=10.0.0.3;rport=5060;branch=z9hG4bK939ddn23d
Via: SIP/2.0/SCTP P1.tekelec.com;received=10.0.0.2;rport=5060;branch=z9hG4bK33u9c9wjnn32s
Via: SIP/2.0/UDP caller.tekelec.com;received=10.0.0.1;rport=5060;branch=z9hG4bK776asdhds


A given request may also encounter very different protocol hops down different branches of a forked request



Each of the different transport protocols has advantages and shortcomings. UDP, for instance, does not provide congestion control and networks may behave badly when packets fragment. TCP exhibits head-of-line blocking by design, potentially resulting in high latency for many messages when things don't go smoothly for just one of them. The choice for which protocol to use depends very much on the network properties and application goals for each hop. Service providers can use the DNS-based mechanisms defined in "Locating SIP Servers" (RFC3263) to let an element know which transport to use.

How best to support BICC-SIP interworking?

It has been nearly two years since 3G Americas published its whitepaper, Why SIP-I - A Switching Core Protocol Recommendation for GSM/UMTS Operators, providing a strong argument for using SIP-I as the recommended voice call control for GSM and 3G networks. The whitepaper compared SIP-I with ISUP encapsulation, SIP-T (IETF standard) with ISUP encapsulation and Bearer Independent Call Control (BICC); and provided a convincing argument in favor of SIP-I. All the standard bodies, including 3GPP, ITU, ETSI and ANSI, have chosen SIP-I as the session control protocol for the reference architecture.

But when we look at network deployments, BICC continues to show strong deployment presence in many 3G networks. Many of the investments in BICC-based core networks are recent and continue today. Therefore, it will be a long time before this infrastructure is written off by operators. However, it is more likely that BICC will remain confined within an administrative network domain, with a Network-to-Network interface between domains using SIP-I. This necessitates interworking between BICC and SIP-I.

While a Softswitch gateway-based solution was suitable for ISUP-SIP interworking, it is not the most efficient solution for BICC-SIP interworking. ISUP-SIP interworking must handle media incompatibility, whereas BICC-SIP interworking could take place purely in the signaling domain (provided there is media compatibility), since both use RTP for voice. The ideal place to implement such interworking is at a Signaling Proxy. There are three potential proxies where such interworking could take place:

1. The Signal Transfer Point (STP) that acts as a routing hub for the BICC messages at the SCTP layer
2. The Call Mediation Node (CMN) defined in the 3GPP R4 architecture. This is the BICC equivalent of the SIP Proxy Server
3. The SIP Proxy Server

With these thoughts, I'd like to open up the discussion to our reader community. Here are a few questions to get the dialogue going:

• Do you agree that BICC-SIP interworking at the signaling plane makes sense and not in a Softswitch or an MSC Server?
• If so, in your view, which of the three nodes above is better suited architecturally? And why?
• Do you think that more standards work is necessary and where should it be done.

Architectural Options for Core SIP Signaling Networks: Part 2

This is the second of two blog postings on this topic. The first posting was on April 21^st and can be accessed by clicking HERE.

Once we make the determination that SCTP will be the foundation for building a Signaling Transport Network, many important issues must be addressed. SCTP is a connection oriented protocol with advanced features such as multi-homing and multi-streaming that can be leveraged to both enhance reliability and scalability.

However, it also makes the network design that much more complex. Therefore, it is essential that a common architecture strategy be defined for all types of signaling (SS7, BICC, SIP, LTE X2AP/S1AP, DIAMETER etc.). Instead of building islands of Signaling Transport infrastructure, it has to be built as a common resource that can serve as a shared transport for different types of controlling/signaling information. The connection oriented nature of SCTP imposes certain challenges with respect to network scalability. Having one or more SCTP hubs that centralize the SCTP connection to all the end nodes simplifies both interoperability between different network elements and enhances the network scalability. Higher layer session level routing (such as Global Title Translation, SIP Proxy Routing, ENUM resolution) could be added on top of the centralized SCTP layer, thus offloading many of these functions from the end nodes. The architecture is not voice-centric and can be reused for any non-VoIP services that use SIP-like signaling. The architecture also facilitates network monitoring by providing a centralized vantage point in the Signaling network. Architectural strategies such as path diversity are addressed once and reused for all types of signaling.

This approach has already been applied by many operators for both traditional TDM networks that use SS7 and VoIP networks using BICC. However, most initial SIP-based VoIP networks today use SIP over UDP (and sometimes TCP.) Is it time to make the transition to carry SIP over SCTP and have a common signaling transport strategy? If you agree that we should not build airplanes based on who travels in it, then you probably agree with this common signaling transport strategy too.

I look forward to hearing your comments.

Architectural Options for Core SIP Signaling Networks

This is the first of two blog postings on this topic. The second posting is planned for Tuesday, April 28th.

Most early VoIP networks that use SIP Signaling use UDP as the transport layer for carrying signaling and payload. The advantage of using UDP as a transport layer protocol is that it is simple, has low overhead and is omnipresent. The disadvantage of UDP is that it is not a guaranteed delivery protocol.

While UDP is good enough for carrying the payload such as voice, its suitability for carrying Control Information is debatable.  Message loss has very limited impact on the quality of voice (hardly noticeable), whereas signaling message loss could have a significant impact on the quality of session setup (post-dial delay, dropped sessions, session setup time etc.), network resource utilization, and charging functions.

Use of UDP can also be justifiable at the edge of the network (User to Network boundary), where the advantage of simplicity and scalability outweighs any reliability requirements. However, as SIP becomes a mainstream signaling control protocol within carrier core networks, using SIP over UDP is questionable. Looking at the past, when carriers migrated SS7 signaling from TDM to IP, experience clearly indicates that SS7 over UDP (or TCP) was not a feasible option. The industry standardized on SS7 over SCTP implementation, which was developed as part of SIGTRAN group of protocols. The same was also true with BICC networks as mobile carriers started deploying R4 Mobile Switching Servers. Looking into the future, LTE networks and the IMS architecture have standardized on SCTP as the standard transport layer protocol for signaling.

What are the challenges of building a large scale SIP-based signaling network using SCTP as the foundation? Is it scalable? Have standard bodies addressed all the architectural issues related to building a large scale SIP signaling network over SCTP? I will be talking more about this next week, and meanwhile I would like to know what you think about this?