By Pierre-Jean Chalon, Vice President and General Manager, APAC, Sonus Networks
The problem with the business case for unified communications
The push to adopt a Unified communications (UC) solution is often driven by the combined desires for increased productivity both within the office and while mobile, and anticipated cost savings – especially in the area of conferencing. However, CIOs can struggle to build the business case for UC investment – there is pressure to ‘sweat’ current assets and, when competing for funding against customer-facing IT projects, UC projects can often falter before the Board. And, even when the project is approved, there are potential stumbling blocks – does the IT team have the necessary skills to implement and support a UC solution? How will legacy system assets be ‘sweated’?
The key to building a compelling business case for UC needs to focus on the ability to migrate to a UC system – where integration and interoperability of legacy systems are the hub of the plan, so no existing functionality is lost and everyone, from the users to the IT teams, are given time to learn and change. The problem with a migration strategy is that most enterprises have a complex array of infrastructure and software – the result of acquisitions and de-centralized IT models – and many branch offices find themselves on entirely separate systems altogether to those of the corporate organisation. In fact, research has shown that 66% of enterprises are managing a multi- vendor network environment, and 29% have more than 5 vendors – this can make the move to UC entirely too complex.
The role of SBCs in unified communications
Session Border Controllers (SBCs) can remove the complexity of UC by overlaying existing networks and integrating disparate systems enabling the seamless combination of the best-of- breed solutions available today and in the future.
Such an approach allows enterprises to create new communication and collaboration opportunities at minimal risk and disruption at a pace that suits them.
SBCs sit at the border of the enterprise between the internal voice network and the SIP Trunk service or VoIP of the ISP or legacy IP telephony infrastructure. SBCs provide a variety of functions, including:
• Gatekeeping: SBCs look at each SIP packet crossing between a network and the external ISP network, determining what should be allowed through and routing it correctly. They are security guardian and policy enforcers to your communications.
• Interworking: SBCs allow SIP systems to communicate even if there are slight variants with the version of SIP being used. ‘SIP normalization’ is where an SBC modifies different variants in the packets so both ends of the call understand each other. Translating is where an SBC modifies the bit-rate of a call to accommodate different devices.
• Transcoding is used for digitizing and transmitting calls by translating the codecs in real- time.
Improving the business case for UC using SBCs
For any CIO looking to build their business case for a UC implementation, an SBC must be considered part of the solution. We recommend using the following arguments:
• SBCs integrate with existing IP-PBX platforms: For enterprises looking to protect legacy investments, SBCs play a vital intermediation between UC voice platforms and existing IP-PBX systems. SIP normalization allows a smooth integration between the voice network and the IP PBX. For enterprises with a disparate IP-PBX base including equipment from multiple vendors, the SBC is able to normalize, transcode and transate the various SIP variations. This ensures calls are routed correctly with the most efficient use of the network at the lowest cost.
• SBCs ensure QoS: Particularly with voice communications, it is vital that sound quality is not degraded and there is no delay on the line when people are trying to communicate. SBCs can decide which calls can be allowed at what time to keep the network running smoothly during busy periods and monitor the network’s health in terms of latency, jitter and other metrics.
• SBCs secure communications at every stage: Denial-of-Service attacks, caller ID spoofing, toll fraud, attempts to steal secrets – all of these things should be considered when deploying UC. An SBC should be able to provide Denial of Service (and Distributed Denial of Service) prevention, topology hiding, rogue RTP encryption, media encryption, signalling encryption, NAT traversal – everything you need at every stage.
