It may seem incredible but it’s true: In a recent Google Hangouts videoconference I was strangely unable to log in (while all the others had no problem in doing so) and had to have one of the participants hold up his mobile phone to his laptop screen so I could see what was going on through Skype! While the wizardry of modern technology when it comes to event videoconferencing may seem at the surface to be flawlessly superlative, the reality is that the underpinnings are still uncomfortably clunky due to the fact that we’re cramming real time multilateral video on a global network which wasn’t really designed for it.

A Commie nuke strike takes out several US cities

The internet was originally devised by the Pentagon as a military communications network engineered to suit the following scenario: “A Commie nuke strike takes out several major American cities, so how do we make sure that the cities that are left can communicate with each other?” The linear “telephone line” communication matrixes of that era were essentially hub and spoke topologies. If, for example, all the communications lines between New York and San Francisco went through Chicago and the Windy City was turned into radioactive glass, there would be nothing left but carrier pigeons to keep the Big Apple communicating with the Golden Gate city.

ARPANET was a web rather than a trunk line system

ARPANET as the embryonic internet was called at the time sought to remediate this problem by creating a web of communication lines. Instead of straight trunk lines between major population centers east to west or north to south, there would be a set of strands connecting just about anywhere to just about anywhere else. So if Chicago was cratered, the New York to San Fran communication could be automatically rerouted through Indianapolis, New Orleans, Nashville, or even Sault Ste. Marie!

One server in the middle has a hiccup & whoops!

It’s these jumps between endpoints which lie at the heart of many of the problems which face event videoconferencers today. Data packets follow unpredictable paths as they cross the country and these paths can change many times in the duration of a single videoconference. So the New York – Cleveland – St. Louis – Dallas – Denver – Salt Lake City – Las Vegas – San Francisco routing can become New York – Baltimore – Charlotte – Atlanta – Houston – Albuquerque – Phoenix – Los Angeles – San Francisco the very next second. While in most cases each one of these nodes is able to handle its traffic flow efficiently, all it takes is for one server in the middle of the chain to have a hiccup and the event videoconferencer is going to be witnessing dropouts, freezes, or outright disconnection by some or even all of their participants.

Invasion force landed at Half Moon Bay: Send bombers

ARPANET was designed to get simple text only messages across the country such as “Commie invasion force landed at Half Moon Bay: Send bombers.” Now each node is now carrying billions of times more information that that every second and when it comes to event videoconferencing it has to do so without even a half second’s delay or the latency it will create will make the entire event seem laggy and out of phase.

A single packet might be resent dozens of times

If a single data packet is sent with the loss of even a single bit of information, that packet will need to be resent again and again until it arrives whole. Since there is a tendency for nodes which are suffering from high traffic to drop the occasional bit some packets have to be sent dozens of times until they finally arrive in a complete fashion. That means that the time measured in milliseconds for the packet to be transmitted can increase to the point that the series of packets take noticeable fractions of seconds to go through properly.

There are various diagnostic tools which can check for a variety of factors that can have a severe effect on your event videoconference. Pre-event checking for latency, routing, bandwidth and other critical factors can help your online event go smoothly!