IBC2018 Show Event Channel

Everything you need to know for the show and exhibitors.

Click here

Understanding IP Networks - Why Do We Need Interoperability?

Point to point connections with well-designed standards have given broadcaster engineers piece of mind for many years, knowing when they connect one AES-3 audio output to an AES-3 audio input, the two will connect seamlessly and audio will pass without incident. The same can be said of MADI and analogue twisted pair. Signal routing is easy to follow using numbered cabling and system diagrams.

The world of IP is very different. Trying to take the output of one device and connect it to the input of another is fraught with problems. The only commonality is the definition of the Internet Protocol, defining the header and payload information for packetized data to be sent to different buildings over a variety of networks using routers and switches.

RTP is Generic

Real-time Transport Protocol (RTP) was designed to deliver audio and video over IP networks and is used extensively in audio over IP systems. But like many standards, RTP is generic and the protocol can be configured in diverse ways.

IP routing was not designed to move large and voluminous packets of real-time data around a network. Instead, it was designed to transfer short bursts and time independent data. Transferring the same file using FTP from one file server to another across the same network can vary in time due to the routing protocols employed. In the IT world this doesn’t matter, whether a file transfer takes half a second, or three quarters of a second is largely irrelevant.

IT Tradeoff

IT have traded guaranteed time delivery for flexibility and resilience. In the IT world, it’s better to guarantee a packet will be delivered within a certain time frame than an absolute measurement. In effect, IT has widened the window of delivery time compared to broadcast audio and video.

For many years broadcasters have enjoyed the luxury of point to point networks that guarantee bandwidth, availability and data integrity. The IT industry trades this for greater flexibility and massively reduced costs. If we compare the cable systems used in broadcast to IT we can see that the amount of copper needed is significantly less in the IT world. This is partly driven by cost, but also due to the need to keep cable volumes to a minimum so they can be easily deployed in offices.

IT Engineers and Mixing Desks

Although RDP solves a problem, it starts to fail when moving multiple, high bandwidth audio around IP networks. It also assumes all vendors have configured their RDP protocols in the same manner and they have IT engineers on hand to configure the microphones and mixing desks using them. And finding an IT engineer who understands what a mixing desk does is an even greater challenge.

AES67 builds on RDP to provide highly accurate timing systems using the IEEE PTP standard. The specification makes sure packets are correctly time stamped and are assembled at the destination receiver, such as a mixing desk, in the correct order and time. Jitter, delay and data dropout are all removed so all packets are received and decoded in time to provide splat free and glitch-less audio.

Without discovery, adding an extra device to an IP network can be a time consuming and dangerous task.

Without discovery, adding an extra device to an IP network can be a time consuming and dangerous task.

Discovery is the concept of plug-and-play for the broadcast industry. In the old days of personal computing, we had to set IRQ’s and address memory space when adding a new peripheral device, the same is true of audio-IP devices without discovery, they must be manually configured with IP addresses, gateway address and bit masks.

And to connect to all the devices in an audio network we must enter all the IP addresses of each device. If a system consisted of twenty stage boxes, and five mixers, each device would need to be programmed with the IP address of every other device on the network, in this example, each device would need to be programmed with twenty-five IP addresses, a mammoth task. And when a new stage box was added, each of the other twenty stage boxes and five mixing desks would need to be updated with the IP address of the new stage box.

IP Chaos

And what would happen if somebody duplicated an IP address? Chaos would ensue! And it’s very easily done.

Discovery overcomes this using the plug and play philosophy. In the example above, each stage box and mixer would auto detect the other devices and configure their IP addresses accordingly, resulting in a much more reliable system.

AES67 does not provide discovery, but standards bodies such as AIMS and Media Networking Alliance do. These are industry consortiums trying to make sense of the IP world and moving broadcast television to IP, in a practical and workable manner.

Making it Work

The theory is all well and good, but it can be a challenge for broadcast engineers who are new to IP to make this technology work. SSL recently solved a lot of the technology problems whilst working with, and delivering their system to Canal+. This state-of-the-art IP installation solved many of the timing, jitter, latency and discovery problems already highlighted.

SSL have provided the white paper, SSL Networking Now, listed below showing how to build a reliable IP audio and control system over IP, using Canal+ as a working example.

We are only just discovering the problems we must solve and engineers are well placed to do this. By studying other manufacturers and broadcaster’s solutions we can quickly learn how to move forward and build reliable, cost effective IP solutions.

Let us know what you think…

Log-in or Register for free to post comments…

You might also like...

Essential Guide: Reality of IP

As broadcasters migrate to IP, the spotlight is focusing more and more on IT infrastructure. Quietly in the background, IT has been making unprecedented progress in infrastructure design to deliver low latency high-speed networks, and new highly adaptable business models,…

IMF - Interoperability and Content Exchange Made Easy

As the television business has become more global, and evolving consumer devices spawn the need for ever more formats, there has been an explosion of the number of versions that are needed for an item of content. The need to…

Broadcast For IT - Part 20 - IP Systems

In principle, IP systems for broadcasting should not differ from those for IT. However, as we have seen in the previous nineteen articles in this series, reliably distributing video and audio is highly reliant on accurate timing. In this article,…

IP Explored - ST2110 and ST2022

As broadcasters accelerate IP migration we must move from a position of theory to that of practical application. Whether we’re building a greenfield site or transitioning through a hybrid solution, simply changing SDI components with analogous IP replacements will n…

Broadcast For IT - Part 19 - Why Use IP?

Moving from the luxury of dedicated point-to-point connectivity in favor of asynchronous, shared, and unpredictable IP networks may seem like we’re making life unnecessarily difficult for ourselves. However, there are compelling reasons to make the transition to IP. In t…