Microsoft Lync and Microsoft Exchange 2010 UM integration
There are a lot of other resources out there that will tell you how to integrate Exchange UM with Microsoft Lync. This blog isn’t going to cover this aspect. It is covering another issue, transferring calls from an UM Auto-attendant to another extension, say a Subscriber Access number. Here is the scenario:
Client has limited amounts of DIDs, so all users use the tel:+1xxxyyyzzzz;ext=aaaa format. They have a single DID that is going to be used for an auto-attendant. They still want a Subscriber Access number, but to have it as an extension versus a DID. The extension used for the Subscriber Access number is +2999. I could not use the format above as it is 21 characters and Exchange 2010 UM has a limit of 20 characters (figures ). When you call into the AA, you press “8” or say “Subscriber Access” to be transferred. The transfers would fail to the Subscriber Access number. Transfers to users (entering extensions and/or saying their name worked every time, but transfers to Subscriber Access failed. Here’s why:
Exchange 2007 UM
First let’s cover the “old” days of OCS R2 and/or Lync integration with Exchange 2007 UM. In the past you had to have your dial-plans match exactly or the integration would fail. Example would be Lync dial-plan of “Test123.local.com”. The dial-plan you create on Exchange would need to be exactly the same “Test123.local.com” or the integration would fail. This is because when a call would come into Exchange 2007 and the call was being transferred to a user and/or another number, it would append the “Test123.local.com” to the “phone-context=” in the INVITE. Lync would see this and handle the call appropriately.
Exchange 2010 UM
With Exchange 2010 the above Exchange 2007 rules no longer apply. You no longer need the dial-plans in Lync and Exchange to match in order for the UM integration to function properly. Why? Well, Microsoft changed the way the calls are transferred. Instead of appending the “phone-context=” with the dial-plan name, it sends the calls with “phone-context=user-default@domainname.com”. This is a great change, but there is a caveat.
Caveat
The problem with the above is when the INVITE is sent using the default dial-plan, Lync matches the Global dial-plan. Some people configure the Global dial-plan, others like more personalized or easily identifiable dial-plans. So they leave the default configuration of the Global dial-plan. If you are using E.164, then this isn’t a problem as the default normalization rule prefixes a “+” to the numbers coming in. Everything and everyone is happy. In this particular installation, this wouldn’t work as the call coming in wasn’t matching the default rules and Lync was giving errors in the translation logging that it found a matching number, but it was in a different dial-plan, and the transfer would fail.
Resolution
To make the transfers work, I needed to modify the normalization rules of the Global dial-plan to match the incoming “2999” number and normalize it too “+2999”. This worked. I know I could have given a bogus E.164 (+15555552999) number instead of using a 4-digit extension, but we didn’t for other reasons.
Emilio Rivera, PEI
