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.
Multiexcerpt include |
---|
MultiExcerptName | SMM_note_incoming_register_messages |
---|
PageWithExcerpt | _SMM_Incoming_Register_Messages_Note |
---|
|
Different SIP elements are used while identifying the criteria, as described below.
Multiexcerpt include |
---|
MultiExcerptName | SMM_Rule_Criteria_Regex_ExtendedRegex_Note |
---|
PageWithExcerpt | _SMM_Rule_Criteria_Regex_ExtendedRegex_Note |
---|
|
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
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.
Note |
---|
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. |
Include Page |
---|
| Regular_expression |
---|
| Regular_expression |
---|
|
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.
Caption |
---|
0 | Table |
---|
1 | SIP Parameter Types |
---|
3 | SIP Parameter Types |
---|
|
SIP Parameter Type | Description | Example |
---|
Generic | Generic parameters are added to headers after the field value. | In the following example, "reason " is a generic parameter with value of "rejected": Subscription-State: terminated; reason=rejected
| 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, "lr " is a URI parameter: Route: <sip: proxy@example.com; lr>
| 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, "phone-context " is a user parameter with a value = 5, and "user " is a URI parameter with a value of "phone": INVITE sip: +125-323-1234567; phone-context=5@foo.com; user=phone SIP/2.0
|
|
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
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.
Note |
---|
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.