In this section:
A criteria identifies which conditions to meet before a modification specified in an action part is executed. Different criteria elements and their use cases include:
- Message Criteria Element—Specifies whether the rule applies for requests/responses/both, method name and if response code/response code range is applicable. This criteria element must be present in all types of rules.
- Header Criteria Element—Specifies for which header the rule is applicable. This criteria element must be present in Request Line, Header, Parameter and Token rules.
- Parameter Criteria Element—Specifies for which parameter the rule is applicable. This criteria element must be present in Parameter rules.
- Token Criteria Element—Specifies for which token the rule is applicable. This criteria element must be present in Token rules.
- Variable Criteria Element—Specifies for which value of an internal variable the rule is applicable. This criteria element must be present in Variable rules.
- Global Variable Criteria Element—Specifies for which value of the global variable the rule is applicable. This criteria must be present in the global variable rules.
- Message Body Criteria Element—Specifies for which message body the rule is applicable. This criteria must be present in the message body rules.
Different SIP elements are used while identifying the criteria, as described below.
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.
Message Criteria
The Message criteria optionally specifies a SIP request or response for a particular method or response (status) code, as follows:
- All messages
- All requests
- Requests for a specified SIP method
- All responses
- All responses for a specified SIP method
- Responses with a specified status code
- Responses with a specified status code for a specific SIP method
- Responses with a specified status code range
- Responses with a specified status code range for a specific SIP method
SIP Header Criteria
The Header criteria specify the presence, absence, or value of a specific SIP Header as follows:
- Presence of a specified SIP header/Request-URI
- Absence of a specified SIP header/Request-URI
- Specified SIP header contains a specified value
- Specified SIP header does not contain a specified value
- Value of specified SIP header matches a specified regular expression
- Value of specified SIP header does not match a specified regular expression
Per RFC 3261 section 7, the Field Value is defined per header-name. As either an opaque sequence of TEXT-UTF8 octets, or a combination of white space, tokens, separators, and quoted strings. Many existing header fields adhere to the general form of a value followed by a semicolon (;) separated sequence of parameter-name, parameter-value pairs, as shown below:
field-name: field-value *(;parameter-name=parameter-value)
In the following example, "terminated" is a field value:
Subscription-State: terminated; reason=rejected
A set of criteria must always include a single SIP Header instance that specifies the SIP Header/Request-URI to be used for the indicated action.
When multiple instances of the same header are present in a message, headers are examined in the order presented. This action applies to the Header Instances (or range of instances) which match the Header Criterion specified in the rule.
Regular expressions are based on the following W3C regular expressions pattern which is defined as a pattern, or sub-pattern, containing any white space or none white space string for up to 128 characters. The pattern can occur zero or one time.
"(((([\s\S])){0,128})){0,1}"
SIP Parameter Criteria
SIP parameter criteria specify the presence, absence, or value of a specific SIP Parameter as follows:
- Presence of a specified SIP parameter
- Absence of a specified SIP parameter
- SIP parameter has a specified value
- SIP parameter does not have a specified value
- Value of a SIP parameter matches a specified regular expression
- Value of a SIP parameter does not match a specified regular expression
If a criterion contains a SIP parameter component, it is evaluated together with the SIP header component. For example, if the SIP header component = presence of P-CALLED-PARTY-ID, and the SIP parameter component = absence of OPERATOR parameter, the rule matches if P-CALLED-PARTY-ID is present and no operator parameter is present in the P-CALLED-PARTY-ID.
Three different types of parameters may be specified as detailed in the table below. The parameter type allows the criterion to locate the position of specified parameter.
SIP Parameter Types
| SIP Parameter Type | Description | Example |
|---|---|---|
| Generic | Generic parameters are added to headers after the field value. | In the following example, "
|
| URI | URI Parameters follow addresses in different URI schemes. They are distinguished from generic parameters by being present before the greater-than (>) symbol in a URI value. | In following example, "
|
| User | User Parameters are embedded in SIP/SIPS URI schemes and are present in the userpart, i.e. they are positioned before the @ and are separated from the actual userpart value by a semi-colon (;). | In following example, "
|
ISUP Parameter Criteria
ISUP parameter criteria specify the presence, absence, or value of a specific ISUP parameter as follows:
- Presence of a specified ISUP parameter
- Absence of a specified ISUP parameter
- ISUP parameter has a specified value
- ISUP parameter does not have a specified value
- Value of a ISUP parameter matches a specified regular expression
- Value of a ISUP parameter does not match a specified regular expression
Info
Refer to SIP-I Support for additional parameter details.
Token Criteria
Token criteria specify the following:
- Presence of a token
- Absence of a token
- A SIP token has a specified value
- A SIP token does not have a specified value
- Value of a SIP token matches a specified regular expression
- Value of a SIP token does not match a specified regular expression
Tokens displayname, username, hostname, scheme and hostport are available to define a token criterion. A criterion may or may not have a token component. If token component is present, it must be evaluated together with the SIP header component or with SIP header/SIP parameter components.
Internal Variable Criteria
The Internal Variable criteria specify the following:
- Presence of a specified internal variable
- Absence of a specified internal variable
- Internal variable has a specified value
- Internal variable does not have a specified value
- Value of an internal variable matches a specified regular expression
- Value of an internal variable does not match a specified regular expression
Internal variables temporarily store values of SIP elements in a message. Internal variables have predefined names in the range VAR1, VAR2,... VAR30. An internal variable with a specified value can also be a criteria. A defined internal variable is available to all rules in a SIP Adaptor Profile when a message is being modified.
A value specified for a criteria component can be a static value, e.g. phonecompany.com, or an internal variable, e.g. VAR6. If an internal variable is given, its value is used.
Global Variable Criteria
The Global Variable criteria specify the following:
- Presence of a specified global variable
- Absence of a specified global variable
- Global variable has a specified value
- Global variable does not have a specified value
- Value of a global variable matches a specified regular expression
- Value of a global variable does not match a specified regular expression
Global variables are another type of internal variable. Currently seven global variables are supported: srcipaddr, srcport, sigportID, localIP, localPort, ingressTgName and egressTgName. A global variable with a specified value can also be a criteria. Global variables always exist; unlike internal variables, it is not necessary to create them. Plus, a global variable is always read-only, and its value is set when applying the rules in the SIP Adaptor Profiles.
Do not use egressTgName or ingressTgName in a SMM profile defined at the Zone level. Also, egressTgName and ingressTgName can only be used in an outputAdaptor profile.
Message Body Criteria
The Message Body criteria specify the following:
- Presence of a specified content type
- Absence of a specified content type
- Value of a message body matches a specified regular expression
- Value of a message body does not match a specified regular expression
A criterion may or may not have a message body component. If a criterion contains a message body component matching the message body of a SIP Message, the SIP Message is manipulated as specified in message body rules.
Overview
Content Tools