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 growing size of a Cisco Unified Communications Manager cluster increases the need for an intracluster CAC solution.

The Quality of Service (QoS) baseline recommends that all VoIP and videoconferencing devices provide admission control by using RSVP.

Tip 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 “Internet Protocol Version 6 (IPv6)” in the Cisco Unified Communications Manager Features and Services Guide.

Tip 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 “Internet Protocol Version 6 (IPv6)” in the Cisco Unified Communications Manager Features and Services Guide.

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.

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 Capabilities

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.

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.

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.

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 “Internet Protocol Version 6 (IPv6)” in the Cisco Unified Communications Manager Features and Services Guide .

NoteRSVP does not conflict with Automated Alternate Routing (AAR), which continues to function if AAR is configured. See the RSVP does not conflict with Automated Alternate Routing (AAR), which continues to function if AAR is configured. See the “Automated Alternate Routing” section 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.

Why an Agent?

An agent provides a point of trust and eases migration to RSVP.

Figure 9-1 shows 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. See the following topics:

Tip The RSVP feature 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 “Internet Protocol Version 6 (IPv6)” in the Cisco Unified Communications Manager Features and Services Guide.

Clusterwide Default RSVP Policy

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

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:

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.

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.

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.

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.

NoteIn 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. 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.

Using 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.

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 “Gatekeepers and Trunks” section 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 .

For more information about SIP trunk configuration, see the “SIP Profile Configuration” chapter of the Cisco Unified Communications Manager Administration Guide .

Enabling RSVP for a Call

To enable RSVP for a call, follow these steps:

1. Assign the calling device and the called device to different locations.

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.”

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.

Migrating 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.

Example

The following steps show how to migrate the first location and hub to RSVP.

1. Install RSVP agent A at Location 1.

2. Install RSVP agent B at Location 0 (hub).

3. Add agent A to the Media Resource Group List of all endpoints at Location 1.

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.

5. Configure RSVP policy from Location 1 to all other locations to be Mandatory (or some other policy, if desired).

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 “Internet Protocol Version 6 (IPv6)” in the Cisco Unified Communications Manager Features and Services Guide .

RSVP and Shared-Line Calls

Figure 9-3 shows the RSVP interaction during the alerting phase of a shared-line call.

Figure 9-3 RSVP During a Shared--Line Call (Alerting Phase)

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

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 9-5 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 Figure 9-5, the MOH server resides in the same location as phone A.

Figure 9-5 Phone B Puts Phone A on Hold, MOH Server in 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 9-6 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 9-7 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.)

Figure 9-7 Phone B Puts Phone A on Hold, MOH Server in a Third 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

The following figures show RSVP interaction with a call-transfer scenario. Figure 9-8 shows the initial scenario, where phone A is in a call with phone B.

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 9-10 Call Transfer Completes, and Phone A and Phone C Get Connected

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.

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:

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.

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.