WebRTC in 2017
The road to the promised land.
For more than 6 years, we have been working on and looking forward to a simpler way to build RTC (Real Time Communications) applications on the web. In order for this technology to truly show its value, the major browser vendors needed to show up.
macOS Sierra – Left: Safari Preview 32 (Safari 11.0, WebKit 12604.1.23.0.4) using H.264 Right: Chrome Version 58.0.3029.110 (64-bit). https://webrtc.github.io/samples/ using H.264
Mobile, mobile, mobile.
Now that Apple has joined the party in earnest, does the technology have the coverage required in order for developers to make good use of WebRTC on mobile devices? Let’s find out.
Until now, in order for WebRTC to work on iOS, we were relegated to wrapping WebRTC code in Objective-C and Swift, in our native iOS apps. Basically, we had to take the Chrome code and build an app that was sent to the app store for approval and wait in line, like all the other chumps (yours truly included). Conversely, on Android we could run much of that same code from our desktop Chrome apps, on the Android device as well, within reason of course.
Now that Safari and Chrome are shipping compatible WebRTC on mobile, we get to reuse the same code, right!? Well, mostly, they are different code bases, after all.
A word about hardware acceleration.
If ubiquitous mobile video is to take off, the battery life of the device has to last more than the length of the 10 minute video call (ok, I am exaggerating a bit, but I think you get the point) and the performance needs to be at least adequate enough to distinguish facial features. My bar is set a little higher, baby steps for now.
Without h/w acceleration the CPU is likely working too hard to encode the local video and decode the inbound video + service the other processes required at the same time. That really means there needs to be hardware onboard the device dedicated to video coding. That in turn means H.264, since there are very few vendors that offer VP8 or VP9 h/w acceleration.
Question: Does this mean that mobile apps written with VP8 will not be able to deliver decent mobile video conferencing?
Answer: No, not at all, but they will likely not be as performant as those taking advantage of hardware acceleration.
Suffice to say that SVC (Scalable Video Coding) usage would be another reason why we need h/w acceleration, but that’s for another day.
Who’s using what?
The majority of desktop and mobile WebRTC apps written today, are using VP8 for video.
Since Apple and Microsoft both use H.264 and Google uses VP8 and H.264 (recently shipped Open H.264 – on the desktop and mobile). Also, many of the Enterprise RTC developers are already on that H.264 bandwagon.
Question: If Apple and Microsoft devices ship with H.264, what is the case with Google Chrome on desktops and android, are they preferencing VP8?
Answer: Chrome for desktop and android now have H.264 native. Many of the Android devices that ship today all have H.264 hardware acceleration onboard. In order to understand which units have H.264 and hardware acceleration, you can run use the Android APIs to pull a list of available codecs, but in the case of WebRTC, you will only get H.264 in Android WebRTC if there is a h/w encoder on the device.
Is H.264 the answer for WebRTC video?
Here is a recent test:
Host 1 – (before joining):
macOS Sierra, Macbook, Safari (Technology Preview 32)
Host 2 (after joining):
Android 7, Samsung 7, Chrome 55
setRemoteDescription OperationError: Failed to set remote video description and params. Likely because Safari is not seeing H.264 on Android.
Host 1 (after joining):
According to the Chrome Status page, Chrome for Android should have H.264. So why is the session barfing when trying to set up video? The logs do not lie…
Safari – offer:
a=rtpmap:96 red/90000
a=rtpmap:98 ulpfec/90000
a=rtpmap:99 H264/90000
Chrome on android – answer:
a=rtpmap:96 red/90000
a=rtpmap:98 ulpfec/90000
a=rtpmap:97 rtx/90000
Err, huh? No H.264 in reply?
So, I updated to latest Chrome on android (58) and tried again…
… et voilà!!
Next topic, paying the man!
Shipping your product with H.264 enabled, means you may potentially need to deal with the MPEG-LA royalty police for H.264 royalties, but there are some grey areas.
In the case of Apple and Microsoft, where H.264 royalties are already being paid for by the parent vendor, the WebRTC developer is riding on the coattails of papa bear, at least in theory.
Cisco’s generous OpenH.264 offer means that those using this binary module, can do so at potentially no cost:
We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms.
Q: If I use the source code in my product, and then distribute that product on my own, will Cisco cover the MPEG LA licensing fees which I’d otherwise have to pay?
A: No. Cisco is only covering the licensing fees for its own binary module, and products or projects that utilize it must download it at the time the product or project is installed on the user’s computer or device. Cisco will not be liable for any licensing fees incurred by other parties.
That seems to mean (I am no lawyer) every developer shipping WebRTC apps supporting Open H.264 binary module, get a free ride. Those using some other binary, or shipping the above source code for that module, could be on the hook for those royalties. That said, since there are royalties being paid by parent vendors where devices are shipping H.264 anyways, developers may not get hassled regardless.
Summary:
So what did we learn here?
- Apple has joined the party, now we have a full complement of browser vendors!
- If you want to leverage WebRTC video to deliver a ubiquitous mobile and desktop experience for your users, you should likely consider including both H.264 and VP8.
- VP8 is (still) free and powers most of the WebRTC video out there today.
- You can make use of the Open H.264 project and get a free H.264 ride, albeit baseline AVC.
- WebRTC on Android does not support software encoding of H.264, so unless there is local hardware acceleration, H.264 will not be in the offer.
- H.264 is not fully enabled (or buggy) in Chrome 55 (I was using it on Samsung S7 Edge (Android 7), but it does work with Chrome 58.
- WebRTC is not DOA!
- SDP still sucks and ORTC can’t come soon enough!!
The W3C and IETF are also closing in on shipping WebRTC as a web standard, here’s a great update from Google on that as well. Latest W3C WebRTC editor’s draft, latest charter.
As a side note, it would be interesting to see something like this open sourced; VP8 / H.264 conversion without transcoding, if only to service the existing desktop apps currently running VP8 <-> mobile H.264. It would likely overwhelm the mobile device, but it would be cool if it worked!
Disclaimer: The views expressed by me are mine alone and do not necessarily represent the views or opinions of my employer.
PulverHWC – How We Communicate
Next week I will be joining friends old and new at PulverHWC to rediscover – How We Communicate.
Here is an email from Jeff Pulver inviting all of you to join us in Los Gatos for what is sure to be a landmark occasion.
Hope to see you there!
Erik
The Keys to the Communications Universe
Next week I return to doing the one thing that I love best – bringing together brilliant, interesting people.
Leaders, visionaries, dreamers and market makers from the worldwide communications industry have accepted my invitation to take part in the Pulver HWC Summit, May 18 – 19 at Testarossa Winery in Los Gatos, CA. I am grateful for both the people who are speaking and the tech legends who have signed up to join us for an intimate conversation. I believe understanding the message behind “How We Communicate” (“HWC”) is the next great area of growth in the communications space. Trillions of dollars of opportunity will be created and there are relationships to be forged, deals to be made, and knowledge to be shared.
There are a limited number of tickets still for sale. To join the conversation and to register, please click here. I would appreciate it if you could share this email with your friends and family involved in the communications industry.
Thank you!
Warm hugs, Jeff
Do you really want a dual MTI video codec for WebRTC?
Update: There is now some healthy conversation in the IETF WG around what “compliant” and “compatible” actually mean. More on this as it unfolds.
—
We are now in the final throes of a consensus call in the IETF around which video codec should be made mandatory for those building WebRTC apps, services et al, who wish to be considered “WebRTC Compliant”. The codec contenders are VP8 and H.264, in many forms and combinations.
This latest consensus call is for both codecs to be mandated for all WebRTC endpoints, or “dual MTI codec”. I am sure I will catch hell from someone on language but that is the essence of it. As one might expect, there are some that are in favor and some that are against a dual MTI video codec. Those in favor seem motivated to accept this based on the promise of interoperability that might follow and other reasons. As one might expect, we are all quite eager to put this debate to bed so we could get on with other work.
This is not a decision that should be made lightly. Let’s consider the implications. Imposing a dual MTI suggests that every developer that wishes to produce a WebRTC compliant app must implement both codecs.
Coming from a co-founder of an RTC toolkit vendor I can tell you that this does not sit very well with me, nor others in the WebRTC WG. One glance at the thread comments should provide some insight.
I find it difficult to agree to mandate a dual MTI codec knowing that there are a great many developers who will not want or will be in a position to implement both codecs. Yes, many WebRTC SDK vendors will support both. Even if both codecs and their transports are provided as part or could be easily added to the application at compile time it doesn’t mean that every developer will want to implement or ship both codecs.
Bottom line is, according this consensus, if developers do not implement/ship both codecs they are not considered WebRTC compliant. To me, this seems like a rather unreasonable expectation. Developers should be able to choose which codec they ship, and not be forced to do 2x the work to become compliant.
I would love to hear from other developers on this. Do you plan on implementing both VP8 and H.264 in your apps?
Hookflash posts now on Tumblr
I have decided to stop posting Hookflash content here, all of my new Hookflash posts will appear over at Tumblr.
/Erik
Hookflash Concert Tour
We had a great Hookflash shaker last night! Had a blast showing off our new baby with Trent, was such a pleasure spending time with everyone.
So, what’s next you ask?
Mountain View – March 7
SFO – March 16
SoMa – March 21
Skype for SIP, it's about time!
+ 
Back in 2004 I wrote a post relating to the VON Canada Panel I sat on with Niklas Zennstrom. It was an interesting debate on open standards (SIP in this case) and closed networks, specifically Skype. I was quite vocal about how silly I thought Skype was not to include SIP, a few of you picked up on that 😉
It looks like something good came of the eBay purchase as we now see a Skype pushing towards open standards, good stuff!
On a similar note, I heard a rumour that it’s likely Jason Fischl the current CTO at Counterpath (Xten) will be going over to work with Jonathan Christensen (General Manager – Media Platform) at Skype. Jason was an early advocate of SIP in the IETF and works with some of the best minds on the subject: Cullen Jennings, Robert Sparks, Alan Duric come to mind.
This could get interesting.
I will do some testing with SkypeforSIP & Response Point and post the results along with my comments on what this new offer from Skype might mean for Response Point.
Andy's 2.0 Telco Top 10
Thanks for the mention Andy, I have been busy with my own projects for the last couple of years but I appreciate the fact you still remember some of the projects I had some significant success with, just a wee bit disappointed you forgot to mention them, that’s what I get for not speaking at eComm I guess 🙂
The list of course is bang-on, considering the source that should be no surprise.
I will in fact see become more active this year as my latest startup “SMB Phone” ramps towards general availability and launch. My last conference calling service provider startup “Lypp” is on auto-pilot and is growing nicely, thanks in part to Jay Phillips and adhearsion. The next stop for me will be at Internet Telephony Expo in Miami where I will be talking a bit about why we chose to build a new ITSP “SMB Phone” serving Microsoft’s new Response Point PBX.
Here is the Response Point Seminar schedule:
Tuesday, February 3rd Presentations:
4. An Integrated Solution: SMB Phone Goes to Market
with Response Point
3:00 pm
SMB Phone is a unique VAR and ITSP. Come learn how they identified Response Point as a key technical and business component in their nation-wide go to market programs focused on SMBs.
Presenter(s): Trent Johnsen, VP Business Development – SMB Phone
Wednesday, February 4th Presentations:
3. Response Point Service Provider Roundtable
Interact with the key members of the Response Point Ecosystem. Service Providers will be represented and open to discuss their service offerings and VAR/Agent programs.
Presenter(s):
Bandwidth.com, Cbeyond, Junction Networks, NGT, Packet8, SMB Phone, TotalTel
If you will be attending the show and would like to schedule a meeting, please email Trent Johnsen or myself or call us toll free: 1.866.473.0516 , say either “Trent” or “Erik”.
Ribbit sold, what's going on with Lypp?
Already a couple of days old now is the news that Ribbit just sold for $105m with (£53m) in cash. A congratulations is in order for Ted Griggs and his crew!
Due to this news Lypp is receiving a bit more attention and I have recently been asked by a few interested parties, “What are you going to do with Lypp?”.
The short answer is “We are building a profitable company.” The long answer is, “We are building a profitable company.”
Next week as we will be announcing the availability of the Lypp Teleconferencing service in more than 20 countries Worldwide with more to come shortly thereafter. Countries in this next release include; UK, Australia, Germany, Netherlands, Hong Kong and 15 more.
The international rates will be competitive, as an example Australia will be the same price as our North American rate at 9 cents/min with zero long distance calling costs. International Toll Free will be unnecessary considering Lypp calls all the meeting participants, in all countries served, at the time of the meeting.
So that is what is going on with Lypp. We are on track and I am thrilled with our progress. Yes, there are some interesting conversations in play and we will see where that takes us but the end game is to create a healthy company that continues to grow.
Home baked SEO lands Lypp.com on page 1 of Google
As a guest contributor for Techvibes I recently wrote a story about my journey through the land of SEO. It is my quest to make Lypp the number 1 conference call service in North America. I knew SEO would play a huge part.
I managed to take lypp.com from page 61 to page 1 in 7 weeks for key word phrase “conference call” on both google.com and google.ca. No small feat considering there are nearly 60 million results for that term on both sites.
You can read the entire story at Techvibes.
Cheap Mobile Calls in Canada
I had a great conversation today from a new Lypp user who was blown away by the Lypp mobile calling service that is current being offered at Lypp.com. The one thing that this gentleman kept reiterating was that mobile calling in Canada is so costly and how Lypp service all of North America for one low price.
It was so great to have some positive feedback on the service and I hope they will be even happier when they see the new features we are unleashing in February.
Next month we will be launching a new Next Generation Conference Calling service but at the same time we will be enhancing the current mobile offering at Lypp.com. Lypp mobile calling users in Canada will soon be introduced to a host of new features that we believe will enhance their mobile calling experience, at no extra cost.
WebRTC.is 