One of the challenges of Session Border Controllers (SBCs) is that their name is somewhat open to interpretation—in other words, what constitutes a session, a border, and control, is somewhat subject to the whims of the product developer. It is generally accepted that a SBC enables peering between two service providers’ networks; between an access network and a service provider’s network; or between an enterprise IP PBX and a service provider’s network. Unfortunately, that is where much of the current industry agreement ends. In other words, the functions available in one vendor’s SBC may be very different from those found in another vendor’s device.
In our previous tutorial, we considered the architecture of a Session Border Controller (SBC), plus two deployment scenarios—peering and access—as defined by the IETF’s Session Initiation Proposal Investigation (“sipping”) working group and their recently-issued Internet Draft document titled Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments (see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-01.txt). (As noted before, Internet Draft documents are considered “work in progress,” and therefore subject to change.)
This document faces the issue of variable product requirements head on—by defining seven different functions that are used in SBC deployments in communications networks, while keeping a focus on the impact that these functions may have on support for SIP-related systems. In this and the next two tutorials, we will look at these SBC functions in depth.
The connection of two networks, be they private or public, always brings an element of security risk But remember that there are really two connections involved: a physical connection, which is implemented at the Open Systems Interconnection (OSI) Physical and Data Link layers, and a logical connection, which is typically implemented at the OSI Network, Transport, and Session layers. The requirement for a physical connection is quite obvious, as there must be some communication channel—be that twisted pair, fiber optic, wireless, or some other—between the two networks. The logical connection is a little more obscure, as it involves application processes on either end (typically called sessions), which must also exchange information. That logical communication requires addressing, which might involve the address of the device (the IP source and destination address), or the address of that device’s process (the TCP port address).
IP addresses follow a well-known format, and once you know part of that addressing format (such as the network and subnet numbers), figuring out the balance (such as the host number) is certainly possible through an iterative process of elimination. And therein lies the rub—if you reveal part—or all—of the network addresses of your servers, SIP proxies, gateways, and so on, you also leave them vulnerable to potentially disruptive hacks and attacks, or you simply reveal information to your competition that should really be kept proprietary. Hence, the requirement for the SBC for what is called topology hiding.
To implement topology hiding, the SBC must remove and rewrite any addressing information that is carried in the SIP message headers (such as the Record-Route and Via entries) that would reveal any internal network topology information. To accomplish this, the SBC operates as a Back-to-Back User Agent (B2BUA), which is defined in the SIP specification, RFC 3261 (see http://www.ietf.org/rfc/rfc3261.txt?number=3261). The B2BUA acts as both a User Agent Server (by receiving and processing requests), and as a User Agent Client (by generating requests). The SBC receives the signaling information from the inner network, and then generates a new call that is destined for the outer network. During this process, any proprietary topology information (such as might be contained within the Record-Route entry) is replaced with information that only identifies the SBC, and thus protecting the internal network topology.
Media Traffic Shaping
The act of controlling the media traffic that is carried on the network is called media traffic shaping. Network operators may perform this function for several reasons, including: financial advantage (billing differently for one type of traffic, such as video, than another type, such as voice); having the ability to enforce the use of specific codecs; ensuring a specified Quality of Service (QoS) level; monitoring the traffic to verify compliance with a Service Level Agreement, or implementing auditing or traffic intercept (i.e., law enforcement) functions.
To implement traffic shaping, the SBC must access and modify the session descriptions (offer/answer messages) that are exchanged between the SIP user-agents (see the Session Description Protocol, RFC 4566, http://www.ietf.org/rfc/rfc4566.txt?number=4566). As was described above in the Topology Hiding section, the SBC operates as a B2BUA, and is inserted in the media path. It then modifies the session description messages that are carried in the SIP messages, and can receive the media from one user-agent, and relay it to the other user-agent. A similar process is undertaken for the opposite communication path.
In our next tutorial, we will continue our examination of the functions that a SBC should perform.
Copyright Acknowledgement: © 2007 DigiNet Corporation ®, All Rights Reserved
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.