Why Enterprise Live Streams Break

Enterprise streams rarely fail in exotic ways. They fail in the same handful of ways, most of which have nothing to do with video and everything to do with the building’s network and who controls it.

That is good news, because a known list is a solvable list. Every failure below has a fix, and every one of those fixes is cheap when you find it during planning and expensive when you find it at load-in. This is the list we work through on every corporate job, and what we do about each one.

The network blocks the platform you are streaming to

The most common one, and entirely routine: a client wants their event on YouTube, and their corporate network blocks YouTube.

The stream cannot reach a destination the firewall will not allow. Nothing about that is hard to solve. It is only hard to solve at nine in the morning on show day, which is when it surfaces for anyone who has not tested against the real network from inside the real room.

So that is a planning task, not a setup task. We test the actual destination over the actual connection during the site visit, well before load-in. If the firewall blocks it, opening it becomes a conversation with IT that has days to happen in rather than hours (and when the IT person might not even be present). And if IT will not or cannot open it, we know early enough to simply run the show on our own connectivity instead.

The port in the wall that is not live

We are told the network port in the room is enabled. We arrive, plug in, and there is nothing. Someone enabled a port. It was not that one. Or it was enabled onto a VLAN that does not route anywhere useful.

The house port is often the right plan. A good venue connection is usually better than anything we can carry in, and cheaper to run. What it cannot be is the only plan. We arrive with our own connectivity already standing whether we expect to need it or not, so a dead port costs a few minutes of reconfiguring instead of costing the show. Nobody on our side is troubleshooting a patch panel while the room fills up.

The IT department that is not in the building

Small and mid-size businesses frequently subcontract IT. Those people are not on call for a live show, and they are often the only ones who can change anything.

This is the failure with the worst timing characteristics: a problem solvable in ten minutes by somebody who is not reachable for four hours.

The fix is to have that conversation while they are still reachable. During planning we ask who actually controls the network, and whether they will be available on the day. If the answer is that nobody will be, that is not a problem, it is just information. It tells us to plan around them completely rather than discover the gap at load-in.

You cannot get the assets in

A quieter failure, and a constant one. The client has a pre-recorded video that needs to play during the show. Their laptop’s USB ports are disabled by policy. Dropbox and Google Drive are blocked on the network. There is no supported path from their file to our playback machine.

The workaround is to route around the corporate network entirely. We email the external video or marketing agency that produced the file and have them send a link straight to our team, so we download it directly from the people who created it rather than through corporate IT.

It works reliably. It also means the asset arrives outside the client’s own IT chain, so it wants planning days ahead rather than discovering it at rehearsal.

Bring your own network

The reason most of the above is survivable is that we can run the show on our own connectivity and bypass the building entirely.

We always bring a bonded network encoder. Instead of depending on one connection, it sends the signal up over several cellular modems at the same time, to a cloud server that reassembles the pieces in order before passing the finished stream on to its destination.

The modems are multicarrier. Each one polls the available cellular networks and selects whichever performs best at that specific location, so the show is never riding on one carrier happening to have good coverage in one building. They are also commercial-grade hardware, which carries network priority over consumer devices. That matters most in exactly the situation you would expect it to: a venue filling with a couple of thousand people, all of them on their phones.

That changes what a network problem actually costs. If one of three modems drops out, or just slows down, the show keeps sending over the other two. The stream does not stop, restart, or drop quality in a way anybody watching would notice. Redundancy that only works once somebody spots the problem and intervenes is not really redundancy. Handling it at the encoder means the recovery happens whether or not anyone is looking at that moment.

That is not a fallback we improvise on the day. It is the default assumption on any corporate job, because every failure listed above is a network we do not control.

Somebody whose only job is the thing that goes wrong

Automatic failover covers the failures that can be handled automatically. It does not cover all of them. So we also staff an EIC, an engineer in charge, on every show. Their entire job for the length of the broadcast is to watch for problems and fix them.

When everything goes correctly, that role does very little. That is exactly what makes it difficult to justify as a budget line, and it is still some of the best money a client can spend. The difference between a problem that gets solved in ninety seconds and a problem that takes the whole show down is almost always whether somebody deeply knowledgeable, and calm under pressure, was already watching when it started.

What redundancy actually buys you

We were about to stream from a sound stage. During planning I had asked whether the client wanted redundant internet. They told us the facility had not lost its connection once in ten years of operating.

Five minutes before we were due to go live, the internet died. Not the building’s equipment. A neighborhood-wide outage at their ISP.

We had brought the redundant setup regardless. The client made the call to pay for the additional modems we needed to bring online, and we went live about a minute late. From that point the show ran without a further issue.

The lesson is not that the venue was wrong about their track record. They were probably right. It is that a ten-year record tells you nothing about one specific hour, and the cost of being wrong about that hour is the entire event.