Configuration Issues for VoIP on Wi-Fi

By William Flanagan

The designs of VoIP and wireless LANs originated separately and at first didn't consider each other as part of a total network.

• 802.11b, first to deploy, was kept simple by focusing on data applications.
• VoIP protocols ignored the possibility of a radio link (not to mention Network Address Translation).

VoIP and Wi-Fi kept bumping into each other in the wiring closet and data center until each technology had to acknowledge the other. The result was enhanced protocols and added features:

• VoIP: encryption in IP phones countered the weakness of the WEP, first air-side algorithm for Wi-Fi.
• Wi-Fi: not only improved encryption (WPA2 uses AES), vLANs, and authentication, but also added capabilities (with 802.11e) to assign priority to voice packets.

Now vendors offer VoIP mobile handsets with Wi-Fi radios (some with cellular too, but that's for another issue). Wireless Access Points can give priority to the phones, ahead of the PC's data--if you configure them all properly. In addition to any cellular service setup, there's the Wi-Fi configuration. Just for starters:

• Service Set Identifier (Extended SSID when configured on an Access Point); some APs support multiple SSIDs
• virtual LAN ID (in the 802.11Q header)
• Priority class assignments in both IP stack and Wi-Fi
• Encryption protocol and algorithm
• RF channel assignments
• Authentication method (registering the MAC address of a device, requiring a name/password log in to get on the network, knowing the SSID, etc.)
• Voice encoding algorithm, most often G.711 (PCM) or G.729 (ACELP)

That last item, the choice of codec, can generate a lot of discussion related to bandwidth usage and the number of simultaneous voice channels a link can carry. G.711 encodes at 64,000 bit/s while G.729 compresses the digital stream to 8,000 bit/s. On a satellite link, when using header compression to replace the RTP/UDP/IP headers with four bytes or less, the difference can be significant. In the local area, without header compression, the situation is not as clear.

Voice is not only real-time, it is constant, equal in both directions, and demands low latency from the network. To minimize delay at the source, an IP phone seldom accumulates more than 10 ms of sound before sending the digital information in a new packet.

G.711 generates 640 bits or 80 bytes in 10 ms, where G.729 outputs 10 bytes. The catch is that either payload requires the same set of headers, which take 74 bytes for the LAN headers. Encryption adds another header.

On modern wired LANs, voice usually represents a small fraction of total traffic. If prioritized ahead of data (with absolute priority) voice packets "see" a lightly loaded network, encounter minimum delay, and have no packets dropped due to congestion. Granting top priority to voice under these conditions can't block or starve data traffic because each voice channel has only a fixed and relatively low throughput. An IP phone doesn't burst to high volume the way a file transfer can.

Wi-Fi adds overhead in the form of time delays to allocate air time to different stations and a necessary wait time between packets on the radio. With the headers and overhead dominating the air interface, it's often the large number of small packets that limits the number of voice channels on an AP and not the encoded bandwidth of the voice payloads.

In their book Wi-Fi Telephony (Newnes/Elsevier, 2007) Chandra and Lide calculate the number of telephone connections one 802.11b access point can support without recent improvements in a/g/n Wi-Fi versions or 802.11 enhancements. Even at the shortest range (highest data rate) only 12 calls fit on the 11 Mbit/s channel. The interesting point is that the difference between G.711 and G.729 is just one connection--10 vs. 11 for one set of conditions--confirming that codec selection has little impact on capacity.

You mileage probably varies. Particularly if you have deployed the later releases of the Wi-Fi standards and radios, you should be able to support more simultaneous calls per AP. What do you see in your environment? Let us know and we'll share the aggregate info (or not yours, if you prefer). Email publisher@viewsletter.com.