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.


Overview

Each SIP Adaptor Profile can contain up to 10,000 rules that are applied sequentially to messages. Each rule can have up to 20 criteria and up to 128 actions. The SIP Message Manipulation (SMM) rule processing inspects each SIP message and looks for a matches with its defined criteria. If all the criteria are met, SMM applies its defined action(s) to the message and sends the message for further processing.

Rules within a profile are applied to messages sequentially in the order of the rule index numbers.

  • If a message meets a rule criteria, it is processed by that rule and then passed to the next rule. Therefore, a message might be modified by more than one rule.
  • If a message does not meet a rule criteria, it is passed to the next rule.
  • If a message does not meet any criteria in any of the rules, it is passed on unmodified.

Each rule consists of two main parts:

  • One or more criteria
  • One or more actions

Criteria includes the conditions required to execute the rules. Actions specify the actual modifications to perform.

IMPORTANT

Do not use SMM to manipulate To, From, Contact and Request URIs in incoming REGISTER messages.

IMPORTANT

For an OPTIONS ping that the SBC generates for Pathcheck, apply the SMM only at the Global level. If the SMM is attached at Zone, TG, or AddressContext, the rules are not applied. Refer to Signaling - Global - CLI for applying SMM profiles (SIP adaptor profiles) at the global level.

Note

The SBC uses GNU Extended Regular Expressions character sets, which does not support the characters "\d" and "\D". Ribbon recommends not using "\d" and "\D" in the regular expressions of SMM rule criteria. As an alternative, use the [0-9] format.

SMM Rule Categories

Rules are logically grouped into the following categories.

  • Message Rule—Ignore an inbound message by dropping silently or by not sending an outbound message. Reject a message (requests) with a configured response code. Create a URI.
  • Header Rule—Add/delete headers or modify their content.
  • Parameter Rule—Add/delete parameters in a header or modify their content.
  • Token Rule—Add/delete tokens in a header or modify their content.
  • Internal Variable Rule—Set or compare the values of internal variables. Criteria should specify that the modification must be performed on the variable and the variable ID.
  • Global Variable Rule—Use Global Variables to modify a header, parameter, token, message body, or variable. Criteria should specify the Global Variable name and the name of the target to modify with the global variable.
  • Message Body Rule—Add, delete or modify message body contents. Criteria should specify that modification must be performed on the message body.
Limitation:

Once you modify a header instance's Header-Value, all subsequent rules for validating/modifying the same instance are invalidated.

Unknown Headers and Parameters

As rules are defined, some headers or parameters may be unknown to the SBC (for example, a rule to remove a proprietary header). In such cases, even though the SBC does not have any information about the type of header or parameter, it can still refer to the tokens in these constructs.
It is assumed that if a rule refers to a userpart or hostpart, the corresponding header or parameter is in URL format.

  • Userpart value is the content before "@". If there is a ";" in that portion, the userpart value contains only the parts present before it.
  • Hostpart value is the content after "@". The value contains the content until the end of the header line or until a ";" or ">" is met.

SMM Rules on a Live System

The SBC supports modifying SMM rules on a live system. SBC users can edit or update the SMM rules in a SIP Adaptor profile without changing the admin state. The existing rules continue to exist and new rules are active once confirmed or applied. 

Two Variables Comparison Support

SMM provides functionality to compare two variables. The criterion values, variables-equal and variables-not-equal, determine:

  • If the two variables exist and are equal.
    or
  • If the two variables exist and are not equal.

Write CDRs using SMM Rules

Five CDR fields of 256 bytes each are provided to log proprietary information in accounting records using SMM rules:

  • SMM-Field-1
  • SMM-Field-2
  • SMM-Field-3
  • SMM-Field-4
  • SMM-Field-5

These fields are present in SIP Specific Protocol string of the START, STOP, INTERMEDIATE, and ATTEMPT records for session-based accounting.

The value of the above SMM CDR fields can store:

  • Header value of the SMM rules.
  • Parameter value of the SMM rules.
  • The value stored in the variable.
  • The token value.

Dropping "18x with 100Rel" and Handling PRACK

The SBC supports generating and sending PRACK messages internally and sending PRACK messages back to the IAD if an incoming 18x with 100Rel is dropped.

Feature limitations:

  • It is assumed that the dropped 18x does not carry a new offer.
  • If a 18x is dropped by an SMM rule, for a call to succeed, the "200 OK for INVITE" must contain the SDP.
  • If End-to-End PRACK is enabled, do not use SMM rules to drop "18x with 100Rel."
  • If a "18x with 100Rel" is dropped on egress, the Required Header received on ingress is not passed to the egress when Required Header Transparency is enabled.
  • If a "18x with 100Rel" is dropped by an SMM rule, INVITEs with "Require:100 rel" are not supported.

Native SDP Manipulation Support

The SBC uses SMM to manipulate SDP using regular expressions. 

You must use CLI commands; there is no EMA support for Native SDP Manipulation.

You can create SMM rules to directly manipulate SDP using the following operations:

ADD Operation

Use the ADD operation to:

  • add a line to the session block
  • add a line to the specific media stream
  • add a parameter to the specific SDP line in either session block or media stream
  • add a codec (codec name) to a specific instance of a particular media stream or all instances of that particular media stream
  • add a new stream to the SDP

DELETE Operation

Use the DELETE operation to:

  • delete a line in the session block
  • delete a line in a specific media stream
  • delete a parameter from a specific SDP line
  • delete a codec (codec name) in a specific instance of a particular media stream or all instances of that particular media stream
  • delete a codec by the position as it appears in the "m=" line in a specific instance of a particular media stream or all instances of that particular media stream

GET Operation

Use the GET operation to store the:

  • payload type for a given codec (full codec name) in a specific instance of a particular media stream
  • codec position as it appears in the "m=" line for given codec (partial codec will be supported) in a specific instance of a particular media stream

STORE Operation

Use the STORE operation to store:

  • a line in the session
  • a line in a specific media stream
  • a parameter in a specific SDP line

FILTER-CODEC Operation

Use the FILTER-CODEC operation to filter or re-arrange the codecs in a particular media stream. The From operand value represents the codec pattern being applied for the filtering. The pattern can contain up to 25 comma-separated codec names, or the wildcard codec "*". Do not use more than one wildcard "*" codec in the codec pattern.

Note

Limitations:

  • You can use the Value type as "From" to specify a pattern of up to 25 comma-separated codecs. However, the total length of the pattern cannot exceed 128 bytes.
  • You can use the Variable type as "From" to specify a pattern of up to 25 comma-separated codecs. However, the total length of the pattern cannot exceed 256 bytes.

CONDITION EXIST Criterion

Use the CONDITION EXIST Criterion option to:

  • use criterion type "sdpContent" to determine whether a specific media stream contains a codec-specific criterion
  • use messageBody type "messageBody: SDP" to determine whether SDP content exists in the message body

SMM Switch Semantics

The SBC is able to reduce the usage of SMM rules significantly using switch semantics. To support this functionality, the object switch can be added to the sipAdaptorProfile. When a value or a regular expression string matches a defined SMM rule, the corresponding action is performed. Switch semantics are applicable only to the variables, global variables, headers, parameters, and tokens of SMM rules. 

  • You can configure up to 128 switch values.
  • This feature is not applicable for message body and isup parameters.
  • Actions configured in switch should be present in the list of actions created.
  • The keyword others can be used for the switchValue which represents all the values which are not explicitly specified.