3

Scenario: Webrtcpeer1 wants to send a video (send only data) to Webrtcpeer2. It turn out that webrtcpeer2 is behind a symmetric NAT and direct communication is not possible. Now both the peers contact a turn server and get their respective "relayed transport address" and share it with one other over the signaling channel along with their NAT " Server Reflexive transport address" as ICE candidates. Now a Webrtcpeer3 comes into the scene and wants to see the same video feed which webrtcpeer1 is sharing with webrtcpeer2. It turns out that webrtcpeer3 is also behind a symmetric NAT.

Questions:

  1. Will WebRTC stack allocate a new "relayed transport address" for webrtcpeer1 for communicating with webrtcpeer3? OR can webrtcpeer1 use the existing "relayed transport address" it received while connecting with webrtcpeer2.

  2. Does TURN support this? --> webrtcpeer1 sends a single video feed to the turn server( along with webrtcpeer2 and 3's "relayed transport address" info) and turn server somehow magically sends it to the respective "relayed transport address" of webrtcpeer2 and webrtcpeer3.

Mukesh Kumar
  • 302
  • 1
  • 2
  • 9

1 Answers1

2

1.) You need a new Relayed Transport Address for each peer. You need to create a new PeerConnection for each person you want to connect too. webrtcpeer1 can only connect to webrtcpeer2. You will need to create webrtcpeer1-1 (on the same host as webrtcpeer1) to communicate with webrtcpeer3

2.) TURN doesn't support that unfortunately. A SFU (Selective Forwarding Unit) does accomplish that though!

Sean DuBois
  • 3,972
  • 1
  • 11
  • 22
  • But SFU cannot solve the issue if the peer is behind a Symmetric NAT because peer to SFU connection is also webrtc. – Mukesh Kumar Nov 06 '20 at 07:58
  • 1
    the SFU is not so the client can connect to the public ip and the sfu can send back from the ip the client sends to which works with symmetric NAT. – Philipp Hancke Nov 06 '20 at 08:35