Prioritizing VOIP

vanagon2tdi · ‎04-11-2006

I am wokring on prioritizing our Voice traffic over our 10mb fiber link between our office and our hub, that houses our PRI gateway. Here is the config that i pu ton both sides of the link. I still see random call problems wich are usually voice dropping so that words here and there get missed.

class-map match-any VoIP-Control-UnTrust

match access-group name VoIP-Control

class-map match-any VoIP-RTP-UnTrust

match protocol rtp audio

match access-group name VoIP-RTCP

class-map match-any VoIP-Remark

match ip dscp ef

match ip dscp cs3

match ip dscp af31

!

policy-map Policy-UnTrust

class VoIP-RTP-UnTrust

priority percent 70

set dscp ef

class VoIP-Control-UnTrust

bandwidth percent 5

set dscp af31

class VoIP-Remark

set dscp default

class class-default

fair-queue

!

interface FastEthernet0/0

description Fiber to Hub

no ip address

duplex full

speed 10

service-policy output Policy-UnTrust

!

interface FastEthernet0/0.7

description Fiber to Hub

encapsulation dot1Q 7

ip address 7.x.x.x.255.255.248

no ip redirects

no ip mroute-cache

no snmp trap link-status

no cdp enable

!

ip access-list extended VoIP-Control

permit tcp any any eq 1720

permit tcp any any range 11000 11999

permit udp any any eq 2427

permit tcp any any eq 2428

permit tcp any any range 2000 2002

permit udp any any eq 1719

permit udp any any eq 5060

ip access-list extended VoIP-RTCP

permit udp any any range 16384 32767

This is on both sides of the link, ans i am still seeing problems, that seem to be related to other traffic taking bandwidth from the voice.

dgahm · ‎04-12-2006

It is unusual to mark packets and set up your queues with the same policy map, but having never tried it I can't say it won't work. If the voice endpoints are Cisco gateways or phones the DSCP values should already be set correctly, in which case you can just define your class maps to match ip dscp or ip precedence. If not Cisco, you might try using a policy map applied as an input service policy on the ingress interface to mark packets. Then your egress policy could just set up the bandwidth for your media and control traffic.

Have you done a show policy-map interface f0/0? This will show you what your service policy is actually doing. It would be especially useful if you can look when the quality is bad.

Do you have CAC to prevent the voice traffic from exceeding the size of the priority queue? Anything exceeding your 70% will be dropped even if bandwidth is available.

One thing that can cause clipping is having VAD enabled. Are your problems only happening when the link is heavily loaded? If all the time look at VAD.

Please rate helpful posts.

vanagon2tdi · ‎04-13-2006

Thanks for all your help. First i will admit that QOS is totally new to me and I am strugling.(taking course real soon)

All of my phones (non-cisco) are on a specific range of IP's. 10.7.7.20 to 10.7.7.50 Can I, on the ingress interface assign them a DSCP value that is matched on the outgoing interface that gives them high priority? Is this what you were saying to me? Is this a good idea?

Thanks again.

dgahm · ‎04-13-2006

As always the best solution depends on a lot of factors. In general, it is best practice to mark packets as close to the sending device as possible. If you have a Cisco switch you may be able to mark packets there which offers the best performance. Even though your phones are non-Cisco I bet they are capable of setting DSCP. This would simplify things, as you would just need to trust those settings, and then use them to setup your egress QOS. Is the gateway Cisco?

To answer your specific question, yes that would work , though it is important to differentiate between media and control traffic, so you will need to pin it down to ports as well as IP.

vanagon2tdi · ‎04-13-2006

Upon a bit more investgation I noticed that the phones send all of thier data to our voice server (10.7.7.19) here at this office, and then it sends the traffic to our voice server (7.7.1.19) in our hub, which in turn sends it to the Cisco voice gateway (10.254.254.3). At no time does the voice go directly to the GW or to the hub voice server (10.7.7.19).

So here is what I have and it seems to be helping.

class-map match-any voip-priority

match ip dscp ef

class-map match-any voip-tag

match access-group name voip-tag

!

policy-map voip-priority

class voip-priority

bandwidth 7500

class class-default

fair-queue

queue-limit 5

policy-map voip-traffic

class voip-tag

set ip dscp ef

class class-default

set ip dscp default

!

interface FastEthernet0/0

description Fiber to hub

no ip address

duplex full

speed 10

service-policy output voip-priority

!

interface FastEthernet0/0.7

encapsulation dot1Q 7

ip address 7.7.1.1 255.255.255.0

no ip redirects

no ip mroute-cache

no snmp trap link-status

no cdp enable

!

interface FastEthernet0/1

description Hub to Office

ip address 10.7.7.9 255.255.255.0

duplex full

speed 100

service-policy input voip-traffic

!

ip access-list extended voip-tag

permit ip host 10.7.7.19 host 7.7.1.19

!

I should have this similarly setup on the other side of my link right? that way it prioritises the traffic in both directions, right?

dgahm · ‎04-14-2006

Yes, you need to set up both directions. Does a show policy-map int FX/X verify that packets are being marked on F0/1 and priority queued on F0/0?

Please the use the pulldown menu to rate helpful posts.