Cisco Unified Communications Manager System Guide, Release 9.1(1)
Resource Reservation Protocol
Download this chapter
Resource Reservation ProtocolResource Reservation Protocol
Download the complete book
Cisco Unified Communications Manager System Guide, Release 9.1(1)Cisco Unified Communications Manager System Guide, Release 9.1(1) (PDF - 9 MB)
 Feedback

Contents

Resource Reservation Protocol

Resource Reservation Protocol (RSVP) specifies a resource-reservation, transport-level protocol for reserving resources in IP networks. RSVP provides an additional method to achieve call admission control (CAC) besides location-based CAC. Location-based CAC constitutes a point-to-point CAC mechanism that does not take into account topology changes nor multi-tiered topologies, whereas RSVP does take these into account.

  • The following factors call for RSVP support as an alternative call admission control (CAC) mechanism in Cisco Unified Communications Manager:
  • Many customers request a full-mesh network topology for their video conferencing and video telephony environment to match their existing topology. If Cisco Unified Communications Manager does not support an RSVP-based CAC mechanism, a location-based CAC mechanism can still be leveraged as a viable solution.
  • The Quality of Service (QoS) baseline recommends that all VoIP and videoconferencing devices provide admission control by using RSVP.

For more information on call admission control (CAC), see the Call admission control.

This section provides an overview of RSVP, describes RSVP configuration within Cisco Unified Communications Manager, discusses migration to RSVP, shows example RSVP interactions, and provides troubleshooting information.

Configure RSVP

Resource Reservation Protocol (RSVP) specifies a resource-reservation, transport-level protocol for reserving resources in IP networks. RSVP provides an additional method to achieve call admission control (CAC) besides location-based CAC. Location-based CAC constitutes a point-to-point CAC mechanism that does not take into account topology changes nor multi-tiered topologies, whereas RSVP does take these into account.

Procedure
    Step 1   Configure the clusterwide default RSVP policy.
    Step 2   Configure the RSVP policy for any location pair that requires a different RSVP policy from the clusterwide default RSVP policy.
    Step 3   Configure other RSVP-related service parameters:
    • RSVP Retry
    • Midcall RSVP Error Handling
    • MLPP-to-RSVP Priority Mapping
    • TSpec
    • DSCP
    • Application ID
    Step 4   Configure RSVP Agents for media devices.
    Step 5   Configure end-to-end RSVP over SIP trunks.
    Step 6   Enable RSVP for a call.
    Related Tasks
    Related References
    Related Information

    RSVP overview

    RSVP includes the following features:

    • RSVP reservations get made for a particular session. A session comprises a flow that has a particular destination address, destination port, and a protocol identifier (TCP or UDP). RSVP reservations treat each session as one independent unit.
    • RSVP messages travel along the same path as the media flow path.
    • RSVP specifies a unidirectional protocol, so flows get reserved in only one direction.
    • RSVP specifies a receiver-oriented protocol; as such, the receiver of the stream requests the reservation.
    • RSVP supports both unicast and multicast environments.
    • RSVP messages flow transparently through non-RSVP routers and switches.

    Advantages of RSVP

    The following factors make RSVP a more desirable solution than location-based call admission control (CAC) for providing quality of service (QoS):

    • RSVP can handle complex topologies. Location-based CAC supports only hub-and-spoke or point-to-point topologies, such as simple Multiprotocol Label Switching (MPLS) any-to-any topologies. Locations cannot properly support multi-tiered topologies. Location-based CAC does not handle complex topologies, such as the following
      • Redundant links (A = B)
      • More than three sites in a series (A - B - C - D)
      • Multilevel hierarchies (hubs, regions, and subregions)
      • Meshes
    • RSVP exhibits network awareness, whereas location-based CAC cannot handle dynamic changes to bandwidth.
    • IP videoconferencing not only requires significant bandwidth but also requires specialized service from the network with respect to latency and packet loss. RSVP enables network to accommodate such traffic without unduly degrading the performance of other applications in the network
    • RSVP supports Multilevel Precedence and Preemption (MLPP) inherently.

    RSVP capabilities

    The following capabilities get built on top of RSVP:

    • RSVP supports all signaling protocols, including SIP, SCCP, MGCP, and H.323.
    • RSVP works by enforcing a location-pair-based RSVP policy. You can enable and disable RSVP based on location pairs. This practice allows for migration.
    • The setting of a systemwide service parameter determines RSVP policy for the system. Therefore, you can enable or disable RSVP throughout the system. Location-pair-based policies, however, override the systemwide policy.
    • RSVP provides the following RSVP policy levels:
      • No reservation (Continue using location-based CAC.)
      • Mandatory
      • Optional (video desired)
      • Mandatory (video desired)
    • RSVP contains a retry reservation capability. This capability allows a call to gain or regain premium Quality of Service (QoS) even if the resources (bandwidth) are not currently available.
    • The RSVP Retry Timer controls the frequency of retry. The Mandatory RSVP Midcall Retry Counter and Mandatory RSVP mid call error handle option service parameters control the number of attempts to restore premium service by reserving the necessary resources if the initial RSVP policy specifies Mandatory.
    • RSVP integrates with Differentiated Services (DiffServ) QoS. The outcome of an RSVP reservation updates the Differentiated Services Code Point (DSCP) value.
    • The midcall failure policy that RSVP has means that this capability allows a user to determine what happens to the call if the call loses the bandwidth reservation in mid call. The following options exist:
      • The call fails after N reservation retries.
      • The call becomes a best-effort call.
    • RSVP supports bandwidth reservation for both audio and video streams.
    • RSVP provides application ID support.
    • RSVP supports Multilevel Precedence and Preemption (MLPP).
    • RSVP retains the reservation when a party gets put on hold. The reserved resource(s) can potentially get reused when the call resumes.
    • Shared-line devices that are located in the same location/region share the same reservation for incoming calls.
    • RSVP works with all Cisco Unified Communications Manager supplementary services and features to ensure that bandwidth reservation is correct after the service or feature is invoked. Examples of supported features include Call Transfer, Conference, and Call Forwarding.
    • RSVP supports Music on Hold (MOH) and annunciator features.

    RSVP-based MLPP

    When RSVP is configured, MLPP functions as follows:

    • Cisco Unified Communications Manager passes the precedence level of the MLPP call to the RSVP agent by means of SCCP Quality of Service (QoS) messages.
    • Agents add priority information to RSVP requests.
    • IOS routers can use this priority information to admit calls.
    • If preemption occurs at the IOS router, the RSVP agent notifies Cisco Unified Communications Manager about the reservation failure due to preemption.
    • Cisco Unified Communications Manager notifies the preempted calling party and called party of the preemption. Cisco Unified Communications Manager uses the existing MLPP functionality, which resembles the location-based call admission control (CAC) MLPP preemption mechanism.
    • Preempted calls can either fail or continue with decreased QoS. Preempted calls receive the same treatment as midcall reservation failure.

    Additional features

    Cisco Unified Communications Manager supports the following interactions:

    • RSVP agent supports Differentiated Services Control Point (DSCP) remarking. This capability mitigates the trust issues with desktop applications, such as Communicator and VTA.
    • RSVP supports audio, video, and data pass-through. Video data pass-through allows video and data packets to flow through RSVP agent and media termination point devices. Video data pass-through also allows audio transcoding to work with video calls. Audio pass-through allows encrypted calls to flow through MTPs.

    Pass-Through Conditions

    The following conditions apply to both audio and video/data pass-through:

    • All intermediate MTP devices support pass-through.
    • No "MTP required" check box is checked for either endpoint.

    The following additional audio pass-through condition applies:

    • A matching audio cap exists between two endpoints after region filtering.

    The following additional video pass-through condition applies:

    • All intermediate MTP devices support multimedia. That is, MTP devices support multiple channels per call.

    RSVP caveats

    RSVP presents the following support limitations:

    • Cisco Unified Communications Manager does not support RSVP interaction with endpoints that support RSVP natively.
    • RSVP does not support the G. Clear Codec.

    Note

    RSVP does not conflict with Automated Alternate Routing (AAR), which continues to function if AAR is configured. See the Automated Alternate Routing for details.

    RSVP agent and quality of service

    Cisco Unified Communications Manager uses an RSVP agent, which is an IOS-based RSVP proxy with an SCCP interface to support RSVP. Cisco Unified Communications Manager communicates with the RSVP agent through a set of SCCP messages. The RSVP agent registers with Cisco Unified Communications Manager as either a media termination point or a transcoder device.

    Each endpoint requires an RSVP agent. The agent pair (one agent for endpoint A, another agent for endpoint B) signals RSVP on behalf of the endpoints that Cisco Unified Communications Manager controls.

    RSVP agent example

    Figure 1. Cisco Unified Communications Manager network configured with RSVP Agent. This figure illustrates an example of a Cisco Unified Communications Manager network with RSVP that is configured through an RSVP agent.



    RSVP agent allocation

    Cisco Unified Communications Manager allocates the RSVP agent resource in the same manner that it allocates media termination point and transcoder resources. You configure a Media Resource Group List (MRGL) that includes the RSVP agent and assign the MRGL to the device or the device pool that associates with the device. RSVP reservation fails if the same RSVP agent is assigned to both endpoints that are making a call.

    RSVP agent interaction with location-based CAC

    Cisco recommends that you do not activate both location-based Call Admission Control (CAC) and RSVP at the same time, except during the migration period from location-based CAC to RSVP.

    If location bandwidth is not set to unlimited (infinite bandwidth) in the location, Cisco Unified Communications Manager performs location-based CAC before performing RSVP. If location-based CAC fails, the call fails, and Cisco Unified Communications Manager does not invoke RSVP.

    If location bandwidth is set to unlimited (infinite bandwidth) in the location, Cisco Unified Communications Manager invokes RSVP based on RSVP policy for the location pair that is associated with the calling and the called parties.

    RSVP configuration

    RSVP configuration comprises configuration of various service parameters and other components. The sections that follow describe the various service parameters and other configuration that is needed to configure RSVP.


    Tip

    Before you configure RSVP, see the Configure RSVP.

    Configure clusterwide default RSVP policy

    To configure the clusterwide RSVP policy, configure the following clusterwide (System - RSVP) service parameter for the Cisco CallManager service:

    Procedure
      Step 1   In Cisco Unified Communications Manager Administration, choose the System > Service Parameters menu option.
      Step 2   In the Service Parameter Configuration window, choose a server and choose the Cisco CallManager service.
      Step 3   In the Clusterwide Parameters (System - RSVP) section, configure the Default interlocation RSVP Policy service parameter.

      You can set this service parameter to the following values:

      • No Reservation-No RSVP reservations get made between any two locations.
      • Optional (Video Desired)-A call can proceed as a best-effort, audio-only call if failure to obtain reservations for both audio and video streams occurs. RSVP agent continues to attempt RSVP reservation for audio and informs Cisco Unified Communications Manager if reservation succeeds.
      • Mandatory-Cisco Unified Communications Manager does not ring the terminating device until RSVP reservation succeeds for the audio stream and, if the call is a video call, for the video stream as well.
      • Mandatory (Video Desired)-A video call can proceed as an audio-only call if a reservation for the audio stream succeeds but a reservation for the video stream does not succeed.

      Configure location-pair RSVP policy

      Use the Location Configuration window to configure the RSVP policy for a given location pair. The RSVP policy that is configured for a location pair overrides the default interlocation RSVP policy that you configure in the Service Parameter Configuration window.

      To configure the RSVP policy for a pair of locations, configure the RSVP Setting field for the location pair:

      Procedure
        Step 1   In Cisco Unified Communications Manager Administration, choose the System > Location menu option.
        Step 2   Find one location of the location pair and select this location.
        Step 3   To modify the RSVP policy between the selected location and another location, select the other location in the location pair.
        Step 4   In the RSVP Setting drop-down list box, choose an RSVP policy for this location pair.

        You can set this field to the following values:

        • Use System Default-The RSVP policy for the location pair matches the clusterwide RSVP policy. See the Configure clusterwide default RSVP policy for details.
        • No Reservation-No RSVP reservations get made between any two locations.
        • Video Desired (Optional)-A call can proceed as a best-effort, audio-only call if failure to obtain reservations for both audio and video streams occurs. The RSVP agent continues to attempt RSVP reservation for audio and informs Cisco Unified Communications Manager if reservation succeeds.
        • Cisco Unified Communications Manager does not ring the terminating device until RSVP reservation succeeds for the audio stream and, if the call is a video call, for the video stream as well.
        • Video Desired-A video call can proceed as an audio-only call if a reservation for the audio stream succeeds but the reservation for the video stream does not succeed.

        Configure RSVP retry

        Use the following clusterwide (System - RSVP) service parameters to configure the frequency and number of RSVP retries:

        • RSVP Retry Timer
        • Mandatory RSVP Midcall Retry Counter

        To locate and configure these service parameters, follow these steps:

        Procedure
          Step 1   In Cisco Unified Communications Manager Administration, choose the System > Service Parameters menu option.
          Step 2   In the Service Parameter Configuration window, choose a server and choose the Cisco CallManager service.
          Step 3   In the Clusterwide Parameters (System - RSVP) section, configure the specified service parameters.

          You can set these service parameters to the following values:

          • RSVP Retry Timer-Specify the RSVP retry timer value in seconds. If you set this parameter to 0, you disable RSVP retry on the system.
          • Mandatory RSVP Midcall Retry Counter-Specify the midcall RSVP retry counter when the RSVP policy specifies Mandatory and midcall error handling option is set to "call fails following retry counter exceeds." The default value specifies 1 time. If you set the service parameter to -1, retry continues indefinitely until either the reservation succeeds or the call gets torn down.

          Configure midcall RSVP error handling

          Use the following clusterwide (System - RSVP) service parameter to configure midcall RSVP error handling:

          • Mandatory RSVP mid call error handle option

          To locate and configure this service parameter, follow these steps:

          Procedure
            Step 1   In Cisco Unified Communications Manager Administration, choose the System > Service Parameters menu option.
            Step 2   In the Service Parameter Configuration window, choose a server and choose the Cisco CallManager service.
            Step 3   In the Clusterwide Parameters (System - RSVP) section, configure the specified service parameter.

            You can set the Mandatory RSVP mid call error handle option service parameter to the following values:

            • Call becomes best effort-If RSVP fails during a call, the call becomes a best-effort call. If retry is enabled, RSVP retry attempts begin simultaneously.
            • Call fails following retry counter exceeded-If RSVP fails during a call, the call fails after N retries of RSVP, where the Mandatory RSVP Mid-call Retry Counter service parameter specifies N.

            Configure MLPP-to-RSVP priority mapping

            Use the following clusterwide (System - RSVP) service parameters to configure the mapping from a caller MLPP precedence level to RSVP priority:

            • MLPP EXECUTIVE OVERRIDE To RSVP Priority Mapping
            • MLPP FLASH OVERRIDE To RSVP Priority Mapping
            • MLPP FLASH To RSVP Priority Mapping
            • MLPP IMMEDIATE To RSVP Priority Mapping
            • MLPP PL PRIORITY To RSVP Priority Mapping
            • MLPP PL ROUTINE To RSVP Priority Mapping

            To locate and configure these service parameters, follow these steps:

            Procedure
              Step 1   In Cisco Unified Communications Manager Administration, choose the System > Service Parameters  menu option.
              Step 2   In the Service Parameter Configuration window, choose a server and choose the Cisco CallManager service.
              Step 3   In the Clusterwide Parameters (System - RSVP) section, configure the specified service parameters.

              These service parameters function as follows:

              • Cisco Unified Communications Manager maps the caller precedence level to RSVP priority when initiating an RSVP reservation based on the following configuration: the higher the service parameter value, the higher the priority.
              • The IOS router preempts the call based on RSVP priority.
              • The RSVP agent must notify Cisco Unified Communications Manager about the reason for an RSVP reservation failure, including the cause for preemption.
              • Cisco Unified Communications Manager uses the existing MLPP mechanism to notify the preempted calling and called parties about the preemption.

              TSpec

              The TSpec object describes the traffic that the sender generates. The TSpec gets transported through the network to all intermediary routers and to the destination endpoint. The intermediate routers do not change this object and the object gets delivered unchanged to the ultimate receiver(s).

              The TSpec object comprises the following elements:

              • averageBitRate (kb/s)
              • burstSize (bytes)
              • peakRate (kb/s)

              Audio TSpec

              For audio flows, the TSpec calculations specify the following measurements:

              • burstSize (bytes)-This value gets calculated as the size of the packet times the number of packets in a burst. For audio flows, the burst usually specifies 1 to 2.
              • peakRate (bytes)-The peakRate, in bytes, refers to the maximum bytes/second that the endpoint transmits at any given time. If the burst is small, as is the case in audio streams, the peakRate can be calculated as 1.1 (or 1.2) times the tokenRate.

              To avoid adjusting the bandwidth reservation upward when the call gets answered, Cisco Unified Communications Manager reserves the maximum bandwidth for each region codec at call setup time. Cisco Unified Communications Manager then modifies or adjusts the bandwidth based on the media capability of the connected parties when the call gets answered.

              Example Audio TSpec Calculations

              See the following examples of bandwidth calculations for different region codecs for call setup.

              G.711: 8 sample/frame; for 10-ms packet: 80 + 40 (header) = 120 * 100 (packets/sec) = 12000 * 8 = 96 kb/s; (packet_size_in_ms*8+40)*8000/packet_size_in_ms

              G.729: 10 ms/frame; 8 kb/s; Default is 20 ms; 0 and 10 are possible. For 10-ms packet: 10 + 40 = 50 * 100 = 5000 * 8 = 40 kb/s

              kb/s: (packet_size_in_ms+40)*8000/packet_size_in_ms

              The TSpec of the G.711 codec specifies the following calculations:

              Tspec.mAverageBitRate = bwPlusHeader = 96 kb/s;

              Tspec.mPeakRate = Tspec.mAverageBitRate * (1.2) = 115;

              Tspec.mBurstSize = PacketSize * 2 = 120 * 2 = 240;

              Video TSpec

              For video streams, the packet length does not depend on codecs. Individual implementations provide the basis for packet length. Also, the packet sizes do not remain uniform across all packets. Estimating the number of packets per second therefore proves difficult.

              Assume that the maximum packet size for a video stream specifies 1000 bytes.

              The RSVP Video Tspec Burst Size Factor service parameter in the Clusterwide Parameters (System - RSVP) section of the service parameters for the Cisco CallManager service allows you to configure the video stream burst size. The default value for this service parameter specifies 5.

              The following elements comprise the video Tspec:

              • burstSize (bytes)-Burst size factor (5) * max packet size (1000)
              • peakRate (bytes)-This element refers to the maximum bytes/second that the endpoint transmits at any given time. If the burst is small, as is the case with audio streams, you can calculate the peakRate as 1.1 (or 1.2) times the tokenRate.

              Cisco Unified Communications Manager attempts to use the bandwidth for the entire video call to reserve bandwidth for the video stream first: 384 kb + overhead.

              Example: 384 + 27 = 410 kb/s

              If insufficient bandwidth exists for the entire video call, Cisco Unified Communications Manager next attempts to reserve the following amount of bandwidth: (video call bandwidth - audio stream codec) + overhead).

              Example: (384 - 64) + 22 = 342 kb/s

              The Tspec for the 384 kb codec specifies the following calculations:

              Tspec.mAverageBitRate = bwPlusHeader = 410 kb/s;

              Tspec.mPeakRate = Tspec.mAverageBitRate = 410;Tspec.mBurstSize = 1000 * 5 = 5000;

              DSCP

              If the RSVP reservation fails, Cisco Unified Communications Manager instructs the RSVP agent or endpoint devices (in case a failure to allocate an RSVP agent occurs) to change media Differentiated Services Control Point (DSCP) marking to best effort. Otherwise, an excess of EF-marked media packets can degrade quality of service (QoS) even for flows that have a reservation.

              Cisco Unified Communications Manager uses the clusterwide (System - QoS) DSCP for Audio Calls When RSVP Fails service parameter or the DSCP for Video Calls When RSVP Fails service parameter to determine the DSCP values for this instruction when RSVP fails for the call.

              Application ID

              An application ID specifies an RSVP object that can be inserted in a policy element in an RSVP message. RFC 2872 describes this object. This policy object serves to identify the application and associates the application with the RSVP reservation request, thus allowing routers along the path to make appropriate decisions based on the application information.

              The following clusterwide (System - RSVP) system parameters allow configuration of application IDs:

              • RSVP Audio Application ID
              • RSVP Video Application ID

              When a voice call is made between locations with an RSVP policy, the resulting reservations for the audio stream get tagged with the RSVP Audio Application ID. When a video call is made between locations with an RSVP policy, the resulting reservations for the audio stream and the video stream get tagged with the RSVP Video Application ID.

              If a call changes from audio to video, the following happens:

              • The existing audio reservation gets released from the audio pool.
              • The audio bandwidth reservation is re-attempted in the video pool with optional policy.
              • The Application ID for the audio stream gets changed to RSVP Video, and the new video stream gets tagged with the RSVP Video Application ID.

              If a video call changes to an audio call, the following happens:

              • Both existing audio and video reservations are released from the video pool.
              • The audio bandwidth reservation is re-attempted in the audio pool with optional policy.
              • The Application ID for the audio stream gets changed to RSVP Audio.

              Note

              In an end-to-end RSVP environment, when the audio bandwidth reservation is re-attempted in either the audio or video pool, both clusters try to release the audio bandwidth from the existing pool and re-attempt the audio reservation in the new pool. This can cause a race condition that might take up to a re-try cycle to complete before the audio bandwidth reservation in the new pool happens.

              By using this call admission control model, you can reserve a certain amount of bandwidth for voice calls and allow them to use the entire available bandwidth in the priority queue, thus ensuring that all the available bandwidth can be used for voice calls if no video calls are in progress. If enough available bandwidth exists in the priority queue, calls can optionally be enabled for video. You can set limits on how much bandwidth the video-enabled calls can consume, but if voice calls are consuming all the available bandwidth, it might not be possible to place a video call at all.

              RSVP for media devices

              Because conference bridges, music on hold servers, and annunciators do not specify Media Resource Group List (MRGL) configuration, you make RSVP resources available for these devices by associating these devices with a device pool that has an associated RSVP agent. The MRGL that is associated with the device pool gets used to allocate RSVP resources for these types of media devices.

              Use RSVP between clusters

              RSVP supports reservations between end points in separate clusters by using two different configurations: local and end-to-end.

              Local RSVP

              Local RSVP does not support reservations between two RSVP agents that are located in different clusters. It uses two RSVP agents per cluster, and does not use RSVP across the trunk that connects the clusters. This is the default configuration.

              Consider the following scenario:

              endpoint A - agentA - agentICT1 - ICT1 - ICT2 - agentICT2 - agentB - endpoint B

              where A specifies an endpoint in cluster 1, B specifies an endpoint in cluster 2, ICT1 and ICT2 specify the intercluster trunks within clusters 1 and 2, and the RSVP Agents associate with the respective devices.

              In this scenario, Cisco Unified Communications Manager 1 controls the reservation between agentA and agentICT1, and Cisco Unified Communications Manager 2 controls the reservation between agentB and agentICT2.

              As an alternative, you can use Cisco Unified Border Element (formerly Cisco Multiservice IP-to-IP) gateways. See the Configure gatekeepers and trunks for more information.

              End-to-End RSVP

              End-to-end RSVP configuration is available if the clusters are connected by a SIP trunk. End-to-end RSVP uses RSVP on the entire connection between the end points, and uses only one RSVP agent per cluster.

              Consider the following scenario:

              endpoint A - agentA - ICT1 - ICT2 - agentB - endpoint B

              where A specifies an endpoint in cluster 1, B specifies an endpoint in cluster 2, ICT1 and ICT2 specify the intercluster trunks within clusters 1 and 2, and the RSVP Agents associate with the respective end points.

              In this scenario, Cisco Unified Communications Manager establishes an end-to-end RSVP connection between agentA and agentB.

              Configuring End-to-End RSVP Over a SIP Trunk

              RSVP configuration on a SIP trunk is determined by the SIP profile that is applied to the trunk. To enable end-to-end RSVP on a SIP trunk, configure the trunk’s SIP profile as follows:

              • From the RSVP Over SIP drop-down list, choose E2E.
              • Set the Fall back to local RSVP field to your preference.
              • From the SIP Rel1XX Options drop-down list, choose an option other than Disabled.

              Enable RSVP for a call

              To enable RSVP for a call, follow these steps:

              Procedure
                Step 1   Assign the calling device and the called device to different locations.
                Step 2   Either configure default interlocation policy to any setting other than "No Reservation" or use the Location Configuration window to configure the RSVP setting for the two locations to anything other than "No Reservation."
                Step 3   Assign a Media Resource Group List (MRGL) that includes an RSVP agent resource to both endpoint devices. Use either the configuration window for the devices or the Device Pool Configuration window.

                Special configuration with RSVP

                In an RSVP session, special configuration applies if all the following conditions exist:

                • One endpoint device, such as Cisco IP Interactive Voice Response (IP IVR), was configured to support only the G.711 codec.
                • RSVP was configured for the call.
                • The interregion codec specifies G.729 between the calling RSVP agent and the called RSVP agent.

                When the call is made, to achieve successful allocation and reservation of RSVP agent resources and bandwidth, the administrator must configure the media termination point (MTP)/RSVP agent with the G.729 codec in addition to the pass-through codec. This configuration allows insertion of a transcoder between the RSVP agent of the called side and the called device at the time of media connection. When codecs match, codec pass-through takes place; if codecs do not match, the call cannot continue without a transcoder.

                If configuration of the G.729 codec in the agent does not take place, the call will fail because Cisco Unified Communications Manager will not invoke a transcoder that is needed for the RSVP call.

                The situation arises if either of the following conditions apply: the interregion codec gets used between calling and called agents or between two endpoints that specify G.729. Two options exist to enable successful routing of this call:

                • Use RSVP agent for IVR as a transcoder. In this case, the interregion codec between the transcoder/RSVP agent and IVR needs to specify the G.711 codec.
                • Use software MTP as RSVP Agents and insert a transcoder between IVR and the RSVP agent for IVR. In this case, ensure the software MTP is configured with the G.729 codec in addition to the pass-through codec.

                Keep in mind that the RSVP agent that has transcoding capability cannot perform G.729-to-G.729 transcoding. If you use a transcoder as an RSVP agent, you either must use the pass-through codec or configure the transcoder, so one of the codecs that is used on both sides of the transcoder specifies G.711.

                Migrate to RSVP

                Migration from location-based call admission control (CAC) to RSVP requires that you take some special circumstances into consideration. During the RSVP deployment time period, devices in some locations will probably have RSVP agent that is configured while others do not have RSVP agent that is configured.

                When a call takes place from a location that has RSVP agent to another location that does not have RSVP agent, Cisco Unified Communications Manager will manage the quality of service (QoS) of the call by using both location-based CAC and RSVP. The first part of the call, from the location that has RSVP agent to the hub/central site that has RSVP, uses the RSVP mechanism. The second part of the call, from the hub/central site to the location that does not have RSVP, gets managed through location-based CAC. If either mechanism fails to allocate bandwidth, the call fails.

                Procedure
                  Step 1   Install RSVP agent A at Location 1.
                  Step 2   Install RSVP agent B at Location 0 (hub).
                  Step 3   Add agent A to the Media Resource Group List of all endpoints at Location 1.
                  Step 4   Add agent B to the Media Resource Group List of all endpoints not at Location 1, including devices at the hub and at all other locations.
                  Step 5   Configure RSVP policy from Location 1 to all other locations to be Mandatory (or some other policy, if desired).
                  Step 6   Change the location CAC bandwidth limit for Location 1 to unlimited.
                  Figure 2. Migrating the First Spoke of a Location Configuration. This illustration shows a location configuration to which the migration process applies.



                  After you perform the preceding configuration steps, the following bandwidth applies to the locations:
                  Table 1 Bandwidth
                  Location Bandwidth
                  0 Unlimited
                  1 Unlimited
                  2 1500
                  3 3000
                  4 3000
                  After you perform the preceding configuration steps, the following RSVP policies apply:
                  Table 2 RSVP policies

                  Location Pair

                  RSVP Policy

                  1

                  1

                  None

                  1

                  Not 1

                  Mandatory

                  Not 1

                  Not 1

                  None

                  After you take the preceding configuration steps, the following call admission control (CAC) takes place:
                  • Calls within locations 0, 2, 3, and 4 use the same CAC as before.
                  • Calls within location 1 are not subject to CAC.
                  • Calls between location 0 and location 1 use RSVP CAC.
                  • Calls between location 1 and locations 2, 3, or 4 have RSVP on the 0-to-1 link and location-based CAC on the 0-to- 2, 0-to-3, or 0-to-4 link. If either mechanism fails, the call fails.

                  RSVP interactions

                  The following sections provide examples of RSVP interaction with various Cisco Unified Communications Manager features and services.

                  RSVP and IPv6

                  RSVP does not support IPv6. RSVP calls support IPv4. If RSVP is required for the call and any device in the call is configured for or uses an IPv6 address, Cisco Unified Communications Manager rejects the call, and the caller receives a busy tone. For more information on IPv6, see RSVP and MLPP.

                  RSVP and shared-line calls

                  Figure 3. RSVP During a Shared--Line Call (Alerting Phase). This illustration shows the RSVP interaction during the alerting phase of a shared-line call.



                  The example shows the following configuration during the alerting phase of the shared-line call:

                  • Phones B1 (in location 2), B2 (in location 3), and B3 and B4 (both in location 4) share the DN 2000.
                  • The RSVP agent in location 1 has a single reservation. The reservation has multiple destinations, one to each RSVP agent in the other locations (2, 3, and 4).
                  • RSVP agent in location 4 has one allocated reservation. Phones B3 and B4 share this reservation.

                  Phones B3 and B4, which share the DN 2000, use a single RSVP agent.

                  Figure 4. RSVP During a Shared-Line Call (Call Answered Phase). This illustration shows the RSVP interaction after a shared-line call gets answered.



                  After phone B2 (in location 3) answers the shared-line call, the RSVP reservation between location 1 and location 2, as well as the reservation between location 1 and location 4, get torn down. Only the RSVP reservation between location 1 and location 3 remains established.

                  RSVP and music on hold

                  Figure 5. Phone B Puts Phone A on Hold, MOH Server in Same Location as Phone A. This illustration shows a call that invokes Music On Hold. Phones A and B are in a call when phone B puts phone A on hold. In this example, the MOH server resides in the same location as phone A.



                  RSVP preserves the reservation between phone A and phone B while phone A is on hold and receiving Music On Hold. After the call between phone A and phone B resumes, the reserved resource gets reused. Because phone A and the MOH server that provides its music on hold are in the same location, no need exists for RSVP reservation between phone A and the MOH server.

                  Figure 6. Phone B Puts Phone A on Hold, MOH Server in Same Location as Phone B. This illustration shows a call that invokes Music On Hold. Phones A and B are in a call when phone B puts phone A on hold. In the illustration, the MOH server resides in the same location as phone B.



                  This example shows a phone call between phone A and phone B, with the music on hold server in the same location as phone B. If phone B puts phone A on hold, so phone A receives music on hold, the reservation that was used to connect phone A and phone B gets reused for the music on hold session. No additional reservation gets created.

                  Figure 7. Phone B Puts Phone A on Hold, MOH Server in a Third Location. This illustration shows a call that invokes music on hold. Phones A and B are in a call when phone B puts phone A on hold. In the illustration, the MOH server occupies a different location from both phone A and phone B. (Phone A, phone B, and the music on hold server each reside in a different location.)



                  If phone B puts phone A on hold, so phone A receives music on hold, RSVP agent preserves the reservation that was used to connect phone A and phone B. Another RSVP agent creates a new reservation between phone A and the MOH server.

                  RSVP and call transfer

                  Figure 8. Call from Phone A to Phone B with RSVP Agent Connection. This illustration shows the initial scenario, where phone A is in a call with phone B.



                  In the illustration, phone A, DN 1000, location 1, calls phone B, DN 2000, location 2. RSVP agent establishes a reservation for the call. Phone B presses the Transfer button and dials DN 3000. Phone C, DN 3000, location 4, answers the call.

                  Figure 9. Phone B Initiates Transfer of Call from Phone A to Phone C. This illustration shows the RSVP connections as phone B transfers the call to phone C.



                  When phone B initiates transfer of the call from phone A to phone C in this configuration, the RSVP agent preserves the reservation between phone A and phone B. An RSVP agent creates a new RSVP reservation between phone A and the MOH server. An RSVP agent creates a new reservation between phone B and phone C.

                  Figure 10. Call Transfer Completes, and Phone A and Phone C Get Connected. This illustration shows the scenario after the transfer completes.



                  After phone B completes the transfer, a new RSVP reservation gets created between phone A and phone C. The RSVP reservations between phone A and the MOH server, phone A and phone B, and phone B and phone C, all get torn down.

                  RSVP and MLPP

                  The following sections discuss various RSVP-based MLPP scenarios.


                  Note

                  RSVP-based MLPP does not support nonpreemtable numbers.

                  Scenario 1: A lower priority call gets preempted during congestion.

                  Initial call RSVP Policy: Mandatory

                  Midcall RSVP Policy: Call fails. No retries

                  Other configuration details: RSVP bandwidth equals 100 kb/s. Each call takes 80 kb/s; therefore, only one call can obtain a reservation successfully.

                  1. Start a Priority call. The call succeeds.
                  2. Start a Routine call. The call fails to initialize due to the Mandatory setting.
                  3. Start a Flash call. The call succeeds because the Priority call gets preempted.

                  Scenario 2: A video call proceeds as an audio-only call if sufficient bandwidth does not exist.

                  Initial call RSVP Policy: Mandatory with video desired

                  Midcall RSVP Policy: Best effort

                  Other configuration details: RSVP bandwidth equals 100 kb/s. Each audio calls takes 80 kb/s; therefore, only one call can obtain a reservation successfully.

                  1. Start a Priority audio call. The call succeeds.
                  2. Start a Flash video call. The call starts as audio only because insufficient bandwidth exists for a video call. The quality of the Priority call decreases.

                  Scenario 3: A lower priority call continues during congestion with no premium QoS.

                  Initial call RSVP Policy: Optional

                  Midcall RSVP Policy: Best effort

                  Other configuration details: RSVP bandwidth equals 100 kb/s. Each audio calls takes 80 kb/s; therefore, only one call can obtain a reservation successfully.

                  1. Start a Priority call. The call succeeds.
                  2. Start a Routine call. The call succeeds, but no premium QoS is available. (The call uses a different DSCP.)
                  3. Start a Flash call. The call succeeds. The QoS for the Priority call decreases.
                  4. End (hang up) the Flash call. The Priority call recovers the RSVP reservation, and QoS increases.

                  Troubleshooting RSVP

                  For information about troubleshooting end-to-end RSVP, see the Troubleshooting end-to-end RSVP.

                  RSVP provides the performance monitoring (PerfMon) counters, Call Detail Records (CDRs), alarms, and trace information to assist with troubleshooting RSVP.

                  Performance monitoring counters

                  The following Cisco Unified Communications Manager RSVP admission control performance monitoring counters exist:

                  • RSVP AudioReservationErrorCounts
                  • RSVP MandatoryConnectionsInProgress
                  • RSVP OptionalConnectionsInProgress
                  • RSVP TotalCallsFailed
                  • RSVP VideoCallsFailed
                  • RSVP VideoReservationErrorCounts

                  These location-based and node-based performance monitoring counters do not synchronize across nodes.

                  To troubleshoot RSVP agent resources, the following RSVP performance monitoring counters exist:

                  • OutOfResources
                  • ResourceActive
                  • ResourceAvailable
                  • ResourceTotal

                  See the Cisco Unified Real Time Monitoring Tool Administration Guide for descriptions of the performance monitoring counters and instructions on how to view performance monitoring counters.

                  Call detail records

                  The Cisco Unified Communications Manager Quality of Service (QoS) RSVP agent feature adds the following Call Detail Record (CDR) fields:

                  • origRSVPAudioStat-Status of RSVP audio reservation from originator to terminator
                  • destRSVPAudioStat-Status of RSVP audio reservation from terminator to originator
                  • origRSVPVideoStat-Status of RSVP video reservation from originator to terminator
                  • destRSVPVideoStat-Status of RSVP video reservation from terminator to originator

                  These fields reflect the status of RSVP bandwidth reservation per audio or video stream.

                  The following values apply for the Cisco Unified Communications Manager RSVP CDR status fields:

                  • 0-Indicates RSVP NO RESERVATION condition, which is the default value.
                  • 1-Indicates RSVP RESERVATION FAILURE condition at call setup or feature invocation.
                  • 2-Indicates RSVP RESERVATION SUCCESS condition at call setup or feature invocation.
                  • 3-Indicates RSVP RESERVATION NO RESOURCE (RSVP agent) condition at call setup or feature invocation.
                  • 4-Indicates RSVP MID_CALL FAILURE_PREEMPTED condition (preempted after call setup).
                  • 5-Indicates RSVP MID_CALL FAILURE_LOST_BANDWIDTH condition (includes all midcall failure except MLPP preemption).

                  The Cisco Unified Communications Manager RSVP CDR status field value gets concatenated, and the most recent 32 status values get retained for the call.

                  Example

                  A call establishes with the Optional RSVP policy, and the initial RSVP reservation succeeds. The call subsequently loses its bandwidth reservation and regains the bandwidth reservation after retrying. This sequence repeats several times during the call, and the call ends with a successful RSVP reservation. In this case, the CDR shows the following string as the Cisco Unified Communications Manager RSVP reservation status for that particular stream:

                  "2:5:2:5:2:5:2" (success:lost_bw:success:lost_bw:success:lost_bw:success)

                  See the Cisco Unified Communications Manager CDR Analysis and Reporting Administration Guide for additional information.

                  Alarms

                  The RsvpNoMoreResourcesAvailable alarm gets generated when no RSVP agent resource is available.

                  The following Cisco Unified Communications Manager alarm catalog defines this alarm: /vob/ccm/Common/XML/AlarmCatalog/Communications Manager.xml.

                  Trace information

                  RSVP generates several SDL and SDI traces for the Cisco CallManager service upon RSVP reservation failure. The user sees the RSVP error codes in both the Cisco Unified Communications Manager SDL and SDI trace files.

                  The RSVP agent can send the following RSVP Reservation error codes:

                  • QOS_CAUSE_RESERVATION_TIMEOUT=0,
                  • QOS_CAUSE_PATH_FAIL,
                  • QOS_CAUSE_RESV_FAIL,
                  • QOS_CAUSE_LISTEN_FAIL,
                  • QOS_CAUSE_RESOURCE_UNAVAILABLE,
                  • QOS_CAUSE_LISTEN_TIMEOUT,
                  • QOS_CAUSE_RESV_RETRIES_FAIL,
                  • QOS_CAUSE_PATH_RETRIES_FAIL,
                  • QOS_CAUSE_RESV_PREEMPTION,
                  • QOS_CAUSE_PATH_PREEMPTION,
                  • QOS_CAUSE_RESV_MODIFY_FAIL,
                  • QOS_CAUSE_PATH_MODIFY_FAIL

                  Troubleshooting end-to-end RSVP

                  This section provides troubleshooting information for end-to-end RSVP. For more information about end-to-end RSVP, see the Use RSVP between clusters.

                  Table 3 Troubleshooting End-to-End RSVP

                  Problem

                  Recommended Action

                  After a tandem/remote transfer, the final call is no longer an end-to-end RSVP call.

                  In the transferring node, make sure that the RSVP policy is activated between locations to which the inbound and outbound SIP trunk is assigned.

                  When the call is put on hold, there is no end-to-end RSVP between the MOH server and a held party.

                  In the holding cluster, make sure that the MOH’s device pool has a MRGL that has the RSVP agents assigned. Also make sure RSVP policy is activated between locations to which the MOH server and SIP trunk are assigned.

                  When a device in campus (Hub_none location) makes or receives a call, there is no end-to-end RSVP.

                  Make sure that RSVP policy is activated between the Hub_none location and location to which the SIP trunk is assigned.

                  When a conference call gets invoked, there is no end-to-end RSVP between the conference bridge and remote conference participants.

                  In the cluster that invoked the conference call, make sure that the conference bridge’s device pool has a MRGL that has the RSVP agents assigned. Also make sure that RSVP policy is activated between locations to which the conference bridge and SIP trunks are assigned.

                  When a call gets blind transferred to a remote system, there is no end-to-end RSVP between the announciator and the calling phone.

                  In the transferring cluster, make sure that the annunciator’s device pool has a MRGL that has the RSVP agents assigned. Also make sure RSVP policy is activated between locations to which the annunciator and SIP trunks are assigned.

                  A basic end-to-end RSVP call fails.

                  Make sure that the RSVP policy has been activated between endpoint and trunk on both the clusters, and that the SIP profile for the inbound and outbound SIP trunk is configured to support end-to-end RSVP on both clusters.

                  End-to-end RSVP reservation fails.

                  A possible cause is that the same router is being used as the calling and called RSVP agents, and that router is not running the latest IOS version, which supports loopback on RSVP reservation. Make sure that the router is running the latest IOS version.