On Wed, 2009-07-15 at 08:10 -0500, Danny Nicholas wrote: > In my shop, we got a better router to support QOS and configured our Polycom > phones to always request highest levels (UDP gets 6, everything else gets > 3). > > -----Original Message----- > From: asterisk-users-boun...@lists.digium.com > [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Jeff > LaCoursiere > Sent: Tuesday, July 14, 2009 5:04 PM > To: asterisk-users@lists.digium.com > Subject: [asterisk-users] QoS > > > Howdy, > > Getting ready to play with QoS settings. We have an asterisk 1.4.23 > server running in a colo bunker in the US Virgin Islands under a large > radio tower. That tower has multiple "sector" radio/antenna pairs that > blanket a valley in 802.11a. The customers have directed dishes aimed at > the sector antennas, mounted on their roofs. This setup has been working > great for their broadband access for many years. > > Now we want to sell voice services on top of this infrastructure, and it > works fine too, until they start some data intensive process on the > customer end, like bittorrent :) > > We would like to avoid these problems by properly setting up packet > prioritization between the customer and the sector radios, which we have > control over. > > Any links to share to get us started? Basically from zero? :) <snip> I'm entirely unfamiliar with your environment and very new to Asterisk so please take what I say with a large dose of skepticism.
We elected to move CoS right to the core switch and tried to keep it consistent throughout the path. Our environment is still pretty simple so we are using HP Procurve 2810 switches. Asterisk sits on its own VLAN. We believe we found some conflict between typical DSCP settings and Linux routers / firewalls in their default state. We initially set our systems to use Expedited Forwarding for both SIP and audio RTP. I believe this is b8 in Asterisk and 184 for our Snom phones. This sets the bits in the DSCP field as 101110. However, the default Linux packet prioritization (pfifo_fast) is looking at only the last three bits of that field (because it is not actually using DSCP but the ToS bits). It sees 110 and that middle 1 causes it to place the packets in band1 which is the default processing rather than band0 which is priority processing. We thus changed the DSCP header to 101100 (b0 in Asterisk and 176 in Snom). We believe this will cause default Linux routers / firewalls using pfifo_fast to process these packets in band0 (high priority). We then returned to our switch and told it to map DSCP header 101100 to its highest priority path. Thus, we should now have consistent CoS from the servers to the switches to the firewalls to the phones. Since our connection to Asterisk is via VPN, we also ensure the ToS bits are passed to the VPN header (be it IPSec or OpenVPN). I know that sounds dreadfully complicated but that is how we did it. If someone sees a better way or if we are unnecessarily complicating it, please let us know. If you need more information, I can probably post some of our internal documentation. Hope this helps - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsulli...@opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users