Transparency Profile

Overview

The

Unable to show "metadata-from": No such page "_space_variables"

includes a configurable Transparency Profile capable of transparently passing SIP headers and SIP message bodies. If a received Content-Type header value matches any “Message Body” entry configured in the Transparency Profile, the

Unable to show "metadata-from": No such page "_space_variables"

transparently passes the corresponding message body in the outgoing message.

The 

Unable to show "metadata-from": No such page "_space_variables"

supports configuring up to 256 Transparency Profiles. The following functionality is included:

• Ability to transparently pass "all" SIP headers and message body types.
• Selectively ignore transparency of select headers and message body types (useful when transparency is enabled for all headers and/or message body types).
• Exclude one or more methods for which transparency of headers or message body types is not needed.

The Transparency Profile is associated with the egress trunk group, and includes support for 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 and their responses.

The Transparency Profile is supported across Sonus Gateways (using Sonus proprietary GW-to-GW signaling) for SIP INVITE messages only. 

The following transparency is not supported by the

:

• PRACK messages and responses to PRACK messages are not sent end-to-end through the
  Unable to show "metadata-from": No such page "_space_variables"
  . Therefore, the
  Unable to show "metadata-from": No such page "_space_variables"
  does not support transparency of message-bodies or headers in these messages.
• ACK messages are not normally sent end-to-end through the
  Unable to show "metadata-from": No such page "_space_variables"
  . Transparency of ACK messages is not supported even if the endToEndAck flag is enabled in the "IP Signaling Profile".
• In late media scenarios, the
  Unable to show "metadata-from": No such page "_space_variables"
  does not support transparency of headers and bodies.
• Transparency for headers and bodies is not supported for methods such as CANCEL and methods that are "hop-by-hop".

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

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.

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

SIP Headers not Under Transparency Control in Relay Scenarios

Some headers are not under the control of transparency flags in relay scenarios. These headers (see Table 1) can be classified as follows:

• added/modified by the SBC,
• transparently sent irrespective of the transparency settings,
• or not sent at all.

SIP Headers Not Transparently Passed in Calls

The following SIP headers cannot be transparently passed in a call:

• Call-ID
• Allow
• Require
• Supported
• RSeq

SIP Headers Brought Under Transparency Control in Relay Scenarios

Previously, the following headers were transparently passed by the

. From release 4.2 onwards, these headers are controlled using transparency flags.

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

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.

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

Transparency of Multi-part Message Bodies

The

treats constituent parts of a 'multipart/mixed' message body just as it treats any message with a single body. Therefore, a constituent part of a 'multipart/mixed' message body will be transparently passed through only if the Content-Type specified in the MIME envelope of the corresponding part has been configured in the Transparency Profile.

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.

Support for Message Body Transparency Across Sonus Gateways

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

Inter-working with IP Signaling Profile

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

Supported Scenarios

Transparency Profile supports the following scenarios:

• Initial INVITE, its responses, and other requests/responses within the INVITE dialog
• REGISTER, BYE, UPDATE, REFER, INFO, PUBLISH, MESSAGE, OPTIONS, SUBSCRIBE, NOTIFY and their responses