-
Notifications
You must be signed in to change notification settings - Fork 0
Logbook
Apparently we won the "community award". This was just an exhibit of a combination of two courses taught by our professor. We were one of the two winners out of around 35 projects.
Go here to watch the magic happen!
It has been a while since we updated our log. We finally got the load balancer working thanks to a suggestion from Cliff and Eric from Abebooks/Amazon. They suggested we retrieve the ip of the server that the load balancer first points us to, and then send that ip directly to our participant so that he can join our room.
Also now we immediately create a hash for a room and provide a private link that contains the server-ip and room name that the client can send to the participants.
We have been running into issues with the webspeech recognition. It stops working after a while. We think it's because it's vying for microphone control along with our app. We have put a workaround in place that checks the recognition status every 5 seconds and restarts it if it detects it isn't working.
We have been trying to analyze web-speech and web-RTC packets to verify the protocols that they use using Wireshark. Also we have been generating Flac files to hit the google web-speech server and try and collect some data around it. We have been doing this on our home network. The plan is to use the same files and run the tests on UVic network and compare the trip times, rates, etc. to see if there's throttling in place at UVic which can account for the speech recognition misbehaviour during our previous demo.
We have tried out the aws elastic load balancer. We haven't been able to figure out how to make sure that a client connects to a specific server behind the load balancer. Specifically for the following scenario:
- Client A starts a room on server A and sends a link to client B.
- Client B follows the link but is directed to server B by the load balancer.
We haven't really been able to find out how to configure the load balancer to accomplish this yet.
Our signalling is fault tolerant! We had been struggling with this for a while. This allows us to have fallback signalling servers which handle two scenarios very gracefully:
- Client A wants to start a meeting but is unable to contact the signalling server. In this case, client A will try and cycle through the available signalling servers till it can connect to one.
- Client A has started a meeting room on Server A and is waiting for client B to join. Server A crashed. In this case, Client A will detect that server A crashed and will cycle through available signalling servers till it can connect to one.
This still leaves the scenario where client A has started the room and while client B is joining, the server crashes. We probably won't tackle this right now and leave it to the clients to start a new room.
We finally have a basic credential-less turn server (rfc-5766) working on AWS. It took us a while to install and understand the configuration of it. Next we will figure out putting in credentials and run some performance tests on it. We will then see if we can put in some load balancing.
https://torrentfreak.com/huge-security-flaw-leaks-vpn-users-real-ip-addresses-150130/
"VPN users are facing a massive security flaw as websites can easily see their home IP-addresses through WebRTC. The vulnerability is limited to supporting browsers such as Firefox and Chrome, and appears to affect Windows users only. Luckily the security hole is relatively easy to fix."
We were rushing today to get the captioning going till the very end. We finally got something going. It's not as performant as we were hoping. There are huge delays between translations, and it doesn't catch everything (no matter how loudly and clearly you speak).
Another issue we had was using the Grunt/Yo/Bower tools for developing our front-end. We tried the front-end install instructions on Macbook, Windows machine, Amazon VM, and an Ubuntu VM. We kept having errors in installing some of the packages. Wasted a lot of time on that, but hopefully they should work
Then there's git. One of our teammates was improving the UI look and feel and he was accidentally working off an old branch. So in the end, we weren't able to merge his changes into the master branch because git doesn't seem to think there are any changes! But we also can't pull request because github can't auto-merge due to conflicts...
Good news is that we were able to get the fallback signalling servers going, and we were able to get the translations and audio/video going. It's just not very polished.
We've figured out how to convert speech to text using webkit recognition in Chrome. It took us quite a while to investigate how to send that text over to our peers. We will continue to investigate.
In the mean time, we are making sure that our front-end install instructions work perfectly. We've had some dependency issues when trying on different machines.
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.