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:
- 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
Find the original article on The Broadcast Bridge
|
|
|
|
