A Canary in a Coal Mine: Video vs Your Network

If your enterprise infrastructure has problems, video will find them.

In a previous article I coached remote workers on making sure their home internet could handle video conferencing, even if someone was watching Netflix and playing CoD at the same time.

That was for one video call at a time, or a couple at most if multiple people in the household were working at home or attending school remotely.

That’s easy.

As an enterprise IT pro, you don’t get such luxury. Depending on the choices you (or in some cases, your technically ignorant executives) make, you need to ensure every part of your network can handle the load of your remote workforce utilizing video for much of their workday. That’s a tough enough job if you have just a few hundred employees. If you have tens of thousands of employees, it’s enough to raise your stress to tax audit levels.

Now, if you’re just looking to improve your home video conferencing experience, please check out my article “Are You Ready For Your Closeup?” This article is going to be well over that scope.

But if you’re an IT professional panicking because HD video is about to turn your network into the equivalent of a couple of tin cans with a string…keep reading. Note that I’ll be explaining some terms as I go, but this article will assume a certain base level of networking knowledge.

With all that out of the way, let’s break this down into a few common decisions and tasks.

Cloud or on-prem?

The first decision you’ll have to make is cloud vs on-premises for a video solution, or perhaps even a hybrid deployment model. This may be simple for you…perhaps you use a cloud VoIP provider, or, on the other end of the spectrum, your IT security team won’t allow cloud-based collaboration solutions. For most organizations the truth lies somewhere in between.

If you have a major investment in on-premises VoIP and call control like Cisco’s Unified Collaboration Manager (CUCM) as a common example, you may choose to select video endpoints from the same manufacturer, register them to your existing call control infrastructure, and then deploy a cloud or hybrid solution like Cisco’s WebEx.

Likewise, if you use a cloud VoIP solution like Microsoft’s Teams Cloud Voice, you may want to keep all of your video infrastructure cloud-based to match.

Here’s the first caveat…not all of these systems play nice with each other.

A prime example of compatibility issues comes with Microsoft Teams talking to Cisco or other traditional SIP endpoints. Let me explain.

Let’s say you have a multi-million dollar investment in Cisco CUCM for voice, but your CIO prefers Microsoft Teams for desktop collaboration over Cisco’s WebEx. You now have a problem on your hands, because Teams does not natively use the industry standard version of the SIP protocol for video (at least as of this writing in April 2021). You’ll need a solution to perform translation or “inter-op” between the platforms, and it’s likely that such a solution will involve cloud components. You’re now forced into a hybrid solution whether you wanted one or not.

The moral of this short story is plan wisely, but be ready to be forced into a model based on choices that have already been made or are out of your hands. Flexibility is key.

Bandwidth is your best friend.

This is where video will start to poke holes in your carefully designed and managed network. There’s no way around it, video devours bandwidth like no other application on your network today. Let’s look at the numbers.

For standard definition video that doesn’t make people look like robots that need oil, you’ll need at least 384 kilobits per second (kbps) of bandwidth bidirectionally. In fact, let’s just get this out of the way right now…start thinking in terms of symmetrical bandwidth for your users on video. It’s the nature of the beast.

However, if you deploy a video solution that limits your users to standard definition, you’re likely to find torches and pitchforks outside your virtual door. YouTube and Netflix along with FaceTime, Google Meet, and all those other consumer video services have ruined your users when it comes to experience. They want HD, and you’re going to need to provide enough bandwidth to get the job done.

The numbers listed here are VERY approximate, and assume H.264 for video encoding. Many modern endpoints and software support H.265 (HEVC), or VP8 and VP9. A discussion of the specifics of each codec is beyond this article, but this should at least give you a starting point.

For 720p video, I’d plan for 1.5 megabits per second (mbps) bidirectionally to and from each user. Yes, some vendors will tell you they can do it at 768 kbps. Don’t count on it. The actual number will go up and down based on the complexity of the video image (e.g. lots of motion takes more bandwidth), but it’s a good start for planning.

A quick note…you may hear from executives that they insist on 1080p or even 4K. Be prepared to explain that those are almost always overkill for desktop video. In a large room with a 70” display, there is merit to having a 1080p signal. On a laptop monitor, even a pro would be hard pressed to tell the difference between 720p and 1080p, and 4K conferencing is just not practical right now in 2021. It’s far too bandwidth intensive to scale up beyond a few special use cases.

If you are deploying room systems large enough to warrant 1080p, plan on an average of 3 mbps minimum bidirectionally.

Make sure you’re looking at not only your access layer, but also your distribution layer, core, and pipes to any cloud services along with your WAN, internet, VPN concentrators, etc. If you have a weak link in your network, video WILL find it, and usually at the worst / busiest time of the business day when every user will notice it.

Clear a path.

Regardless of the specific numbers needed, all video traffic needs to arrive at each endpoint and user as fast as possible and not be delayed anywhere in the signal path. Note that while the signaling for video calls is done via TCP, the media is normally carried over UDP so there is no mechanism for recovering lost packets.

The easiest way to ensure this is to throw a ton of bandwidth at it, but you should have your quality of service (QoS) properly configured as well. Most of the industry follows Cisco’s rules of thumb. If you don’t understand QoS tagging, I would suggest reading one of the many excellent Cisco CCNA study guides on the market or one for CompTIA’s Network+.

Your VoIP traffic should take the highest priority as Expedited Forwarding (EF), or DSCP 46.

Right behind that should be your real-time video traffic, which means your video conferencing, tagged as Assured Forwarding (AF) 41, or DSCP 34.

Make sure that tagging is respected end to end on your network, and that means over your WAN as well. Most major providers offer WAN services that will respect QoS markings.

Once your traffic hits the internet you’re at the mercy of the wire, but that’s life in IT.

Make a hole!

Firewall time. If video is the scourge of network engineers, firewalls are the scourge of the video professional.

Nothing can stop video dead in its tracks faster than an incorrectly configured firewall, and there’s a lot to configure.

Follow your vendor’s documentation, but you can count on making sure SIP signaling is open on TCP 5060 and 5061 (plan for TLS as well because you DO support encryption, right?), perhaps H.323 in the 1720 and 1730 ranges, and a huge range of ephemeral UDP ports. Your security engineer is likely to make a noise like a strangled moose at the latter. Stand your ground. You really do need a range of ephemerals for media traffic.

Here’s the good news for those UDP ports…they are only in use once a call session is set up, and they stop being used once the call ends.

The easiest way to handle this is by use of a SIP proxy such as a Cisco Expressway, Poly DMA, Pexip Proxying Edge Node, etc., and almost any design will include one or more such systems. These solutions will often sit in a DMZ and will proxy video traffic to your main call control infrastructure inside your borders.

(Disclaimer, I do work for Pexip as of the writing of this article. I make no comment as to the relative merit of any of the above listed solutions, and I have worked on successful deployments of all of them during the course of my career.)

Back to firewalls. Firewalls, by nature, inspect traffic. That takes time, and delays are not a good thing for real-time collaboration. Your security team needs to get the video traffic through your firewalls with as much haste as can safely be configured on your specific security devices.

You may run across a security engineer or vendor who touts the idea of a SIP Application Layer Gateway (ALG) on your firewall and wants to turn it on for your video traffic. Your answer needs to include the word “NO” as many times and in as many languages as you can fit into a single sentence. I don’t care what a firewall manufacturer claims about the performance of their SIP ALG, it will be flaming death from above for your video traffic. TURN IT OFF AND LEAVE IT OFF. Most solution manufacturers will tell you this in similar terms in their documentation, and believe me, they mean it.

Any enterprise video deployment is going to include much more detail than is presented here, but this should give you at least a basic idea of what you’re in for when tasked with setting up a large scale video infrastructure.

The need for video collaboration isn’t going to go away or even decrease; video is here to stay and IT pros need to start wrapping their heads around the unique use case presented by such a bandwidth intensive real-time application.

If you have specific issues or topics you’d like me to discuss, please drop me a note on Twitter or LinkedIn and I’ll be happy to add them to my writing list. Don’t forget to unplug once in awhile, and thanks for reading!