Friday, November 18, 2011

Lync and 3rd Party PBX Integration

I've been reading the comments over at VOIPNorm's blog post about Avaya ACE.  There's a lot to wade through there, but it got me thinking about customer expectations around unified communications.  I've got this one particular customer who's got Cisco phones deployed everywhere.  They've also got Lync everywhere and people love it.  They recognize that Lync has nailed the user experience, encompassing a full featureset along with an easy-to-use interface.  Naturally, this customer doesn't want to toss out their significant investment in Cisco hardware, and they want Cisco and Lync to work together.  They want Lync to work with their existing phone system with little fuss, and still maintain the rich UI experience of Lync.

What I want to tell them is that you will NEVER have a truly seamless easy-to-use experience when you try to join two competitors' UC products together.  To paraphrase one of the commentors at VOIPNorm's blog: when you mix a nice red wine with a nice white wine, the end result isn't a great rosé.

At this client, we attempted to go down the integration path with OCS and a third-party product that promised seamless remote call control with Cisco.  They were looking at a 3rd party for RCC rather than Cisco's Unified Presence Server (CUPS), because of apparent scalability issues with CUPS.  From an administrative standpoint, the 3rd party product was an absolute nightmare to configure and troubleshoot.  Once we did get it working, it did provide remote call control, but there were significant usability issues.  The product worked fine when the user was in the office.  Users could make or take calls on their deskphone using Lync to control it.  However, when the user went home they got frustrated when they couldn't answer incoming calls they could see on their Communicator client because it would answer it on the deskphone back in the office.

We tried giving them the best of both worlds by enabling them for Enterprise Voice, but that became a support nightmare when they got confused about which way to answer the phone or to make calls.  If they were set to answer via Communicator, they were confused why their deskphone didn't go off-hook.  If they made a call from home and they were set to RCC mode, then they didn't understand what was going on when they dialed a number and they couldn't hear anything (because the call was going out via the deskphone at the office).  Not only that, but we now had two separate phone systems to manage.

We tried CuciMOC and CuciLync as well. I remember saying that if CuciMOC could deliver on even half of what they were promising, then our integration problems would be solved.  Unfortunately, the end-user experience was so lacking that the project never went beyond the IT pilot phase.  Not only that, but the administrative burden involved in configuring and maintaining it was not something that the IT group wanted to deal with on a large scale.

Both projects died a well-deserved death, but the CIO has been demanding seamless connectivity between Cisco and OCS/Lync ever since.  It's interesting that people expect so much more from Microsoft than any other vendor.  I don't think I've ever heard anyone demanding that Cisco and Avaya integrate with each other.  Why should Microsoft get such different treatment?

Unfortunately, when we are dealing with two COMPETING vendors like Cisco and Microsoft, there will never be the sort of tight integration that will allow companies to both leverage their existing investment AND take full advantage of the UC capabilities of Lync.  Each vendor has their own very good reasons to push the benefits of their own particular solution.  Companies need to stop trying to get the best of both worlds and fully invest in either one or the other solution, not both.

I truly believe that Lync is the best and most cost-effective unified communications solution out there.  No other vendor has the same level of product functionality built into the base product as Lync.  Companies can get IM, presence, video/audio conferencing, whiteboarding, application/desktop sharing and Enterprise Voice with as little as ONE server.  Of course, high availability requirements and larger deployments do require more servers, but it does serve to illustrate what is possible with just one server.  Add ONE more server for seamless external connectivity with other companies and remote users.  Lync can provide companies with the sort of unified communications their users desire, but sadly even with my best pre-sales pitch, I can't convince everyone.

We are in the early days of a true revolution in communications.  Its natural to be resistant to the big changes necessary to put the pieces in place.  However, once the switch is made, it will pay dividends in terms of ease-of-communications, cost and flexibility.


Wednesday, November 9, 2011

Dialing Rule Optimizer Now Does Extensions

I've been keeping myself busy lately with updates to the Lync Dialing Rule Optimizer.  If you've been keeping track, you may have noticed the numerous improvements lately, including new options for adding Call Park and Premium Number Blocking.

There have also been numerous little changes to the website over the past few months, like:

  • Minor change to the Lync rule naming convention to include the NPA/NXX for companies that have multiple Lync sites in the same city.  So, instead of rules like NA-ON-Toronto-National, you get NA-ON-Toronto-416555-National.   
  • Website interface change to include warning if Javascript isn't enabled.  The webpage relies on Javascript for proper functionality, but users might not notice when creating basic rules.  This can lead to all sorts of weird behaviour, so I added a big WARNING: JAVASCRIPT NOT DETECTED! right in the middle of the screen when it doesn't detect Javascript.
  • Detailed help for every option
  • Rule tweaks to fix some recently found issues

I am now proud to unveil the latest iteration of the Lync Dialing Rule Optimizer (v7.0).  You now have the option to include dialing rules for local extensions.  This is useful for companies that connect Lync to an existing PBX and want to maintain extension dialing for their Lync users.  It can also be used to allow Lync users in a purely Lync environment to dial each other by extension number, which is especially useful to help users transition from a legacy PBX environment where they were used to dialing each other by their extension.

The new option is visible for Lync users in all countries, as shown below:

When you select the checkbox, it will show an Edit Extensions button.  Clicking it will bring up the Extension Entry screen...

Add up to 10 extension ranges and the associated PBX main office number, in e.164 format.  The program will create normalization rules, routes and outbound translation rules to make sure that when a Lync user dials an extension, it will route to the PBX.

I've also cleaned up the .PS1 script so that when you run it, it will provide concise and useful information about what it's doing, rather than the flying stream of output it used to do.  It will also prompt for an application pool to apply call park/block rules, if it detects more than one in a site.

Try it out, and as always, be careful when applying to an existing Lync site.  The script is designed to work in a new, blank site.

If you find issues or have ideas for improvement, please let me know.

Monday, November 7, 2011

Migrating PBX Users to Lync Enterprise Voice

In 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 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.  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:
E.164 Formatting
Normalization
Usages and Routes
Extensions