Configuring SIP RSVP Features
First Published: October 11, 2008
Last Updated: February 27, 2009
Cisco IOS software combines Session Initiation Protocol (SIP) with Resource Reservation Protocol (RSVP) to enhance RSVP Application ID support (RFC 2872) and RSVP precondition support (RFC 3312 and RFC 4032). The RSVP Preconditions for Audio on SIP-TDM Gateway and Cisco Unified Communications Manager Express (Cisco Unified CME) feature introduces application-specific reservations that enhance the granularity of local policy match criteria on Cisco IOS SIP devices. Additionally, this feature provides support for SIP audio RSVP preconditions for audio on both SIP time-division multiplexing (TDM) gateways and on SIP trunks for Skinny Client Control Protocol (SCCP) line-side Cisco Unified CME devices.
The RSVP Preconditions for Video Gateway feature expands existing support for SIP video calls on H.324-SIP video gateways to include H.320-SIP video gateways. Additionally, this feature adds support for SIP video RSVP preconditions for SIP video calls on both H.320-SIP and H.324-SIP video gateways.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for SIP RSVP Features" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS, Catalyst OS, and Cisco IOS XE software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•Prerequisites for SIP RSVP Features
•Restrictions for SIP RSVP Features
•Information About SIP RSVP Features
•How to Configure SIP RSVP Features
•Configuration Examples for SIP RSVP
•Additional References
•Feature Information for SIP RSVP Features
•Glossary
Prerequisites for SIP RSVP Features
You must configure RSVP on one or more interfaces on at least two neighboring routers that share a link within the network before you can configure RSVP application ID support for quality of service (QoS) management.
SIP time-division multiplexing (TDM) gateways already support RSVP preconditions based on RFC 3312 end-to-end preconditions for basic audio call and midcall bandwidth changes.
Restrictions for SIP RSVP Features
The following restrictions apply to RSVP features on SIP TDM gateways:
•Merging of global and interface-based local policies is not supported—you cannot match on multiple policies.
•RSVP is the only precondition-based QoS mechanism supported.
•Only end-to-end preconditions are supported and segmented preconditions are not supported.
•QoS strength must be the same (mandatory or optional) in both directions (SENDRECV).
•Midcall QoS negotiation does not use provisional responses as depicted in RFC examples.
•New session parameters (codec and remote address) are used immediately after OFFER/ANSWER during the midcall QoS negotiation even when strength is mandatory (see RFC 3312, Section 6).
•RSVP initiation is supported only for single stream.
Additionally, RSVP support is not available for the following features and devices:
•SIP call forking.
•H.323 gateways.
•Video supplementary services.
•Video calls on Cisco Unified Border Elements.
•Video calls on Cisco Unified CME.
•Video calls connected to Cisco Unified Communications Manager or any third-party endpoints.
•H.320, H.323, and H.324 audio-only calls.
•Basic video call escalations and de-escalations.
Information About SIP RSVP Features
The information in this section focuses primarily on RSVP preconditions for SIP. It includes information about support for SIP RSVP audio requests issued from Cisco Unified CME and SIP TDM gateways and about support for SIP video calls on H.320-SIP and H.324-SIP video gateways. The RSVP Preconditions for Audio on SIP-TDM Gateway and Cisco Unified Communications Manager Express feature is available only on supported devices that are running Cisco IOS Release 12.4(22)T or later releases and the RSVP Preconditions for Video Gateway feature is available only on supported devices running Cisco IOS Release 12.4(24)T or later releases. For more information about the RSVP Applications ID feature, see the "Configuring RSVP" module in the subsections about RSVP in the "Signalling" part in the Cisco IOS Quality of Service Solutions Configuration Guide.
Before configuring SIP RSVP application ID support or SIP RSVP preconditions on a SIP TDM gateway or Cisco Unified CME, you should understand the following concepts:
•RSVP Bandwidth Limits
•RSVP Preconditions
•Global and Per-Interface RSVP Policies
•RSVP Policy Applications
•Preemption and Defending Priorities
•Supported SIP RSVP Implementations and Functions
RSVP Bandwidth Limits
Multiple applications, such as voice and video, need RSVP support. In Cisco IOS software, RSVP can process and accept requests by referring to multiple bandwidth pools that are based on application IDs and configured RSVP local policies. These pools specify which applications are allowed and how much bandwidth can be reserved for each until specified bandwidth limits are reached.
When there is limited or no available bandwidth remaining, RSVP rejects requests that are not configured and prioritized in the bandwidth pools. For example, if video calls are configured in a pool but voice calls are not, just a few video calls could prevent most, maybe all, voice calls from being established—the video calls require such a large amount of bandwidth that there may not be enough bandwidth remaining. Such behavior could prevent deployment of RSVP for multiple applications, not just voice, when video is one of the applications for which RSVP is required.
To prevent one application type from consuming all bandwidth, RFC 2872, Application and Sub Application Identity Policy Element for Use with RSVP, allows for creation of separate bandwidth reservation pools. For example, an RSVP reservation pool can be created for voice traffic and another for video traffic so that reservations tagged with these application IDs can then be matched to the interface bandwidth pools using RSVP local policies. To limit bandwidth per application, though, you must configure a bandwidth limit for each application and configure each with a reservation flag that associates the application with the appropriate bandwidth limit.
RSVP Preconditions
Information about RSVP preconditions for SIP calls is provided in the following sections:
•SIP Audio RSVP Preconditions
•SIP Video RSVP Preconditions
SIP Audio RSVP Preconditions
The RSVP Preconditions for Audio on SIP-TDM Gateway and Cisco Unified CME feature enables configuration of RSVP as a precondition for establishment of SIP sessions initiated on a SIP gateway or a Cisco Unified CME SIP trunk. To enforce RSVP limitations, both endpoints must be configured to accept and support RSVP connections. Once configured, RSVP precondition support allows you to ensure support of RSVP application IDs on a SIP TDM gateway by requiring that the participant reserve network resources before continuing with the session.
RSVP support on Cisco IOS SIP gateways includes support for call hold, call forward, call transfer, and shared line features. This implementation uses a SIP header precondition option tag that enables synchronization of call control with the RSVP layer.
The RSVP Preconditions for Audio on SIP-TDM Gateway and Cisco Unified CME feature enhances RSVP support on Cisco IOS SIP gateways to handle the reINVITE and REFER/302-based supplementary services initiated by Cisco IOS SIP-TDM gateways.
SIP Video RSVP Preconditions
The RSVP Preconditions for Video Gateway feature expands existing support for SIP video calls on H.324-SIP video gateways to include H.320-SIP video gateways. Additionally, this feature adds support for SIP video RSVP preconditions for SIP video calls on both H.320-SIP and H.324-SIP video gateways. However, there are significant differences in the bandwidth reservation attributes for each of these gateways.
Bandwidth Reservations for H.320 Video Gateways
•An H.320 call can occupy up to 16 B channels (determined by the max-bandwidth configuration on the POTS dial peer.)
•During precondition negotiation, 64 KB/s plus 20 percent overhead is reserved for the audio stream and the configured max-bandwidth amount (plus 20 percent overhead) is reserved for the video stream.
•Once the call is established, if the negotiated audio codec requires less than 64 KB/s, excess audio bandwidth is released. Additionally, the required video bandwidth is determined (the configured max-bandwidth setting minus the audio bandwidth) and excess video bandwidth is released.
Bandwidth Reservations for H.324 Video Gateways
•An H.324 call occupies only one B channel.
•The audio bandwidth will be either 12.2 KB/s for the adaptive multirate (AMR) codec or 64 KB/s for the G.711 codec. The H.324 codec is always AMR so if the audio codec on the SIP side is G.711, then the digital signal processor (DSP) will perform transcoding between the two.
•The video bandwidth will always be 50 KB/s (64 KB/s minus 12.2 KB/s).
•As with H.320 calls, during precondition negotiation, 64 KB/s plus 20 percent overhead is reserved for the audio stream. But for H.324 calls, bandwidth reserved for video will always be 64 KB/s (plus 20 percent overhead).
•Once the call is established and the audio codec is negotiated, excess bandwidth is released, which results in 50 KB/s reserved bandwidth for video and 64 KB/s or 12.2 KB/s (depending on the negotiated codec) reserved for audio.
Global and Per-Interface RSVP Policies
You can configure RSVP policies globally and on a per-interface basis. You can also configure multiple global policies and multiple policies per interface.
Global RSVP policies restrict how much RSVP bandwidth a router uses regardless of the number of interfaces. You should configure a global policy if your router has CPU restrictions, one interface, or multiple interfaces that do not require different bandwidth limits.
Per-interface RSVP policies allow you to configure separate bandwidth pools with varying limits so that no one application, such as video, can consume all the RSVP bandwidth on a specified interface at the expense of other applications, such as voice, which would be dropped. You should configure a per-interface policy when you need greater control of the available bandwidth.
RSVP Policy Applications
RSVP searches for policies whenever an RSVP message is processed. The policy tells RSVP if any special handling is required for that message.
If your network configuration has global and per-interface RSVP policies, the per-interface policies are applied first meaning that RSVP looks for policy-match criteria in the order in which the policies were configured. RSVP searches for policy-match criteria in the following order:
•Nondefault interface policies
•Default interface policy
•Nondefault global policies
•Global default policy
If RSVP finds no policy-match criteria, it accepts all incoming messages. To change this decision from accept to reject, issue the ip rsvp policy default-reject command.
Preemption and Defending Priorities
Preemption happens when one reservation receives priority over another because there is insufficient bandwidth in an RSVP pool. General information about preemption behavior and configuration is provided in the following sections:
•Preemption Behavior Overview
•Preemption Priority Signaling
•Preemption Behavior Configuration
Preemption Behavior Overview
There are two types of RSVP bandwidth pools: local policy pools and interface pools. Local policies can be global or interface-specific. RSVP performs admission control against these pools when a RESV message arrives.
If an incoming reservation request matches an RSVP local policy with an RSVP bandwidth limit that has already been reached, RSVP tries to preempt lower-priority reservations that were admitted by that policy. If there are not enough lower-priority reservations that can be preempted to make room for the incoming higher priority request, then RSVP rejects it. If there are enough lower-priority reservations that can be preempted to make room for the new call, then RSVP continues the reservation process by next checking the interface bandwidth pool to determine if bandwidth is available on the interface.
If the interface bandwidth pool limit has been reached, then RSVP tries to preempt lower-priority reservations on that interface to accommodate the new reservation request. However, RSVP does not take into account which local policies admitted the reservations—if there is not enough bandwidth on the interface bandwidth pool that can be preempted to make room for the new call, RSVP rejects the new reservation even though the new reservation was able to obtain bandwidth from the local policy pool.
Preemption can also happen when you manually reconfigure an RSVP bandwidth pool of any type to a lower value such that the existing reservations using that pool no longer fit in the pool. Assigning preemption and defending priority values allows reservations to register with those values and preempt or avoid preemption when competing with other reservations for available bandwidth.
Preemption Priority Signaling
If a received RSVP PATH or RESV message does not contain preemption priorities, the ip rsvp policy preempt command is enabled globally, and the message matches a local policy that contains an ip qos preemption-priority command, then a POLICY_DATA object with a preemption priority element that contains the local policy's priorities is added to the message as part of the policy decision. These priorities are stored with the RSVP state in the router and forwarded to neighbors.
Preemption Behavior Configuration
The ip rsvp policy preempt command controls whether or not a router preempts any reservations when required. When you issue this command, a RESV message that subsequently arrives on an interface can preempt the bandwidth of one or more reservations on that interface if the assigned setup priority of the new reservation is higher than the assigned hold priorities of the installed reservations.
Additionally, you can use the ip qos defending-priority and ip qos preemption-priority commands in dial peer VoIP configuration mode to configure the RSVP defending and preemption priority values, respectively, for more specific configuration of QoS behavior.
Supported SIP RSVP Implementations and Functions
The Cisco IOS Audio RSVP Preconditions feature also adds RSVP support on the SIP trunk of SCCP line-side Cisco Unified CME devices. The following RSVP scenarios are supported on SIP-TDM gateways and on the SIP trunk of SCCP line-side Cisco Unified CME devices for audio calls:
•Basic call with SCCP-Cisco Unified CME and Cisco IOS SIP TDM gateways
•SCCP-Cisco Unified CME and Cisco IOS SIP-TDM gateway initiated call hold, call forward, and call transfer (blind and consult).
The feature also provides support for the functions described in the following sections:
•Configurable RSVP Application ID
•Call Treatment Policies on Reservation Failures
•Configurable DSCP Values Based on No RSVP, RSVP Success, and RSVP Failure
Configurable RSVP Application ID
Prior to Cisco IOS Release 12.4(22)T, Cisco IOS SIP implementations did not pass any RSVP application information to the QoS module. Since then, a command was added in dial peer VoIP configuration mode so that Cisco IOS devices running Cisco IOS release 12.4(22)T and later can be configured to pass RSVP application IDs to the QoS module while requesting RSVP for audio and video streams.
Call Treatment Policies on Reservation Failures
A reservation failure could happen during the initial RSVP establishment attempt, during subsequent RSVP rereservation attempts (such as for a session target change), or during the tear-down of an established RSVP session. Regardless at which of these points the failure occurs, RSVP failure policies are applied. For pre-alert calls, refer to the default policy described in RFC 3312. For post-alert calls, locally configured RSVP failure policies can be applied using the voice-class sip rsvp-fail-policy command in dial peer VoIP configuration mode.
The strength of local RSVP failure policies can be configured as either "mandatory" or "optional" with the following options:
•Strength configured as optional—The failure policy specifies only the interval at which the RSVP reservation is retried (the interval setting can be configured as "infinity," which specifies no retries).
•Strength configured as mandatory—The failure policy determines both the interval at which the RSVP reservation is retried ("infinite," or no retries is an option) and the number of retries attempted before the call is disconnected. When appropriate, the number of retries for a failure policy with a mandatory strength setting can be configured as "infinity," which specifies that the call is not to be disconnected upon failure.
Configurable DSCP Values Based on No RSVP, RSVP Success, and RSVP Failure
In releases prior to Cisco IOS Release 12.4(22)T, there existed a command (the ip qos dscp command in dial peer VoIP configuration mode) for assigning a different DSCP value for video packets according to three different RSVP scenarios: when RSVP is disabled, when it is successful, and when it fails. But only one DSCP value could be configured for audio packets regardless of the RSVP scenario.
In Cisco IOS Release 12.4(22)T and later releases, the ip qos dscp command includes a modification that makes it possible to configure different DSCP values for audio packets that are also specific to the the three different RSVP scenarios (disabled, successful, and failed). With this command, a unique DSCP value can be configured and sent to the RTP library for each RSVP status for both video and audio packets according to the RSVP status.
How to Configure SIP RSVP Features
This section contains the following procedures:
•Configuring SIP RSVP Application ID Support (required)
•Configuring SIP RSVP Bandwidth Reservation (required)
•Configuring SIP RSVP Preconditions (required)
Configuring SIP RSVP Application ID Support
Perform the tasks in this section to configure SIP RSVP application IDs, defending priority settings, and, if needed, preemption priority settings:
•Configuring Application Identities for SIP Audio RSVP Preconditions (required)
•Configuring Defending Priority for RSVP (required)
•Configuring Preemption Priority for RSVP (optional)
Configuring Application Identities for SIP Audio RSVP Preconditions
Perform this task to configure application identities for specifying SIP audio RSVP preconditions. (This task does not apply to video calls. The default policy will apply for video.)
SUMMARY STEPS
1. enable
2. configure terminal
3. dial-peer voice tag voip
4. ip qos policy-locator {video | voice}
[app app-string] [guid guid-string]
[sapp subapp-string] [ver version-string]
DETAILED STEPS
|
|
|
Step 1 |
enable
Router> enable |
Enables privileged EXEC mode. •Enter your password if prompted. |
Step 2 |
configure terminal
Router# configure terminal |
Enters global configuration mode. |
Step 3 |
dial-peer voice tag voip
Router(config)# dial-peer voice 1 voip |
Enters dial peer VoIP configuration mode from global configuration mode. |
Step 4 |
ip qos policy-locator {video | voice} [app app-string] [guid guid-string] [sapp subapp-string] [ver version-string]
Router(config-dial-peer)# ip qos policy-locator voice app CISCO guid aaa sapp bbb ver ccc |
Configures application IDs. |
Configuring Defending Priority for RSVP
Perform this task to configure the defending priority of RSVP reservations.
SUMMARY STEPS
1. enable
2. configure terminal
3. dial-peer voice tag voip
4. ip qos defending-priority defending-pri-value
DETAILED STEPS
|
|
|
Step 1 |
enable
Router> enable |
Enables privileged EXEC mode. •Enter your password if prompted. |
Step 2 |
configure terminal
Router# configure terminal |
Enters global configuration mode. |
Step 3 |
dial-peer voice tag voip
Router(config)# dial-peer voice 1 voip |
Enters dial peer VoIP configuration mode from global configuration mode. |
Step 4 |
ip qos defending-priority defending-pri-value
Router(config-dial-peer)# ip qos defending-priority 65 |
Configures the RSVP defending priority. |
Configuring Preemption Priority for RSVP
Perform this task to configure the preemption priority of RSVP reservations.
SUMMARY STEPS
1. enable
2. configure terminal
3. dial-peer voice tag voip
4. ip qos preemption-priority preemption-pri-value
DETAILED STEPS
|
|
|
Step 1 |
enable
Router> enable |
Enables privileged EXEC mode. •Enter your password if prompted. |
Step 2 |
configure terminal
Router# configure terminal |
Enters global configuration mode. |
Step 3 |
dial-peer voice tag voip
Router(config)# dial-peer voice 1 voip |
Enters dial peer VoIP configuration mode from global configuration mode. |
Step 4 |
ip qos preemption-priority preemption-pri-value
Router(config-dial-peer)# ip qos preemption-priority 45 |
Configures the RSVP preemption policy and defending priority. |
Configuring SIP RSVP Bandwidth Reservation
Perform the tasks in this section to configure RSVP bandwidth reservation settings for use with the SIP RSVP Preconditions feature:
•Configuring RSVP Bandwidth Reservations on an Interface (required)
•Setting Bearer Capability for an H.320 Dial Peer (optional)
Configuring RSVP Bandwidth Reservations on an Interface
Perform this task to configure RSVP bandwidth reservations on an interface.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip rsvp bandwidth [interface-kbps] [single-flow-kbps] [rdm kbps {subpool kbps | bc1 subpool} | mam max-reservable-bw kbps bc0 kbps bc1 kbps]
DETAILED STEPS
|
|
|
Step 1 |
enable
Router> enable |
Enables privileged EXEC mode. •Enter your password if prompted. |
Step 2 |
configure terminal
Router# configure terminal |
Enters global configuration mode. |
Step 3 |
interface type number
Router(config)# interface FastEthernet 0/1 |
Specifies an interface and enters interface configuration mode. |
Step 4 |
ip rsvp bandwidth [interface-kbps] [single-flow-kbps] [rdm kbps {subpool kbps | bc1 subpool} | mam max-reservable-bw kbps bc0 kbps bc1 kbps]
Router(config-if)# ip rsvp bandwidth 1158 100 |
Configures bandwidth reservations for RSVP on an interface. |
Setting Bearer Capability for an H.320 Dial Peer
Perform this task to configure the bearer capability setting, which enables support of unrestricted digital media on an H.320 dial peer.
Note This task is required for H.320-SIP calls. It is not required for H.324-SIP calls or for RSVP specifically but it must be configured before using RSVP preconditions on an H.320 dial peer.
SUMMARY STEPS
1. enable
2. configure terminal
3. dial-peer voice tag voip
4. voice-class sip calltype-video
DETAILED STEPS
|
|
|
Step 1 |
enable
Router> enable |
Enables privileged EXEC mode. •Enter your password if prompted. |
Step 2 |
configure terminal
Router# configure terminal |
Enters global configuration mode. |
Step 3 |
dial-peer voice tag voip
Router(config)# dial-peer voice 1 voip |
Enters dial peer VoIP configuration mode. |
Step 4 |
voice-class sip calltype-video
Router(config-dial-peer)# voice-class sip calltype-video |
Configures the bearer capability setting on an H.320 dial peer to support unrestricted digital media. |
Configuring SIP RSVP Preconditions
Perform the tasks in this section to configure the SIP RSVP Preconditions feature on a SIP TDM gateway or Cisco Unified CME:
•Configuring RSVP Failure Policies for SIP Audio RSVP Preconditions (required for audio only)
•Configuring DSCP Identity (required)
Configuring RSVP Failure Policies for SIP Audio RSVP Preconditions
Perform this task to configure RSVP failure policies for SIP audio RSVP preconditions. (This task does not apply to video calls. Due to the bandwidth calculation algorithm, there is no RSVP failures post alert for video.)
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip rsvp bandwidth [interface-kbps] [single-flow-kbps] [rdm kbps {subpool kbps | bc1 subpool} | mam max-reservable-bw kbps bc0 kbps bc1 kbps]
5. exit
6. dial-peer voice tag voip
7. req-qos {best-effort | controlled-load | guaranteed-delay} [{audio bandwidth | video bandwidth} default | max bandwidth-value]
8. acc-qos {best-effort | controlled-load | guaranteed-delay} [audio | video]
9. voice-class sip rsvp-fail-policy {video | voice} post-alert {optional keep-alive | mandatory {keep-alive | disconnect retry retry-attempts}} interval retry-interval
DETAILED STEPS
|
|
|
Step 1 |
enable
Router> enable |
Enables privileged EXEC mode. •Enter your password if prompted. |
Step 2 |
configure terminal
Router# configure terminal |
Enters global configuration mode. |
Step 3 |
interface type number
Router(config)# interface FastEthernet 0 |
Specifies an interface and enters interface configuration mode. |
Step 4 |
ip rsvp bandwidth [interface-kbps] [single-flow-kbps] [rdm kbps {subpool kbps | bc1 subpool} | mam max-reservable-bw kbps bc0 kbps bc1 kbps]
Router(config-if)# ip rsvp bandwidth 85 85 |
Enables RSVP for IP on the specified interface. |
Step 5 |
exit
Router(config-if)# exit |
Exits interface configuration mode and returns to global configuration mode. |
Step 6 |
dial-peer voice tag voip
Router(config)# dial-peer voice 1 voip |
Enters dial peer VoIP configuration mode from global configuration mode. |
Step 7 |
req-qos {best-effort | controlled-load | guaranteed-delay} [{audio bandwidth | video bandwidth} default | max bandwidth-value]
Router(config)# req-qos controlled-load |
Specifies the desired quality of service to be used in reaching a specified VoIP dial peer. |
Step 8 |
acc-qos {best-effort | controlled-load | guaranteed-delay} [audio | video]
Router(config)# acc-qos controlled-load |
Defines the acceptable QoS for any inbound and outbound call on a VoIP dial peer. |
Step 9 |
voice-class sip rsvp-fail-policy {video | voice} post-alert {optional keep-alive | mandatory {keep-alive | disconnect retry retry-attempts}} interval retry-interval
Router(config-dial-peer)# voice-class sip rsvp-fail-policy voice post-alert optional keep-alive interval 60 |
Configures RSVP failure policies. |
Configuring DSCP Identity
Perform this task to configure the DSCP identity.
SUMMARY STEPS
1. enable
2. configure terminal
3. dial-peer voice tag voip
4. ip qos dscp {dscp-value | set-af | set-cs | default | ef} {signaling | media [rsvp-pass | rsvp-fail] | video [rsvp-none | rsvp-pass | rsvp-fail]}
DETAILED STEPS
|
|
|
Step 1 |
enable
Router> enable |
Enables privileged EXEC mode. •Enter your password if prompted. |
Step 2 |
configure terminal
Router# configure terminal |
Enters global configuration mode. |
Step 3 |
dial-peer voice tag voip
Router(config)# dial-peer voice 1 voip |
Enters dial peer VoIP configuration mode from global configuration mode. |
Step 4 |
ip qos dscp {dscp-value | set-af | set-cs | default | ef} {signaling | media [rsvp-pass | rsvp-fail] | video [rsvp-none | rsvp-pass | rsvp-fail]}
Router(config-dial-peer)# ip qos dscp 12 media rsvp-pass |
Configures the DSCP identity. |
Configuration Examples for SIP RSVP
This section provides the following configuration example:
•SIP Audio RSVP Preconditions on a SIP Gateway: Example
•SIP Video RSVP Preconditions on an H.320-SIP Gateway: Example
•SIP Video RSVP Preconditions on an H.324-SIP Gateway: Example
•RSVP Preconditions Behavior Verification in SIP Calls: Example
SIP Audio RSVP Preconditions on a SIP Gateway: Example
The following example shows how to configure SIP audio RSVP preconditions for audio calls on a SIP-TDM gateway:
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
no network-clock-participate slot 2
multilink bundle-name authenticated
codec preference 1 g711alaw
codec preference 2 g729r8
codec preference 3 g729br8
interface GigabitEthernet0/0
interface GigabitEthernet0/1
ip address 172.25.19.72 255.255.255.0
ip route 0.0.0.0 0.0.0.0 172.25.19.1
voice-class sip rsvp-fail-policy audio post-alert optional keep-alive interval 60
voice-class sip rsvp-fail-policy audio post-alert mandatory disconnect retry 2 interval 30
interval 60
session target ipv4:172.25.19.71
incoming called-number 1001
ip qos defending-priority 65534
ip qos preemption-priority 45
session target ipv4:172.25.19.73
ip qos defending-priority 65
session target ipv4:172.25.19.74
ip qos dscp af21 media rsvp-fail
ip qos dscp af21 media rsvp-pass
session target ipv4:172.25.19.3
alias exec sdp show running-config | sec dial-peer
scheduler allocate 20000 1000
SIP Video RSVP Preconditions on an H.320-SIP Gateway: Example
The following example shows how to configure SIP video RSVP preconditions for video calls on an H.320-SIP video gateway:
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
isdn switch-type primary-ni
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
voice class called number pool 100
index 1 5551005 - 5551015
voice class called number pool 7002
interface GigabitEthernet0/1
ip address 172.25.19.72 255.255.255.0
ip rsvp bandwidth 400 400
isdn switch-type primary-ni
isdn protocol-emulate network
isdn integrate calltype all
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1
voice-class called-number-pool 100
description INCOMING DP FOR 8000
incoming called-number 800
description OUTGOING DP FOR 8000
voice-class sip rel1xx require "100rel"
session target ipv4:172.25.19.77
req-qos controlled-load audio
req-qos controlled-load video
acc-qos controlled-load audio
acc-qos controlled-load video
scheduler allocate 20000 1000
SIP Video RSVP Preconditions on an H.324-SIP Gateway: Example
The following example shows how to configure SIP video RSVP preconditions for video calls on an H.324-SIP video gateway:
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
logging message-counter syslog
multilink bundle-name authenticated
isdn switch-type primary-ni
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
codec preference 1 g711ulaw
codec preference 1 g711ulaw
license feature gsmamrnb-codec-pack
interface GigabitEthernet0/0
ip address 172.25.19.37 255.255.0.0
ip rsvp bandwidth 1000 1000
interface GigabitEthernet0/1
isdn switch-type primary-ni
isdn protocol-emulate network
ip default-gateway 172.25.1.1
ip route 0.0.0.0 0.0.0.0 172.25.1.1
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0
voice-class sip rel1xx require "100rel"
voice-class sip calltype-video
session target ipv4:172.25.19.5
incoming called-number 8000
req-qos controlled-load audio
req-qos controlled-load video
acc-qos controlled-load audio
acc-qos controlled-load video
ss7 mtp2-variant Company 0
ss7 mtp2-variant Company 1
ss7 mtp2-variant Company 2
ss7 mtp2-variant Company 3
exception data-corruption buffer truncate
RSVP Preconditions Behavior Verification in SIP Calls: Example
The following is sample output from the show sip-ua calls command to verify RSVP preconditions settings and behavior when mandatory QoS is configured at both endpoints and RSVP has succeeded:
Router# show sip-ua calls
Number of SIP User Agent Client(UAC) calls: 0
SIP Call ID : F31FEA20-CFF411DC-8068DDB4-22C622B8@172.18.19.73
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Bit Flags : 0x8C4401E 0x100 0x4
Source IP Address (Sig ): 172.18.19.72
Destn SIP Req Addr:Port : 172.18.19.73:5060
Destn SIP Resp Addr:Port: 172.18.19.73:64440
Destination Name : 172.18.19.73
Number of Media Streams : 1
Number of Active Streams: 1
Media Mode : flow-through
State of the stream : STREAM_ACTIVE
Stream Type : voice-only (0)
Negotiated Codec : g711ulaw (160 bytes)
Negotiated Dtmf-relay : inband-voice
Dtmf-relay Payload Type : 0
Media Source IP Addr:Port: 172.18.19.72:18542
Media Dest IP Addr:Port : 172.18.19.73:16912
Orig Media Dest IP Addr:Port : 0.0.0.0:0
Local QoS Strength : Mandatory
Negotiated QoS Strength : Mandatory
Negotiated QoS Direction : SendRecv
Local QoS Status : Success
Options-Ping ENABLED:NO ACTIVE:NO
Number of SIP User Agent Server(UAS) calls: 1
The following is sample output from the show sip-ua calls command to verify RSVP preconditions settings and behavior when optional QoS is configured at both endpoints and RSVP has succeeded:
Router# show sip-ua calls
Number of SIP User Agent Client(UAC) calls: 0
SIP Call ID : 867EA226-D01311DC-8041CA97-F9A5F4F1@172.18.19.73
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Bit Flags : 0x8C4401E 0x100 0x4
Source IP Address (Sig ): 172.18.19.72
Destn SIP Req Addr:Port : 172.18.19.73:5060
Destn SIP Resp Addr:Port: 172.18.19.73:25055
Destination Name : 172.18.19.73
Number of Media Streams : 1
Number of Active Streams: 1
Media Mode : flow-through
State of the stream : STREAM_ACTIVE
Stream Type : voice-only (0)
Negotiated Codec : g711ulaw (160 bytes)
Negotiated Dtmf-relay : inband-voice
Dtmf-relay Payload Type : 0
Media Source IP Addr:Port: 172.18.19.72:17556
Media Dest IP Addr:Port : 172.18.19.73:17966
Orig Media Dest IP Addr:Port : 0.0.0.0:0
Local QoS Strength : Optional
Negotiated QoS Strength : Optional
Negotiated QoS Direction : SendRecv
Local QoS Status : Success
Options-Ping ENABLED:NO ACTIVE:NO
Number of SIP User Agent Server(UAS) calls: 1
The following is sample output from the show sip-ua calls command to verify RSVP preconditions settings and behavior when optional QoS is configured at both endpoints and RSVP has failed:
Router# show sip-ua calls
Number of SIP User Agent Client(UAC) calls: 0
SIP Call ID : 867EA226-D01311DC-8041CA97-F9A5F4F1@172.18.19.73
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Bit Flags : 0x8C4401E 0x100 0x4
Source IP Address (Sig ): 172.18.19.72
Destn SIP Req Addr:Port : 172.18.19.73:5060
Destn SIP Resp Addr:Port: 172.18.19.73:25055
Destination Name : 172.18.19.73
Number of Media Streams : 1
Number of Active Streams: 1
Media Mode : flow-through
State of the stream : STREAM_ACTIVE
Stream Type : voice-only (0)
Negotiated Codec : g711ulaw (160 bytes)
Negotiated Dtmf-relay : inband-voice
Dtmf-relay Payload Type : 0
Media Source IP Addr:Port: 172.18.19.72:17556
Media Dest IP Addr:Port : 172.18.19.73:17966
Orig Media Dest IP Addr:Port : 0.0.0.0:0
Local QoS Strength : Optional
Negotiated QoS Strength : Optional
Negotiated QoS Direction : SendRecv
Options-Ping ENABLED:NO ACTIVE:NO
Number of SIP User Agent Server(UAS) calls: 1
The following is sample output from the show sip-ua calls command on the originating gateway (OGW) to verify RSVP preconditions settings and behavior when optional QoS is configured on the OGW, mandatory QoS is configured on the terminating gateway (TGW), and RSVP has succeeded:
Router# show sip-ua calls
Number of SIP User Agent Client(UAC) calls: 0
SIP Call ID : 867EA226-D01311DC-8041CA97-F9A5F4F1@172.18.19.73
State of the call : STATE_ACTIVE (7)
Substate of the call : SUBSTATE_NONE (0)
Bit Flags : 0x8C4401E 0x100 0x4
Source IP Address (Sig ): 172.18.19.72
Destn SIP Req Addr:Port : 172.18.19.73:5060
Destn SIP Resp Addr:Port: 172.18.19.73:25055
Destination Name : 172.18.19.73
Number of Media Streams : 1
Number of Active Streams: 1
Media Mode : flow-through
State of the stream : STREAM_ACTIVE
Stream Type : voice-only (0)
Negotiated Codec : g711ulaw (160 bytes)
Negotiated Dtmf-relay : inband-voice
Dtmf-relay Payload Type : 0
Media Source IP Addr:Port: 172.18.19.72:17556
Media Dest IP Addr:Port : 172.18.19.73:17966
Orig Media Dest IP Addr:Port : 0.0.0.0:0
Local QoS Strength : Optional
Negotiated QoS Strength : Mandatory
Negotiated QoS Direction : SendRecv
Local QoS Status : Success
Options-Ping ENABLED:NO ACTIVE:NO
Number of SIP User Agent Server(UAS) calls: 1
Additional References
The following sections provide references related to SIP RSVP preconditions on SIP TDM gateways and Cisco Unified CME.
Related Documents
Standards
MIBs
|
|
None |
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: http://www.cisco.com/go/mibs |
RFCs
Technical Assistance
|
|
The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website requires a Cisco.com user ID and password. |
http://www.cisco.com/techsupport |
Feature Information for SIP RSVP Features
Table 1 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.
Table 1 Feature Information for SIP RSVP Features
|
|
|
RSVP Application ID Support |
12.2(33)SRB 12.4(6)T 12.4(22)T |
The RSVP Application ID Support feature was introduced in Cisco IOS Release 12.2(33)SRB (and later integrated into Cisco IOS Release 12.4(6)T) to support application-specific reservations, which enhance the granularity for local policy-match criteria so that you can manage QoS on the basis of application type. To accommodate the RSVP Preconditions for Audio on SIP-TDM Gateway and Cisco Unified Communications Manager Express feature, the RSVP Application ID Support feature was modified in Cisco IOS Release 12.4(22)T. Detailed information for this feature is provided in the following section: •Configuring SIP RSVP Application ID Support For more information, see the "Configuring RSVP" module in the subsections about RSVP in the "Signalling" part in the Cisco IOS Quality of Service Solutions Configuration Guide. The following commands were introduced or modified: ip qos defending-priority, ip qos policy-locator, ip qos preemption-priority. |
RSVP Preconditions for Audio on SIP-TDM Gateway and Cisco Unified Communications Manager Express |
12.4(22)T |
The RSVP Preconditions for Audio on SIP-TDM Gateway and Cisco Unified Communications Manager Express feature enables SIP RSVP as a precondition for establishment of SIP calls on SIP-TDM gateways and Cisco Unified CME, enabling interoperability with both Cisco Unified CM and Cisco Unified CVP. Detailed information is provided in the following section: •Configuring SIP RSVP Preconditions The following commands were introduced or modified: handle-replaces, ip qos dscp, show sip-ua calls, voice-class sip rsvp-fail-policy. |
RSVP Preconditions for Video Gateway |
12.4(24)T |
The RSVP Preconditions for Video Gateway feature expands existing support for SIP video calls on H.324-SIP video gateways to include H.320-SIP video gateways. Additionally, this feature adds support for SIP video RSVP preconditions for SIP video calls on both H.320-SIP and H.324-SIP video gateways. Detailed information is provided in the following section: •Configuring SIP RSVP Preconditions The following command was introduced: voice-class sip calltype-video. |
Glossary
CAC—Call Admission Control.
CME—Communications Manager Express.
CVP—Customer Voice Portal.
GW—gateway.
mline—The media-level section of an SDP session begins and ends with an "m" line that confines the information about the media stream.
MOH—Music on Hold.
QoS—quality of service.
RSVP—Resource Reservation Protocol.
SDP—Session Description Protocol.
SIP—Session Initiation Protocol.
TDM—time-division multiplexing.
UA—user agent.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2008-2009 Cisco Systems, Inc. All rights reserved.