QOS for Communicator clients

Unanswered Question
Aug 31st, 2010


Whats the best method to use to get QOS working for Communicator clients, Cisco Phones and Video Conf on a 3560G switch?

We dont know which ports are running the communicator clients.

Could i just setup a class map for communicator and video and apply to trunk port?



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.9 (6 ratings)
William Bell Tue, 08/31/2010 - 17:51

I suppose you could use the auto qos voip cisco-softphone configuration

command. But I am not a fan of auto qos so I couldn't guide you on what

this macro command is doing. You can read up on it here:



You could also look into leverage Trusted Relay Point (TRP). I prefer this

method. The idea is that you have a "media proxy" (for all intents and

purposes) that you can then use in your traffic classification at the edge.

I did a write up on it here:



That doesn't cover your video conferencing component. The approach take

with video depends on the equipment you have in play, the network areas

being traversed, the class of service you want to provide.




Please remember to rate helpful posts.

On 8/31/10 8:32 PM, "clougher01"

clougher01 Tue, 08/31/2010 - 18:13

Ok thanks i'll have to check if the cisco-softphone incorporates the

same ports as the cisco phone..

Aaron Harrison Wed, 09/01/2010 - 01:08

I'd fully agree with Bill's points above (+5).

AutoQos does a reasonable job for a customer that doesn't want the time/expense/consideration that needs to be put into a QoS design. It can be tricky due to the way that QoS is implemented using different commands, terminology, queueing/shaping methods on each switch type, and when you consider that most networks have at least two different switch families in play it makes it a difficult thing to explain unless someone is willing to put in their own time to chew over the SRND that Java has referenced below (+5).

90% of the time QoS raises it's head as something that's required when we roll out a CallManager; and for a lot of them AutoQos is fine as they don't have the requisite knowledge to do it manually.

It's also perfectly possible to take the 'baseline' autoqos configuration and tweak it to work they way you need it to. The downside to that is that by the time you know what you need to change, you're getting to the point where you've read most of the SRND and don't need AutoQos; but at least that way you are learning by example.

For example, in the original implementations the 'auto qos trust cisco-phone' command relied on the extended trust/CDP mechanism to recognise a phone, and required dot1q trunked phones. Pretty typical with CIsco setups, but didn't cater for softphones, didn't cater for anything else running on PCs (CUVA etc), and wasn't much use if you didn't have Cisco phones. The cisco-softphone choice would work fine for any softphone scenario (at least where the softphone would mark DSCP appropriately), non-Cisco phones, non-converged converged LANs (where customers have seperate 'Voice VLAN' switches(!)) etc.

The last time I did a modified autoqos install, I recall that the queueing configuration that was applied catered for video traffic, but the input service-policy on the edge ports didn't classify AF41 traffic at all. Adding another class and a policy map section to police that traffic to sensible levels was required to recognize that.



Tracy Larson Wed, 09/01/2010 - 05:07

Gotcha. I thought there would be some major downside to autoqos that I wasnt aware of. Thanks to all 3 of you for responding, your points make perfect sense.


Tracy Larson Tue, 08/31/2010 - 18:13

Hi Bill,

Not that this applies to this topic much, but could you elaborate as to why you are not a fan of auto qos? I use it in my switches for the phones and have no trouble with it. I have heard others say the same thing but I have never asked them why they dont want to use it. I am just curious because I would love to be doing things better if I can in all facets. Thanks if you choose to reply!

Edit: i also meant to say that i tried to go to your document to read it but i get a 404 error Article #70 not found.

Edit again: good lord, i needed to copy the whole link and past it, stupid word wrap nabbed you on this forum.

William Bell Tue, 08/31/2010 - 19:31


That could be a long discussion. I have to run so I will keep this brief.

The main reason is that I have been doing QoS on Cisco gear for a long time

and I remember a time when auto-qos macros were not available on every

platform. I also remember a time when auto-qos would make error in

configurations. IOW, I have seen software defects that would make any

perceive value negligible.

Further, in my current job I lay out design/architecture for the most part.

Which requires me to spell out the QoS configs for customer

documentation/education/etc. Implementation becomes a matter of scripting.

Finally, I typically find myself incorporate QoS for IPVC, video streaming,

non-Cisco voice gear, and business applications. This means I have to touch

the config either way, so why bother with auto-qos.

My opinion on auto-qos is primarily personal preference. If I am involved

with an implementation, I usually have a complete config template built out

that makes the auto-qos benefits moot.

That being said, I have had customers where I have recommended auto-qos.

This is true when the customer doesn't want to pay for a full

blown/end-to-end QoS design, the customer just doesn't get QoS, and/or the

customer is only doing voice (i.e. There are no business apps that require

QoS, there is no scavenger class, etc.).




On 8/31/10 9:13 PM, "[email protected]"


This Discussion