PBX Software Plugin

The final end-user scenario is one in which the PBX vendor uses the Lync client APIs to develop add-on software for the desktop to integrate with Lync. Examples of this are Cisco’s UC Integration for Microsoft Lync (CUCILYNC) and Avaya’s Application Enablement Server (AES) products, which must be installed and managed separately from the Lync client.

These solutions might seem appealing to organizations with an existing investment in telephony platforms that offer these options, but these plugins can introduce a layer of complexity in troubleshooting any voice issues. These actually remove the Enterprise Voice functionality and instead use their own software shims to control the voice features. Call signaling flows through the PBX and the client’s audio or video traffic uses the PBX’s configuration and not Lync’s dynamic media stack, like shown in Figure 17.14. Instead of seeing the native call controls provided by Lync, users will see a UI developed by the PBX vendor, which could be a point of confusion for end users. These solutions also don’t work through the Lync Edge server and require a user to connect a VPN client before signing in through Lync remotely.

Figure 17.14. Lync software plugin traffic flow.

The main difference with these solutions over Remote Call Control is that the presence and phone control features are client-side as opposed to server-side. Instead of Lync Server integrating with a PBX for presence updates and phone control, the software plugin handles the call control and updating the user’s presence, meaning no CSTA gateway is required. The confusing end-user experience is the biggest downside, but keep in mind that organizations using this approach are now at the mercy of a PBX vendor for approving any upgrades to both Lync clients and the plugin software. The last point here is to consider how many resources and how much time a PBX vendor really wants to invest in working on improving integration with a competitor’s product.