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
That's so far the best documented argument to show Lync as an alternative to the PBX.
ReplyDeleteEven if you compared with a unique solution from the competition it would be complex.
Some manufactures create plugins to show integration with Lync, but it's becoming more a more visible to customers: "Why do I have to pay for two voice products?"
The number of questions "Can I use Lync as the only phone system?" is increasing, and your posts are helping that ;)
We are looking at a VPN conundrum that hits close to your post: how do you define split tunnel rules that allow 99% of PC traffic to go in the VPN tunnel, but allow Lync traffic to go straight to the Edge. Voice, video and desktop sharing fall apart when forced through our current VPN software on the remote desktop.
ReplyDeleteTrapperB, split tunnel is a common solution. I have a script somewhere of simple Windows 7 Firewall rules to enable the relevant media to bypass the VPN, nothing fancy really. In addition, we increasingly see customers use DirectAccess.
ReplyDeleteThis is a very nice post however it does not represent the entire truth about API integrations that Microsoft promotes. As an example, in the MS Lync architecture the 3rd party gateways typically needed (AudioCodes, .net, etc.) are not reflected which basically acts as Lync’s voice PBX gateway (similar to a traditional PBX). Remember that any relatively new voice solution (Avaya, Cisco, Microsoft, etc.) all have a Voice Server and typically a Media Gateway. They all have presence/federation, conferencing, video, soft clients, mobility, CEBP and other features. They all run SIP but also maintain backward compatibility with H.323, TDM and other legacy protocols (which shouldn’t be a bad thing in the case of investment protection or selective distance requirements).
ReplyDeleteThe value for Direct SIP integration is if you have made the decision to migrate from an existing voice system to a full Lync (“full” meaning Lync desktop with E-CALs and those Gateways with Plus CALs) and need a “temporary” integration during a phased migration. The problem with this long term is that you will have to manage two systems instead of one (routing tables, extensions, etc). Your end users could have two phone numbers instead of one. The existing telephone may not show presence status to the rest of the enterprise and you may not be able to switch between your existing telephone and Lync soft phone easily. End users may be confused on when to use their Lync soft client versus their existing telephone. All these issues go away with API integration for most platforms.
Some other considerations to understand on the value of Microsoft’s API integration with Lync include:
• VPNLess Access – Yes, the standard is an SBC (Session Border Controller) which is preferred over the proprietary MS Edge server. (Avaya ACE supports in 6.2).
• Federation Support – Yes, they support standards based Federation. (Avaya, Cisco, etc.)
• Communications Enabled Business Processes (CEBP) – Yes, most support CEBP (Avaya, Cisco, etc.)
• Video Support – Yes, they have their own. (Avaya ACE supports Lync Video in 6.2)
• E911 Support – Yes, they have had this since before Lync/OCS was in existence. (Avaya, Cisco, etc.)
• Dynamic Bandwidth – Yes, they have had several bandwidth features for years. (Avaya, Cisco, etc.)
• Audio Conferencing – Yes, they have their own or can integrate with Lync Conferencing. (Avaya ACE can do both)
• Media Encryption – Yes, Avaya can encrypt all portions when using standards based encryption.
• Reliability – Yes, if the Lync servers go down, the core voice (Avaya ACE example) still provides up to 99.999 uptime for dial tone in Avaya’s case.
For the Avaya ACE (API) integration with Lync, think of it as the link to enable the Avaya core voice functionality with the Lync Desktop features (instead of deploying AudioCodes Gateways, etc.). Like explained previously, all newer voice solutions have basically the same components.
Don’t get me wrong, Microsoft Lync is a fantastic solution and a great option for totally new deployments. But sometimes it makes sense to leverage the best-of-breed approach if you already have an investment in a core voice solution.
Hi Anon,
DeleteYou seem to be addressing a completely different post which I have posted below incase people are confused. I suggest anyone reading this comment please take a look at the post below along with the 65 comments addressed within it.
http://voipnorm.blogspot.com/2011/11/what-avaya-arent-telling-you-about-ace.html
Direct SIP is the most common way I currently see companies doing interoperability today. I see less and less companies willing to add complexity at the desktop and instead choose to take the direct SIP path even if they don't plan to replace the PBX because the complexity you tried to convey isn't true. In fact the integration at the desktop is typically seen as the more complex of the two since now instead of one back end integration you add it to every desktop.
While direct SIP may not provide desk phone presence what most companies are beginning to realize is that the cost and complexity of desk phone presence isn't worth the complexity of a plugin when doing interoperability between two platforms. Even after trialing plugins against native I have yet to see a company side with the plugin but instead are siding with direct SIP because of the limitations and complexities I have described in this post. After having worked on large scale desktop deployments deploying plugins to any application is typically not a well liked experience for any company. Although its sometimes unavoidable to get the features a company wants in this case its avoidable and the interoperability can be kept to the backend which is seamless to the user.
If people are interested in trialing a Lync plugin, I would suggest doing both plugin and native and comparing the experience fo both. I know that's what I did when I worked as an engineer at a global company and found the plugin experience less than favorable which is why we went with native features.