Tsahi Levent-Levi has made himself into one of the top experts on WebRTC in the industry. His website, BlogGeek.me is a great place to keep up on WebRTC developments, learn about startups and developments in the standard, and get great analysis about the progress of this exciting new standard. Tsahi is also a regular contributor here at No Jitter, and you can find his stuff here.
Now Tsahi has an in-depth paper on WebRTC that's definitely worth your time to check out. It's called WebRTC for Business People, and at 93 pages, it's a great deep dive into both the fundamentals of the technology, as well as a profile of some of the leading companies in some of the leading segments of WebRTC development. It's also--and this is what I found most useful about the paper--written with an eye (as the title suggests) to what makes WebRTC different, potentially revolutionary, and important to business.
One of the common themes that Tsahi keeps coming back to is how WebRTC's Web origins make it different from VOIP standards and protocols that came before. He discusses the new focus that comes when Web developers rather than communications developers are driving the process. This change
"means a change in focus--from the need to focus on how to implement a solution with high media quality, to a focus on the service being developed and the user experience it provides."
That's a pretty significant point. In the early generations of VOIP, it never occurred to anyone to deliver anything less than "toll quality", and chances are that even if it had, buyers would have rejected the lower quality. But in the near-decade since that time, a lot has changed. Gold-plated voice quality doesn't really matter if it's being delivered to a desk phone that nobody would consider picking up. At the same time, forward-thinking developers do think about services holistically--voice isn't important in and of itself, it's only important if the service requires it.
One of the best cases in point, ironically, is video. At our Enterprise Connect WebRTC day last year, a speaker noted that, "The most important part of video is voice"--after all, no one would stay on a video conference if somehow the voice stream dropped or degraded beyond recognition. There's no value to watching a talking head you can't hear. Same thing if someone's talking over a slide presentation; if you can't hear them, you're not really getting the experience.
On the other hand, it's hard to imagine anyone convening MOS score panels to judge voice quality on a Web-based communications session. Voice quality is a moving target and only one piece of that crucial element that Tsahi identifies--"user experience."
Another example of how Tsahi gives a good perspective on the issues that may actually affect deployment comes when he discusses STUN, TURN, and ICE, which are the 3 methods for multimedia to traverse Network Address Translation (NAT) boundaries. Basically, they require an external server to resolve issues that are way too complicated to get into here. Tsahi writes:
"The main challenge with NAT traversal in WebRTC is the fact that it is a new challenge for web developers, who are accustomed to having data pass through NATs and firewalls seamlessly for web traffic. They are unaware [of] the intricacies, challenges and cost of dealing with NATs in the real-time communications domain."
Again, this is less a technical problem than a developer cultural issue. It's not like web developers won't be able to figure this out; it's a matter of them making a routine part of their work on WebRTC apps and services. Unlike voice quality, NAT traversal isn't a variable consideration, or one that developers can give short shrift to; if a developer overlooks this element, sessions won't be completed.
One final example. Tsahi tackles the difficult issue of interoperability, but has a take on it that's different from that of the hand-wringers:
"1. Interoperability is less of an issue--prior to WebRTC, 10s of different implementations needed to be tested against each other for interoperability. I attended such interoperability events--they are a lot of fun and usually packed full with vendors testing their applications and devices against each other. With WebRTC, we are down to a handful of browsers that need to deal with the real headache of interoperability. So consider this one mostly "done", while expecting the same incompatibilities you will find with other HTML5 features across browsers.
2. Interoperability bugs get fixed faster--with browsers being updated regularly and automatically these days, you can expect known interoperability issues to be solved by browser vendors rather fast, and reach end users faster than any other VoIP solution out there.
2. Interoperability bugs get fixed faster--with browsers being updated regularly and automatically these days, you can expect known interoperability issues to be solved by browser vendors rather fast, and reach end users faster than any other VoIP solution out there.
These points put interoperability into perspective: Instead of the multitude of players that we've had in VOIP and other technologies, we're down to just 4 browser vendors.
The problem--and here's where I'm more of a hand-wringer and less sanguine than Tsahi--is that this appears to still be at least 2 vendors too many--considering that Microsoft and Apple are no-shows to the WebRTC game so far.
And that's just when we're talking about browser vendors. The recent dustups over video codecs show that other stakeholders, like Cisco and Google, are capable of injecting a lot of proprietary struggles into the process.
It's these issues--vendor cooperation; developer commitment; and a refocusing onto the user experience--that will have the most to do with how well WebRTC succeeds and how much change it really brings about. Tsahi Levent-Levi has done a tremendous job in describing these issues and rendering the state of the art in WebRTC. If this is a subject you have a stake in, it's worth your time to check out this paper (for which there is a charge).
Follow Eric Krapf and No Jitter on Twitter and Google+!
@nojitter
Eric Krapf on Google+
