Page History

1. Introduction

This document provides configuration and provisioning guidance to enable SIP transparency on

1.1 Audience

This document is intended for design engineers, system engineers and operations staff for the purpose of deploying SIP on a 

• Phone: +1 888-391-3434 (Toll-free) or +1 978-614-8589 (Direct)
• Web: https://doc.rbbn.com/display/PORTAL/Salesforce+Login

1.2 Requirements

This document describes configuration procedures related to version 4.2 of the 

1.3 References

• Spacevars
  0 series4

   product documentation—Go to

  Spacevars
  0 company

  Documentation and Support Portal at: https://doc.rbbn.com/display/ALLDOC/SBC+5000-7000-SWe+Documentation
• Transparency Profile Configuration Examples

2. SIP Transparency

For some SIP elements, transparency is a frequently-debated topic. When transparency for a SIP header or body is desired, the user may often compare the element against a SIP Proxy which is a typical benchmark for significant transparency. Considered a popular comparison, this topic needs to addressed up front when discussing SIP transparency.

2.1 SIP Proxy vs. SIP B2BUA

The SIP devices that connect most peers and endpoints are typically a SIP Proxy or Back-to-Back User Agent (B2BUA). The most transparent device is the SIP Proxy; its behaviors are primarily specified in RFC 3261 and are very basic in its message processing capabilities. The required transparency of a Proxy is one of its few strengths when compared to a B2BUA.

Although an

While RFC 3261 goes into detail describing the required behavior of a SIP Proxy, its description for a B2BUA could be considered somewhat terse: "Since it is a concatenation of a UAC [User Agent Client] and UAS [User Agent Server], no explicit definitions are needed for its behavior." This statement notwithstanding, debate and research into the transparency behavior of a B2BUA continued, but seemingly without consensus. An often referenced IETF draft (draft-marjou-sipping-01) submitted to the SIPPING WG was not accepted as a working group document.

Admittedly, complete SIP transparency is not achievable due to the needs and requirements of changing some headers. Even a SIP Proxy is not completely transparent. In many scenarios the ability to control and even minimize transparency is a strength of a B2BUA/

• SIP Normalization (including arbitrary SIP Message Manipulation)
• Topology Hiding
• Protocol Translation
• Codec Transcoding (allowing a non-transparent SDP)

Fundamentally, the 

This document describes the

3. 

Spacevars
0 product

SIP Transparency and Control Mechanisms

Since its inception, the 

3.1 Existing 

Spacevars
0 product

Transparency Mechanisms

Prior to release 4.0, SIP header and body transparency was controlled primarily by the use of individual Transparency Flags, mostly within the IP Signaling Profile (IPSP; ipSignalingProfile > commonIpAttributes > transparencyFlags) and apply on the egress leg of a session (egress relative to the SIP message).

 If a header or body did not have a specific flag on the

When a transparency flag was added for a header, it meant that the header was now known and that the unknownHeader flag no longer controlled it.

This methodology was problematic as headers transitioned from unknown to known on the

Starting in version 4.0, the 

3.2 Transparency Profile

A Transparency Profile is a user-configurable profile allowing the user to transparently pass almost any SIP header/body through the

Both already-known and previously-unknown SIP headers and bodies can be configured in a Transparency Profile. By default, no headers or message bodies are present in a Transparency Profile. Up to 256 unique Transparency Profiles can be created on the 

When a header or body is specified in a Transparency Profile, the profile will take precedence over any applicable Transparency Flag. For headers not specified in a transparency profile, the setting of existing Transparency Flags will continue to determine the transparency of that header. In this way, a Transparency Profile can either override or augment existing Transparency Flag settings. This document will describe some usage scenarios where both mechanisms may be used together.

When configuring a Transparency Profile for specific SIP headers,

3.2.1 SIP Message Header

Starting in version 4.0, the 

set profiles services transparencyProfile <profile> sipHeader <SIP Header>

where <SIP Header> is case insensitive, supports up to 31 characters, and supports an "all" entry to match all headers (see section 3.3 for exceptions).

The ability to exclude specific headers from transparency is primarily intended for use in conjunction with the "all" header option.

SIP headers are also configurable using compact form. When configuring specific headers in a Transparency Profile,

Compact form can be received by the

The 

The following SIP headers are not controlled by the Transparency Profile (or any Transparency Flags), and are ignored if configured in a

Transparency Profile:

• Allow
• Call-ID
• CSeq
• Max-Forwards
• Require
• RSeq
• Supported

If Contact Header is specified in a Transparency Profile, then it is treated as full Contact transparency and it will take precedence over other Contact related flags (such as useZoneLevelDomainNameInContact).

3.2.2 SIP Message Body

set profiles services transparencyProfile <profile> sipMessageBody <Content-Type> 

where <Content-Type> is case insensitive, supports up to 127 characters, and supports an "all" entry to match all message bodies except those described in the below list.

The following Content-Types are not controlled by the Transparency Profile and are ignored if configured in a profile:

• application/sdp
• application/dtmf
• application/dtmf-relay
• application/sonus-media
• application/broadsoft
• application/isup
• multipart/mixed
• multipart/related

Multipart/mixed and multipart/related are ignored because the 

A Transparency Profile cannot control the SDP (application/sdp). The SDP and its controls will be discussed later in this document.

The other exceptions are due to existing Relay Flags (see table below) elsewhere within the 

See

Relay Flags below for details.

3.3 SIP Header Transparency Behaviors

3.3.

1 Non-Transparent Methods and Scenarios

The following SIP methods are not supported by a Transparency Profile (or any Transparency Flags):

• ACK (even if the endToEndAck flag is enabled)
• CANCEL
• PRACK

3.3.

2 Non-Transparent Headers

The following SIP headers are not supported by a Transparency Profile (or any Transparency

flags):

• Allow

• Call-ID

• CSeq

• Max-Forwards

• Require

• RSeq

• Supported

These SIP headers are entirely added and/or modified by the 

3.3.3 Transparently Pass or Block Option Tags/Methods of Allow/Require/Supported Headers

Option tags/methods of the following SIP headers can be transparently passed or blocked by configuring the SIP Param Filter Profile.

• Allow
• Require
• Supported

3.3.

4 In-Dialog vs. Out-of-Dialog

Some header behaviors vary depending on whether they are received in or out of an existing dialog. While the Transparency Profile has been extended in 4.2 to apply to out-of-dialog messages, there are some specific headers whose behavior is not under the control of a Transparency Profile (or Transparency Flags) when received in out-of-dialog messages.

A Dialog "represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The dialog represents a context in which to interpret SIP messages." (reference: RFC 3261)

The 

Out-of-Dialog header behavior irrespective of the Transparency Profile or Flags:

3.4 SDP

The

1. Audio
2. Video Main
3. Video Extended (for Content Share)
4. Binary Floor Control Protocol (UDP and TCP)
5. Far End Camera Control (FECC)
6. Message Session Relay Protocol ( MSRP)

For all the above mentioned media types (with the exception of Audio), the 

• C line
• RTCP attributes
• Media direction (a= sendrecv/sendonly/inactive/recvonly)

• Spacevars
  0 product

  supports Secure Real-Time Transport Protocol (SRTP) media pass-through for SRTP and Secure Real-Time Transport Control Protocol (SRTCP) media streams.

For Audio, the 

• rtpmap and fmtp – For supported codecs, see Audio Support and Video Support.
• Fax Relay attributes (T38)
• ptime & maxptime

You must enable Video (assign a valid video bandwidth) and Audio transparency to achieve the above described behavior using the below CLI syntax.

% set profiles media packetServiceProfile <packetServiceProfileName> packetToPacketControl transcode transcoderFreeTransparency
% set addressContext <addressContextName> zone <zoneName> sipTrunkGroup <trunkGroupName> media sdpAttributesSelectiveRelay enabled
% set addressContext <addressContextName> zone <zoneName> sipTrunkGroup <trunkGroupName> media lateMediaSupport passthru 

3.4.1 SRTP Pass-through

The following diagram illustrates the media flow for an SRTP pass-through call.

To control this SRTP media pass-through, a new allowPassthru flag is introduced to the secureRtpRtcp of PSP. When allowPassthru flag is enabled along with the security enableSrtp flag, it allows SBC topass-through SRTPmedia without authenticating, decrypting, and encrypting it internally. When selected, this flag prioritizes SRTP pass-through media over terminated SRTP media. When disabled, this flag terminates all SRTP and SRTCP media for authentication, encryption, or decryption. This flag is disabled by default.

3.4.2 SDP Transparency Flag

Make note that the sdpTransparencyState signaling object within the SIP Trunk Group should not be considered a general use parameter.  It is specific to some functionality (mainly ICE) and environments; however, this flag does not apply to all types of call flows.

Anchor
RelayFlags RelayFlags

3.5 Relay Flags

Relay Flags exist mostly within the IP Signaling Profile (IPSP; ipSignalingProfile > commonIpAttributes > relayFlags) and apply on the ingress leg of a session (ingress relative to the SIP message).
Relay Flags are intended mainly for SIP Methods (Requests) and Responses (and some SIP message bodies) that normally get consumed or modified by the 

1. Documentation.

   Code Block

   > show table profiles callParameterFilterProfile Description: Profile used for routing based on SIP message type. Possible completions: SIP_MSG_TYPE_INFO - SIP Message Type is Info SIP_MSG_TYPE_MESSAGE - SIP Message Type is Message SIP_MSG_TYPE_NOTIFY - SIP Message Type is Notify SIP_MSG_TYPE_REFER - SIP Message Type is Refer SIP_MSG_TYPE_REGISTER - SIP Message Type is Register SIP_MSG_TYPE_SUBSCRIBE - SIP Message Type is Subscribe none - seed data for provisioning support

   All > Profiles > Call Parameter Filter Profile

   Caption
   0 Figure 1 Call Parameter Filter Profile List showing SIP_MSG_TYPE_REFER profile
   Image Modified

   Note
   A new script SONS_SIP_REFER_RELAY is seeded in both ERE and PSX.

2. Disable the Refer relay flag in IPSP.

   Code Block
   % set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags refer disable

3. Enable the Notify relay in Egress side on IPSP to relay REFER for DN/Username/FQDN match.

   Code Block
   % set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags notify enable

   All > Profiles > Signaling > Ip Signaling Profile > Common Ip Attributes > Relay Flags

   Caption
   0 Figure 1 Notify and Refer relay flags
   Image Modified

4. Create a new routing label with the script SONS_SIP_REFER_RELAY to trigger process refer request feature.

   Note
   The routing label action must be set as script.

   Code Block
   % set global callRouting routingLabel <routing_label> script SONS_SIP_REFER_RELAY action script

   All > Global > Call Routing > Routing Label

   Caption
   0 Figure 1 Creating a Routing Label
   Image Modified

   Caption
   0 Figure 1 Routing Label screen
   Image Modified

5. Configure a DN criteria in the standard route and attach the SIP_MSG_TYPE_REFER profile to the standard route by executing the following command:

   Code Block
   % set global callRouting route none Sonus_NULL Sonus_NULL standard <Matched_DN or FQDN> 1 all ALL SIP_MSG_TYPE_REFER Sonus_NULL routingLabel <routing_label>

   For DN (Directory Number) or username

   Code Block
   % set global callRouting route none Sonus_NULL Sonus_NULL standard <Matched_DN or Username> 1 all ALL SIP_MSG_TYPE_REFER Sonus_NULL routingLabel <routing_label>

   For FQDN with DN or username

   Note
   The corresponding Sip domain group must be configured in Spacevars 0 company .

   Code Block
   % set global sipDomain <Matched_domain_name > % set global callRouting route none Sonus_NULL Sonus_NULL standard <Matched_DN or Username> 1 all ALL SIP_MSG_TYPE_REFER <Matched_domain_name> routingLabel <routing_label>

   All > Global > Call Routing > Route

   Caption
   0 Figure 1 Creating a Route
   Image Modified

   Caption
   0 Figure 1 Route screen
   Image Modified

6. Execute the following commands to view the call detail status and call media status.

   Code Block
   > show status global callDetailStatus or > show status global callMediaStatus

3.7 Transparency Profile Usage

As discussed previously, the Transparency Profile does not deprecate any existing Transparency Flag. Those flags continue to function as designed. When a header/body is specified in a Transparency Profile, then the profile takes precedence over any applicable Transparency Flag. For headers/bodies not specified in a transparency profile, the setting of existing Transparency Flags continues to determine the transparency of that header.

When configuring a Transparency Profile for specific SIP headers,

set profiles services transparencyProfile MAX_TRANSPARENCY sipHeader all
set profiles services transparencyProfile MAX_TRANSPARENCY sipMessageBody all
set profiles services transparencyProfile MAX_TRANSPARENCY state enabled
commit
set addressContext <AC> zone <ZONE> sipTrunkGroup <TG> services transparencyProfile MAX_TRANSPARENCY
commit 

set profiles services transparencyProfile ALMOST_ALL_HDRS sipHeader all
set profiles services transparencyProfile ALMOST_ALL_HDRS sipHeader History-Info ignoreTransparency yes
set profiles services transparencyProfile ALMOST_ALL_HDRS state enabled
commit
set addressContext <AC> zone <ZONE> sipTrunkGroup <TG> services transparencyProfile ALMOST_ALL_HDRS
commit

set profiles services transparencyProfile IDENTITY_HDRS sipHeader Identity
set profiles services transparencyProfile IDENTITY_HDRS sipHeader y
set profiles services transparencyProfile IDENTITY_HDRS sipHeader Identity-Info
set profiles services transparencyProfile IDENTITY_HDRS sipHeader n
set profiles services transparencyProfile IDENTITY_HDRS state enabled
commit
set addressContext <AC> zone <ZONE> sipTrunkGroup <TG> services transparencyProfile IDENTITY_HDRS
commit
set profiles signaling ipSignalingProfile <IPSP> commonIpAttributes transparencyFlags unknownHeader disable
commit

% set addressContext default zone ZONE1 sipTrunkGroup TG_SBX_INT media sdpAttributesSelectiveRelay enabled
% set addressContext default zone ZONE2 sipTrunkGroup TG_SBX_EXT media sdpAttributesSelectiveRelay enabled

% set profiles media packetServiceProfile PSP_INT packetToPacketControl transcode transcoderFreeTransparency 
% set profiles media packetServiceProfile PSP_EXT packetToPacketControl transcode transcoderFreeTransparency

% set profiles media packetServiceProfile PSP_INT audioTransparency unknownCodecBitRate 124
% set profiles media packetServiceProfile PSP_EXT audioTransparency unknownCodecBitRate 124

% set profiles media packetServiceProfile PSP_INT audioTransparency unknownCodecPacketSize 10
% set profiles media packetServiceProfile PSP_EXT audioTransparency unknownCodecPacketSize 10

% set profiles media packetServiceProfile PSP_INT flags reserveBwForPreferredAudioCommonCodec enable
% set profiles media packetServiceProfile PSP_EXT flags reserveBwForPreferredAudioCommonCodec enable