All 18 articles in this series are now available in our free 84 page eBook ‘Designing IP Broadcast Systems’ – download it HERE.

All articles are also available individually:

Although we would like to make IP integration as easy as possible, the concept of plug-and-play needs much more thought, especially when we start considering security.

Anybody walking between rooms within any modern office block or television studio will not necessarily notice the level of sophistication that is required to keep their mobile devices reliably connected to the network. IP addresses are dynamically assigned by the host system and the devices credentials are automatically detected so that only authorized personnel can access the systems. Then, based on the user-level of access, security systems will determine what they have access to, when, and how.

If we consider the Zero-trust method, then every transaction and interaction with any of the systems will be validated so that the user does not gain access to any information or processes they do not have the authority to access.

When considering plug-and-play in a broadcast signal environment, that is, the systems responsible for exchanging media over the network, then adding devices, and how we handle them becomes a little interesting, especially when we include the high levels of security that are now demanded by broadcasters.

Take for example the act of adding a microphone to the network. Assume we have an IP broadcast microphone with embedded pre-amp and equalization that requires a PoE connection to be controlled from the sound console. The first problem to solve is assigning an IP address. If we assume plug-and-play in the IT sense, then a DHCP server will need to allocate the IP address to the microphone. Technically, this is easy enough and the technology is well proven with all manner of mobile devices from cell phones to IoT demonstrating this. But after the initial connection and IP allocation, the microphone needs to be validated.

Why do we need to approve the microphone? It’s just a microphone. In the Zero-trust environment, which many modern IT infrastructures are moving to, and is expected by Tier-1 broadcasters, the microphone cannot be trusted and therefore must be validated as it may well be a device planted by a hostile actor. For example, how do you know the microphone isn’t streaming its sampled audio to a foreign server? Validation can be achieved using login credentials thus requiring the microphone to need a username and password. As we’re treating the microphone like any other IP connected device then the central administration system such as Active Directory or RADIUS will need to provide this.

Digging a little deeper into the microphone, to make it truly plug-and-play, then we will need an SDP (Session Description Protocol) file to describe parameters such as the sampling rate, bit depth and word size. However, this file will also need to be verified as it could be the source of a back door attack containing embedded code. Again, this could be added to AD or RADIUS but we’re starting to delve into expert broadcast knowledge and it’s unreasonable to expect an IT specialist to understand the intricacies of an SDP file.

As the IP microphone has a control circuit then it’s possible for any other IP enabled device to hijack it and control it, so not only do we have to protect the network from the microphone, but also protect the microphone from the network. In the Zero-trust philosophy this is a given.

A typical light-entertainment studio could easily use 50 microphones each with its own login credentials and SDP files, and somebody must administer this in the AD or RADIUS server. Therefore, the challenges just described will be multiplied fifty-fold, and that’s just for one studio. One solution is to use remote stage boxes that multiplex multiple microphones onto an IP/ethernet connection, but each stage box is still treated as an IP enabled device, thus requiring its own SDP file and login credentials. Also, the granular control of each microphone would potentially be lost, depending on the sophistication of the stage box.

Live studios will often use multicast to distribute real-time video and audio. This reduces the chance of network congestion but at the expense of increased complexity. Switches need to be configured to operate in multicast mode, so they know which packets to duplicate and which ports to transmit them from. Although PIM (Protocol Independent Multicast) goes a long way to maintaining multicast streams and keeping them optimized, automating the configuration process can be challenging. Furthermore, as the number and type of media streams varies from show to show and studio to studio, a record of the dynamic allocation of multicast streams needs to be maintained thus frustrating attempts to automate this through plug-and-play.

IP microphones are relatively straightforward when compared to studio cameras using standards such as SMPTEs ST2110, mainly due to the bidirectional nature of the video signals to and from the camera. For example, a camera may have multiple outputs for HD and down-converted SD, and inputs for signals such as reference feeds and the prompter input. There are auxiliary input feeds for the camera operator’s viewfinder as well as comms, and even simple control protocols for the tally light and cues. The reference feed will require a connection to a PTP IEEE-1588 clock but plugging the camera into a network and then expecting the plug-and-play controller to detect it, assign IP addresses, configure the multicast streams, and sync up to a PTP feed is a big ask.

Although the automation that plug-and-play offers would certainly make every broadcast engineers life a dream, the reality is the technology is just not there yet to completely implement a fully automated Zero-trust plug-and-play. In this context, when we speak of technology, we’re not suggesting waiting for a new piece of hardware to become available or a ground breaking technological breakthrough, instead, we’re thinking more in terms of the software that needs to be written to consider every use case and workflow, then standardize it. Vendors such as Microsoft and Apple have both achieved this and open-source applications such as Linux are equally competent at plug-and-play, but that’s because these organizations have spent hundreds of thousands of hours designing these systems and considering the set of all potential workflows and use cases – a huge undertaking.

Broadcast specific vendors are working on solving the plug-and-play challenges and to progress this journey have created hybrid solutions. This includes creating a network sub-environment where devices such as microphones and cameras are detected by the controller and instead of auto assigning IP addresses, they are flagged to a control surface where the engineer must actively accept them into the system before they can be used. During this process, security validation, multicast streams, SDP files and control systems can all be manually enabled and configured thus creating a hybrid plug-and-play.

The hybrid plug-and-play allows the broadcast engineers to operate and administer their own AD or RADIUS server so that the high levels of Zero-trust security are maintained, and any configuration issues are kept within the boundaries of the broadcast network and don’t infiltrate the rest of the IT network. Completely automated plug-and-play will become a reality at some point during our IP journey, but to achieve this, vendors will need to work through hundreds of thousands of different workflow configurations to make it reliable. 

In the meantime, for ST2110 type studios, the options are to either painstakingly and manually configure every device or adopt one of the hybrid plug-and-play solutions that vendors are currently providing. But it’s worth remembering that configuration isn’t just about sending media signals across networks with minimal latency and maximum reliability but is also about controlling end devices and most importantly, creating and maintaining Zero-trust secure infrastructures.