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.

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.