Generic VoIP QoS Priority in WISP environment

Hello all!

I work for a WISP and my goal is simple, but possibly not doable. I want to prioritize all VoIP traffic across our network regardless to the VoIP provider. Everything I have found on the net have had great solutions for specific VoIP providers by either IP, TOS packet etc, but nothing for all VoIP traffic in general. I did stumble upon this http://store.wispgear.net/p260/RouterOS-Advanced-QOS-Implementation/product_info.html?osCsid=qjg17co2pkstclscli97o5mcg5 but am reluctant to spend money on something I don’t know will work for sure. Any solutions or suggestions? Thanks in advance!

Omally01…

There is no universal way to match all VOIP traffic. VoIP can use random ports and can come from or go to any ip. The best you can get is to match most VoIP. I have personally decided to build my QOS to use the tos bit and I expect the VoIP carriers to set the TOS bit on their traffic. For business customers I am happy to install a router and change the tos bit per internal ip if they need it.

Thanks for the quick response! I was afraid that would be the case. So let’s say I do the tos packet option, would that be as simple as finding out the tos packet value for most common voip manufactures like Cisco, Polycom, etc or can tos values very from model to model from the same manufacturer? Basically I want to know just how many tos values I would have to add to the packet marking feature in routerOS. And how effective has it been for you? Thanks again for your input!

Omally01…

There is a standard meaning of each TOS (aka DSCP) number.

Here is the Wikipedia on the subject: http://en.wikipedia.org/wiki/Differentiated_services
Here is a chart: http://blog.webdir.bg/tos-to-dscp-mapping/

The DSCP byte is a binary representation of the class of the packet and the drop probability. The cool thing about using the DSCP is that it is part of the packet header so you can simply follow the DSCP that is already applied to each packet and or change the DSCP byte on traffic that has the default and should be marked up otherwise. I wouldn’t recommend, however, that you markup packets with DSCP bits that they should not have and send them out across the internet because the TOS byte will remain in the packet header until it is mangled, delivered or dropped.

In my config, I add packet marks according to the DSCP code of the packet and then queue for each separately. This means that each interface has 8 child queues for each class and up to 3 grandchild queues for the drop probability of each class.

I’d be happy to email you the documentation on what I am doing in my network and how I am calculating my limits.