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.

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.”