The terms SBC and Gateway are use interchangeably on a regular basis. I do it all of the time but in reality they are two very distinct products in the VoIP world. They share very similar attributes and functionality because they both are used in VoIP communications.
Lets look at the Gateway first and where and how it is used. A Gateway typically has some form of TDM interface in it, a PRI/T-1 or FXS/FXO that connects to a legacy PSTN network or PBX. The legacy signal is terminated and the the payload is converted over into a TCP/IP packet for transport to a destination end-point. Pretty straight forward when you think about it, a converter! Okay, that is an over simplification but just the same it changes one format to another and routes it to a predetermined end-point.
The Session Border Controller (SBC) amps up the capabilities because it has to! The SBC deals with SIP trunks which are TCP/IP based data connections between the service provider network and the customer premise internal network. The best analogy for the SBC is a firewall. The SBC is a firewall for voice because it adds in a layer of security that do not get with a Gateway. Think about it for a second, the Gateway handles inbound and outbound calls but the inbound caller has to actually dial a number to reach the gateway. Not a whole lot to secure because you are permitting the inbound caller access by the nature of the application.
The SBC is essentially dealing with pure IP based communications which changes the game. Once you make a connection to the internet, you just opened yourself up to 7+ billion internet connected devices. Clearly you don’t want all them to have access to you network making calls through your PBX so the SBC has security functionally built in to permit to only those devices or service providers you need to be communicating.
The SBC also allows the user to address inter-operability issues between providers and devices. As much as we want to believe all of the issues have been worked out through RFC based standards, each manufacturer implements them in their own way and the SBC can normalize them through manipulations in the header.
The SBC routes packets to an end-point much like the Gateway but has more routing capability than the Gateway as it is designed to handle many inbound and outbound connections to end-points than a Gateway. An SBC can handle 10’s of thousands of connections where the Gateway is typically limited to the number of TDM channels that can be plugged into it.
So where is the confusion? The Hybrid… because enterprises typically migrate from one technology to another over time, the SBC has morphed into the eSBC which includes the Gateway interface connectivity as well as the SBC routing and security functionality. So if your plan your migration correctly, you will be able to purchase the core hardware once and through software license keys enable the SBC functionality when needed. No breaking of the budget up front and a easy migration when the time is right, simple!
I will continue to use the terms interchangeably for the foreseeable future, no reason to change now until we nail down the application requirements.