Wednesday, October 12, 2011

Lync Normalization Rules, RCC and You

A little publicized feature of Lync is its ability to remotely control a deskphone from another vendor (say Cisco).  This is known as Remote Call Control (RCC).  Your desk phone rings, and you get the Lync pop-up telling you about the call. Clicking the pop-up will answer the call on your deskphone.  You can make calls via Lync, but the call will be dialed via your deskphone.  In this scenario, you're not using any of the features of Enterprise Voice, but it does provide some semblance of integration between another vendor's PBX and Lync.  The mechanism that allows this coordination is called Computer Supported Telecommunications Application (CSTA).  If the PBX doesn't support it natively, then you would usually deploy a SIP/CSTA gateway between Lync and the PBX.

This post isn't about how to setup RCC.  There is already lots of information out there about that.  As the post title infers, it's about phone number normalization and RCC and some confusing information from Microsoft. 

If you read through the official Technet documentation on RCC, you may have noticed the following bit of info (from http://technet.microsoft.com/en-us/library/gg558630.aspx):
Lync clients download phone number normalization rules as part of the Address Book Service (ABS) file download. In remote call control scenarios, Address Book Service phone number normalization rules are applied to both incoming and outgoing remote call control calls.
From that, you'll probably think that all you need to do is to setup normalization rules as part of a Lync dial plan, as I've described before.  So, you go through the motions of creating a dial plan, but you'll soon realize that the normalization rules you created are not being applied to RCC calls.  If you do some more digging, you might come across this seemingly contradictory statement from Microsoft (from Remote Call Control Features not Working):

Issue: You are using remote call control with Microsoft Lync 2010 and are unable to do one or more of the following:
  • Download normalization rules (emphasis mine)
  • Use video calling
  • Transfer meetings to your own number(s)
  • Join meetings by using the Join From dialog box
Resolution: Lync 2010 does not support the remote call control features in the preceding list. There currently is no workaround for this issue.
While these two statements might seem to contradict each other, they are actually both correct.  The key difference is that the first statement says Lync will download normalization rules as part of the Address Book Service file download.  The documentation doesn't go into much more detail on that, but what they are referring to is the normalization rules stored in the Company_Phone_Number_Normalization_Rules.txt file. 

The original purpose of this file was to store normalization rules that are applied to phone numbers associated with Active Directory user accounts. If your users' phone numbers in AD are not in E.164 format, then Lync won't show them to you when you click on a user.  The normalization rules defined in the Company_Phone_Number_Normalization_Rules.txt file are used to normalize those AD numbers into the proper E.164 format.  I won't go into more detail, because there is already an excellent post on the subject by Jeff Schertz. 

The little known part is that this same file is the ONLY method used for normalizing phone numbers  typed into the Lync client for outbound dialing, when that user is enabled for RCC.  Lync dial plan normalization rules are not applied (hence the statement about RCC Lync users not downloading normalization rules). 

For instance, if your PBX requires a 9 in front of local numbers and an 8 in front of long-distance numbers, you would have to create these rules in the Company_Phone_Number_Normalization_Rules.txt file like this:

^(\d{10})$
9$1

^(1\d{10})$
8($1)

When a user types a 10-digit number into Lync like 4165551111, it will normalize to 94165551111, which can be sent to the PBX for proper remote call control functionality.  Likewise, typing 16132223333 would normalize to 816132223333

An additional example would be 4-digit extensions that need to be translated to 10-digits:

^(\d{4})$
905222$1

You may notice that these examples don't normalize to E.164, which is something I preach regularily on this blog.  When you're dealing with a legacy PBX, you're at the mercy of whatever rules are defined for it.  Those rules often don't use E.164 formatting.  You just have to work with what you've got.

Now, what if you've got multiple sites that you want to use RCC, but each site has its own special rules on how to deal with particular numbers?  You can have a different Company_Phone_Number_Normalization_Rules.txt for each Lync pool, so it shouldn't be too difficult to make RCC work in most scenarios.

In essense, when deploying RCC, don't bother creating Lync dial plans, normalization rules or any other Enterprise Voice related content.  Remote Call Control simply does not use any Enterprise Voice functionality.  The Company_Phone_Number_Normalization_Rules.txt file is the only way to do any number manipulation.

Hopefully, this will help anyone attempting to deploy Lync RCC and has come across this stumbling block.

6 comments:

  1. Ken- Great post. However, I've got the file set up like you and Jeff define, with the sole exception that we use an 8 for all outbound dialing on our RCC phones, but no matter how many times I update the address book, it never seems to get those rules. Is it something that's specific to the target phone system? We have an Avaya system that hasn't always played nice with Lync. Thanks in advance!

    ReplyDelete
  2. Hi adam. If you delete the galcontacts in the user folder does it update then? where have you placed the normalization file?

    ReplyDelete
  3. Ken, this is a great post and I wish I would have came across it earlier (before learning the HARD way).

    One point I wanted to make is that there DOES appear to be at least one scenario where I've found it necessary to deploy Lync Dial Plans with RCC. This is when the system is also needed for multiple Dial-In Conferencing Access numbers (say, you have several companies, and want to default Des Moines users to a different dial-in than Seattle, for eacmple). Because the Lync Dial Plan is the construct that maps a dial-in conferencing to a user and conferencing region, it's the only way I've found to do this.

    Because the Lync Control Planel GUI doesn't allow an RCC user to even choose DialPlan, I found it necessary to use the cmdlet 'grant-csdialplan' necessary.

    mG

    ReplyDelete
  4. So given that the normalization file is for both inbound and outbound calls. How do you differentiate which rules are for inbound calls (AD Number Normalization) and which are for outbound calls (Lync RCC number pad dialing Normalization)?

    For example, the first rule I would have would be to normalize AD numbers:
    ^(\d{10})$
    +1$1

    But then I'd want a rule for adding 9 for any 10 digit local numbers manually typed into Lync by RCC users:
    ^(\d{10})$
    9$1

    The patterns are the same, so how would it know which one to use?

    ReplyDelete
  5. Great post Ken. I wanted to ask you a question, I have 1500 rules of normalization on a Dial Plan. When I delete one of these, can I still use that rule of normalization in the lync clients. Is there any way to update clients on Lync normalization rules either interface or via powershell?

    thanks

    ReplyDelete
    Replies
    1. Hey Christian,
      No, client side normalization rules are done only via the dial plan.

      Ken

      Delete

Note: Only a member of this blog may post a comment.