9 comments on “Dear Slack: why is your WebRTC so weak?

  1. 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.

  2. 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 🙂

  3. 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 😉

  4. 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.

  5. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *