Test cases

We picked basic test cases at this point:

1. We connected two users to the same signalling server and made sure that the basic audio/video streams are sent and received.

2. Then when we added speech recognition and captioning, we tested sending the messages along with the videos on data channels between the peers.

3. We brought down the signalling servers while the peers had already established connection. This didn't affect the communication as we thought.

4. We brought down the signalling servers once a client had created a room. When the second client loaded the page, we didn't see the room as that information is gotten from the signalling server.

5. We took down the load-balancer. This killed all hopes for our poor application.

6. We used a tool called "Network Link Conditioner" to reduce our client bandwidth during a call. When we reduced the bandwidth enough, the Web-RTC component automatically adjusted the video frame-rate and audio quality to avoid stutter.

7. We had one client behind a symmetric NAT and tried to initiate a call with them. Since the STUN server couldn't traverse that NAT, the Web-RTC automatically fell back onto using the TURN server that we had specified as a relay server. We were able to capture this using a tool called "Wireshark".

8. We connected 4 clients onto a single call to try and take advantage of the built-in "mesh networking" feature of Web-RTC. We noticed that the quality got degraded, as we added more clients and by 4th client it was very low quality.

9. We generated some audio flac files to test Google Speech API. We generated two different versions of each file: 16k resolution and 44.1k resolution. We then sent these flac files to the Google Speech API to see if it affects the translation capabilities. We had some mixed results with this and it turns out that the biggest factor with accurate translations seems to be the speed of the speech.