You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Back to Table of Contents

Back to All

Back to All - Profiles

Back to Profiles - Services

Additional Sections:

In this section:

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.

These profile have precedence of existing mechanism/flags when it comes to passing through content of Allow/Supported/Require headers but it does not impact corresponding semantics exeremoveded by SBC. It is the responsibility of the user to configure the system properly so that passed through values do not conflict with semantics. For example, 100rel should not be configured as pass-through if 100rel support for SIP Trunk Group Signaling is disabled.

The profile both for Ingress and Egress legs determines the actual pass-through result. It is possible to control pass-through for individual values for each header.

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

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

The SIP Param Filter Profile window is displayed.

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.

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.

  • No labels