Voice bandwidth requirements depend on a number of parameters, including the sampling rate, codec, link type, header compression techniques, and the number of simultaneous voice calls. This section identifies voice bandwidth requirements for WAN links.
The most important issue is the number of simultaneous calls that are permitted across the WAN link.
The organization can limit the number of calls via call admission control; however, with a centralized call processing model, attempts that are made at calling capacity will simply busy out. This is the same behavior one would expect with a centrex solution when an outside line is not available. In addition, no exact rules exist for the percentage of lines to phones since it depends on business requirements. The organization can start by determining how many outside lines and phones the remote location currently has implemented. The organization may also be able to collect statistics on how frequently a busy-out occurred with the current solution to determine additional needs. Since you are implementing a new solution, this is a good time to investigate whether the number of lines available at the remote location is sufficient for the remote location.
Once you determine the maximum number of calls allowed across the WAN link, you can better understand the additional bandwidth requirements for that link. The next step is to understand the amount of bandwidth required for one voice call. Unfortunately, if you ask for the bandwidth requirements for a voice call, you are likely to get a variety of different answers, all of which may be correct for any given situation. It is therefore important to understand the components of a VoIP packet and the different variables that affect overall utilization. The following diagram identifies the
components in a VoIP packet. In addition to packet size, the sampling rate will affect bandwidth requirements. The configuration of VAD (voice activity detection), will also impact bandwidth
WAN Link and
Direction Minimum Delay Maximum Delay Potential Jitter
Packet Loss
Los Angeles to San Jose
8 ms. 18 ms. 10 ms. none
San Jose to Seattle 26 ms. 120 ms. 94 ms. none
Seattle to San Jose 26 ms. 102 ms. 76 ms. none
requirements. VAD reduces bandwidth requirements using the theory that in any given voice call, only one party is talking at a time. Using this theory, periods of non-activity are then not transmitted across the link. VAD is expected to save overall bandwidth by as much as 50%. Planners must be careful however because at any one time 100% of the expected bandwidth may be required for one voice stream.
Figure 3-5 VoIP Packet Components
The organization can start by understanding payload requirements. Two different encoding methods are currently available: G.711 and G.729A. In general, Cisco recommends G.711 encoding for LAN environments and G.729A across the WAN. When both are tested for voice quality, G.711 slightly edges out G.729 because of the additional payload information. The more important factor is the sampling rate, which is the period of time allocated to encoding information before the packet is transmitted. Twenty millisecond sampling rates have higher quality because less voice information is needed for a 20 ms.
time slot. Thirty millisecond sampling rates have lower voice quality than 20 ms. It is possible to configure sampling rates above 30 milliseconds; however, this is not recommended because it usually results in very poor voice quality.
Table 3-19, Part 1 shows payload requirements for G.711 and G.729A for 20ms and 30ms sampling rates. Note that the sampling rate does not significantly impact bandwidth for the payload. However, when overhead is added, there are significant increases with 50 packets per second rather than 33 packets per second. The bandwidth consumption is also required for each VoIP stream. In any conversation, two such streams are required: one in each direction.
Table 3-19, Part 1 Bandwidth Consumption for Payload Only
Table 3-19, Part 2 takes into account the additional overhead of headers including RTP headers, UDP headers, IP headers, and link headers. All of the media types below include RTP, UDP, and IP headers at 40 bytes per packet.
Table 3-19, Part 2 Bandwidth Consumption with Headers Included Codec Sampling Period1
1. The sampling period is the wait time to collect voice information before being forwarded.
Voice Payload in
2. The value is rounded to the nearest integer.
64 kbps
G.711 at 50 pps 85.6 kbps 82.4 kbps 106 kbps 81.6 kbps
You can improve bandwidth allocations using RTP header compression and VAD. RTP header compression reduces the size of the IP/UDP/RTP header from 40 bytes to 2 bytes. VAD reduces the bandwidth requirement by approximately one-half since bandwidth is only allocated to the talking party.
The values below for VAD can be misleading since the media streaming is not deterministically interrupted 50 percent of the time: VAD-controlled media streaming is a function of the measured audio levels at the sending end, which are influenced by factors including background noise. For this reason, caution should be used in reducing the bandwidth allocation.
Table 3-19, Part 3 shows bandwidth requirements for all major media types with and without RTP header compression and VAD, on a per-stream basis. Remember that any conversation has two streams, one in each direction.
Table 3-19, Part 3 Per-flow Bandwidth Consumption with Headers and Compression Techniques
G.711 at 33 pps 78.4 kbps 76.3 kbps 84.8 kbps 75.7 kbps
G.729A at 50 pps 29.6 kbps 26.4kbps 42.4 kbps 25.6 kbps
G.729A at 33 pps 22.4 kbps 20.3 kbps 28.3 kbps 19.7 kbps
Codec
Ethernet 14 Bytes of Header
PPP 6 Bytes of Header
ATM
53-byte Cells with 48-byte Payload
Frame-Relay 4 Bytes of Header
G.711 at 50 pps 85.6 kbps 82.4 kbps 106 kbps 81.6 kbps
With cRTP 70.4 kbps 67.2 kbps 84.8 kbps 66.4 kbps
With VAD 42.8 kbps 41.2 kbps 58 kbps 40.8 kbps
With cRTP & VAD 35.2 kbps 33.6 kbps 51 kbps 33.2 kbps
G.711 at 33 pps 78.4 kbps 76.3 kbps 84.8 kbps 75.7 kbps
With cRTP 67.7 kbps 64.5 kbps 84.81 kbps 65.6 kbps
With VAD 39.2 kbps 38.1 kbps 42.4 kbps 37.8 kbps
With cRTP & VAD 33.9 kbps 32.3 kbps 42.4 kbps 32.8 kbps
G.729A at 50 pps 29.6 kbps 26.4kbps 42.4 kbps 25.6 kbps
With cRTP 14.4 kbps 11.2 kbps 21.2 kbps 10.4 kbps
With VAD 14.8 kbps 13.2 kbps 21.2 kbps 12.8 kbps
With cRTP & VAD 7.2 kbps 5.6 kbps 10.7 kbps 5.2 kbps
G.729A at 33 pps 22.4 kbps 203 kbps 28.3 kbps 19.7 kbps
With cRTP 12.3 kbps 10.1 kbps 14.1 kbps 9.6 kbps
With VAD 11.2 kbps 10.1 kbps 14.2 kbps 9.9 kbps
With cRTP & VAD 6.1 kbps 5.1 kbps 7.1 kbps 4.8 kbps
Using the information above, network planners can estimate the bandwidth required for each WAN site.
Remember that WAN links are generally full-duplex so an equal amount of bandwidth should be allocated in each direction for one voice call. Be careful when estimating bandwidth using VAD because the values above do not represent the actual required bandwidth in any one direction at a particular point in time.
For example, the Acme Corporation has a remote field site that has 20 permanent employees. The site currently has three Centrex lines and users sometimes busy-out because an outside line is not available.
Network planners talked to the provider and found out that the busy-out condition was occurring roughly ten times a day. This was considered unacceptable to the office so the network planner agreed to provide bandwidth for four simultaneous voice calls. The site is currently connected via frame relay. The network planner also tested different compression techniques and decided to use G.729 encoding with cRTP and VAD over frame relay at 50 pps. Using the available information, the network planners found that each call would use approximately 10.8 kbps per stream. However, the planner was a bit
uncomfortable with only 43.2 kbps in each direction because VAD does not guarantee that bandwidth requirements will be this low in each direction at one time. The planner decided that to better guarantee voice quality, 64kbps should be allocated across frame relay. The site currently has 64 kbps CIR over frame relay so the planner intends to double CIR to 128k and configure the appropriate QOS, traffic shaping, and link fragmentation interleaving to provide acceptable voice quality.