The VoIP Peering Puzzle�Part 24: Session Border Controller Functions, #2
In our previous tutorial, we looked at the first two Session Border Controller (SBC) functions that the IETF's Session Initiation Proposal Investigation ("sipping") working group documented in its 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). (Remember that Internet draft documents are considered "work in progress," and are therefore subject to change.) These functions were Topology Hiding, which is designed to maintain the proprietary of the private network topology; and Media Traffic Shaping, which modifies the session description messages, thus changing the characteristics of the network traffic.
In this tutorial we will examine two additional functions: Fixing Capability Mismatches and Maintaining SIP-related NAT Bindings.
Fixing Capability Mismatches
Conspiracy theorists might claim that vendors tweak network standards ever so slightly, and build these minor differences into their products just so those products will not interoperate with those of their competition. It's not clear if product developers are this overt, but nevertheless, product differences do arise, and typically it is the network manager that is left to figure out why a device or system from Vendor A will not communicate with its peer from Vendor B.
In the case of SIP, the base standards have been developed by the IETF and documented in RFC 3261 (see http://www.ietf.org/rfc/rfc3261.txt?number=3261), but there are two other standards organizations that are also embracing this technology. The first is the 3rd Generation Partnership Project (3GPP), which incorporates SIP into the IP Multimedia Subsystem (IMS) specification (see http://www.3gpp.org/ftp/Specs/archive/23_series/23.228/23228-760.zip). The second is represented by the PacketCable standards, developed by Cable Labs, a consortium of cable system operators (see http://www.packetcable.com/).
Other examples of potential incompatibilities would be networks that are running IP version 6 or IPv6 (in addition to the more common IP version 4), which have very different protocol and address formats, or differences in the types of codecs that are supported by each network.
Network operators have a big incentive to fix these capability mismatches so that their communication capabilities can extend past their own networks. To correct these mismatches, the SBC must intercept the SIP INVITE message as it is being passed from the outer network to the inner network. The SBC then examines the session description line contained in that SIP INVITE message, and rewrites the part of that descriptor that is not compatible. Because this process operates on the media being transferred between networks, it is often called media bridging.
Maintaining SIP-related NAT Bindings
In many cases, the solution to one networking challenge turns into a problem for another networking technology, and such is the case with Network Address Translation, or NAT, which is defined in RFC 3022 (see http://www.ietf.org/rfc/rfc3022.txt?number=3022). NAT was originally devised in the mid-1990s as a way to deal with the impending shortage of IPv4 addresses, as the world awaited the deployment of IPv6-based internetworks.
In brief, a NAT device sits at the edge of a network, representing one or a block of IPv4 addresses to the public world (i.e., the Internet) and another block of addresses (typically with the format 10.x.y.z) 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 from the private to public format, depending upon the direction of communication, with that mapping process being transparent to the end users.
A second process, known as Network Address Port Translation (NAPT), is a method in which both the IP addresses and the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port addresses are translated as well. Because addresses are frequently considered to be proprietary to the private network, the NAT function is often incorporated into other security devices, such as a firewall.
But herein lies the rubsome upper layer protocols, specifically the File Transfer Protocol (FTP) and the SIP embed IP addresses within their upper layer protocol messages, with the intention of using this address information for part of the message processing. In the case of SIP, those addresses may identify the end point (e.g., a softphone) that is being called. And if the destination endpoint address is translated mid stream between the calling and called parties, how do you complete that call? A second challenge is that of the firewallits objective is to protect the private network from unauthorized access, which typically gleans its marching orders from the source and destination addresses or the type of traffic that is being sent.
To further illustrate this challenge, recall that a SIP call is comprised of two parts: signaling for the call setup/disconnect, and media transfer of the actual call information. 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, and if they were allowed to get through, the embedded addresses would identify private, not public (or routable) addresses, thus resulting in packet delivery problems.
Several solutions to this problem have been designed, all under the general rubric of NAT Transversal. One solution that is found with VoIP networks is called Simple Transversal of UDP over NATs (STUN), as defined in RFC 3489 (see http://www.ietf.org/rfc/rfc3489.txt?number=3489). Another option is an enhanced Firewall/NAT function, frequently called an application-layer gateway, which modifies the signaling messages to include public routable addresses. Vendor-proprietary solutions are also available, all designed to achieve the same end result.
The issue of maintaining SIP-related NAT bindings occurs when an SBC is performing the NAT transversal function. In this example, assume the SBC is between a SIP User Agent (on the private or access network side) and the SIP Registrar (on the public side). When the Registrar receives a REGISTER REQUEST from the User Agent, the SBC modifies the response so that the registration expires sooner than normal. This triggers the User Agent to refresh the binding at the NAT sooner than normal. This process allows connectivity (i.e., registration) across the SBC, but not for so long a time as to leave the network open to extensive security breaches.
In our next tutorial, we will conclude 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.