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.
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
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:
Chrome on android – answer:
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.
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!!
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.
How long is it going to take before we see Apple living up to their commitments? Hopefully not long, I for one would love to see a FaceTime (and iMessage) API.
Imagine a new secure P2P (Skype like) offer that also supported SIP in the client. You could use the client software on it’s own (just like Skype) or attach it to just about any VoIP service or phone system for free.
Does it make sense for consumers?
Does it make sense for business users?
Is there room in the market?
Would you use it?
Martyn Davies chimes in…
I would use it, but as a telecom industry insider, I know that I’m not the average business user or consumer. As to whether there is room in the market, I think that depends a lot on what Microsoft do with Skype now that they own it. From a business point-of-view, their efforts are focused around OCS/Lync (and software licenses), so Skype there is not adding to their central proposition. Skype has a lot of users, but produces very little revenue, since the majority just use the free services. As a Skype competitor you would have the same problems getting to the cash.
Skype was really the first company to take VoIP and make it completely trivial to install and use. To do that, they had to take some liberties and deviate from standards (like SIP), so that they could add the magic that made it work from behind firewalls, add security and self-configuration, and integrate video so seamlessly. Like Facebook, once it is clearly the biggest of its kind of services, it becomes the community that everyone must join. I can’t see that another Skype-alike has a way in, unless Microsoft significantly change the rules now.
It looks like the first victim in the Microsoft acquisition of Skype is Digium and the open source PBX – Asterisk. The following is an email sent to existing Skype for Asterisk users…
Skype for Asterisk will not be available for sale or activation after July 26, 2011.
Skype for Asterisk was developed by Digium in cooperation with Skype. It includes proprietary software from Skype that allows Asterisk to join the Skype network as a native client. Skype has decided not to renew the agreement that permits us to package this proprietary software. Therefore Skype for Asterisk sales and activations will cease on July 26, 2011.
This change should not affect any existing users of Skype for Asterisk. Representatives of Skype have assured us that they will continue to support and maintain the Skype for Asterisk software for a period of two years thereafter, as specified in the agreement with Digium. We expect that users of Skype for Asterisk will be able to continue using their Asterisk systems on the Skype network until at least July 26, 2013. Skype may extend this at their discretion.
Skype for Asterisk remains for sale and activation until July 26, 2011. Please complete any purchases and activations before that date.
Thank you for your business.
Digium Product Management
One has to wonder what will become of Skype Connect, Skype’s answer to SIP Trunking. Will Microsoft shut off the Skype Connect vendors (Cisco, Avaya, Grandstream, etc.) as well?
Original forum post here.
My Chief Architect and I arrived in Prague today to attend the 80th IETF meetings. 12 hours in planes and airports makes Erik a very sad man 😦
I have been working with the folks over at ImmersiFind on a mobile voip project for the past 8 months, the invite-only beta went live yesterday in the iTunes app store. It’s called “gabpark”. It’s been tested on the iPhone, iPod Touch and the iPad. In my humble opinion, it has some cool features that many should find quite useful.
The service is free during the invite-only beta period. I have a few invites for bloggers who are interested in getting a sneak peak, just email erik AT sipthat.com.
iTunes Store Overview
Gabpark is a new fun way to communicate with your family, friends and colleagues. Gabpark allows you to make and receive calls phone calls over 3G (Cellular Data Network) or WiFi. It works on both iPhone, iPod and iPad devices running OS 3 or higher. Never pay for roaming charges again!
Turn your iPod Touch or iPad into a phone in just a couple of minutes! Use the Follow-me feature and gabpark will call up to 3 of your alternate numbers at the same time! Use your cellular phone, home and work numbers or any 3 numbers in North America! Gabpark Voicemail allows you to see and hear your voicemail without having to call in for messages! Share your voicemails with anyone!
Change your Caller ID to match any of your existing numbers!
Gabpark is currently available via invitation. Invite up to 50 of your friends right from the app so they can enjoy Gabpark FREE calling in North America!
• Free calling in US and Canada!
• Get a phone number nearly anywhere in Canada or the US
• Receive calls even when the gabpark app is not running.
• Choose up to 3 follow-me numbers and gabpark will call them all at the same time.
• Gabpark voicemail can be seen and heard right in the app.
• Share voicemail with friends and family at the click of a button.
• Voicemail to email.
• Record up to 9 new voicemail greetings right from the app.
• Record calls from any phone you receive a gabpark call on.
• Blacklist. Add unwanted callers to your Blacklist and when they call your gabpark number they will hear a busy tone or a “This line has been disconnected..” message.
• Integrated with your contacts.
• See recent calls.
• Calls do not count towards your cellular calling plan.
• Compatible with iPhone, iPhone 3GS, iPod Touch and iPad.
• Built-in VoIP connection test.
Free calling requires free and instant registration to protect against abuse.
*IMPORTANT VOIP OVER CELLULAR / 3G NOTICE*
Because some mobile network operators may prohibit or restrict the use of VoIP (Voice over Internet Protocol) functionality over their network, such as the use of IP telephony over a cellular network, and may also impose additional fees, or other charges in connection with VoIP. As the user of this application, you agree to learn and abide by your cellular carrier’s network restrictions. Immersifind Inc. will not be held liable for any charges, fees or liability imposed by your carrier(s) for the use of VoIP over cellular networks.
*IMPORTANT Non-Availability of Traditional 911 or E911 Service*
END USER MUST MAINTAIN AN ALTERNATE MEANS OF REQUESTING EMERGENCY SERVICES. END USER acknowledges and understands that COMPANY does NOT support traditional 911 and E911 access to emergency services. END USER must maintain an alternate means of accessing traditional emergency response services.
UPDATE: It’s looking good folks!
In the agreement…
3.3. 23 Because some mobile network operators may prohibit or restrict the use of Voice over Internet Protocol (VoIP) functionality over their network, such as the use of VoIP telephony over a cellular network, and may also impose additional fees, or other charges in connection with VoIP, You agree to inform end-users, prior to purchase, to check the terms of agreement with their operator, for example, by providing such notice in the marketing text that You provide accompanying Your Application on the App Store.
9. Third Party Terms of Agreement: You must state in the EULA that the end-user must comply with applicable third party terms of agreement when using Your Application, e.g., if You have a VoIP application, then the end-user must not be in violation of their wireless data service agreement when using Your Application.
Now that we know VoIP over the cellular data network is allowed, and ATT has said they will support it, and ATT has a cheap unlimited data plan (Listen up Rogers, Telus, Bell!), the iPad and iPhone has just become something I think we should be excited about.
Apparently the new iPhone dev agreement has officially been modified allowing for VoIP over the cellular data networks. Trying to confirm that myself.
If this is the case, the iPad and iPhone just got a whole lot more interesting.