Living with Lync Part 4: Interoperability
A range of scenarios is available for making Lync work alongside, or together with, the other elements of your communications architecture.
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
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.)
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.)
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