Page History

Back to Table of Contents

Back to All

Back to All - Profiles

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.

To View SIP Param Filter Profile

...

Click OK Yes 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 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.