search

rarebreed / khadga

Web application to gather real time video and text data over WebRTC and websockets
Other
3 stars 0 forks source link

Implement STUN/TURN service #37

Open rarebreed opened 4 years ago

rarebreed commented 4 years ago

Initially we can use a public STUN server to try to get around client NAT issues. Eventually we will want to implement our own STUN and TURN server.

Ideally we only want to implement STUN since this will allow direct peer to peer communication. Using TURN will be bandwidth heavy for the service making it more expensive to run. The STUN protocol also seems more simple!e, plus all TURN servers are also STUN servers.

TURN STUN

rarebreed commented 4 years ago

There's a rust STUN server library, but it seems to be little used and somewhat abandoned. I'll probably take this and update it to the latest async/await syntax.

I'm also not going to implement TURN for now. TURN servers just eat up too much bandwidth even with just a handful of users. That would cost a fortune in the long run. STUN however has very little overhead in comparison.

Another option would just be to write my own STUN server based on the IETF protocol. It's only about 40pages long, so it might not be that difficult to implement.

rarebreed commented 4 years ago

Currently, with the existing signaling service code, eventually the ICE negotiation will fail, and at least on Firefox, it will say that TURN is needed.

What I noticed is that for both the caller and the callee, the remote videocam (MediaStream) is blank. This seems to suggest that either:

  1. There's something wrong with the mediastream and
  2. The track(s) on the callee/caller side aren't added right
  3. The stream data isn't coming through because it doesn't know how to reach the target

It's possible that my code works, but my test setup is wrong. Currently, I am testing this by opening up 2 different browsers on two separate machines logged in as 2 different users. On one system, I will right click on the other user, and start a video call (ie, the caller). Depending on whether i run the test on Firefox or Chrome, I get slightly different error messages. In either case, the ICE candidates will eventually fail.

I think I need to dig deeper into the actual ICE candidate objects, and see if the caller and callee are able to get the right IP address for each other. It's possible that they do have the right address for each other, but the way that the NAT on my router is set up, it is preventing traffic.

rarebreed commented 4 years ago

Even if i do get the video chat to work, I will still need to implement at least my own STUN server. Currently, for testing, I am using the Google public STUN servers, but this is bad form for a production environment.

As mentioned before, I will not implement TURN servers, because that's just too much bandwidth and will cost too much to implement for users. Perhaps with a paid service, this can be done, but not for now.