Connect802 is a nationwide wireless network equipment reseller providing system design consulting, equipment configuration, and installation services.

CSS Mega Menu



Voice-over-WLAN (VoWLAN) / Voice-over-IP (VoIP)
Bandwidth Requirements Provisioning Calculator

This VoIP calculator is provided as a reference aid for considering various wireless Voice-over-IP design alternatives. Calculate estimated MOS score and number of simultaneous active voice call connections for your wireless VoIP system.



Current Selection: G729 VoIP codec with devices connected through an 802.11b Access Point
7 maximum recommended simultaneous VoIP calls (per Access Point)
3.8 anticipated MOS (Mean Opinion Score) on each VoIP circuit
26 maximum calls are possible through a single Access Point with this configuration
3.2 MOS quality (or below) at maximum call loading.

MOS ratings are: 5=Excellent, 4=Good (analog telephone quality),
3=Fair (cell phone quality), 2=Poor, 1=Bad. Ratings below 3.0 are considered unacceptable.

SubBand Adaptive PCM (SB-ADPCM) 48 kbps 56 kbps 64 kbps
ACELP 5.3 kbps    
MP-MLQ 6.4 kbps    
Adaptive Differential PCM (ADPCM) 32 kbps    
Low-Delay Code Excited Linear Predication (LD-CELP) 16 kbps    
Conjugate Structure Algebraic-Code Excited Linear Prediction (CS-CELP) 8 kbps    
Internet Low Bitrate Coded (ILBC) 13.33 kbps 15.20 kbps  
Code Excited Linear Prediction (CLEP) 2.15 kbps 20 kbps 44.2 kbps
ACELP (includes G.722.2) 4.75 kbps 6.6 kbps 12.2 kbps
Click to set the sample period and samples per VoIP packet values to typical
defaults for your selected codec and recalculate using these typical values:
What is the sample period (in milliseconds) configured for use with the selected codec? ms

Select the options that describe your VoIP system then click: or


This is actually true even if you select the 802.3 standard for calculations (802.3 is simply provided as a general purpose reference point for comparison). By way of contrast, wireline PDH and SDH (Telco T1/E1 and SONET fiber) networks experience very little bit loss and never have packet collisions. Wired 802.3 Ethernet has almost no packet corruption and, in a switched infrastructure, almost never experiences significant numbers of collisions. 802.11 Wi-Fi, by its nature, is exposed to a potential for significant packet corruption by noise and other environmental RF influences. The definitions in the IEEE 802.11 standards change the transmission bitrate in response to both function and to signal quality aspects. The WLAN "hidden node" problem can increase collisions and packet corruption when stations that are out of each other's reception range attempt to transmit to a third station somewhere in the middle. As a result, you're going to get calculated maximum circuit values that apply to the 802.11 Wi-Fi environment and which do not 'convert' for application in a wired network system.

A codec (compressor / decompressor) is a module (software or hardware) that uses a mathematical algorithm to compress, and decompress, the bit stream that is the digital representation of the analog sound signal. The various codecs output the digitized audio at different bitrates. The digitized output of the codec is carried in an 802.11 frame containing an IP/UDP and RTP packet header. Codecs configured to operate with smaller sample times must send more IP packets than those configured to operate with large sample times. More IP packets means more overhead and a resulting overall greater bandwidth requirement (all other things being equal). On the other hand, large samples introduce the potential for call quality degradation when packets are lost (since a larger 'chunk' of the voice signal is lost when a single packet carries a long sample time).


A codec must apply its compression algorithms on a fixed block of bits. During each Sample Period this block of bits is gathered by the codec from the digitizing (quantizing) hardware. Then (during a period of processing delay) the bit block is compressed. This compression delay is in a range of roughly 10ms to as much as 45 ms. Humans begin to become annoyed when the delay reaches roughly 250 ms. Decompression, by the way, typically takes roughly 10 ms; it's easier than the compression phase. It's faster for a codec to compress a 10ms sample than it is for a 30ms sample and this fact speaks in favor of using small sample periods. On the contrary, however, smaller samples may result in increased overhead if only one compressed sample is carried in each IP/UDP/RTP data packet. If this were the case then using 10ms samples would cause three times more fixed bandwidth overhead (IP/UDP/RTP header information) than using 30ms samples.

A codec will construct a Real Time Protocol (RTP) payload consisting of one or more compressed samples. If multiple samples are carried as a single IP/UDP/RTP payload then the same packet overhead is required for 3 10ms samples as would be required for 1 30ms sample. Carrying a greater number of samples as a single RTP payload reduces overhead and results in a lower bandwidth requirement. On the contrary, however, when many samples are carried as a single RTP payload the variable IP packet delay through the IP network impacts all samples equally. Hence there is an increased chance of 'jitter" that will degrade voice quality. Moreover, the loss of a single IP packet will result in the loss of the entire multi-sample payload; again reducing call quality.

Normally VoIP data is the payload carried by Real Time Protocol (RTP). RTP is carried on top of IP and UDP resulting in 40-bytes of fixed header length that is overhead in every VoIP packet. RFC 2508 specifies methods whereby the UDP and RTP portion of the payload header can be compressed into as little as 5% of its normal length. Since the UDP/RTP header information is a fixed overhead in every VoIP packet that's transmitted the use of cRTP (compressed RTP) can significantly reduce bandwidth requirements. RFC 2508 specifies compression to 2-bytes (with no UDP checksum) and compression to 4-bytes (retaining the UDP checksum).


Digitized sound (voice and background noise), compressed through the codec, is constantly transmitted across a VoIP connection. Typical voice conversations can contain as must as 35% to 50% silence. When Voice Activity Detection is enabled for a transmitter fully digitized and compressed RTP data payloads are only sent when voice is detected. In the absence of a voice sound the RTP packet contains a 2-byte Comfort Noise payload. A Comfort Noise Generator (CNG) introduces a slight amount of background "hiss" into the receiver's phone set. The alternative would be for the receiver's phone to become completely silent during periods when the transmitter's VAD detected silence. Because this is perceived as a "dead line" by the listener the CNG creates enough low-level background noise to maintain a psychological comfort level. When used, VAD reduces the bandwidth required for the VoIP connection by as much as 35% or more.


Frame Control Field 2-bytes
Duration Field 2-bytes
Receiver Address 6-bytes
Transmitter Address 6-bytes
Service Set ID 6-bytes
Sequence Number 2-bytes
Additional Address 6-bytes
IP (and other) data variable length
Frame Checksum 4-bytes
Frame Control Field 2-bytes (Indicates that this is an ACK frame)
Duration Field 2-bytes
Receiver Address 6-bytes
Frame Checksum 4-bytes
Short PLCP Header 24-bytes
802.11 Packet Header 30-bytes
802.11 Packet Checksum 4-bytes
InterFrame Gap Time Equal to 12-bytes
ACK PLCP Header 24-bytes
ACK Packet 14-bytes



Information obtained from using this wireless VoIP Bandwidth Provisioning Calculator is believed to be accurate. Nonetheless, Connect802 makes no guarantee that the results will provide any particular level of accuracy. Results obtained from using this calculator should be considered and evaluated as part of a complete VoIP network system design and should not be relied upon as a sole source of information.