In this section:


What is an SBC?

A Session Border Controller is a special-purpose device that protects and regulates IP communications flows.  As the name implies, session border controllers are deployed at network borders to control IP communications sessions.  Originally conceived to protect and control VoIP networks, SBCs are now used to regulate all forms of real-time communications including VoIP, IP video, text chat and collaboration sessions.. 

Session

An SBC “Session” license unit is defined as a point-to-point conversation, two legs of a call, and is represented by a single Global Call ID (GCID). Each session used decrements an official Ribbon License. When call transfers are processed using SIP REFER, even though two GCIDs are created for the original and transferred call, the SBC uses only one Session license for the session.

A call leg is a single connection between the SBC and another device. A session between two devices includes a call leg between device A and the SBC, and a call leg between the SBC and device B.

A call may require a single session or it may require multiple sessions resulting from call forking, conference call, call transfer, call recording or other mechanisms. For example, a call between two registered users through a feature server consumes two sessions: one session from User A to the Feature Server and one session from the Feature Server to User B.

The total number of concurrent sessions supported on the SBC platform may be limited by different factors, including:

  • Available Bandwidth – For calls with pass-through media, the SBC computes the media bandwidth required for each call leg, and determines if there is sufficient bandwidth available to host the call. Calls exceeding the bandwidth limit of the interface are rejected.
  • Call Rate – If the incoming call rate exceeds the rated capacity of the platform, calls are discarded to protect the system from overload. The number of concurrent sessions required is directly related to the Call Rate and the Call Hold Time (CHT). High call rates with a low average CHT value will result in fewer sessions than the same call rate with a high average CHT value.
  • System Limits – Each platform includes upper limits on the number of sessions supported. For example, the SBC 5200 supports a maximum of 64,000 sessions, while the SBC 5100 supports a maximum of 10,000 sessions.
  • License Limits – The SBC is licensed for the maximum number of sessions desired. However, the license limit may be less than what the bandwidth, call rate or system limits support. Any call that exceeds the licensed limit of the SBC platform are rejected.

Example #1: Call with one Session

A customer has purchased a 5,000 package of licenses, calls are coming in and egressing the SBC with no call forking – so each ingress and egress is one session. The maximum number of active calls is 5,000.

Call with one session

Example #2: Call with two Sessions

A customer has purchase a 5,000 package of licenses. Calls are coming in and getting transferred back through the SBC. Each call consists of two sessions, so the maximum number of simultaneous active calls is 2,500. 

Call with two sessions

Note

For multiple call transfers using SIP REFER, even though two GCIDs are created for the original and transferred call, the SBC uses only one Session license for the session.


Border

Typically, these sessions will traverse one or more IP networks, whether on an enterprise network or multiple service provider networks. The SBC sits at the border of each network in order to control the amount and type of sessions, as well as the type of data that can be used during these sessions. In this sense the SBC is part firewall, protecting the network from malicious IP traffic, and part traffic cop, policing how much traffic can enter the network in order to prevent overloads.

Controller

The SBC is a controller, which means it controls not only whether traffic can enter the network, but where it should be sent (referred to as session routing) and what type of modifications should be made to the traffic (example, transforming a SIP message header into an H.323 message header or downgrading an HD voice call to a compatible voice codec).

Ribbon SBC Portfolio Components

The Ribbon SBC Portfolio is comprised of the following Session Border Controller products:

SBC Edge

  • SBC 1000/2000

SBC Core

  • SBC 5000 series
  • SBC 5400
  • SBC 7000
  • SBC Software Edition (SWe)


The focus of this documentation space is on the SBC Core platforms. To view SBC 1000/2000 product documentation, navigate to the SBC Edge Documentation landing page.

The SBC Core addresses the next-generation needs of SIP communications by delivering embedded media transcoding, robust security and advanced call routing in a high-performance, small form-factor device enabling service providers and enterprises to quickly and securely enhance their network by implementing services like SIP trunking, secure Unified Communications and Voice over IP (VoIP).

The SBC Core provides a reliable, scalable platform for IP interconnect to deliver security, session control, bandwidth management, advanced media services and integrated billing/reporting tools in an SBC appliance. This versatile series of SBCs are deployed as Peering SBCs, Access SBCs, or Enterprise-SBCs (e-SBCs). The SBC product family is tested for interoperability and performance against a variety of third party products and call flow configurations in the customer networks.

  • Peering SBC: The SBC is deployed on the Peering Edge in an IMS/VoLTE network. On the Peering Edge the functional roles include: IBCF (TrGW). Refer to Configuring SBC as IBCF, for details.
  • Access SBC: The SBC is deployed on the Access Edge in an IMS/VoLTE network. The functional roles include: P-CSCF (IMS-AGW), E-CSCF, ATCF (ATGW) and EATF. Refer to Configuring SBC as Access SBC with External P-CSCF, for details.
  • Enterprise SBC: The SBC platforms that enable enterprises to control critical IP network borders to their centers that host VoIP/UC infrastructure. Refer to Enterprise Deployment Scenarios, for details.

The SBC Core can be further expanded to:

  • SBC 5000 Series
    • SBC 5100/5110 Platforms
      Targets small to medium session count deployments (250 to 10,000). These capacities make this product particularly well suited for medium enterprises and small to medium service providers.
    • SBC 5200/5210 Platforms
      Targets medium to large session count deployments (500 to 64,000). These capacities make this product particularly well suited for large enterprises and medium to large service providers.
  • SBC 5400
    Targets medium to large session count deployments (700 to 75,000). These capacities make this product particularly well suited for large enterprises and medium to large service providers.
  • SBC 7000 Series
    Targets large session count deployments (up to 150,000 sessions). These capacities make this product particularly well suited for large service providers. Example deployment scenarios include:
    • Service Provider Access – High subscriber and simultaneous call scale coupled with high availability and redundancy.
    • Service Provider Peering – High simultaneous call scale coupled with high availability and redundancy.
    • Enterprise and Service Provider Video – Supports large WAN interface bandwidth.
    • Wireless – Supports a large number of subscribers and calls where high availability is essential.

  • SBC Software Edition (SBC SWe)
    Targets small to large session count deployments (25 to unlimited). These capacities make this product particularly well suited for small to large enterprises and service providers. SBC SWe application resides on a private or public virtualized cloud, or on a dedicated server.

    Ribbon offers different SBC personalities on the SBC SWe platform, as summarized below:
    • I-SBC: "Integrated SBC" with signaling, media, and (optional) transcoding functionality within a single node. An SBC instantiated without a personality type defaults to I-SBC. This personality type is analogous to the SBC Core hardware platforms.

    • D-SBC: "Distributed SBC" refers to the architecture where the signaling, media, and (optional) transcoding functions are handled by dedicated SBC nodes or clusters, and includes the personalities below:
      • S-SBC: "Signaling SBC" in a distributed SBC deployment. An SBC must be instantiated with the Signaling "personality" to behave as an S-SBC.
      • M-SBC: "Media-handling SBC" in a distributed SBC deployment. An SBC must be instantiated with the Media "personality" to behave as an M-SBC.
        • T-SBC: "Transcoding-handling SBC" in a distributed SBC deployment. T-SBC is a special case for an M-SBC. "Transcoding-handling" requires specific configuration settings, but not a completely distinct "personality." Only an M-SBC can be configured as a T-SBC.

    • SO-SBC: "Signaling Only SBC" is not an SBC personality, but denotes a configuration setting dedicated to handling signaling only. Either an I-SBC or an S-SBC can be configured as an SO-SBC, which is the primary difference between S-SBC and SO-SBC.



SBC Core Architecture

This following pages detail the SBC Core and SBC Software Edition architectures: