Earlier this month Fippo published a post analyzing Slack’s new WebRTC implementation. He did not have direct access or a team account to do a thorough deep dive – not to mention he is supposed to be taking some off this month. That left many with some open questions? Is there more to the TURN network? How does multi-party calling work? How exactly is Slack using the Janus gateway? Fortunately WebRTC has an awesomely active and capable community that quickly picked up the slack (pun intended).
Dear Slack,
There has been quite some buzz this week about you and WebRTC.
WebRTC… kind of. Because actually you only do stuff in Chrome and your native apps:
I’ve been there. Launching stuff only for Chrome. That was is late 2012. In 2016, you need to have a very good excuse to launch something with WebRTC and not support Firefox like this:
Maybe you had your reasons. As usual, I tried to get a dump from chrome://webrtc-internals to see what is going on. Thanks to Dag-Inge Aas for providing one. The most interesting bit is the call to setRemoteDescription:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
type: answer, sdp: v=0 o=- 1242503183783 1242503183783 IN IP4 127.0.0.1 s=Room with no name.. t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS janus m=audio 1 RTP/SAVPF 111 c=IN IP4 10.9.4.95 a=mid:audio a=recvonly a=rtcp-mux a=ice-ufrag:rKmT a=ice-pwd:AOrIm8kDxew5sVNUCQrrmJ a=ice-options:trickle a=fingerprint:sha-256 C5:5F:DA:7D:84:47:B1:BF:6B:55:16:62:48:31:3E:D3:F1:7B:25:89:92:4A:4B:4D:4D:D9:D5:AF:EA:D8:15:44 a=setup:active a=connection:new a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1; usedtx=1 a=candidate:1 1 udp 2013266431 10.9.4.95 12000 typ host a=candidate:2 1 udp 2013266431 172.31.0.190 12000 typ host |
I would like to note that you reply to Chrome’s offer of UDP/TLS/RTP/SAVPF with a profile of RTP/SAVPF. While that is still tolerated by browsers, it is improper.
Your a=msid-semantic line looks very interesting. “WMS janus”. Sounds familiar, this is meetecho’s janus gateway (see Lorenzo’s post on gateways here). Which by the way works fine with Firefox from what I hear.
Two weeks ago Philipp Hancke, lead WebRTC developer of Talky and part of the &yet‘s WebRTC consulting team, started a series of posts about detailed examinations he is doing on several major VoIP deployments to see if and how they may be using WebRTC. Please see that post on WhatsApp for some background on the series and below for another great analysis – this time on Facebook Messenger. {“editor”: “chad hart“}
Last week, Facebook announced support for video chats in their Messenger app. Given that Messenger claims to account for 10% of global mobile VoIP traffic, this made in a very interesting target for further investigation. As part of the series of deconstructions, the full analysis (another fifteen pages, using the full range of analysis techniques demonstrated earlier) is available for download here, including the wireshark dumps.
One of our first posts was a Wireshark analysis of Amazon’s Mayday service to see if it was actually using WebRTC. In the very early days of WebRTC, verifying a major deployment like this was an important milestone for the WebRTC community. More recently, Philipp Hancke – aka Fippo – did several great posts analyzing Google Hangouts and Mozilla’s Hello service in Firefox. These analyses validate that WebRTC can be successfully deployed by major companies at scale. They also provide valuable insight for developers and architects on how to build a WebRTC service.
Unnatural shrinkage. Photo courtesy Flikr user Ed Schipul
One evening last week, I was nerd-sniped by a question Max Ogden asked:
That is quite an interesting question. I somewhat dislike using Session Description Protocol (SDP) in the signaling protocol anyway and prefer nice JSON objects for the API and ugly XML blobs on the wire to the ugly SDP blobs used by the WebRTC API.
The question is really about the minimum amount of information that needs to be exchanged for a WebRTC connection to succeed.
WebRTC uses ICE and DTLS to establish a secure connection between peers. This mandates two constraints:
Last year we interviewed Oleg Moskalenko and presented the rfc5766-turn-server project, which is a free open source and extremely popular implementation of TURN and STURN server. A few months later we even discovered Amazon is using this project to power its Mayday service. Since then, a number of features beyond the original RFC 5766 have been defined at the IETF and a new open-source project was born: the coTURN project.
Today we are catching up with Oleg again to see what’s new and to learn what coTURN is about.
Amazon aggressively market’s its Mayday button for the Kindle. Does this use WebRTC?
Many in the industry, including myself, reference Amazon’s Kindle Fire HDX Mayday button as using WebRTC or at least as something that is WebRTC like. The Kindle Fire HDX is not available everywhere, so if you have not seen this the Android Authority has a good video of this feature here.
First lets think about how we tell if an app is using WebRTC. If the app is a webpage it is fairly simple – just look for the use of the getUserMedia and CreatePeerConnection APIs in the site’s Javascript using your browser’s developer console. It is a little more complex if WebRTC is embedded inside a native application. We could start with a debate about “What makes an app a WebRTC app”? If it uses part of WebRTC source code and not the W3C API’s does it count? Since this blog is for developers, not philosophers, let’s start by figuring out what Mayday actually does by looking at a Wireshark trace.
For the last year and a half I’ve been working with a number of customers helping them to understand what WebRTC is about, supporting them in the definition of new products, services, and in some cases even developing WebRTC prototypes/labs for them. I’ve spent time with Service Providers, Enterprise and OTT customers and the very first time I demoed WebRTC to them, after the initial ‘wow moment’ almost all of them complained about the ‘call setup delay’, as in some cases represented tens of seconds.
As Reid previously introduced in his An Intro to WebRTC’s NAT/Firewall Problem post, NAT traversal is often one the more mysterious areas of WebRTC for those without a VoIP background. When two endpoints/applications behind NAT wish to exchange media or data with each other, they use “hole punching” techniques in order to discover a direct communication path that goes from one peer to another through intervening NATs and routers but not traversing any relays. “Hole punching” techniques will fail if both hosts are behind certain types of NATs (e.g. symmetric NATs) or firewalls. In those cases, a direct communication path cannot be found and it’s necessary to use the services of an intermediate host that acts as a relay for the media or data packets, which typically sits on the public Internet. The TURN (Traversal Using Relays around Nat) protocol allows an endpoint (the TURN client) to request that a host (the TURN server) act as a relay. So far TURN, along with ICE and STUN, has seen little deployment. Now that it is a fundamental piece of WebRTC, it is gaining some momentum. In fact, at the IETF we’re now starting a new effort that will focus on enhancements to TURN/STUN that will be applicable to WebRTC deployments. This new effort is called TRAM (Turn Revised And Modernized), and we’re currently discussing its charter.
Most folks that set out to write an application, or build an architecture, begin with nothing but features and functionality in mind. Many might start out assuming they will be traversing flat, reliable, and secure networks. Inevitably, reality sets in as one starts to demo or prototype much beyond the friendly confines of the lab, and suddenly you begin finding scenarios not working properly, quality issues cropping up, or your stuff gets hacked. “Phase 2” of the design emerges, backing in all the necessary tools to cover the gaps.
