SIP Configuration Guide, Cisco IOS Release 12.4T

Configuring SIP RSVP Features

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

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

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

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

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

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

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

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 

! 

hostname 3845-RSVP-1 

! 

boot-start-marker 

boot-end-marker 

! 

no aaa new-model 

no network-clock-participate slot 2 

! 

ip cef 

! 

no ip domain lookup 

multilink bundle-name authenticated 

! 

voice-card 0 

no dspfarm 

! 

voice-card 2 

no dspfarm 

! 

voice service voip 

sip 

! 

voice class codec 1 

codec preference 1 g711alaw 

codec preference 2 g729r8 

codec preference 3 g729br8 

! 

archive 

log config 

hidekeys 

! 

controller T1 2/1/0 

framing esf 

linecode b8zs 

! 

controller T1 2/1/1 

framing esf 

linecode b8zs 

! 

interface GigabitEthernet0/0 

no ip address 

shutdown 

duplex auto 

speed auto 

media-type rj45 

! 

interface GigabitEthernet0/1 

ip address 172.25.19.72 255.255.255.0 

duplex auto 

speed auto 

media-type rj45 

ip rsvp bandwidth 85 85 

! 

ip route 0.0.0.0 0.0.0.0 172.25.19.1 

! 

ip http server 

ip rsvp policy preempt 

! 

control-plane 

! 

voice-port 2/0/0 

! 

voice-port 2/0/1 

! 

dial-peer voice 1 voip 

description TO RSVP GW-2 

destination-pattern 2001 

voice-class codec 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 protocol sipv2 

session target ipv4:172.25.19.71 

incoming called-number 1001 

req-qos controlled-load 

ip qos defending-priority 65534 

ip qos preemption-priority 45 

! 

dial-peer voice 2 pots 

destination-pattern 1001 

port 2/0/0 

! 

dial-peer voice 3 voip 

description TO CME-1 

destination-pattern 6001 

session protocol sipv2 

session target ipv4:172.25.19.73 

req-qos controlled-load 

acc-qos controlled-load 

ip qos defending-priority 65 

! 

dial-peer voice 4 voip 

description TO CME-2 

destination-pattern 7001 

session protocol sipv2 

session target ipv4:172.25.19.74 

ip qos dscp af21 media rsvp-fail 

ip qos dscp af21 media rsvp-pass 

! 

dial-peer voice 100 voip 

description TO THE CUCM 

destination-pattern 5000 

session protocol sipv2 

session target ipv4:172.25.19.3 

! 

sip-ua 

handle-replaces 

! 

alias exec sdp show running-config | sec dial-peer 

! 

line con 0 

exec-timeout 0 0 

stopbits 1 

line aux 0 

stopbits 1 

line vty 0 4 

! 

scheduler allocate 20000 1000 

! 

End 

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

!

hostname H320_GW2

!

voice-card 0

 no dspfarm

!

voice-card 1

 dspfarm

!

ip cef

!

isdn switch-type primary-ni

!

voice service voip 

 allow-connections h323 to h323

 allow-connections h323 to sip

 allow-connections sip to h323

 allow-connections sip to sip

 h323

  call start slow

!

voice class called number pool 100

 index 1 5551005 - 5551015

!

voice class called number pool 7002

 index 1 7003 - 7018

!

controller T1 3/0

 framing esf

 linecode b8zs

 pri-group timeslots 1-24

!

interface GigabitEthernet0/1

 ip address 172.25.19.72 255.255.255.0

 duplex auto

 speed auto

 media-type rj45

 ip rsvp bandwidth 400 400

!

interface Serial3/0:23

 no ip address

 encapsulation hdlc

 isdn switch-type primary-ni

 isdn protocol-emulate network

 isdn integrate calltype all

 no cdp enable

!

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1

!

ip http server

!

voice-port 3/0:23

 voice-class called-number-pool 100

!

dial-peer voice 1 pots

 description INCOMING DP FOR 8000

 information-type video

 incoming called-number 800

 video calltype h320

 bandwidth maximum 384

 direct-inward-dial

 forward-digits all

!

dial-peer voice 3 voip

 description OUTGOING DP FOR 8000

 destination-pattern 8001

 voice-class sip rel1xx require "100rel"

 session protocol sipv2

 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

!

line con 0

 exec-timeout 0 0

 stopbits 1

line aux 0

 stopbits 1

line vty 0 4

!

scheduler allocate 20000 1000

!

End

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

!

hostname LB-5400-uut7

!

boot-start-marker

no boot startup-test

boot-end-marker

!

logging message-counter syslog

logging buffered 500000

no logging console

!

resource-pool disable

no aaa new-model

voice-card 1

!

voice-card 7

!

ip source-route

!

ip cef

!

no ipv6 cef

multilink bundle-name authenticated

isdn switch-type primary-ni

!

voice service voip 

 allow-connections h323 to h323

 allow-connections h323 to sip

 allow-connections sip to h323

 allow-connections sip to sip

 fax protocol none 

 h323

  call start slow

 sip

  no update-callerid

!

voice class codec 200

 codec preference 1 g711ulaw

 video codec h261

 video codec h263

!

voice class codec 301

 codec preference 1 g711ulaw

 video codec h263

 video codec mpeg4

!

license feature gsmamrnb-codec-pack

!

archive

 log config

  hidekeys

!

controller T1 7/0

 framing ESF

 linecode b8zs

 pri-group timeslots 1-24

!

controller T1 7/1

!

interface GigabitEthernet0/0

 ip address 172.25.19.37 255.255.0.0

 no ip proxy-arp

 duplex auto

 speed auto

 negotiation auto

 ip rsvp bandwidth 1000 1000

!

interface GigabitEthernet0/1

 no ip address

 shutdown

 duplex auto

 speed auto

 negotiation auto

!

interface Serial0/0

 no ip address

 shutdown

 clock rate 2000000

 no fair-queue

!

interface Serial0/1

 no ip address

 shutdown

 clock rate 2000000

!

interface Serial7/0:23

 no ip address

 encapsulation hdlc

 isdn switch-type primary-ni

 isdn timer T310 400000

 isdn protocol-emulate network

 no cdp enable

!

ip default-gateway 172.25.1.1

!

ip forward-protocol nd

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

no ip http server

!

control-plane

!

voice-port 7/0:D

!

mgcp fax t38 ecm

!

dial-peer voice 301 voip

 voice-class sip rel1xx require "100rel"

 voice-class sip calltype-video

 session protocol sipv2

 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

 codec g711ulaw

!

dial-peer voice 300 pots

 destination-pattern 8000

 progress_ind alert strip

 information-type video

 direct-inward-dial

 port 7/0:D

 forward-digits all

!

ss7 mtp2-variant Company 0

ss7 mtp2-variant Company 1

ss7 mtp2-variant Company 2

ss7 mtp2-variant Company 3

!

line con 0

 exec-timeout 0 0

line aux 0

line vty 0 4

 login

!

exception data-corruption buffer truncate

end

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 

SIP UAC CALL INFO

  Number of SIP User Agent Client(UAC) calls: 0

SIP UAS CALL INFO

Call 1

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)

 Calling Number          : 6001

 Called Number           : 1001

 Bit Flags               : 0x8C4401E 0x100 0x4

 CC Call ID              : 30

 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

 RTP Fork Object         : 0x0

 Media Mode              : flow-through

 Media Stream 1

  State of the stream      : STREAM_ACTIVE

  Stream Call ID           : 30

  Stream Type              : voice-only (0)

  Negotiated Codec         : g711ulaw (160 bytes)

  Codec Payload Type       : 0 

  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

  QoS ID                   : -2

  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 

SIP UAC CALL INFO

   Number of SIP User Agent Client(UAC) calls: 0

SIP UAS CALL INFO

Call 1

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)

 Calling Number          : 6001

 Called Number           : 1001

 Bit Flags               : 0x8C4401E 0x100 0x4

 CC Call ID              : 30

 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

 RTP Fork Object         : 0x0

 Media Mode              : flow-through

 Media Stream 1

  State of the stream      : STREAM_ACTIVE

  Stream Call ID           : 30

  Stream Type              : voice-only (0)

  Negotiated Codec         : g711ulaw (160 bytes)

  Codec Payload Type       : 0 

  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

  QoS ID                   : -2

  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 

SIP UAC CALL INFO

   Number of SIP User Agent Client(UAC) calls: 0

SIP UAS CALL INFO

Call 1

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)

 Calling Number          : 6001

 Called Number           : 1001

 Bit Flags               : 0x8C4401E 0x100 0x4

 CC Call ID              : 30

 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

 RTP Fork Object         : 0x0

 Media Mode              : flow-through

 Media Stream 1

  State of the stream      : STREAM_ACTIVE

  Stream Call ID           : 30

  Stream Type              : voice-only (0)

  Negotiated Codec         : g711ulaw (160 bytes)

  Codec Payload Type       : 0 

  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

  QoS ID                   : -2

  Local QoS Strength       : Optional

  Negotiated QoS Strength  : Optional

  Negotiated QoS Direction : SendRecv

  Local QoS Status         : Fail

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 

SIP UAC CALL INFO

   Number of SIP User Agent Client(UAC) calls: 0

SIP UAS CALL INFO

Call 1

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)

 Calling Number          : 6001

 Called Number           : 1001

 Bit Flags               : 0x8C4401E 0x100 0x4

 CC Call ID              : 30

 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

 RTP Fork Object         : 0x0

 Media Mode              : flow-through

 Media Stream 1

  State of the stream      : STREAM_ACTIVE

  Stream Call ID           : 30

  Stream Type              : voice-only (0)

  Negotiated Codec         : g711ulaw (160 bytes)

  Codec Payload Type       : 0 

  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

  QoS ID                   : -2

  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

RFCs

Technical Assistance

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.

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.