9 comments on “Is Slack’s WebRTC Really Slacking? (Yoshimasa Iwase)

  1. I am not convinced that the standards should encourage, let alone recommend use of TURN/TCP & TURN/TLS, if the LAN policy is to expressly prohibit RTP traffic. Such tunneling mechanism is a renegade act and the correct way is for the affected users to lobby their local admins to relax the policy.

    Furthermore, we need to develop comm protocol between the applications and Middleboxes so that dynamic pin holes can be created. Use of these TURN schemes take the easy way out by pushing the problem under the rug.

    • It makes sense that relaxing the policy under the strict network such as enterprise world is a good solution. My opinion I forgot to write in the article is that the best path is P2P(no relay). If Slack allows us to collect host candidate it’s better.

    • Having deployed into dozens of large companies, lobbying local admins to “relax the policy” is often like arguing with a kitchen table. It simply will not happen.

      The reality is deploying inside of big enterprise requires TURN/TCP and HTTP CONNECT support for bypassing proxies. I am 100% convinced that to have broad WebRTC adoption, these absolutely must be part of the standard.

  2. The main reason Slack is forcing traffic through TURN is because otherwise they end up in a full-mesh configuration for multi-party chats.

    For example, if all traffic is p2p and it’s a five person conference, each participant is sending four streams, and receiving four streams. This simply doesn’t scale well given that most people have limited upload bandwidth. With a media server in the mix, each party pushes a *single* stream, and receives four streams: much less stress on an individual user’s upload connection. For audio-only, you might get away with full mesh.

    Furthermore, because they are an enterprise product, the reality is p2p is likely impossible. A TURN server isn’t a nicety; it’s a requirement. In many regards, it becomes easier to force all traffic through TURN than even bother with the complexities of ICE negotiation.

    Lastly, if recording content is of any interest, there is no good option besides MITM’ing traffic and recording at an MCU/SFU.

    • I’m not sure I understand your comment, here. TURN does NOT allow you to change a full-mesh topology: that’s what SFUs are for.

      The only thing TURN allows you to do is relaying media between two peers even in situations where this could be troublesome (e.g., see Symmetric NATs). In a full-mesh conference you’d still need to send/encode your stream multiple times even with TURN involved (you’d just have N relays transporting all of them).

      What you explain is addressed by SFUs, which allow you to publish your media just once, and then take care of making the stream available to all interested parties themselves.

      • Apologies–let me explain. I skipped a part and that was probably confusing.

        With any SFU, there still has to be a signaling channel. Almost without fail, that signaling channel is going to be some HTTPS-ish protocol over 443 (anything else is prone to failure for the same reasons WebRTC is prone to failure); for example, licode uses socket-io. However, this means the signaling server itself is likely listening on 443, which means: a separate TURN server is ultimately necessary.

        In other words, SFU for enterprise environments necessitates the use of a separate TURN server to listen on 443. And at that point, rather than bother with complicated ICE negotiation, it’s a lot easier to simply force all traffic through the TURN server.

        • Or, more simply put: once you’re dealing with enterprise and need to use an SFU, it’s a lot easier to just pump everything through TURN than bother with the corner cases.

          In any event, my original post is phrased incorrectly–sorry for being unclear.

  3. Pingback: RealTimeWeekly | RealTimeWeekly #123

  4. Its easy to understand why they FORCE turn servers. Exposing client IPs is becoming a big no no in software dev. With the rise of DDOSing, and the ease it can be done with the services standing by, exposing clients IPs in on way, its a bad idea.

    Even Skype isnt p2p anymore.

Leave a Reply

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