/mcpQuality of Service for Voice over IP Resource Reservation Protocol 21 QoSVoIP.mif enhancements have been made to address these limitations, and RSVP can now be used to implement CAC and to signal a desired QoS that will provide good quality voice end-to-end, even in the presence of congestion. In this section RSVP is described (in general), focusing on a particular subset of platforms, topologies, and protocols. We also assume that you are using H.323 as the session protocol for a VoIP gateway-based network. This section includes the following subsections: • RSVP Overview • RSVP for CAC Overview • Deploying CAC Based on RSVP • Configuring Local Gateway Resources if CAC Fails • Using RSVP with LLQ • Deploying RSVP Support for LLQ RSVP Overview The initial implementation of RSVP for VoIP had two limitations. The first was that CAC could not be implemented with RSVP because the reservation process was not synchronized with the voice call signaling. A call would proceed even if the RSVP reservation had failed or had not been completed. The second limitation was that a successful RSVP reservation might not provide good voice quality during periods of network congestion. RSVP created a reserved queue-per-traffic flow within the WFQ system and relied on that system to guarantee a bounded delay. However, WFQ was unable in some cases to provide an acceptable bounded delay for voice. RSVP needed to be able to use the priority queue in LLQ to guarantee a bounded delay that would not affect voice quality. In addition, RSVP was not supported on ATM or on shaped Frame Relay PVCs. You should deploy RSVP to improve VoIP QoS only where it can have a positive impact on quality and functionality. The benefits of using RSVP outweigh the costs (management, overhead, and performance impact) only where there is limited bandwidth and frequent network congestion. Some IP environments have enough bandwidth to guarantee the appropriate QoS without needing to implement CAC for every call. The following four mechanisms were introduced in Cisco IOS software to handle resource-based CAC: • PSTN fallback—This method relies on network probing to measure delay, jitter, and loss to estimate the potential voice impairment that the call will experience. (The potential impairment is called the Calculated Planning Impairment Factor (ICPIF) and is explained in ITU-T G.113.) With this mechanism, you can define several thresholds so that calls are rejected if an IP network is congested. • CAC defined on local gateway resources such as CPU, memory, and number of calls—With this method, you can configure thresholds that trigger different actions, such as hairpin call, reject call, or play a message. • Bandwidth management via the H.323 gatekeeper—In this method, you can configure a maximum amount of bandwidth that gatekeepers then allocate to calls. • RSVP. In this document we discuss only the use of RSVP for CAC.