Migrating PBX Users to Lync Enterprise Voice

In http://innaz2.blogspot.com /search/label/EV%20Best%20Practices">all my previous blog entries about Lync Enterprise Voice Best Practices, I've assumed that the Lync deployments described are pure Lync.  There is no mention about connecting to legacy PBXs and how to best setup Lync to integrate with them.  Well, today is the day that we deal with that thorny issue.

Typically, there are two types of PBXs.  The oldest style are purely analog devices and are known in the industry as TDM PBXs.  TDM is short for Time Division Multiplexing - the old analog way of slicing up a telephony pipe to allow multiple calls.  Since Lync is not an analog phone system, you require an IP-PSTN gateway to communicate with TDM PBXs.  There are several gateway vendors out there that provide Lync-compatible gateways.  Some of my favourites include Audiocodes, Dialogic and NET.

The other type of PBX is called an IP-PBX, which is digital in nature and uses TCP/IP for its voice backbone.  Pretty much every PBX sold today is IP-based.  An IP-PBX may use SIP or other proprietary protocol for communications.  If the IP-PBX uses SIP, then there is a fairly good chance it can communicate directly with Lync over TCP/IP.  This is by no means a sure thing, because every vendor interprets the SIP standard differently, and this often means that two different SIP-based telephony systems can't communicate with each other.  In that case, you'll need to use an IP-PSTN gateway to bridge the two.  Even if you can get Lync to talk to the PBX for basic calls, you may encounter issues with transferring or forwarding, which is again due to the different ways that vendors interpret the SIP standard.

Connecting a PBX to Lync
There are two ways to connect an IP-PSTN gateway to a PBX. The most obvious way is to put the gateway behind the PBX (as shown below) connected via a T1 crossover cable. This is the lowest impact solution for the PBX side of things, but it can make routing calls to Lync difficult, because you will be relying on the capabilities of the PBX for such decisions. If you are not well-versed in the operation of the PBX, this will usually require the services of a PBX technician, which can cost both money and time. If you are working with a TDM-PBX, then you are also relying on the availability of a spare PRI card on the PBX. This may not be available due to limited expansion capabilities or availability of hardware.

This may be the only workable solution if your users are assigned extensions, rather than direct numbers (DIDs), because the gateway will always just see the main office number on inbound calls, and won't be able to tell if the call should go to Lync or the PBX.  Also, if you rely on an autoattendant for routing calls, you will need to route all calls to the PBX until you've migrated all users to Lync.

If your users all have DIDs or your PBX doesn't have any expansion slots available for an additional PRI card, then the more preferred solution is to place the IP-PSTN gateway in front of the PBX.  This requires 2 PRI interfaces on the gateway (or more if you have multiple lines coming in to the PBX).  Most gateways allow you to set the interfaces in pass-through mode, so that a failure in the gateway will just pass all calls through as if it weren't even there.

Now inbound routing logic is controlled by the gateway, which is much easier to manage than most PBXs.  Usually, you set a default rule for calls bound to the PBX, and insert rules to forward calls to Lync users as you see fit.  Many gateways provides Active Directory-based routing that can detect if the user is enabled in Lync and route calls accordingly.

Outbound routing from the PBX should be relatively easy as well.  In some cases, you would create a default rule that would route any extension that doesn't have an internal match out of the PBX, and the gateway will route the call to Lync.  Other cases may involve setting up forwarding on the internal extension to a pre-defined extension range, that then gets transferred to the gateway and on to Lync.

Setting Up Lync to Route Calls to a PBX
Once you've got the hardware setup, you need to connect Lync to the PBX or gateway.  This guide won't get into the details of setting up a specific gateway to work with an given PBX.  There are lots of those out there.  Once you've got a working connection, you need to define the IP address of the gateway in your Lync topology document.  You define the gateway under the PSTN gateways node of your Lync site.  A PSTN gateway needs to connect to a mediation pool, which is often collocated with the front-end Lync server role. 

As followers of this blog may know, I am a big proponent of e.164 formatting for phone numbers.  Ideally, all the phone numbers you define for Lync use - from the actual number assigned to an Enterprise Voice enabled user to the phone numbers listed in Active Directory - should be formatted in e.164 format.  If your users have DIDs, then this should be straightforward.  For users that only have extensions, you should use the format +<countrycode><officenumber>;ext=<extension>as explained in my http://innaz2.blogspot.com /2011/05/enterprise-voice-best-practices-in-lync.html">blog post on Internal Extensions.  Resist the temptation to use only the extension as the user's phone number.

As you transition to Lync, you should allow your Lync users to dial others using the methods they are familiar with.  For most, this means dialing by extension.  You will want to allow extension dialing in Lync with the least amount of administrative overhead as you migrate users from the legacy system to Lync.

You achieve this by creating normalization rules that translate extensions to full e.164 phone numbers and outbound translation rules that turn e.164 phone numbers BACK into extensions.  An example with a company whose main number is +1 (212) 555-1111 that uses 3-digit extensions starting with 2 is below:

Normalization Rule: ^(2\d{2})$ --> +12125551111;ext=$1
Outbound Translation Rule: ^\+12125551111;ext=(2\d{2})$ --> $1

Sample scenario:
Dial 234 --> normalize to +12125551111;ext=234 --> strip to 234 --> send to PBX

You may wonder why go through the trouble of normalizing 3-digit extensions to e.164 when we just strip it back down to 3-digits at the gateway.  A long time ago, I evangelized the reasons why you should use e.164 formatting for your user phone numbers.  http://innaz2.blogspot.com /2010/12/enterprise-voice-best-practices-in-lync.html">I won't rehash what was said there, but it suffices to say that e.164 formatting is the way to go in almost every situation.  So, using the above example with +1 (212) 555-1111 as the main office number, assign phone numbers to your Lync users like this:  tel:+12125551111;ext=201.  If a Lync user dials 201, it will normalize to the full e.164 format, find a match in its database and ring the user.

If someone dials an extension that doesn't yet exist in Lync, say 299, it will normalize to e.164, fail to find a match in its database, and then route it out to the PBX after stripping it back down to 3-digits. 

The Lync Dialing Rule Optimizer can help ease the workload involved in setting up this routing logic.  Simply select the Use Extensions checkbox (coming soon), and enter up to 10 extension ranges.  The Optimizer will take care of the rest, including proper ordering and placement of rules.

Migrating PBX Users to Lync
Following this generalized plan makes migrating users to Lync very simple:

1. Enable user in Lync with the proper e.164 phone number.  Lync-initiated calls to their extension should now be intercepted by Lync.
2. Depending on the layout of your legacy PBX, you may just need to simply delete the users extension, and PBX-initiated calls to that number should default to routing out to the gateway.  Other PBXs may require additional work to ensure calls to that specific user route to the gateway.
3. Depending on the gateway, you may need to modify your PSTN-inbound rule to route inbound PSTN calls for that user to Lync.  As mentioned earlier, some gateways can detect the user is enabled on Lync and route the call accordingly.

The first few times I had to go through this exercise, it took me a while to wrap my head around what I now think is the best way to do things.  I hope this will help others get over some of the hurdles of deploying Enterprise Voice and do thing right the first time.

Links to my other posts in my Enterprise Voice Best Practices series:
http://innaz2.blogspot.com /2010/12/enterprise-voice-best-practices-in-lync.html">E.164 Formatting
http://innaz2.blogspot.com /2011/01/enterprise-voice-best-practices-in-lync.html">Normalization
http://innaz2.blogspot.com /2011/01/enterprise-voice-best-practices-in-lync_21.html">Usages and Routes
http://innaz2.blogspot.com /2011/05/enterprise-voice-best-practices-in-lync.html">Extensions