Your Practical Guide to AES67—Part 3

In this conclusion, Part 3, of our tutorial on AES 67, we examine proper connection and configuration for AES 67 links. Understanding how each of these elements fit into the overall network will make both setup and troubleshooting easier.

In this tutorial, readers will learn how to properly configure an audio-over-IP, AES 67 network. While there are some differences between each vendors’ products, these instructions are sufficiently generic that they apply to most devices. Learn these steps and you will be an audio-over-IP guru. 

2.2 Device configuration 

2.2.1 IP configuration 

Select the method of IP assignment: DHCP, Zeroconf, manual / static. In case of static IP assignment, make sure you don’t assign any IP address twice and that the subnet mask matches your intended network configuration. In some cases, a gateway needs to be configured (even if it won’t be used). If no gateway is present, just enter the IP address of one of your switches. An Excel spreadsheet helps tracking IP configuration. If you prefer automatic IP configuration, check if IP parameters have been properly assigned through DSCP or Zeroconf.

2.2.2 PTP configuration 

Check / configure all relevant PTP parameters the device offers; follow the guidelines given in section 2.1.5 PTP

2.2.2 Device-specific configuration 

Some devices need further configuration to interoperate properly with other AES67 gear. Here are a few commonly observed settings which may have to be configured individually: 

2.2.3.1 AES67 mode 

Some devices require you to activate the AES67 mode (i.e. Dante devices), other devices support AES67 natively (RAVENNA, Livewire). 

2.2.3.2 Multicast address range 

Despite not being fully AES67-compliant, some devices only support a limited range of multicast addresses for AES67 interoperation (i.e. Dante devices). The range needs to be configured properly with all devices; note that this may even affect devices which don’t exhibit this limitation, as AES67 streams would only be identified / accepted when their multicast address is within that configured range. As some devices don’t have a general device-level configuration for multicast address range (they can work with any valid multicast address in the range 239.x.y.z), this may be have to be respected when configuring individual streams. 

2.2.3.3 Discovery 

While most devices also use their native discovery method for announcement of AES67 streams, some devices offer the ability to enable other discovery options on demand (i.e. enable SAP support).

2.2.3.4 Audio-related configuration 

Some devices support different sampling rates, but only one may be selected at any given time (usually because a device only has one clock circuitry). AES67 calls for support of 48 kHz, but other sample rates may be used; make sure you select the desired sample rate. Further device-specific parametrization may be required; check with the operator’s manual.

2.3 Check for proper synchronization (PTP)

Once all devices have been configured, check for proper synchronization. This is important because all devices on the network derive their locally generated media clocks from the network clock distributed with PTP.

2.2.4  Grandmaster selection 

It is advised that you select a device as the preferred master beforehand and set every other device to slave-only mode. Follow the steps under 2.1.5.2 BMCA parameters. Once properly configured, all devices should indicate that they are listening to the same Grandmaster (IP address and / or GM-ID should be indicated identically on all slave devices). If you see different GM-IDs, the BMCA did not work as intended and at least one device is assuming a false GM role. Here’s a quick checklist:

• Check if (PTP) multicast traffic is forwarded to all nodes (nodes need to receive the ANNOUNCE messages from all other devices for proper BMCA execution). Although the PTP multicast address (224.0.1.129) is a well-known multicast address which should be forwarded by a switch by default, an IGMP request may need to be issued to activate forwarding in certain switches. 

• Check priority 1 values of devices which assume a GM role unexpectedly and compare with the settings of the designated GM. You may have to lower the priority (increase the priority 1 value) of that particular device or assign “slave-only” operation. Alternatively, increase the priority (lower the priority 1 value) of the designated GM. 

• It may also help (even just for analysis) to select a different device to become GM by adjusting the priority 1 fields accordingly, or by temporarily removing suspected devices from the network. 

• If you have PTP-aware switches in the network, it may help to switch PTP support off to diagnose the situation. If the situation corrects after switching off PTP support, you need to carefully check all PTP-related settings in the PTP-aware switches.

2.3.2 PTP accuracy

Check PTP accuracy on all nodes – slave devices generally inform about proper sync status. They either have a sync indicator (traffic light or any other graphical means) or they indicate the current offset from master numerically; in most cases single-digit microseconds are usually sufficient, sub-microseconds are perfect. If you don’t have proper sync on all end nodes, you have to resolve this situation before proceeding any further (i.e. configuring streams). You may want to check on these potential issues:

• SYNC message rate too low: some devices require a certain sync message rate in order to reach a stable locking situation. Try to decrease the SYNC message interval at the chosen Grandmaster (i.e. try a SYNC message interval of 2^-2 or 2^-3). 

• QoS not properly configured: PTP traffic needs to receive the highest forwarding prioritization. Check if PTP packets are marked with a proper DSCP value and if all participating switches in the network are configured to store packets with this DSCP value in their highest priority queue. 

• Removing traffic load: If you are unsure about properly configured QoS you can also try to remove any foreign traffic on the network to reduce the bandwidth utilization (i.e. remove potential network overload). The simplest approach would be to unlink devices or network segments which are not relevant to AES67. You could also start building your network from scratch by plugging in devices incrementally and checking each time for proper synchronization. 

• Mixed switch configuration (FE / GbE): In some cases the use of switches with different network link speeds may cause synchronization issues. In most cases, this will result only in a permanent offset from master without necessarily affecting the synchronization stability. The node may settle into a synchronized condition, but most likely larger latency settings will be required for streams coming from/going to this node due to a permanent displacement between local and network time. It is good advice to only use GbE switches in the network and connect end nodes with FE interfaces directly to the GbE switch ports. 

• PTP-aware switches: as mentioned earlier, PTP-aware switches are certainly valuable (or even required) to improve synchronization (especially in larger networks), but they may make things more complicated and require deeper knowledge for proper configuration. Check if PTP-aware switches are part of your network and try switching PTP support (temporarily) off. 

In general, PTP-aware switches can usually only support one version of the PTP protocol – AES67 mandates the use of PTPv2. Since some solutions use PTPv1 for their legacy equipment (i.e. Dante), a PTP-aware switch may not properly forward those packets, effectively resulting in synchronization problems in certain areas of the network. Also, make sure that all configuration requirements for COTS switches are in place (i.e. QoS, IGMP etc.). 

This concludes Part 3 of our three-part series. An extended version of this article - including a part 4 which focuses on RAVENNA-specific practical connection examples, along with many instructional screen shots - is available from the RAVENNA web site at this link.

Links to previous articles: 

Part 1 link: Your Practical Guide to AES67—part 1

Part 2 link: Your Practical Guide to AES67—part 2

Andreas Hildebrand is acting as Senior Product Manager and Evangelist for the RAVENNA technology developed by ALC NetworX, Germany. His experience is based on more 25 years of occupation within the Professional Audio / Broadcasting industry. <br /><br />ALC NetworX - an R&D company in Munich, Germany – assembled a team of experts to develop the RAVENNA technology platform, which is now an established media networking standard and compatible with the recently published AES67 standard on high-performance streaming audio-over-IP interoperability.<br />

Andreas Hildebrand is acting as Senior Product Manager and Evangelist for the RAVENNA technology developed by ALC NetworX, Germany. His experience is based on more 25 years of occupation within the Professional Audio / Broadcasting industry.

ALC NetworX - an R&D company in Munich, Germany – assembled a team of experts to develop the RAVENNA technology platform, which is now an established media networking standard and compatible with the recently published AES67 standard on high-performance streaming audio-over-IP interoperability.

Although product implementations of RAVENNA are executed by individual partner companies, ALC NetworX continues to keep the lead role with respect to technology definition. More info is available at: https://www.ravenna-network.com/resources/.


Let us know what you think…

Log-in or Register for free to post comments…

You might also like...

AES70 - The Future of Audio Control, Part 1

Having spent much time and energy exploring AES67 (see our recent 3-part series, “Your practical guide to AES67, Parts 1-3”), we’d now like to turn our attention to AES70 – what is it, how does it relate to AES67 and why do …

DPP - The Live Explosion

Away from traditional broadcasting a revolution is happening. Live internet streaming is taking the world by storm with unprecedented viewing figures and improved accessibility for brands looking to reach better targeted audiences. The Live Explosion, hosted by the DPP in…

Your Guide to Understanding IP

See that hill up ahead? It’s not a hill, it’s Mt Everest and your job is to conquer that mountain. Rendered into familiar industry vernacular, you, video engineer, are charged with building an IT-centric facility. A SMPTE standard was…

Articles You May Have Missed – November 22, 2017

At the start of 2013, BCE at RTL City was a hole in Luxembourg’s ground. In less than four years the facility was on air broadcasting 35 different channels across Europe and Singapore. Costas Colombus is BCE’s Special Projects Manager and…

BCE Going Deeper - Part 2, Choosing Routers

At the start of 2013, BCE at RTL City was a hole in Luxembourg’s ground and in less than four years they were on air broadcasting 35 different channels across Europe and Singapore. Costas Colombus is BCE’s Special Projects Manager and…