In this section:

Related articles:

 

The SIP Param Filter Profile is used by SBC to create one or more profiles defining whether to block or transparently pass option tags/methods for SIP headers Allow, Require and Supported.

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

For feature details, see SBC SIP Transparency Implementation Guide.


IMPORTANT

Ribbon recommends using the Transparency Profile to configure transparency on the SBC Core for new deployments, as well as applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases.

Refer to the SBC SIP Transparency Implementation Guide for additional information.

To View SIP Param Filter Profile

On the SBC main screen, go to All > Profiles > Services > SIP Param Filter Profile.

The SIP Param Filter Profile window is displayed.

Figure 1: SIP Param Filter Profile

To Edit SIP Param Filter Profile

To edit any of the SIP Param Filter Profile in the list, click the radio button next to the specific SIP Param Filter Profile name.

The Edit Selected SIP Param Filter Profile window is displayed below.

Make the required changes and click Save at the right hand bottom of the panel to save the changes made.

To Create SIP Param Filter Profile

To create a new SIP Param Filter Profile, click New SIP Param Filter Profile tab on the SIP Param Filter Profile List panel.

The Create New SIP Param Filter Profile window is displayed.

The following fields are displayed:

Table 1: SIP Param Filter Profile Parameters

Parameter

Description

Name

Specifies the name of the SIP Param Filter Profile.

State

Specifies the admin state of this SIP option tag Param Filter Profile. Enable this option to reject the request if tag is dropped due to this profile settings. The options are:

  • Disabled (default)
  • Enabled

To Copy SIP Param Filter Profile

To copy any of the created SIP Param Filter Profile and to make any minor changes, click the radio button next to the specific SIP Param Filter Profile to highlight the row.

Click Copy SIP Param Filter Profile tab on the SIP Param Filter Profile List panel.

The Copy Selected SIP Param Filter Profile window is displayed along with the field details which can be edited.

Make the required changes to the required fields and click Save to save the changes. The copied SIP Param Filter Profile is displayed at the bottom of the original SIP Param Filter Profile in the SIP Param Filter Profile List panel.

To Delete SIP Param Filter Profile

To delete any of the created SIP Param Filter Profile, click the radio button next to the specific SIP Param Filter Profile which you want to delete.

Click Delete at the end of the highlighted row. A delete confirmation message appears seeking your decision.

Click Yes to remove the specific SIP Param Filter Profile from the list.

Allow/Supported/Require Profiles Semantics

The Allow and Require/Supported semantics are listed below.

Allow

  • For Ingress leg Allow header processing: The Allow header in the received message after Ingress SMM processing but before any other SBC 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 SBC after all SBC 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 SBC 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 SBC after all SBC 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 SBC processing, for example path, are not cause rejection of the message even if they are eventually dropped by the Require Transparency Functionality.


  • No labels