Microsoft Teams, Direct Routing and SBCs (pt.1)
My journey creating a scalable SBC as a Service for Microsoft Teams Direct Routing is over at Snapsonic.com.
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.
Open and secure alternative to Skype
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.
What do you think?
Security and Spam Server Released
Security is a hot topic these days and Anti-SPAM solutions even hotter. Yesterday Eyeball networks released their Anti-SPIT server as the newest addition to their product lignup.
One of the FEW Anti-SPIT solution available today, perfect for Carriers, MSOs and New Era IP Communications providers.
VoIP Security
VoIP Security gets more attention as Phil Zimmerman builds prototype of PGP VoIP.
Wired features an interview with Zimmerman on PGP VoIP.
Excerpt…
Like PGP and PGPfone, which he created as human rights tools for people around the world to communicate without fear of government eavesdropping, Zimmermann hopes his new program will restore some of the civil liberties that have been lost in recent years and help businesses shield themselves against corporate espionage.
It should be interesting to see what the VoIPSA (VoIP Security Alliance) and the others involved at the IETF have to say about Zimmerman’s proposal.
VoIP Security in a nutshell:
Eavesdropping – Listening in / recording calls without the participant’s consent. I think it would probably be easier to for the average hacker to jack into the PSTN network as the tools are already abundant for that.
Denial-of-service (DoS) attacks – Usually a packet storm aimed at a critical central server in the VoIP network of choice
Registration or Identity Theft – SIP traditionally requires the registration of an IP address with their SIP ID or URI. Today this URI can be spoofed, that needs to get fixed and the IETF gurus are working on it.
SPIT (Spam over Internet Telephony) – Spammers can create a spam engine that blasts a great number of calls per second.
SPIM – (Spam over Instant Messaging) – Bulk and potentially malicious spam sent to an IM user’s ID. Since many of the new applications are IM/VoIP apps we need to consider this.
Caller ID Phishing – Spammers can recreate the caller ID being sent to any one they chose, making it harder to NOT pick up the phone.
One thing is for sure, we need to work on this. Spammers are smart, it won’t take them long to figure out how to make great sums of money sending junk calls to your phone.
More on SPIT, SPIM and SIPS
The world of IP Communications is changing, so is SPAM. We have had to deal with it in email and now we are seeing evidence in IM and VoIP. AOL even filed a suite regarding SPIM last year. >SPIT is also getting a great deal of attention these days and I think it’s obvious that everyone will have to include some defence against the issues headed our way. The open standards bodies are proposing that TLS, S/MIME, SRTP, Secure certs and SIPS will help aid in the defence us against this attacks. I happen to believe that all of those smart people in the IETF form the line of defense, it’s up to the software developers to integrate it, for that you can count Xten in. Security in Xten product is to be deployed in the next release due out late summer.
Secure VoIP – Good or Bad?
Xten will be releasing an initial build of Encrypted X-PRO within the next few weeks to be used with the Free World Dialup’s and SIPphone’s of the world. It will only be sold to US and CDN consumers mainly to combat corporate espionage. The keys are created dynamically and then destroyed the moment the encryption is turned off. Considering this and the fact we are using AES 256 bit encryption, it will be extremely difficult for anyone to tap these calls.
We built this application to assist legitimate corporations who are trying to protect themselves against others trying to eavesdrop on their conversations and conference calls. We obviously did NOT build this application to assist terrorists and alike in their criminal activities.
Xten is researching many ways to make sure we are not assisting the wrong people when we bring this product to market. We know we don’t have all the answers so we are asking readers for their input in this regard.
What do you think? Are we dreaming or do you think this product along with other encrypted VoIP products will do more good than bad.
Feds Push VoIP Wiretapping
The FBI and the Justice Department have renewed their efforts to wiretap voice conversations carried across the Internet.
The agencies have asked the Federal Communications Commission to order companies offering voice over Internet Protocol (VoIP) service to rewire their networks to guarantee police the ability to eavesdrop on subscribers’ conversations.
Internet-to-Internet voice links like those offered by VoIP companies Vonage and Skype are closer to information services and fall into a regulatory gray area. The status of voice conversations carried through instant-messaging programs is even more unclear, as is the FCC’s ability to compel overseas VoIP providers to comply with U.S. rules.
Secure VoIP & SIP
The next big question for SIP is security. How will we ensure ourselves that the call is not being overheard.
Professionals from every corner are working on a Secure method for using SIP in VoIP. That much is evident by the action on the IETF SIP threads and SIP Authentication, SCTP and TLS methods already in use.
Other methods have also been implemented from several vendors which provide a more comprehensive and imediate fix for Secure SIP Voice conversations and conferencing.
Xten has developed and recently released X-Cipher which is a SIP softphone that has some very unique encryption capabilities. This SIP endpoint can readily be turned into a highly secure IP soft phone at the click of a button. X-Cipher requires a server component that also must be deployed. Here is a snapshot of the offering:
X-Cipher Solution:
– MD5 or SHA1 challenges
– 3DES or AES 128, 192 or 256 bit encryption
– Crypto safe random generators
– X-Cipher to X-Cipher complete encryption
– X-Tunnels NAT traversal functionality
For more on Secure VoIP, check out X-Cipher on Xten’s website.
WebRTC.is 