The SIP Param Filter Profile is used by SBC to create one or more profiles defining whether to block or to 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 (see SIP Param Filter Profile 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.
For additional details, see SBC SIP Transparency Implementation Guide.
To View SIP Param Filter Profile
On SBC main screen, go to All > Profiles > Services > SIP Param Filter Profile.
The SIP Param Filter Profile window is displayed.
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.
SIP Param Filter Profile Highlighted
The Edit Selected SIP Param Filter Profile window is displayed below.
SIP Param Filter Profile Edit Window
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.
SIP Param Filter Profile Fields
The Create New SIP Param Filter Profile window is displayed.
SIP Param Filter Profile Create Window
The following fields are displayed:
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.
SIP Param Filter Profile Highlighted
Click Copy SIP Param Filter Profile tab on the SIP Param Filter Profile List panel.
SIP Param Filter Profile Fields
The Copy Selected SIP Param Filter Profile window is displayed along with the field details which can be edited.
SIP Param Filter Profile Copy Window
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.
SIP Param Filter Profile Highlighted
Click Delete at the end of the highlighted row. A delete confirmation message appears seeking your decision.
SIP Param Filter Profile Delete Confirmation
Click OK to remove the specific SIP Param Filter Profile from the list.
Allow/Supported/Require Profiles Semantics
The following table explains the semantics of the Allow/Supported/Require Profiles.
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 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.
|
|---|
