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.