This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

QoS + VOIP, SIP client phones to Internet server

So I've read and read, and read some more all sorts of different posts and none of them are real clear.  QoS on the UTM seems to be all about throttling and limiting.  Is there a way just to use QoS prioritization like cheap routers/firewalls will and all the other commercial ones will?

I have 4 Cisco SPA525G VOIP phones using SIP + RTP to communicate to my cloud hosted "pbx".  If we're not using the internet everything works well.  However, if I decide to upload a file to dropbox or exchange or whatever, the phones degrade horribly, downloading seems to not affect it as much.  I have an 18Mbit down, 1.5Mbit up connection.  According to my VOIP provider, "marking OSI Layer 2 packets with high-priority (5) class tags (802.1p and IP Precedence)", and they tag all of their voice packets with DSCP value of 46. 

So what settings are required to give these packets absolutely priority over everything else.  I shouldn't have to set guaranteed bandwidth with priority being given to them.  If priority is utilized it should just put them to the front of the line no matter if I have 1 phone in use or all 4 of them.

EDIT: SG135W running 9.412-2 if that matters.

Thanks!



This thread was automatically locked due to age.
  • Ok, I haven't tried it but on the UTM under traffic selectors there is the ability to select DSCP types. Now bear in mind, that those types will most likely be tagged by other devices ie your ip phone etc.

    If you set say 2 different DSCP types in the UTM and bind them to an interface and give that interface the full bandwidth amount, what will the UTM do with the traffic? My guess is it will prioritise between those two types of traffic. The question would be.... what does it do with the remainder of the other traffic?
    You would generally say the rest goes into a fair queue eg it's best effort but that has to be specified even on a Cisco.

  • Well I think that is a little closer, but I believe if I make that selector (which I currently have DSCP value 46 setup in my firewall as it seems to be the only way to make it work) and then bind it to my interface with a guaranteed bandwidth of the whole pipe, as soon as 1 phone call gets setup, the whole uplink gets dedicated to that 1 call.  I currently have mine setup to 400 k/bit and seems to stop the VOIP stuttering while uploading.  The problem comes in that if I only have 1 call (most of the time in my office) then I'm wasting a good bit of my uplink to unused guaranteed bandwidth.  If I'm to use guaranteed BW, I need a way to dynamically allocate more and more based on the needs of the phone system in order to keep everything else chugging along as fast as possible.  Especially if I add more phones in my office. 

    Which leads me to the request for a priority queue.  It is almost like I just need the Traffic Selectors tab to be able to be turned into the priority, based on the order of the list.  I don't have that XG appliance that was recommended, so it would be interesting to see that setup.

  • I'm not 100% sure how the QoS works on the UTM. Perhaps each source gets a guaranteed bandwidth? eg 1 call would get 40kb, 2 calls would get 80kb etc?

    Might be worth looking at what Codec your voice is using. I know we can quite happily get away with an 8kb codec at opposed to a 64kb. We've always found that users don't need the full fat voice codec and can't tell the difference

  • So all the UTM does is when it sees a DSCP with a value of 46, it then commits X amount of  KBit (not KByte, hate this swapping back and forth from byte to bit in the systems) of guaranteed bandwidth.  It doesn't matter if you have 1 call going or 100 calls going, it just know it sees a DSCP 46 and guarantees that.

    If I wanted to do what you said, I'd need to define a traffic selector with a source for each single phone IP, best to make sure DSCP 46 was set as well as the source to make sure stupid things like NTP fetch wouldn't keep flagging it.  Then I could set each of them to have a small bandwidth guarantee.  That would work a little better, and I may end up swapping to that, but that makes for a lot of admin overhead on the phone system.  Either the UTM has to be doing your DHCP (doesn't really happen in a corporate environment usually) or you need to have your phones setup as static IP.  You will then always have to add and delete the phones in each of these traffic selectors and bandwidth pools if you ever change phones around.

    I like your idea as it keeps the most bandwidth available for other applications when not in use.  However, the whole point is to make this easy for an admin, and with a priority queue it would be a lot more dynamic and wouldn't have to be touched if the phone changed IPs or you added or deleted them, etc.  As more and more businesses get away from analog lines, and even dedicated Ts for their phone systems, this is a big must have for good small to medium business firewall appliances.