Peer-to-server audio streaming using WebRTC

5
votes

I understand that to establish a peer-to-peer connection

initiator peer

  • initialises shared signaling channel
  • initialises RTCPeerConnection object (pc)
  • requests local stream(s) using getUserMedia
  • registers local MediaStream with pc
  • creates SDP offer and sends to peer
  • trickles ICE candidates
  • registers remote ICE candidate to begins connectivity checks

receiver peer

  • listens and processes remote offers delivered
  • registers remote ICE candidate to begins connectivity checks
  • generates SDP answer and sends to peer

But my WebRTC use case is peer-to-server where received streams are processed on my Node.js server. In my use case the server has publicly routable IP address and is listening for any new RTCPeerConnection requests. Because of this, some of the steps involved to establish a peer-to-peer connection seem unnecessary for my case.

  • Q1 How do the steps to establish a peer-to-server connection differ from peer-to-peer connection establishment?

Particularly

  • Q2 Do I still need a signaling channel?
  • Q3 Do I still need the step to trickle ICE candidates?
1
webrtc

1 Answers

4
votes
  1. Your peer-to-server connection is no different than a peer-to-peer. Meaning, that your server is just a peer that handles numerous connections. You will still need a unique connection for each connection to the server, so the steps would not differ at all on the connection set up. But you can reuse media streams.
  2. Yes, you still need a signalling server for connection build up and tear down for each of your clients and for your server to communicate(id est exchange ICE/SDP). It could be the same FQDN/physical box as your Node.js server but signalling would still have to take place.
  3. Yes, on the client side. Admittedly, your ICE candidates will be few for your server(since it is publicly accessible) and you may not have to query for them(should just use local IP and what ever ports are available if it is truly open for connections, which is not very secure...) but the client will still have to trickle candidates to the server so that the server's stream can hit the client.