CODEWITHSUNDEEP
javascriptwebrtcstun
Anoosh
Anoosh

Reputation: 155

What type of connection is present between SFU & Client machine?

I have considerably read about WebRTC, ICE, Stun and Turn.

Now, When it comes to SFU, I'm not sure, what connection is established between client(end user browser) & the SFU (is it a webrtc connection ??). Could someone elaborate the flow ?

My assumption: When it is SFU based architecture. SFU & Client establish webrtc connection & send data to each other. SFU knows all the people in the current room & sends the data accordingly. Initial signalling gets the ice candidates of the sfu server to the client & vice-versa.

Am I correct ?

Upvotes: 1

Views: 666

Answers (1)

jib
jib

Reputation: 42450

Yes the connection between a client and an SFU is a WebRTC connection. The SFU is acting as a peer end-point.

There's no distinction made in the w3c specification between a peer and an SFU, except it leaves out defining reception of simulcast in browser-based clients, something you'll need an SFU (or MCU) for.

Typical flow

  1. Do a regular offer/answer exchange between each client and the SFU end-point over signaling.
    • If the server is the offerer it sends an offer to receive simulcast to the client. A normal offer, except the client can tell after setRemoteDescription it will be sending multiple encodings (layers) of a single video track:
    pc.getSenders()[0].getParameters().encodings.length // > 1 means simulcast
    • If the client is the offerer it must create an offer to send simulcast e.g. like this:
    pc.addTransceiver(videoTrack, {sendEncodings: [
  {rid: "hi"},
  {rid: "mid", maxBitrate: 500000, scaleResolutionDownBy: 2},
  {rid: "low", maxBitrate: 150000, scaleResolutionDownBy: 4},
]});
    You don't have to use simulcast for video, but it's common. Sending of audio is simpler and typically negotiated as well, along with client reception of both.
  2. ICE candidates get exchanged as a normal part of this negotiation (between client and SFU).
  3. Once multiple clients have connected, the SFU (Selective Forwarding Unit) typically receives audio and (simulcast a.k.a. multi-size) video from every participant, and in return usually sends each participant a large video and audio from whomever is currently speaking and smaller videos from (some subset of) everyone else. The specific selective forwarding logic is usually controllable by the application through signaling.

Each participant has an encrypted connection that terminates at the SFU middle-box, not with each other. This means that even though WebRTC is always encrypted, your connection to the other participants is not technically end-to-end encrypted. Therefore, make sure you trust or control your SFU. Standard solutions for e2ee over SFUs are in development.

Upvotes: 4

Related Questions