Skip to end of metadata
Go to start of metadata

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.. 


A session is defined as a single connection between a pair of signaling devices that passes through the SBC system.  Each session is comprised of two call legs: one call leg on a trusted interface and the other on an untrusted interface. Each session in the SBC is identified by a global call ID, which is a globally unique identifier assigned by the SBC software.

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.

Figure : 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. 

Figure : Call with two sessions


For multiple transfers, each new GCID and SIP REFER is considered a session.


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.


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)
  • SBC SWe Cloud


The focus of this documentation space is on the SBC Core platforms. To view SBC 1000/2000 product documentation, navigate to the SBC 1000-2000 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 can be 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.

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: