Page History

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

Make note that the sdpTransparencyState signaling object within the SIP Trunk Group should 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.

...

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 

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

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

...

...

3.6 Relaying REFER Request

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. 

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, 

  Spacevars
  0 company

...

• relays the REFER request to Egress SIPSG.
• If the call parameters received with the REFER request do not match the call routing criteria, the REFER request is processed locally by

  Spacevars
  0 company

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

  sends back a 202 response and proceeds for local processing.

3.6.1 Configuring 

Spacevars
0 company

For Enhanced Refer Processing

To configure this feature, perform the following steps:

1. Configure 

   Spacevars
   0 company

   for regular REFER call Blind Transfer.

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

   Caption
   0 Figure 1 Call Parameter Filter Profile List showing SIP_MSG_TYPE_REFER profile
   Image Added

   Note
   A new script SONS_SIP_REFER_RELAY is seeded in both ERE and PSX.

3. Disable the Refer relay flag in IPSP.

   Code Block
   % set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags refer disable

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

   Caption
   0 Figure 1 Notify and Refer relay flags
   Image Added

5. Create a new routing label with the script SONS_SIP_REFER_RELAY to trigger process refer request feature.

   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

   Caption
   0 Figure 1 Creating a Routing Label
   Image Added

   Caption
   0 Figure 1 Routing Label screen
   Image Added

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

   Note
   The corresponding Sip domain group must be configured in Spacevars 0 company .

   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

   Caption
   0 Figure 1 Creating a Route
   Image Added

   Caption
   0 Figure 1 Route screen
   Image Added

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

3.7 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,

3.7.1 Maximum Transparency using the Transparency Profile

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.

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.

3.7.2 Transparency Profile, All Headers, with Exceptions

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.

set profiles services transparencyProfile ALMOST_ALL_HDRS sipHeader all
set profiles services transparencyProfile ALMOST_ALL_HDRS sipHeader History-Info ignoreTransparency yes
set profiles services transparencyProfile ALMOST_ALL_HDRS state enabled
commit
set addressContext <AC> zone <ZONE> sipTrunkGroup <TG> services transparencyProfile ALMOST_ALL_HDRS
commit

3.7.3 Existing Deployment Augmented with a Transparency Profile

Existing deployments will likely utilize Transparency Flags, and those that must pass proprietary or otherwise 

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 

Rather than continue to allow all unknown headers through the

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

3.8 Audio Transparency

• recvonly/sendonly/sendrecv/inactive
• crypto
• X-dmi
• rtcp
• fingerprint
• OMR

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

3.8.1 Audio Transparency and Reserve Bandwidth for Preferred Common Codec

By default for pass-through calls, 

3.8.2 Media Policer Reservation For Worst Case Codec

By default, for pass-through calls the

3.8.3 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

% set addressContext default zone ZONE1 sipTrunkGroup TG_SBX_INT media sdpAttributesSelectiveRelay enabled
% set addressContext default zone ZONE2 sipTrunkGroup TG_SBX_EXT media sdpAttributesSelectiveRelay enabled

% set profiles media packetServiceProfile PSP_INT packetToPacketControl transcode transcoderFreeTransparency 
% set profiles media packetServiceProfile PSP_EXT packetToPacketControl transcode transcoderFreeTransparency

% 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

3.9

3.6.1 Maximum Transparency using the Transparency Profile

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.

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.

3.6.2 Transparency Profile, All Headers, with Exceptions

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.

set profiles services transparencyProfile ALMOST_ALL_HDRS sipHeader all
set profiles services transparencyProfile ALMOST_ALL_HDRS sipHeader History-Info ignoreTransparency yes
set profiles services transparencyProfile ALMOST_ALL_HDRS state enabled
commit
set addressContext <AC> zone <ZONE> sipTrunkGroup <TG> services transparencyProfile ALMOST_ALL_HDRS
commit

3.6.3 Existing Deployment Augmented with a Transparency Profile

Existing deployments will likely utilize Transparency Flags, and those that must pass proprietary or otherwise 

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 

Rather than continue to allow all unknown headers through the

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

3.7 Audio Transparency

• recvonly/sendonly/sendrecv/inactive
• crypto
• X-dmi
• rtcp
• fingerprint
• OMR

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

3.7.1 Audio Transparency and Reserve Bandwidth for Preferred Common Codec

By default for pass-through calls, 

3.7.2 Media Policer Reservation For Worst Case Codec

By default, for pass-through calls the

...

SIP Param Filter Profile

This feature provides SIP tags only for unknown SIP parameter transparency. Known SIP parameter transparency is still determined using existing 

...

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.

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.

The following table explains the semantics of SIP Param Filter Profile behavior when using the Allow/, Supported /and Require Profilesheaders.