Call Admission Control (CAC) is an essential component of any IP telephony system that involves multiple sites connected through an IP WAN. In order to better understand what CAC does and why it is needed, consider the example in Figure 1.
Figure 1. Call Admission Control
As shown on the left side of Figure 1, traditional time-division multiplexing (TDM)-based private branch exchanges (PBXs) operate within circuit-switched networks, where a circuit is established each time a call is set up. As a consequence, when a traditional PBX is connected to the public switched telephone network (PSTN) or to another PBX, a certain number of physical trunks must be provisioned. When calls have to be set up to the PSTN or to another PBX, the PBX selects a trunk from those that are available. If no trunks are available, the call is rejected by the PBX and the caller hears a network-busy signal.
Now consider the IP telephony system shown on the right side of Figure 1. Because it is based on a packet-switched network (the IP network), no circuits are established to set up an IP telephony call. Instead, the IP packets containing the voice samples are simply routed across the IP network together with other types of data packets. Quality of service (QoS) is used to differentiate the voice packets from the data packets, but bandwidth resources, especially on IP WAN links, are not infinite. Therefore, network administrators dedicate a certain amount of "priority" bandwidth to voice traffic on each IP WAN link. However, when the provisioned bandwidth is fully used, the IP telephony system must reject subsequent calls to avoid oversubscription of the priority queue on the IP WAN link, causing quality degradation for all voice calls. Call Admission Control, then, helps guarantee good voice quality in a multisite deployment involving an IP WAN.
To preserve a satisfactory end-user experience, the CAC function should always be performed during the call setup phase so that if no network resources are available a message can be presented to the end user or the call can be rerouted across a different network (such as the PSTN).
Cisco RSVP Agent
Cisco® RSVP Agent provides CAC and QoS (Figure 2). With CAC, your network can accept or reject a call based on bandwidth and policy considerations. Resource Reservation Protocol (RSVP), an IETF standards-based signaling protocol for reserving resources in the IP network, secures and reserves bandwidth across the WAN for calls accepted by Cisco RSVP Agent. The resulting user experience is characterized by superior QoS and reliability for calls amid meshed and multitiered networks.
Figure 2. Cisco RSVP Agents
Call setup is initiated between the IP phone, IP videophone, or gateway; Cisco Unified Communications Manager classifies the call based on parameters such as application (voice or video) and Multilevel Precedence and Preemption (MLPP), and signals the classification to Cisco RSVP Agent in the access router. Bandwidth pools are preconfigured in the router on a per-application and per-interface basis. Using the classification provided by Cisco Unified Communications Manager, Cisco RSVP Agent attempts to set up a call within the appropriate bandwidth pool and across the WAN to a far-end Cisco RSVP Agent for the receiving party. If RSVP bandwidth is secured, Cisco RSVP Agent signals back to Cisco Unified Communications Manager, which in turn signals to the IP phone, IP videophone, or gateway and the call proceeds.
Cisco RSVP Agent can also apply differentiated-services-code-point (DSCP) marking to media packets based on instruction from Cisco Unified Communications Manager. DSCP packet marking may be applied to place the RSVP secured media stream into the router priority queue. If RSVP bandwidth cannot be secured, Cisco RSVP Agent signals back to Cisco Unified Communications Manager, which administers policies. The call is either disallowed or allowed to proceed with a lower-priority DSCP packet marking applied by Cisco RSVP Agent as instructed by the Cisco Unified Communications Manager. Mid-call policies may also be applied for handling of changes to the media stream such as transfers during a call.
Key Features and Benefits
Cisco RSVP Agent offers the following features and benefits:
• Complex network topologies: Cisco RSVP Agent provides CAC for complex and dynamically changing network topologies. Both the logical and physical network design for data, voice, and video can now be the same, simplifying deployments and reducing the cost for both infrastructure and management.
• Locations capability: You can enable and disable Cisco RSVP Agent functions based on location. This feature enables Cisco RSVP Agent to coexist with location-based CAC and eases migration to Cisco RSVP Agent implementations. Location awareness also allows you to choose whether or not to use Cisco RSVP Agent for local calls that do not cross the WAN.
• End-user device independence: Cisco RSVP Agent is managed and secured as part of the network and does not rely on end-user devices to secure CAC. This feature eliminates concerns of endpoint trust, and also preserves investment in existing phones.
• Call-signal independence: Cisco RSVP Agent supports calls made using Session Initiation Protocol (SIP), Skinny Client Control Protocol (SCCP), H.323, and Media Gateway Control Protocol (MGCP).
• Application ID: Cisco RSVP Agent allows you to establish separate bandwidth pools based on application. As a call is initiated, Cisco Unified Communications Manager assigns the call an application ID and signals this ID to the router. The call is then placed using the appropriate bandwidth pool. This feature helps ensure that a single application (such as video) does not overwhelm the available reserved bandwidth.
• Interface configuration: You can configure RSVP bandwidth pools on a per-interface level.
• Integration with Differentiated Services (DiffServ) QoS: RSVP is used to manage admission to a bandwidth pool. After admission, QoS parameters are applied to ensure prioritization of the admitted media flow. The Cisco RSVP Agent can provide DSCP marking to place the media packets into the priority queue. Cisco RSVP Agent also prevents media flows that fail admission from entering the priority queue.
• DSCP marking of media where RSVP is not secured: When an RSVP reservation cannot be secured, Cisco Unified Communications Manager policy determines whether or not the call is allowed to proceed. If the call is allowed to proceed, Cisco Unified Communications Manager can instruct Cisco RSVP Agent to mark the packets with a lower-priority (best-effort) DSCP label.
• New call policy: You have a choice of policies to configure in Cisco Unified Communications Manager; for example, you can require RSVP, or if RSVP cannot be secured to allow calls to proceed, you can use lower-priority (best-effort) DSCP packet marking. You can configure separate policies for audio and video.
• Mid-call policy: You can configure a separate set of policies in Cisco Unified Communications Manager to handle changes to the media stream during a call. Transfer, conference, MLPP preemption, and loss of a network connection are examples of when these policies become important.
• Retry reservation: Cisco Unified Communications Manager can instruct multiple retries to secure RSVP if RSVP is not initially secured. Retry reservation can be used in conjunction with both new-call and mid-call policies.
• PSTN failover: You can employ alternate automatic routing (AAR) to route calls over the PSTN when an RSVP secured connection cannot be obtained.
• Music on hold (MoH) and Annunciator: Cisco RSVP Agent support is extended to Cisco Unified Communications Manager MoH and Annunciator features.
• Shared-lines optimization: In the case of shared lines, only one RSVP connection is established to a site.
• Secure Real-Time Transport Protocol (SRTP): Cisco RSVP Agent supports secure media using SRTP.
• MLPP: Cisco RSVP Agent works in conjunction with MLPP to allow high-priority calls to take precedence and receive guaranteed bandwidth when needed.
• RSVP not required on every hop: Cisco RSVP Agent secures a reservation across the WAN. Routers along the media path that support RSVP provide a bandwidth guarantee. Routers along the path that do not have RSVP enabled (for example, in the network core) do not guarantee bandwidth but do pass the RSVP reservation. Therefore, Cisco RSVP Agent controls admittance to the network and secures bandwidth across elements of the network when necessary. You can design networks to implement RSVP at the edge and combine it with packet marking in the network core.
• Cisco Unified Border Element: Cisco RSVP Agent provides CAC for Cisco Unified Communications Manager intracluster calls. You can use the Cisco IP-to-IP Gateway to provide RSVP-based CAC for Cisco Unified Communications Manager intercluster calls. In addition, you can enable both Cisco RSVP Agent and Cisco IP-to-IP Gateway on either an Integrated Services Router platform or on the ASR platform.
• Trusted DSCP marking: Cisco RSVP Agent allows the network to mark media packets. End-user devices such as softphones, Cisco Unified Video Advantage, and SIP phones lack a trusted mechanism for ensuring appropriate DSCP priority. Cisco RSVP Agent provides a point of trust in the network and, when used with Cisco Unified Communications Manager, can assure media flows receive the desired QoS treatment. You can implement DSCP packet marking with other Cisco RSVP Agent functions or on its own.
The Cisco RSVP Agent registers with Cisco Unified Communications Manager as either a media termination point (MTP) or a transcoder device with RSVP support. When an endpoint device makes a call that needs a bandwidth reservation, Cisco Unified Communications Manager invokes a Cisco RSVP Agent to act as a proxy for the endpoint to make the bandwidth reservation.
Figure 3 shows the signaling protocols used between Cisco Unified Communications Manager and various other devices, as well as the associated Real-Time Transport Protocol (RTP) streams for calls across the WAN in a given location. For any calls across the WAN, Cisco Unified Communications Manager directs the endpoint devices to send the media streams to their local Cisco RSVP Agent, which originates another call leg synchronized with an RSVP reservation to the Cisco RSVP Agent at the remote location. Figure 3 illustrates the following signaling protocols:
• Cisco RSVP Agents register to Cisco Unified Communications Manager through SCCP.
• IP phones register with Cisco Unified Communications Manager through SCCP or SIP.
• PSTN gateways register with Cisco Unified Communications Manager through MGCP, SIP, or the H.323 protocol.
Figure 3. Protocol Flows for Locations with RSVP
Figure 4 shows a typical Cisco RSVP Agent deployment within a Cisco Unified Communications Manager cluster, which includes three locations: Central site, branch 1, and branch 2. The IP WAN connecting the three locations can be of any topology type and is not restricted to the hub-and-spoke topology. For any call between two locations that requires an RSVP reservation in the media path, Cisco Unified Communications Manager dynamically invokes a pair of Cisco RSVP Agents. The Cisco RSVP Agent acts as a proxy to make an RSVP reservation for the IP phone in the same location with the Cisco RSVP Agent. For example, when phone A in branch 1 calls phone E in the central site, an RSVP reservation (illustrated as the red line in Figure 4) is established between Cisco RSVP Agents in the branch 1 and central-site locations.
The media streams of this call have three call legs. The first call leg is between phone A and the branch 1 Cisco RSVP Agent, the second call leg is between the branch 1 and central-site Cisco RSVP Agents, and the third call leg is between the central-site Cisco RSVP Agent and phone E. Similarly, when phone B in branch 1 calls phone D in branch 2, the RSVP reservation is established between the branch 1 and branch 2 Cisco RSVP Agents. Note that the media streams of a call between two branch locations are not sent through the central site in this case -- a situation that is different from a call made over the traditional hub-and-spoke topology using CAC based on static locations.
Figure 4. RSVP Agent Call Flow
Cisco RSVP Precondition
At session establishment time, after the callee is alerted the chances of a session establishment failure are minimal. One source of failure is the inability to reserve network resources for a session. In order to minimize "ghost rings", network resources for the session must be reserved before the callee is alerted. However, the reservation of network resources frequently requires learning the IP address, port, and session parameters from the callee. This information is obtained as a result of the initial offer and answer exchange carried in SIP. This exchange normally causes the "phone to ring", thus introducing a "loop" dilemma: resources cannot be reserved without performing an initial offer and answer exchange, and the initial offer and answer exchange cannot be done without performing resource reservation.
The solution is to introduce the concept of a precondition, which is a set of constraints about the session that are introduced in the offer. The recipient of the offer generates an answer, but does not alert the user or otherwise proceed with session establishment. Proceeding occurs only when the preconditions are met. This knowledge can be obtained through a local event (such as a confirmation of a resource reservation), or through a new offer sent by the caller.
Figure 5. No RSVP over the Trunk
In order to ensure that session establishment does not take place until certain preconditions are met, we distinguish between two different state variables that affect a particular media stream: current status and desired status. The desired status consists of a threshold for the current status. Session establishment stops until the current status reaches or surpasses this threshold. When this threshold is reached or surpassed, session establishment resumes.
Cisco supports RSVP precondition for basic audio and video call and supplementary services on the Cisco IOS® SIP Gateway. It also supports RSVP on the Cisco IOS SIP Gateway to interwork with Cisco Unified Communications Manager and Cisco Unified Customer Voice Portal (CVP) for basic calls and supplementary services. Currently Cisco IOS SIP Gateway supports RSVP based on RFC 3312 end-to-end preconditions for basic audio call and mid-call bandwidth changes. Only end-to-end QoS (RSVP) precondition is supported; segmented precondition is not supported. (Note: Cisco Unified Communications Manager features are expected to be released in Version 8.0.)
Following are the RSVP scenarios that are supported on Cisco IOS SIP Gateway:
• Basic call with Cisco Unified Communications Manager, Cisco Unified CVP, and SIP Gateway
• Call hold initiated by Cisco Unified Communications Manager
• Call forward (call forward all [CFA], call forwarding busy [CFB], and call forwarding no answer [CFNA]) initiated by Cisco Unified Communications Manager
• Call transfer (blind and consult) initiated by Cisco Unified Communications Manager
• Conferencing initiated by Cisco Unified Communications Manager
• Call hold initiated by Cisco Unified Communications Manager Express with SCCP
• Call forward (CFA, CFB, and CFNA) initiated by Cisco Unified Communications Manager Express with SCCP
• Call transfer (blind and consult) initiated by Cisco Unified Communications Manager Express with SCCP
• Configurable RSVP Application ID
• Configurable policies for call treatment on RSVP failure
• RSVP support for basic video call
Figure 6 shows the deployment scenario that needs RSVP support for basic call and supplementary services. When calls are made between two call-control systems, RSVP is invoked over the SIP trunk.
Figure 6. RSVP over the SIP Trunk: End-to-End QoS RSVP Set Up Between a Cisco RSVP Agent and a Remote Endpoint
In the current release, the precondition feature is fully supported in call flows between Cisco Unified Communications Manager Express applications (Figure 7). The Cisco Unified Communications Manager support is expected to be released in Version 8.0.
Figure 7. RSVP Precondition over SIP Trunk
Handling Delayed Offer
The "precondition" tag can be mandatory or optional in a SIP call. On receiving the delayed offer INVITE during call setup, the Cisco IOS Gateway relies on the precondition tag in the "Supported" or "Require" header to determine whether or not the remote user authentication supports RSVP preconditions.
If the delayed offer INVITE contains the precondition tag in the Require header, the Cisco IOS Gateway assumes that the remote user authentication supports RSVP precondition and remote QoS strength is mandatory. So if the Cisco IOS Gateway supports RSVP precondition, it sends the offer in 183 with QoS precondition attributes. If the Cisco IOS Gateway does not support RSVP precondition and the incoming delayed offer INVITE has a precondition tag in the Require header, then the Cisco IOS Gateway responds with a "580 Precondition Failed" error response.
If the delayed offer INVITE contains a precondition tag in the Supported header only and not in the Require header, the Cisco IOS Gateway presumes that the remote user authentication supports RSVP precondition and that either remote QoS strength is optional or there is none. So if the Cisco IOS Gateway supports RSVP preconditions, it sends the offer in 183 with QoS precondition attributes. If the Cisco IOS Gateway does not support RSVP preconditions and the incoming delayed offer INVITE has a precondition tag in the Supported header only, then the Cisco IOS Gateway responds with offer in 183 without any QoS precondition attributes.
If mandatory QoS strength is configured on the Cisco IOS Gateway and the incoming delayed offer INVITE does not have a precondition tag in either the Supported or Require header, the Cisco IOS Gateway responds with "580 Precondition Failed".
Table 1 shows the proposed Cisco IOS Gateway behavior based on the precondition tag in the incoming delayed offer INVITE and local precondition configurations.
Table 1. Precondition Configuration on Cisco IOS Gateway
Precondition Tag in Incoming INVITE
Precondition Configuration on Cisco IOS Gateway
183 with QoS precond
183 with QoS precond
183 with QoS precond
183 with QoS precond
As you consider improving your voice-over-IP (VoIP) network, you should think about deploying RSVP in your unified communications solution. This technology can make your network more intelligent, efficient, flexible, and robust, and improve experiences for end users. It can help you converge video, voice, and data traffic to a single IP network.