Ravenna AES67 Practical Manual page 10

For practical purposes, the Priority 1 field is the most important. Start with keeping the value at the
device default setting (should be 128 for devices which can become GM and 255 for devices which are
slave-only). If you don't have a dedicated GPS-referenced GM device in the network you may either
decrease the Prio1 for certain devices you want to become preferred GMs, or decrease the Prio1 field
for the devices which should only become GM if there is absolutely no better GM available on the
19
net .
In any case, and regardless of the intended size of your network, always make sure that the PTP
distribution results in the desired accuracy in any particular network segment before proceeding with
setting up any stream traffic. A good indicator is the clock offset (calculated time offset from PTP
master) indication offered by most end nodes. Indicators may vary between devices, most feature at
least a status indicator or a numerical offset display. If you see a "green" light or see offset numbers
in the single-digit microseconds or sub-microseconds range, you are usually good. Remember to
check those indicators from time to time during regular operation.
2.1.6 Discovery
As described in the introduction, session description data is required to connect to an available
stream and decode its content. While the parameters required and their proper line-up are defined
by the session description protocol (SDP), AES67 does not define a mandatory method to transport
the data; hence, manual read-out and entry is assumed as the minimal common ground.
Most AES67 systems or devices provide means of discovering available streams on the network and
support protocol-based communication of these SDP parameters. The methods and protocols
supported usually relate to the native networking solution those devices adhere to; RAVENNA,
Livewire and Dante all offer discovery and connection management functionality, which of course
includes the transfer of SDP data. Unfortunately, they all use different methods and protocols,
rendering them incompatible with each other:
•
RAVENNA uses DNS-SD
•
Livewire uses a proprietary protocol, but also supports the RAVENNA method
•
Dante uses different methods – a proprietary method based on mDNS
operation and SAP
Since Dante devices don't have means for manual read-out or entry of SDP data, there is no practical
way to establish connections between Dante devices with activated AES67 mode and any other
AES67 device. For this reason, some device manufacturers have decided to include SAP support.
19
Some AES67 devices have default Prio1 values of 248 which usually will result in those devices not
becoming GM, unless there is absolutely no better GM available on the network. In those cases, check the
achievable accuracy of all participating nodes as – depending on the clock quality of the then selected GM –
they may not be able to successfully settle into stable synchronization.
20
DNS-based service discovery -
21
Real-time Streaming Protocol -
22
Multicast DNS - https://en.wikipedia.org/wiki/Multicast_DNS
23
Session Announcement Protocol -
20
for discovery and RTSP
23
for AES67 formatted streams.
https://en.wikipedia.org/wiki/Zero-configuration_networking#DNS-SD
https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol
https://en.wikipedia.org/wiki/Session_Announcement_Protocol
Page 10 of 28
AES67 Practical Guide
21
for SDP transfer
22
for native stream