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.
Vancouver WebRTC – Meetup 2 @PlentyofFish
With more than 40 members and growing, Vancouver WebRTC now has a new venue! Chris Simpson from PoF rallied to get us into their new presentation lounge, the “Aquarium”, thanks Chris!
Our next event is on June 25th from 6-8pm and we have a great evening planned with Omnistream and Perch presenting!
Vancouver WebRTC – Inaugural Meetup Tonight!
Join us this eve at Launch Academy for the very first Vancouver WebRTC meetup!
This inaugural meetup should be a real fun event! I will be providing an introduction to WebRTC and Tobias Noiges (QHR Technologies) will be walking us through the creation of Medeo, a medical virtual visit application based on WebRTC.
Join us and learn about WebRTC and how it’s forever changing communications on the web!
Meeting info:
Location: Launch Academy #300 – 128 West Hastings Street, Vancouver, BC
Date and Time: Wednesday May 27, 2015 6-8pm
Buzz in Code: #300 or DM @elagerway on twitter
Agenda:
– Welcome!
– WebRTC Introduction; Erik Lagerway, Hookflash
– WebRTC in the real world; Tobias Noiges, QHR Technologies
– WebRTC Demo; Tobias Noiges
– Q&A
Hope to see you there!
/Erik Lagerway
WebRTC Meetup – Vancouver
Vancouver is one of the hotbeds for IP communication technology and is home to many developers. With the advent of WebRTC, integration of voice and video chat into almost any application is within reach but as always, there are always pitfalls. Sounds like a great reason to start a WebRTC meetup in Vancouver!
As of today Vancouver now has its own WebRTC meetup group. If you are interested in linking up and talking to like-minded RTC geeks implementing real time comm using WebRTC please join and let’s get together. We will also be looking for meetup facilities & sponsors (snacks, drinks etc.).
I am thinking our first meetup will be in May sometime, not sure on exact dates yet.
Agenda and topic for the first meeting is wide open. Topics like, “WebRTC 101” or “Dos and Don’ts” come to mind, but we can decide on that when we have heard from some active members.
We will also be bringing in some live guests from time to time via what else, WebRTC!
Hope to see you soon!
/Erik
Will Rogers follow AT&T's lead and allow VoIP over 3G? Yes.
Yes, they will.
Jailbroken iPhone running VoIP over 3G on Rogers
1. Rogers has cornered the GSM market in Canada and is the only carrier to offer the iPhone, but that is about to change. Telus and Bell have tag-teamed to erect an HSPA+ network and will be offering the iPhone as early as next month. Just in time for the holiday season and with plenty of time to ready themselves for the 2010 games in Vancouver.
It’s true that 3G is not yet ubiquitous which mean VoIP over 3G is not something that will drive massive adoption in the near term, but it will be enough of a detractor for a good percentage of the users to not choose Rogers if Telus and Bell allow VoIP over 3G on the iPhone.
2. Rumors have it that Globalive / Wind Mobile is hot on trail of Rogers and will be completing Phase 1 of their network build-out as early as this spring. They too might be carrying the iPhone. None of the big three want to get beat out by the new guy on the block.
3. Other devices on the Rogers network already have apps that deliver VoIP over 3G service. It’s not the network that is the limiting factor here, it’s the Apple app store and the contract they have with the carriers representing the iPhone.
4. Net Neutrality. I am sure that Rogers would like to avoid getting dragged into the same kind of kerfuffle the FCC has been crowing about in the US. The Internet does not stop at the desktop, so why should those it be left out of such conversations, it simply shouldn’t.
It’s should also be clear that Apple would prefer it if the carriers would allow VoIP over 3G. It would mean more devices sold and more interesting apps in the app store. I just can;t see Apple saying “no thanks” to VoIP related (product and service) revenue in the app store.
I think the question is more a matter of ‘when’ as opposed to ‘if’. Hopefully it’s soon!
Response Point VPNs and Remote Workers
I wrote an article over at the SMB Phone blog on Response Point VPNs and remote workers. If you are having some issues with VPNs and Response Point this might help.
Response Point Rapid Turn Around
First off let me just say that this team continues to blow me away. They listen and respond, go figure!
Yesterday the RP team addressed some concerns over loosing “barge-in” in the latest Service Pack and added that feature back in for a new build, now available. Yep, you heard right. This is not a patch, it’s a new build. If you know anything about the development of commercial software you would certainly agree that a 2 week turnaround (from SP 2 launch in Miami) on a new build is pretty damn impressive.
In addition, they have seemed to fix a few issues that I missed in my first pass/review of SP2. Since I am a Mac guy, I run all of my Windows software in a VM. Until SP2 there were a few quirky issues (Netbios ?) that made it impossible to do a few things easily or at all. The use of Assistant was simply not there on a VM and Administrator needed the base unit IP to connect. Sending recording prompts to phones (record name, greetings, etc) would belch as well. The RP team seemed to have remedied all of those issues with this release. Administrator and Assistant now work seamlessly, which means they work on a Mac, which makes me happy.
Vancouver Small Business Server User Group – Response Point
Join Erik Lagerway and Trent Johnsen, co-founder/executives of SMB Phone to see how Microsoft Response Point is changing small business communications and what it means for you and your customers.
SMB Phone is a national Response Point distributor and Canada’s newest Microsoft certified Internet Telephony Service Provider (ITSP) and the only provider to be integrated with Response Point in Canada. Along with a working demo/overview of Response Point, SMB Phone will provide an insider’s industry perspective on Microsoft Response Point and the latest software release, Service Pack 2, and how you can improve your customer’s business communications and enjoy significant new business opportunities working with Microsoft Response Point and SMB Phone.
3/12/2009 | 6:30 PM – 8:30 PM
Welcome Time:
3/12/2009 6:00 PM Pacific Time
The BC Liquor Distribution Branch (BC LDB)
3200 East Broadway (Okanagan room)
Vancouver, BC V5M 3T5
Canada
SMB Phone Goes to Market with Response Point
For those at IT Expo, this free session is about to begin in Room 109.
4. An Integrated Solution: SMB Phone Goes to Market
with Response Point
3:00 – 4: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.
Presented by:
Trent Johnsen, Vice President, Business Development, SMB Phone
Response Point Service Pack 2 (SP 2) is GA
The Response Point team have done it again. Response Point SP 2 is now generally available.
Some new features include:
– 1 way paging
– 2 way intercom
– After hours / time of day rules
– Out of band DTMF
WebRTC.is 