We've always known that it was going to take a lot more than some new browser releases to make WebRTC a reality. It's going to take back-end infrastructure that can allow WebRTC-enabled endpoints to participate in the whole diverse, multi-faceted, non-interoperable world that is public and enterprise communications.
There have been some entries already in this product category, early WebRTC gateways, but today at Oracle OpenWorld, the former Acme Packet folks, now part of Oracle's Communications division, announced WebRTC Session Controller, which promises a serious load of functionality for service providers and enterprises that want to support WebRTC use in ways that end users can actually take advantage of. The controller is also the first product of joint Oracle-Acme Packet product development.
Though Oracle representatives say the new WebRTC Session Controller is aimed at both the service provider and enterprise audience, the pitch here at OpenWorld fell more heavily on the SP end of things, since SPs are where much of Oracle Communications is focusing its efforts (the company complemented its Acme Packet purchase with the subsequent acquisition of carrier software supplier Tekelec earlier this year). But whether for the enterprise or service provider, the new session controller tackles some of the major issues in WebRTC enablement at scale.
This is a completely standalone software product, which can run on a virtualized server--there's no Session Border Controller (SBC) functionality involved; it's just meant to implement WebRTC. The new product sets out to deal with the largest reliability, interoperability, scalability and security issues that WebRTC brings about, according to Chris King of Oracle, who delivered the company's presentation on the new product at OpenWorld.
When it comes to reliability, one of the major challenges is dealing with the vagaries of Web browser operation and being able to pick up dropped sessions--a function called "rehydration." This is basically how the controller deals with browser crashes. Chris King explained that the controller maintains state on the server side for all clients involved in a session, so that if the browser crashes, when the unfortunate end user reconnects, they're immediately rejoined to the existing session, to re-establish the connection.
This same principle also allows for device-to-device handoffs--say, if you want to start a WebRTC session on a PC and switch it to your mobile.
On interoperability, it's clear that Oracle has no illusions about the kind of world that WebRTC users will be living in. The product will start out mediating between Chrome and Firefox WebRTC browser implementations (which don't seamlessly talk to each other yet), adding other endpoint types as these come on line with (inevitably) slightly-incompatible implementations of the WebRTC standard, according to King. In fact, he noted that even if a standard is widely accepted, "minor incompatibilities we anticipate, will grow rather than compress over time" as incremental changes are made to the same browser over successive versions, not to mention variations between different browsers.
And that's all just WebRTC-to-WebRTC interoperability. The new Oracle controller will also address interoperation with the legacy PSTN and will handle media interworking and transcoding in IP communications.
The complete solution includes a media engine and signaling engine to provide that interoperability and interworking, as well as a client SDK to support applications leveraging WebRTC. Here's Oracle's diagram of the controller in a typical deployment:
On security, the controller will coordinate identity/authentication across systems, implement firewall traversal, and will block any inadvertently-generated malformed or inappropriate traffic from endpoints, that could act as unintentional Denial of Service effects, according to King.
Oracle didn't announce a date for the product's GA, or pricing. And there's really not a huge rush, at this stage, at least in terms of actually rolling this out into networks. WebRTC is still very much in its infancy, and isn't widely adopted. But there's every reason to believe that WebRTC will have a prominent role to play in both enterprise and service provider networks in the future, and those networks will need systems like this controller to make those WebRTC endpoints something more than hobbyists' playthings.
Follow Eric Krapf and No Jitter on Twitter and Google+!
@nojitter
Eric Krapf on Google+
