Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

QOS issue with centralized call processing.

Hi, our environment consists of a 3 server call manager cluster in the headquarters and we have a branch office of about 30 IP phones that we have set up with centralized call processing off of the ccms at the headquarters with their own voice T1. So basically we are using the wan for call setup only. We have QOS on the router but we with are still having issues. The phones constantly reboot, slow functionality and and at times bad voice quality. I would like to know if anyone is using centralized call processing and if you have any suggestion that can help us. Also what is the bandwidth on the link? We have 512k and have since put an upgrade for a full t1 to see if it would solve our issue but not sure.



New Member

Re: QOS issue with centralized call processing.

Centralized call processing works fine in many networks. The main idea for working IP Telephony is QOS enabled infrastructure (Everywhere in the network). You have to check your QOS configuration on all network devices. More detailed info you can find here.

Don't forget to use Locations in CallManager configuration.


Re: QOS issue with centralized call processing.

You should be fine if your QOS is properly configured. One potential gotcha is the tagging of voice signalling packets. Cisco has transitioned from using AF31 to using IP precedence 3. Make sure your voice control/signalling class map is set to recognize either, unless you are sure which is being used. A helpful hint for catching this kind of issue is to use random-detect dscp-based in your default class. Then you can see what tags are present in the default traffic.

Here is an example:

class-map match-any voicecontrol

match ip dscp af31

match ip precedence 3


class-map match-any voice

match ip dscp ef


policy-map voiceT1

class voice

priority 600

class voicecontrol

bandwidth 64

class class-default


random-detect dscp-based

interface s0/0

service-policy out voiceT1

To verify:

show policy-map int s0/0

Please rate helpful posts.

New Member

Re: QOS issue with centralized call processing.

Hi Laila, I am having the same issue at a site, did you resolve this?




Re: QOS issue with centralized call processing.


from reading the PDF's i saw that you need to enable the priority queue by issuing the command priority out...

Hall of Fame Super Silver

Re: QOS issue with centralized call processing.

That's correct on the switches. You have to make sure you've enabled QoS end-to-end and trust boundries are configured correctly. Make sure LLQ is matching correct DSCP values

class match-any RTP

match ip dscp ef

class match-any Control

match ip dscp af31

match ip dscp cs3

policy-map voip

class RTP

priority percent 33

class Control

bandwidth percent 2

class default-class


apply it to the engress WAN interface on the router. To check if packets are matched issue:

sh policy-map interface serial x/x

Also, look at shaping, compression and LFI

refer to for QoS srnd doc,




Re: QOS issue with centralized call processing.


from ealier discussions with QOS issues of my own, it was recommended that i not mix the priority and bandwidth commands for the qos policy. meaning if i use priority percent for my first class, utilize the same priority command for the second (with different weighting values of course)


Re: QOS issue with centralized call processing.

I think they were talking about this:

The bandwidth and priority commands cannot be used in the same class, within the same policy map. These commands can be used together in the same policy map, however.

Within a policy map, you can give one or more classes priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is queued to the same, single, priority queue.

So the limitation is if you are doing two priority classes, they should both be the same - either percent or bandwidth (and really, should be percent). We usually don't put the signalling in priority queue, just reserve bandwidth, as the post above did.

Mary Beth

Re: QOS issue with centralized call processing.

Hi Laila,

- If you have QoS on the switches too, check if you set the trust on the switches correctly

- Use "DSCP" for trust at the switchports where CCM and WAN router are connected

- configure "ip accounting precedence in" and "ip accounting precedence out" on the interface and check if you see traffic in the correct classes ("show interface precedence")

- if you don't have voice bearer over the WAN you should not have a voice quality issue because of the WAN.-> check if clocking is okay ("show controller t1"). If you really have no voice bearer traffic, you don't need priority queueing.

- if you use DSCP for classifying, be aware that it can be AF31 (old) OR CS3. best would be to define both.

You have two problems which might not be interconnected:

- Voice quality

- Signalling problems (likely QoS problems)

Good luck,