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 http://maxyaquos.blogspot.com /2011/01/enterprise-voice-best-practices-in-lync.html">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):
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.Issue: You are using remote call control with Microsoft Lync 2010 and are unable to do one or more of the following:Resolution: Lync 2010 does not support the remote call control features in the preceding list. There currently is no workaround for this issue.
- Download normalization rules (emphasis mine)
- Use video calling
- Transfer meetings to your own number(s)
- Join meetings by using the Join From dialog box
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.
0 komentar:
Posting Komentar