Cisco Unified Border Element Configuration Guide, Release 15.2

SIP-to-SIP Connections on a Cisco Unified Border Element

This chapter describes how to configure and enable features for SIP-to-SIP connections in an Cisco Unified Border Element topology. A Cisco Unified Border Element (Cisco UBE), in this guide also called an IP-to-IP gateway (IPIPGW), border element (BE), or session border controller, facilitates connectivity between independent VoIP networks by enabling VoIP and videoconferencing calls from one IP network to another.

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 "Cisco Unified Border Element Features Roadmap" section.

Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

For more information about Cisco IOS voice features, see the entire Cisco IOS Voice Configuration Library—including feature documents, and troubleshooting information—at http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/cisco_ios_voice_configuration_library_glossary/vcl.htm.

Contents

This chapter describes how to configure SIP-to-SIP connections in a Cisco Unified Border Element (Cisco UBE). It covers the following features:

•Prerequisites for Configuring SIP-to-SIP Connections on a Cisco Unified Border Element

•Restrictions for Configuring SIP-to-SIP Connections on a Cisco Unified Border Element

•Information About Configuring SIP-to-SIP Connections on a Cisco Unified Border Element

•How to Configure SIP-to-SIP Gateway Features

•Configuration Examples for SIP-to-SIP Connections in a Cisco Unified Border Element

•Troubleshooting Tips

•Additional References

•Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element

Prerequisites for Configuring SIP-to-SIP Connections on a Cisco Unified Border Element

•Perform the prerequisites listed in the "Prerequisites for Cisco Unified Border Element Configuration" procedure in this guide.

•Perform fundamental gateway configuration listed in the "Prerequisites for Fundamental Cisco Unified Border Element Configuration" procedure in this guide.

•Perform basic H.323 gateway configuration.

•Perform basic H.323 gatekeeper configuration.

Note For configuration instructions, see the "Configuring H.323 Gateways" and "Configuring H.323 Gatekeepers" chapters of the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2.

Restrictions for Configuring SIP-to-SIP Connections on a Cisco Unified Border Element

Cisco IOS Release 12.4(15)XY and later releases:

•Registration is not supported.

Cisco IOS Release 12.4(15)T and before:

•Delayed-Offer to Delayed-Offer is not supported.

•Codec T is not supported.

•Registration is not supported.

•Supplementary services are not supported.

•Transcoding is not supported.

•Like-to-like error messages are not passed from the incoming SIP leg to the outgoing SIP leg.

Cisco IOS Release 12.4(9)T and before:

•Topology and address hiding is not supported.

Cisco IOS Release 12.4(9)T and later releases:

•Media flow-around for Delayed-Offer to Early-Offer audio and video calls is not supported.

•DTMF Interworking rtp-nte to out of band is not supported when high density transcoder is enabled. Use normal transcoding for rtp-nte to out of band DTMF interworking.

ptime attributes

•SIP gateway supports one ptime attribute per media line.

•Cisco UBE supports ptime attribute when one codec is offered. The ptime attribute is not sent when multiple codecs are offered by the Cico UBE.

•The default behavior of the Cisco UBE is to select the minimum ptime value from the offer and prefer. Results are unpredictable when dissimilar networks with different packetization time periods are connected.

Information About Configuring SIP-to-SIP Connections on a Cisco Unified Border Element

Note When you configure SIP on a router, the ports on all its interfaces are open by default. This makes the router vulnerable to malicious attackers who can execute toll fraud across the gateway if the router has a public IP address and a public switched telephone network (PSTN) connection. To eliminate the threat, you should bind an interface to private IP address that is not accessible by untrusted hosts. In addition, you should protect any public or untrusted interface by configuring a firewall or an access control list (ACL) to prevent unwanted traffic from traversing the router.

•Delayed-Offer to Early-Offer audio calls are supported.

•Delayed-Offer to Delayed-Offer calls are supported.

•Delayed-Offer to Delayed-Offer video calls are supported in Cisco IOS Release 12.4(15)XY and later.

•Delayed-Offer to Delayed-Offer audio calls are supported in Cisco IOS Release 12.4(15)T and later.

•Early-Offer to Early-Offer for audio calls are supported.

•Early-Offer to Early-Offer, Delayed-Offer to Early-Offer video calls are supported in 12.4(15)XZ and later.

•Fax relay is enabled by default for all systems. No further configuration is needed.

•Like-to-like dtmf, codec and fax are supported.

•Like-to-like error messages are not passed from the incoming SIP leg to the outgoing SIP leg. Error messages are passed through Cisco Unified BE when the header-passing error-passthru command is configured in Cisco IOS Release 12.4(15) T and later.

•Media flow-around (except for Delayed-Offer to Early-Offer audio and video calls) in Cisco IOS Release 12.4(9)T and later.

•reINVITE pass-through for Session Refresh is supported.

•SIP-to-SIP Video (including Delayed-Offer to Delayed-Offer, Early-Offer to Early-Offer, Delayed-Offer to Early-Offer calls) are supported.

•SRTP-to-SRTP support for SIP-to-SIP calls is supported.

How to Configure SIP-to-SIP Gateway Features

The following section provides configuration information for the following SIP-to-SIP features.

•SIP-to-SIP Basic Functionality for Session Border Controller (SBC)

•SIP-to-SIP Extended Feature Functionality for Session Border Controller (SBC)

•SIP-to-SIP Supplementary Services for Session Border Controller (SBC)

•SIP-to-SIP Supplementary Feature Interworking for Session Border Controller (SBC)

•Configuring IP Address-Hiding

•Configuring SIP-to-SIP Connections on a Cisco Unified Border Element

•Configuring Delayed-Offer to Early-Offer for SIP Audio Calls

•Configuring Call Escalation from Voice to Video

•Configuring SIP Error Message Pass Through

•Configuring Cisco UBE for Unsupported Content Pass-through

•Configuring Cisco UBE for STUN and DTLS Pass-through

•Configuring Media Flow-Around

•Configuring Media Antitrombone

•Configuring Support for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls Feature

•Enabling In-Dialog OPTIONS to Monitor Active SIP Sessions

•Configuring Cisco UBE Out-of-dialog OPTIONS Ping for Specified SIP Servers or Endpoints

•Configuring an Error Response Code upon an Out-of-Dialog OPTIONS Ping Failure

•Configuring SIP Parameters

•Configurable SIP Parameters via DHCP

•Configuring SIP Listening Port

•Configuring Bandwidth Parameters for SIP Calls

•Configuring Support for Session Refresh with Reinvites

•Sending a SIP Registration Message from a Cisco Unified Border Element

•Configuring Adjustable Timers for Registration Refresh and Retries

•Configuring Cisco Unified Border Element Support for SRTP-RTP Internetworking

•Configuring Assisted Real-time Transport Control Protocol (RTCP) Report Generation

•Support for PAID, PPID, Privacy, PCPID, and PAURI Headers on the Cisco UBE

•Support for Preloaded Routes in Outgoing INVITE Messages Based on REGISTER Information

•Configuring Support for SIP UPDATE Message per RFC 3311

•Selectively Using sip: URI or tel: URL Formats on Individual SIP Headers

•Configuring Selective Filtering of Outgoing Provisional Response on the Cisco Unified Border Element

•Configuring Support for Negotiation of an Audio Codec from a List of Codecs on Each Leg of a SIP-to-SIP Call on the Cisco Unified Border Element

•Configuring Support for SIP Registration Proxy on Cisco UBE

•Configuring Support for Conditional Header Manipulation of SIP Headers

•Configuring Support for Reporting End-of-Call Statistics in SIP BYE Message

•Configuring RTP Media Loopback for SIP Calls

•Verifying and Troubleshooting SIP-to-SIP Connections on a Cisco Unified Border Element

SIP-to-SIP Basic Functionality for Session Border Controller (SBC)

SIP-to-SIP Basic Functionality for SBC for Cisco UBE provides termination and reorigination of both signaling and media between VoIP and video networks using SIP signaling in conformance with RFC3261. The SIP-to-SIP protocol interworking capabilities of the Cisco Unified Border Element (Cisco UBE) support the following:

•Basic voice calls (Supported audio codecs include: G.711, G.729, G.728, G.726, G.723, G.722, AAC_LD, iLBC. Video codecs: H.263, and H.264)

•Codec transcoding

•Calling/called name and number

•DTMF relay interworking

–SIP RFC 2833 <-> SIP RFC 2833

–SIP Notify <-> SIP Notify

•Interworking between SIP early-media and SIP early-media signaling

•Interworking between SIP delayed-media and SIP delayed-media signaling

•RADIUS call-accounting records

•RSVP synchronized with call signaling

•SIP-SIP Video calls

•TCL IVR 2.0 for SIP, including media playout and digit collection (RFC 2833 DTMF relay)

•T.38 fax relay and Cisco fax relay

•UDP and TCP transport

SIP-to-SIP Extended Feature Functionality for Session Border Controller (SBC)

Enables the SIP-to-SIP functionality to conform with RFC 3261 to interoperate with SIP UAs. New SIP-to-SIP features available include:

•Call Admission Control (based on CPU, memory, total calls)

•Delayed Media Call

•ENUM support

•Configuring SIP Error Message Pass Through

•Interoperability with Cisco Unified Communications Manager 5.0 and BroadSoft.

•Lawful Intercept

•Media Inactivity

•Modem passthrough

•TCP and UDP interworking

•Tcl scripts with SIP NOTIFY VoiceXML with SIP-to-SIP

•Transport Layer Security (TLS)

SIP-to-SIP Supplementary Feature Interworking for Session Border Controller (SBC)

Provides enhanced termination and re-origination of signaling and media between VoIP and Video Networks in conformance with RFC3261. New SIP-to-SIP capabilities offered in this release on the Cisco 28xx, 38xx, 5350XM and 5400XM include:

•iLBC Codec

Codecs section of the Dial Peer Configuration on Voice Gateway Routers Guide

–http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/dial_peer/dp_ovrvw.html

Dial Peer Features and Configuration section of the Dial Peer Configuration on Voice Gateway Routers Guide

–http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/dial_peer/dp_confg.html

•G.711 Inband DTMF to RFC 2833

•Session refresh

•SIP-to-SIP Supplementary Services

–Refer/302 Based Supplementary Services Supported from 12.4(9)T onwards

–ReInvite Based Supplementary Services Supported from 12.4(15)XZ

SIP-to-SIP Supplementary Services for Session Border Controller (SBC)

This chapter describes the SIP-to-SIP supplementary service features for SBC. The SIP-to-SIP supplementary services feature enhances terminating and re-originating both signaling and media between VoIP and Video networks by supporting the following features:

•IP Address Hiding in all SIP messages including supplementary services

•Media

–Media Flow Around

•Support on Cisco AS5350XM and Cisco AS5400XM

•SIP-to-SIP Supplementary services using REFER/3xx method. The following features are enabled by default.

–Message Waiting Indication

–Call Waiting

–Call Transfer (Blind, Consult, Alerting)

–Call Forward (All, Busy, No Answer)

–Distinctive Ringing

–Call Hold/Resume

–Music on Hold

•Hosted NAT Traversal for SIP

Configuring IP Address-Hiding

Configuring address-hiding hides signaling and media peer addresses from the endpoints, especially for supplemental services when the Cisco Unified BE passes REFER/3xx messages from leg to leg. Configuring the address hiding feature ensures that the Cisco Unified BE is the only point of signaling and media entry/exit in all scenarios. To enable address-hiding in all SIP messages, perform the steps in this section.

Prerequisites

To enable this feature, you must have Cisco IOS Release 12.4(9)T or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

Restrictions

When supplementary services are configured the endpoint sends messages to the SBC, this is then forwarded to the peer endpoint. Address-hiding is preserved during this message forwarding

1. enable

2. configure terminal

3. voice service voip

4. address-hiding

5. exit

Router(config)# voice service voip

Configuring SIP-to-SIP Connections on a Cisco Unified Border Element

To configure SIP-to-SIP connection types, perform the steps in this section.

Prerequisites

To enable this feature, you must have Cisco IOS Release 12.3(1) or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

Restrictions

•Connections are disabled by default in Cisco IOS images that support the Cisco UBE.

•This chapter covers only those features that require a unique configuration in order to support the Cisco UBE. For information on those H.323 gateway features not mentioned in this chapter, see the Cisco IOS Voice, Video, and Fax Configuration Guide.

1. enable

2. configure terminal

3. voice service voip

4. allow-connections

5. exit

Configuring Delayed-Offer to Early-Offer for SIP Audio Calls

This feature the alters the default configuration of the Cisco Unified BE from not distinguishing SIP Delayed-Offer to Early-Offer call flows, to forcing the Cisco Unified BE to generate an Early-Offer with the configured codecs for a incoming Delayed-Offer INVITE. To configure a Cisco Unified Border Element to send a SIP invite with Early-Offer (EO) on the Out-Leg (OL) perform the steps in this section.

Prerequisites

•To enable this feature, you must have Cisco IOS Release 12.4(15)XZ or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

•The allow-connections sip to sip command must be configured before you configure media flow-around. For more information and configuration steps see the "Configuring SIP-to-SIP Connections on a Cisco Unified Border Element" section of this chapter.

Restrictions

•Cisco Unified Communications Manager 5.x supports Early-Offer over SIP trunk for audio calls with MTP

•Support for Cisco Unified Communications Manager Early-Offer for video calls and audio calls without MTP is not supported

Table 1 shows a list of protocol interworking for SIP.

How to Configure Delayed-Offer to Early-Offer for SIP Audio Calls

To Delayed-Offer to Early-Offer for SIP Audio Calls for all VoIP calls, or individual dial peers, perform the steps in this section. This section contains the following subsections:

•Configuring Delayed-Offer to Early-Offer for SIP Audio Calls at the Global Level

•Configuring Delayed-Offer to Early-Offer for SIP Audio Calls for a Dial-Peer

Configuring Delayed-Offer to Early-Offer for SIP Audio Calls at the Global Level

To configure Delayed-Offer to Early-Offer for SIP Audio Calls at the global level, perform the steps in this section.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voip

4. allow-connections sip

5. early-offer forced

6. exit

Configuring Delayed-Offer to Early-Offer for SIP Audio Calls for a Dial-Peer

To configure Delayed-Offer to Early-Offer for SIP Audio Calls for an individual dial-peer, perform the steps in this section.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice 1 voip

4. voice-class sip early-offer forced

5. exit

Configuring Call Escalation from Voice to Video

The Call Escalation from Voice to Video feature supports mid-call escalation of SIP-to-SIP calls via signaling from voice calls to video. The call initially starts as an audio-only call. When the call is in progress, media renegotiation results in a video stream being added to the call, leading to call escalation from an audio-only call to an audio and video call.

To configure call escalation for SIP-to-SIP calls from voice calls to video, perform the following task.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voip

4. allow-connections from-type to to-type

5. exit

6. dial-peer voice tag voip

7. session protocol sipv2

8. codec transparent

9. end

Configuring SIP Error Message Pass Through

The SIP error message pass through feature allows a received error response from one SIP leg to pass transparently over to another SIP leg. This functionality will pass SIP error responses that are not yet supported on the Cisco UBE or will preserve the Q.850 cause code across two sip call-legs.

SIP error responses that are not supported on the Cisco UBE include: 300—Multiple choices, 301—Moved permanently, and 485—Ambiguous

Pre-leg SIP error responses that are not transparently passed though include:

Prerequisites

To enable this feature, you must have Cisco IOS Release XXX or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

Restrictions

•Configuring SIP error header passing in at the dial-peer level is not supported.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voice

4. sip

5. header-passing error-pass through

6. exit

Configuring Cisco UBE for Unsupported Content Pass-through

This feature introduces the ability to configure the Cisco UBE to pass through end to end headers at a global or dial-peer level, that are not processed or understood in a SIP trunk to SIP trunk scenario. The pass through functionality includes all or only a configured list of unsupported or non-mandatory SIP headers, and all unsupported content/MIME types.

The Cisco Unified Border Element does not support end-to-end media negotiation between the two endpoints that establish a call session through the Cisco Unified Border Element. This is a limitation when the endpoints intend to negotiate codec/payload types that the Cisco Unified Border Element does not process, because currently, unsupported payload types will never be negotiated by the Cisco Unified Border Element. Unsupported content types include text/plain, image/jpeg and application/resource-lists+xml. To address this problem, SDP is configured to pass through transparently at the Cisco Unified Border Element, so that both the remote ends can negotiate media independently of the Cisco Unified Border Element.

SDP pass-through is addressed in two modes:

•Flow-through: Cisco Unified Border Element plays no role in the media negotiation, it blindly terminates and re-originates the RTP packets irrespective of the content type negotiated by both the ends. This supports address hiding and NAT traversal.

•Flow-around: Cisco Unified Border Element neither plays a part in media negotiation, nor does it terminate and re-originate media. Media negotiation and media exchange is completely end-to-end.

Prerequisites for Cisco UBE for Unsupported Content Pass-through

•To enable this feature, you must have Cisco IOS Release XXX or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

•Configuring the media flow-around command is required for SDP pass-through. When flow-around is not configured, the flow-through mode of SDP pass-through will be functional.

•When the dial-peer media flow mode is asymmetrically configured, the default behavior is to fallback to SDP pass-through with flow-through.

Restrictions for Cisco UBE for Unsupported Content Pass-through

When SDP pass-through is enabled, some of interworking that the Cisco Unified Border Element currently performs cannot be activated. These features include:

•Delayed Offer to Early Offer Interworking

•Supplementary Services with triggered Invites

•DTMF Interworking scenarios

•Fax Interworking/QoS Negotiation

•Transcoding

To enable Cisco UBE Unsupported Content Pass-through perform the steps in this section. This section contains the following subsections:

•Configuring Cisco UBE for Unsupported Content Pass-through at the Global Level

•Configuring Cisco UBE for Unsupported Content Pass-through at the Dial Peer Level

Configuring Cisco UBE for Unsupported Content Pass-through at the Global Level

To configure Unsupported Content Pass-through on an Cisco Unified Border Element at the global level, perform the steps in this section.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voip

4. sip

5. pass-thru {content {sdp | unsupp} | headers {unsupp | list tag}}

6. exit

Router(config)# voice service voip

Configuring Cisco UBE for Unsupported Content Pass-through at the Dial Peer Level

To configure Unsupported Content Pass-through on an Cisco Unified Border Element at the dial-peer level, perform the steps in this section.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice number voip

4. voice-class sip pass-thru{{headers | content} {content {unsupp | sdp}}

5. exit

Passes the SDP transparently from in-leg to the 
out-leg with no media negotiation.

Configuring Cisco UBE for STUN and DTLS Pass-through

Cisco TelePresence System (CTS) endpoints send and receive Session Traversal Utilities for NAT (STUN) and Datagram Transport Layer Security (DTLS) packets. STUN packets are sent to open and refresh firewall pinholes. DTLS handshakes are performed to establish the Secure Real-Time Transport Protocol (SRTP) security parameters for secure CTS calls.

This feature enables Cisco Unified Border Element (Cisco UBE) to support STUN and DTLS packet pass-through, thereby adding support for secure CTS calls through Cisco UBE. However, the feature is generic and is supported for any endpoint that sends STUN or DTLS packets, including Trusted Relay Point (TRP).

Note The configuration for STUN and DTLS pass-through on Cisco UBE is enabled by default and requires no specific configuration.

However, to enable STUN and DTLS pass-through for Cisco TelePresence System (CTS) calls, perform the following tasks:

•Configuring RTCP Report Generation on Cisco UBE (optional)

•Troubleshooting Tips (optional)

Restrictions

•STUN and DTLS pass-through over IPv6 is not supported.

•DTLS pass-through is not supported for T.38 fax and modem relay calls.

•STUN and DTLS pass-through is not supported when Cisco UBE inserts a Digital Signal Processor (DSP) for transcoding interworkings such as SRTP-RTP, dual-tone multi-frequency (DTMF), and so on.

Configuring STUN and DTLS Pass-through for CTS Calls at the Global Level

Perform this task to configure STUN and DTLS pass-through for CTS calls at the global level.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voip

4. rtp-ssrc multiplex

5. allow-connections from-type to to-type

6. sip

7. rel1xx disable

8. header-passing error-passthru

9. end

DETAILED STEPS

Configuring STUN and DTLS Pass-through for CTS Calls at the Dial Peer Level

Perform this task to configure STUN and DTLS pass-through for CTS calls at the dial-peer level.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice voice-dial-peer-tag voip

4. destination-pattern E.164-standard-number

5. rtp payload-type cisco-codec-fax-ind number

6. rtp payload-type cisco-codec-aacld number

7. rtp payload-type cisco-codec-video-h264 number

8. session protocol sipv2

9. session target ipv4:destination-address

10. incoming called-number E.164-standard-number

11. playout-delay minimum low

12. codec transparent

13. no vad

14. end

DETAILED STEPS

Troubleshooting Tips

The following debug commands display the details about STUN and DTLS packets sent and received:

•debug ccsip messages—Shows SIP messages.

Router# debug ccsip messages

SIP Call messages tracing is enabled

•debug ccsip error—Shows SIP Service Provider Interface (SPI) errors.

Router# debug ccsip error

SIP Call error tracing is enabled

•debug voip rtp session event—Shows debugging related to RTP named event packets.

Router# debug voip rtp session event

*Nov 26 12:10:06.558: voip_rtp_is_media_service_pak: Received DTLS packet

              (src ip=192.16.2.2, src port=19312, dst ip=192.16.2.1, dst port=16386

               pdu size=111, pdu=0x16, switching ctx=interrupt)

*Nov 26 12:10:06.558: voip_rtp_send_service_pak: Sending DTLS packet

              (src ip=192.16.2.1, src port=17958, dst ip=192.16.2.3, dst port=5020

               pdu size=111, pdu=0x16, switching ctx=interrupt)

*Nov 26 12:10:07.014: voip_rtp_is_media_service_pak: Received STUN packet

              (src ip=192.16.2.2, src port=19210, dst ip=192.16.2.1, dst port=16910

               pdu size=20, pdu=0x00, switching ctx=interrupt)

*Nov 26 12:10:07.014: voip_rtp_send_service_pak: Sending STUN packet

              (src ip=192.16.2.1, src port=17894, dst ip=192.16.2.3, dst port=5022

               pdu size=20, pdu=0x00, switching ctx=interrupt)

Note The debug voip rtp session event command should be enabled only for troubleshooting purposes.

Configuring Media Flow-Around

This feature adds media flow-around capability on the Cisco Unified Border Element by supporting the processing of call setup and teardown requests (VoIP call signaling) and for media streams (flow-through and flow-around). Media flow-around can be configured the global level or it must be configured on both incoming and outgoing dial peers. If configured only on either the incoming or outgoing dialpeer, the call will become a flow-through call.

Media flow-around is a good choice to improve scalability and performance when network-topology hiding and bearer-level interworking features are not required

With the default configuration, the Cisco UBE receives media packets from the inbound call leg, terminates them, and then reoriginates the media stream on an outbound call leg. Media flow-around enables media packets to be passed directly between the endpoints, without the intervention of the Cisco UBE. The Cisco UBE continues to handle routing and billing functions.

To specify media flow-around for voice class, all VoIP calls, or individual dial peers, perform the steps in this section. This section contains the following subsections:

•Configuring Media Flow-Around for a Voice Class

•Configuring Media Flow-Around at the Global Level

•Configuring Media Flow-Around for a Dial Peer

•Configuring Delayed-Offer to Early-Offer Media Flow-Around at the Global Level

•Configuring Delayed-Offer to Early-Offer Media Flow-Around for a Dial-Peer

•Configuring Delayed-Offer to Early-Offer Media Flow-Around for High-Density Transcoding Calls

Prerequisites

•To enable this feature, you must have Cisco IOS Release XXX or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

•The allow-connections sip to sip command must be configured before you configure media flow-around. For more information and configuration steps see the "Configuring SIP-to-SIP Connections on a Cisco Unified Border Element" section of this chapter.

Configuring Media Flow-Around for a Voice Class

To configure media flow-around for a voice class, perform the steps in this section.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice class media 1

4. media flow-around

5. dial-peer voice 2 voip

6. voice-class media 1

7. exit

Configuring Media Flow-Around at the Global Level

To configure media flow-around at the global level, perform the steps in this section.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voip

4. media flow-around

5. exit

Configuring Media Flow-Around for a Dial Peer

To configure media flow-around for an individual dial peer, perform the steps in this section.

Restrictions

If you plan to configure both incoming and outgoing dial peers, you must specify the transparent codec on the incoming dial peer.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice number voip

4. media flow-around

5. exit

Configuring Delayed-Offer to Early-Offer Media Flow-Around at the Global Level

Perform this task to configure delayed-offer (DO) to early-offer (EO) media flow-around at the voice service configuration mode.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voip

4. media flow-around

5. sip

6. early-offer forced

7. exit

8. exit

9. exit

Configuring Delayed-Offer to Early-Offer Media Flow-Around for a Dial-Peer

Perform this task to configure DO to EO Media Flow-Around for an individual dial peer.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice number voip

4. media flow-around

5. voice class sip early-offer forced

6. exit

7. exit

Configuring Delayed-Offer to Early-Offer Media Flow-Around for High-Density Transcoding Calls

Perform this task to configure Delayed-Offer to Early-Offer Media transcoding high-density calls.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voip

4. media transcoder high-density

5. sip

6. early offer-forced

7. exit

8. exit

9. exit

Configuring Media Antitrombone

Media Trombones are media loops in a SIP entity due to call transfer or call forward. Media loops in Cisco UBE are not detected because Cisco UBE looks at both call types as individual calls and not calls related to each other.

Antitromboning is a media signaling service in SIP entity to overcome the media loops. Antitrombone service has to be enabled only when no media interworking is required in both the out-legs.

To specify media antitrombone for voice class, all VoIP calls, or individual dial peers, perform the tasks in the following sections:

•Configuring Media Antitrombone for a Voice Class (Required)

•Configuring Media Antritrombone at the Global Level (Required)

•Configuring Media Antitrombone for a Dial Peer (Required)

Prerequisites

To enable this feature, you must have Cisco IOS Release 15.1(3)T or a later release installed on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

Restrictions

•When media antitrombone service is activated, Cisco UBE does not perform supplementary services such as handling REFER-based call transfers or media services such as SRTP, SNR and call transfers.

•Video codecs are not supported for the normal media handling because the SIP Cisco IOS gateway infrastructure does not support flow-through and flow-around for video.

•Antitrombone will not work if one call leg is flow-through and another call leg is flow-around. Similarly, antitrombone will not work if one call leg is SDP pass-through and another call leg is SDP normal.

•H.323 is not supported.

•Delayed-offer to early-offer (DO-EO) video media flow around is not supported.

Configuring Media Antitrombone for a Voice Class

Perform this task to configure antitrombone service for a voice class.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice class media tag

4. media anti-trombone

5. exit

6. exit

Configuring Media Antritrombone at the Global Level

Perform this task to configure media antitrombone service at the voice service configuration mode.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voip

4. media anti-trombone

5. exit

6. exit

Configuring Media Antitrombone for a Dial Peer

Perform this task to configure media antitrombone at individual dial peer level.

Restrictions

•If both incoming and outgoing dial peers are configured, you must specify the transparent codec on the incoming dial peer.

•The media anti-trombone command needs to be enabled for all related dial peers.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice number voip

4. media anti-trombone

5. exit

6. exit

Configuring DTMF Relay Digit-Drop on a Cisco Unified Border Element

To avoid sending both in-band and out-of band tones to the outgoing leg when sending Cisco UBE calls in-band (rtp-nte) to out-of band (h245-alphanumeric), configure the dtmf-relay rtp-nte digit-drop command on the incoming SIP dial-peer. On the H.323 side configure either the dtmf-relay h245-alphanumeric or dtmf-relay h245-signal command. This feature can also be used for H.323-to-SIP, and H.323-to-H.323 calls.

Note For a SIP (rtp-nte) to H.323 (h245-alphanumeric) via Cisco UBE call, if any RTP-NTE packets are sent before the H.323 Endpoint answers the call, the dual-tone multifrequency (DTMF) signal is not audible on a terminating gateway (TGW).

To configure DTMF relay digit drop on an Cisco UBE with Cisco Unified Communications Manager, perform the steps in this section.

Prerequisites

To enable this feature, you must have Cisco IOS Release 12.4(4)T or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

Restrictions

•You should not configure digit-drop for inband to and from rtp-nte dtmf conversion (this involves transcoder), the digit-drop CLI prevents sending rtp-nte packets from the RTP lib.

•Configuring the digit-drop command is required for interworking between OOB and RTP NTE.

•Digit-drop for in-band rtp-nte DTMF conversion requiring a transcoder is not supported.

•Cisco IOS MTP should be used when the Cisco UBE does DTMF interworking between inband G.711 voice and RFC 2833 with Cisco Communication Manager (CCM) SIP trunk.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice tag voip

4. dtmf-relay [cisco-rtp] [h245-alphanumeric] [h245-signal][rtp-nte [digit-drop]]

5. exit

Examples

The following example shows DTMF-Relay digits configured to avoid sending both in-band and out-of-band tones to the outgoing leg in an Cisco Unified BE:

.

.

.

dial-peer voice 1 voip

 dtmf-relay h245-alphanumeric rtp-nte digit-drop 

.

.

.

Troubleshooting tips

The debug output will show that the H245 out of band messages are sent to the TGW. However, entry of the digits are not audible on the phone.

Configuring Support for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls Feature

The Support for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls feature provides dynamic payload type interworking for dual tone multifrequency (DTMF) and codec packets for Session Initiation Protocol (SIP) to SIP calls.

Based on this feature, the Cisco Unified Border Element interworks between different dynamic payload type values across the call legs for the same codec. Also, Cisco UBE supports any payload type value for audio, video, named signaling events (NSEs), and named telephone events (NTEs) in the dynamic payload type range 96 to 127.

Symmetric and Asymmetric Calls

Cisco UBE supports dynamic payload type negotiation and interworking for all symmetric and asymmetric payload type combinations. A call leg on Cisco UBE is considered as symmetric or asymmetric based on the payload type value exchanged during offer answer with the endpoint:

•A symmetric endpoint accepts and sends the same payload type.

•An asymmetric endpoint can accept and send different payload types.

Default Behavior

The Support for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP to SIP Calls feature is enabled by default for a symmetric call. An offer is sent with a payload type based on the dial-peer configuration. The answer is sent with the same payload type as was received in the incoming offer. When the payload type values negotiated during the signaling are different, the Cisco UBE changes the Real-Time Transport Protocol (RTP) payload value in the VoIP to RTP media path.

CLI Behavior

The Support for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP to SIP Calls feature is not enabled by default for an asymmetric call leg. You must use the asymmetric payload command to configure this feature to support asymmetric call legs. The dynamic payload type value is passed across the call legs, and the RTP payload type interworking is not required. The RTP payload type handling is dependent on the endpoint receiving them.

Prerequisites

To enable this feature, you must have Cisco IOS Release 15.0(1)XA or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

Restrictions

The Support for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP to SIP Calls feature is not supported for the following:

•H323-to-H323 and H323-to-SIP calls.

•All transcoded calls.

•Secure Real-Time Protocol (SRTP) pass-through calls.

•Flow-around calls.

•Asymmetric payload types are not supported on early-offer (EO) call leg in a delayed-offer to early-offer (DO-EO) scenario.

•Multiple m lines with the same dynamic payload types, where m is:

m = audio <media-port1> RTP/AVP XXX
m = video <media-port2> RTP/AVP XXX

Configuring Dynamic Payload Support at the Global Level

Perform this task to configure the Support for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP to SIP Calls feature at the global level.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voip

4. sip

5. asymmetric payload {dtmf | dynamic-codecs | full | system}

6. end

Configuring Dynamic Payload Support for a Dial Peer

Perform this task to configure Support for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP to SIP Calls feature for a dial peer.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice tag voip

4. voice-class sip asymmetric payload {dtmf | dynamic-codecs | full | system}

5. end

Troubleshooting the Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP to SIP Calls Feature

Use the following commands to debug any errors that you may encounter when you configure the Support for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP to SIP Calls feature.

•debug ccsip all

•debug voip ccapi inout

•debug voip rtp

Verifying Support for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP to SIP Calls Feature

This task shows how to display information to verify Support for Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP to SIP Calls configuration. These show commands need not be entered in any specific order.

SUMMARY STEPS

1. enable

2. show call active voice compact

3. show call active voice

Enabling In-Dialog OPTIONS to Monitor Active SIP Sessions

The two common methods to determine whether a SIP session is active; RTP/RTCP media inactivity timer and session timer have limitations when used with the Cisco UBE. The media inactivity (rtp/rtcp) method will not work if flow around mode is configured as the media is sent directly between endpoints without going through the Cisco UBE and session timer cannot be used if the SIP endpoint does not support session timer.

The in-dialog OPTIONS refresh feature introduces a refresh mechanism that addresses these two scenarios, and can be used on SIP-to-SIP and SIP-to-H.323 calls. The refresh with OPTIONS method is meant to only be hop-to-hop, and not end-to-end. Since session timer achieves similar results, the OPTIONs refresh/ping will not take affect when session timer is negotiated. The behavior on the H.323 endpoint is as if it was a TDM-SIP call. The generating in-dialog OPTIONS is enabled at the global level or dialpeer level. The system default setting is disabled. This feature can be use by both a TDM voice gateway and an Cisco UBE.

To enable in-dialog OPTIONS at the global level, or individual dial peers, perform the steps in this section. This section contains the following subsections:

•Methods to Determine Active SIP Sessions

•Enabling In-dialog OPTIONS at the Global Level

•Enabling in-dialog OPTIONS for a Dial-Peer

•Configuring Library Based RTCP Media Inactivity Timer

Methods to Determine Active SIP Sessions

RTP/RTCP

The SIP Media Inactivity Timer enables Cisco gateways to monitor and disconnect VoIP calls if no Real-Time Control Protocol (RTCP) packets are received within a configurable time period.

Session Timer

The SIP Session Timer periodically refresh Session Initiation Protocol (SIP) sessions by sending repeated INVITE requests. The repeated INVITE requests are sent during an active call leg to allow user agents (UA) or proxies to determine the status of a SIP session. The re-INVITES ensure that active sessions stay active and completed sessions are terminated.

Prerequisites

To enable this feature, you must have Cisco IOS Release XXX or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

Enabling In-dialog OPTIONS at the Global Level

To enable in-dialog OPTIONS at the global level, perform the steps in this section.

Note The global system default setting is disable.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voip

4. sip

5. options-ping 90

6. exit

7. end

Enabling in-dialog OPTIONS for a Dial-Peer

To enable in-dialog OPTIONS for an individual dial-peer, perform the steps in this section.

Restrictions

When configuring in-dialog OPTIONS at the dial-peer level OPTIONS must be configured on both incoming and outgoing dial peers.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice 1 voip

4. voice-class sip options-ping

5. exit

6. end

Configuring Library Based RTCP Media Inactivity Timer

Restrictions

•No dsp based media inactivity is supported in CUBE

SUMMARY STEPS

1. enable

2. configure terminal

3. ip rtcp report interval

4. gateway

5. media-inactivity-criteria rtcp

6. timer receive-rtcp 5

7. exit

8. end

Configuring Cisco UBE Out-of-dialog OPTIONS Ping for Specified SIP Servers or Endpoints

The Out-of-dialog (OOD) Options Ping feature provides a keepalive mechanism at the SIP level between any number of destinations. A generic heartbeat mechanism allows Cisco Unified Border Element to monitor the status of SIP servers or endpoints and provide the option of busying-out a dial-peer upon total heartbeat failure. When a monitored endpoint heartbeat fails, the dial-peer is busied out. If an alternate dial-peer is configured for the same destination pattern, the call is failed over to the next preferred dial peer, or else the on call is rejected with an error cause code.

The response to options ping will be considered unsuccessful and dial-peer will be busied out for following scenarios:

All other error codes, including 400 are considered a valid response and the dial peer is not busied out.

Note The purpose of this feature is to determine if the SIP session protocol on the endpoint is UP and available to handle calls. It may not handle OPTIONS message but as long as the SIP protocol is available, it should be able to handle calls.

When a dial-peer is busied out, Cisco Unified Border Element continues the heartbeat mechanism and the dial-peer is set to active upon receipt of a response.

Prerequisites

•To enable this feature, you must have Cisco IOS Release XXX or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

•The following are required for OOD Options ping to function. If any are missing, the Out-of-dialog (OOD) Options ping will not be sent and the dial peer is reset to the default active state.

–Dial-peer should be in active state

–Session protocol must be configured for SIP

–Configure Session target or outbound proxy must be configured. If both are configured, outbound proxy has preference over session target.

Restrictions

•The Cisco Unified Border Element OOD Options ping feature can only be configured at the VoIP Dial-peer level.

•All dial peers start in an active (not busied out) state on a router boot or reboot.

•If a dial-peer has both an outbound proxy and a session target configured, the OOD options ping is sent to the outbound proxy address first.

•Though multiple dial-peers may point to the same SIP server IP address, an independent OOD options ping is sent for each dial-peer.

•If a SIP server is configured as a DNS hostname, OOD Options pings are sent to all the returned addresses until a response is received.

•Configuration for Cisco Unified Border Element OOD and TDM Gateway OOD are different, but can co-exist.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice tag voip

4. voice-class sip options-keepalive

5. exit

Router(config)# dial-peer voice 200 voip

Troubleshooting Tips

The following commands can help troubleshoot the OOD Options Ping feature:

•debug ccsip all—shows all Session Initiation Protocol (SIP)-related debugging.

•show dial-peer voice x—shows configuration of keepalive information.

Router# show dial-peer voice | in options

voice class sip options-keepalive up-interval 60 down-interval 30 retry 5

voice class sip options-keepalive dial-peer action  = active

•show dial-peer voice summary—shows Active or Busyout dial-peer status.

Router# show dial-peer voice summary

           AD                   PRE PASS

TAG TYPE  MIN  OPER PREFIX    DEST-PATTERN KEEPALIVE

111 voip  up     up               0 syst   active 

9  voip   up    down              0 syst   busy-out

Configuring an Error Response Code upon an Out-of-Dialog OPTIONS Ping Failure

Cisco Unified Border Element (Cisco UBE) provides an option to configure the error response code when a dial peer is busied out because of an Out-of-Dialog OPTIONS ping failure.

The OPTIONS ping mechanism monitors the status of a remote Session Initiation Protocol (SIP) server, proxy or endpoints. Cisco UBE monitors these endpoints periodically. When there is no response from these monitored endpoints, the configured dial peer is busied out. If the dial-peer endpoint is busied out due to an OPTIONS ping failure, the call is passed on to the next dial-peer endpoint if an alternate dial peer is configured for the same destination. Otherwise the error response 404 is sent. This feature provides the option of configuring the error response code to reroute the call. Therefore when a dial peer is busied out due to the OPTIONS ping failure, the SIP error code configured in the inbound dial-peer is sent as a response.

To configure the SIP error code response, perform the following tasks:

•"Configuring an Error Response Code upon an Out-of-Dialog OPTIONS Ping Failure at the Global Level" section (required)

•Configuring an Error Response Code upon an Out-of-Dialog OPTIONS Ping Failure at the Dial Peer Level (required)

Prerequisites

•To enable this feature, you must have Cisco IOS Release 15.0(1)XA or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

•The Cisco UBE Out-of-Dialog (OOD) OPTIONS Ping for Specified SIP Servers or Endpoints feature should be configured before configuring this error response code for a ping OPTIONS failure.

Restrictions

The error code configuration will not have any effect if it is configured on the outbound dial peer.

Configuring an Error Response Code upon an Out-of-Dialog OPTIONS Ping Failure at the Global Level

Table 3 describes the SIP error codes.

To configure the error response code for the OPTIONS ping failure to support the Cisco Unified Border Element at the global level, perform the steps in this section.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice service voip

4. sip

5. error-code-override options-keepalive failure sip-status-code-number

6. end

Configuring an Error Response Code upon an Out-of-Dialog OPTIONS Ping Failure at the Dial Peer Level

To configure the error response code for the OPTIONS ping failure to support the Cisco Unified Border Element at the dial-peer level, perform the steps in this section.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice voice-dial-peer-tag voip

4. voice-class sip error-code-override options-keepalive failure {sip-status-code-number | system}

5. end

	Command or Action	Purpose
Step 1	enable Example: Router> enable	Enables privileged EXEC mode. •Enter your password if prompted.
Step 2	configure terminal Example: Router# configure terminal	Enters global configuration mode.
Step 3	dial-peer voice voice-dial-peer-tag voip Example: Router(config)# dial-peer voice 234 voip	Enters dial peer voice configuration mode.
Step 4	voice-class sip error-code-error-override options-keepalive failure {sip-status-code-number | system} Example: Router(config-dial-peer)# voice-class sip error-code-override options-keepalive failure 500	Configures the specified SIP error code number. •sip-status-code-number —SIP status code to be sent for an options keepalive failure. Range: 400 to 699. Default: 503. •Table 3 provides more details about these error codes. Note If the system keyword is configured, the global level configuration will override the dial-peer configuration.
Step 5	end Example: Router(config-dial-peer)# end	Exits dial peer voice configuration mode and returns to privileged EXEC mode.

Troubleshooting Tips

The following debug commands display any error that occurs with the error code response:

•debug ccsip messages—shows SIP messages.

Router# debug ccsip messages

SIP Call messages tracing is enabled

•debug ccsip all—shows all SIP-related debugging.

Router# debug ccsip all

This may severely impact system performance. Continue? [confirm]

All SIP Call tracing is enabled

Configuring SIP Parameters

The SIP Parameters feature allow customers to add, remove, or modify the SIP parameters in the SIP messages going out of a border element. The SIP message is generated from the standard signaling stack, but runs the message through a parser which can add, delete or modify specific parameters. This allows interoperability with additional third party devices that require specific SIP message formats. All SIP methods and responses are supported, profiles can be added either in dial-peer level or global level. Basic Regular Expression support would be provided for modification of header values. SDP parameters can also be added, removed or modified.

This feature is applicable only for outgoing SIP messages. Changes to the messages are applied just before they are sent out, and the SIP SPI code does not remember the changes. Because there are no restrictions on the changes that can be applied, users must be careful when configuring this feature - for example, the call might fail if a regular expression to change the To tag value is configured.

The all keyword is used to apply rules on all requests and responses.

Prerequisites

To enable this feature, you must have Cisco IOS Release XXX or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

Restrictions

•This feature applies to outgoing SIP messages.

•This feature is disabled by default.

•Removal of mandatory headers is not supported.

•This feature allows removal of entire MIME bodies from SIP messages. Addition of MIME bodies is not supported.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice number voip

4. voice-class sip profiles group-number

5. response option sip-header option ADD word CR

6. exit

7. end

Example

!

!

!

voice service voip

allow-connections sip to sip

redirect ip2ip

sip

early-offer forced

midcall-signaling passthru

sip-profiles 1

!

!

!

voice class sip-profiles 1

request INVITE sip-header Supported remove

request INVITE sip-header Min-SE remove

request INVITE sip-header Session-Expires remove

request INVITE sip-header Unsupported modify "Unsupported:" "timer"

!

!

!

Configurable SIP Parameters via DHCP

The Configurable SIP Parameters via DHCP feature allows a Dynamic Host Configuration Protocol (DHCP) server to provide Session Initiation Protocol (SIP) parameters via a DHCP client. These parameters are used for user registration and call routing.

The DHCP server returns the SIP Parameters via DHCP options 120 and 125. These options are used to specify the SIP user registration and call routing information. The SIP parameters returned are the SIP server address via Option 120, and vendor-specific information such as the pilot, contract or primary number, an additional range of secondary numbers, and the SIP domain name via Option 125.

In the event of changes to the SIP parameter values, this feature also allows a DHCP message called DHCPFORCERENEW to reset or apply a new set of values.

The SIP parameters provisioned by DHCP are stored, so that on reboot they can be reused.

Prerequisites for Configurable SIP Parameters via DHCP

•To enable this feature, you must have Cisco IOS Release12.4(22)YB or a later release installed and running on your Cisco gateway. For detailed information on platform availability and subsequent releases, see the "Feature Information for SIP-to-SIP Connections on a Cisco Unified Border Element" section.

•A DHCP interface has to be associated with SIP before configurable SIP parameters via DHCP can be enabled.

Restrictions for Configurable SIP Parameters via DHCP

•DHCP Option 120 is the standard DHCP option (RFC3361) to get a SIP server address, and this can be used by any vendor DHCP server. Only one address is supported, which is in the IPv4 address format. Multiple IPv4 address entries are not supported. Also, there is no support for a DNS name in this or for any port number given behind the IPv4 address.

•DHCP Option 125 (RFC 3925) provides vendor-specific information and its interpretation is associated with the enterprise identity. The primary and secondary phone numbers and domain are obtained using Option 125, which is vendor-specific. As long as other customers use the same format as in the Next Generation Network (NGN) DHCP specification, they can use this feature.

•A primary or contract number is required in suboption 202 of DHCP Option 125. There can be only one instance of the primary number and not multiple instances.

•Multiple secondary or numbers in suboption 203 of DHCP Option 125 are supported. Up to five numbers are accepted and the rest ignored. Also, they have to follow the contract number in the DHCP packet data.

•Authentication is not supported for REGISTER and INVITE messages sent from a Cisco Unified Border Element that uses DHCP provisioning

•The DHCP provisioning of SIP Parameters is supported only over one DHCP interface.

•The DHCP option is available only to be configured for the primary registrar. It will not be available for a secondary registrar.

Information About Configurable SIP Parameters via DHCP

To perform basic Configurable SIP Parameters via DHCP configuration tasks, you should understand the following concepts:

•Cisco Unified Border Element Support for Configurable SIP Parameters via DHCP

•DHCP to Provision SIP Server, Domain Name, and Phone Number

•DHCP-SIP Call Flow

•DHCP Message Details

Cisco Unified Border Element Support for Configurable SIP Parameters via DHCP

The Cisco Unified Border Element provides the support for the DHCP provisioning of the SIP parameters.

The NGN is modeled using SIP as a VoIP protocol. In order to connect to NGN, the User to Network Interface (UNI) specification is used. Cisco TelePresence Systems (CTS), consisting of an IP Phone, a codec, and Cisco Unified Communications Manager, are required to internetwork over the NGN for point-to-point and point-to-multipoint video calls. Because Cisco Unified Communications Manager does not provide a UNI interface, there has to be an entity to provide the UNI interface. The Cisco Unified Border Element provides the UNI interface and has several advantages such as demarcation, delayed offer to early offer, and registration.

Figure 1 shows the Cisco Unified Border Element providing the UNI interface for the NGN.

Figure 1 Cisco NGN with Cisco Unified Border Element providing UNI interface

DHCP to Provision SIP Server, Domain Name, and Phone Number

NGN requires Cisco Unified Border Element to support DHCP (RFC 2131 and RFC 2132) to provision the following:

•IP address for Cisco Unified Border Element's UNI interface facing NGN

•SIP server address using option 120

•Option 125 vendor specific information to get:

–Pilot number (also called primary or contract number), there is only one pilot number in DHCPACK, and REGISTER is done only for the pilot number

–Additional numbers, or secondary numbers, are in DHCPACK; there is no REGISTER for additional numbers

–SIP domain name

•DHCPFORCERENEW to reset or apply a new set of SIP parameters (RFC 3203)

DHCP-SIP Call Flow

The following scenario shows the DHCP messages involved in provisioning information such as the IP address for UNI interface, and SIP parameters including the SIP server address, phone number, and domain name, along with how SIP messages use the provisioned information.

Figure 2 shows the DHCP and SIP messages involved in obtaining the SIP parameters and using them for REGISTER and INVITE.

Figure 2 DHCP-SIP Call Flow

DHCP Message Details

The DHCP call flow involved in obtaining Cisco Unified Border Element provision information, including the IP address for UNI interface and SIP information such as phone number, domain, and SIP server, is shown in Figure 2.

Figure 3 DHCP Message Details

The DHCP messages involved in provisioning the SIP parameters are described in Steps 1 to 6.

1. F1: The Cisco Unified Border Element DHCP client sends a DHCPDISCOVER message to find the available NGN DHCP servers on the network and obtain a valid IPv4 address. The Cisco Unified Border Element DHCP client identity (computer name) and MAC address are included in this message.

2. F2: The Cisco Unified Border Element DHCP client receives a DHCPOFFER message from each available NGN DHCP server. The DHCPOFFER message includes the offered DHCP server's IPv4 address, the DHCP client's MAC address, and other configuration parameters.

3. F3: The Cisco Unified Border Element DHCP client selects an NGN DHCP server and its IPv4 address configuration from the DHCPOFFER messages it receives, and sends a DHCPREQUEST message requesting its usage. Note that this is where Cisco Unified Border Element requests SIP server information via DHCP Option 120 and vendor- identifying information via DHCP Option 125.

4. F4: The chosen NGN DHCP server assigns its IPv4 address configuration to the Cisco Unified Border Element DHCP client by sending a DHCPACK message to it. The Cisco Unified Border Element DHCP client receives the DHCPACK message. This is where the SIP server address, phone number and domain name information are received via DHCP options 120 and 125. The Cisco Unified Border Element will use the information for registering the phone number and routing INVITE messages to the given SIP server.

5. F5: When NGN has a change of information or additional information (such as changing SIP server address from 1.1.1.1 to 2.2.2.2) for assigning to Cisco Unified Border Element, the DHCP server initiates DHCPFORCERENEW to the Cisco Unified Border Element. If the authentication is successful, the Cisco Unified Border Element DHCP client accepts the DHCPFORCERENEW and moves to the next stage of sending DHCPREQUEST. Otherwise DHCPFORCERENEW is ignored and the current information is retained and used.

6. F6 and F7: In response to DHCPFORCERENEW, similar to steps F3 and F4, the Cisco Unified Border Element requests DHCP Options 120 and 125. Upon getting the response, SIP will apply these parameters if they are different by sending an UN-REGISTER message for the previous phone number and a REGISTER message for the new number. Similarly, a new domain and SIP server address will be used. If the returned information is the same as the current set, it is ignored and hence registration and call routing remains the same.

How to Configure SIP Parameters via DHCP

To configure SIP parameters via DHCP, perform the following tasks:

•Configuring the DHCP Client (Required)

•Enabling the SIP Configuration (Required)

•Configuring a SIP Outbound Proxy Server (Required)

•Enabling Forced Update of SIP Parameters via DHCP (Required)

Configuring the DHCP Client

To receive the SIP configuration parameters the Cisco Unified Border Element has to act as a DHCP client. This is because in the NGN network, a DHCP server pushes the configuration to a DHCP client. Thus the Cisco Unified Border Element must be configured as a DHCP client.

Perform this task to configure the DHCP client.

Prerequisites

You must configure the ip dhcp client commands before entering the ip address dhcp command on an interface to ensure that the DHCPDISCOVER messages that are generated contain the correct option values. The ip dhcp client commands are checked only when an IP address is acquired from DHCP. If any of the ip dhcp client commands are entered after an IP address has been acquired from DHCP, the DHCPDISCOVER messages' correct options will not be present or take effect until the next time the router acquires an IP address from DHCP. This means that the new configuration will only take effect after either the ip address dhcp command or the release dhcp and renew dhcp EXEC commands have been configured.

SUMMARY STEPS

1. enable

2. configure terminal

3. interface type number

4. ip address dhcp

5. ip dhcp client request sip-server-address

6. ip dhcp client request vendor-identifying-specific

7. exit

Router(config)# interface gigabitethernet 0/0

Enabling the SIP Configuration

Enabling the SIP configuration allows the Cisco Unified Border Element to use the SIP parameters received via DHCP for user registration and call routing.

Perform this task to enable the SIP configuration.

Prerequisites

The dhcp interface command has to be entered to declare the interface before the registrar and credential commands are entered.

SUMMARY STEPS

1. enable

2. configure terminal

3. interface type number

4. sip-ua

5. dhcp interface type number

6. registrar dhcp expires seconds random-contact refresh-ratio seconds

7. credentials dhcp password [0 | 7] password realm domain-name

8. exit

Router(config)# interface gigabitethernet 0/0