Recently I was working with a SIP Trunk provider (who shall remain nameless) who was doing something rather annoying. Any INVITEs that were being received from downstream for inbound calls were using the service’s pilot number in the Request URI (RURI) header field. The phone number of the party the external caller was actually trying to reach was found further down in the To field:
In the example above, the inbound call was to 0386097221. However, the number in the RURI field is 0386097220. In fact, any INVITEs received from the service provider to any direct in dial number would always have the pilot number in the RURI field. Unless you plan for all inbound calls to route to the same destination, such as an Auto Attendant or Response Group, this is going to cause you problems.
Introduction to SIP Message Manipulation
The above scenario outlines one of the advantages of having a Session Border Controller (SBC) deployed in your Lync environment. If we were terminating the SIP Trunk directly on a Mediation server, we would be limited in what approaches we can take to get around this problem.
With an SBC in place, we can use SIP Message Manipulations to re-write the RURI header field, which will make the issue transparent to Lync. Any Lync certified SBC should be able to do this for you, here I’ll will be outlining the process on a Sonus SBC 1000.
For a more thorough and detailed outline of SIP Message Manipulation on a Sonus SBC series appliance, check out the full SBC documentation (Page 1066 onwards). This article deals specifically with how to get the phone number from the TO field into the RURI field.
- From the main settings tab, open SIP > Message Manipulation > Message Rule Tables:
- Click the green plus sign to create a new table. Enter in a description, and click Ok:
- Click on the newly created Message Rule Table. From the Create Rule drop down menu, select Request Line Rule:
Aside – Manipulation Rule Types
Depending on what part of the SIP message you want to manipulate, you have four manipulation rules to choose from:
Below, I’ve highlighted which part of the SIP message is being worked with depending on which rule type you select:
- Enter in a description, and click the arrow to the left of Request Line Value and URI to expand out the rest of the rule options:
- For URI User Info, Select Modify, and click on Add/Edit:
- For Type of Value, select Token, and enter in a Value of to.uri.userinfo.user, and click Ok:
- At the bottom of the SIP Request Line Rule, make sure you click Ok:
Aside – Tokens
Tokens are pre-assigned variable names that have been given to different portions of a SIP message. Similar to how the numbers in an incoming SIP message are mapped to a Transformation Table (Called Number, Calling Number, etc), various portions of a SIP packet are mapped to SIP Manipulation Table (SMM) Tokens.
Example token mappings are shown below, with x representing a SIP Request Status Line, in our case, the To field:
Once you have created the manipulation rule, use the built in test function to ensure the configuration is correct:
- Click on the Message Rule Table, and select Test Message from the top menu:
- Copy in the SIP header, and click ok. In the result pane that appears below, it will show the original header at the top, scroll down to see the updated header. There, you will see the RURI header field now has the correct phone number:
Apply to Signalling Group
Now that the Message Manipulation Rule has been created and tested, it needs to be applied to the SIP Trunk provider’s Signalling Group:
- From the settings menu, click on Signalling Groups and select the signalling group for your SIP Trunk provider:
- Near the bottom of the configuration options, Enable Message Manipulation, and select the Message Table created earlier for Inbound Message Manipulation, and click Apply:
- You’re done
This article only covers one scenario where an SBC can be useful when dealing with irregular SIP messages from a SIP trunk provider. Using the same logic, pretty much anything can be manipulated to ensure Lync plays well with all providers.
I wouldve thought it would be best to apply that only to Invites. This would theoretically lower the overhead on the SBC when processing SIP messages.
Is there a reason you didn’t do that?
Not that I recall, but this was 5 years ago… I honestly can’t remember.