SBC SIP Transparency Implementation Guide

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 

Sonus technical support can be obtained through the following:

• 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

• Unable to show "metadata-from": No such page "_space_variables"
   product documentation—Go to Sonus 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.

SIP Transparency Spectrum

Although an SBC is not defined in any IETF standard, it is most closely associated functionally with a SIP B2BUA (RFC 5853, 7092). Unless otherwise specified, this document will use B2BUA and SBC terms interchangeably.

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/SBC. Some key selling points of an SBC highlight its ability to not be transparent:

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

Fundamentally, the Sonus SBC behaves as a SIP Back-to-Back User Agent (B2BUA) and not as a SIP Proxy. (If SIP Proxy behavior is actually needed then use of the Sonus PSX Policy Server should be considered as it can be deployed specifically as a SIP Proxy or Redirector.) Unlike a standard SIP Proxy, the Sonus SBC can provide a wide spectrum of SIP message transparency, from fairly transparent to almost completely non-transparent.

This document describes the SBC SIP transparency controls, how they behave, and how they interact. Some configuration examples using these transparency controls is also provided.

3. SBC SIP Transparency and Control Mechanisms

Since its inception, the SBC includes two related types of control flags: Relay Flags and Transparency Flags. Relay Flags primarily control SIP at the Request and Response level and are discussed later in a separate section. Transparency Flags control SIP headers and bodies that are generally not modified when received in a SIP message. While these controls are related, there is no direct overlap or precedence between them.

3.1 Existing SBC 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 SBC, it was treated as unknown, which meant it, along with any other SBC-unknown header, was controlled by the single unknownHeader flag (or unknownBody).

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 SBC. It also meant that the unknownHeader flag was a very coarse control as it would allow any header that was unknown to the SBC.

Starting in version 4.0, the SBC introduced a more robust future-proofing mechanism called the Transparency Profile. Sonus SBC version 4.2 extends the Transparency Profile with similar support for SIP message bodies and the flexible ability to explicitly exclude some headers and/or methods.

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 SBC. It is no longer necessary for a user to request Sonus to create a specific Transparency Flag for the desired header/body.

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 SBC and Transparency Profiles are applied on a SIP Trunk Group basis.

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, Sonus recommends that the unknownHeader flag be disabled (similarly, when configuring a Transparency Profile for specific SIP message bodies, Sonus recommends that the unknownBody flag be disabled).

3.2.1 SIP Message Header

Starting in version 4.0, the SBC introduced the Transparency Profile, where one or more SIP headers can be configured in a single profile to be passed transparently through. Version 4.2 extended the abilities of the Transparency Profile further. It now supported transparency for out-of-dialog messages, the ability to exclude specific headers from transparency and the ability to configure transparency on a per-method basis (e.g. INVITE, REGISTER, SUBSCRIBE, REFER, etc...), where specific methods can be excluded from transparency for that header. If no methods are specified to be excluded, then the configured header will be transparent for all methods.

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, Sonus recommends the configuration of both compact and long forms.

Compact form can be received by the SBC, but the Sonus SBC never generates the Compact form of any headers.

The Sonus SBC does not send multiple header instances as a comma separated list; they are always sent as separate headers.

The following SIP headers are not controlled by the Transparency Profile (or any Transparency Flags), and are ignored if configured in a 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

Sonus SBC version 4.2 extends the Transparency Profile with similar support for SIP message bodies. In addition, both message header and body transparency is configurable on a per-method basis (e.g. INVITE, REGISTER, SUBSCRIBE, REFER, etc...), where specific methods can be excluded from transparency for that body. If no methods are specified to be excluded, then the configured body is transparent for all methods.

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 SBC automatically matches each component message body contained within a multipart message independently. For example, if "application/qsig" is configured in a profile, the SBC will match it even if it is contained within a multipart/mixed message with no additional configuration needed.

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 SBC.

See RelayFlags below for details.

3.3 SIP Header Transparency Behaviors

SBC transparency mechanisms control the initial INVITE, its responses, and other requests/responses within the INVITE dialog, as well as REGISTER, BYE, UPDATE, REFER, INFO, PUBLISH, MESSAGE, OPTIONS, SUBSCRIBE, NOTIFY requests and their responses (this assumes that the request method has been allowed by the applicable Relay Flag: INFO, MESSAGE, etc…).
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.1 SBC 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 SBC 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 SBC itself and cannot be transparently passed.

3.3.3 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 SBC can receive messages within a dialog or outside of a dialog, and treats them differently based upon that relationship (or lack thereof).

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

3.4 SDP

The SBC supports anchoring the following media types:

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 SBC consumes (hence does not transparently relay) the following attributes that are required to anchor the media:

• C line
• RTCP attributes
• Media direction (a= sendrecv/sendonly/inactive/recvonly)
• Crypto - the SBC terminates SRTP on a leg by leg basis

For Audio, the SBC does not transparently relay the following attributes in addition to the above mentioned attributes:

• 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 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.

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 SBC when received in the incoming SIP message.

Albeit imprecise, a good method to contrast Relay Flags and Transparency Flags/Profiles is to consider that Relay controls whether a SIP request/response is sent through the SBC, while the Transparency controls whether a header/body in a SIP request/response is sent through the SBC.

3.6 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, Sonus recommends disabling the unknownHeader flag (similarly, when configuring a Transparency Profile for specific SIP message bodies, Sonus recommends disabling the unknownBody flag).

3.6.1 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.

3.6.2 Transparency Profile, All Headers, with Exceptions

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.

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

3.6.3 Existing Deployment Augmented with a Transparency Profile

Existing deployments will likely utilize Transparency Flags, and those that must pass proprietary or otherwise SBC unsupported SIP headers will most likely make use of the unknownHeader transparency flag in an IP Signaling Profile.

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 SBC transparently pass RFC 4474 identity headers. Prior to the introduction of the Transparency Profile, the user would have had to enable the unknownHeader transparency flag.

Rather than continue to allow all unknown headers through the SBC, the user can configure a Transparency Profile that only allows the RFC 4474 identity headers (configured in standard and compact forms) and disable the unknownHeader transparency flag.

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