You need both reliability and performance in your VoIP (Voice over Internet Protocol) software to get the best out of it. Traditionally, performance has been emphasised in telephony software such as Asterisk and Asterisk-based call center software with reliability coming from the infrastructure you set up around it. Network and hardware performance are key components of a reliable voice connection. For this reason, call signalling in VoIP has been done via UDP (User Datagram Protocol) most of the time.
Just to give a quick overview, there are two primary methods of sending data over IP (Internet Protocol): TCP (Transmission Control Protocol) and UDP. Most familiar applications, such as the World Wide Web, use TCP. TCP guarantees the delivery of packets, and that they will arrive in order. It also allows larger packets to be split and sent separately. To do this, it must add additional data to each packet to keep track of all that. UDP does not guarantee arrival, packets may arrive out of order, and packets may not arrive at all.
In that case, why on Earth would anyone use UDP at all? Efficiency is the key. UDP doesn’t have as much overhead as TCP, and if a packet gets lost, you don’t have to wait for it to be resent before handling the next one. This makes it ideal for applications where immediacy is needed. For instance, in a voice call, it’s often better to have a packet drop and lose a fraction of a second of audio, than create an even longer delay while the packet is reassembled. Sometimes you prefer a bit of scrambled audio for a second or two to having long, awkward pauses.
This is why UDP has been king of VoIP until recently. However, use cases are becoming more common where UDP is becoming a hindrance, and the reliability of TCP is preferred. Some of the advantages TCP can bring are:
- Reliability of connection – With VoIP in use by call centers across the globe, we can’t guarantee the state of the connection from point A to point B at all times. Mobile apps have to deal with the same issue. When voice traffic is being sent, dropping packets may be Ok. When you’re talking about the signalling itself such as SIP (Session Initiation Protocol), the part that deals with the call itself rather than the actual voice traffic, having a couple of packets drop can mean losing the call.
- May Reduce traffic in idle states – because the connection is maintained by the TCP protocol, we don’t have to send keepalive and other packets so often. Under other circumstances, however, we may see additional packets being sent.
- Handles larger control packets better – in some cases SIP packets can become quite large. UDP packets have a maximum size, but TCP can handle the larger packets by splitting them.
- Better handling of NAT – this is related to the reduction of traffic in idle states, but many NAT (Network Address Translation) implementations handle TCP better than UDP.
For these reasons, and others, many applications have started implementing SIP with TCP as an option, or as the only option. This gives the benefit of TCP reliability to the call control side, while allowing the efficiency of UDP to be used with the actual call audio (or other media). Because of the need to connect under many situations, Asterisk allows you to specify TCP as the method of connection for SIP connections. This gives you the ability to deploy Asterisk under whichever conditions you may find yourself.