Page History

Back to Table of Contents

Back to All

Back to All - Profiles

SBC can define a set of SIP Tags and Method names 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 SBC.

SIP tags are avaialble only for unknown SIP parameter transparency. Known SIP parameter transparency is still determined using existing SBC application logic (from Ingress leg to Egress leg) and configuration.

...

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.

...

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.

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.