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.
SIP Trunking and Hosted PBX in Canada will speed HD Voice for small business
SIP trunks are simply another way of saying VoIP Provider for your phone system. A SIP trunk is a connection from a PBX (phone system) using SIP (Session Initiation Protocol) to an ITSP (Internet Telephony Service Provider).
It might sound complicated but it’s really quite simple, SIP trunks take the place of your legacy telephone company. Most phone systems out there today are more than a couple of years old and are likely based on circuit switched technology. Newer IP-PBXs use packet switching technology, which means they leverage the Internet to deliver the same features you have now, and then some. The difference could be minor or major depending on what your PBX is capable of and what your ITSP can deliver in terms of features and functionality.
Since the PSTN (public switch telephone network) is tied to aging circuit switched technology it has limitations in terms of what media it can support. Essentially, it can deliver low quality voice, that’s it.
SIP Trunks replace older PRI and POTS interfaces that we are used to and bring to the table a wide variety of communications options. Depending on your IP-PBX and your ITSP you could potentially look forward to HD (High Defenition) Voice and potentially HD Video.
HD voice (and video) for small business in Canada will happen, it’s only a matter of time. As broadband providers increase upstream bandwidth and dual WAN link-failover devices become common place, SIP trunking will accellerate in growth and on-net (calls made on the ITSP network) HD Voice will become common place.
Unfortunately, HD communication off-net (eg. PSTN) is not going anywhere at any great speed. Jeff Pulver is back as he reboots the communications industry with his new HD Communication Summit. I welcome Jeff back with open arms, if anyone can convince operators to increase speed towards wide-band/HD adoption it would Jeff Pulver.
Today we can see SIP trunking providers and hosted pbx providers supporting wideband codecs and devices on their networks. This will allow user to communicate in high definition with other users that have devices that support it, in brief you could have better calls between you and your colleagues in the office and remote office workers connected to the same PBX, and that is a step in the right direction.
How much bandwidth do I need for Response Point? G.711 vs. G.729
G.711 is the default audio CODEC for most Response Point phones and requires approximately 90Kbps bandwidth upstream (your voice going out) and 90Kbps bandwidth downstream (your caller’s voice coming in).
To calculate peak usage take the peak concurrent callers x 90Kbps. For example: 5 concurrent calls x 90Kbps = 450Kbps is the required bandwidth for each direction. Keep in mind, this does not account for VPN usage for remote users or voice mail to email etc.
As an example, if you have a 1Mbps ADSL connection from your service provider, you might have an upstream bandwidth of approximately 700 Kbps. A conservative approach is to estimate just over half of the upstream bandwidth is available, ISPs generally over-sell their bandwidth. In this case, you could safely support 4 simultaneous G.711 calls if you were not doing anything else (e.g. downloading email, listening to online radio, downloading large files, etc.) on that connection.
The SMB Digital Voice network also supports G.729, which uses approximately 20Kbps bandwidth upstream (your voice going out) and 20Kbps bandwidth downstream (your caller’s voice coming in) for each call. G.729 provides very good call quality while minimizing bandwidth usage. The only noticeable difference would likely arise during on-net calls (calling other users on the SMB Phone network). G.711 offers a higher quality on-net call because G.711 does not compress audio, but as soon as the the call is handed off to the PSTN the call quality between G.711 and G.729 is hardly noticeable.
G.729 offers some real benefits, the most obvious is the 400% decrease in bandwidth capacity requirements. G.729 also handles Jitter more efficiency during times where low bandwidth / high congestion would likely render a similar call using G.711 unintelligible.
You can force your phone to use G.729 on Response Point handsets but some are harder to configure than others. For example, on Aastra 675x phones the global SIP settings are grayed out out via Javascript on page load making it tough to set the codec.
As a general rule of thumb, we like to recommend an independent broadband connection that you can use for Response Point. You may want to acquire a router that has dual WAN link failover, VPN Server (for remote sites) and some QOS traffic shaping functionality.
WebRTC.is 