• Define all storage rules first. Each subsequent header rule processes against the same SIP message, so each additional header rules works off of the results from the application of the rule that precedes it.

  In general, you want to store values from the original SIP header rather than from the iteratively changed versions.

• Implement rules at the element rule rather than the header rule level. Header rules should only be a container for element rules.
• Add additional element rules to modify a single header. Do not create multiple header rules, each with one element rule. Instead, create multiple element rules within a header rule.
• Think of performance. Reuse as many built in variables as possible
• Avoid lengthy string matches unless absolutely necessary
• Wherever possible, constrain your HMR appropriately by specifying a SIP method and message type
• Build an HMR library

You need to determine if you want changes to occur on traffic that is relative to the OCSBC inbound or outbound.

As you decide direction, you must also consider the order in which the OCSBC applies HMR for session agents, realms, and SIP interfaces. The order of precedence is:

• session agent
• realm
• SIP interface

A SIP manipulation applied to a session agent overrides the other two, and a SIP manipulation for a realm overrides one for a SIP interface.

The OCSBC applies SIP header rules in the order you have entered them, which guards against the removal of data that might be used by other header rules. The order starts with the top-most rule and continues with the execution of the sub-rules one by one. Each new rule is carried out on the result of the preceding rule.

This ordering also lets you strategically use manipulations. For example, you can use two rules if you want to store the values of a regular expression. The first rule stores the value of a matched regular expression and the second deletes the matched value.

You can operate on a specific instance of a given header by adding a trailing [<index>] value after the header name. This [<index>] is a numerical value representing the specific instance of the header on which to operate. However, the OCSBC takes no action if the header does not exist. You can also use the caret ^ to reference the last header of that type if there are multiple instances.

The count for referencing is zero-based, meaning that the first instance of the header counts as 0.

Although the OCSBC has a set method for how certain manipulation rules take precedence over others; you can use multiple SIP HMR sets to

• Apply multiple inbound and outbound manipulations rules to a SIP message
• Provision the order in which the OCSBC applies HMRs

You cause the header rule in one HMR to invoke another HMR. Values from that invoked HMR for the match value, comparison type, and methods are then supported. The invoked HMR is performed when those values are true.

You can use a tool that allows you to test the outcome of your SIP manipulation and header rules without sending real traffic through the OCSBC to see if they work.

To use the tool, you enter the ACLI's test-sip-manipulation utility and reference the rule you want to test using its name. Then you enter a mode where you put in a SIP message entered in ASCII. You can cut and paste this message from sipmsg.log or from some other location. Using <Ctrl-D> stops the SIP message collection and parses it.

The test informs you of any parsing errors found in the SIP message. Once the message is entered, you can execute the SIP manipulation against the message. The output after this step is the modified SIP message after manipulations have been applied. You will also find a debugging option, which displays SIP manipulation logging to the screen as the manipulation takes place.

As a starting point for testing, this tool comes loaded with a default SIP message. It cannot be associated with realms, session agents, or SIP interfaces, and so it also comes with certain resolves reserved words, such as: $LOCAL_IP, $TRUNK_GROUP_CONTEXT, and $REMOTE_PORT. In addition, you can use your settings for testing across terminal sessions; if you choose to save your settings, everything (including the SIP message) will be saved, with the exception of the debugging option.

It is not recommended that you use this tool to add an ISUP message body.

• Header rule getToURI for To header is not needed. The built-in variable $RURI_USER can be used.
• Header rule getFromURIDigits for From header. Stores specific digits for the uri-user-only part of the From header.
• Header rule constructRURIUsingToAndFrom to build the Request-URI. Replaces the uri-user of the Request-URI with a concatenation of the stored digits.

(configure)# session-router test-pattern-rule
(test-pattern-rule)# string +14167601262
expression made 0 matches against string
(test-pattern-rule)# expression ^\+1([0-9]{7}).*$
expression made 2 matches again string
(test-pattern-rule)# show
Pattern Rule:
Expression	: ^\+1([0-9]{7}).*$
String	: +14167601262
Matched	: TRUE
Matches:
$0 +14167601262
$1 4167601

sip-manipulation
name                        ContructURI
description	
header-rule
    name                    getFromURIDigits
    header-name             From
    action                  store
    comparison-type         case-sensitive
    match-value
    msg-type                request
    new-value
    methods                 INVITE
    element-rule
        name                getDigit
        parameter-name 
        type                uri-user
        action              store
        match-val-type      any
        comparison-type     pattern-rule
        match-value         ^\+1([0-9]{7}).*$
        new-value
header-rule
    name                    constructRURIUsingToAndFrom
    header-name             request-uri
    action                  manipulate
    comparison-type         case-insensitive
    match-value
    msg-type                request
    new-value
    methods                 INVITE
    element-rule
        name                constructRURI 
        parameter-name 
        type                uri-user 
        action              replace 
        match-val-type      any 
        comparison-type     pattern-rule 
        match-value 
        new-value           $RURI_USER.$0+$getFromURIDigits.$getDigits.$1 

(test-sip-manipulation)# load-sip-message

You might want to edit the Content-Length value default value of 276 or to remove the header. Retaining that value causes test-sip-manipulation to transmit only the first 276 characters of the loaded SIP message.

Test Sip Manipulation:
    sip-manipulation	       : ConstructRURI
    debugging	              : enabled
    direction	              : out
    manipulation-string	    :
    manipulation-pattern	   : \,+
    tgrp-context	           :
    local-ip	               : 192.168.1.60:5060
    remote-ip	              : 192.168.1.61:5060
    sip-message	            : parsed OK

(test-sip-manipulation)# execute
Header Rule ConstructRURI (headerName=request-uri action=manipulate cmpType=pattern-rule) does not apply to method INVITE
After Manipulation[ConstructRURI]

The following output snippet shows that the HMR worked:

INVITE sip:2114167601@192.168.65.16:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.1.119.152:5060;branch=x9hG4bKj3svpd1030b08nc9t3f1.1
From: JOHN SMITH<sip:+14167601262@sipt.tech.ca;user=phone;tag=SDekcfd01-966714349-1273696750280-
To: <sip:211;csel=noind@10.1.119.151:5060;user=phone

Run log.sipd at debug level on the OCSBC where you plan to test the HMR to gain the most information. Then examine log.sipd to review information about the HMR execution.