...
| Info |
|---|
The instructions, commands and references in this document apply to the (SBC 5000 series, SBC 7000 series, and SBC Software Edition Sonus Edition Session Border Controllers).This document does not apply to SBC Edge (SBC 1000 and 2000 systems). |
...
This document provides configuration and provisioning guidance to enable SIP transparency on
systems. In addition to the configuration examples on the
SBC (Session Border Controller), this document provides an introduction to key topics related to SIP headers and bodies on the
.
...
This document is intended for design engineers, system engineers and operations staff for the purpose of deploying SIP on a
system. Although this document provides some background on the concepts involved, the reader is expected to have a basic understanding of SIP.
Technical Support Sonus technical support can be obtained through the following:
...
...
| Caption |
|---|
| 0 | Figure |
|---|
| 1 | 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 and 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 the
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 the 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.
...
SIP Transparency and Control MechanismsSince its inception, the SBC the
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
Transparency MechanismsPrior 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).
...
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 SBCthe .
Starting in version 4.0, the SBC the
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.
...
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 request 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 the
and Transparency Profiles are applied on a SIP Trunk Group basis.
...
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).
...
Starting in version 4.0, the SBC the
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.
...
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
, but the never generates the Compact form of any headers.
The Sonus SBC The
does not send multiple header instances as a comma separated list; they are always sent as separate headers.
...
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.
...
Multipart/mixed and multipart/related are ignored because the SBC the
automatically matches each component message body contained within a multipart message independently. For example, if "application/qsig" is configured in a profile,
the SBC the will match it even if it is contained within a multipart/mixed message with no additional configuration needed.
...
The other exceptions are due to existing Relay Flags (see table below) elsewhere within the SBCthe
.
| Caption |
|---|
| 0 | Table |
|---|
| 1 | 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 |
|
...
transparency 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
Non-Transparent Methods and ScenariosThe following SIP methods are not supported by a Transparency Profile (or any Transparency Flags):
- ACK (even if the endToEndAck flag is enabled)
- CANCEL
- PRACK
...
Non-Transparent HeadersThe following SIP headers are not supported by a Transparency Profile (or any Transparency Flags):
...
These SIP headers are entirely added and/or modified by the SBC the
itself and cannot be transparently passed.
...
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
The SBC can receive messages within a dialog or outside of a dialog, and treats them differently based upon that relationship (or lack thereof).
...
3.4 SDP
The SBC
supports anchoring the following media types:
...
For all the above mentioned media types (with the exception of Audio), the SBC the
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
- Crypto— supports Secure Real-Time Transport Protocol (SRTP) media pass-through for SRTP and Secure Real-Time Transport Control Protocol (SRTCP) media streams. does not terminate the Session Description Protocol (SDP) security description or SRTP media streams and passes them through without authenticating, decrypting, and encrypting. In this pass-through mode of operation, treats SRTP media as plain text RTP pass-through media. on a leg by leg basis
For Audio, the
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 You must enable Video (assign a valid video bandwidth) and Audio transparency to achieve the above described behavior using the below CLI syntax.
...
| Note |
|---|
Do not enable the sdpTransparencyState flag unless specifically directed to do so by Sonus by Design or Support engineers. |
...
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 the
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.
| Caption |
|---|
| 0 | Table |
|---|
| 1 | Configuration Locations of Relay Flags |
|---|
|
Relay Flag | 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 |
|
...
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).
...
Existing deployments will likely utilize Transparency Flags, and those that must pass proprietary or otherwise SBC otherwise
unsupported SIP headers will most likely make use of the unknownHeader transparency flag in an IP Signaling Profile.
...
For example, a user may wish to have the SBC the
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.
| 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 <ZONE> sipTrunkGroup <TG> services transparencyProfile IDENTITY_HDRS
commit
set profiles signaling ipSignalingProfile <IPSP> commonIpAttributes transparencyFlags unknownHeader disable
commit |
3.7 Audio Transparency
for the audio m line allows relaying unknown attributes. allows transparency for subset of attributes like 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. supports audio transparency for known attributes by relaying attributes and codecs transparently in pass-through scenarios for SIP-SIP calls only. However, the following exceptions require system handling:- recvonly/sendonly/sendrecv/inactive
- crypto
- X-dmi
- rtcp
- fingerprint
- OMR
| Note |
|---|
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:
unknownCodecBitRateunknownCodecPacketSize
| Note |
|---|
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. |
3.7.1 Audio Transparency and Reserve Bandwidth for Preferred Common Codec
By default for pass-through calls,
reserves the worst case common audio codec bandwidth on Trunk Groups and IP interfaces, and polices for the same bandwidth. To facilitate pass-through calls scenarios/cases, where media uses the preferred common codec the flag 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.| Note |
|---|
This flag can be used independently or in conjunction with Audio Transparency feature and/or policeOnHeaviestAudioCodec flag. This functionality is currently supported for SIP-SIP call scenarios only. In the event that policeOnHeaviestAudioCodec and reserveBwForPreferredAudioCommonCodecare both configured, the following behavior applies: reserveBwForPreferredAudioCommonCodec impacts the bandwidth reservation policy. That is, first common codec from Answer (SIP) and,policeOnHeaviestAudioCodec impacts the policer configuration. That is, heaviest codec in the offer or answer.
|
| Note |
|---|
The flag reserveBwForPreferredAudioCommonCodec is active for a call when both the PSPs have this flag enabled. If this flag is disabled in any of the PSPs, the flag is not applied. |
3.7.2 Media Policer Reservation For Worst Case Codec
By default, for pass-through calls the
reserves the worst case common audio codec bandwidth on trunk groups and IP interfaces, and polices for the same bandwidth. To facilitate asymmetric pass-through calls scenarios/cases and to police on the heaviest codec in the offer or answer, a new flag policeOnHeaviestAudioCodec is introduced in PSP.| Note |
|---|
This flag can be used independent of or in conjunction with Audio transparency feature and/or reserveBwForPreferredAudioCommonCodec flag. This functionality is currently supported for SIP-SIP call scenarios only. |
3.8 Allow/Supported/Require Transparency Profiles
supports a set of SIP Tags and Method names using CLI and EMA and assign that profile to a Trunk Group (TG). The SIP headers configured in this table are transparently passed on to the Egress TG if received in the Ingress SIP message. This configuration is used in concert with a number of new internal arrays and tables to provide the new transparency functionality within the .To support this functionality the following profiles are added:
This feature provides SIP tags only for unknown SIP parameter transparency. Known SIP parameter transparency is still determined using existing
application logic (from Ingress leg to Egress leg) and configurationThese profile have precedence of existing mechanism/flags when it comes to passing through content of Allow/Supported/Require headers but it does not impact corresponding semantics executed by
. It is the responsibility of the user to configure the system properly so that passed through values do not conflict with semantics. For example, 100rel should not be configured as pass-through if 100rel support for SIP Trunk Group Signaling is disabled.The profile both for Ingress and Egress legs determines the actual pass-through result. It is possible to control pass-through for individual values for each header.
Allow/Supported/Require Profiles related procedures are executed after Ingress SMM and before other Ingress processing on the Ingress leg and after other Egress processing and before Egress SMM on the Egress leg.
| Info |
|---|
| The supports configuring up to 32 SIP Param Filter Profiles. Each profile can be configured using any/all of the three SIP headers. |
The following table explains the semantics of the Allow/Supported/Require Profiles.
| Caption |
|---|
| 0 | Table |
|---|
| 1 | Allow/Supported/Require Profiles Semantics |
|---|
|
| Allow | - For Ingress leg Allow header processing: The Allow header in the received message after Ingress SMM processing but before any other processing is taken as base.
- If pass-through <method name list> is specified for Ingress leg respective to the message under consideration, methods present in the Allow header but not in the <method name list> are removed.
- If pass-through "all" is specified for Ingress leg respective to the message under consideration, methods present in the Allow header are left intact.
- If block <method name list> is specified for Ingress leg respective to the message under consideration, methods present in the <methods name list> are removed if they exist in the Allow header.
- If block "all" is specified for Ingress leg respective to the message under consideration, all methods present in the Allow header are removed.
- For Egress Allow header processing: The Allow header in the message to be egressed by after all the processing but before Egress SMM processing is taken as the base.
- If pass-through <method name list> is specified for Egress leg respective to the message under consideration, methods present in the Allow header to be egressed but not in the <method name list> are removed.
- If pass-through "all" is specified for Egress leg respective to the message under consideration, methods present in the Allow header are left intact.
- If block <method name list> is specified for Egress leg respective to the message under consideration, methods present in the <methods name list> are removed if they exist in the Allow header.
- If block "all" is specified for Egress leg respective to the message under consideration, all methods present in the Allow header are removed.
|
|---|
Require/Supported | - For Ingress leg Require/Supported header processing: The Require/Supported header in the received message after Ingress SMM processing but before any other processing is taken as base.
- If pass-through <option tag list> is specified for Ingress leg respective to the message under consideration, option tags present in the Require/Supported header but not in the <option tag list> are removed.
- If pass-through "all" is specified for Ingress leg respective to the message under consideration, option tags present in the Require/Supported header are left intact.
- If block <option tag list> is specified for Ingress leg respective to the message under consideration, option tags present in the <option tag list> are removed if they exist in the Require/Supported header.
- If block "all" is specified for Ingress leg respective to the message under consideration, all option tags present in the Require/Supported header are removed.
- For Egress Require/Supported header processing: the Require/Supported header in the message to be egressed by after all processing but before Egress SMM processing is taken as the base.
- If pass-through <option tag list> is specified for Egress leg respective to the message under consideration, option tags present in the Require/Supported header to be egressed but not in the <option tag list> are removed.
- If pass-through "all" is specified for Egress leg respective to the message under consideration, option tags present in the Require/Supported header are left intact.
- If block <option tag list> is specified for Egress leg respective to the message under consideration, option tags present in the <option tag list> are removed if they exist in the Require/Supported header.
- If block "all" is specified for Egress leg respective to the message under consideration, all option tags present in the Require/Supported header are removed.
If an option tag present in the received Ingress request is dropped due to Require Transparency settings, and if reject request is configured, the request is rejected with a new internal cause code. This internal cause code is mapped to 420 "Bad Extension" by default. Option-tags added to Require header due to processing, for example path, are not cause rejection of the message even if they are eventually dropped by the Require Transparency Functionality.
|
|---|
|
reserveBwForPreferredAudioCommonCodec