Peer-to-server audio streaming using WebRTC -


i understand establish peer-to-peer connection

initiator peer

  • initialises shared signaling channel
  • initialises rtcpeerconnection object (pc)
  • requests local stream(s) using getusermedia
  • registers local mediastream pc
  • creates sdp offer , sends peer
  • trickles ice candidates
  • registers remote ice candidate begins connectivity checks

receiver peer

  • listens , processes remote offers delivered
  • registers remote ice candidate begins connectivity checks
  • generates sdp answer , sends peer

but webrtc use case peer-to-server received streams processed on node.js server. in use case server has publicly routable ip address , listening new rtcpeerconnection requests. because of this, of steps involved establish peer-to-peer connection seem unnecessary case.

  • q1 how steps establish peer-to-server connection differ peer-to-peer connection establishment?

particularly

  • q2 still need signaling channel?
  • q3 still need step trickle ice candidates?

  1. your peer-to-server connection no different peer-to-peer. meaning, server peer handles numerous connections. still need unique connection each connection server, steps not differ @ on connection set up. can reuse media streams.
  2. yes, still need signalling server connection build , tear down each of clients , server communicate(id est exchange ice/sdp). same fqdn/physical box node.js server signalling still have take place.
  3. yes, on client side. admittedly, ice candidates few server(since publicly accessible) , may not have query them(should use local ip , ever ports available if open connections, not secure...) client still have trickle candidates server server's stream can hit client.

Comments

Popular posts from this blog

c++ - OpenCV Error: Assertion failed <scn == 3 ::scn == 4> in unknown function, -

php - render data via PDO::FETCH_FUNC vs loop -

The canvas has been tainted by cross-origin data in chrome only -