A few months ago, my boss came back excited about some news coming out of Ohio State University — they were going to be implementing WiFi IP Phones throughout their campus. I’m sure you can guess what the next things were out of his mouth : “Lets do that!”
WiFi phones, while sounding like a great idea on paper, their implementation is a lot more tricky than one would first imagine. Everybody thinks that WiFi is one of those technologies that just ‘work’ — you just open your laptop and start your work.
Unfortunately, VoIP (Voice over IP), is extremely sensitive to any network activity or blips. A typical conversation will begin to be broken up if there is a disruption on the network for longer than 50ms. Often times when a VoIP system is deployed, the IT infrastructure needs to be conditioned for voice traffic. You need to set priorities to the different types of traffic, regulate how much bandwidth each type of traffic can have, etc. Over the past 7 years or so, this field has been growing and is finally becoming mature. VoIP works fairly well, assuming you have done the above.
When you throw VoIP onto a wireless network, you throw an entire additional host of problems into the mix. 802.11a, b, g and n networks behave very similar to token-ring based wired networks; only one device can talk at a time, and only when told it can talk. In addition, the data rates that the devices communicate at change based on the quality of the signal to the access points. Most of the technologies that exist today rely on the principal that says we can dedicate xxKb of bandwidth to application a, and let application x talk as much as it wants until it fills that pipe. With no guaranteed bandwidth transmission rate, or no guaranteed talk path, voice becomes a “best effort” to most equipment, and usually suffers. Add in a few WiFi VoIP devices and you have a true contention issue.
Avaya / Spectralink designed a box that is supposed to “schedule” the WiFi devices so they do not attempt to talk at the same time. That, combined with some of the new WiFi technologies from Meru and Aruba, will allow WiFi VoIP devices to work properly in theory. Again, sounds good on paper, but we will see in short order. At MSU, we recently setup a lab with two WiFi VoIP phones (models 3645), and the “AVPP” or Avaya Voice Priority Processor. This setup is supposed to allow the phones to work within the range of the AP. Seems to work, except, as expected, the voice is very choppy. Since we did not deploy the solution on one of the newer access points, I’ll leave my final decision until we do.