Last week we wrote about the Session Initiation Protocol (SIP), explaining how it’s a crucial underpinning of any Unified Communications (UC) rollout. In this post we’ll cover another crucial element, the Session Border Controller (SBC), which provides a number of important functions in a SIP-based network.
First and foremost is security, says Mykola Konrad, VP of Cloud and Strategic Alliances for Sonus Networks, Inc. SIP networks generally replace time-division multiplexed (TDM) networks, which are inherently secure because they’re difficult for outsiders to tap into. SIP is a different story, because it is fundamentally an IP network and is thus subject to all the same security issues as any other IP network.
Normally, you’d use a firewall to protect the network against unwanted intruders but they are ineffective on a SIP network. “A firewall can’t look and see the start and end of a session or a call,” Konrad says. “It doesn’t understand things like caller ID and the concept of sessions that exist for a short time and then disappear.”
SBCs, on the other hand, do understand the intricacies of SIP and are able to open up pathways for legitimate calls to go through, then close them down the instant the call ends. “SBCs guard the border,” he says, just as firewalls do for data networks. SBCs can also perform encryption, he notes, such as for sensitive voice or video calls that traverse the PSTN.
SBCs: Key to Interworking and Migration
Interworking is another important function that SBCs provide, which means translating between various SIP “dialects. ”The issue is the SIP equipment you have in your network, such as a router or PBX, may not implement the protocol in exactly the same way as the carrier that provides your SIP trunks,” Konrad says. The SBC provides a translation, essentially, that enables the two to effectively communicate with one another. That can apply equally to voice calls as well as video, such as in instances where you want to tie in someone outside the company to a video call and need to communicate with that person via the Internet.
When a call comes in to the enterprise, a decision has to be made on where to route it – to the legacy PBX or the Lync servers. One way to do that is to manually configure each PBX, detailing the extensions it supports – and then try to keep up with all the changes. An easier way is to have an SBC do a directory lookup, using Microsoft Active Directory in the Lync example, to determine whether the call is destined for the Lync environment; if not, it goes to the legacy PBX.
SBC Transcoding Enables Integration of Legacy and UC SystemsFinally, an SBC performs transcoding to enable legacy equipment to integrate with UC systems. For example, say you implement UC in your call center, with an existing interactive voice response (IVR) unit. You still need callers to be able to use their touch-tone phones to enter responses to the IVR unit. An SBC can translate the DTMF tones from the touch-tone phones to their SIP equivalent and present them to the IVR, Konrad says.
Similarly, internally a company may use G.729 coding to compress voice on its network, to conserve bandwidth. But when calls go to the PSTN, the carrier may only accept G.711 coding. Here again, the SBC can perform the translation, enabling the compressed call to go through with good quality.
Those are just a few of the examples of where an SBC plays a crucial role in a UC network. “There’s this UC ocean out there,” Konrad says. “As enterprises start plunging in, they need to take care of all these things so they can swim and not sink.”