In our last tutorial, we summarized some of the business issues that enterprise network managers should examine when considering a move toward a peering architecture. To conclude our series on this topic, let’s review some of the technical requirements of one of the key elements of that peering architecture, the session border controller or SBC.
To begin, it should be noted that we looked at SBCs from 27 different vendors, designed and manufactured in locations all around the globe, and ranging from systems that were “all-in-one” products, providing secure branch-office connectivity, to dedicated session border controllers designed as carrier-class products.
So it becomes clear that you have to match the scope of your peering project with the session border controller you are considering, and narrow your short list down to those companies that provide products that match your peering objectives. Independent of the size of your peering project—be that peering between two enterprise locations, or a plan to provide VoIP services on a much broader scale, such as a wholesale carrier services—many of the underlying technical considerations remain the same.
Defining those technical criteria for SBCs has been an ongoing project of the Internet Engineering Task Force’s Session Initiation Proposal Investigation (“sipping”) Working Group (see http://www.ietf.org/html.charters/sipping-charter.html), with their recently updated 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-03.txt).
Remembering that Internet Drafts are the first step on the path to an IETF-approved Request for Comments (RFC) document, and are subject to change, the functions described therein nevertheless provide solid technical benchmarks against which various SBCs can be compared. Let’s briefly review these seven functions:
Topology Hiding—The connection of two networks, be they private or public, always brings an element of security risk. Communication between these networks 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). And 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. Hence, the requirement for the SBC for what is called topology hiding, in which the SBC removes and re-writes any addressing information that is carried in the SIP message headers that would reveal any internal network topology information. Any proprietary topology information is replaced with information that only identifies the SBC, 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.
Fixing Capability Mismatches—Many organizations have embraced SIP, including the Internet Engineering Task Force (IETF, see www.ietf.org), that developed the base standards, the 3rd Generation Partnership Project (3GPP, see www.3gpp.org), which incorporates SIP into the IP Multimedia Subsystem (IMS) specification , and Cable Labs, a consortium of cable system operators that developed the PacketCable standards, (see http://www.packetcable.com/). As you might expect, not all of these implementations are designed in the same way, so interoperability issues can arise. Network operators want their communication capabilities to extend past their own network, and may rely upon the function of the SBC at the network border to fix any capability mismatches that may occur.
Maintaining SIP-related NAT Bindings—A NAT device sits at the edge of a network, representing one or a block of IPv4 addresses to the public world (i.e. Internet) and another block of addresses that identify a private network. As IP traffic transverses the NAT device, the addresses are mapped on the fly from the public to private format, or vice versa, depending upon the direction of communication. The NAT function is often incorporated into other security devices, such as a firewall.
However, if a SIP station is located behind a Firewall/NAT device, an inbound SIP INVITE message will not be successful, since the destination address is translated by the NAT. In addition, any inbound media streams will be blocked at the firewall, because if they were allowed to get through, the embedded addresses would identify private, not public (or routable) addresses, thus resulting in packet delivery problems. The issue of maintaining SIP-related NAT bindings occurs when a SBC is performing the NAT transversal function, while still respecting the timing and other protocol requirements of SIP, to assure that both the call control and security processes are maintained.
Access Control—can be applied to the two key elements of the SBC: to signaling, or to both signaling and media. When access control is applied to the signaling function, the SBC operates similarly to a proxy server, which receives a service request, and then forwards it on behalf of the requestor. When access control is applied to both signaling and media, the SBC operates similarly to the media shaping function, where session description parameters are modified in transit. In either event, the ultimate result is that only media for authorized sessions is allowed to pass through the SBC.
Protocol Repair—Some signaling messages from non-standard clients may not be formatted according to the rules defined for that protocol, and in other cases, a client may implement an older version of the protocol, and not (yet) take advantage of a new parameter or option that is available in the latest protocol release. The SBC can repair the protocol messages before sending them on their way, and when doing so, operates like a proxy server, being liberal in what it receives and accepts, but being strict in what is transmits. An example of this condition would be a SIP INVITE message that requires a simple parameter modification in order for it to be compatible with the version supported on the other side of the SBC.
Media Encryption—A media encryption/decryption function is performed by the SBC at the edge of the network when the media from the access network is encrypted, yet the media is transported unencrypted in the inner (or provider) network. Note that encryption within the provider network may not be feasible, as the network operator may have a legal obligation to allow legal intercept of the information, which requires that media to be transmitted in the clear.
This wraps up our look at VoIP Peering with the hope that this subject is a little less puzzling now than it was before you started the journey with us. Our next tutorial will begin a new chapter in our technical tour through converged networking technologies, and look at how the VoIP network can be optimally managed.
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.