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.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...