AutoQoS configuration

[mohammedmahmoud]

All,

After i issued the "auto qos voip" command on one of my routers the router autoconfigures the commands provided in the attachement, my questions are:

1.Why did the router match on RTCP and add it to the LLQ-Priority (shouldn't LLQ be just for VoIP payload and not signaling)

2.In the ACL "AutoQoS-VoIP-RTCP", will it only match on the odd ports (RTCP)

3.Is RTCP considered VoIP signalling and not control (it is not matched in the class-map "AutoQoS-VoIP-Control-UnTrust") - Simply i mean is RTCP considered voice signalling while for example in SIP voice control is UDP port 5060 - I mean is voice signalling different than voice control

Thanks in advance.

[robert.hyde]

Hello,

Good questions. Since no one else has responded yet, I'll shoot some quick answers your way, and then if you can ask additional questions if you would like more detail. Long story short, RTCP is not really "call signaling" or "call control" within the scheme of VoIP. It is merely the control protocol for RTP, which carries the audio stream, and it will always accompany RTP. Generally speaking, RTCP will use <= 5% of the bandwidth that RTP uses, i.e. for every 64k of rtp voice you will see <= 3k of rtcp. Generally speaking. But RTCP does not function as call signaling, it does not fit into the grand scheme of call control, call setup, call teardown, and so on.

1. Because RTCP always accompanies RTP yet consumes such a small amount of bandwidth, the best practice is to group them together. As you indicated, however, best practice dictates that call signaling be kept OUT of the priority queue, so that you do not risk a surge in call signaling overrunning your priority queue and causing choppy voice.

2. Access-list AutoQoS-VoIP-RTCP will not match only on odd ports; it will match on all ports in that range. But because the access-list is the second match criteria within the AutoQoS-VoIP-RTP-UnTrust class, the "match protocol rtp audio" will catch the rtp packets first, which will have fallen on the even ports. Between those two match statements, you get rtp plus rtcp. Newer versions of nbar (embedded within newer IOS beginning with 12.1E) will match on rtcp, so you can simply use "match protocol rtp audio" and "match protocol rtcp" instead of having to use an access-list. In fact, most platforms will support the rtcp pdlm that you can download from CCO, see this link if you are interested:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1833/products_feature_guide09186a00804aedb8.html#wp1075340

3. RTCP is not voice signaling, it is simply control for RTP. Notice that the AutoQoS-VoIP-Control class is matching on the call control ports used by all the big players - SIP, H323, etc.

Hopefully this quick info will get you started, please feel free to reply with more questions. Good luck!

Best Regards

Robert

[mohammedmahmoud]

I really don't know what to say ... what a nice brief answer to my questions. I really enjoied your answer ... it seems that your are well experienced in these stuff.

but let me summarize the conclusions:

. For a well designed QoS scheme we should match on both RTP and RTCP to apply LLQ

. RTCP is not treated as call control or signalling

. the "match protocol rtp audio" only matches the even port while the ACL matches both (even and odd) but it was used in the illustrated AutoQoS to match RTCP (but using the ACL alone would have done the job - Match both even and odd ports)

really thanks.

[robert.hyde · Accepted solution]

You got it! I have seen case studies where RTCP was included in the priority queue of LLQ along with voice, and I have seen case studies where RTCP was left out, ultimately falling into the default class. But it appears that more and more QoS deployments are including RTCP in the priority queue, and the advantages are clear.

The "match protocol rtp audio" actually goes beyond just matching the even ports; it uses NBAR which looks into the payload itself to classify the packet as rtp audio. In fact, you can take it a step further and classify based on the payload type - the following example will match only rtp audio which is PCM a-law, PCM u-law, or G.729:

match protocol rtp payload-type "0, 8, 18"

See the following link for the list of RTP payload types:

http://www.iana.org/assignments/rtp-parameters

So in that AutoQos config that was generated, instead of just using the AutoQoS-VoIP-RTCP access-list to match both rtp audio and rtcp, they separated out rtp audio via the NBAR statement so that when you look at your "show policy-map interface" stats, you can see how much of the matched traffic was rtp audio and how much was rtp control.

Let me know if there are any more questions. Good luck!

Best Regards

Robert

[mohammedmahmoud]

Robert,

Thank you very very very much, one thing i am sure of is that your brief direct answers wouldn't be found easily in books ... Thanks very much and i won't hesitate if i have more questions.

Mohamed