Table Of Contents

SIP-I Transparency and Profile Support

Contents

Restrictions for SIP-I Transparency and Profile Support

Information about SIP-I Transparency and Profile Support

How to Implement SIP-I Transparency and Profile Support

Examples of Show Commands

SIP-I Transparency and Profile Support

---

This feature enables the Session Border Controller (SBC) to pass through the ISDN User Part (ISUP) parameters in Session Initiation Protocol (SIP) messages that may have been added by a SIP or Public Switched Telephone Network (PSTN) interworking gateway.

SIP is an application layer protocol for establishing, terminating, and modifying multimedia sessions. ISUP is a level-four protocol used in SS7 networks to control telephone calls and for maintenance of the network, such as blocking circuits or resetting circuits. The mapping between these two protocols is carried out by Media Gateway Controller (MGC). In the SBC, the ISUP parameters may be carried in the SIP Request-Uniform Resource Identifier (URI) or the SIP message body.

---

Note For ACE SBC Release 3.0.00 and later, this feature is supported in the unified model only.

---

Feature History for SIP-I Transparency and Profile Support

Release	Modification
ACE SBC Release 3.0.00	This feature was introduced on the Cisco 7600 series router along with support for the SBC unified model.

Contents

This module contains the following sections:

•Restrictions for SIP-I Transparency and Profile Support

•Information about SIP-I Transparency and Profile Support

•How to Implement SIP-I Transparency and Profile Support

•Examples of Show Commands

Restrictions for SIP-I Transparency and Profile Support

The following restrictions and limitations apply to Session Initiation Protocol (SIP)-I transparency and profile support:

•The SBC allows only non-Session Description Protocol (SDP) bodies in SIP messages to pass through or be stripped. This feature is further limited to a single per-adjacency flag.

•If an existing single per-adjacency flag controls the passing through of non-SDP bodies, this flag does not control non-essential methods.

•If multiple SDP content types are present in a request, the method is rejected and a 501 response code is generated.

•If dual tone multifrequency (DTMF) internetworking is enabled for a call, the INFO messages containing a DTMF digit may not pass through.

•The SBC does not support Secure Multipurpose Internet Mail Extensions (S/MIME) encryption or decryption. While the SBC may allow encrypted bodies to pass through, it does not modify them.

•In compliance with Section 8.2.1.1 of RFC 3398, the SBC does not support a From header without a username.

•The total size of the MIME bodies and associated header allowed to pass through is limited to approximately 1000 bytes. The final size allowed depends on the structure of the headers and MIME bodies and should not exceed 2000 bytes.

•The SBC may not preserve the original order of MIME bodies and may insert the SDP as the first body part.

•This feature does not work in conjunction with H.323.

•Since the SBC considers BYE requests on a hop-by-hop basis, it does not pass any information using a BYE response it received.

•The SBC allows the user=phone URI parameter on the Request-URI to pass through.

•The SBC may alter the MIME boundary of a message.

Information about SIP-I Transparency and Profile Support

The SBC supports the following:

•Application or SDP is processed on INVITE, UPDATE, and PRACK requests and their responses.

•Application or DTMF-info is processed on INFO to allow DTMF tones to pass through.

•The NOTIFY messages on message or SIP-frag is analyzed to find out whether it indicates that a subscription or refer dialog is to be terminated.

How to Implement SIP-I Transparency and Profile Support

This section contains the steps for configuring a SIP adjacency for SIP-I passthrough.

SUMMARY STEPS

1. configure

2. sbc service-name

3. sbe

4. adjacency sip adjacency-name

5. sipi passthrough

6. exit

DETAILED STEPS

	Command or Action	Purpose
Step 1	configure Example: host1/Admin# configure	Enables global configuration mode.
Step 2	sbc service-name Example: host1/Admin(config)# sbc mysbc	Enters the mode of an SBC service. •Use the service-name argument to define the name of the service.
Step 3	sbe Example: host1/Admin(config-sbc)# sbe	Enters the mode of the signaling border element (SBE) function of the SBC.
Step 4	adjacency sip adjacency-name Example: host1/Admin(config-sbc-sbe)# adjacency sip test	Enters the mode of an SBE SIP adjacency. •Use the adjacency-name argument to define the name of the service.
Step 5	sipi passthrough Example: host1/Admin(config-sbc-sbe-adj-sip)# sipi passthrough	Configures the SIP adjacency for SIP-I passthrough.
Step 6	exit Example: host1/Admin(config-sbc-sbe-adj-sip)# exit	Exits the adj-sip mode and returns to the SBE mode.

Examples of Show Commands

# show services sbc mySbc sbe adjacencies SipToIsp42 detail

SBC server mySbc

Adjacency SipToIsp42 

Status:  Attached

Signaling address: 10.2.0.122:5060

Signaling-peer:    200.200.200.179:8888

Force next hop:   No

Account:   core

Group:     None

In Header Profile:    Default

Out Header Profile:   Default

In method profile:    Default

Out method profile:   Default

In UA option profile: Default

Out UA option profile:   Default

In proxy option profile: Default

Priority set name:       Default

Local-id:             None

Rewrite REGISTER:     Off

Target address:       None

NAT Status:           Auto-Detect

Reg-min-expiry:       3000 seconds

Fast-register:        Enabled

Fast-register-int:    30 seconds

Authenticated mode:   None

Authenticated realm:  None

Authenticated nonce life time: 300 seconds

IMS visited NetID:    NOne

Inherit profile:      Default

Force next hop:       No

Home network ID:      None

UnEncrypt key data:   None

SIPIpassthrough:      No

Rewrite from domain:  Yes

Rewrite to header:    Yes

Media passthrough:    No

Preferred transport:  UDP

Hunting Triggers:     Global Triggers

Redirect mode:        Passthrough

Security:          Untrusted