Network bandwidth is often among the top concerns for IT teams when it comes to running internal live events. Will the network hold up, or will it become overwhelmed, leading to broadcast failure?
Why a failed live stream is very different from a failed team call
With smaller team meetings, participants can easily jump back on the call even if there’s a major interruption or connectivity breakdown. If necessary, the meeting can even be pushed for another time or a later date – with instant messaging apps, teams can sync and change plans fairly quickly.
But what happens when the meeting in question is a live broadcast where attendee numbers lie in the tens, or even hundreds of people? Even a short interruption during the live stream can result in participants dropping off and moving on to other daily tasks. Getting everyone back online won’t be as easy as shooting a message in a team chat, and rescheduling will most certainly lead to major financial losses. Costly preparations and pre-event promotion will be wasted, and worse yet, much will need to be done from scratch for the re-broadcast.
Network bandwidth behavior is hard to predict
Network bandwidth utilization is always a major concern while running a live event. There are multiple tools available to enterprise IT teams that help monitor network performance. The issue is, these tools usually alert of problems once the network bandwidth has already been overloaded and its capacity is already at its maximum.
Preventing these issues from happening requires exceptional knowledge of the network and its possible behaviors. But even with great insight into the workings of the network, there is always a chance that something unpredictable occurs during the event run time. A failure to predict all possible scenarios where things can go wrong can lead to a catastrophic network breakdown, and a complete collapse of the live stream.
Troubleshoot before each live stream with pre-event Silent Testing
Pre-event stream testing helps IT teams identify exactly the kinds of issues that can come up, long before the actual event stream.
Hive’s own Silent Testing capability gives customers a tool that will not try to predict a problem, but instead show you exactly how your network will perform when you select the expected number of attendees and their location for a scheduled live event.
Silent Testing doesn’t just predict problems – it shows you exactly how a stream will perform so you can troubleshoot specific issues proactively before your live event.
Running a Silent Test on WebRTC requires no software installation. In the past, Silent Testing was a feature only available to customers using an installable Hive Agent. However, as demand for seamless, installation-free solutions grew, our Product and Engineering teams worked to expand the Hive WebRTC offering to match that of the installable Agent. WebRTC Silent Testing is a proud result of this work, it draws on the same robust data and offers network analytics comparable to those accessible through an installed Hive Agent.
Why Silent Testing is essential to enterprise network teams
By being able to see how each live event will perform before it even happens, customers can optimize the utilization of their network for employees that are in the office, working remotely, or just using a VPN. Silent Testing offers visibility on what to focus on when preparing a network for a live event stream, and shows how to prevent network congestion on specific connection links, whether in the LAN, WAN or VPN.
By identifying where users will be connecting from, IT teams can prevent possible issues, focus on the weakest links and react faster. If a problem occurs, the network team no longer has to go through multiple monitoring tools and analyze the entire network footprint. Instead, they can first troubleshoot the previously identified failure points. Often, they will start troubleshooting and solving issues even before any reports of failures come back to them.