While working on a project, I ran into an issue with SimRing and Call Forwarding. If a user set their Lync account to either SimRing or Call Forward to their mobile and another internal user called them via Lync, the call would forward just fine but if an external party called, the call would ring the Lync end-point (if set to SimRing) or just go straight to voice mail (Call forward).

Here is an example of the scenario:

After reviewing the logs, I couldn’t see anything wrong so I started watching the syslog on the AudioCodes gateway. As I was watching, I could see the History-Info header being sent so I figured it should be good to go. I talked to our CenturyLink support and found out that they will only allow a call to go through if they recognize it to be from one of their phone numbers. They also told me they won’t look at the History-Info header either. They only look at the Diversion header.

A couple of things to note, a great document on Lync 2013 Headers and SIP trunks is here: http://www.microsoft.com/en-us/download/details.aspx?id=38820 and Lync doesn’t send a diversion header natively.

Thankfully, we were using an AudioCodes device as our gateway so I figured I could do a manipulation there to solve this issue.

First, I started by reading the documentation (actually, that’s a lie, I started by using Google and contacting a bunch of people smarter than me, but when that came up short, I RTFM). In the documentation for the gateway, I found the section on “Interworking SIP Diversion and History-Info Headers. In the description, they had:

“This device can be configured to interwork between the SIP Diversion and History-Info headers. This is important, for example, to networks that support the Diversion header but not the History-Info header, or vice versa.”

Awesome! This is exactly the situation I’m in so I continue reading.  They have the following table:

As you can see, I should be able to set the DiversionMode to “Add” and HistoryInfoMode to “Remove” in order to solve my issue.  I tried that (and several other combo’s) and it did not work. I spent a ton of time on this before I finally broke down and opened a case with AudioCodes.  The solution they gave me was to perform Message Manipulation.  In order to achieve what I was looking to do, I had to perform the following steps:

Under VoIP, SIP Definitions, Msg Policy & Manipulation, click on Message Manipulations:

Then, add a record. In the Add Record box, set your Index (mine was 0 because I didn’t have any others).  Then choose the Manipulation Set ID (I chose 1 as I didn’t have any others). In the Message Type, enter “invite.request” and then in the Action Subject type “header.diversion”. For the Action Type select “Add”. Finally, enter the Action Value.  The action value is where you enter what you want to go into the Diversion header. Here is an example:

‘tel:+18889990000;reason=unknown;counter=1;screen=no;privacy=off’

The tel:+18889990000 needs to be a phone number that CenturyLink owns (I just chose the main number for the client). Also, the single quotes are needed as well.

After creating the Message Manipulation, we need to make it so that it will take effect on one of our IP Groups. Under VoIP, Control Network, click on IP Group Table and choose the entry for your SIP Provider and click Edit.

Click on the SBC tab and under the Outbound Message Manipulation Set enter the value that you entered in the Manipulation Set ID previously (in my case it was “1”).

After submitting and burning the config, we tested an bingo, we had Call Forward and SimRing working.

Another note, in the AudioCodes Mediant 1000B documentation, the Message Manipulation section is 17.4.  Here is a quick snip from it:

The Message Manipulations page allows you to define up to 100 SIP message manipulation rules. Each manipulation rule can be assigned any Manipulation Set ID (0 to 19), enabling you to create groups (sets) of manipulation rules whereby rules of a group are configured with the same Manipulation Set ID number. To use these Manipulation Sets, you need to assign them to IP Groups in the IP Group table (see ‘Configuring IP Groups’ on page 198) where they can be applied to inbound and/or outbound SIP messages.

_SIP message manipulation enables the normalization of SIP messaging fields between communicating network segments. For example, it allows service providers to design their own policies on the SIP messaging fields that must be present before a SIP call enters their network. Similarly, enterprises and small businesses may have policies for the information that can enter or leave their networks for policy or security reasons from a service provider. The manipulations can also be implemented to resolve incompatibilities between SIP devices inside the enterprise network.___

_SIP message manipulation supports the following:___

  * _Addition of new headers.___
  * _Removal of headers ("Black list").___
  * _Modification of header components - value, header value (e.g., URI value of the PAsserted-___
  * _Identity header can be copied to the From header), call's parameter values.___
  * _Deletion of SIP body (e.g., if a message body isn’t supported at the destination network this body is removed).___
  * _Translating one SIP response code to another.___
  * _Topology hiding (generally present in SIP headers such as Via, Record Route, Route and Service-Route).___
  * _Configurable identity hiding (information related to identity of subscribers for example,___
  * _P-Asserted-Identity, Referred-By, Identity and Identity-Info).___
  * _Apply conditions per rule - the condition can be on parts of the message or call’s parameters.___
  * _Multiple manipulation rules on the same SIP message.___