[Asterisk-Dev] Re: 802.11b a contraindication?

[Rich Adamson]

> > I agree that a more specific understanding of interactions between 
> > 802.11[b,a,g] and SIP RTP sessions would be worthwhile if it could be 
> > found or generated and posted to this list.  Additionally, what would be 
> > more worthwhile would be a similar IAX2 study.   I'll put this on my 
> > long and un-cheery list of "things to be tested", right beside satellite 
> > latency effects on IAX2...
> 
> Some AP's claim they prioritize voice - I don't know how. Symbol have said
> that for a long time, and they supported H.323 in their equipment. There's
> a new QoS standard for 802.11, but I don't know how that works with various
> protocols or equipments. Check 802.11e.

There are only two common ways that network hardware supports QoS. One
method has been to watch for the specific IP ports used by sip or h323, 
looking inside those packets to watch for rtp port negotiation, and then
prioritize the traffic seen on those ports. The cisco pix firewall does
something like that with their "fixup" statements for allowing access (not
QoS).

The second common way is to watch the TOS (Type of Service) bits in the IP
header, and prioritize the traffic based on specific bit patterns. That's
one typical way to handle QoS in cisco routers as an example.

I'm with Olle in that I don't know what Symbol or others have actually
implemented, however out of the box there aren't very many network devices
that truly support QoS in any form. And, in most cases if they do support 
some form of QoS prioritization, their support is not well documented in 
their marketing/sales material or spec sheets.

QoS really does not do much good unless the majority of network devices
between the voip endpoints all support QoS. In the case of AP's, there is
already a problem with queuing prior to the voip traffic "reaching" the
AP from the wireless client (eg, queuing to grab a piece of the wireless 
bandwidth does not involve QoS).

Even if all network devices support QoS, managing the queues is still a
major operational problem. E.g., what happens when the high priority
queue is full and additional traffic arrives? How do you know when the
queue is full and how do you know when to add more bandwidth? I've been
doing professional network performance analysis for corporations in 40+
states since 1993, and I've not seen any network support organization
truly manage their bandwidth or network quality yet, let alone QoS.

If one thinks about how current wireless endpoints control the quality
of wireless transmission by varying bandwidth, and combine that with how
one manages the QoS queues, don't think there will be any real
implementations that actually work using current technology. The current
stuff does work fine with voip for low usage wireless links, but as that
traffic increases (or one/two wireless devices hog bandwidth) the voip
traffic will be impacted one way or another.

Those of us that have analyzed iax and iax2 queuing already know that
well designed jitter buffers (etc) can handle 500 millisecond latency
with hugh jitter variations and maintain quality audio. In the short
term, there is more to be gained in optimizing the jitter buffers then
there is in truly attempting to manage QoS on an end-to-end network 
basis. (Obviously there are some examples of where QoS can have a 
significant impact though, but most are temporary point solutions.)

Rich