The VoIP Peering Puzzle�Part 22: Session Border Controller Architecture

By Mark A. Miller | Mar 28, 2007 | Print this Page
http://www.enterprisenetworkingplanet.com/unified_communications/The-VoIP-Peering-Puzzle151Part-22-Session-Border-Controller-Architecture-3668336.htm

Thus far in our study of VoIP peering, we have considered some of the technical issues, such as the SPEERMINT peering standards developed by the Internet Engineering Task Force (IETF); the technology behind IP-address-to-telephone-number conversion known as ENUM; some of the organizations that are providing ENUM database services; and the concepts and standards behind SIP trunking, which allows a direct connection between an IP PBX and a service provider, without the need for additional gateways or format conversions. But according to many analysts’ reports, the SBC market is even hotter than some of these other peering technologies. And no, we’re not speaking of the service provider Southwestern Bell Corporation (they recently swallowed up AT&T and Bell South, so it would appear that they are also doing quite well), we are talking about Session Border Controllers, the guardians of your peered enterprise.

Would you believe a vendor if they pitched you on a product that provided network-to-network security, resolved IP addressing differences between two networks, kept track of key call information such as the calling and called parties and the call duration, allowed a VoIP call to traverse a Network Address Translation (NAT) device and a security firewall, provided admission control, monitored Quality of Service (QoS) and Service Level Agreement (SLA) issues, provided protocol translation between different networking formats (transcoding), and possibly more?

Sound like a lot to have in one box? Indeed, these are all functions performed by devices that their vendors identify as Session Border Controllers. There is no standardization, however. Some of these critical functions may be omitted from SBCs developed by different manufacturers.

So, in an attempt to clear up some of that uncertainty, the IETF’s Session Initiation Proposal Investigation (aka "sipping") Working Group (see http://www.ietf.org/html.charters/sipping-charter.html) recently issued an Internet Draft document titled Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments that provides an architectural background and defines the functions of an SBC (see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-01.txt). As a caution, keep in mind that Internet Drafts are the first step on the path to an IETF-approved Request for Comments (RFC) document, and are subject to change as further research and implementation experience is obtained with that technology.

This document looks at two critical areas of SBC deployment: their architecture and the scenarios in which they are deployed, and the functions that they should provide. Let’s look at the architecture and deployment issues first.

As the term border implies, the SBC functions as a demarcation point between two networks, which could be designated as an inner network, and an outer network. This architecture is further distilled down to two components, a signaling component, and a media component, that logically and physically connect these inner and outer networks. The signaling component deals with service requests, including connect, disconnect, authentication, and authorization. The media component deals with the transport of the information, including the monitoring of QoS and SLA If we drill down a little deeper, we find that this architecture can be deployed in two key scenarios: a peering scenario, and an access scenario.

In the peering scenario, the inner and outer networks represent different service providers that are exchanging traffic. The function of the SBC at the inner network is to control access to its network resources, protect its gateways and switching systems from unauthorized access and use, and monitor both the signaling (call control) and media (information flow) traffic. The SBC would assure that only media from authorized sessions would be allowed to access the inner network’s switching topology.

In the access scenario, the inner network represents a service provider, and the outer network represents the access network. For example, this access network could represent the open Internet, and the inner network could represent a SIP service provider. As before, the SBC provides the control and monitoring functions, but can also prevent over-subscription of the access links.

In our next tutorial, we will examine the functions that a SBC should perform.

Copyright Acknowledgement: © 2007 DigiNet Corporation ®, All Rights Reserved


Author's Biography
Mark A. Miller, P.E. is President of DigiNet Corporation®, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.