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?
- 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.
- 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.
- 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
Post a Comment