WebRTC doesn’t necessitate n SBC. Your use case might. WebRTC doesn’t need a gateway either.
The Session Border Controller is relatively new. When we first started off with VoIP there was no such entity in the specs. In a way, the SBC is a technical solution to a real problem – SIP had a few major flaws that made it impossible to use:
- It didn’t interoperate well. Different vendors had their own proprietary extensions or just interpreted the standard a bit differently
- NAT traversal was broken in SIP. It was there, but nobody really used it
With these two issues, the SBCs of the world started offering a solution that you as an enterprise can place at the edge of your network and “fix” these issues. The SBC acted as the intermediary between different equipment, and based on its location in the network – it also offered means to traverse firewalls by acting as one for VoIP traffic. Which lead to the SBC being touted as a security measure. With time, transcoding was added as another capability to SBCs.
Fast forward to WebRTC, and we see SBCs adding WebRTC to their bag of protocols and tools. The reason? WebRTC is just another access point into the networks of their customers.
While all this is true, here’s the thing: in my opinion, most use cases in the future are NOT going to be the traditional ones. Our interactions will migrate to the web, and a lot of them won’t really look back at all the telephony and VoIP infrastructure we already have. This greatly reduces the need for an SBC since WebRTC doesn’t suffer from the same issues as SIP:
- Interoperability in WebRTC is between browsers. With only 4 of them (2 implementing WebRTC now), there’s little chance of it not working well
- NAT traversal is a part of WebRTC in a way that doesn’t necessitate any SBC replacement for it
- Security is ingrained into WebRTC, so no need for help from an SBC here
The same applies to gateways. While these are necessary for use cases where you want to connect with an existing telephony network (traditional or VoIP), in many situations this isn’t going to be the case.
If you want to develop a service, you might not need an SBC or a gateway. The question you need to ask is what is your use case and what requirements do you have for it.
The Big Question
And now for the big question.
WebRTC doesn’t need the NAT traversal mechanism originally offered by SBCs.
The more WebRTC gets popular, the more STUN, TURN and ICE gets used; and the more that gets used, the more we will be seeing it with SIP deployments as well.
In such a case, we will be needing less of the SBC… taken to the extreme, are the days of the SBC numbered?