Everyone recognizes that flexible multimodal communications supported by UC will still require efficient consolidation and management of network access. Given that the market is still migrating from legacy TDM telephony networks and the PSTN, what solutions are available for bridging the network gaps at the enterprise or service provider levels?
Migrating Enterprise Telephony Networks for Microsoft’s Lync UC
By Art Rosenberg
Microsoft’s launch of its Lync Server 2010 on November 17, 2010 will trigger great enterprise IT activity in UC implementation planning. In addition to the basic enterprise Lync Server, Microsoft has also developed a Survivable Branch Appliance (SBA) for Lync, which will enable a branch location to continue using Lync capabilities if disconnected from the enterprise network.
While operational business benefits of multimodal unified communications (UC) can be identified through specific operational “use cases” of an enterprise, the migration from existing TDM and PSTN network infrastructures to IP Telephony and SIP trunking infrastructure must also be carefully planned from an implementation and maintenance cost perspective. Accordingly, UCStrategies.com will be hosting a new forum to discuss real-world issues that enterprise organizations should consider in implementing IP Telephony networking in a centralized and virtual UC network environment.
While IP Telephony will still be location-based in terms of desktop equipment and network connectivity, management and control will move to network and software-based solutions. This will include not only traditional person-to-person communication applications (phone calls, messaging, IM, conferencing, etc.), but also integration of third-party business process applications communicating with individual end users at desktops and mobile endpoint devices (smartphones, tablets, iPads, etc.) under the label of Communications Enabled Business processing (CEBP).
Integrating Tomorrow’s Telephony For “Multimodal” UC
The telecom industry has had a hard time explaining the concept and benefits of “UC,” primarily because telephony is no longer the only or even primary mode of communication contact with people. This is especially true for wireless mobility, where individual end users will dynamically require the flexibility of multimodal communications to efficiently communicate under a variety of personal circumstances. Even for employees dedicated to handling customer contacts (call centers), the need for UC flexibility will still be generated by mobile customers and business partners.
As the big enterprise application players move into UC, i.e., Microsoft, IBM, etc., they are driving the need for new telephony integrations and media mediation that legacy phone systems didn’t deal with. Accordingly, enterprise network infrastructures will be faced with the need to accommodate such functionality with technology that is both cost-efficient and easily operational manageable. The traditional approach of “gateways” to handle diverse network interconnectivity has been expanded to incorporate more intelligent functionality and simplified, software-based, remote “virtual” management.
The Application “Eggs” Or The Network “Chickens?”
There has always been a question of anticipating network capacity requirements to support communication traffic. In a UC environment, where modalities can be dynamically changed or escalated from asynchronous messaging to real-time connections for voice or video (“click-to-call”) the problem becomes greater and requires the flexibility that IP communications supports. So, getting the enterprise networks ready for multimodal UC and CEBP will demand that IT be well prepared with a cost-effective network solution to support such flexibility.
Inasmuch as UC technologies are still evolving and not all the standards have been defined, there is little experience available within most enterprise IT departments to provide practical guidelines for UC migration implementations. That is why the industry technology providers are trying to reach out to IT management to help them understand the implementation and support needs of UC vs. traditional telephony systems. They are absolutely not the same!
So, while business management has to define their operational UC “use cases” and ROI priorities, in terms of identifying what communication modalities and applications are required by which end users and end point devices, IT’s responsibility is to take care of associated network connectivity needs between branch locations, the PSTN (which is not going away overnight), and the Internet.
Stay Tuned For Our Forum on UC Networking Migration Issues
The latter need will be the focus of the UCStrategies Forum, sponsored by NET, who has announced a new platform for simplifying the networking and mediation needs of existing telephony switches and new UC platforms like Microsoft’s Lync Server 2010 and Survivable Branch Appliance, that can interoperate or even replace legacy or IP PBX systems. The UC migration dilemma is complex and every enterprise organization has investments to protect or maximize in implementation planning.
To be notified by email when a new issue has been raised and/or answered, please sign up for our UC Alerts, which will give you a direct link to that item.
This from Alec Spyrou 11/18/2010 5:58:57 PM
As with many others this has been a challenge for us for some time. How do we ensure that we have some control over the bandwidth used from multiple endpoints that are now mobile capable?
I would appreciate hearing from the folk on here.
Some background. We are well progressed in what we have called our Collaboration strategy. This started back in 2007 and we saw UC as just one of te latter parts of that collaboration strategy which encompassed Web, real-time, message based and UC leading into CEBP.
We are well progressed on that journey and are in the latter phases of message based (90% complete), realtime (75% complete) and UC (70% complete). These are the platform building phases that lead us to CEBP. We have voicemail and video conferencing left to complete in the platform building phase before we move into CEBP. CEBP will need a lot of prep work before we are ready to deploy in this phase.
There are a few questions here:
Can I carry SIP/RTP all the way to the service provider network edge without a gateway?
When the Mediation Server was first conceived (2005), there was a significant gap between the abilities of most PBXs/VoIP Gateways and OCS: e.g. few vendors supported TCP as a SIP transport, much less TLS, which is the preferred OCS SIP transport. A fuller explanation can be found here. Many gateway vendors have closed these gaps and Lync now provides 'media bypass' for calls being placed from inside the corporate network that are now carried on G.7xx codecs: this obviates the need to transcode to RT Audio (however, note that roaming calls still need RT Audio). Therefore with Lync, Mediation Server is only required for PBX interoperability and for some gateway signaling intermediation and to provide a 'trust boundary' to which the Lync client can securely connect.
Some VoIP Gateways have gone a long way towards replacing the Mediation Server (see above). Survivable Branch Appliance gateways actually have a Mediation Server on board. Note that the Mediation Server image is included with the Lync FE server, so you save deploying a box but get the capabilities of the software when you need it. Also note that for PBX systems that have been verified in the Open Interoperability Program, there is no need for a Gateway, but a Mediation Server is required.
The same benefits of any centralized resource vs. a local one. Note that if transcoding is required (i.e. a telephony to Lync call where the Lync call leg is 'roaming' [e.g. working at home]) then the Mediation Server must be co-located with the Gateway. If the Gateway is a central resource, then Mediation Server can also be centralized. However, if the Gateway is a distributed resource (e.g. branch office based in a 'least cost routing' scheme) then Mediation Server must be local: this can be achieved with a Survivable Branch Appliance in most cases.
Any Service Provider SIP Trunk that is certified in the Open Interoperability Program does not need a gateway. Otherwise, the Gateway will be required due to the interoperablity challenges that are encountered with many SIP Trunk services.