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


An earlier post questioned whether it was better to employ RSVP or utilize the Call Manager for CAC and I want to share my own experience.

If my take on the subject is incorrect, by all means add a follow up to correct the facts. I have only been involved in this for 5 months and my input is based on endless hours of cramming and hindsight into our own deployment of VoIP.

RSVP creates a reservation of Bandwidth meted out on demand. One CAC feature of Call Manager is the locations bandwidth. CM allocates this resource in 24k chunks. If you have properly deployed your structure to use G729, CM still allocates bandwidth in 24k chunks. Without defining your locations bandwidth with this in mind, CM will think you are out of bandwidth before you really are.

For example, you have a 128k circuit and you are using G729 compression, RTP header-compression, etc. You see the opportunity to make 10 individual calls at 12k each. You define your location in CM as 128k and find that CM will only let you make 5 calls before you get the NO Bandwidth message. CM allocates 24k, by default for each of your 12k calls. You aren't using 24k of bandwidth for the call but CM does reduce your total available bandwidth by 24k for each call from a given location and can make it appear you are out of resources before you really are. If your RSVP config on your router and the bandwidth for locations in CM were properly matched, your RSVP config on your router would still have bandwidth available for allocation on demand for 5 more calls.

RSVP, RTP Priority, RTP header compression, CBWFQ, and Call Admission Control in the Call Manager work in unison to provide true QOS.

Even if you aren't actively deploying VoIP, take a look at CBWFQ. I had no idea what was happening on my WAN circuits until I employed this. For once I could easily identify the volume of time sensitive traffic as well as limited the traffic which was harmful to VoIP and Terminal Services traffic, all from the CLI.

My own case for these tools is this. I commonly see 8 gigs of traffic cross a router's ethernet interface from remote sites to our hub location in a 24 hour period. Max jitter has been reduced and stabilized and it is not unusal to go a week at a time without seeing a SINGLE dropped packet.

Just my two cents.