WebRtcServer on port 443 vs TURNS

Deployment & Scalability
1

I know a typical deployment would operate a TURNS server on TCP port 443 to get through restrictive firewalls or content filters. From that perspective I’m curious if there is much difference between running CoTurn (or similar) vs running a mediasoup instance with it’s WebRtcServer listening on port 443.
Would a firewall / content filter see the traffic to both the same way? Or would a TURNS server be more likely to connect as it uses the same TLS as https?

A couple thoughts about the pros and cons of each.

WebRtcServer over port 443
Cons

  • Can only run a single mediasoup worker per VM do to the single port (easily done with a single cpu core VM)
  • Must authorize non root user to bind to port 443 for security (can be done with authbind)
  • Must run Node API/Signalling on a non standard port (can be done with a reverse proxy)

Pros

  • Simplifies infrastructure (less server setup / maintenance with single application)

TURNS
Cons

  • Need to setup and maintain an additional server system / application
  • Additional cost for dedicated TURN infrastructure or service
  • Additional latency (if using a service instead of a VM in the same network)

Pros

  • Standard operating procedure - tested and proven to work reliably
  • ?

This post isn’t meant to be a “solve this problem for me post” with the answer “just setup TURN and be done”. My hope is to gain a deeper understanding of the differences between running mediasoup on TCP port 443 vs TURN over TLS on port 443 (if there is a difference), especially from the perspective of a firewall or content filter in a highly restricted network. Any insights would be appreciated.
Thanks

2

I think you exposed pros and cons properly.

3

Thanks Inaki. Any insights if a firewall or content filter would see the network traffic differently between the two approaches?

4

Of course. A firewall cannot detect what is sent over TLS (as turns does). mediasoup doesn’t use TLS even if it listens in port 443 (traffic is STUN, DTLS, RTP and RTCP), so a firewall may affect it.

5

That makes sense. One thing I’m still a little confused by. I was under the impression that DTLS is specific to UDP connections? So if the mediasoup WebRTCServer is set to only connect over TCP, does that mean that mediasoup and the browser are making a TLS connection the same way that TURNS is? Or does TURNS effectively make an encrypted tunnel and pass rtp/rtcp data through that tunnel?
I recognize this is not specific only to mediasoup. I have only a surface understanding of this subject, so I appreciate your help furthering my understanding.

6

No. If TCP is used in mediasoup for clients’ WebRTC connections then STUN, DTLS and RTP are encapsulated in framed TCP packets where the first two bytes indicate the length of the real packet. This is as per spec and this is not TLS at all.

Also, please don’t assume that RTP goes over DTLS. That’s not true. I insist:

  • STUN
  • DTLS
  • RTP and RTCP

Those are the types of packets transmitted in both directions in WebRTC, over UDP or over TCP as explained above.

7

Ah! I think I understand. I am going to go through and read the specs as I want to have a deeper understanding of the network protocols involved.
I had the (false) impression that DTLS was what provided encryption for RTP in a WebRTC connection. Looks like this is another area I need to read more into.