The published API’s have opened up Lync and Lync Server to the developer world and allowed developers to extend the value of Lync. Even the development of the third party applications for VoIP are indeed proof of the flexibility Lync provides as a development platform. But in the same vein replacing elements of native features even though it is possible can raise questions of the value of doing so.
“We believe that the native functionality in Office Communicator provides a much better and more complete user experience …… is a less complex and more cost-effective integration technique than adding additional software to every desktop”. BJ Haberkorn, OCS Senior Product Manager.
BJ makes some interesting comments but what’s really going on in the back ground that makes adding a third party application for telephony more complex than native Lync features?
This particular post is describing all third party Microsoft Lync plugin applications that aim to remove native functionality and replace it with their own. Often competitors pitch this as a way to avoid paying for E-Cal or Plus Cal but you are losing much more than just telephony by dropping down to Standard-Cal licensing. When you look at UC platforms it’s important to consider what you are buying as a whole and not just one portion. Often when moving a portion of functionality to another system you are adding more complexity than first realized and in the long run more cost both in licensing and manageability.
Amidst the claims of lower costs and multiple dial plans, the end user experience when using the plugin is often overlooked. Native features are focused on bringing about the best user experience for a collaborative environment. Plugins on the other hand are by design focused on preserving legacy PBX systems where desktop usability and integration are secondary unless it is promoting other competitive services such as voicemail, conferencing or external web collaboration. Also, this often means deploying group policies or in extreme cases adding custom Active Directory attributes to get a plugin to register and function as desired adding to the complexity which its meant to be avoiding.
Third party application for telephony and video integration…
Versus
Native Lync telephony and video…
I wanted to paint a complete picture of what’s happening with this type of integration from a generic point of view. Depending on which vendor you choose the features may change somewhat and may even look more or less complex than is presented here. Remote call control has been omitted as most vendors are not providing it through this integration but through a separate CSTA gateway that is unrelated to the third party application for VoIP (see diagram 2). So from the top diagram:
1) LDAP information in some circumstance comes from direct integration from the client plugin.
2) SIP/TLS for IM and presence. Some vendors are recommending turning off all Communicator features other than IM and presence.
3) Call signaling flowing from the third party softphone integration to control call( either a soft switch or IP PBX)
4) API integration to pass presence and other desktop level integration
5) Video integration if available. This may or may not be the same application that provides telephony integration so it may require additional signaling depending on the manner in which it is deployed.
There is a lot going on in this diagram and most of it at the desktop. This is purely from separating out one service (telephony), two if you count video as well if it is supported by the plugin. If video is not supported then you are back to doing it with Microsoft Lync or another application. Most times though the vendor providing the plugin recommends disabling Lync voice and video even for peer to peer communications. Comparing the different end-user experiences with the plugin you will see various Lync menus greyed out and when using the plugin multiple windows for voice and video where with Lync you would see only one.
So stepping through each point for the native Lync experience:
1) SIP TLS encrypted call signaling when using Lync for IM, presence , voice and video.
2) SIP TLS encrypted call signaling Lync phone edition for voice and presence.
3) SIP Trunk to IP PBX or Soft switch much like any traditional tie trunk between two PBX’s.
4) SIP call signaling to the IP phone.
5) USB cable to enable Phone Control function of the Lync Phone Edition device with Lync 2010.
Things are significantly different between the two diagrams. The lower diagram presents a clearly server side integration. Using the SIP trunk between the two systems now allows Lync to be used as softphone. This removes the burden of desktop administration of the integration displayed in the third party application diagram. Even with including Phone Control in the native solution via tethering we have been able to greatly simplify not only the signaling required but also the deployment scenarios. Removing the second application from the desktop (third party softphone) has reduced software deployment dependencies and removed the need to disable native Lync features to avoid end user confusion.
Remote Access
In the first section I covered the basics of of a telephony plugin and how it interacts with Lync. In this second section I will present remote access and how the plugin changes the remote access options.
Third party application for telephony and video integration beyond the corporate firewall…
Versus
Native Lync telephony and video with remote access…
As you can see in the top diagram we are forced to run the third party VoIP application over either a hardware or software VPN separate from edge services that are available with Lync. We now have a more complex VPN setup having to spilt tunnel communication services and in some cases VPN services may not be designed to take large amounts of real time media traffic.
This setup also removes the use of RT Audio codec which is specifically designed for uncontrolled networks like the Internet to improve the user’s voice experience. With this setup they are more than likely only able to complete calls using G.711 or G.729 which are affected by network degradation of more than 1% whereas RTAudio will work acceptably with up to 10% packet loss.
Looking at the Lync native solution we begin to see some immediate benefits. First is an Edge specifically designed for real time communication traffic including voice, video, IM, presence and desktop sharing. The second point is that we no longer need to route media traffic back to our internal resources consuming vital Internet bandwidth when both users are remote to our internal network. If one of our users were internal the media would in fact flow through the Edge and not over a VPN service limiting reliance and lowering bandwidth consumption on VPN services. Lastly we have now removed the reliance on the desktop to complete our integration and instead have chosen interoperability at a server level.
Of course there are more reasons to enable edge services with Lync than just telephony. To me one of the most compelling reason to use the Edge has always been federation with business partners to better enable collaboration and lower communication costs.
Just to recap. Lync remote scenarios are designed to be secure and leverage the internet to allow peer to peer connections reducing bandwidth requirements and allowing Lync to scale to large enterprise needs. By removing the native functionality and replacing with a plugin not only have you increased desktop reliance but also made telephone dependent on VPN services to allow functionality. So when you consider what it takes to keep telephony control on a separate system through desktop integration there is much more to consider than just licensing and dial plans.
Comments welcomed.
VoIPNorm
