Skip to content
Riz Panjwani edited this page Feb 27, 2015 · 21 revisions

2/26/2015 - Web-RTC Security Flaw

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."

2/23/2015 - Project 1 Deadline (Distributed Computing)

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.

2/22/2015 - Investigated Captioning

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.

2/20/2015 - Distributed signalling servers

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.

2/20/2015 - TURN server (which also inherently provides STUN functionality).

We have access to a SAVI cloud vm, so we tried setting up a few open-source TURN servers:

  1. Tried reTurn: Installation was fine, but could not connect to it even locally as it kept dropping the connection.

  2. Tried rfc5766, but it was too complicated to setup. Maybe later...

  3. 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.

2/8/2015 - Basic Front-end & Back-end (local)

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.

2/7/2015 - Investigation

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.

Clone this wiki locally