2

i need to use the webRTC "capture of medias" part, and send the video/audio stream to a server. First I thought about using websockets to send that stream but it looked complicated, i only found some examples that drew the video into a canvas and sent the generated image thanks to websockets; heavy. So i think the best solution is to use the RTCPeerConnection api to create a one-to-one peer connection and then use the rest of this API to transfer the stream. Is that possible and not stupide? If it's not i would like to know if it's possible to create a simple ICE server to connect only two peers with a known IP (or is there a way to avoid using these ICE servers?)

Thanks for your answers! :)

Ernest
  • 121
  • 10
  • have you looked at MCU/SFU? – mido Apr 19 '16 at 02:45
  • No need to draw into a canvas. Use MediaRecorder. See [my answer to another question](http://stackoverflow.com/a/34997248/918910). – jib Apr 19 '16 at 16:26
  • Well i was actually looking into that. I suppose i can send recorded parts (as binary data) while i capture video/audio? (i just can't test it right now) – Ernest Apr 19 '16 at 17:03

2 Answers2

0

There's no such thing as an ICE server. ICE is a protocol (https://www.rfc-editor.org/rfc/rfc5245) for establishing network connections.

Apart from that if I understand your question correctly you want to use WebRTC to establish a media stream between two peers. If so the answer is yes, that's exactly what WebRTC is for. The WebRTC peers will take care of the ICE part themselves although if they are on different private networks you may have to involve a STUN and TURN server.

Community
  • 1
  • 1
sipsorcery
  • 30,273
  • 24
  • 104
  • 155
  • Hi, i want to do a "client-server" connection. So i was thinking about using webrtc peer2peer functionality and consider my server as a standard peer. But i would like to avoid (if possible) this STUN/TURN part, because obviously i know my server ip and my server can know my client ip easily. Thanks :) – Ernest Apr 19 '16 at 09:02
  • @Ernest nope, server would only know client's public, won't help if client is behind a NAT – mido Apr 19 '16 at 09:20
  • All right. So i must use at least a STUN server right? Do you know if there is another way to send my stream to the server anyway? – Ernest Apr 19 '16 at 09:40
  • @Ernest, if you know the public IP address on each peer you could manually edit the SDP before forwarding it to the remote peer but that's likely to be a very fragile approach. As for alternative approaches I don't know of any if you want a browser to browser streaming WebRTC is the way to go. There are lots of free public STUN and TURN servers (google runs some) why not just use those. – sipsorcery Apr 19 '16 at 09:47
  • So the question is, how can i make the server act like a simple peer? – Ernest Apr 19 '16 at 14:00
0

You are confusing P2P with Client/Server - these are two different things. WebRTC uses both - the discovery is Client/Server (Stun) and the streaming is P2P (ICE).

Discovery is essential to initiate P2P. The peers must know each other's IP addresses. That is where Stun comes in - it is a central registry (server) of peers, accessed with a Stun client.

Once two peers discover each other's addresses via Stun, they disconnect from the Stun server, and start streaming to each other directly via the ICE P2P protocol.

Dominic Cerisano
  • 3,522
  • 1
  • 31
  • 44
  • Thanks, but i do understand the basics of webRTC. What i wanted to do is: faking a one-to-one peer connection in order to transfer data from a client to a server. All right, this has nothing to do with ICE servers after all. Currently i'm just sending video chunks as binary data through websockets. – Ernest May 09 '16 at 10:34