Finding the right protocols for voice transport

When people speak of voice over IP, just concentrating on IP may tend to oversimplify the process. IP is only a part of the requisite protocol stack.

Going down the protocol stack (toward the physical layer), IP does not have a “link layer.” That is, you can’t simply transport IP packets. Instead, the IP packets have to ride inside a Layer 2 protocol, such as frame relay, PPP, or Ethernet.

Gong up the protocol stack, there’s also a need for another protocol. For typical data transmission, the dynamic duo of TCP and IP are typically paired. IP provides the connectionless addressing, and TCP provides the connection-oriented assured delivery. The good news is that TCP works extremely well for data transmission. In particular, any packets that are missing or erred are retransmitted.

For the actual stream of voice packets, it turns out that the retransmission capabilities of TCP are a liability rather than an asset. All of the packet voice-coding algorithms are designed to compensate for a fairly high percentage of lost packets without serious voice quality degradation. On the other hand, the process of detecting a lost voice packet, requesting a retransmission, and receiving the packet correctly can add significantly to delay. And delay is a significant problem for voice.

Consequently, using a SNP (Send and Pray) transmission protocol is greatly preferable for the actual voice stream. That’s where UDP comes into the picture. As noted by our colleague Gary Kessler, “Some applications, such as those that involve a simple query and response, are better suited to the datagram service of UDP because there is no time lost to virtual circuit establishment and termination. UDP’s primary function is to add a port number to the IP address to provide a socket for the application.”

No question. UDP is the right protocol for the voice stream. But what about the call control information? Should H.323 and/or SIP use TCP or UDP? We’ll tackle that in the next newsletter.