IP telephony and unified communications (UC) suites enjoy a high level of integration with enterprise applications...
and connectivity to remote locations. But with this level of accessibility comes the risk associated with putting anything on the open network, exposing enterprise communications to denial of service (DoS) attacks or potentially allowing hackers to gain access to the organization's core communications. Session border controllers (SBCs) serve as the traffic cop for IP telephony and other communications traffic. SBC hardware appliances or software allow valid communications sessions to enter or leave the enterprise, insulating the UC environment from hacking attempts and providing the signaling protocol translation between two telephony systems.
Session border controllers in enterprise communications
In a typical enterprise deployment, a session border controller would be deployed at the network edge to connect to carrier voice service into the network. Unlike IP telephony gateways, SBCs are focused solely on IP traffic and do not interface with circuit-based telephony services, such as PSTN, although a number of telephony vendors have introduced products that roll both functions into a single standalone appliance.
The SBC will identify the traffic between the enterprise and carrier service, allowing only authorized sessions to pass through. Additionally, the session border controller defines and monitors the quality of service (QoS) status for all sessions, ensuring that the callers can actually communicate with each other and that emergency calls are delivered correctly and prioritized above all other calls.
Session border controllers play their role in IP telephony security
For security reasons, session border controllers are likely to be deployed on both the carrier and enterprise side of the connection. In both cases, the SBC will likely utilize network address translation (NAT). Similar to consumer broadband routers, NAT only exposes the external network interface to the outside world, redirecting packets to the appropriate system by changing the IP address destination to match the internal network. With this minimal exposure, both the enterprise and service provider can keep the prying eyes of hackers or curious network administrators at bay.
Beyond obscuring the internal networks of the enterprise customer and service providers, the NAT interface also directs IP telephony traffic to the session border controller rather than the normal traffic routers on the IP network. This allows the SBC to serve as the firewall for session traffic, applying its own QoS rules and identifying specific incoming threats to the communications environment. Most session border controllers offer monitoring and reporting services to alert network administrators of attempted accesses of their IP telephony solution.
Session border controllers and interoperability
The telephony market has historically struggled with interoperability between vendor systems. Whether the result of standalone PBXs as single-source solutions or the relative immaturity and rapid evolution of IP telephony standards, interconnection of two telephony solutions is rarely a given. To aid in interoperability, session border controllers can be deployed as a translator between incompatible systems.
Session border controllers are designed to support the nuances of various signaling protocols, making them the choice to link two telephony platforms that cannot natively communicate with one another. By residing between the two, a session border controller essentially takes control of the IP packet stream, modifying the protocol packets, fixing known compatibility problems and even changing the codec used to send the media stream in a way that will correspond with the requirements of the intended target. The role of session border controllers will also likely continue to evolve as new communications services, such as video conferencing, make their way into more enterprises and as organizations work to bring those services into their overall unified communications platform.
Session border controllers and regulatory compliance
The session border controller actually serves a number of support roles in helping enterprises comply with certain regulations. The first is in E911 calling, enabling users to quickly contact emergency services in the event of a problem. With its control over the quality of service for IP telephony traffic, an SBC can identify and prioritize emergency dialing, making sure that the user making the call gets through, no matter what other traffic may be on the network at the time. With a combination of dial plans and location information, a session border controller will direct an emergency call to the nearest Public Safety Answering Point (PSAP). Likewise, because the SBC sets the prioritization and ultimately the acceptance or rejection of telephony sessions, it could interrupt a video conference to make room for the emergency call to go through.
Beyond just making sure that calls go through, a session border controller actually serves on both sides of privacy compliance. For the health industry, for example, HIPAA compliance demands a level of customer privacy in regards to their health. Retailers need similar privacy awareness to achieve PCI DSS compliance. Ensuring the privacy of callers can be further complicated as many enterprises have either outsourced call centers or are enabling customer service representatives to work from home. Session border controllers encrypt session traffic from the network edge to the remote endpoints, ensuring that patients can give their Social Security or credit card numbers over the phone to call center agents without the risk of that call being intercepted, even if the connection is made over public networks.
Conversely, as the traffic cop for communications, the session border controller exists at the edge of the network, making it the logical place for lawful interception by law enforcement personnel. Internal quality control and training processes may require a way to screen and record calls. A number of industries may also have some specific requirements to track relevant conversations for e-discovery and compliance purposes.