This document outlines the SIP Message Manipulation feature.
Assumes the user is familiar with configuring the SBCx000's WebUI
Requires Sonus SBC1000/2000 Version 2.2 or later
Because you can never tell just what the other side of a SIP connection might send or need, the SBC1000/2000 version 2.2 includes a feature to manipulate any SIP header.
The SMM feature is enabled on a Signaling Group. That means you can configure a SMM to change an incoming or outgoing SIP Message. It is important to note that SMM feature is separate from the SBC's SIP engine. SMM changes SIP Message either before they are processed, or after they are processed, by the SIP engine. In essence, SMM is not state aware.
For instance, if you were to change a FROM Tag on a 180 Ringing Message, the SIP engine would discard that 180 Ringing because it had a differernt Tag than all the previous SIP Messages. To the SIP engine, it would appear as if that 180 Ringing belonged to a different dialogue.
So, SMM changes must be made carefully to ensure that the SIP engine can still recognize that the messages are part of an ongoing dialogue.
In order to properly employ the SMM function, you need to understand the SIP protocol and packet syntax. With SMM its possible to change any portion of the SIP packet, so you best understand what's being changed!
Below is a brief SIP referesher, including:
SIP Requests are different than SIP Responses. In order to employ the SIP Manipulation function, you must know the difference between a Request and Response.
SIP Requests |
| SIP Responses (partial list) |
---|---|---|
INVITE |
| 100 Trying |
ACK |
| 180 Ringing |
BYE |
| 183 Session Progressing |
CANCEL |
| 200 OK |
OPTIONS |
| 202 Accepted |
REGISTER |
| 302 Moved Temporarily |
PRACK |
| 400 Bad Request |
SUBSCRIBE |
| 401 Unauthorized |
NOTIFY |
| 403 Forbidden |
PUBLISH |
| 500 Server Internal Error |
INFO |
| 503 Service Unavailable |
REFER |
| 504 Server Timeout |
MESSAGE |
| 603 Decline |
UPDATE |
| 606 Message Too Large |
Knowing the separate parts of the SIP packet will help you use the correct section of the SMM Web UI. Request Line, Status Line, Headers, Header Parameters, URI and URI parameters are all portions of a SIP packet.
Now that we're familiar with the anatomy of a SIP packet, let's examine the SMM Rules.
This diagram shows each type of SMM Rule and what portion of the SIP packet that type of rule affects.
After selecting the appropriate Rule type, the Rule itself must be configured. Using the diagrams below, you can see which section of each rule corresponds with portions of a SIP message. Once you've identified what needs to be changed, consult the diagrams below to determine which configuration entry to employ to create the desired change.
Normally used to change the SDP, the Raw Rule will change any regex match found within the entire SIP packet. If a Raw Rule was created to match on sip: and change it to sips:, then every sip: that appears in a packet would be changed to sips: using a single Raw Rule.
Tokens are basically variable names which have been pre-assigned to different portions of a SIP Message. Just like the numbers in an incoming SIP packet are mapped into Tranformation Table IEs (Called Number, Calling Number, etc.), various portions of a SIP Packet are mapped into SMM Tokens.
Tokens make it easier for you to know what's being changed. For instance, if you're making a SMM Rule to change the diversion number to be the same as the the calling number, you would use the SMM Rules menu to change the diversion value from the token from.user.userinfo.user (as that is the token that contains the calling number).
Below find a sample mapping of SIP messages sections to their corresponding tokens; x represents a SIP Request Line, Status Line or Header name. For example:
The TO number would be recorded in the to.uri.userinfo.usertoken.
Some of the available tokens are listed below.
Request URI Header Tokens | Value |
---|---|
request-line | sip:+15103644064@ux.vx.net;user=phone SIP/2.0 |
request-line.uri | sip:+15103644064@ux.vx.net |
request-line.uri.host | ux.vx.net |
request-line.uri.port | 5061 |
request-line.uri.userinfo.user | +15103644064 |
request-line.sipversion | 2.0 |
TO/FROM/P-headers Tokens | Value |
---|---|
from | "Jane Doe"<sip:+14083483531:passwrd;usr=param:test@sba1.vx.net:5061;user=phone>;epid=03FE79405B;tag=d953c6165d |
from.displayname | "Jane Doe" |
from.param.tag | d953c6165d |
from.uri | sip:+14083483531@sba1.vx.net;user=phone |
from.uri.host | sba1.vx.net |
from.user.port | 5061 |
from.user.userinfo.password | passwrd |
from.user.userinfo.param.ext | 7565 |
from.user.userinfo.param.phone-context | cda.udp |
from.user.userinfo.user | +14083483531 |
When you want an SMM to operate only if something specific occurs, then you create a Condition Rule. Condition Rules, which are applied with the Message Rule, can be configured to match specific numbers, tokens, or by regex.
The SMM feature cannot be used to create a SIP packet. As indicated above, the SMM feature handles a SIP packet either just before or just after the SIP Engine. In either case, an already-existing SIP packet is presented to the SMM function. The SMM function only works on packet it receives--it cannot create a packet.