Session border controller

A session border controller (SBC) is a device regularly deployed in 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.

Early deployments of SBCs were focused on the borders between two service provider networks in a peering environment. This role has now expanded to include significant deployments between a service provider's access network and a backbone network to provide service to residential and/or enterprise customers.[1]

The term "session" refers to a communication between two parties – in the context of telephony, this would be 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 demarcates 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.

Functions

SBCs commonly maintain full session state and offer the following functions:

With the advent of WebRTC some SBCs have also assumed the role of SIP to WebRTC Gateway and translate SIP. While no one signalling protocol is mandated by the WebRTC specifications,[2] SIP over Websockets (RFC 7118) is often used partially due to the applicability of SIP to most of the envisaged communication scenarios as well as the availability of open source software such as JsSIP. In such a case the SBC acts as a gateway between the WebRTC applications and SIP end points.

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 many cases, in order to hide the network topology and protect the service provider or enterprise packet network, the session border controller (SBC) will terminate a received call and initiate 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. In cases where the SBC does not have the capability to provide media services on board, SBCs are also able to redirect media traffic to a different element elsewhere in the network, for recording, generation of music-on-hold, or other media-related purposes. Conversely, without an SBC, the media traffic travels directly between the VoIP phones, without the in-network call signaling elements having control over their path.

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 the network operators to manage the calls that are made on their networks, 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.

Example of a simple SIP call establishment

In order to show how an SBC works one can compare a simple call establishment sequence with a call establishment sequence with an SBC.[3] In the simplest session establishment sequence with only one proxy between the user agents the proxy’s task is to identify the callee’s location and forward the request to it. The proxy also adds a Via header with its own address to indicate the path that the response should traverse. The proxy does not change any dialog identification information present in the message such as the tag in the From header, the Call-Id or the Cseq. Proxies also do not alter any information in the SIP message bodies. Note that during the session initiation phase the user agents exchange SIP messages with the SDP bodies that include addresses at which the agents expect the media traffic. After successfully finishing the session initiation phase the user agents can exchange the media traffic directly between each other without the involvement of the proxy.

SBCs come in all kinds of shapes and forms and are used by operators and enterprises to achieve different goals. Actually even the same SBC implementation might act differently depending on its configuration and the use case. Hence, it is not easily possible to describe an exact SBC behavior that would apply to all SBC implementations. However, in general one we can still identify certain features that are common for most of SBCs. For example, most SBCs are implemented as back-to-back user agent (B2BUA). A B2BUA is a proxy-like server that splits a SIP transaction in two pieces: on the side facing User Agent Client (UAC), it acts as server; on the side facing User Agent Server (UAS) it acts as a client. While a proxy usually keeps only state information related to active transactions, B2BUAs keep state information about active dialogs, e.g., calls. That is, once a proxy receives a SIP request it will save some state information. Once the transaction is over, e.g., after receiving a response, the state information will soon after be deleted. A B2BUA will maintain state information for active calls and only delete this information once the call is terminated.

Example of a SIP call establishment with an SBC

When an SBC is included in the call path, the SBC acts as a B2BUA that behaves as a user agent server towards the caller and as user agent client towards the callee. In this sense, the SBC actually terminates that call that was generated by the caller and starts a new call towards the callee. The INVITE message sent by the SBC contains no longer a clear reference to the caller. The INVITE sent by the SBC to the proxy includes Via and Contact headers that point to the SBC itself and not the caller. SBCs often also manipulate the dialog identification information listed in the Call-Id and From tag. Further, in case the SBC is configured to also control the media traffic then the SBC also changes the media addressing information included in the c and m lines of the SDP body. Thereby, not only will all SIP messages traverse the SBC but also all audio and video packets. As the INVITE sent by the SBC establishes a new dialog, the SBC also manipulates the message sequence number (CSeq) as well the Max-Forwards value. Note that the list of header manipulations listed here is only a subset of the possible changes that an SBC might introduce to a SIP message. Furthermore, some SBCs might not do all of the listed manipulations. If the SBC is not expected to control the media traffic then there might be no need to change anything in the SDP header. Some SBCs do not change the dialog identification information and others might even not change the addressing information.

SBCs are often used by corporations along with firewalls and intrusion prevention systems (IPS) 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 replace the function of application-level gateways.[4] In larger enterprises, SBCs can also be used in conjunction with SIP trunks to provide call control and make routing/policy decisions on how calls are routed through the LAN/WAN. There are often tremendous cost savings associated with routing traffic through the internal IP networks of an enterprise, rather than routing calls through a traditional circuit-switched phone network.

Additionally, some SBCs can 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. Most SBCs also provide firewall features for VoIP traffic (denial of service protection, call filtering, bandwidth management). Protocol normalization and header manipulation is also commonly provided by SBCs, enabling communication between different vendors and networks.

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 IBCF, 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 IBCF, IWF, THIG, and I-BGF functions on the peering side. Some SBCs can be "decomposed", meaning the signaling functions can be located 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 IBCF/IWF can be separated from the I-BGF functions physically. Standards-based protocol, such as the H.248 Ia profile, can be used by the signaling platform to control the media one while a few SBCs use proprietary protocols.

Controversy

The concept of SBC is controversial to proponents of end-to-end systems and peer-to-peer networking because:

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 unfettered 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 provide the infrastructure used to connect the call end-points, are typically concerned about overall network performance/quality and want to ensure it is secure against the new series of threats that come with an IP based packet infrastructure. 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.

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.

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 (acquired in 2013 by Oracle Corporation), Cisco Systems, Kagoor Networks (acquired in 2005 by Juniper Networks now offering a router-integrated solution), Jasomi Networks (acquired in 2005 by Ditech Communications, now known as Ditech Networks), Netrake (acquired in 2006 by Audiocodes[5]), Newport Networks (now out of business), NexTone (first merged with Reef Point to form Nextpoint, and later purchased 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), Sonus Networks, Veraz Networks merging in 2010 with Dialogic to Dialogic Corporation, Cirpack, Data Connection renamed to Metaswitch in 2009, and Nable Communications. 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. . Newport Networks was the first to have an IPO on the London Stock Exchange's AIM in May 2004 (NNG), while Cisco has been publicly traded since 1990. Acme Packet followed in October 2006 by floating on the NASDAQ. With the field narrowed by acquisition, NexTone merged with Reefpoint becoming Nextpoint, which was subsequently acquired in 2008 by Genband. At this same time, there emerged the “integrated” SBC where the border control function was integrated into another edge device. Currently, both Cisco's CUBE (Cisco Unified Border Element) Enterprise and Oracle ACME are the leading enterprise SBCs in the market as per Infonetics Research.[6]

The continuing growth of VoIP networks pushes SBCs further to the edge, mandating adaptation in capacity and complexity. As the VoIP network grows and traffic volume increases, more and more sessions are passing through SBC devices. Vendors are addressing these new scale requirements in a variety of ways. Some have developed separate, load balancing systems to sit in front of SBC clusters. Others, have developed new architectures using the latest generation chipsets offering higher performance SBCs and scalability using service cards.

See also

References

  1. ↑ Hautakorpi, J.; Camarillo, G.; Penfield, R.; Hawrylyshen, A.; Bhatia, M. (April 2010). Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments. IETF. RFC 5853. https://tools.ietf.org/html/rfc5853.
  2. ↑ How WebRTC Is Revolutionizing Telephony. Blogs.trilogy-lte.com (2014-02-21). Retrieved on 2014-04-11.
  3. ↑ "Understanding Session Border Controllers" (PDF). FRAFOS GmbH.
  4. ↑ Sinnreich, Henry; Johnston, Alan B. (2001), Internet Communication Using SIP, Wiley, p. 180, ISBN 0-471-77657-2
  5. ↑ "AudioCodes SBC R7.0 Introduction 2015" (PDF).
  6. ↑ "Cisco Captures Lead in Enterprise SBC Market According to New Infonetics 2012 Market Share Report".
This article is issued from Wikipedia - version of the Tuesday, January 19, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.