Skip to end of metadata
Go to start of metadata

To understand the role of an SBC, let us break the term down to its basic elements:


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 defined as a single connection between the SBC and another device. So 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 should be 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).