Microsoft Lync arguably supports the largest number of interoperability scenarios of any leading unified communications platform. I say this because unlike, for example, Cisco, Microsoft relies solely on third parties to provide headsets, IP phones and gateways that are compatible with Lync.
Literally hundreds of devices have been certified to interoperate with Lync 2010 and 2013. A complete list is available at www.technet.com/ucoip. At last count, there were upwards of 30 different wired and wireless phone sets compatible with Lync; 8 specific video endpoints; multiple video infrastructure bridges; 20+ PSTN/PBX gateways; 10+ survivable branch appliances (SBAs); 20 session border controllers (SBCs); and countless Lync-compatible headsets (both wired and wireless).
In addition to devices that are certified to work with a complete Microsoft Lync voice and UC solution, there are several supported ways to integrate Lync with an existing PBX (aka legacy voice system):
1. Side-by-side interoperability (no integration)
2. PSTN interoperability
3. Direct SIP interoperability
4. Remote call control (RCC) interoperability
Side-by-side Interoperability
Many times, Lync is first installed and used to provide instant messaging and presence services. Lync works side-by-side with the existing telephony environment. Eventually people discover that Lync allows peer-to-peer voice, video and desktop sharing whether they are in the office or working remotely. For internal users, Lync can become an alternative communication channel that can be used in ways the legacy phone system cannot.
Of course, with this simple side by side interoperability--which is really a choice not to integrate--Lync cannot place calls to or receive calls from regular phones; in this case, Lync can only be used to connect calls between internal users (or "federated" users...which will be explored in the next "Living with Lync" article.)
PSTN Interoperability
Sometimes side-by-side integrations grow so that a separate PSTN connection is added into the Lync environment. This can be done most easily by arranging a Lync-certified SIP trunk from a telco provider and connecting this SIP trunk either directly to the Lync mediation server, or by connecting the SIP trunk to an SBC (session border controller), which is in turn connected to the mediation server. In this case, new DIDs are acquired and assigned to the Lync users.
With Lync connected separately to the PSTN and using a separate range of DIDs, you now really have two complete voice systems in your organization. This can work perfectly fine, especially if different locations are serviced by the different phone systems. The two phone systems have what I call "PSTN integration"--that is, they are connected and can call one another via the PSTN, the same way most organizations today are "connected" to other organizations. (Of course, for "federated" organizations using Lync there is a much-improved interoperability, another topic for my next article.)
Direct SIP
As opposed to connecting Lync directly to the PSTN through a new separate connection, alternatively Lync can be connected to the PSTN "through" the existing voice system. Most often this involves establishing an internal Direct SIP (or similar) connection between Lync (sometimes through a gateway) to the existing voice system.
Outbound calls are routed from Lync to the legacy voice system and then to the PSTN through the existing PRIs connected to the legacy voice system. New DIDs could be assigned to Lync users or endpoints and routed through the legacy voice system to Lync; or unique extensions could be assigned to unique accounts and then the legacy PBX could be set to simultaneously ring (or fork) inbound calls to both the regular phone and the Lync account.
In this scenario, in addition to allowing Lync users to place and receive calls, when you connect Lync to an existing voice system you can now take advantage of Lync's ability to act as an audio conferencing bridge.
The disadvantage with this type of interoperability is that users may end up with two separate voice endpoints, their legacy phone and their Lync endpoint. This can lead to user experience confusion and might result in other issues such as needing two separate voice mail systems.
This type of integration approach tends to work best when users either use Lync for voice or use the legacy phone system for voice. One customer of mine successfully used this strategy to quickly deploy voice services in a new office facility; all the users in the new building were given only Lync as their "phone". This also works well if you have home-based workers; because Lync has very strong remote user support, it is a good solution for home-based workers.
Remote Call Control
Remote call control (RCC) is different. RCC scenarios enable users to control their PBX phones by using Lync on their desktop computers. While the specific RCC features available depend on your PBX, typically from Lync you can click to make a call (your legacy desk phone rings when the connection is made); click to answer a call (on your legacy phone); place calls on hold; answer a call with an instant message; forward an incoming call; and transfer a call.
To be clear, with RCC the audio portion of the call is handled by the legacy PBX with Lync simply sending commands to the PBX. With RCC, Lync almost exclusively serves as an IM and presence tool; RCC does NOT provide any soft phone, remote worker or advanced Lync calling features such as audio conferencing, delegate handling, response groups (call queues) or team calling (hunt groups).
In the original days of OCS (Office Communications Server, the predecessor to Lync 2010 and Lync 2013) Microsoft embraced RCC, as few customers were ready to use OCS as a PBX replacement. Today Microsoft supports RCC only grudgingly, and has tried to deprecate this functionality several times. Because Lync is now capable of being a full PBX replacement, Microsoft is strongly suggesting that customers enable "Enterprise Voice" and phase out legacy voice systems.
Next Page: The Good, the Bad, and the Ugly
The Good, the Bad and the Ugly
Lync is a fine PBX replacement. This is a good solution for some organizations. Equally good is a side-by-side integration between Lync and existing PBXs, different locations being serviced by different voice solutions. Similarly, Direct SIP works, and works best when users have either traditional IP sets or Lync endpoints (and not both).
Remote call control is not always "bad," but more often than not it introduces "user experience" issues. Often organizations that pursue RCC have users who expect to be able to use Lync softphone functionality when remote or traveling, and this is not possible. Eventually Microsoft will deprecate RCC, so long term support for this type of integration may be problematic.
Now we come to the "ugly". However, before I proclaim an interoperability scenario as ugly, I do want to suggest that the saying, "Beauty is in the eye of the beholder", first uttered in 3rd century Greece, does have merit. Specific business requirements may make one of these desktop integration solutions a good match for an organization; but you need to proceed cautiously.
All of these interoperability scenarios are similar in that separate voice softphone applications "pretend" to be part of the Lync application by "bolting" themselves onto the bottom of the Lync application window. Cisco has CuciLync (left image), Mitel has MiVoice for Lync (right image) and Avaya has ACE for Lync (not shown).
While these are interesting technical solutions and perhaps brilliant marketing strategies to keep Lync restricted to only providing IM and presence, these solutions have a tendency to confuse users and complicate the user experience. Perhaps this is because they "attach" to Lync and pretend to be part of Lync while in reality all voice, video and conferencing services are provided by the non-Microsoft vendor application.
This typically causes several potential problems:
* Remote VPN-less connectivity provided by Lync is not available or may operate differently.
* Lync conferencing capabilities are not available.
* Team calling, delegate handling and other advanced Lync features work differently; each of the above vendors provides these capabilities, and in some cases they may be stronger than what is offered by Lync, but they are different and users can be confused.
* The detailed Monitor Server and Quality of Experience reporting provided by Lync is not available.
* You cannot use Lync IP endpoints such as the Polycom CX5000 or new Lync Room Systems.
* Media encryption may be handled differently (by default, Lync encrypts all media and signalling; not all UC solutions do the same.)
* Directory lookups work differently (this is illustrated clearly in the Mitel screenshot where there are in fact two separate search boxes, one at the top provided by Lync and one at the bottom provided by the Mitel app.)
In a given case, none of the above items may matter. However, in my experience, IT professionals trying to select a solution do not fully understand the impact of these items and thus end up at best with "expectation gap" issues and at worst with a solution that does not work reliably in their environment. I would strongly recommend that any desktop integration with Lync, such as these, be fully pilot tested both from a technical perspective and from a user experience perspective (and make sure you involve non-IT users).
Concluding Remarks
In theory, interoperability is great. In reality, involving the fewest number of vendors in a solution that meets your needs is the best path to success.
Lync has "grown up". If you plan to "live with" someone then perhaps Lync is the voice and UC solution that is best aligned with your business objectives. If for some reason Lync does not meet your needs, you can look at interoperability scenarios, but some scenarios are more "pain" than "gain," and so you might also want to look at the complete "solution stack" from another vendor. In the current market, no UC solution is without fault; the trick is to choose the solution, single vendor or multi-vendor, which is best aligned to your specific needs.
Previous Living with Lync Articles:
In part 1 of this series I suggested rules that can help make living with Lync more rewarding.
In part 2, I explored three areas people can run into trouble when deploying Lync.
In part 3, I looked at opportunities and challenges in using Lync for switchboard and reception functions.
And in Living with Lync: Lessons Learned I recapped the lessons shared by the panel from Enterprise Connect.
Have you had success or failure in getting Lync to interoperate with other systems and applications? Share your experiences in the comments or below or via twitter @kkieller.
Follow Kevin Kieller on Twitter and Google+!
@kkieller
Kevin Kieller on Google+
