This is the second part in the series that focus’s in on voice capabilities and how removing native functionality from Microsoft Office Communicator can have an adverse effect on a deployment. This post I plan to discuss remote access scenarios. I think this really is a major differentiator between native and third party application for VoIP but enough of me waffling on let’s get to the first diagram.
Remote user scenario with third party application for VoIP integration…
Products and Features
Office Communicator – IM, Presence, desktop sharing
Third Party Application for VoIP – Telephony and video if available
As you can see in this 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 OCS. 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. I always think back to the classic example of where I live when it snows. When no one is capable of actually being on site and the VPN services are carrying a significant load now voice service may be effected even though data services may be working fine. Meanwhile services over the OCS access edge are unaffected due to having purpose built access on the perimeter. 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 like 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.
In some circumstance company’s do not allow the OCS edge forcing all services through a VPN. In this case using RTAudio which is native with Communicator would still be beneficial due to its ability to handle packet loss and jitter. From my own personal experience and also from talking with customers using more traditional codecs, i.e. G.711 and G.729, audio quality over VPN tends to suffer.
Remote worker with Native Communicator Features…
Products and Features
Office Communicator – IM, Presence, desktop sharing, voice and video
Looking at the native solution we begin to see some immediate benefits. First is an access 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 access 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 OCS than just telephony. To me 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. OCS remote scenarios are designed to be secure and leverage the internet to allow peer to peer connections reducing bandwidth requirements and allowing OCS 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.
Hopefully this has been an interesting series. Please feel free to post comments or email me your feedback. For more on this subject please check out the following post: