| Include Page |
|---|
| Transparency_Profile_Note |
|---|
| Transparency_Profile_Note |
|---|
|
| Excerpt Include |
|---|
| SBC SIP Transparency Implementation Guide |
|---|
|
...
...
...
Related articles:
...
| | SBC SIP Transparency Implementation Guide |
|---|
|
...
| Excerpt |
|---|
The 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 transparently passes the corresponding message body in the outgoing message.The 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
:- PRACK messages and responses to PRACK messages are not sent end-to-end through the . Therefore, the does not support transparency of message-bodies or headers in these messages.
- ACK messages are not normally sent end-to-end through the . Transparency of ACK messages is not supported even if the
endToEndAck flag is enabled in the "IP Signaling Profile". - In late media scenarios, the 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 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. |
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
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 |
|---|
| 0 | Table |
|---|
| 1 | SIP 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 | |
|
The following SIP headers cannot be transparently passed in a call:
- Call-ID
- Allow
- Require
- Supported
- RSeq
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
For more information on SIP Transparency Profile, refer to:
| Add_workflow_for_techpubs |
|---|
| AUTH2 | bgoswami |
|---|
| AUTH1 | bscoggins |
|---|
| REV5 | bscoggins |
|---|
| REV6 | bscoggins |
|---|
| REV3 | radaikalam |
|---|
| REV4 | srai |
|---|
| REV1 | dalves |
|---|
| REV2 | mshanmugam |
|---|
|