-
Notifications
You must be signed in to change notification settings - Fork 0
Logbook
We decided to spin up a few Amazon VMs to host our signalling server. The signalling server keeps track of meeting rooms that are currently active and allows peers to join them. After the initial handshake, the peers just take over and communicate using Web-RTC.
We had 3 different servers (vms) and modified our client side code to be more fault tolerant by using the servers as fallback. We tested this by bringing down one server after another and it seems to work for now.
We have access to a SAVI cloud vm, so we tried setting up a few open-source TURN servers:
-
Tried reTurn: Installation was fine, but could not connect to it even locally as it kept dropping the connection.
-
Tried rfc5766, but it was too complicated to setup. Maybe later...
-
Trying restund now, which involves manually making and installing the old school ways!
We couldn't make any progress with the TURN server at this point. So we've decided to switch to something else.
We created a basic front-end for our site. We also got a signalling server running locally using socket.io. Right now we can locally video conference by using the signalling server to do the initial handshake and then use web-rtc to take over after that.
We investigated how Web-RTC works and tried out a few libraries to make our jobs easier: peerJs, Simple Web RTC, and MeetingJs. Web RTC requires signalling servers for the initial handshake. In addition, it requires STUN and TURN servers to deal with NATs. STUN servers extract external IP address for each peer thereby making communication possible. TURN servers take on the task of relaying traffic themselves in case STUN servers are not able to facilitate communication due to NAT issues.