Unique HMR Regex Patterns and Other Changes
In addition to the HMR support it offers, the Oracle Communications Session Border Controller can now be provisioned with unique regex patterns for each logical remote entity. This supplement to pre-existing HMR functionality saves you provisioning time and saves Oracle Communications Session Border Controller resources in instances when it was previously necessary to define a unique SIP manipulation per PBX for a small number of customer-specific rules.
The Default Expression
The SBC supports the non-standard regex
\,+
called the default expression. The default expression matches one or more
characters, including NUL characters. The default expression cannot be used
with other modifiers, like the star.
Note:
In previous releases, the PCRE (Perl Compatible Regular Expression) engine used\, to
match any character, including a NUL character. The PCRE engine was updated in
8.1 and no longer supports
\,.
Manipulation Pattern Per Remote Entity
On the Oracle Communications Session Border Controller, you can configure logical remote entities (session agents, realms, and SIP interfaces) with a manipulation pattern string that the system uses as a regular expression. Then the SIP manipulation references this regular expression using the reserved word $MANIP_PATTERN. At runtime, the Oracle Communications Session Border Controller looks for the logical entity configured with a manipulation pattern string in this order of preference: session agent, realm, and finally SIP interface.
On finding the logical entity configured with the manipulation string, the Oracle Communications Session Border Controller dynamically determines the expression. When there is an invalid reference to a manipulation pattern, the pattern-rule expression that results will turn out to be the default expression (which is \,+).
When the $MANIP_PATTERN is used in a manipulation rule’s new-value parameter, it resolves to an empty string, equivalent of no value. Even though this process ends with no value, it still consumes system resources. And so Oraclerecommends you do not use $MANIP_PATTERN as a new-value value.
In the following example, the SIP manipulation references the regular expression from a realm configuration:
realm-config
identifier net200
description
addr-prefix 0.0.0.0
network-interfaces public:0
...
manipulation-pattern Lorem(.+)
sip-manipulation
name manip
description
header-rules
name headerRule
header-name Subject
action manipulate
match-value $MANIP_PATTERN
msg-type request
comparison-type pattern-rule
new-value Math
methods INVITEReject Action
When you use this action type and a condition matching the manipulation rule arises, the Oracle Communications Session Border Controller rejects the request (though does not drop responses) and increments a counter.
- If the msg-type parameter is set to any and the message is a response, the Oracle Communications Session Border Controller increments a counter to show the intention to reject the message—but the message will continue to be processed.
- If the msg-type parameter is set to any and the message is a request, the Oracle Communications Session Border Controller performs the rejection and increments the counter.
The new-value parameter is designed to supply the status code and reason phrase corresponding to the reject. You can use the following syntax to supply this information: status-code[:reason-phrase]. You do not have to supply the status code and reason phrase information; by default, the system uses 400:Bad Request.
If you do supply this information, then the status code must be a positive integer between 300 and 699. The Oracle Communications Session Border Controller then provides the reason phrase corresponding to the status code. And if there is no reason phrase, the system uses the one for the applicable reason class.
You can also customize a reason phrase. To do so, you enter the status code followed by a colon (:), being sure to enclose the entire entry in quotation marks () if your reason code includes spaces.
When the Oracle Communications Session Border Controller performs the reject action, the current SIP manipulation stops processing and does not act on any of the rules following the reject rule. This course of action is true for nested SIP manipulations that might have been constructed using the sip-manip action type.
Reject Action Configuration
To support the reject action, set two parameters in the session-router-config configuration element.
About Counters
The Oracle Communications Session Border Controller tracks messages that have been flagged for rejection using the reject action type. In the show sipd display, refer to the Rejected Messages category; there is no distinction between requests and responses.
ORACLE# show sipd
13:59:07-102
SIP Status -- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Sessions 0 0 0 0 0 0
Subscriptions 0 0 0 0 0 0
Dialogs 0 0 0 0 0 0
CallID Map 0 0 0 0 0 0
Rejections - - 0 0 0
ReINVITEs - - 0 0 0
Media Sessions 0 0 0 0 0 0
Media Pending 0 0 0 0 0 0
Client Trans 0 0 0 0 0 0
Server Trans 0 0 0 0 0 0
Resp Contexts 0 0 0 0 0 0
Saved Contexts 0 0 0 0 0 0
Sockets 0 0 0 0 0 0
Req Dropped - - 0 0 0
DNS Trans 0 0 0 0 0 0
DNS Sockets 0 0 0 0 0 0
DNS Results 0 0 0 0 0 0
Rejected Msgs 0 0 0 0 0 0
Session Rate = 0.0
Load Rate = 0.0
Remaining Connections = 20000 (max 20000)SNMP Support
The Oracle Communications Session Border Controller provides SNMP support for the Rejected Messages data, so you can access this information externally. The new MIB objects are:
apSysRejectedMessages OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of messages rejected by the SD due to matching criteria."
::= { apSysMgmtMIBGeneralObjects 18 }
apSysMgmtRejectedMesagesThresholdExeededTrap NOTIFICATION-TYPE
OBJECTS { apSysRejectedMessages }
STATUS current
DESCRIPTION
" The trap will be generated when the number of rejected messages exceed the configured threshold within the configured window."
::= { apSystemManagementMonitors 57 }
apSysMgmtRejectedMessagesGroup OBJECT-GROUP
OBJECTS {
apSysRejectedMessages
}
STATUS current
DESCRIPTION
"Objects to track the number of messages rejected by the SD."
::= { apSystemManagementGroups 18 }
apSysMgmtRejectedMessagesNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
apSysMgmtRejectedMesagesThresholdExeededTrap
}
STATUS current
DESCRIPTION
"Traps used for notification of rejected messages"
::= { apSystemManagementNotificationsGroups 26 }
apSmgmtRejectedMessagesCap
AGENT-CAPABILITIES
PRODUCT-RELEASE "Acme Packet SD"
STATUS current
DESCRIPTION "Acme Packet Agent Capability for enterprise
system management MIB."
SUPPORTS APSYSMGMT-MIB
INCLUDES {
apSysMgmtRejectedMessagesGroup,
apSysMgmtRejectedMessagesNotificationsGroup
}
::= { apSmgmtMibCapabilities 37 }Log Action
When you use this action type and a condition matching the manipulation rule arises, the Oracle Communications Session Border Controller logs information about the current message to a separate log file. This log files will be located on the same core in which the SIP manipulation occurred. On the core where sipt runs, a logfile called matched.log will appear when this action type is executed.
The matched.log file contains a timestamp, received and sent Oracle Communications Session Border Controller network interface, sent or received IP address:port information, and the peer IP address:port information. It also specifies the rule that triggered the log action in this syntax: rule-type[rule:name]. The request URI, Contact header, To Header, and From header are also present.
----------------------------------------
Apr 17 14:17:54.526 On [0:0]192.168.1.84:5060 sent to 192.168.1.60:5060
element-rule[checkRURIPort]
INVITE sip:service@192.168.1.84:5060 SIP/2.0
From: sipp <sip:+2125551212@192.168.1.60:5060>;tag=3035SIPpTag001
To: sut <sip:service@192.168.1.84>
Contact: sip:sipp@192.168.1.60:5060Changes to Storing Pattern Rule Values
Release S-C6.2.0 introduces changes to the framework for storing regular expression results within manipulation rules, altering the way the store action works. These changes are beneficial to performance.
In previous releases, when the store action is used, the Oracle Communications Session Border Controller stores all values matching the regular expression defined in the match-value parameter for all headers. At runtime, the system evaluates all stored values to find the correct index.
Now, you no longer need to specify the store action. The simple fact of referencing another rule tells the system it must store a value. When SIP manipulation is used, the system first checks to see if any values require storing. The add action is an exception to this process; storing happens after a header is added.
When referring to a rule, that rule still needs to have a regular expression defined in the match-vale and the comparison type set to pattern-rule; else the default expression will be used.
Removal of Restrictions
The following restrictions related to HMR have been removed in Release S-C6.2.0:
- The action find-replace-all now executes all element rules. Previously, no child rules were executed.
- The action sip-manip now executes existing all element rules. Previously, no child rules were executed.
- The action store now executes existing all element rules. Previously, only child rules with the store action were executed.
- The action add now executes existing all element rules. Previously, only child rules with the add action were executed.
Name Restrictions for Manipulation Rules
Historically, you have been allowed to configure any value for the name parameter within a manipulation rule. This method of naming caused confusion when referencing rules, so now manipulation rules name must follow a specific syntax. They must match the expression ^[[alpha:]][[:alnum:]_]+$ and contain at least one lower case letter.
In other words, the name must:
- Start with a letter, and then it can contain any number of letters, numbers, or underscores
- Contain at least one lower case letter
All pre-existing configurations will continue to function normally. If you want to change a manipulation rule, however, you are required to change its name if it does not follow the new format.
The ACLI verify-config command warns you if the system has loaded a configuration containing illegal naming syntax.
Please note that the software allows you to make changes to HMRs, including configuring new functionality to existing rules, as long as you do not change the rule name. This results in an important consideration surrounding HMRs with hyphens in previously configured rule names.
- You can reference stored values in new value names. (Recall that stored values may be rule names.)
- You can perform subtraction in new value names.
If you use a rule names with hyphens within the REGEX of new value names, the system cannot determine whether the hyphen is part of the rule name or is intended to invoke subtraction within the REGEX. For this reason, you need to use great care with legacy HMR naming that includes hyphens.
As a general rule, create new rule names that follow the new rule naming guidelines if you intend to use new functionality in those rules.
New Value Restrictions
To simplify configuration and remove possible ambiguity, the use of boolean and equality operators (==, <=, <, etc.) for new-value parameter values has been banned. Since there was no specific functionality tied to their use, their ceasing to be use will have no impact to normal SIP manipulation operations.