8 Gaps Left by Google in WebRTC

Here we are, almost 2.5 years after the announcement of WebRTC. I recently attended WebRTC Global Summit. What I was most surprised about was the level and intensity of whining about what is missing in WebRTC.

This got me thinking - what really is missing in WebRTC - and why? Remember: WebRTC is a technology that is meant to be a native part of web browsers. Without WebRTC, there's no way to interact in real time via the browser without plugins. With WebRTC, the sky is the limit.

Being only a technology also means that it is but a building block in a larger solution. What are the things Google left for us to whine about and implement on our own? Here are 8 of them, in no specific order.

1. Interoperability

As Serge Lachapelle of Google said at that same conference - WebRTC wasn't created with Telecom in mind. Neither was it created with UC in mind. It was, and still is, about the web (and web developers).

This is why WebRTC doesn't really care about interoperability in any meaningful way:

• It has G.711, but no wideband voice codec other than Opus, which is even newer than WebRTC itself
• It has no mandatory video codec yet, but the only browser implementations out there are using VP8 and not H.264
• It has no RTP. It mandates DTLS instead of SDES-SRTP for key exchange
• It forces the implementation of new or uncommon RFCs

Interoperability is something left out of WebRTC intentionally. A wide gap left for the incumbents to fill.

The reason Googled decided to ignore interoperability? Trying not be mired down by the past.

2. Popular Voice and Video Codecs

While this affects interoperability, there's more to it than that.

Voice and video codecs today are expensive and hard to purchase - to the point of impossibility in a lot of cases.

If you haven't tried to license a voice codec, I urge you to go and try it. This isn't an easy task, to say the least.

While some would view WebRTC as just a media engine and would love to have more codecs in it, it comes stripped of any common codecs. Something that Imagination Technologies just decided to offer - and they are not the only ones.

Why would you want other codecs?

• Interoperability
• Availability of hardware acceleration
• Prior investments

3. IE and Safari

Not really something Google could have closed, but still a gap.

There's no support for IE or Safari, though here are some promising indications of upcoming WebRTC support in both.

What's a vendor to do about it?

1. Wait
2. Ignore non-supporting browsers
3. Build his own WebRTC plugin for these browsers
4. Use Flash and WebRTC (ugly, complex, but workable)

4. Useful Statistics

Ever tried understanding the getStats() API in WebRTC? It is the API that provides the RTCP reports so the application can know what goes on in the media side.

It gives very little in WebRTC on browsers and is close to useless. It would be nice to get some beefy statistics to chew on and make decisions with.

This looks like an oversight - the effect of fighting over a video codec instead of putting the effort on meaningful tasks.

5. Rock Solid Mobile Support

Mobile is glaringly lacking in WebRTC.

Yes, the code is there, open sourced for all to see and use. But what about something that is easy to compile and run so we don't all need to search and read articles titled, "How to get started with WebRTC and iOS without wasting 10 hours of your life." With 56 comments on that one, you know something is still broken.

Mobile is just not ready in the base WebRTC code for developers to easily adopt - it still requires an effort to be made that isn't trivial.

6. Signaling

No signaling in WebRTC is a great thing. You can use whatever you feel like.

Google has their own signaling in their own WebRTC-enabled services, but somehow, it just neglected providing anything powerful for developers, which meant other SaaS providers filled the WebRTC signaling gap instead of Google here.

7. Server-Side Media Processing

Want to do recording? Fancy a multi-point video use case? How about broadcasting a session to thousands of participants?

All these require server side media processing, and Google hasn't provided any infrastructure here for developers. This is where Backend-as-a-Service for WebRTC comes into play and is required.

There's also a need for media engines and SDKs that can be adopted and used on servers and assist WebRTC developers. Luckily - there are quite a few already.

8. Non-SPA Capabilities

Want to start a chat in one Window and browse during that session? It must be done within the same web page. This is called SPA - Single Page Application - and is a critical part of WebRTC browser implementations today.

The problem? The moment you browse through a page, the WebRTC session you had opened gets severed. This makes it hard to get WebRTC embedded into existing websites easily.

It would be super nice if WebRTC enabled starting a session on one page, and somehow keeping it open while browsing to other pages inside the same website.

Somehow, existing websites got the same treatment as existing VoIP networks - they are just ignored by the WebRTC spec.

Challenges or Opportunities?

Here's the thing. You can view these gaps as challenges, and then decide to ignore WebRTC as a viable technology. Or you can decide it is actually an opportunity - and fill these gaps in your own service or for others.

I just published a report on choosing an API platform for WebRTC. Taking the time to review 13+ platforms and seeing which gaps they close for developers and how, reinforced my belief that WebRTC is production ready yesterday.

It is just a matter of viewpoint.