There is a lot of discussion in the industry around:
- Whether – or not – service providers and enterprise will need SBCs in the future
- Whether SBCs play a role in the world of WebRTC
- Whether a WebRTC gateway is standalone function or an extension of SBC
- Whether a WebRTC gateway replaces SBC
- Different approaches to implement WebRTC – HTTP/REST, SIP over Websockets, etc. and which is better
There are multiple views and lot of times the views are influenced based on whose view it is! I’ve been studying whatSBC vendors, non-SBC vendors, non-telco vendors, telco service providers, OTT providers, analysts, and technologists are saying, and what they are trying to push as part of their overall technology vision and product messaging.
In this column my intent is not to give yet another opinion but put some facts together to help you understand the relationship between all these fancy terms and make the right decision.
There are many ways to implement session control in WebRTC – using HTTP/ REST, JSON over web sockets, XMPP over web sockets, SIP over web sockets, or anything proprietary. Each has its merits and demerits. For instance SIP over web sockets is a good approach if the intent is to simply extend a SIP based telecom solution to the web – like a browser based softphone; but the downside is that SIP based implementation it is not very web developer friendly and limits the innovative uses to what SIP can offer. Fewer developers means higher costs and fewer innovations.
Whereas HTTP/ REST appeals to a large community web and mobile developer – allowing them to embed communication in browsers and mobile applications without requiring to learn SIP. This could extend the innovation beyond the traditional boundaries of telecom infrastructure. A great example of that is improving a user experience of retail online shopping by automatically passing a user’s browsing context to the call agent when a user chooses to calls for help.
I love to use an analogy that unlike other cars, Tesla was designed by keeping software developers in mind and not car mechanics.
Likewise you can say that HTTP/ REST based implementation of WebRTC is more oriented for web developers whereas SIP over Web sockets is more of an approach for traditional telecom VoIP developers.
Let’s now talk about the role of a gateway in the web world.
As long as the communication stays within the web world (i.e. browser to browser), “ideally” you should not need any gateway function, but I say that with full skepticism. We all once believed SIP would standardize IP communications protocol and we all know the reality of that statement!
WebRTC is an evolving “standard” and there certainly are non-conformers who are considering coming up with their own variation of WebRTC implementation (likes of Microsoft and Apple). So there is a role of gateway to provide interworking between different implementations of WebRTC – session control, choice of media codec, browser compatibility, etc. For instance, there is a long standing argument whether to standardize on VP8 vs H.264 for video codec. The gateway function solves that by brokering between these two media codecs – or even others not part of the specification.
I have been in the VoIP industry for well over 14 years and have seen many evolution of what is called an SBC – Session Border Controller. One thing that SBC does best is solve interworking between different IP communication islands, which is a real value prop of an SBC and mandates its role in any IP communication network. It has well over decades worth of experience in solving this painstaking interoperability and interworking challenge between different variations of IP communication protocols – slow start and fast start H.323, H.323 and SIP, IETF SIP and IMS defined SIP, SIP over UDP/TCP/TLS, SIP with SIP-I, SIP with IPv4 and IPv6 addressing, and innumerable vendor specific implementations. Trying to solve it all over again in another gateway function is unsurmountable. So, SBC certainly warrants its position as a SIP normalizer in bridging web and telecom world.
Now, does that mean it can be a WebRTC gateway itself? It depends. It’s worth understanding what function SBC has traditionally played in the network. Irrespective of what shape or form it comes in, there are three key functions it provides –
1) VoIP and multimedia session Security
2) session & media protocol Interworking, and
3) provide session control – which by the same are the same set of characteristics required for a WebRTC Gateway.
SBCs handle IP communication SESSIONS very well … and it depends on how you define a session.
Traditionally it had been a communication session created using a legacy VoIP H.323 protocol, or a SIP protocol for voice, video, IM, file transfers. But, it can very well be any new WebRTC session control mechanisms described above (SIP over web sockets, REST, etc.).
It certainly makes an obvious choice to extend an SBC with WebRTC gateway function when the desired mechanism to manage WebRTC sessions is SIP over Web sockets. For other mechanisms (like REST/ HTTPS, JSON over web sockets etc.) it can be argued whether it should stay as new independent function.
The question should not be whether SBC is required for the WebRTC or SBC can act as a WebRTC gateway…it should be whether you want to deploy a WebRTC session control within an SBC (and call it WebRTC SBC) or make it independent (and call it WebRTC gateway) and deploy it in conjunction with SBC. There is no question that both are needed, especially to enable communication between the web and the telco world. Ultimately, both are software functions which can be virtualized or deployed in separate physical boxes.
Although I promised not to give an opinion, I personally feel that vendors who are adapting to the more innovative HTTP/ REST based WebRTC implementation and at the same can simplify the complexities of interworking with different variations of SIP and media codecs (using their experience in SBC domain) will be more successful, more quickly, and scale to meet the enormous growth predicted as the world of real time communications changes – again.