Page History
Add_workflow_for_techpubs | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Include Page | ||||
---|---|---|---|---|
|
Info | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||
The instructions, commands and references in this document apply to the
|
Introduction
This document provides configuration and provisioning guidance to enable SIP transparency on
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Audience
This document is intended for design engineers, system engineers and operations staff for the purpose of deploying SIP on a
Spacevars | ||
---|---|---|
|
Support
For technical support, log into the Customer Portal and Partner Portal.
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.
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
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
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/
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
- SIP Normalization (including arbitrary SIP Message Manipulation)
- Topology Hiding
- Protocol Translation
- Codec Transcoding (allowing a non-transparent SDP)
Fundamentally, the
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
This document describes the
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Since its inception, the
Spacevars | ||
---|---|---|
|
SIP Message Flow
Existing
Spacevars | ||
---|---|---|
|
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).
Info |
---|
You can configure a maximum of 144 unique unknown headers across all Header Transparency Profiles. |
IP Signaling Profile Transparency Flags
acceptContactHeader | pVisitedNetworkIDHeader |
acceptHeader | qsigBody |
acceptLanguageHeader | reasonHeader |
alertInformationHeader | referredByHeader |
authcodeHeaders | requestURI |
callInfoHeader | resourceListBody |
contactHeader | resourcePriorityOptionTag |
errorInfo | rlmiBody |
externalBody | routeHeader |
fromHeader | serverHeader |
geolocation | serviceRouteHeader |
geolocationError | simpleFilterBody |
geolocationRouting | sipBody |
historyInfo | sipfragBody |
maxForwardsHeader | toHeader |
mwiBody | toneBody |
pAccessNetworkInfoHeader | unknownBody |
passCompleteContactHeader | unknownHeader |
pathHeader | userAgentHeader |
pCalledPartyID | userToUserHeader |
pChargingVectorHeader | viaHeader |
pEarlyMedia | warningHeader |
pidfBody | watcherInfoBody |
pidfDiffBody |
The message bodies are described in blue cells.
If a header or body did not have a specific flag on the
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
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
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
The
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
SIP Transparency Profile
Excerpt | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
A Transparency Profile is a user-configurable profile allowing the user to transparently pass almost any SIP header/body through the
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. If a received Content-Type header value matches any “Message Body” entry configured in the Transparency Profile, the
The following functionality is included:
|
When configuring a Transparency Profile for specific SIP headers,
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
The following transparency is not supported by the
Spacevars | ||
---|---|---|
|
- ACK messages are not normally sent end-to-end through the
. Transparency of ACK messages is not supported even if theSpacevars 0 product endToEndAck
flag is enabled in the "IP Signaling Profile". - In late media scenarios, the
does not support transparency of headers and bodies.Spacevars 0 product
For configuration details, see Service Profiles - Transparency Profile (EMA) or Transparency Profile - CLI.
Info | ||
---|---|---|
| ||
For additional feature details, see Transparency Profile. |
SIP Message Header
The
Spacevars | ||
---|---|---|
|
Code Block | ||
---|---|---|
| ||
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,
Spacevars | ||
---|---|---|
|
Info |
---|
Refer to IANA for the SIP header fields and their compact forms at: http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml |
Compact form can be received by the
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
The
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
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
Info | ||
---|---|---|
| ||
The transparency of Allow, Supported, and Require headers can be controlled by using SIP Param Filter Profile. For more information, refer to SIP Param Filter Profile. |
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).
SIP Message Body
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Code Block | ||
---|---|---|
| ||
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
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
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
Spacevars | ||
---|---|---|
|
Relay Flags That Control SIP Message Bodies
Relay Flag | Configuration Location | Content Applicability |
---|---|---|
dtmfBody | IP Signaling Profile | application/dtmf and application/dtmf-relay |
sonusMediaBody | IP Signaling Profile | application/sonus-media |
thirdPartyBodies | IP Signaling Profile | application/broadsoft |
isupMimeBodyRelay | SIP Trunk Group | application/isup |
conferenceEventPackage | IP Signaling Profile | application/conference-info+xml |
dialogEventPackage | IP Signaling Profile | application/dialog-info+xml |
See Relay Flags below for details.
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.
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.
Info | ||
---|---|---|
| ||
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 can be classified into three categories as shown in the below table:
SIP Headers not Under Control of Transparency Flags in Relay Scenarios
Header Classifications | ||
---|---|---|
Transparently sent irrespective of transparency settings | Added/modified by the SBC | Not sent at all |
Accept-Language | Also | Allow |
Alert-Info | Anonymity | Max-Forwards |
Authorization | Diversion | Require |
Content-Length | Path | Supported |
Error-Info | P-Charge-Info | RAck |
Event | P-DCS-Billing-Info | P-Associated-URI |
Expires | P-K-Cfl | |
Min-Expires | P-K-Cfo | |
Min-SE | P-Preferred-Identity | |
Proxy-Authenticate | P-Sig-Info | |
Proxy-Authorization | Record-Route | |
Proxy-Require | Remote-Party-ID | |
RAck | Reply-To | |
Reason | Requested-By | |
Refer-Sub | Service-Route | |
Resource-Priority | ||
Retry-After | ||
RSeq | ||
Session-Expires | ||
Subscription-State | ||
Warning | ||
WWW-Authenticate |
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
Spacevars | ||
---|---|---|
|
SIP Headers Brought Under Transparency Control in Relay Scenarios
Previously, the following headers were transparently passed by the
Spacevars | ||
---|---|---|
|
- Accept
- SIP-ETag
- SIP-If-Match
- Suppress-If-Match
SIP Header Transparency Behaviors
Spacevars | ||
---|---|---|
|
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).
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
Info | ||
---|---|---|
| ||
For configuration details, see: |
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
Spacevars | ||
---|---|---|
|
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,
Code Block |
---|
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,
Code Block |
---|
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:
Out-of-Dialog SIP Header Behavior
SIP Header | Out-of-Dialog Behavior |
---|---|
Accept-Language | Sent |
Alert-Info | Sent |
Also | Dropped |
Anonymity | Dropped |
Authorization | Sent |
Content-Length | Sent |
Diversion | Dropped |
Error-Info | Sent |
Event | Sent |
Expires | Sent |
Min-Expires | Sent |
Min-SE | Sent |
P-Charge-Info | Dropped |
P-DCS-Billing-Info | Dropped |
P-K-Cfl | Dropped |
P-K-Cfo | Dropped |
P-Preferred-Identity | Dropped |
P-Sig-Info | Dropped |
Path | Dropped |
Proxy-Authenticate | Sent |
Proxy-Authorization | Sent |
Proxy-Require | Sent |
RAck | Sent |
Reason | Sent |
Record-Route | Dropped |
Refer-Sub | Sent |
Remote-Party-ID | Dropped |
Reply-To | Dropped |
Requested-By | Dropped |
Resource-Priority | Sent |
Retry-After | Sent |
RSeq | Sent |
Service-Route | Dropped |
Session-Expires | Sent |
Subscription-State | Sent |
Warning | Sent |
WWW-Authenticate | Sent |
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.
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 | ||
---|---|---|
|
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 Ribbon Gateways
This feature will be supported across Ribbon Gateways (using Ribbon Proprietary GW to GW Signalling) only for SIP INVITE messages.
SDP
The
Spacevars | ||
---|---|---|
|
- Audio
- Video Main
- Video Extended (for Content Share)
- Binary Floor Control Protocol (UDP and TCP)
- Far End Camera Control (FECC)
- Message Session Relay Protocol ( MSRP)
For all the above mentioned media types (with the exception of Audio), the
Spacevars | ||
---|---|---|
|
- C line
- RTCP attributes
- Media direction (a= sendrecv/sendonly/inactive/recvonly)
supports Secure Real-Time Transport Protocol (SRTP) media pass-through for SRTP and Secure Real-Time Transport Control Protocol (SRTCP) media streams.Spacevars 0 product
For Audio, the
Spacevars | ||
---|---|---|
|
You must enable Video (assign a valid video bandwidth) and Audio transparency to achieve the above described behavior using the below CLI syntax.
Info | ||
---|---|---|
| ||
Associate the following configuration with both Trunk Groups. |
Code Block | ||
---|---|---|
| ||
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 |
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.
Info | ||||
---|---|---|---|---|
| ||||
Do not enable the
|
Audio Transparency
The
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
rtpmap
, fmtp
, and T38
fax
. Audio transparency functionality is used to manage bandwidth for audio stream in the pass-through calls. By enabling this feature, audio codecs that are unknown to the system are available to establish audio calls or streams.Spacevars | ||
---|---|---|
|
- recvonly/sendonly/sendrecv/inactive
- crypto
- X-dmi
- rtcp
- fingerprint
- OMR
Info | ||
---|---|---|
| ||
This feature does not support H323-H323 and GW-GW calls. |
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
Info | ||
---|---|---|
| ||
If the bandwidth is not configured, the default settings (Packet Size—10 ms and Bit Rate—124 KB/s) are used for a pass-through call. |
Audio Transparency and Reserve Bandwidth for Preferred Common Codec
By default for pass-through calls,
Spacevars | ||
---|---|---|
|
reserveBwForPreferredAudioCommonCodec
is added to reserve the bandwidth associated with the preferred common codec (instead of the worst case common codec) on the Trunk Groups and IP interfaces. When this flag is enabled, bandwidth of the first common codec from Answer (SIP) is used for reservation and bandwidth of the heaviest common codec is used for policer.Info | ||
---|---|---|
| ||
This flag can be used independently or in conjunction with Audio Transparency feature and/or
|
Info | ||
---|---|---|
| ||
The flag |
Media Policer Reservation For Worst Case Codec
By default for pass-through calls, the
Spacevars | ||
---|---|---|
|
policeOnHeaviestAudioCodec
is used in the PSP.Info | ||
---|---|---|
| ||
This flag can be used independent of or in conjunction with Audio transparency feature and/or |
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
Anchor | ||||
---|---|---|---|---|
|
sdpAttributesSelectiveRelay
Parameter on Both Ingress and Egress Trunk GroupsCode Block | ||
---|---|---|
| ||
set addressContext default zone ZONE1 sipTrunkGroup TG_SBX_INT media sdpAttributesSelectiveRelay enabled set addressContext default zone ZONE2 sipTrunkGroup TG_SBX_EXT media sdpAttributesSelectiveRelay enabled |
Anchor | ||||
---|---|---|---|---|
|
transcoderFreeTransparency
Parameter on Packet Service ProfileCode Block | ||
---|---|---|
| ||
set profiles media packetServiceProfile PSP_INT packetToPacketControl transcode transcoderFreeTransparency set profiles media packetServiceProfile PSP_EXT packetToPacketControl transcode transcoderFreeTransparency |
Anchor | ||||
---|---|---|---|---|
|
Code Block | ||
---|---|---|
| ||
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 |
Info | ||
---|---|---|
| ||
For configuring Bit Rate (kbps), Packet Size (ms) and Reserve BW For Preferred Audio Common Codec for pass-through calls flags on PSX, refer to PSX Documentation. |
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,
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
There are three modes of using Transparency Profile:
- Transparency Profile with Specific Headers (Positive Enumeration)
- Transparency Profile, All Headers with Exceptions (Negative Enumeration)
Anchor | ||||
---|---|---|---|---|
|
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.
Code Block |
---|
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 | ||||
---|---|---|---|---|
|
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.
Code Block | ||
---|---|---|
| ||
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 | ||||
---|---|---|---|---|
|
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.
Code Block | ||
---|---|---|
| ||
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.
Code Block |
---|
set profiles services transparencyProfile TP1 sipHeader all set profiles services transparencyProfile TP1 sipHeader all excludedMethods bye,info,notify commit |
Info | ||
---|---|---|
| ||
If a specific header is configured, |
Info | ||
---|---|---|
| ||
Use the |
Existing Deployment Augmented with a Transparency Profile
Existing deployments will likely utilize Transparency Flags, and those that must pass proprietary or otherwise
Spacevars | ||
---|---|---|
|
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
Spacevars | ||
---|---|---|
|
Rather than continue to allow all unknown headers through the
Spacevars | ||
---|---|---|
|
Code Block | ||
---|---|---|
| ||
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 |
SRTP Pass-through
Spacevars | ||
---|---|---|
|
The following diagram illustrates the media flow for an SRTP pass-through call.
SRTP Packet to Packet Media Call Flow
Info | ||
---|---|---|
| ||
|
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 | ||||
---|---|---|---|---|
|
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
Spacevars | ||
---|---|---|
|
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
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Relay Flag types and their uses for SIP Access and SIP Peering environments
Relay Flag Type | Requests from Registered Users | Requests from Unregistered Users - SIP |
---|---|---|
IP signaling profile relay flags | The relay flags control the relay of non-INVITE and non-REGISTER requests within dialogs established by the SIP INVITE method. | |
relayNonInviteRequest flag at the sipTrunkgroup level | SBC relays all non-INVITE out-of-dialog requests from registered endpoints irrespective of the value of the Relay Non-Invite Request flag. SBC relays the requests to the destination stored during the SIP endpoint's registration, that is, to a SIP registrar, without a need for a PSX/ERE policy dip. | SBC checks for the value of the Relay Non-Invite Request flag when it receives an out-of-dialog non-INVITE request from a SIP peer. If the flag is enabled, SBC will relay the request, based on a PSX/ERE policy dip, otherwise, SBC will reject the request with a SIP 404 response. |
Configuration Locations of Relay Flags
Relay Flags | Configuration Location |
---|---|
conferenceEventPackage | IP Signaling Profile > Common IP Attributes |
dialogEventPackage | IP Signaling Profile > Common IP Attributes |
dtmfBody | IP Signaling Profile > Common IP Attributes |
force503to500Relay | IP Signaling Profile > Common IP Attributes |
info | IP Signaling Profile > Common IP Attributes |
message | IP Signaling Profile > Common IP Attributes |
notify | IP Signaling Profile > Common IP Attributes |
options | IP Signaling Profile > Common IP Attributes |
publish | IP Signaling Profile > Common IP Attributes |
refer | IP Signaling Profile > Common IP Attributes |
referToHeaderRelay | IP Signaling Profile > Common IP Attributes |
regEventPackage | IP Signaling Profile > Common IP Attributes |
sonusMediaBody | IP Signaling Profile > Common IP Attributes |
statusCode3xx | IP Signaling Profile > Common IP Attributes |
statusCode4xx6xx | IP Signaling Profile > Common IP Attributes |
thirdPartyBodies | IP Signaling Profile > Common IP Attributes |
updateWithoutSdp | IP Signaling Profile > Common IP Attributes |
isupMimeBodyRelay | SIP Trunk Group > Signaling |
relayUpdatewithSdp | SIP Trunk Group > Signaling |
Relaying REFER Request
The
Spacevars | ||
---|---|---|
|
refer
relay flag is disabled. To support this enhancement, Conditional Relay Matching criteria is provided by the Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
If the refer
relay flag is disabled, the Call Control (CC) mechanism forwards the REFER request to Digital Signaling (DS). DS exchanges information with the PSX to check the match criteria set in Conditional Relay Matching.
Info | ||
---|---|---|
| ||
Starting with SBC SWe release 8.1, the D-SBC supports REFER (without Replaces) in relay and local processing mode for audio pass-through calls. |
The matched criteria includes call parameters such as Username, Directory Number (DN), or Fully Qualified Domain Name (FQDN).
- If the call parameters received with the REFER request match the call routing criteria,
relays the REFER request to Egress SIPSG.Spacevars 0 product - If the call parameters received with the REFER request do not match the call routing criteria, the REFER request is processed locally by
. The REFER request acts as the transferor and the call is forwarded to the Egress SIPSG, resulting in call bridging. In this scenario,Spacevars 0 product
sends back a 202 response and proceeds for local processing.Spacevars 0 product
Info | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
If a REFER request is sent after a switchover and:
|
Info | ||
---|---|---|
| ||
This feature is supported only for Blind/Unattended Transfer calls and not for Attended Transfer (refer with replaces) calls. |
The following figure shows the enhanced REFER request processing call flow:
Configuring
Spacevars | ||
---|---|---|
|
To configure this feature, perform the following steps:
- Configure
for regular REFER call Blind Transfer.Spacevars 0 product Create SIP_MSG_TYPE_REFER call parameter filter profile (CPFP) in the PSX. Execute the following command to view the CPFP SIP_MSG_TYPE_REFER. This profile is already present in ERE.
Info title Info For more information on creating CPFP, refer to PSX Documentation.
Code Block > show table profiles callParameterFilterProfile Description: Profile used for routing based on SIP message type. Possible completions: SIP_MSG_TYPE_INFO - SIP Message Type is Info SIP_MSG_TYPE_MESSAGE - SIP Message Type is Message SIP_MSG_TYPE_NOTIFY - SIP Message Type is Notify SIP_MSG_TYPE_REFER - SIP Message Type is Refer SIP_MSG_TYPE_REGISTER - SIP Message Type is Register SIP_MSG_TYPE_SUBSCRIBE - SIP Message Type is Subscribe none - seed data for provisioning support
All > Profiles > Call Parameter Filter Profile
Call Parameter Filter Profile List showing SIP_MSG_TYPE_REFER profileInfo title Note A new script SONS_SIP_REFER_RELAY is seeded in both ERE and PSX.
Disable the Refer relay flag in IPSP.
Code Block set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags refer disable
Enable the Notify relay in Egress side on IPSP to relay REFER for DN/Username/FQDN match.
Code Block set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags notify enable
All > Profiles > Signaling > Ip Signaling Profile > Common Ip Attributes > Relay Flags
Notify and Refer relay flagsCreate a new routing label with the script SONS_SIP_REFER_RELAY to trigger process refer request feature.
Info title Note The routing label action must be set as script.
Code Block set global callRouting routingLabel <routing_label> script SONS_SIP_REFER_RELAY action script
All > Global > Call Routing > Routing Label
Creating a Routing LabelRouting Label screen
Configure a DN criteria in the standard route and attach the SIP_MSG_TYPE_REFER profile to the standard route by executing the following command:
Code Block set global callRouting route none Sonus_NULL Sonus_NULL standard <Matched_DN or FQDN> 1 all ALL SIP_MSG_TYPE_REFER Sonus_NULL routingLabel <routing_label>
For DN (Directory Number) or username
Code Block set global callRouting route none Sonus_NULL Sonus_NULL standard <Matched_DN or Username> 1 all ALL SIP_MSG_TYPE_REFER Sonus_NULL routingLabel <routing_label>
For FQDN with DN or username
Info title Note The corresponding Sip domain group must be configured in
.Spacevars 0 product Code Block set global sipDomain <Matched_domain_name> set global callRouting route none Sonus_NULL Sonus_NULL standard <Matched_DN or Username> 1 all ALL SIP_MSG_TYPE_REFER <Matched_domain_name> routingLabel <routing_label>
All > Global > Call Routing > Route
Creating a RouteRoute screen
Execute the following commands to view the call detail status and call media status.
Code Block show status global callDetailStatus or show status global callMediaStatus
Anchor | ||||
---|---|---|---|---|
|
The
Spacevars | ||
---|---|---|
|
The SIP Param Filter Profile includes the following characteristics:
- This profile takes precedence over existing mechanism/flags when transparently passing Allow/Supported/Require headers, but does not impact corresponding configurations established by the operator. It is operators responsibility to ensure the system is configured properly so that transparently-passed values do not conflict with existing configurations. For example, do not configure 100rel as pass-through if 100rel support fro SIP Trunk Group Signaling is disabled.
- The settings of SIP Param Filter Profiles for both ingress and egress legs dictate the actual pass-through results (see SIP Param Filter Profile Behavior table below for details.)
- Pass-through of individual header values is configurable.
- SIP tags are provided for unknown SIP parameter transparency only. Known SIP parameter transparency is still determined using existing SBC application logic (from Ingress leg to Egress leg) and configurations.
Info | ||
---|---|---|
| ||
The SBC supports configuring up to 32 SIP Param Filter Profiles. Each profile can be configured using any/all of the SIP headers Allow/Supported/Require. |
The SIP Param Filter Profile Behavior table explains the SIP Param Filter Profile behavior when using the Allow, Supported and Require headers.
SIP Param Filter Profile Behavior
Header | SIP Param Filter Profile Processing |
---|---|
Allow | Ingress leg: The Allow header in the received message is processed after Ingress SIP Message Manipulation (SMM) processing but before any other SBC processing occurs.
Egress leg: The Allow header in the message to be egressed by SBC is processed after all SBC processing but before Egress SMM processing is performed.
|
Require/Supported | Ingress leg: The Require/Supported header in the received message is processed after Ingress SMM processing but before any other SBC processing occurs.
Egress leg: The Require/Supported header in the message to be egressed by SBC is processed after all SBC processing but before Egress SMM processing occurs.
If an option tag present in the received Ingress request is dropped due to Require transparency settings, and if |
SIP Filter Profile
The SIP Filter Profile is a collection of the configurable filter settings of individual SIP headers. Depending on the filter settings of each of the SIP headers in the SIP Filter Profile, the SBC either relays the SIP messages without parsing the header, or parses the headers of the messages.
For every SIP message associated with the ingress leg of the call, the SBC first checks the SIP Filter Profile for the filter setting of the SIP header. If the SIP Filter Profile indicates that a particular SIP header needs filtering, the SBC stores it without parsing.
The SIP header of the egress leg is populated on the basis of the configuration in the IP Signaling Profile and the Transparency Profile. In the egress leg of a call, the transparency bit mask is set to identify the headers that are transparently passed. If the transparency settings of all unknown headers in the IP Signaling Profile is enabled, all the stored headers (including the ones filtered in the ingress leg), is copied to the SIP header of the egress leg.
If the Transparency Profile attached with the Egress Trunk Group indicates that specific headers are allowed to pass transparently, and those headers are present as filtered headers, they are individually copied to the SIP header of the egress leg. In this case, the transparency bits are enabled, either by the IP Signaling Profile or through the flexible header transparency.
Include Page | ||||
---|---|---|---|---|
|
Info | ||
---|---|---|
| ||
The SIP Filter Profile is not used for the egress leg of a call. |
Info | ||
---|---|---|
| ||
The mandatory headers which are not part of the
|
Configuring a SIP Filter Profile
Info | ||
---|---|---|
| ||
Avoid filtering headers pertaining to SIP call routing/protocol processing, as it may cause unexpected results such as call failures. Some of the headers that should not be filtered are as follows:
|
Perform the following:
- Creating a new SIP Filter Profile
- Changing the Transparency Setting of a Header Under a SIP Filter Profile
- Configuring the Zone ID for the Selected Zone
- Configuring the Media IP Interface Group Name for a SIP Trunk Group
- Attaching the SIP Filter Profile to the SIP Trunk Group
Creating a new SIP Filter Profile Anchor Creating a new SIP Filter Profile Creating a new SIP Filter Profile
Code Block | ||
---|---|---|
| ||
set profiles signaling sipFilterProfile doc_FILTER2 |
Changing the Transparency Setting of a Header Under a SIP Filter Profile Anchor Changing the Transparency Setting of a Header Under a SIP Filter Profile Changing the Transparency Setting of a Header Under a SIP Filter Profile
Code Block |
---|
set profiles signaling sipFilterProfile doc_FILTER2 header Also enabled |
Info | ||
---|---|---|
| ||
If |
Configuring the Zone ID for the Selected Zone Anchor Configuring the Zone ID for the Selected Zone Configuring the Zone ID for the Selected Zone
Code Block |
---|
set addressContext default zone doc_ZONE_IAD id 10 |
Configuring the Media IP Interface Group Name for the SIP Trunk Group Anchor Configuring the Media IP Interface Group Name for a SIP Trunk Group Configuring the Media IP Interface Group Name for a SIP Trunk Group
Code Block |
---|
set addressContext default zone doc_ZONE_IAD sipTrunkGroup doc_SBX10_IAD media mediaIpInterfaceGroupName LIF1 |
Anchor | ||||
---|---|---|---|---|
|
Code Block |
---|
set addressContext default zone doc_ZONE_IAD sipTrunkGroup doc_SBX10_IAD signaling sipFilterProfile doc_FILTER2 |
Info | ||
---|---|---|
| ||
|
Privacy Transparency
A new flag anonymizeHostIpAddress
is introduced for the privacy
parameter of the IP Signaling Profile to enable or disable this feature. When this flag is activated, the SBC anonymizes the incoming host IP portion of the private headers (P-AID, P-PID, RPID) by replacing it with the IP address of the SBC, before sending it to the egress leg of a call.
This feature supports anonymizing the host IP address for the following message types:
- INVITE
- BYE
- OPTIONS
- SUBSCRIBE
- NOTIFY
- UPDATE
- PUBLISH
- MESSAGE
Info | ||
---|---|---|
| ||
This feature currently supports only in-dialog messages, and not out-of-dialog messages. |
Anonymizing the Host Ip Address
Info | ||
---|---|---|
| ||
|
Perform the following:
Enabling the Anchor Enabling the transparency flag Enabling the transparency flag transparency
Flag
To enable the transparency
flag for an ipSignalingProfile
, enter the following command:
Code Block |
---|
set profiles signaling ipSignalingProfile DEFAULT_SIP egressIpAttributes privacy transparency enable |
Anchor | ||||
---|---|---|---|---|
|
anonymizeHostIpAddress
FlagTo enable the anonymizeHostIpAddress
flag to activate this feature, enter the following command:
Code Block |
---|
set profiles signaling ipSignalingProfile DEFAULT_SIP egressIpAttributes privacy anonymizeHostIpPortion enable |