Microsoft Communicator Native Versus Integrated Part 1: Server Versus Client Side Telephony Integration

I am hoping this makes an interesting read, and gives some food for thought. This particular post is describing all third party Microsoft Office Communicator plugin applications that aim to remove native functionality from Office Communicator and replace it with their own. Often this is to avoid paying for the E-Cal but more often than not you are losing much more than just telephony by dropping down to the Standard-cal. 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.

The published API’s have opened up OCS and OC to the developer world and allowed developers to extend the value of OCS. Even the development of the third party applications for VoIP are indeed proof of the flexibility OCS 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 VoIP more complex than native OC features?

Let’s take a look at the third party application for VoIP integration…



Products and features in diagram
Office Communicator – IM and presence
Integrated softphone/video -Telephony and video (if available)

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 as per the 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 Communicator or another application.

So this presents an interesting scenario but what if we compare this to Enterprise voice. To be fair the next diagram shows Microsoft Communicator and non-native remote call control integration to show a complete feature comparison as some third party VoIP plugins do offer this capability. Rather than enable these features as desktop integration how does it compare to server side integration.

Office Communicator enabled for Enterprise Voice with Remote Call Control of an IP Phone…



Products and features in diagram

Office Communicator - IM, Presence, Video Telephony and RCC client
CSTA Gateway – CSTA to CTI conversion
IP phone- Telephony and RCC endpoint

Even though this does add to the manageability of the solution with some work being required to get the SIP/CSTA Gateway to work, it is still a simpler solution than our first diagram. This is because there is no desktop integration. All integration is being done server side for both enterprise voice and RCC. By leveraging SIP/CSTA OCS now has the capability to control a PBX phone with the help of a CSTA Gateway.

Breaking down each of the components by numbers..

1) SIP/TLS encrypted signaling
2) SIP/CSTA – protocol used to talk to traditional or IP PBX’s for Remote call control
3) Direct SIP Trunk to IP PBX/Soft switch much like any traditional tie trunk between two PBX’s to enable enterprise voice PSTN calls
4) CTI conversion completed by SIP/CSTA Gateway for click to call
5) SIP signaling to the IP phone
6) RTP/Audio – RTP media stream. In this case audio only. I have included it this last slide to show how the RTP streams would flow between the two scenarios while both enabled. This shows that even with both these technologies deployed the RTP stream is no different from the straight EV integration to a PBX. We have just layered on RCC server side integration.

The main down side of Remote Call Control is it is a lot of work with added server and licensing costs by the SIP/CSTA gateway vendor, this makes proving an ROI for this feature much harder. By including the softphone capability of OC with RCC we now have the potential of enabling remote workers and improved OCS A/V conferencing experience without being tied to the desktop phone. The setup is fairly clean just by looking at the diagram even with Enterprise Voice still available via a direct SIP trunk. I would certainly recommend deploying enterprise voice if you are going to deploy RCC so users are able to choose which system to use as their telephony device. This also allows the advantage of remote user scenarios when enterprise voice is deployed without the need for a VPN solution which third party integrations would require as they are not support by OCS edge and similarly do not generally have an edge solution of their own except for VPN.

Next is Office Communicator and OC Phone edition…



Products and features in diagram

Communicator – IM and presence, video, telephony and Phone control with OC phone Edition
OC Phone Edition – Telephony, presence and phone control endpoint

In this diagram I have included Phone Control as a feature with the OC Phone edition (or Tanjay). I wanted to present the complete Microsoft native solution. I have not included dual call forking (in the true OIP sense). Using OCS simultaneous ring to ring additional phones is supported but there is no additional signaling paths than what has been described. Whether it is a PBX IP phone or cell phone it really doesn’t matter both function in the same manner when passing signaling through a direct SIP trunk deployment.

So stepping through each point:

1) SIP TLS encrypted call signaling when using Office Communicator for IM, Presence , Voice and video
2) SIP TLS encrypted call signaling OC 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 OC Phone Edition device with Office Communicator

Things are significantly different between the three diagrams. This diagram presents a clearly server side integration. Using the SIP trunk between the two systems now allows Office Communicator to be used as softphone. This removes the burden from desktop administration of the integration displayed in the third party application for VoIP diagram. Even with including Phone Control in the native solution 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 Office Communicator features to avoid end user confusion.

In conclusion, when you break down each scenario you begin to see how OCS Enterprise Voice can simplify the desktop environment. Adding RCC in conjunction with Enterprise Voice does enable a user to control a PBX phone with Communicator but does add complexity which may have a low ROI for RCC. Third party applications for VoIP add more complexity at the desktop which in the end could affect security, manageability, upgrade roadmaps and ROI especially in large organizations. Finally, OCS enterprise voice with native phone control has the potential to simplify and secure both audio, signaling and phone control natively without complex integrations.

This post, besides being quite lenthy, has really focused in on Voice scenarios but there is more that make up the complete MS UC experience. Look for more comparison posts coming soon. Please feel free to comment.