What Is a Session Border Controller?

Session Border Controller (SBC), a NAT traversal method. SBC secures VoIP and provides a suite of media proxy servers.

SBCs maintain the entire conference status and provide the following features:

• In VoIP calls, SBC is inserted into the signaling and / or media paths between the calling and called parties, mainly those that use the Session Initiation Protocol (SIP), H.323, and MGCP call signaling protocols.

  In many cases, SBC hides the network topology and protects the service provider or enterprise packet network. The SBC terminates the inbound call and initiates a second call leg to the destination. On the technical side, this defines the back-to-back user agent (B2BUA) when used with the SIP protocol. The impact of this behavior is that not only signaling traffic, but also media traffic (voice, video) is controlled by the SBC. In the case that SBC does not have the ability to provide media services, SBC can also redirect media traffic to different elements elsewhere in the network for recording, generating and maintaining music or other media-related purposes. In contrast, without SBC, media traffic travels directly between endpoints, and call signaling elements within the network cannot control its path.

  In other cases, the SBC simply modifies the call control (signaling) data flow involved in each call, may limit the types of calls that can be made, change the codec selection, and so on. Ultimately, SBC allows network operators to manage calls made on their networks, repair or change protocols and protocol syntax for interoperability, and also overcomes some of the issues raised by firewalls and network address translators (NATs) for VoIP calls.

  To show the operation of the SBC, a simple call setup sequence can be compared with a call setup sequence with an SBC. In the simplest session establishment sequence, there is only one agent between the user agents, and the task of the agent is to identify the location of the called party and forward the request to it. The proxy also added a Via header with its own address to indicate the path the response should traverse. The agent does not change any conversation identification information that appears in the message, such as the tag in the From header, Call-Id or Cseq. The proxy does not change any information in the SIP message body. Note that during the session initiation phase, the user agent exchanges SIP messages with the SDP principal, which includes the address where the agent expects media traffic. After successfully completing the session initiation phase, the user agents can directly exchange media traffic with each other without the involvement of the agents.

  SBC is designed for many applications and is used by operators and enterprises to achieve a variety of goals. Even the same SBC implementation may vary depending on its configuration and use case. Therefore, it is not easy to describe the precise SBC behavior applicable to all SBC implementations. Generally, certain characteristics common to SBCs can be identified. For example, most SBCs are implemented as back-to-back user agents. B2BUA is a proxy-like server that splits SIP transactions in two call segments: on the user agent client (UAC) side, it acts as a server and on the user agent server (UAS) side as a client . Although agents usually only keep state information related to active transactions, B2BUA maintains state information about active conversations, such as calls. That is, once the proxy receives the SIP request, it will save some state information. Once the transaction is completed, such as after receiving a response, the status information will be deleted quickly. B2BUA will maintain status information for active calls and will delete this information only after the call is terminated.

  When the SBC is included in the call path, the SBC acts as a B2BUA, which acts as a user agent server towards the caller and as a user agent client towards the callee. In this sense, the SBC actually terminates the call made by the caller and starts making a new call to the callee. The INVITE message sent by the SBC no longer contains an explicit reference to the caller. The INVITE that the SBC sends to the agent includes Via and Contact headers that point to the SBC itself rather than the caller. The SBC also typically manipulates the session identification information listed in the Call-Id and From tags. In addition, in a case where the SBC is configured to also control media traffic, the SBC also changes the media addressing information included in the c and m lines of the SDP body. Therefore, not only all SIP messages will traverse the SBC but also all audio and video packets. When the INVITE sent by the SBC establishes a new dialog, the SBC also manipulates the message sequence number (CSeq) and the Max-Forwards value. Note that the list of header actions listed here is only a subset of the possible changes that SBC may introduce to SIP messages. In addition, some SBCs may not perform all of the operations listed. If the SBC is not expected to control the media traffic, it may not be necessary to change anything in the SDP header. Some SBCs do not change the session identification information, while other SBCs do not even change the addressing information.

  Enterprises often use SBCs and firewalls and intrusion prevention systems (IPS) to enable VoIP calls to and from a protected corporate network. VoIP service providers use SBC to allow the use of VoIP protocols from private networks with Internet connections using NAT, and also implement strong security measures necessary to maintain high-quality services. SBC also replaces the function of the application-level gateway. In large enterprises, SBC can also be used with SIP trunks to provide call control and make routing / policy decisions on how to route calls over LAN / WAN. Routing traffic through an organization's internal IP network can often save a lot of money, rather than routing calls over a traditional circuit-switched telephone network.

  In addition, some SBCs may allow the use of different VoIP signaling protocols (e.g., SIP, H.323, Megaco / MGCP) to establish VoIP calls between two phones, and perform media stream conversion when using different codecs code. Most SBCs also provide firewall capabilities (denial of service protection, call filtering, bandwidth management) for VoIP traffic. Protocol normalization and header operations are also usually provided by the SBC to enable communication between different vendors and networks.

  From the perspective of IP Multimedia Subsystem (IMS) or 3GPP (3rd Generation Partnership Project) architecture, SBC is P-CSCF and IMS-ALG on the signaling plane and IMS access on the media plane on the access side Gateway integration. . On the interconnect side, the SBC is mapped to the IBCF, the IWF in the signaling plane, and the TrGW (transition gateway) in the media plane.

  From the perspective of IMS / TISPAN architecture, SBC is the integration of P-CSCF and C-BGF functions on the access side, and IBCF, IWF, THIG and I-BGF functions on the peer side. Some SBCs can be "decomposed", meaning that the signaling function can be located on a separate hardware platform from the media relay function-in other words, the P-CSCF can be separated from the C-BGF, or the IBCF / IWF can be separated from the I-BGF Physical function. Standard-based protocols, such as H.248 Ia profiles, can be used by the signaling platform to control the media, while a few SBCs use proprietary protocols.

  The history of SBC shows that several companies have been involved in creating and promoting SBC market segments for operators and businesses. The original carrier-oriented SBC companies (either because they have been acquired or have been dissolved): Acme Packet (acquired by Oracle Corporation in 2013), Cisco Systems, Kagoor Networks (acquired by Juniper Networks in 2005, and now provide routers -Integrated solutions), Jasomi Networks (acquired by Ditech Communications in 2005 and now known as Ditech Networks), Netrake (acquired by Audiocodes in 2006 [5]), Newport Networks (now closed), NexTone (first time with Reef Point Merged to form Nextpoint, which was later acquired by Genband), Aravox (acquired and terminated by Alcatel in 2003) and Emergent Network Solutions (acquired by Stratus Technologies in 2006 and split into Stratus Telecommunications in 2009), Sonus Networks, Patton Electronics, Veraz Networks merged in 2010, Dialogic and Dialogic, Cirpack, Data Connection were renamed Metaswitch in 2009, and Nable Communications. According to RFC 3261 (SIP) and the author of many other related RFCs, Jonathan Rosenberg, Dynamicsoft actually developed the first working SBC with Aravox, but the product never really gained market share. . In May 2004, Newport Networks was listed on the London Stock Exchange's AIM (NNG) for the first time, while Cisco has been publicly listed since 1990. Acme Packet was listed on NASDAQ in October 2006. As the scope of the acquisition narrowed, NexTone merged with Reefpoint into Nextpoint, which was later acquired by Genband in 2008. At the same time, there was an "integrated" SBC, in which the border control function was integrated into another edge device. Currently, according to Infonetics Research, Cisco's CUBE (Cisco Unified Boundary Element) Enterprise and Oracle ACME are both market leading companies SBC. With the merger of GENBAND and Sonus to create Ribbon Communications on October 30, 2017, the SBC market continued to consolidate ^[1] .

  The continued growth of VoIP networks has pushed SBC further to the edge, requiring adaptation in terms of capacity and complexity. As VoIP networks grow and traffic increases, more and more sessions are going through SBC devices. Suppliers are meeting these new scale requirements in a variety of ways. Some people have developed independent load balancing systems that can sit in front of an SBC cluster. Others have developed new architectures using the latest generation of chipset, using service cards to provide higher performance SBC and scalability.