There seems to be a popular misconception that SIP is a UDP protocol, whereas some of our new services, such as the SIP Registration Proxy and our Mobile SIM Registration, both require TCP signalling.
A few customers have asked why we don’t support UDP as this is the ‘standard’ transport for SIP, and the one that would generally be expected.
The Limitations of UDP
Our view is that, in any commercial service, reliability is paramount and UDP has a fundamental flaw which is increasingly apparant as the complexity of services we provide increases (e.g. with the Simwood SIP Signalling Extensions and Mobile) and the SIP message length increases.
A UDP datagram is limited to 1500 bytes, so a message larger than that is split into smaller sections – or fragmented – and these fragments may arrive out of order or be lost entirely as the UDP protocol does not acknowledge or retry packets.
Going Bigger with Mobile
The messages generated by services such as our Mobile SIP Registration can regularly exceed 1500 bytes in size, therefore when we tested this internally, and later with our Developer Pack customers, there was feedback suggesting the service was ‘unreliable’ when, in fact, it was due to intermittent packet fragmentation.
Also, in the case of our registration proxy, most end user devices are behind NAT, and there are considerable advantages to be found using TCP where much longer keep-alive times can be used, especially for mobile devices where this can have a significant impact on battery life.
TCP is Standard
The main specification of the SIP protocol that we use today, RFC 3261 (published in June 2002) mandates that;
“All SIP elements MUST implement UDP and TCP. Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them.”
Therefore all SIP platforms should be compatible with our service, although they may require some additional configuration.
It is true that the Simwood Mobile service technically does not fully comply with the requirements of RFC 3261, due to our decision to support only TCP, but we expect that SIP messages will exceed the UDP datagram size limit (and therefore should be sent with TCP according to RFC 3261 18.1.1 which mandates TCP for large messages) meaning that UDP support would be ineffectual.
Indeed we often see tickets from customers using our normal SIP termination who experience intermittent issues, perhaps from customers with a particular type of IP PBX that is adding numerous extra headers, or a particular manufacturer of phone which supports 30 different codecs out of the box and results in huge SDP payloads. Our advice to many of these is to try sending as TCP, which invariably resolves the problem.
We strongly believe that TCP and TLS are more appropriate for signalling than UDP as SIP evolves and we continue to build in our own innovative functionality controlled by custom headers, or use custom headers to communicate additional information at the time of the call, which within the confines of the UDP datagram we would be unable to provide.
Additionally, switching to TCP may bring you some security benefits if you don’t need UDP support for your devices. Less than 1% of the nefarious scanning traffic we see to our network, and to our honeypots, uses TCP.
Our regular VoIP Termination services continue to support both UDP and TCP.
