The official adoption of WebRTC by Apple is great news. As always, the devil is in the details. Before starting the party let’s see Apple’s approach to WebRTC, first and foremost not making it part of their walled garden and second in areas related to interoperability related to APIs, ORTC vs. WebRTC 1.0, codecs support and HW acceleration.
While there is adapter.js that quests to bridge browser compatibility issues, it focuses mainly on API mapping. There are other issues, such as differences in SDP, that it doesn’t handle and these issue cause applications to break when used on dissimilar browsers. The constant changes in browser versions and in some cases, lack of backward compatibility between them make this a moving target.
As part of Chrome 52 release there were some performance and security enhancements, one of them was the decision to switch over to using Elliptic Curve Cryptography for generating the self-sign certificate used in the DTLS handshake. ECDSA is mandatory in WebRTC, question is, should you be worried about patent claims in this regards.
Amazon is working on a WebRTC based UC service, Yet another UC service? An API platform for developers? Here is the Amazon WebRTC and UCaaS menu.
What threats do these new services by the largest public cloud provider impose and are there any opportunities?
Compared to SIP, WebRTC adoption is lightning fast. It is not about replacing VoIP or PSTN. WebRTC is VoIP that extends communications to new dimensions.
Traditional analysts have a hard time quantifying the real usage of WebRTC because is it used in such a wide range of verticals and applications deployed by an undefined list of vendors, service providers and startups.
I had several questions lately from vertical service providers contemplating about the technology to use for their video service.
They were hesitant if building with WebRTC is the right way to go.
Here is a case study showing why building with anything other than WebRTC doesn’t make sense.