Subscribe
Lync,Exchange,VoIP,telephony

Why Microsoft use TCP instead of UDP for SIP ?

July 21, 2009 By: Yann Espanet Category: Interoperability

Is better to use TCP rather than UDP for SIP message fragmentation concerns ?

First concerns : maximum size of a UDP datagram

The maximum message size for a UDP datagram socket is limited by the maximum size of an IP datagram and the size of the UDP datagram socket buffer.
The maximum size of an IP datagram limits the maximum message size of a UDP message to 65507 bytes. Therefore, using the maximum socket buffer size will allow multiple maximum-sized messages to be placed on the send queue. The default inbound and outbound message size limit for a UDP datagram socket is 65535 bytes.

The maximum message size for a UDP broadcast is limited by the MTU size of the underlying link, which is 1500 on Ehternet.

Here’s the MTU for different media :

Network MTU

Token Ring 16 Mb/s 17 914

FDDI 4 352

Ethernet 1 500

IEEE 802.3/802.2 1 492

PPPoE 1 480

X.25 576

UDP has no fragmentation mechanism like TCP or IP, but it used the fragmentation of IP layer.

Transmission Control Protocol (TCP) is an example of a protocol that will adjust its segment size to be smaller than the MTU.
User Datagram Protocol (UDP) disregard MTU size thereby forcing IP to fragment oversized datagrams.

Conclusion :

TCP provide transport-layer fragmentation. If a SIP message is larger than the MTU size, it is fragmented at the transport layer. When UDP is used, fragmentation occurs at the IP layer. IP fragmentation increases the likelihood of having packet losses and makes NAT and firewall traversal difficult, if not impossible. This feature will become important if the size of SIP messages grows dramatically.

Second concerns : Multiple-Stage Fragmentation

While the fragments above are in transit, they may need to pass over a hop between two routers where the physical network’s MTU is only 1,300 bytes. In this case, each of the fragments will again need to be fragmented. The 3,300 byte fragments will end up in three pieces each (two of about 1,300 bytes and one of around 700 bytes) and the final 2,100-byte fragment will become a 1300-byte and 800-byte fragment. So instead of having four fragments, we will end up with eleven.

IPfragmentation

This example shows illustrates a two-step fragmentation of a large IP datagram. The boxes represent datagrams or datagram fragments and are shown to scale. The original datagram is 12,000 bytes in size, represented by the large gray box. To transmit this data over the first local link, Device A splits it into four fragments, shown at left in four primary colors. The first router must fragment each of these into smaller fragments to send them over the 1,300-byte MTU link, as shown on the bottom. Note that the second router does not reassemble the 1,300-byte fragments, even though its link to Device B has an MTU of 3,300 bytes.

What about the impact on SIP performance ? A CPU problem, not a network problem ..

Today’s SIP application is mostly operating over the unreliable transport protocol UDP. In lossy environment such as wireless networks and congested Internet networks, SIP messages can be lost or delivered out of sequence. The SIP application then has to retransmit the lost messages and re-order the received packets. SIP has a builtin process for dealing with the unreliable nature of UDP, however to parse the SIP data a transition from kernel to usermode is required. This additional processing overhead can degrade the performance of the SIP application.

Conclusion :
It’s not a network problem, but a CPU problem !

Take a look at this study :
http://www.research.ibm.com/people/n/nahum/papers/sigmetrics07-sip-perf.pdf

Security concerns ?

  • UDP packets are not interrogated in the same manner as TCP packets making it an easy way to exploit SIP problems.
  • UDP posses a problem for NAT traversal, QOS, and fragmentation.
  • Authentication – By using TCP you can leverage TLS and SRTP to make it extremely difficult to ease drop on conversations.

What about SCTP to transfer SIP messages ?

Ref : RFC 4168
http://www.rfc-editor.org/rfc/rfc4168.txt

Therefore to solve this problem, the researchers are looking for a more appropriate transport layer for SIP. SCTP, a transport protocol providing acknowledged, error-free, non-duplicated transfer of messages, has been proposed to be an alternative to UDP and TCP. The multi-streaming and multi-homing features of SCTP are especially attractive for applications that have stringent performance and high reliability requirements and an example is the SIP proxy server.

Ref :
http://www.bth.se/fou/cuppsats.nsf/all/7d8446ad03071d5ac12575890073deec/$file/Thesis%20Report%20Final.pdf

But additional testing need to be done, and Microsoft doesn’t support SCTP for the moment !

Another article can be found there :

Increased SIP Performance with Stream Control Transmission Protocol
http://blog.tmcnet.com/cross-talk/2008/07/increased-sip-performance-with-stream-control-transmission-protocol.html

SCTP and its applications
http://www.apng.org/9thcamp/Slide/Satit.pdf

Is Microsoft does not support UDP for SIP implementation at all ?

Right in OCS but not in his small business product !, Microsoft SIP Solution for Small Business support UDP !!

http://www.microsoft.com.nsatc.net/responsepoint/resources-whitepapers-sbsintegration.aspx

“Microsoft Response Point is complete phone system software designed specifically for small businesses with 1-50 employees. In the past, deploying an advanced phone system to a small business was considered impractical.”

“Network Protocols
Response Point transfers data and communicates using standard protocols. Generally, there should not be any network configuration changes needed to support these protocols. All hardware and software connected to your network—the router, SBS, and other computers— should work automatically with the following protocols:

Session Initiation Protocol (SIP over UDP) to establish and coordinate phone calls between devices.

  • Real-time Transport Protocol (RTP) to transmit audio over the LAN in the G.711 μLaw and G.723 encoding formats.
  • Secure Hypertext Transfer Protocol (HTTPS) and Extensible Markup Language (XML) to communicate configuration settings between the Administrator program and base unit, or the Assistant program and base unit.
  • Dynamic Host Configuration Protocol (DHCP) to acquire IP addresses; to discover the location of the base unit; and to discover phones and phone line adapters that have not been provisioned yet.
  • Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML) to provision phones and phone line adapters.”

1 Comments to “Why Microsoft use TCP instead of UDP for SIP ?”


  1. Extract from Microsoft whitepaper : “Integrating Enterprise Telephony with
    Office Communications Server 2007 R2”

    UDP as a SIP Transport

    In IP telephony, the most fundamental level of interoperability is in the IP transport protocol used to convey SIP messages from one network element to another. Generically, SIP can use (at least) three types of transport: UDP, TCP and TLS (this is defined in the base SIP spec, RFC 3261). However, Office Communications Server only supports TCP and TLS, with the latter being the default (actually, TLS runs on TCP). If a third-party network element only supports UDP, there would be a fundamental disconnect with Office Communications Server. This is particularly problematic in the “SIP trunking” domain (see earlier discussion), where many service providers currently only support UDP as a SIP Transport.

    The lack of support for UDP is not an oversight but rather a conscious engineering decision based on the suitability of UDP as a SIP transport. There are three issues with UDP:

    1.It is not encrypted, so users cannot ensure end-to-end security of SIP messages over UDP. There is no shortage of opinions on the security, or the lack thereof, of SIP (e.g., Cert® Advisory). As a text-based protocol that is human-readable, there are privacy/security issues of sending SIP “in clear.” Furthermore, UDP allows for easier spoofing of packets since the connection state doesn’t need to be maintained (remember SQL Slammer? [http://en.wikipedia.org/wiki/SQL_slammer]). This is why customers are strongly recommended to accept TLS over TCP as the default SIP transport within the Office Communications Server network.

    2.UDP has a fundamental flaw for large SIP messages: the size of the UDP datagram is limited to 1,500 bytes, so a SIP message larger than that will be broken into two or more packets. The application layer (client or server) can receive the fragments out of order or a fragment could be lost (see the third issue, below). Since Office Communications Server SIP messages tend to contain various XML bodies, machine-generated unique IDs (e.g., GRUUs), ICE candidate attributes, etc., they will normally span multiple packets.

    3.UDP is a “fire and forget” protocol: this is, the transport layer does not consider lost or delayed packets. The onus of tracking messages for which no response has been received (and the generation of new requests) is left to the application layer. This leaves the application (the client or the server) vulnerable to overload situations. In bad network conditions, the best case scenario is a call setup delay. The worst case scenario is that the SIP network can reach a tipping point where the session timers are tripping for every transaction because the network elements are busy generating, or responding to, “retries”—a “retry storm.”
    UDP presents challenges in the areas of security, reliability and scalability and the SIP RFCs allow us to choose from alternative SIP transports. Within the Office Communications Server network, we use TLS; at the edge of the network, we can interoperate over TCP.

    1