Oracle SBC Advanced Config 2 - Header Manipulation Rules (HMR

Oracle SBC Advanced Config 2 - 2

Header Manipulation Rules (HMR) provide the Oracle Communications Session Border
Controller (SBC) with the ability to insert, delete, or modify any SIP header or parameter. You
can also use HMR to copy or move headers or parameter values, rename parameter names,
and delete MIME attachments.
Any of these functions can be performed based on the type of message (request versus
response), the type of request (Invite, Register, and others), or the success or failure of
regular expression matching of any other header or parameter in the same message.
The HMR function can be used in many ways, from modifying messages for interoperability
reasons, routing requests differently based on the matched values, to anonymization and
identity assertion.
HMR rules are a set of tools, whose usefulness depends a great deal on the user's
imagination and understanding of the SIP protocol and the capabilities of the Oracle
Communications Session Border Controller.

Using HMR, you can search a header for dynamic content or patterns with the header value.
For example, search for all user parts of a URI that begin with 617 and end with 5555 (such
as 617...5555), then modify 617 123 5555 to become 617 231 5555, 508 1230000, or any
combination of numbers you specify.

Each sip-manipulation object defines a set of header rules (HRs) and element rules (ERs) as
an inbound or outbound HMR ruleset. Only one sip-manipulation ruleset can be applied to a
session-agent, realm, or sip-interface inbound and outbound.
When you set the parameter to sip-manip, you then configure the new-value parameter with
the name of a SIP manipulation rule that you want to invoke. The values for the match-value,
comparison-type, and methods parameters for an invoked rule are all supported. This means
that the manipulation defined by the rules identified in the new-value parameter are carried
out when the values for the match-value, comparison-type, and methods parameters are true.

The SBC executes the HMR rules on one of the two "sides" of the SBC’s processing: inbound
and outbound, depending on an inbound manipulation rule or an outbound manipulation rule.
Even within that construct, you can apply HMRs inbound or outbound on a session agent, SIP
interface, or a realm config. The order of preference is session agent > realm config > SIP
interface. It is important to remember that a SIP manipulation rule (HMR) applied to a session
agent will override the one applied to the realm config or SIP interface. The HMR applied to a
realm config will override the one applied to the SIP interface.
Rulesets are performed in a stateless manner, meaning they do not know anything about
previous messages or about messages that were received by the SBC for the same
transaction or dialog.
Outbound HMR rulesets are applied just before the SBC sends out the SIP message, and
after the SBC processes SIP NAT. Any changes made by an outbound HMR rule will affect
the message, and will not be overridden by the SBC in any way.
Inbound HMR rulesets are applied before the SBC performs SIP NAT and most other
processes, and after the SBC parses SIP messages.

It is important to understand the order in which the SBC performs all the different functions
and what impact HMRs can have on routing decisions. You need to be aware that before
routing, there is a revision of the structure and validity of the ingress SIP messages. This
process is called parsing. It is after parsing that the SBC applies the inbound header
manipulation. Taking this into account, you can use those inbound HMRs to modify the
routing behavior, something that can be very beneficial by increasing the flexibility of the
routing options.

The syntax of header-rules is:
<name | action | match-value | msg-type | methods |element-rules | header-name |
comparison-type | new-value | batch| select | no | show | done | exit>
The header-name parameter in the header-rule element is the name of the header to which
this rule applies. This name must match a header name. Header manipulation rules operate
on the header you specify when you configure the rule.
A header manipulation rule can also be configured with a list of element rules, each of which
would specify the actions you want performed for a given element of this header. Header
element rules perform operations on the elements of a header. Header elements include all
subparts of a header, excluding the header name, that is, header value, header parameter,
URI parameter, and so on.
To manipulate the SDP body, set the header-name to content-type and the parameter-name
to application/SDP.

Here are more descriptions about action reject and log:
reject: If the rule successfully matches the conditions within the rule (match-value, msg-type,
and so on), it will increment a counter, and if it is a SIP Request, it will reject it; a response will
not be rejected (but the counter will still be incremented). The counter is visible as a new
"Rejected Messages" entry in the table shown by "show sipd status", and is available in a new
MIB object in the ap-smgmt.mib for SNMP get. An SNMP Trap has also been created,
which will be sent if the number of Rejected messages exceeds a configured threshold in a
configured time window (which are set by the new reject-message-threshold and reject-
message-window config attributes in session-router).
You can also specify what response-code and reason-phrase to use in rejecting the SIP
Request in the Rule you have the "reject" action in, by entering the "status-code[:reason-
phrase]" in the new-value field. For example, "403:You are naughty" in new-value of a reject
action rule will make the SBC reject the request with a 403 response and "You are naughty"
as the reason-phrase.
Note: If the message is a Request and thus gets rejected by a Rule, Rules later don't get
executed─the message is rejected immediately.

The match-value parameter in the header-rule element specifies the value to match against
the header value in SIP packets. The SBC matches these against the entire SIP header
value. This is where you can enter values to match using regular expression (Regex) values.
Entries can also contain Boolean operators.

The out-of-dialog value is to maintain proper dialog-matching through manipulation of dialog-
specific information using HMR. Two fundamental challenges arise when looking at the issue
of correctly parameters manipulating dialog-matching:
• Inbound HMR
• Outbound HMR
The out-of-dialog for the msg-type parameter addresses these challenges by offering an
intelligence more of dialog matching of messages for inbound and outbound HMR requests.
This is a msg-type parameter, meaning that it becomes matching criteria for operations
performed against a message. If you also specify methods (such as REGISTER) as matching
criteria, then the rule is further limited to the designated method.
For both inbound and outbound manipulations, using the out-of-dialog setting means the
message must be a request without a to-tag to perform the manipulation.

Because inbound manipulations take place before the message reaches the core of SBC SIP
processing, the SIP proxy takes the manipulated header as what was directly received from
the client. This can cause problems for requests leaving the SBC for the UAC because the
dialog will not match the initial request sent. So the unmodified header must be cached
because for any subsequent request (as in the case of a BYE originating from the terminator),
the SBC might need to restore the original value, enabling the UAC to identify the message
correctly as being part of the same dialog. For out-of-dialog requests (when the To, From, or
Call-ID headers are modified) the original header will be stored in the dialog when the msg-
type out-of-dialog is used.
The SBC performs the restoration of original headers outside of SIP manipulations. That is,
there are no manipulation rules to configure for restoring the header to its original context.
The SBC will recognize that the headers have been modified and restore them to their original
state before sending the message out on the wire. Restoration takes place before outbound
manipulations so that any outbound manipulation can modify those headers once they have
been restored.

When you use the out-of-dialog setting for an outbound manipulation, the SBC executes this
specific SIP header rule only if the same SIP header rule was executed against the initial
dialog-creating request.
For example, if the INVITE’s To header was not manipulated, it would not be correct to
manipulate the To header in the BYE request. To do so would render the UAC unable to
properly match the dialog. This also means that the outbound manipulation should be carried
out against a To, From, or Call-ID header in the BYE request if it was manipulated in the
INVITE.

comparison-type specifies the way you want SIP headers to be compared. This choice
dictates how the SBC processes the match rules against the SIP header.
The values refer-case-sensitive and refer-case-insensitive will make reference to the content
of the variable instead of taking the name of that variable in the match-value. For example, if
the match-value is $TRUNK_GROUP_CONTEXT, the SBC compares with the value of the
parameter trunk-context in the user part of the URI, instead of comparing with the string
“$TRUNK_GROUP_CONTEXT”.
refer-case-sensitive or refer-case-insensitive is incompatible with action set to store, because
if action is set to store, the SBC takes the match value as a Regex pattern and therefore it
does not work.

The new-value parameter in the header-rule element specifies the value of the header to
include in SIP packets; the SBC can use strings, variables, or a combination of both as shown
in the next slide.
Note that the header-name parameter will be the header to be created. If you want to modify
only part of a message header, use the new-value parameter in the element-rule element,
not in the header-rule element.

The value of the new-value parameter can also include:
• $LOCAL_FQDN: Predefined parameter specifying to use the LOCAL FQDN
• $REMOTE_FQDN: Predefined parameter specifying to use the REMOTE FQDN
• “string”: Use the absolute value in the quotation marks
• “string”+: Specifies that the absolute value in quotation marks be prepended to the
original value of the element
• +”string”: Specifies that the absolute value in quotation marks be appended to the
original value of the element
• $<Header-name>$<Element-rule>.$x (x=0 to 9): Pastes the result of a previous stored
value when action is set to store

When using these reserved words, you MUST use the $variable.$0 syntax. For example:
$PAI_USER.$0. If you do not use $0, you will get TRUE or FALSE, which is useful if, for
example, there is no username in the PAI header, or no PAI header at all.
The legacy predefined variables, such as some of those shown in the previous slide, continue
to work as they did, but you can ALSO use the .$0 syntax with them. If you are not using the
.$0 syntax with them, it still works for getting the string. The only ones that may not work are
$TRUNK_GROUP, $TRUNK_CONTEXT, and $MANIP_STRING. To make things consistent,
you can use these predefined reserved words with the .$0 syntax: $T_GROUP,
$T_CONTEXT, and M_STRING, for the same concept as $TRUNK_GROUP,
$TRUNK_CONTEXT, and $MANIP_STRING.
Here is a list of the predefined reserved words: $TO_USER, $TO_PHONE, $TO_HOST,
$TO_PORT, $FROM_USER, $FROM_PHONE, $FROM_HOST, $FROM_PORT,
$CONTACT_USER, $CONTACT_PHONE, $CONTACT_HOST, $CONTACT_PORT,
$RURI_USER, $RURI_PHONE, $RURI_HOST, $RURI_PORT, $PAI_USER, $PAI_PHONE,
$PAI_HOST, $PAI_PORT, $PPI_USER, $PPI_PHONE, $PPI_HOST, $PPI_PORT,
$PCPID_USER, $PCPID_PHONE, $PCPID_HOST, $PCPID_PORT, $CALL_ID,
$TIMESTAMP_UTC (gets the current time from the SBC’s system clock, in RFC 3339 format,
such as: 2008-01-01T22:00:09.123Z)

$MANIP_STRING is a system variable that can be used in the new-value of a sip-
manipulation, pulling the value from the sip-interface/realm/session-agent. This will be
configured in the parameter manipulation-string of any of those elements.
$MANIP_PATTERN can be used in a match-value of a pattern-rule comp-type, to use a
Regex pattern from the most-specific matching session-agent/realm/sip-interface. In those
three elements, a new config attribute called manipulation-pattern lets you enter a regular
expression, and thus have unique Regex patterns per session-agent/realm/sip-interface
without needing to create unique HMRs (sip-manipulations) for each of them. Only one Regex
pattern can be specified in the config attribute, and only the variable $MANIP_PATTERN can
appear in the match-value field. For example, you cannot combine the $MANIP_PATTERN
with additional characters in the match-value.
You can use this $MANIP_PATTERN in any rule where you can use a pattern-rule match-
value, including store action rules. You can also reference the stored values from that in later
rules in the usual way. For example, using the $RuleName for the Boolean TRUE/FALSE, or
$RuleName.$0 for the whole matching string, and so on.

Enter a list of SIP methods to which this header rule applies. An empty value applies this
header rule to all SIP method messages, excluding keywords add and delete. When a list is
already configured, it replaces the entire list.

element-rules are subelements of the header-rule. They define specific components and parts
of the header on which you want to perform an action. It is highly recommended that ERs be
used as much as possible, especially with Regex HMR.

The ER name field along with the parameter-name field are now distinct in that one can
perform multiple actions or rules for the same parameter-name multiple times. For example,
one could store a parameter value and delete the same parameter later. Also, the ER name
can be used in subsequent HRs and ERs, if the ER was stored.

The ER parameter-name along with the ER name parameter are now distinct so that one can
perform multiple actions/rules for the same parameter-name multiple times.

Examples of the uri-user-only usage are tgrp, trunk-context, rn (Route Number), or cic
(Customer Id Code).

The maddr parameter indicates the server address to be contacted for this user, overriding
any address derived from the host field. When an maddr parameter is present, the port and
transport components of the URI apply to the address indicated in the maddr parameter
value. The maddr field has been used as a simple form of loose source routing. It allows a
URI to specify a proxy that must be traversed en route to the destination. Continuing to use
the maddr parameter this way is strongly discouraged.

As defined by the ABNF for uri-parameter in section 25.1 of RFC 3261

The action parameter in the element-rule determines what the ER will do:
• An action of none means the ER will not be performed. This is useful for temporarily
disabling an ER, or reserving a spot for an ER in the chain of ERs for an HR.
• An action of store means the ER will store values that are matched by the match-value
configuration element. The values stored are available for use in later HRs or ERs of
later HRs.
• An action of replace means the ER will replace the value of the element to which it is
applied. For example, if the addTgidParam’s action were replace instead of add, it
would replace an existing tgid parameter value with the new-value. The name of the
parameter would not change in this case, unless the ER type were uri-param-name. In
that case, the name of the parameter would be replaced by the new-value, instead of
replacing the value of the parameter.
An action of add adds the ER type, unless a parameter of the same name already exists.
The name of the new parameter will be the ER parameter-name, and the value of the new
parameter will be the new-value configuration element.

The rule checks whether the header specified in the header-name field exists, and if found,
performs a delete action. This HMR example doesn’t require element-rules.

There can be more complex HMRs that perform some replace actions on SIP
answer/response messages to an OPTIONS method. The one shown in the slide is one of the
examples.

This ruleset adds the tgrp and trunk-context parameters with their values to the Contact
header of an egress INVITE. The values of the parameters are extrapolated by the predefined
values $TRUNK_GROUP and $TRUNK_GROUP_CONTEXT. This allows the core to perform
billing by looking at these two parameters.

The example demonstrates applying the configured ruleset to the out-manipulationid
parameter of a sip-interface.
SIP manipulations may be applied to incoming (before realm bridging has occurred) or
outgoing (after realm bridging has occurred) messages.
• When you apply SIP manipulation rulesets to a SIP interface incoming direction, you
may affect how the SIP messages will be translated and routed.
• When you apply SIP manipulation rulesets to a SIP interface outgoing direction, the
manipulation is done after realm bridging has occurred. Generally, this means that the
manipulation is not intended to affect next hop decisions. Rather it is used to alter SIP
header elements to hide topology.
SIP manipulations may be used for more advanced functions, such as inserting administrator-
defined cookies, stripping proprietary fields, and others.

The SBC Configuration Guide along with the ACLI Reference is an excellent source for
defining the fields in the rulesets. In addition, you should also review the release notes to
ensure you are up-to-date with all the HMR and Regex features available in your release.

A string grouping is a component of a regular expression inside of parentheses. For example,
the Regex ^([^;]+);(.+)$ has two groupings: the first is [^;]+ and the second is .+.
Although HMR rulesets are stateless, in the sense that they do not store values across
messages or remember what they did in previous messages, they can store strings for use
within the same sip-manipulation ruleset. In other words, some HRs and ERs can store values
that later HRs or ERs can use.
After the set of HRs and ERs in a sip-manipulation are performed and the sip-manipulation is
complete for the message, the stored values are forgotten.

The comparison-type for Regex match-value is pattern-rule, although technically, because
the action is store, the comparison-type is assumed to be pattern-rule. If the match-value
references a Boolean (true or false), then the comparison-type value would be Boolean. If it
were a different action type, and one wanted simply a string to match against, you could use
case-sensitive or not case-sensitive comparison-types.
The integer operator will first perform a string to integer conversion of each side because it
does not make sense to perform string comparisons of those operator types. If the string to
integer conversion fails, the value will be treated as 0. So if "$foo" is used in "$foo <= $bar"
and $foo resolves to something stored that cannot be converted to an integer, then it is
treated as the number 0. Usually, you would use these integer operators when you have
stored either phone numbers or port numbers and want to test them against a fixed number.
All of the above operators can be used in conjunction with the "!", "&“, and "|“, can be grouped
in parenthesis, and so on. They all return TRUE/FALSE as Booleans would. You can use
them with $variables or even just strings. For example, "$getPhone.$0 <= 10000" would
resolve to TRUE if the stored value of some rule name "getPhone" were an integer less than
10000, while "$getPhone.$0 == 10000" would be TRUE if the stored value of a rule name
getPhone were the string 10000 (which means the same thing as the integer 10000).

When HRs or ERs Regex matches are performed, the Boolean result is TRUE if the Regex
pattern match-value succeeded in matching, or FALSE if it did not. This Boolean result can be
used later in other HR or ER match-values to decide whether to perform another action or not.
For example, if an ER stored a uri-parameter with a Regex of .+, and the uri-parameter did not
exist, the Boolean result for that ER is FALSE, and a later HR or ER can check that before
performing an action. Boolean values of HRs and ERs are references in a similar manner to
their stored Regex matched strings, except without the last ".$group_number" part. Therefore
the following are the correct formats for referencing the Boolean value of a previous HR/ER
Regex match:
$header_rule_name, $header_rule_name.$element_rule_name
$header_rule_name[number],
$header_rule_name[number].$element_rule_name
$header_rule_name[~], $header_rule_name[~].$element_rule_name
$header_rule_name[^], $header_rule_name[^].$element_rule_name
$header_rule_name[*], $header_rule_name[*].$element_rule_name

Here is an example of the entire Regex pattern matching the input string:
• If the Regex pattern ^([^;]+);(.+)$ were the match-value of an HR named rgxTest:
- The entire Regex matching string trunk-123;core would be referenced in the
new-value of another HR or ER using $rgxTest.$0
- The first group within the Regex trunk-123 would be referenced by
$rgxTest.$1
- The second group core would be referenced by $rgxTest.$2
• If the Regex pattern were instead the match-value of an ER named rgxVal in the HR
rgxTest:
- The whole matched string trunk-123;core would be referenced by
$rgxTest.$rgxVal.$0
- The first group trunk-123 would be referenced by $rgxTest.$rgxVal.$1
- The second group core would be referenced by $rgxTest.$rgxVal.$2
If the entire Regex pattern does not match the input string, then nothing is stored, even if a
subgroup did match. For example, if the input string for the above Regex were only trunk-
123, or trunk-123;, then nothing would be stored because the Regex pattern did not match,
even though the first subgroup would have matched.

In some cases, it is possible that there are multiple SIP headers in the message of the same
name, for example, Route or Via headers. Thus, an HR for that header-name would be
performed multiple times.
If the $HR_name.$ER_name.$number syntax is used for referencing a stored value for such
a case, the value referenced would be that of the first such header in the message. To
reference a particular header, use the relevant syntax shown in the slide.

The SBC supports an ACLI command that can test the regular expression that might be used
in SIP manipulation rules to see if it yields the desired results. This command is useful for
testing the Regex values that you devise because it will tell you whether that value is valid or
not.

This HMR replaces the uri-display parameter value of the P-Asserted-Identity header with the
value of the uri-display parameter of the contact header.
The value of the contact uri-display is stored first. Notice the blank match-value in the
element-rule getNm. Blank in this case is equivalent to .+, meaning match at least one
character and as many times as possible. Whatever you store in the CONTACT HR/ER pair
gets referenced in the P-Asserted-Identity HR/ER pair by setting the value of the match-value
parameter to $getCnt.$getNm.
This reference is set to Boolean by the comparison-type parameter. If the match is TRUE (as
long as you match at least one character in the contact uri-display field, the result is true),
then the new value of the PAI uri-display is replaced by the entire value of the contact uri-
display ($getCnt.$getNm.$0).

In this example, the HMR performs an action for a Boolean result of FALSE.
In the FROMvalue element rule, match-value is ^\+39(046[7-9], meaning that the only
matching calls are from +390467, +390468, or +390469. The numbers that do not match
(!$matchFrom.$FROMvalue) will be blacklisted by adding a Route header pointing to
nowhere, that is, 0.0.0.0.

Using the SIP HMR, you can manipulate MIME types in SIP message bodies. Although you
can manipulate the body of specific content type using other iterations of SIP HMR, this
version gives you the power to change the MIME attachment of a specific type within the body
by using regular expressions. To achieve this, you use the find-replace-all action type,
which enables the search for a particular string and the replacement of all matches for that
type. To manipulate a particular portion of the MIME attachment—as in removing a certain
attribute within the content type of application/SDP—the SBC would need to search the
content multiple times because SDP can have more than one media line, and the SIP
message body can contain more than one application/SDP.
The find-replace-all action type works for SIP header rules and element rules. You can
use it for all manipulation types from the entire header value, to the URI specific parameters,
and MIME attachment. SIP HMR’s support for escape characters allows searches for values
you would be unable to enter yourself. Because they are necessary to MIME manipulation,
support for escape characters now includes: \f, \n, \r, \t, \v.
A new MIME body cannot be added, but it can be deleted and changed.
The HMR MIME feature supports the \R special character, which matches an \r, an \n, or the
combination of \r\n.

The SIP HMR feature supports manipulation of MIME types in SIP message bodies. To
change the MIME attachment of a specific type within the body by using regular expressions,
you use the find-replace-all action type, which enables the search for a particular string and
the replacement of all matches for that type. Although you use find-replace-all to manipulate
MIME attachments, it can also be used to achieve other goals in SIP HMR.
Note that using find-replace-all might consume more system resources than other HMR types.
Therefore this powerful action type should only be used when another type cannot perform
the type of manipulation you require.
To manipulate a particular portion of the MIME attachment, for example when removing a
certain attribute within the content type of application/sdp, the SBC would need to search the
content multiple times because a) SDP can have more than one media line and b) the SIP
message body can contain more than one application/sdp.
The find-replace-all action type works for SIP header rules and for element rules. You can use
it for all manipulation types from the entire header value, to the URI specific parameters, and
MIME attachment.

In this example, the rule is to store the m= line associated to t38, and all the a= lines that are
associated with it. There are two options here:
• With match-value set to m=image 0 udptl t38.*, only the m= line will be matched,
as the . character in Regex does not include CR or LF.
• With match-value set to m=image 0 udptl t38\,*, all lines included in the sdp-
media-rule will be stored.
mime-sdp-rule
name StoremlineWithAllalinesAssociated
msg-type any
methods
action manipulate
comparison-type case-sensitive
match-value
new-value
sdp-media-rule
name storet38
media-type media[0]
action store
comparison-type pattern-rule

match-value m=image 0 udptl t38.* \,*
new-value

These configuration elements allow a lot more flexibility in the way you can work with
manipulations inside the SDP body of a message. They allow you to identify, group, and
perform changes to individual lines, group of lines, or all the attributes related to a particular
type of media, voice, video, fax, and so on.

A hidden header is a header whose name begins with @. Because @ is not a valid character
in a header name, as defined by RFC 3261, these headers do not pass the SIP parser checks
on egress and are therefore not sent out to the next-hop, therefore removing the need for
cleaning up SIP manipulations. In addition, there is no possibility of a collision between a
header name defined in the future and a hidden header name beginning with @.

The SBC can perform specific actions other than just delete an XML Body contained inside a
SIP Method. It can NAT to avoid topology leaking, modify the content, or even reject and log if
it finds specific content on it.
The SBC performs the NAT to the <deviceID> XML tag only if it is configured to perform
registration caching.
When the SBC receives a SIP message from the core side and the request has:
• A Content-Type of application/csta+xml
• A Content-Length greater than 0
It parses the message’s message body into an XML document. Should parsing fail, the SBC
will forward the SIP INFO request without modification to the XML message body. Otherwise,
the SBC searches for the <deviceID> subelement within the XML document. If it finds the
<deviceID> subelement, the SBC searches through its registration cache for a registered
Contact that matches the value of the <deviceID>. If it finds a match, the SBC replaces the
value of the <deviceID> with that of the corresponding registered Contact. If the value of the
<deviceID> is a Contact that the SBC generates for a registered UA, the corresponding
contact from the lookup would be the Contact of the registered UA. After these functions have
been performed, the SBC reformats the SIP INFO request with the modified XML message

body before sending it to the next hop. If there is no match found, the SBC forwards
the SIP INFO request without modifying the XML message body.

The SBC’s HMR functionality can operate on ISDN user party (ISUP) binary bodies. Using the
same logic and mechanisms that are applied to SIP header elements, HMR for SIP-ISUP
manipulates ISUP parameter fields and ISUP message parts. You can create MIME rules that
function in much the same way the SIP header rules do. Although SIP header rules can
change the specific headers of a SIP message, MIME rules can manipulate targeted body
parts of a SIP message.
MIME ISUP manipulation supports performing HMR operations on SIP ISUP binary bodies
and is configured in the mime-isup-rule configuration. This configuration works the same way
that the MIME rule configuration does and contains the same parameters for you to set, but it
also includes additional parameters and a subconfiguration targeted specifically for ISUP
application.

isup-msg-type: Refers to specific ISUP message types, such as Initial Address Message
(IAM) and Address Complete Message (ACM), that the SBC uses with the msg-type
parameter (which identifies the SIP message) in the matching process. You enter values in
this parameter as a list of numbers rather than as an enumerated value because of the large
number of ISUP message types, with a range between 0 and 255.
isup-spec: Specifies how the SBC is to parse the binary body; valid values are the
enumerated type. The values for this parameter are these SIP ISUP formats:
• ANSI-2000—Corresponding to ANSI T1.113-2000
• ITU-99—Corresponding to ITU Q.763
• Because ISUP messages do not identify their format, you must designate which you
want to use.

Here are the descriptions of the ISUP-related parameters:
• isup-parameter-rules (sub-configuration): If you are familiar with HMR, think of
this parameter as being similar to the element-rule for a SIP header-rule. You use it to
create, manipulate, and store different parameters in the body of the ISUP message.
Two parameters for this rule are unique: parameter-rule and parameter-format.
• parameter-type: Using ISUP parameter mapping, this setting identifies on which of
the ISUP parameters you want to perform manipulation. This parameter takes values
between 0 and 255, and you must know the correct ISUP mapping value for your entry.
The SBC calculates the offset and location of this parameter in the body.
Note that the value returned from the body does not indicate the type or length, only the
parameter value. For example, a parameter-type value of 4 acts on the Called Party Number
parameter value. In accordance with the ISUP specifications, only certain message types are
allowed to have optional parameters. If optional parameters are present, an offset field must
exist for them, so its value is 0 even if there are no optional parameters in the SIP message.
For example, if you define a SIP ISUP rule that applies to all message types and adds a
parameter that is neither fixed nor variable, the SBC adds it as an optional parameter
regardless of whether that message type should not support optional parameters.

You can configure a SIP header manipulation to add an ISUP body to a SIP message, and
the SBC will add them after any SDP parts if they are present. You can add an ISUP body to
a SIP message in two ways:
• Create a mime-isup-rule with the action type set to add and enter the entire body in
string hexadecimal form in the new-value parameter.
• Or, leave the new-value parameter empty at the mime-isup-rule level and create an add
rule for an isup-param-rule.

number-param, as the decimal value of the specified number type, treats the parameters as
a generic number parameter type. For example, a parameter-type 4 acts on the Called Party
Number parameter.
When the action type is replace or add, the SBC automatically sets the parameter’s odd-even
bit based on the number being inserted in relation to the new-value setting. If the Numbering
Plan Indicator bits are 0b001 (ISDN, E.164), then the SBC sets the Nature of Address field to
0b0000100 (international). If this number type is added to a non-existent parameter field, then
the Numbering Plan Indicator field is 0b0000011 (national number). If this number type is
added to a nonexistent parameters field, then the Numbering Plan Indicator field will be set to
0b001 (ISDN,E.164) and the SBC will also follow the previous rules.
Regardless of the action type you set, the string represented for match-value use for this type
will be the numbers of the address fields after the BCD coding. There will be a leading plus
sign (+) if the Number Plan is 0b001 and the Nature of Address is 0b0000100 (international);
otherwise, there will not be a plus sign (+).
If it cannot convert the data field to a number parameter, the SBC will return an empty string.
And if the new-value is not a number or cannot fit in the specified parameter type field, the
SBC takes no action.

In ISUP, BCD (Binary Coded Decimal) refers to the binary format of the number used as a
half a byte nibble, with the byte’s lower nibble containing the first digit and the higher nibble
containing the second digit. For example, the number 127 is encoded as the two binary bytes
0x2107 on the wire.
Using this mode, the Net-Net SBC treats the binary ISUP content as BCD; it should decode it
from 0x2107 to the string 1270, and from a string of 127, it should decode it as 0x2107.
Because a byte has two nibbles, a nibble might have to be added. And when the Net-Net
SBC performs decoding, it cannot know that a BCD byte represents one or two ASCII digits—
so it assumes there are two. The number-param setting decodes the parameter as a common
number parameter. The Net-Net SD sees the odd/even bit as in the first bite as telling it how
many nibbles to decode correctly, and it will set the odd-even when it decodes.
Non-binary digit characters fail to match against the body part if they are contained in the
match value, and non-binary characters in the new value result in no operation being
performed.


Oracle SBC Advanced Config 2 - Header Manipulation Rules (HMR

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle SBC Advanced Config 2 - Header Manipulation Rules (HMR

Uploaded by

Copyright:

Available Formats

Oracle SBC Advanced Config 2 - 2

Oracle SBC Advanced Config 2 - 3

Oracle SBC Advanced Config 2 - 5

Oracle SBC Advanced Config 2 - 8

Oracle SBC Advanced Config 2 - 9

Oracle SBC Advanced Config 2 - 10

Oracle SBC Advanced Config 2 - 12

Oracle SBC Advanced Config 2 - 16

Oracle SBC Advanced Config 2 - 18

Oracle SBC Advanced Config 2 - 20

Oracle SBC Advanced Config 2 - 21

Oracle SBC Advanced Config 2 - 22

Oracle SBC Advanced Config 2 - 23

Oracle SBC Advanced Config 2 - 24

Oracle SBC Advanced Config 2 - 25

Oracle SBC Advanced Config 2 - 26

Oracle SBC Advanced Config 2 - 27

Oracle SBC Advanced Config 2 - 28

Oracle SBC Advanced Config 2 - 30

Oracle SBC Advanced Config 2 - 31

Oracle SBC Advanced Config 2 - 32

Oracle SBC Advanced Config 2 - 33

Oracle SBC Advanced Config 2 - 34

Oracle SBC Advanced Config 2 - 37

Oracle SBC Advanced Config 2 - 42

Oracle SBC Advanced Config 2 - 45

Oracle SBC Advanced Config 2 - 46

Oracle SBC Advanced Config 2 - 48

Oracle SBC Advanced Config 2 - 49

Oracle SBC Advanced Config 2 - 50

Oracle SBC Advanced Config 2 - 55

Oracle SBC Advanced Config 2 - 57

Oracle SBC Advanced Config 2 - 58

Oracle SBC Advanced Config 2 - 60

Oracle SBC Advanced Config 2 - 61

Oracle SBC Advanced Config 2 - 62

Oracle SBC Advanced Config 2 - 63

Oracle SBC Advanced Config 2 - 66

Oracle SBC Advanced Config 2 - 67

Oracle SBC Advanced Config 2 - 68

Oracle SBC Advanced Config 2 - 69

Oracle SBC Advanced Config 2 - 71

Oracle SBC Advanced Config 2 - 71

Oracle SBC Advanced Config 2 - 72

Oracle SBC Advanced Config 2 - 75

Oracle SBC Advanced Config 2 - 77

Oracle SBC Advanced Config 2 - 77

Oracle SBC Advanced Config 2 - 79

Oracle SBC Advanced Config 2 - 80

Oracle SBC Advanced Config 2 - 81

Oracle SBC Advanced Config 2 - 83

Oracle SBC Advanced Config 2 - 84

Oracle SBC Advanced Config 2 - 85

You might also like