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.
Using Janus is somewhat surprising, too. I expected your own MCU thing. What happened?
Since you did not configure ICE-TCP and you are running on an odd port 12000 (on private ip addresses), you also configured a TURN server:
|
1 |
turn:slack-calls10.slack-core.com:22466?transport=udp |
Now… this is only using TURN over UDP. On an odd port 22466 that is about as likely to be open as port 12000 is. It will not work in most corporate environments where UDP is blocked. For those, you need TURN/TCP or TURN/TLS running on port 443. And hopefully there is no proxy server involved that requires authentication.
But Slack, do you really need to run a user-facing test to figure this out? This doesn’t look like the 21st century to me.
Best
Philipp
p.s.: Google Hangouts is moving away from sessions decrypted by a server in the middle. Maybe so should you?
{“author”: “Philipp Hancke“}
{“editor”: “Chad Hart“}
Don’t be so negative, it supports BUNDLE ;P
I was also expecting a custom media server optimized for large group communications (something forwarding only the media from active speakers and using less PeerConnections) but I think it is just a first step and it is great both for WebRTC and Slack fans.
Good catch about the RTP/SAVPF part, when I added support for UDP/TLS/RTP/SAVPF in Janus I then forgot to make sure the same protocol would be matched in answers as well. I’ll fix this shortly. As a side note, Janus definitely works on Firefox just as well as it does on Chrome, so not sure why they’re limiting access now (may be a UI thing).
That said, I hope you didn’t consider the weak part in your analysis to be Janus itself 🙂
Lorenzo: I have seen this bug way too often — thanks for eliminating one instance of it 🙂
All in all, this is very good news. Slack is a nice product with a solid users’ base. If they succeed in seamlessly integrating audio and video, they’ll certainly stay one step ahead of the pack of direct competitors. And I’m happy they’re leveraging Janus for the video part, obviously 😉
It is clear Slack have been working on this for some time since their acquisition of Screenhero back in January 2015. There was, and quite possibly still is, a fair amount of scepticism around this acquisition. They haven’t seemed to utilise Screenhero’s capability until recently. Slack are new to WebRTC and working out how it works exactly, let alone how best to integrate the service into Slack.
The announcement along with what you have mentioned above, has been designed to put a feeler out there, for people like us, to share their thoughts and assess the feasibility of implementing this. You can be reassured they will provide full support across all compatible browsers when they make the full official release.
Iwashi of HTML5 JP did a deeper analysis here: http://iwashi.co/2016/03/05/slack-webrtc-analysis.html
A few comments:
* As a developer, Firefox’s WebRTC implementation is a constant frustration for me. Their permissions dialogs are hard to work with. The bandwidth estimation is completely different and prone to errant interaction with Chrome. They have no FEC implementation. Their SDP parsing code is mediocre at best. Their implementation’s ability to adjust to network changes is dramatically worse than Chrome. And for reasons unknown to me, they’ve opted to borrow some code from Chrome, and write other portions themselves. Having worked extensively with Firefox and Chrome at this point, Firefox’s WebRTC implementation is beta quality at best.
* Given that Firefox is a small percentage of users at this point (and particularly so in business/enterprise), I completely understand their decision not to support it. Frankly, I’d be happy if Firefox stopped trying to write WebRTC code and just adopted google’s code entirely. Mostly all they’re doing is screwing things up for WebRTC at this point.
* Hangouts isn’t “moving away from” having an MCU/SFU. In your link, “To improve call quality and speed, Hangouts will route audio and video over a peer-to-peer connection when possible,” a Google spokesperson told VentureBeat. Translation: *when possible* they’ll go p2p. If it’s anything beyond 1 to 1 chat, my guess is they’ll route through an MCU/SFU.
i’m well aware of issues with Firefox and the usage numbers. I do not consider them an excuse given that Slack does not use anything affected by them.
Does that mean we should stop caring about interoperability? Great, we can just stop caring about the w3c too and just write code for Chrome!
Believe me, I’d love a solid product from Mozilla. But as a developer, the amount of flak I’ll take for a failed audio/video call isn’t worth 5% market share in big enterprise.
It definitely isn’t worth the amount of work to make an MCU/SFU handle Firefox’s implementation quirks.