SIP Reliability

SIP can run over both TCP and UDP. Clearly UDP is an unreliable protocol, and so in this case SIP must provide its own reliability, which it does by retransmission. So why run SIP over UDP when TCP provides reliability for free?

In truth, this reliability is not ``for free''. When you use TCP, you use a general purpose reliable transport protocol, and you get TCP's concept of what reasonable retransmission timeouts are. TCP is also totally reliable - once data is put into a TCP connection, it will eventually come out the other end unless the connection is terminated. Sometimes this isn't what we want, because old data has been superseded by new data, and if the old data hasn't got there yet, we no longer want it to be delivered. In short, UDP allows the SIP applications to control the timing and reliability, or so it gives improved performance to this kind of signalling protocol.

In addition, when SIP uses UDP, a proxy server may be stateless - a SIP request can be relayed without leaving behind state in the proxy because any response the request later generates contains (in its Via fields) all the information needed for the proxy to get these responses back to the caller's client application. This allows very large proxy servers to be built - if these servers used TCP, they would have to maintain TCP connection state for all calls, and this would make very large proxy servers a difficult proposition.

Why then support TCP at all? The primary reason is that many firewalls do not allow UDP traffic to pass whereas it is relatively simple to configure them to pass SIP traffic to an internal server which may then open a hole in the firewall for the relevant RTP traffic. Eventually though we expect firewalls to be SIP proxies, and we envisage that SIP over TCP will not be widely used.