Versions Compared

Old Version 1

changes.mady.by.user Ribbon Communications

Saved on

compared with

New Version Current

changes.mady.by.user Ribbon Communications

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Include Page
Transparency_Profile_Note
Transparency_Profile_Note

Excerpt Include
SBC SIP Transparency Implementation Guide

Noprint
Panel
borderColorgreen
bgColortransparent
borderWidth2

Back to Table of Contents

Back to SIP Services

...

Column
Panel

In this section:

Table of Contents

...

width40%

...

Related articles:

...

SBC SIP Transparency Implementation Guide

...

nopanel

Excerpt

The

Spacevars
0series4
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
Spacevars
0product
transparently passes the corresponding message body in the outgoing message.

The 

Spacevars
0product
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.

Note
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

Spacevars
0product
:

  • PRACK messages and responses to PRACK messages are not sent end-to-end through the
    Spacevars
    0product
    . Therefore, the
    Spacevars
    0product
    does not support transparency of message-bodies or headers in these messages.
  • ACK messages are not normally sent end-to-end through the
    Spacevars
    0product
    . Transparency of ACK messages is not supported even if the endToEndAck flag is enabled in the "IP Signaling Profile".
  • In late media scenarios, the
    Spacevars
    0product
    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.

Note
Headers may be configured in compact form and transparently passed using a Transparency Profile. It is advisable to configure both compact and long formats to ensure both types of received headers in the PDU are transparently passed.

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.
Caption
0Table
1SIP Headers not Under Control of Transparency Flags in Relay Scenarios

Accept-Language

Alert-Info

Also

Allow

Anonymity            

Authorization

Content-Length

Diversion

Error-Info

Event

Expires

Max-Forwards

Min-Expires

Min-SE

Path

P-Charge-Info

P-DCS-Billing-Info

P-K-Cfl

P-K-Cfo

P-Preferred-Identity

Proxy-Authenticate

Proxy-Authorization

Proxy-Require

P-Sig-Info

RAck

Reason

Refer-Sub

Record-Route

Remote-Party-ID

Reply-To

Requested-By

Require

Resource-Priority

Retry-After

RSeq

Service-Route

Session-Expires

Subscription-State

Supported

Warning

WWW-Authenticate

 

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

Spacevars
0product
. 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

Spacevars
0product
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

true

For more information on SIP Transparency Profile, refer to:

Add_workflow_for_techpubs
AUTH2UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26c85b00e8, userName='null'}
AUTH1UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cd5909df, userName='null'}
REV5UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cd5909df, userName='null'}
REV6UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cd5909df, userName='null'}
REV3UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26c7cd0042, userName='null'}
REV4UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26ced50c92, userName='null'}
REV1UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26ccd208db, userName='null'}
REV2UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cca00892, userName='null'}

Pagebreak