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 

1.2 Support

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

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

The 

3.2 SIP Transparency Profile

When configuring a Transparency Profile for specific SIP headers,

The following transparency is not supported by the

In late media scenarios, the

For configuration details, see Service Profiles - Transparency Profile (EMA) or Transparency Profile - CLI.

3.2.1 SIP Message Header

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

• RAck

• P-Associated-URI

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/alternative

Multipart/mixed and multipart/alternative 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.2.3 Inter-working with IP Signaling Profile

SIP Transparency Profile provides advanced control of the transparency of headers and message bodies. However, customers may continue with the existing (albeit simple) IPSP transparency controls in PSX/e-PSX/ERE.

Using message body transparency as an example:

• If a message body is allowed by the IPSP but configured to be ignored by the Transparency Profile, it is not transparently passed through.
• If a message body is allowed by the IPSP but configured to be excluded by the Transparency Profile for a particular SIP method, it is not transparently passed through for that specific SIP method.
• If specific message bodies are allowed by the IPSP, but transparency of 'all' message bodies is configured in the Transparency Profile, all types of message bodies are transparently passed through.
• If 'Unknown Body' transparency is enabled in the IPSP, but an unknown message body is configured to be ignored (or excluded for a specific SIP method) by the Transparency Profile, it is not transparently passed through.

3.3 SIP Header Transparency

Header transparency is based on the headers that are present in the Transparency Profile of the egress trunk group for requests and headers that are present in the ingress trunk group for responses. By default, no headers are present in the Transparency Profile.

3.3.1 Allowed Values for a SIP Header in the Transparency Profile

A 'sipHeader' in the Transparency Profile can be composed of:

• Any string with a maximum length of 31 characters
• Any case, lower/upper/mixed
• Special characters are allowed

3.3.2 SIP Headers not Under Transparency Control in Relay Scenarios

Some headers are not under the control of transparency flags in relay scenarios. These headers can be classified into three categories as shown in the below table:

3.3.3 SIP Headers Not Transparently Passed in Calls

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

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

• RAck

• P-Associated-URI

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

3.3.4 SIP Headers Brought Under Transparency Control in Relay Scenarios

Previously, the following headers were transparently passed by the

• Accept
• SIP-ETag
• SIP-If-Match
• Suppress-If-Match

3.3.5 SIP Header Transparency Behaviors

There are some exceptions to the transparency mechanisms. Some SIP Methods and some SIP headers are not affected by any configurable transparency mechanism, while other headers may not be affected by transparency controls in some scenarios (in-dialog vs. out-of-dialog).

3.3.6 Non-Transparent Methods and Scenarios

The following SIP method is not supported by a Transparency Profile (or any Transparency flags):

• ACK (even if the endToEndAck flag is enabled)

3.3.7 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.8 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 

If "Session-Expires" header is configured, the SBC passes the "Min-SE" header and their values transparently to the egress remote peer. This behavior is achieved either by configuring “all” header or “Session-Expires” and “Min-SE” header in the Transparency Profile. The Keep-Alive behavior must be disabled by setting “Session-Expires” to “0” in the respective SIP Trunk Group.

For example,

set profiles services transparencyProfile ALL_HEADER sipHeader all 
set profiles services transparencyProfile SIP_HEADER sipHeader Session-Expires ignoreTransparency no
set profiles services transparencyProfile SIP_HEADER sipHeader Min-SE ignoreTransparency no 
set addressContext default zone Zone1 sipTrunkGroup TG1 signaling timers sessionKeepalive 0

If "all" header in Transparency Profile is configured and SBC supports "Session Keep Alive" mechanism, the "Session-Expiry" and "Min-SE" headers are excluded from the Transparency Profile by setting ignoreTransparency as “yes”.

For example,

set profiles services transparencyProfile ALL_HEADER sipHeader all 
set profiles services transparencyProfile ALL_HEADER sipHeader Session-Expires ignoreTransparency yes
set profiles services transparencyProfile ALL_HEADER sipHeader Min-SE ignoreTransparency yes         

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

3.4 SIP Message Body Transparency

Message body transparency is based on message bodies that are present in the Transparency Profile of the egress trunk group for requests and content-types/bodies that are present in the ingress trunk group for responses. By default, no message bodies are present in the Transparency Profile.

3.4.1 Allowed Values for a Content Type in the Transparency Profile

The allowed range for a "contentType" in the Transparency Profile includes:

• Any string with a maximum length of 127 characters
• Any case, lower/upper/mixed
• Special characters are allowed
• An existing transparency flag for that Content-Type in IP Signaling Profile (IPSP) is not required

3.4.2 Transparency of Multi-part Message Bodies

The

For example, consider a SIP message with content-type 'multipart/mixed' with two parts in its body: the first part is type 'application/foo' and the other type 'application/bar'. If the Transparency Profile is configured to transparently pass 'application/foo', then the first part of the message body is passed transparently in the egress SIP message.

3.4.3 Support for Message Body Transparency Across Ribbon Gateways

This feature will be supported across Ribbon Gateways (using Ribbon Proprietary GW to GW Signalling) only for SIP INVITE messages.

3.4.4 SDP

he

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 

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.4.1 SDP Transparency Flag

Make note that the sdpTransparencyState signaling object within the SIP Trunk Group must 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.

3.4.5 Audio Transparency

The

• recvonly/sendonly/sendrecv/inactive
• crypto
• X-dmi
• rtcp
• fingerprint
• OMR

Audio Transparency Feature is controlled by two flags:

• Enable Transcoder-Free-Transparency for the session (enable on either of the PSPs).
• Enable Selective-SDP-Transparency on both ingress and egress Trunk Groups that receive the relayed SDP.

Bandwidth (b) lines are transparently relayed and do not play any role in calculating the unknown audio codec bandwidth. The following PSP configuration bits for Audio Transparency feature are included for Unknown audio bandwidth reservation to calculate the Unknown audio bandwidth:

• unknownCodecBitRate

• unknownCodecPacketSize

3.4.5.1 Audio Transparency and Reserve Bandwidth for Preferred Common Codec

By default for pass-through calls, 

3.4.5.2 Media Policer Reservation For Worst Case Codec

By default for pass-through calls, the

3.4.5.3 Configuring Audio Transparency

Configuring the basic audio transparency feature contains:

• Enabling the sdpAttributesSelectiveRelay Parameter on Both Ingress and Egress Trunk Groups
• Configuring the transcoderFreeTransparency Parameter on Packet Service Profile
• Configuring audioTransparecy Parameter on Packet Service Profile

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

3.5 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,

There are three modes of using Transparency Profile:

• Transparency Profile with Specific Headers (Positive Enumeration)

• Maximum Transparency Using the Transparency Profile

• Transparency Profile, All Headers with Exceptions (Negative Enumeration)

Anchor
Positive Enumeration Positive Enumeration

3.5.1 Transparency Profile with Specific Headers (Positive Enumeration)

In this mode, only headers/bodies explicitly configured in the Transparency Profile are allowed to pass-through.

For example, the following scenario allows only the headers "p-asserted-identity" and "xyzHdr" and message bodies of type "application/simple-message-summary" and "xyzContentType" to pass transparently.

set profiles services transparencyProfile ALLOW_SPECIFIC_HDRS_BODIES sipHeader p-asserted-identity
set profiles services transparencyProfile ALLOW_SPECIFIC_HDRS_BODIES sipHeader xyzHdr
set profiles services transparencyProfile ALLOW_SPECIFIC_HDRS_BODIES sipMessageBody application/simple-message-summary
set profiles services transparencyProfile ALLOW_SPECIFIC_HDRS_BODIES sipMessageBody xyzContentType
set profiles services transparencyProfile ALLOW_SPECIFIC_HDRS_BODIES state enabled
commit

Anchor
Maximum Transparency Maximum Transparency

3.5.2 Maximum Transparency using the Transparency Profile

Complete or maximum transparency is occasionally desired, especially during initial integration testing to determine if specific headers are required for the success of certain call flows.

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 

Additional Relay Flags also need to be enabled to maximize the transparency of the Trunk Group for testing. See Relay Flags above.

Anchor
Negative Transparency Negative Transparency

3.5.3 Transparency Profile, All Headers with Exceptions (Negative Enumeration)

All headers/bodies are allowed to pass-through unless they are explicitly disallowed by Transparency Profile configuration. The ignoreTransparency header option within the Transparency Profile is primarily used for excluding one or more specific headers when paired with the "all" header option. In the example below, the user wishes to pass all SIP headers except for the History-Info header.

For example, in the following scenario, the rules are configured and all the headers and message bodies except "history-info" and "application/resource-lists+xml" are passed transparently. The "xyzHeader" is passed transparently in all methods except INFO and REGISTER. The "xyzContentType" is passed transparently in all methods except INVITE.

set profiles services transparencyProfile ALMOST_ALL_TRANSPARENCY sipHeader all
set profiles services transparencyProfile ALMOST_ALL_TRANSPARENCY sipMessageBody all
set profiles services transparencyProfile ALMOST_ALL_HDRS sipHeader history-info ignoreTransparency yes
set profiles services transparencyProfile ALMOST_ALL_HDRS sipMessageBody application/resource-lists+xml ignoreTransparency yes
set profiles services transparencyProfile ALMOST_ALL_HDRS sipHeader xyzHeader excludedMethods info,register
set profiles services transparencyProfile ALMOST_ALL_HDRS sipMessageBody xyzContentType excludedMethods invite
set profiles services transparencyProfile ALMOST_ALL_HDRS state enabled
commit

The excludedMethods parameter indicates the list of methods for which the transparency is not allowed and is common to both header and body entries.

set profiles services transparencyProfile TP1 sipHeader all
set profiles services transparencyProfile TP1 sipHeader all excludedMethods bye,info,notify
commit

3.5.4 Existing Deployment Augmented with a Transparency Profile

Existing deployments will likely utilize Transparency Flags, and those that must pass proprietary or otherwise 

While a Transparency Profile can be configured to completely overlap with any existing Transparency Flags settings, it is not required. A Transparency Profile can be configured to simply augment existing Transparency Flags settings with a more surgical configuration and allowing unknownHeader to be disabled.

For example, a user may wish to have the 

Rather than continue to allow all unknown headers through the

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

3.6 SRTP Pass-through

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

To control this SRTP media pass-through, the allowPassthru flag is available from the secureRtpRtcp parameter of the 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.

Anchor
RelayFlags RelayFlags

3.7 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 

set profiles signaling sipFilterProfile doc_FILTER2

set profiles signaling sipFilterProfile doc_FILTER2 header Also enabled

set addressContext default zone doc_ZONE_IAD id 10

set addressContext default zone doc_ZONE_IAD sipTrunkGroup doc_SBX10_IAD media mediaIpInterfaceGroupName LIF1

set addressContext default zone doc_ZONE_IAD sipTrunkGroup doc_SBX10_IAD signaling sipFilterProfile doc_FILTER2     

set profiles signaling ipSignalingProfile DEFAULT_SIP egressIpAttributes privacy transparency enable

set profiles signaling ipSignalingProfile DEFAULT_SIP egressIpAttributes privacy anonymizeHostIpPortion enable