accommodate received packets being acknowledged, sent packets being kept in a retransmission buffer until the receiver acknowledges receipt, and so on. The large TCP header (20 bytes) consumes more bandwidth than the smaller UDP header (8 bytes) does. Also, voice transmission does not need the retransmission functionality of TCP once call setup is complete. Because UDP and RTP headers are smaller than TCP headers, UDP and RTP headers do not provide reliable transport. A VoIP device can have multiple active calls. The device must track which packets belong to each call. To provide the VoIP device with this needed multiplexing capability, UDP port numbers identify the call that the packet belongs to and tracks packets to specific calls. During call setup, the VoIP device negotiates UDP port numbers for each call and ensures that the port numbers are unique for all currently active calls. The UDP port numbers that are used for RTP are in the range of 16,384 to 32,767.
Content 2.3 Encapsulating Voice Packets for Transport 2.3.4 Voice Encapsulation Codecs VoIP devices encapsulate voice into RTP and UDP before adding the IP header. The size of the whole VoIP packet depends on the codec that is used and the amount of voice that is packetized. The length of the samples can vary, but for voice, samples representing 20 ms are the maximum duration for the payload. The selection of this payload duration is a compromise between bandwidth requirements and quality. Smaller payloads demand proportionately higher bandwidth per channel band because the header length remains at 40 octets. However, if payloads increase, the overall delay in the system increases, and the system is more susceptible to the loss of individual packets by the network. Figure shows voice samples encapsulated in IP packets with UDP and RTP support. Each sample uses a different codec, and is based on a default of 20 ms of voice per packet. When analog signals are digitized using the G.711 codec, 20 ms of voice consists of 160 samples, with each sample measuring 8 bits. The result is 160 bytes of voice information. These G.711 samples (160 bytes) are encapsulated into an RTP header (12 bytes), a UDP header (8 bytes), and an IP header (20 bytes). Therefore, the whole IP packet carrying UDP, RTP, and the voice payload using G.711 has a size of 200 bytes. In contrast, 20 ms of voice encoded with the G.729 codec consists of 160 samples, where groups of 10 samples are represented by a 10-bit code word. The result is 160 bits (20 bytes) of voice information. These G.729 code words (20 bytes in size) are encapsulated into an RTP header (12 bytes), a UDP header (8 bytes), and an IP header (20 bytes). Therefore, the whole IP packet carrying UDP, RTP, and the voice payload using G.729 has a size of 60 bytes.
Content 2.3 Encapsulating Voice Packets for Transport 2.3.5 Reducing Header Overhead with cRTP The combined overhead of IP, UDP, and RTP headers is enormously high, especially because voice travels in relatively small packets and at high packet rates. Figure shows the voice packet structure using G.729 and G.711. When G.729 is used, the headers are twice the size of the voice payload. The pure voice bandwidth of the G.729 codec (8 kbps) is tripled for the whole IP packet. This total, however, is still not the final bandwidth requirement because Layer 2 overhead must also be included. Without the Layer 2 overhead, a G.729 call requires 24 kbps. When G.711 is used, the ratio of header to payload is smaller because of the larger voice payload. Headers of 40 bytes are added to 160 bytes of payload, so one-quarter of the G.711 codec bandwidth (64 kbps) must be added. Without Layer 2 overhead, a G.711 call requires 80 kbps. Figure shows how RTP header compression (cRTP) reduces the huge bandwidth overhead that is caused by the IP, UDP, and RTP headers. The name of this process can be misleading because cRTP not only compresses the RTP header, but it also compresses the IP and UDP headers. cRTP is configured on a link-by-link basis. It is possible to use cRTP on just some links within your IP network. When cRTP is configured (whether on all or some links in the path), a router that receives cRTP packets on one interface and routes the packets out another interface (that is also configured for cRTP) has to decompress the packet at the first interface and then compress the packet again at the second interface. cRTP compresses the IP, UDP, and RTP headers from 40 bytes to 2 bytes if the UDP checksum is not conserved (this is the default setting on Cisco devices) and to 4 bytes if the UDP checksum is also transmitted. cRTP is especially beneficial when the RTP payload size is small; for example, with compressed audio payloads between 20 and 50 bytes. cRTP works on the premise that most of the fields in the IP, UDP, and RTP headers do not change or that the change is predictable. Static fields in the headers include source and destination IP address, source and destination UDP port numbers, and many other fields in all three headers. The RTP Header Compression Process table shows the cRTP process for the fields where the change occurs. RTP Header Compression Process Condition Action The change is predictable. The sending side tracks the predicted change. The predicted change is tracked. The sending side sends a hash of the header. The receiving side predicts what the constant change is. The receiving side substitutes the original stored header and calculates the changed fields. There is an unexpected change. The sending side sends the entire header without compression. These examples illustrate the impact of header compression under various conditions. Example: cRTP with G.729, without UDP Checksum
When RTP is used for G.729 voice streams without preserving the UDP checksum, 20 bytes of voice are encapsulated into 2 bytes of cRTP. In this case, the overhead is 10 percent; uncompressed encapsulation adds 200 percent of overhead. Example: cRTP with G.711, with UDP Checksum
When cRTP is used for G.711 voice streams preserving the UDP checksum, 160 bytes of voice are encapsulated into 4 bytes of cRTP. The overhead in this case is 2.5 percent; uncompressed encapsulation adds 25 percent of overhead.
Content 2.3 Encapsulating Voice Packets for Transport 2.3.6 When to Use RTP Header Compression cRTP reduces overhead for multimedia RTP traffic. The reduction in overhead for multimedia RTP traffic results in a corresponding reduction in delay; cRTP is especially beneficial when the RTP payload size is small, such as audio payloads. Use RTP header compression on any WAN interface where you are concerned about bandwidth and where there is a high proportion of RTP traffic.Despite the advantages, there are some disadvantages to consider before enabling cRTP. Consider the following factors before enabling cRTP: These points are summarized in Figure .
Content 2.4 Calculating Bandwidth Requirements for VoIP 2.4.1 Impact of Voice Samples and Packet Size on Bandwidth When a VoIP device sends voice over packet networks, the device encapsulates digitized voice information into IP packets. This encapsulation overhead requires extra bandwidth as determined