Home > Uncategorized > Lync, CenturyLink, AudioCodes and a Diversion Header

Lync, CenturyLink, AudioCodes and a Diversion Header

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:

CallForward

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:

AC_Manual

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:

AC1

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.

AC2

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.

AC4

AC5

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”).

AC6

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.
Advertisements
Categories: Uncategorized
  1. Cameron Moore
    June 19, 2014 at 3:28 pm

    Great blog post. I wanted to share a few things. I’m using Lync 2010.
    1) The “Interworking SIP Diversion and History-Info Headers” section of the AC docs doesn’t work because that feature requires that a Diversion or History-Info header be present to convert between them. Since Lync doesn’t provide either header, that feature is not applicable to our situation.
    2) My SIP provider, Level 3, requires me to send a host in the Diversion header URL. For example, I have to send “Diversion: ;…”
    3) I wanted to create a Diversion header with the actual referring number instead of just a main number, so I created a rule to get the number from the Referred-By header to create the Diversion header user field. Lync creates a Referred-By header like this for me:
    REFERRED-BY:
    Here’s my message manipulation rule:
    Message Type: Invite.Request
    Condition: header.referred-by regex <tel:([^;]*);
    Action Subject: header.diversion
    Action Type: Add
    Action Value: ';reason=unconditional;counter=1;screen=yes;privacy=off’
    If you don’t use the ext=NNNN format in Lync (ie. “”), you can create a simpler rule without the regex:
    Message Type: Invite.Request
    Condition: header.referred-by exists
    Action Subject: header.diversion
    Action Type: Add
    Action Value: ‘;reason=unconditional;counter=1;screen=yes;privacy=off’

    • June 19, 2014 at 4:00 pm

      For Lync 2010, you can enable the History-Info (ReferedBy) using http://support.microsoft.com/kb/2500421. Not sure if that will work or if that is what you did to get your Phone number for your Diversion header.

      My specific issue was that we were not using the SBC functionality, we were using just the Gateway functionality.

      Thanks for commenting and posting it on your blog so you could have the good formatting!

      • Cameron Moore
        June 19, 2014 at 4:18 pm

        Although I did it months ago and my memory may be fuzzy, I believe that KB article is how I got the Referred-By header.

  2. Cameron Moore
    June 19, 2014 at 3:54 pm

    *sigh*
    Comment formatting gremlins chewed up my beautiful comment. I’ve posted a properly formatted response on my blog:
    http://wp.me/p1f04-9

  1. August 12, 2013 at 6:48 am
  2. January 7, 2014 at 3:27 pm
  3. June 19, 2014 at 3:50 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: