11-21-2008 12:14 AM - edited 03-06-2019 02:36 AM
Hi,
I want to know why do we need commands on a 4506 for IP Phones to work ?
This command is taken from a 4506 switch that works fine.
qos map dscp 24 25 26 27 28 29 30 31 to tx-queue 4
qos map dscp 32 33 34 35 36 37 38 39 to tx-queue 4
qos map cos 3 to dscp 26
qos map cos 5 to dscp 46
qos
!
!
<interface level command>
qos trust cos
auto qos voip cisco-phone
tx-queue 3
priority high
shape percent 33
1) Why are we only giving priority to queue 3 only with respect to voice ?
2) This would also work if I used this for Avaya Phones as well right ?
Thank you,
Cheers,
- InternetB -
Solved! Go to Solution.
11-22-2008 02:47 PM
Strictly speaking, you don't 'need' these commands to make IP phones work. QoS mechanisms will come into play only when there is congestion. Since phone traffic is both latency-sensitive and unreliable (non re-transmittable), it must be high priority. If you start dropping RTP packets from a voice call, the call will be choppy and sound quality will suffer, or the call will drop altogether. In the case of dropped packets from a TCP stream, we can just request retransmission of those packets, adding a minute amount of time to the TCP transfer (loading a webpage or somesuch).
Because of this, we can't buffer voice packets for very long, and so in times of congestion voice packets get the highest transmission priority. This is why, in this case, tx-queue 3 (DSCP 46 and CoS 5) is the priority queue. We will service the queue until empty before moving on to other queues.
I believe Avaya phones tag DSCP rather than CoS, so you would probably want to trust DSCP there instead of trusting CoS. Other than that, this should work fine.
11-22-2008 02:47 PM
Strictly speaking, you don't 'need' these commands to make IP phones work. QoS mechanisms will come into play only when there is congestion. Since phone traffic is both latency-sensitive and unreliable (non re-transmittable), it must be high priority. If you start dropping RTP packets from a voice call, the call will be choppy and sound quality will suffer, or the call will drop altogether. In the case of dropped packets from a TCP stream, we can just request retransmission of those packets, adding a minute amount of time to the TCP transfer (loading a webpage or somesuch).
Because of this, we can't buffer voice packets for very long, and so in times of congestion voice packets get the highest transmission priority. This is why, in this case, tx-queue 3 (DSCP 46 and CoS 5) is the priority queue. We will service the queue until empty before moving on to other queues.
I believe Avaya phones tag DSCP rather than CoS, so you would probably want to trust DSCP there instead of trusting CoS. Other than that, this should work fine.
01-14-2009 03:02 AM
Hi,
In addition to the previous reply, Avaya phones do tag DSCP rather then COS. I am currently implementing QoS on our network and found that using the "trust cos" did nothing, where the "trust dscp" worked like a charm.
Also, you may want to change to "auto qos voip trust" instead of "cisco-phone". If I'm not mistaken the "ip-phone" option works only trusts the markings if a Cisco phone is seen via CDP, if no Cisco phone is seen, everything gets marked zero.
qos trust cos
auto qos voip trust
no cdp enable
tx-queue 3
priority high
shape percent 33
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide