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 \u201clink layer.\u201d That is, you can\u2019t 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\u2019s 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\u2019s where UDP comes into the picture. As noted by our colleague Gary Kessler, \u201cSome 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.\u201dNo 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\u2019ll tackle that in the next newsletter.