Let’s say it loud and clear: WebRTC is pure VoIP. It does nothing better than the rest of the pack.
How I sometimes feel about experience and expertise in WebRTC:
Ever heard of WebRTC being better than Skype because it works with less bandwidth? How about the one saying it is the solution for the NSA snooping? Or that it works better on mobile than other solutions because it is embedded in the operating system and the browser?
None of it is true. At times, it is even the opposite. I am still amazed by the amount of misinformation out there.
A rule of thumb here: when it comes to media, WebRTC doesn’t provide a technology that is superior or unique that others don’t already have or can add relatively easily.
Some things to note in this regard:
- Codecs in WebRTC are negotiated via SDP. This is the same mechanism used by SIP
-
The mandatory voice codecs for WebRTC are G.711 and Opus
- G.711 is the same crap as all the rest of the pack (least common denominator). In most cases, when you see gateways for WebRTC to anything else – this is the narrowband voice quality you should be expecting
- Opus is too new, so it might be better than the rest of them. That said, there are those who are closing the gap already (Linphone and Audio Codes to be more specific)
- Not a lot of bandwidth is required for good voice, even in narrowband. While WebRTC does have an edge, it usually requires pure software coding while other codecs may need less of that at the moment
-
The mandatory video codecs for WebRTC are… still undecided. Either VP8 or H.264. H.264 is the industry standard – everything that looks remotely good in higher resolutions or frame-rates is H.264
- This includes Skype as far as I know (they shifted to VP8, but I assume they retracted since their acquisition by Microsoft)
- VP8 has no real technology benefit over H.264. Those that say otherwise may be technically correct, but I have yet to meet a single person who can see the visual difference between a VP8 to an H.264 video stream
-
The network magic? How you deal with jitter, latencies, packet loss, echo, etc?
- A known industry problem
- Every vendor has his own secret sauce for it. Some better than others
- There are better solutions than the one presented in WebRTC
- There are worse solutions than the one presented in WebRTC
- Translation: it is on par with the industry standard
So just remember: WebRTC is a media engine. There are other media engines that are in the same class when it comes to quality, but none of them are:
- Free (BSD)
- Maintained by top engineers as a day job
- Wrapped and packed nicely into a huge amount of web browsers with a Java Script API on top of it
Buried under your last bullet, but worthwhile to call it out: Session is initiated by visiting a URL and signaling procedure is downloaded as part of JS associated with that URL, facilitating triangular connection, thereby avoiding interop issues. In my opinion this will be considered more imp benefit of WebRTC.
Aswath,
You are of course correct. The whole point here is a request to stop evangelizing WebRTC for providing better media quality.
I’d note that those engineers day job is to fix their own problems, not providing free support for the media engine. And convincing them that there is a problem can make it necessary to hunt down the bug yourself.
In my experience over the last 6 months of using WebRTC for video the media seems better mainly through lower latency and jitter offered by peer to peer connections and no intermediate processing or routing.
I actually think the network compensation is better than most other implementations and certainly much better than any of the low to mid tier VC products.
To me though, the biggest breakthrough is the comprehensive NAT traversal that allows the peer to peer set up. If this had been available previously with non-browser soft clients over existing SIP signalling, WebRTC may not seem quite so special now.
@Warren,
The mechanisms that WebRTC is using for NAT traversal, ICE, TURN, STUN, have all been available and used by SIP and XMPP products well before WebRTC appeared.
The only piece of NAT related work that is happening within the context of WebRTC is “Trickle ICE” and this does make NAT traversal more reliable, it just makes the negotiation faster.
@Aswath
Downloading the signaling makes you compatible with yourself … so not much of win. You get the same level of compatibility when you download and install the same client on two machines.
The one true advantage of the WebRTC *model* is ease of deployment but that is still a promise that WebRTC has to live up to given its support by “only” two major browsers (i.e. when you are deploying web RTC apps, you still need to worry about the other browsers or require your users to install stuff … as with rich clients).
There is of course a side effect to the WebRTC work which is to get the community to agree on improving, adopting and deploying a number of protocols such as bundle, trickle ice (and ICE actually), SRTP, RTCP-MUX and many others. This is of course very positive but it is not exclusive to WebRTC and web pages.
I think the key is “comprehensive”. I find the level of true ICE and TURN support offered in pre WebRTC clients to be sub par.
This movement has envigorated the attitude towards promulgation and adoption of these standards.