> > 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 _______________________________________________ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
