Voice Bandwidth Considerations
Voice calls create a flow with a fixed data rate, with equally spaced packets. Voice flows can be described as isochronous, which, according to Dictionary.com, means "characterized by or occurring at equal intervals of time." Consider Figure 1-19, where a call has been placed between analog phones at extensions 201 and 301.
Figure 1-19 Isochronous Packet Flow for Voice Call
Server 1
Figure 1-19 Isochronous Packet Flow for Voice Call
Server 1
R1 creates the IP/UDP/RTP voice payload packets and sends them, by default, every 20 ms. Because Cisco IOS Software places 20 ms of encoded voice into each packet, a packet must be sent every 20 ms. So, how much bandwidth is really needed for the voice payload call? Well, actual bandwidth depends on several factors:
• Packet overhead (IP/UDP/RTP)
• Data-link framing (depends on data links used)
• Compression
Most people quote a G.711 call as taking 64 kbps, and a G.729 call as taking 8 kbps. Those bandwidth numbers consider the payload only—ignoring data-link, IP, UDP, and RTP headers. Consider Table 1-14, with actual bandwidth requirements for various types of voice calls.
Table 1-14 Bandwidth Requirements with Various Data-Link Types
|
L2 Header Type |
Header Size |
IP/UDP/RTP Header Size |
Codec |
Bandwidth |
||
|
Ethernet |
14 |
40 bytes |
G.711 |
64 kbps |
85.6 |
|
|
MLPPP/FR |
6 |
40 bytes |
G.711 |
64 kbps |
S2.4 |
|
|
Ethernet |
14 |
40 bytes |
G.729 |
S kbps |
29.6 |
|
|
MLPPP/FR |
6 |
40 bytes |
G.729 |
S kbps |
26.4 |
|
For DQOS test takers: These numbers are extracted from the DQOS course.
For DQOS test takers: These numbers are extracted from the DQOS course.
The bandwidth requirements vary dramatically based on the codec and the compression effect if RTP header compression is used. Compressed RTP (cRTP) actually compresses the IP/UDP/ RTP headers, with dramatic reduction in bandwidth when used with lower bit-rate codecs. With G.711, because a large percentage of the bandwidth carries the payload, cRTP helps, but the percentage decrease in bandwidth is not as dramatic. In either case, cRTP can increase delay caused while the processor compresses and decompresses the headers.
NOTE Although other codecs are available, this book compares G.711 and G.729 in most examples, noting any conditions where a different specific codec may need different treatment with QoS.
ATM can add a significant amount of data-link overhead to voice packets. Each ATM cell has 5 bytes of overhead; in addition, the last cell holding parts of the voice packet may have a lot of wasted space. For instance, a voice call using G.729 will have a packet size of 60 bytes. ATM adds about 8 bytes of framing overhead, and then segments the 68-byte frame into two cells— one using the full 48 bytes of ATM cell payload, and the other only using 20 bytes of the cell payload area—with 28 bytes "wasted." Therefore, to send one voice "packet" of 60 bytes, two cells, in total 106 bytes, must be sent over ATM. One option to lessen the overhead is to change the payload size to contain 30 ms of voice with a G.729 codec—which interestingly also only takes two ATM cells.
Voice Activity Detection (VAD) also affects the actual bandwidth used for a voice payload call. VAD causes the sender of the voice packets to not send packets when the speaker is silent. Because human speech is typically interactive (I know there are some exceptions to that rule that come to mind right now!), VAD can decrease the actual bandwidth by about 60 percent. The actual amount of bandwidth savings for each call cannot be predicted—simple things such as calling from a noisy environment defeats VAD. Also VAD can be irritating to listeners. After a period of not speaking, the speaker starts to talk. The VAD logic may perform front-end speech clipping, which means that the first few milliseconds of voice are not sent.
Note that the numbers shown in the previous table, Table 1-14, come directly from the DQOS course (and several other sources inside Cisco). Interestingly, the numbers ignore data-link trailer overhead, and ignore ATM and 802.1Q framing. One of the technical editors of this book graciously provided an alternative, more accurate table that you should consider using for planning in production networks. For the exam, trust the numbers in Table 1-14. Table 1-15 lists the updated numbers.
|
Bandwidth Consumption, Including L2 Overhead |
802.1Q Ethernet (32 Bytes of L2 Overhead) |
PPP (9 Bytes of L2 Overhead) |
MLP (13 Bytes of L2 Overhead) |
Frame-Relay (8 Bytes of L2 Overhead) |
ATM (Variable Bytes of L2 Overhead, Depending on Cell-Padding Requirements) |
|
G.711 at 50 pps* |
93 kbps |
84 kbps |
86 kbps |
84 kbps |
106 kbps |
|
G.711 at 33 pps |
83 kbps |
77 kbps |
78 kbps |
77 kbps |
84 kbps |
|
G.729A at 50 pps |
37 kbps |
28 kbps |
30 kbps |
28 kbps |
43 kbps |
|
G.729A at 33 pps |
27 kbps |
21 kbps |
22 kbps |
21 kbps |
28 kbps |
* pps = packets per second
* pps = packets per second
Continue reading here: Considering the Effects of Packetization and Codec Delay
Was this article helpful?