Adding peer-to-peer communications to an application is relatively straight-forward. Developers can leverage WebRTC APIs or a CPaaS service to quickly add real time voice and video to their web or mobile app. But, what if you want to hold a meeting with more than two people? How can you leverage powerful WebRTC APIs to build a multi party conferencing application?
Application developers make a lot of choices when designing a SIP-based communications service. Many are straight-forward. However, choosing between transport protocols isn’t as easy. The SIP protocol supports transport over TCP and UDP with each having its advantages and disadvantages. In addition, security considerations may drive you to consider the TLS protocol.
We have designed this guide to help you understand the tradeoffs between alternative transport protocols and make the best decision for your communications service. You’ll learn the differences between TCP, UDP, and TLS, and gain practical tips for choosing between them.
Transport Protocols Explained
Transport protocols enable your application messages to find their way from a source to a destination address on the Internet. They sit in the middle of the ISO model with applications above and the best effort IP protocol below. Transport protocols encapsulate/decapsulate the messages created by applications, such as SIP, and hand them off to the IP layer for transmission across a particular network media (Wi-Fi, Ethernet, etc.).
Transport protocols provide essential services to the application, including:
- Multiplexing - Assigning port numbers to each application, which enables the IP network to carry thousands of application messages between hosts simultaneously
- Reliable message delivery - The receiver verifies the transmission of each packet using a checksum to ensure contents are not corrupted. The receiver acknowledges the verified packet or requests retransmission of the corrupted packet. If the transmitter doesn’t receive an acknowledgement, it assumes the packet is lost and retransmits it. The transport layer also ensures packets arrive in sequence by inserting a sequence number.
- Flow control - The receiver uses a transmission window value to provide feedback to the sender about buffer space to avoid buffer overruns and underruns.
- Congestion management - When multiple losses occur, the transport layer implements a back-off algorithm that allows congestion to clear before resuming transmission.
The OSI’s definition of the transport layer is very robust. IETF architects recognized that such a robust protocol can introduce a lot of overhead on communicating hosts, and not every application requires the services of a fully featured transport protocol. This is why they built multiple alternative transport protocol specifications.
VoIP media needs speed, not reliability
Real- time communications is an example of an application that doesn’t always need the services of a fully featured transport protocol. In particular, the reliability features are superfluous to voice and video communications applications because the extra time to recover lost media packets detracts from the quality of the user’s experience. It’s more important that packets carrying media arrive quickly than error-free. If a packet is lost, arrives out of order, or is corrupted, the receiver simply discards it and plays the next available packet. Because each packet carries a tiny amount of audio - usually about 20 ms, the user may not even detect the lost packet.
In contrast, file transfers, database transactions, and many other applications have the exact opposite requirements; it’s more important that packets arrive error-free than quickly.
It’s important to note that communications signaling messages have different latency requirements than media packets. This means SIP signaling can sometimes benefit from a fully featured transport protocol. We’ll discuss this further, below.
VoIP transport options
The IETF have specified a small suite of transport protocols to address the varying needs of applications.
The TCP Protocol Delivers Reliable Messages
The IETF Transport Control Protocol provides a reliable message delivery service across unreliable, best-effort IP networks by implementing the features described earlier. It is a stateful, connection-oriented protocol because connections are set-up and torn-down using a 3-way handshake. The handshake is composed of three messages that enable the endpoints to negotiate the connection properties, including port addresses.
TCP has the capability to move large data blocks by fragmenting them into packets small enough not to exceed the maximum transmission unit (MTU) size of the underlying network.
The UDP Protocol Transports Datagrams
The IETF User Datagram Protocol provides a connectionless best-effort message delivery service across IP networks. You can think of it as a stripped-down transport designed to multiplex applications and rapidly move packets between hosts. It provides no delivery guarantees, no flow control, no means to reorder packets or detect corrupt data. It also has no ability to transport messages that exceed the MTU size.
What UDP provides is speed and efficiency, which is ideal for transporting voice and video media packets.
The TLS Protocol Delivers Secure Messages
The IETF Transport Layer Security Protocol provides a reliable, secure message delivery service across IP networks. It is layered on top of TCP and carries all its robust features, plus message integrity and privacy. It includes features for authenticating endpoints and you can choose from a range of strong ciphers.
What is the Best Transport for SIP?
SIP can be carried over any of the three transport protocols we’ve discussed. To ensure interoperability in open network environments, the SIP specification requires implementations to support both TCP and UDP. But private communications services have a choice. If you are a communications architect, carefully consider the cases and conditions under which users will engage your service.
Trusted vs. untrusted networks
The first and simplest use case is untrusted networks. If your users will transit untrusted networks, you really have no choice but to use TLS security to protect signaling and SRTP to protect media. Contemporary client devices have the horsepower to handle the additional overhead imposed by ciphers without degrading the quality of service.
Firewall and NAT traversal
Will your service span any firewalls or NAT devices? This is an important consideration because these devices are quick to close UDP ports. SIP infrastructure knows this and will send frequent keep-alive messages throughout a session to keep the port it is using open. Generally, this isn’t a problem unless your users are on mobile devices, which can see their batteries drain more rapidly. If mobile is important, the better alternative is to use TCP because NAT devices can’t shut the port until the connection is torn-down.
Note, web-oriented communications alternatives to SIP are not as susceptible to firewall and NAT interference. WebRTC or a native web communications SDK use different methods than SIP to traverse NAT devices without keep-alive messages. They also fall back to web ports when UDP is blocked.
Will you be supporting complex heterogeneous sessions? This is important because UDP supports a 1,500-byte maximum MTU size which could be exhausted by complex setup messages. When considering message size, remember SDP options contribute to the size of SIP INVITE requests. Factors that drive message size include negotiation among multiple codecs. If you are expecting large SIP messages, choose TCP for its ability to fragment and reassemble them.
Will clients frequently move between networks? If clients need to frequently register with SIP servers, the overhead with TCP could limit the capacity of your registration server. UDP can lighten the load on the server.
Finally, consider that UDP is faster and more efficient than TCP. By eliminating the latency of the three-way handshake, you can reduce call setup times.
Summary Pros/Cons for TCP and UDP
As Moore’s Law continues to increase the processing power available on endpoint devices and network speeds continue to increase, the overhead associated with using connection-oriented protocols is diminishing. The industry seems to recognize this and is shifting to SIP over TCP for its greater flexibility and reliability. Among enterprise UC as a service platforms, Microsoft Teams (formerly Skype for Business) has always used SIP over TCP and Ringcentral began shifting to TCP about two years ago. In the enterprise telephony equipment industry, Cisco has offered TCP on its flagship Unified Communications Manager product.
Make An Informed Choice
Knowing the trade-offs between the available SIP transport protocols should make your decision a little easier. There are always many “unknowns” associated with running any network service. You can’t account for every use case. But, armed with the information in this guide, you can make an informed choice for your network.
Voximplant Supports SIP Over Any Transport Protocol
The Voximplant platform offers developers flexibility to use SIP over UDP, TCP, and TLS. Alternatively, our WebRTC interface and SDK enable communications using web methods. You can learn how to use these services by referencing our documentation or contact us for more information.