QueTwo's Blog

thouoghts on telecommunications, programming, education and technology

Wireless IP Phones

4 Comments Posted by on December 28, 2007

,,,

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.

About these ads
Avaya, Telecom

4 Responses to Wireless IP Phones

  1. Andrew Jones July 21, 2008 at 11:09 pm

    Did you move forward with wireless VOIP phones?

    We’re looking at deploying 3641/3645 phones. Our sysadmin is convinced we don’t need the AVPP, though Avaya says it’s required (one model, 3631 does not require it per the specs).

    I tend to suspect that we might be able to make things work without the AVPP, but Avaya likely won’t support the equipment unless it’s installed to their specifications. And there’s nothing stopping them from designing the phones in a proprietary-enough fashion that they simply won’t function without the AVPP present.

    Our WLAN equipment and switches can handle QOS, both in terms of prioritizing and tagging, and the Meru equipment we’re looking at it supposedly very good at “time-slicing” to work around the “token-ring” issue you mentioned…your experience is quite discouraging but it’s been almost a year since; maybe things have improved.

    Reply
  2. quetwo July 22, 2008 at 12:13 am

    We are still in the planning phases… We deployed them in our lab, and they worked great. We did a field trial, and by far, our users liked the 3645 MUCH better than the 3641.

    I’ve tried lots of SIP based wireless devices and they all have one flaw — even though QoS is deployed, they really stop working when you have too many of them (> 4 in our tests) on one access point. The problem with WiFi is it behaves very much like Token Ring — only one device can talk at a time. This is OK for data packets, but for VoIP it really starts to break down when you get lots of devices. The AVPP really helped this, simply by making the devices actually stop trying to talk until it was their turn.

    Unfortunately, we haven’t deployed the WiFi solution across our campus yet. The biggest problem is that you are required to have 1 AVPP per subnet. We have hundreds of wireless subnets on our campus, and sometimes many per building. Also, our WiFi network wasn’t designed with Multicast in mind (so that will need to change too). We are on our beginning phase in rolling out some new Meru gear, and will be rearchitecting the wireless network at the same time. At that time, we can probably roll out larger than the few building we have today.

    Otherwise, the 3645 is an awesome product. Only wish for it would be that it would behave like a softphone instead of a dedicated stations — dedicated stations makes it expensive to deploy!

    Reply
  3. Josh June 17, 2009 at 8:54 pm

    Hey, so looks like this is almost a year old, but just wondering if you ever finalized this project?

    I’m looking at adding a handful of wireless phones to my wireless network here.

    Current config supports WMM but I’m not sure if i need the AVPP or not.

    Reply
    • quetwo July 7, 2009 at 12:07 pm

      @Josh:
      We ended up abandoning our work with the Avaya AVPP based products. While they worked VERY well in our testing lab, one thing we overlooked is how the devices expect to communicate with eachother, and the master servers. Avaya expects that each AVPP based phone sits on the same broadcast domain (subnet) as the AVPP server — in addition the AVPP needs to be in the same multicast domain as all the other AVPP servers, and the PBX. Any way we sliced it, this wouldn’t work for us, as in most cases we have more than 255 WiFi clients in a building, and often have split up our design so that we have about 3 – 4 subnets per building. That, coupled with the want/need to be within 120 buildings on our campus made the design way too complicated. We weren’t out to buy that many servers to fill this niche.

      What we have been doing is looking at hibrid WiFi/Cell phones that work with the One-X Mobile software. While the software is still on its way, we are hoping that this setup will make the portable / wifi phone much more useable, as they would continue to get coverage outside our buildings.

      I really wished this product would have worked. I loved the phones, and they seemed to work really solid — but their dependance on the AVPP Servers just made them out to be a deal-breaker.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out / Change )

Twitter picture

You are commenting using your Twitter account. ( Log Out / Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out / Change )

Cancel

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: