SIP via UDP vs. TCP

SIP via UDP vs. TCP

One of the things I enjoy doing is taking complex subjects and explaining them in such a way that nearly any interested party can understand. I spent nearly an hour last night explaining the Big Bang theory to my 12 year-old son. I think, eventually, we got there. The task before me today is to explain why SIP, the protocol of VoIP, is best left as a UDP service as opposed to a TCP service. This is nearly as formidable as explaining the Big Bang to a sixth grader.

First, we need to build some vocabulary. TCP and UDP are connection protocols in use today for data traversing the Internet. Data travels across the Internet in packets. Think of them like letters. Like letters, they have an envelope with a to/from address on them. TCP and UDP are just two types of envelopes. The IP addresses are the to/from addresses. They both carry data and both use IP addresses, but just the outside envelope is different. Think US mail vs. FedEx. The address on the envelope is the IP address for where the packet came from (source address) and where it's going (destination address). TCP is so prevalent on the Internet that it's typically combined with IP, and written as TCP/IP.

TCP would be the 'FedEX' part of the analogy from above. Whenever two servers 'speak' TCP, they set up a formal connection. Every time a packet is sent from one side, the other side sends a packet back acknowledging the packet's arrival. If no acknowledgment packet arrives after a certain amount of time, or if the acknowledgment states that there was a problem, then the packet is re-sent. It can sometimes take a few seconds for a packet to be fully successfully transmitted. TCP is optimized for accurate delivery, not timeliness, and is the protocol for WWW sites and e-mail among others.

UDP is the opposite. It is a protocol optimized for getting packets there in a timely fashion with little overhead, but with just as little accountability. It's more like throwing a bottle in the ocean. Ok, a very rapidly moving ocean, but you get the point. With UDP, you just address the envelope and drop it on the network. There's no handshake, and no setup. Just the data packets. UDP is meant for real-time conversations where you are more interested in keeping the stream going then making sure that you have every single packet.

Right this very moment, Junction Networks has over 3,500 devices attempting to connect with Junction Networks. These devices are everything from individual SIP phones, to SIP devices, to other PBXs. Most of the connection attempts are simple SIP registrations. A SIP registration is when a SIP device tells the server, in this case Junction Networks, that it's available for calls and what its IP address is. This communication happens anywhere from every minute to every hour, for EVERY device. That's a LOT of packets. If these were TCP packets, each time a phone wanted to tell us that it's available, it would have to go through the whole TCP connection setup. That would be a HUGE amount of overhead for a VoIP carrier. In a LAN environment, it would be manageable, but for thousands of individual devices and hundreds of them attempting to register EVERY SECOND, a TCP connection would grind servers to a halt.

Next, once the phones are registered and a call is set up, it's really UDP's time to shine. A phone conversation is a stream of packets meant to be created, sent and received in real time. A lag, any lag, would mean a degradation in the quality of the phone call. Imagine hearing something on the call one to two seconds after the person on the other end says it. You're replying to what they're saying, but they've already moved on. It would be totally disconcerting. And, since it's real-time, there's no catching up. Better to drop a packet and have a millisecond of silence than seconds of lag.

In short, VoIP traffic is best left as UDP traffic for both server load and call quality reasons.

This post gives me the background I need to answer why BitTorrent will NOT bring down the Internet and VoIP if/when they switch to UDP, contrary to
this article. Taking on explaining BitTorrent is going to be much harder than the Big Bang.

Misleading article

Posted by: Guest
Sat, 12/31/11 9:14 pm EST

Nice article, but very misleading...


1. A server should easily be able to manage 3,500 devices attempting a tcp connection. SIP is a very light weight protocol, once the connections is established it's effectively left idle until the infrequent event of someone making a phone call.


TCP (unlike UDP) will actually reduce traffic to the server by eliminating need to;

a. re-register every few minutes

b. refresh/ping server


2. "Next, once the phones are registered and a call is set up, it's really UDP's time to shine."


This is irrelevant to the topic of SIP. You can run SIP over TCP and then use (as is recommended) UDP for RTP.


Re: Misleading

Posted by: mike
Tue, 1/03/12 5:12 pm EST

First, thanks for reading.


Yes, I agree that a server should be able to manage 3,500 devices (in 2008 that seemed like a big number), but the question is what is the maximum number of devices a server can support under the competing protocols? If 10,000 is a good round number for devices connecting via UDP then I would suggest that the same server could not handle 10,000 devices registering, making calls, transferring calls, putting calls on hold, sending SIP Options packets as keep alive packets, etc. via TCP over IP.


All of that being said, we are looking to expand to supporting TCP. We have seen the once lightweight SIP User Agents expand to cover multiple codecs, multimedia, video and screen-sharing. The INVITE packets are growing ever larger and are starting to run over the UDP single datagram size thereby forcing our hand.


Nice post

Posted by: Vladimir
Thu, 1/19/12 9:24 am EST

Very good article explaining what's the deal with SIP TCP. I see this SIP TCP feature offered a lot lately, usually in premium packages. So basically it should give us higher call quality but will require state of the art infrastructure (and lots of overhead)? Why would anyone want to use SIP over TCP?


Is TCP a solution for remote Call Center?

Posted by: Dario
Thu, 1/26/12 10:25 pm EST

Hi,

Is a very interesting post. Just when I'm fighting with a large VoIP deployment (2000 concurrent agents)... We have a few sites with a poor WAN connection. The wideband is fine, the packet error is very low (under 2%), but we facing micro disconnections between the endpoint (we are using Eyebeam) and SIP-Server. This issue make us drop many calls at the day. So, my question. The TCP connection instead UDP can improve the connectivity?


Re: TCP for a call center

Posted by: mike
Wed, 2/01/12 3:22 pm EST

With SIP, call control (call setup and call tear-down) is separated from the call media (the audio). In the middle of a phone call I can disconnect my Polycom phone from the ethernet jack in the wall, count to 10 and plug it back it and the call continues as normal. Yes, the audio "drops" during that time, but not the call. The call is still up and only ends when one end sends a very specific "BYE" message.


With real-time audio re-transmitting a dropped packet doesn't help call quality because the conversation itself has moved on. The only thing a re-trans would do is stick a packet into the audio stream out of order which will actually degrade the call quality even further. The best thing for a real-time media experience is to just drop the packet if it's out of order or missing and move on.