we do measurements "literally" in the clouds. #webrtc #callstatsio #techcrunch #airplane #Norwegian #disruptlondon pic.twitter.com/AMx80JmCiS

— Varun Singh (@vr000m) December 6, 2015

Last weekend, Lasse was flying to London for TC Disrupt with Norwegian Air Shuttle. Norwegian offers free wireless connectivity to its passengers. Lasse and Varun were messaging each other before the flight and due to the onboard connectivity, they continued to strategize even after the plane took-off. When onboard, they realized that it was a good opportunity to test out the connectivity of WebRTC literally when in the clouds. Below is Lasse’s account:

Mid-air, I (Lasse) realised that we had a good opportunity to test how well a WebRTC connection between a person on an airplane and a person on the ground works. Also, we really wanted to see what kind of effect the “miles high” distance would have on the metrics we track.

Our first try was not much of a success. My browser got to the conference page and it looked that the page rendered correctly, but there was no WebRTC connection. WebRTC internals on Chrome confirmed my fears: no connection. Varun realised that we had a logistics problem, the service was incorrectly picking a TURN server on the west coast of USA, which took too long for the connectivity checks to succeed, ergo no connection was established . The connection hops between the airplane and Finland was: airplane somewhere between Finland and UK - satellite - land station (most likely) in Europe - TURN server in the US, finally, Varun in a coffee shop in Finland. Given that we already had a satellite involved, picking a TURN server in the US would not work!

Hoping to accomplish our goal, we switched to our demo app, it is not pretty and the TURN server is in Germany. Unlike before, we had a working WebRTC connection with video! I was surprised how good the video quality on the airplane was. I (the blue lines) was getting most of the time 1000-2000 kbps of throughput, which is a lot more than I expected on an airplane. Varun, on the other hand, was only getting 400-600 kbps of throughput. The disparity in the throughputs is consistent with how wireless works, the uplink to the wifi router is in contention, and the downlink is round-robinned, hence, getting media to me (lasse) was more consistent. This is also confirmed by the high uplink loss from me to Varun.

Throughput (sending bit rate and rendered bit rate) in the conference call. The plane was receiving much better throughput than it was sending. Blue lines indicate the link from the ground to the airplane and the orange lines indicate the metrics on the links from the airplane to the ground. Reporting userID are indicated with asterisk.

The fractional loss figure shows that the losses on the uplink from the plane were brutal compared to the losses on the downlink to the plane. The connection quality indicated by the WebRTC client on the ground was roughly 33x the amount of cumulative compared to the client on the airplane.

Fraction loss in the conference call. Dark blue line in the airplane and light blue line on the ground. Hence, there were more losses from the plane to the ground than from the ground to the plane. Erg, the losses on the links are asymmetric.

As the connection went through a satellite, latency was between three to four seconds throughout the conference call, which meant that there was consistent delay, but the jitter shows high variance leading to a loss in audio/video sync.

Latency in the conference call. MediaStreamTracks 1590553213 and 476737194 (dark blue and light orange in the legend) are carrying video signal.

There you have it, the first recorded metrics of a video conference call made between a person on an airplane and a person on the ground. As you can see from the graphs the quality of the conference call was surprisingly good on the airplane. Looking back at my personal experiences, I have to say that overall I’ve had bigger problems on a transcontinental calls than on this cloud calls. Now, if I only could get myself onto a spaceship so we could analyse a space call as well…