Tuesday, August 28, 2012

Lync Server 2010/2013 and Cisco/Nortel/Avaya integration

UPDATED: Slight change in my approach here. As it turnes out we only need to drop the plus sign on sim-ring users. Read on...

I suppose the article name is somewhat misleading as the following information is really pertinent to just about any Lync Server 2010/2013 implementation involving a PBX. New Lync Server 2013 features notwithstanding, I'll provide a few scenarios for implementing the more common (Cisco/Nortel/Avaya) PBX systems on the market today and demonstrate what I believe is the perfect compromise between world domination and exile.

I'm engaged with customers on a regular basis who have an existing legacy PBX (i.e. Nortel/MITEL) or have completed a new implementation (i.e. Cisco/Avaya) of an IP telephony solution. As an afterthought they have visions of a perfectly integrated Unified Communications strategy involving multiple vendors including Microsoft's Lync Server platform. Some of the common questions I hear are:
  1. We've just completed our Cisco Call Manager installation, have deployed IP phones, and we simply don't like their desktop software story. We want Lync on the desktop but don't want to lose our investment in IP telephony. Can you make them work 'together'?
  2. We like what Lync has to offer but we simply can't remove our PBX yet due to call center integration and feature limitations. We want users to keep their identity and voicemail platform on the PBX. How can you integrate Lync with our existing systems?
As an advocate for the Microsoft UC platform, I used to consider anything short of a full Lync IP telephony deployment a failure. After realizing we can't win them all...I've softened up a bit and since then have come up with a solution I believe is a great balance between ripping out the PBX and losing a Lync deal.

Before we get started you need to forget one of the most important rules you've learned; you won't be using E.164 format for the LineURI in Lync. Actually we will, sort of. The purpose of using E.164 as a numbering standard is because your dial plan is exposed across the AD forest. In other words the LineURI needs to be globally unique enough to prevent collision with another number.

So let's start with common customer requirements. In some cases customers will want voicemail to remain on the PBX and are strictly against Exchange UM for compliance or political reasons. In other cases customers want voicemail both tied to the IP phone and the Lync user. I'll outline options for both scenarios.

Customer requirements:
  1. We need Lync users enabled for Enterprise Voice (EV).
  2. EV-enabled Lync users must keep their IP phones.
  3. IP phones should have voicemail homed on the PBX.
  4. Calls to IP phones must also ring the Lync user (sim-ring).
  5. Caller ID for calls from Lync to PBX or PSTN should represent the PBX DID. Additionally, users authenticating to a Lync PSTN conference need to authenticate with their real DID and PIN.
  6. Lync to Lync calls via click to call (contact card DID) or simply keying in the user's DID must ALWAYS leave Lync and ring the PBX first.
To many who design Lync environments this can be a difficult list to adhere to. In many cases the most difficult requirement is the last one because of "Reverse Number Lookup" (RNL) in Lync Server. For those who don't know what RNL does, it is a process by which Lync Server will perform a lookup of the dialed number (the "A-party") and if a match is found it will ring the user's SIP URI. Any other IP-PBX system does the same thing however in Lync we call it RNL. In cases where a person performs a click-to-call (i.e. contact card in Lync or number on a web page), RNL will find the SIP URI of the called party and the call will never leave Lync and ring the IP-PBX phone. So how can we force Lync to send calls to the PSTN in the click-to-call scenarios?

Let's focus on requirements #4, #5, and #6 as they are most relevant here.

Scenario: Alice is using her IP phone (7805551234) to call Bob's IP-PBX phone (7805553001) where the call is forked to Bob's Lync identity (SIPURI: bob@contoso.com and LineURI: +17805553001;ext=3001). Let's look at the requirements again:

4. Calls to IP phones must also ring the Lync user (sim-ring).
The PBX really needs to own this feature however we need to ensure we work with the telecom teams to design a solution which will work with Lync. In the case of Cisco, the Mobility feature must be used to sim-ring the Lync number and in cases where Nortel is used, PCA licenses may be required for the same purpose/feature-set.

Similar to the RNL feature in Lync, other PBX systems need a unique number represented by the sing-ring so as to not cause a loop or sim-ring call to end up directed at voicemail instead of Lync Server. For this purpose I'd recommend using a steering code (prefix called party with a series of digits). For example, if Alice (7805551234) calls Bob (7805553001) we need the PBX to fork the call to a third number for Bob (89+7805553001). The PBX adds the "89" steering code which is used in their routing engine to send the call to Lync via Direct SIP or a Gateway.

To simplify the configuration we need Lync to strip the steering code so the number can match Bob's LineURI attribute in Lync.

NOTE: Common mistakes are to set Bob's LineURI to "897805553001" which breaks requirement #5 or to use a phantom non-DID such as "3001" which also breaks #5 and #6.

Don't use the gateway to this work as it only complicates the solution. Within Lync Server create a pool-based dial plan tied to your IP gateway object and within it create a normalization rule to strip the steering code. For example "^89(\d{10})$" translates to "$1". This means Lync will attempt to perform RNL against 7805553001 specifically.

NOTE: Another common mistake I've seen is Lync administrators writing inbound normalization rules to handle the 'non-DID' formatted number (with the ;ext= attribute). You don't need to worry about this as a call to 7805553001 will match both 7805553001 and 7805553001;ext=3001. Beware however that if you have a base number of 7805553001 assigned to a Lync user along with extensions off the same base number such as 7805553001;ext=1301 and 7805553001;ext=1302, etc. This will result in a failed call as it is too ambiguous (SIP/2.0 485 Ambiguous).

So now that Lync receives a call for 7805553001 and matches Bob's LineURI which is 7805553001;ext=3001 we have met this requirement. Both Bob's IP phone and Lync will ring. The only real change to a typical dial plan is that we've removed the country code (North America=1). Again going back to my E.164 discussion above, by removing the "1" we've potentially made the number less unique however I would submit to you that in 100% of the cases I've seen this isn't an issue because we're using the ";ext=" attribute to gain uniqueness again. In other words if you have a collision in your dial plan as a result of "7805553001;ext=3001" not being unique enough come talk to me!!

5. Caller ID for calls from Lync to PBX or PSTN should represent the PBX DID. Additionally, users authenticating to a Lync PSTN conference need to authenticate with their real DID and PIN.

Since we've given Bob a LineURI of +7805553001;ext=3001 his caller ID to the PBX from Lync will be displayed correctly. In Lync Server 2013 you can optionally build trunk de-normalization rules to strip the ;ext=3001 from the caller ID if necessary.

Bob's LineURI also permits him to authenticate to Lync PSTN conferences using his PIN and even his 10-digit number if necessary. Never give Bob a 'fake' LineURI as this only adds confusion in the Dial-In conferencing page and with his experience in authenticating to the bridge.

6. Lync to Lync calls via click to call (contact card DID) or simply keying in the user's DID must ALWAYS leave Lync and ring the PBX first.

So this is often the most tricky to achieve not only because of RNL but also because of "Global Numbers". What are Global Numbers you ask? Lync will never use client-side or server-side normalization rules for numbers prefixed with a "+" sign. This is very important in click to call scenarios as you would possibly expect +17805556009 follow client-side normalization. It will not as it assumes the number has been pre-formatted already on purpose.

So the challenge is....when a Lync user selects a user's desk phone number from their contact card, how can we bypass RNL so the call leaves Lync and rings the PBX? Well the secret again is in the LineURI format.

NOTE: I've seen people hack away at the Address Book normalization rules to present a different number format in the contact card; don't do this! Remember....contact card is also visible to federated users as well and if you're representing a number only relevant to you, this will break their click to call scenario. Leave your address book normalization rules as they should be and normalize to E.164 format ALWAYS. Secondly, if you've enabled Call Admission Control and a situation occurs where your call is blocked due to a CAC policy, we need the LineURI number for PSTN reroute.

When Bob clicks on Alice's contact card to call her DID on the PBX it shows up as +17805551234. Since Alice is also a Lync user with Enterprise Voice, her LineURI is +7805551234;ext=1234. This will result in a failed match by RNL and Lync Server will then route the call to the PBX. Optionally you can use trunk de-normalization rules to strip the "+1" from the called party ID.

A word about voicemail...
In many of these cases customers are interested in trying out the features of Exchange UM to the point where we install a server as a pilot initiative. The issues we face with integrating Lync and Exchange with another PBX or IP telephony solution often circle back to Lync's limited integration with 3rd party voicemail platforms. Said another way, you cannot connect Lync to any other voicemail platform than Exchange UM. This certainly isn't a dig against Lync as the amount of engineering gone into the 'better together' story of Lync and Exchange is simply staggering. I understand the investment and need to protect that. So the real question is....what's the best way to make this all work?

Let's start with what your options are, describe the pros and cons of each, and I'll provide my recommendation.

Option 1: Keep voicemail with the PBX
In this scenario the IP phone will remain paired to the voicemail platform in place today and the Lync EV user isn't UM-enabled. Since we're sim-ringing into Lync, a call gone unanswered will divert to the PBX voicemail platform. In an environment politically charged with fear of job loss due to VoIP in general, the upside is people feeling more comfortable about the solution and overall simplicity. The theme is "Lync is simply a 'bolt-on' and I'm not going to lose my job because of it". The downside is Lync to Lync calls will end after 20 seconds.

NOTE: Keep in mind you will want to introduce a GPO for Lync to turn off the feature to "Save call logs in my email Conversation History folder" as this will result in a missed call notification for every call answered by the PBX on a sim-ring into Lync.

Option 2: Keep voicemail with the PBX and enable the Lync user for UM.
Enabling the Lync user for UM will resolve the downside issue in the previous example so we consider this to be a pro. However there is an argument to be made about complexity as call routing scenarios could result in missed calls going to one of two voicemail platforms adding confusion to the user experience. Add to this the ability for a Lync user to sim-ring, call forward, or team-call a series of other Lync users and the call routing/destination could be any one of hundreds of possibilities.

Consider the following: Bob, a PBX user with voicemail is set up to sim-ring his Lync account which is also UM-enabled. Bob set up sim-ring in Lync to ring his cell phone at the same time. While out of range, or with a dead battery, Alice calls Bob. What happens to the call? The answer is....Bob's cell phone voicemail will. Confusing? Maybe not for someone who understands the solution but to Bob it most certainly could be. You could resolve this by disabling call forward and sim-ring via Voice Policy in Lync however at this point the added complexity to neuter Lync seems like a lost cause.

Additionally, this method is a little more tricky as you not only need to take the above GPO setting into account, you also need to turn off missed call notifications in the UM dial plan.

Option 3: Move voicemail from PBX to UM and enable the Lync user for UM.
This one seems to have the most promise but comes with a significant "con". The biggest advantage here is that users have a consolidated voicemail platform between the two systems which reduces confusion and complexity.

In this scenario we have an IP-PBX configured to use Exchange UM as the voicemail platform for Bob's IP phone. Bob is also a Lync EV user who we'd like to provide voicemail for sim-ring calls and/or Lync to Lync calls. The solution here involves the enablement of a secondary dial plan for Bob.

Here are a couple of things to consider:
  1. You must enable the Lync user for UM first.
  2. Then add the secondary dial plan which uses the IP-PBX as a UM IP Gateway.
  3. In this scenario the voicemail light (MWI) on the IP phone will not light up even with Exchange 2010.
At first glance the obvious "con" is the lack of a Message Waiting Indicator light on the IP phone could spell disaster. I have to say that it really depends on the organization you're dealing with. If you explain how Lync will show new voicemail in the system tray, in the client, and Exchange will show voicemail in the inbox, users typically have smartphones these days so they know immediately if they have voicemail even when they're away from their desk.....and on and on....sometimes its enough to convince them....sometimes it isn't.

Secondary Dial Plan Reference: http://technet.microsoft.com/en-us/library/ff629383.aspx

Recommendation: Option 3 some of the time...
Believe it or not I honestly can't say I've seen one solution work 'better' over another. It really comes down to customer requirements, their ability and willingness to test and take on new challenges, and maturity from an Exchange/Lync perspective.

Hope you all find this useful. I'll update and modify this article as I come across anything new or if someone reports an issue/error in the content.

Remember....Keep Calm and Chive On!

9 comments:

  1. Great article. Really helped me. I have one question though.

    What do I in the scenario of "7805553001;ext=1301 and 7805553001;ext=1302" numbers? My CISCO environment does not have DIDs and has extensions off the base number.

    Right now I am just sending the extensions (13xx and 40xx) and in Lync I have specified the user Line URI as "Tel:13xx"

    Thanks in advance,
    Paul

    ReplyDelete
  2. Send the calls as 13xx to Lync but change your LineURI on your Lync user accounts to use the format suggested. You can actually keep the country code as I've tested this as well. Just make sure you don't include the plus sign.

    ReplyDelete
  3. Thanks for confirmation. I was able to integrate with Call Manager 5.1 which is not officially supported. Your article was of great help! :)

    ReplyDelete
  4. Thank you for this information. Really helped me! Have a great day!

    ReplyDelete
  5. Hi Jason,
    we have a Nortel CS1000 E and a Cisco UCM. Which vendors would recommend for a GW? Thanks for the article.

    ReplyDelete
  6. Any of the certified gateways on the Lync OIP site will work. Personally I've found the NET/Sonus devices to have the most flexibility.

    ReplyDelete
  7. Avaya CM R5.2.1, works fine. No UM in those branch-offices.
    Avaya CM R6 + SM R6 works as well, together with Exchange 2010 UM. Btw, MWI is working on the phones (Avaya 9640G H.323 and Avaya 9670G H.323)

    ReplyDelete
  8. Forgot to mention, you will require EC500 licenses ( Avaya equivalent of "mobility" or "sim-call" feature). However most of the customers have gotten them for free if updated within past few years from CM5 or purchased a new installation of CM6.

    Generally there is just one major downside of implementing Lync and PBX integration. The total cost of ownership is insane. You need Exchnage Enterprise CAL's, Lync Enterprise CAL's and a full Lync client which comes with Pro Plus Office or bought separately.

    ReplyDelete
  9. Great Article,

    You know I just recently integrated Lync 2010 w/EV & CUCM 9.1.1 by creating a SIP Route Pattern using SIP URI dialing pinned to the Direct SIP trunk to the Lync server. This allowed me to keep the same DNs on both sides and the routing works great (and YES I also disabled the missed call notification in the Lync policy).

    In order to get around the RNL issues I appended the following to the Lync user's Line URI:

    tel:+1555556812;ext=26812;ms-skip-rnl

    The (2) before the four digit extension represents a rudimentary site code to route calls to a different partition as we are a national organization with offices in many states.

    The (ms-skip-rnl) designation tells the Lync server to ignore RNL and passes every call over the SIP trunk to the call manager. Paired with Cisco mobility, It works pretty well.

    Two things I get beat up about on occasion.

    1) Lack of presence information for off-hook status between Lync and Cisco phones. I thought that I could get around it by working a federation with presence but it has yet to pan out. I even started to look at the Presence API to see if I can hack it together but I simply don't have the time to code something on the quick. Not to mention that there is NOTHING "quick" about coding a listener for both sides.

    2) Setting up remote destination profiles for each user in the Call Manager has the CUCM operators pulling their hair out. Waiting to see if Cisco Prime will make this nightmare easier to take on.

    I looked at RCC but it gutted too much of the Lync functionality. Its not perfect but people love the ability to do interactive desktop/application sharing out in the wild (from home, a cafe, etc) without VPN (which they could not do with Jabber at the time).

    Not to mention that provisioning users in Lync is considerably more scalable/"automatable" (not a word I know) from an operations perspective than with CUCM.

    Thanks again, really good stuff.

    ReplyDelete