Session border controller

From Wikipedia, the free encyclopedia

Jump to: navigation, search

A session border controller is a device used in some Voice over Internet Protocol (VoIP) networks to exert control over the signaling and usually also the media streams involved in setting up, conducting, and tearing down telephone calls or other interactive media communications.

Within the context of VoIP, the term session refers to a call. Each call consists of one or more call signaling message exchanges that control the call, and one or more call media streams which carry the call's audio, video, or other data along with information of call statistics and quality. Together, these streams make up a session. It is the job of a session border controller to exert influence over the data flows of sessions.

The term border refers to a point of demarcation between one part of a network and another. As a simple example, at the edge of a corporate network, a firewall demarcs the local network (inside the corporation) from the rest of the Internet (outside the corporation). A more complex example is that of a large corporation where different departments have security needs for each location and perhaps for each kind of data. In this case, filtering routers or other network elements are used to control the flow of data streams. It is the job of a session border controller to assist policy administrators in managing the flow of session data across these borders.

The term controller refers to the influence that session border controllers have on the data streams that comprise Sessions, as they traverse borders between one part of a network and another. Additionally, session border controllers often provide measurement, access control, and data conversion facilities for the calls they control.

Contents

[edit] Theory of operation

SBCs are inserted into the signaling and/or media paths between calling and called parties in a VoIP call, predominantly those using the Session Initiation Protocol (SIP), H.323, and MGCP call signaling protocols.

In some cases, the SBC acts on behalf of a called VoIP phone and creates a second call leg to the destination party. In technical terms, when used within the SIP protocol, this is defined as being a back-to-back user agent (B2BUA). The effect of this behavior is that not only the signaling traffic, but also the media traffic (voice, video) can be controlled by the SBC. SBCs also make it possible to redirect media traffic to a different element elsewhere in the network, perhaps for recording, generation of music-on-hold, or other media-related purposes. Without an SBC, the media traffic travels directly between the VoIP phones, without the in-network call signaling elements having control over their path.

However, in other cases, the SBC simply modifies the stream of call control (signaling) data involved in each call, perhaps limiting the kinds of calls that can be conducted, changing the codec choices, and so on. Ultimately, SBCs allow their owners to control the kinds of calls that can be placed through the networks on which they reside, fix or change protocols and protocol syntax to achieve interoperability, and also overcome some of the problems that firewalls and network address translators (NATs) present for VoIP calls.

SBCs are often used by corporations along with firewalls to enable VoIP calls to and from a protected enterprise network. VoIP service providers use SBCs to allow the use of VoIP protocols from private networks with Internet connections using NAT, and also to implement strong security measures that are necessary to maintain a high quality of service. SBCs also perform the function of application-level gateways.[1]

Additionally, some SBCs can also allow VoIP calls to be set up between two phones using different VoIP signaling protocols (e.g., SIP, H.323, Megaco/MGCP) as well as performing transcoding of the media stream when different codecs are in use. Many SBCs also provide firewall features for VoIP traffic (denial of service protection, call filtering, bandwidth management).

From an IP Multimedia Subsystem (IMS) or 3GPP (3rd Generation Partnership Project) architecture perspective, the SBC is the integration of the P-CSCF and IMS-ALG at the signaling plane and the IMS Access Gateway at the media plane on the access side. On the interconnect side the SBC maps to the I-BCF, IWF at the signaling plane and TrGW (Transition Gateway) at the media plane.

From an IMS/TISPAN architecture perspective, the SBC is the integration of the P-CSCF and C-BGF functions on the access side, and the I-BCF, IWF, and I-BGF functions on the peering side. Some SBCs can be "decomposed", meaning the signaling functions can be on a separate hardware platform than the media relay functions - in other words the P-CSCF can be separated from the C-BGF, or the I-BCF/IWF can be separated from the I-BGF functions physically. A proprietary or standards based protocol, such as the H.248 Ia profile, can be used by the signaling platform to control the media one.

[edit] Controversy

The concept of SBC is controversial to proponents of end-to-end systems and peer-to-peer networking in consideration of the following:

  • SBCs can extend the length of the media path (the way of media packets through the network) significantly. A long media path is undesirable, as it increases the delay of voice packets (especially if the SBC implements transcoding) and the probability of packet loss. Both effects deteriorate the voice/video quality. However, sometimes there are obstacles to communication such as firewalls between the call parties, and in these cases SBCs can be used to guide media streams towards an acceptable path between caller and callee, whereas without the SBC the call media would be blocked. Some SBCs can detect if the ends of the call are in the same subnetwork and release control of the media enabling it to flow directly between the clients, this is anti-tromboning. Also, some SBCs can create a media path where none would otherwise be allowed to exist (by virtue of various firewalls and other security apparatus between the two endpoints). Lastly, for specific VoIP network models where the service provider owns the network, SBCs can actually decrease the media path by shortcut routing approaches.
  • SBCs often restrict the flow of information between call endpoints, restricting end-to-end transparency. VoIP phones may not be able to use new protocol features unless they are understood by the SBC. However, some SBCs are more able than others to cope with previously unseen and unanticipated protocol features. End-to-End encryption can't be used if the SBC does not have the key, although some portions of the information stream in an encrypted call are not encrypted, and those portions can be used and influenced by the SBC. Some SBCs are able to offload this encryption function from other elements in the network by terminating SIP-TLS, IPsec, and/or SRTP. Furthermore, some SBCs can actually make calls and other SIP scenarios work when they couldn't have before, by performing specific protocol "normalization" or "fix-up".
  • In some cases, far-end or hosted NAT traversal can be done without SBCs if the VoIP phones support protocols like STUN, TURN, ICE, or Universal Plug and Play (UPnP). To date STUN, TURN, ICE and others have not seen wide deployment, and their complexity leaves much to be desired.

Most of the controversy surrounding SBCs pertains to whether call control should remain solely with the two endpoints in a call (in service to their owners), or should rather be shared with other network elements owned by the organizations managing various networks involved in connecting the two call endpoints. For example, should call control remain with Alice and Bob (two callers), or should call control be shared with the operators of all the IP networks involved in connecting Alice and Bob's VoIP phones together. The debate of this point is vigorous, almost religious, in nature. Those who want control in the endpoints only, are greatly frustrated by the various realities of today's networks, such as firewalls, filtering/throttling, and the lack of adoption of a universal VoIP equivalent to the phone number. Those who want control in the middle of the call end-points, are typically trying to replicate the old-style phone system, where virtually all control rested with the service provider. So far, these views have not proven to be reconcilable. Note that it may be required for a third call control element such as an SBC to be inserted in between the two endpoints in order to satisfy local lawful interception regulations.

[edit] Lawful Intercept and CALEA

An SBC may provide session media (usually RTP) and signaling (often SIP) wiretap services, which can be used by providers to enforce requests for the lawful interception of network sessions. Standards for the interception of such services are provided by ATIS, TIA, CableLabs and ETSI, among others.

[edit] History and market

The history of SBCs shows that several corporations were involved in creating and popularizing the SBC market segment for carriers and enterprises. The original carrier-oriented SBC companies are (or were, since several have been acquired or are defunct): Acme Packet (NASDAQ: APKT), Kagoor Networks (acquired in 2005 by Juniper Networks and later end-of-lifed), Jasomi Networks (acquired in 2005 by Ditech Communications which is now known as Ditech Networks), Netrake (acquired in 2006 by Audiocodes), Newport Networks, NexTone (first acquired by Nextpoint who was then acquired by Genband), Aravox (acquired in 2003 by Alcatel and terminated) and Emergent Network Solutions (acquired in 2006 by Stratus Technologies and in 2009 spun-off as Stratus Telecommunications). According to Jonathan Rosenberg, the author of RFC 3261 (SIP) and numerous other related RFCs, Dynamicsoft actually developed the first working SBC in conjunction with Aravox, but the product never truly gained marketshare. Five companies also played a major role in delivering enterprise-oriented SBCs: Jasomi Networks with its PeerPoint product line, Covergence, Edgewater, Borderware, and Ingate.

During the evolution of SBCs, many other companies undertook software development programs to create SBCs. However, doing so turned out to be a far greater technical challenge than most had anticipated, and there were few successes. An even larger group of companies began to remarket their existing products as SBCs when it became clear that the SBC market was "hot" with respect to acquisitions and IPOs.

Of these companies Newport Networks was the first to have an IPO on the London Stock Exchange's AIM in May 2004 (NNG), Acme Packet followed in October 2006 floating on NASDAQ, Acme Packet is the market segment leader. With the field narrowed by acquisition, NexTone (recently merged with Reefpoint becoming Nextpoint, then acquired in 2008 by Genband) was considered to be in second place, although they traditionally target a different market segment, having started life as a softswitch vendor.

[edit] See also

[edit] References

  1. ^ Internet Communication Using SIP (p 180), Henry Sinnreich & Alan B. Johnston, ISBN 0-471-77657-2.

[edit] External links

Retrieved from "http://en.wikipedia.org/wiki/Session_border_controller"
Personal tools