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
Before wiring up a system, careful planning is advised. Configuration, system monitoring and debugging will be much more efficient if the general system layout and other vital aspects have been given ample thought.
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:
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:
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
Find the original article on The Broadcast Bridge