No it doesn’t. But that doesn’t mean we don’t need an SBC.
There’s a whole area of WebRTC that is left unhandled. I’ve first tried to approach it at the WebRTC Conference last year (slides at the end of this post). I am not the only one complaining – if you’ve read what Jeremy Thomas had to say on the joys of using WebRTC to build popexpert, you’d know:
[…] But I’d love to see a more authoritative reference architecture which illustrates how to setup a TURN server, which technologies are good for signaling, etc.
This makes it rather heartening to see Chad Hart from Acme Packet write about the various types of gateways for WebRTC. In Chad’s case, it continues with a set of questions that gets the reader understand he really needs an SBC from a large company (hint hint).
It did raise a question for me – does WebRTC need SBC?
The straight forward answer is no. it doesn’t.
This doesn’t mean that all WebRTC deployments don’t need an SBC – just that most of them won’t. Scoping this discussion, let’s go back to the basic question of where WebRTC plays. VoIP vendors will treat it as yet-another-interface, which I think will end up being less than 20% of WebRTC related interactions. For these, you probably do need SBC – but what about the rest?
Do I need an SBC for a call button on my website? An overkill.
Do I need an SBC for a dating site using WebRTC? Probably not. All calls are point-to-point, none really go into my enterprise, so there’s nothing really to protect
Gaming? No SBC.
I guess most of the companies I already interviewed wouldn’t gain much from an SBC. They might need a gateway or some other infrastructure component, but not an SBC.
An SBC is a firewall for VoIP coupled with a gateway. What happens when firewall vendors add support for WebRTC? This will be easier to achieve than doing the same for SIP or H.323 on the firewall. If (and when) it happens, will SBC be needed for those who just require WebRTC? I am not convinced.
Of course for that to happen, the likes of Check Point, Cisco and Juniper need to get their offering updated and support WebRTC. The fact that WebRTC is part of HTML5, and instantly available to anyone makes me believe they will take that plunge.
Acme Packet has done the wise thing – joining the WebRTC wagon as soon as possible. Other SBC vendors should do the same, and hope that the firewall won’t end up eating their business 5 years from today.
Tsahi – thanks for the mention!
We see SBCs as a toolkit of features for enabling real time communications delivery. These tools can be roughly classified into security, interoperability, reliability, and regulatory compliance. Most SBC users leverage a subset these tools and we think the same will be true for WebRTC. For today’s initial deployments, we see the most value on the interoperability side – particularly since the standards, particularly in the area of signaling protocols and codec choices are not even finalized. Reliability (i.e. performance) is also another “imminent requirement” – particularly as TURN servers are not always the easiest thing to setup. Having TURN server capabilities embedded into the SBC as part of a WebRTC gateway feature set will go a long way to addressing that challenge. As WebRTC matures and starts to have a more substantial user base, security needs will quickly come into play. Regulatory compliance of course much more complex, but I don’t see many ways WebRTC will be able to completely escape it – i.e. France’s recent regulatory interest in Skype is an example of how an OTT service may be subject to regulatory requirements in the future.
So regarding your comments on the scope of need for SBCs with WebRTC – yes, today it is just emerging but that is because it is very early days. That fact that our customers (service providers, contact centers, & enterprises) are continually coming to us to ask about how we can help with WebRTC is quite reassuring. Longer term, if the SBC vendors do a good job then SBCs should apply to much more than existing communications models. We see significant opportunities here.
Regarding inclusion of WebRTC in firewalls – while that is certainly a possibility, we think that is unlikely as current products have only basic SBC-like features sets. They would have a lot of development to do here to get into the DPI and deep-packet-manipulation aspects of SBCs. The firewall vs. SBC was also an argument against SBCs for SIP long ago, but that never came to fruition.
I think you can compare SBCs to CDNs. A CDN isn’t mandatory, but a lot of companies use them. They aren’t free and they did not really emerge until web-based content hit a critical mass. We see SBCs in WebRTC as being very similar – just instead of content they focus on the delivery of sessions.
Disclaimer: I work for a recently acquired company whose primary business is selling SBCs.
All true Chad. I just think that this focuses on current enterprises who need VoIP and will require WebRTC.
Not sure if this belong to the larger scope that is WebRTC.