Page 5 - ADVANCING AOIP FOR BROADCAST

Why do we need AES67?
IP networking is easily one of the most ubiquitous technologies found in the world today. IP audio network manufacturers are able to take advantage of, and share in, many, many proven standards as a result. So, why do we need one more standard? Because the rules of IP packet distribu on are not friendly to real- me audio. Synchronizing large amounts of data is the biggest problem. In the IP network, packets aren’t necessarily routed based on which packets were created rst. That works ne for a typical o ce network, but without some sort of determinis c rou ng for the heavy tra c loads
of the audio network, packets can become jumbled and delayed. This can cause ji er and packet loss or dropout. Audio network makers have had to work around this problem with tools like bu ering and QoS to assure con nuous audio transport. No two manufacturers solve this problem the same way, which has made it di cult for them to exchange audio between them.
What does AES67 do?
Almost all audio networks use a standard IP protocol called RTP (Real-Time Protocol) to create the proper packet order. RTP provides iden ca on in the packets about their crea on me and order but, for all the reasons stated above, it has been up to the IP audio network manufacturer to extract this informa on and to recreate the audio data and ming. Each di ers in the speci c packet loading, ming and synchroniza on mechanisms within the protocol.
AES67 has come along to provide the common synchroniza on, clock iden ca on, session descrip on and other interoperability recommenda ons we can all share. AES67 adapted the PTPv2 (Precision Time Protocol - IEEE 1588-2008) standard as the master clock reference, so we can more easily transport audio between our various systems without ji er, delay and data dropout.
Check out this AES link for a full descrip on:
h p:/www.aes.org/standards/blog/2013/9/aes67-2013- audio-over-ip-130911
Does AES67 provide for discovery?
No. AES67 does not provide for a standard way to nd and add devices to a network. Discovery is le up to each individual manufacturer, although most of the major players take a similar approach to nding and labeling components in the network. Most designate extra packets on the network to communicate discovery data and display it seamlessly to all users with signal names and other informa on easily created and recognizable to broadcasters.
Does AES67 provide for control?
No. AES67 is an audio transport standard only. Other standards are intended to address full interoperability of the control features of various audio networks.
We recognize that gaining access to hundreds of channels of audio on a network is useless if you can’t route them, turn them on or o , re their playback, or turn an ON AIR light on when needed. Currently, to accomplish this, IP audio network manufacturers use packets to communicate command and control. Each system is di erent, and some mes an ancillary PC is used for this and some mes the intelligence is built right into the network devices (as is the case for WheatNet-IP).
In a WheatNet-IP system, control is built into each I/O connec on point and shared with other IP connec on points across the network, allowing systemwide access to all available sources as well as any associated logic that goes along with each feed, such as control of mic ON/OFF, changing remote mic se ngs for IFB, audio processing, and other parameters.
Does AES67 pay it forward?
Yes. AES67 is extensible, meaning that you will be able to add to it as situa ons change. It is an cipated that any future standards are will add on to, not replace, AES67.
5