As an IP-based solution, RAVENNA is based on protocol levels on or above Layer-3 of the OSI reference model.
IP can be transported on virtually any LAN and is used as the base layer for communication across WAN connections (including the internet). Although Ethernet will be deployed in most cases as underlying data link layer, IP is in general infrastructure-agnostic and can be used on virtually any network technology and topology.
While simple streaming across a network can be achieved without any synchronization at all, in pro audio applications a tight synchronization between all devices and streams is absolutely
mandatory. While playback synchronization in most applications requires sample accuracy, it has been the goal for RAVENNA to optionally provide superior performance by providing
phase-accurate synchronization of media clocks according to AES-11; this would render the separate distribution of a reference word clock throughout the facility or venue obsolete.
In RAVENNA, synchronization across all nodes is achieved through IEEE1588-2008 (Precision Time Protocol - sometimes referred to as PTPv2), another standard protocol which can be operated on IP. PTPv2 provides means for synchronizing local clocks to a precision in the lower nanoseconds range with reference to a related master clock - provided that all participating switches natively support PTPv2. But even without native PTP support, the achievable precision - while varying depending on size and bandwidth utilization of the network - will be more than sufficient to reach sample accurate synchronization across each node.
Sample-accurate synchronization can even be reached across WAN connections, when local master clocks are synchronized to GPS as a common time domain.
As IP has been chosen as a basis, it's only natural to use RTP for streaming of media content.
RTP - the real-time transport protocol, as defined by the IETF is widely used and supported by numerous applications and comes with a large number of standardised payload formats. For RAVENNA, specifically RTP/AVP over UDP together with RTCP (the real-time transport control protocol) according to RFC 3550 is used. This provides the possibility to transport any RAVENNA stream across IP-based WAN connections. Basic payload formats for audio are 16 and 24-bit @48 kHz with any desired number of channels. This would allow any standard media player to potentially link to a RAVENNA stream and monitor its content - even without knowledge or support of any of the other RAVENNA-specific features or methods. Of course the payload format is not restricted to those basic formats as with RTP a huge variety of different payload formats for audio and video is already defined; it is even is supported both in unicast and multicast mode on a per-stream basis providing the highest flexibility to match the distinct requirements of different applications. Unicast is preferred in situations where a certain stream needs to be transported to a single destination only or where the network infrastructure or application prohibits the use of multicast (e.g. across most WAN connections). On the other hand, multicast allows resource-efficient usage of network links and faster switching between available streams in situations, where a certain stream will be accessed at different locations.
As different services can co-exist with RAVENNA on the same network, it has to be ensured that the traffic related to RAVENNA will be expedited with priority across the network.
For IP-based traffic, several QoS schemes have been defined as standard over time. Today, DiffServ has largely supplanted other Layer 3 QoS mechanisms (such as IntServ) as the primary protocol to provide different levels of service and is widely supported by most modern managed switches. DiffServ operates on the principle of traffic classification, where each data packet is placed into a limited number of traffic classes, rather than differentiating network traffic based on the requirements of an individual stream. Each traffic class can be managed differently, ensuring preferential treatment for higher-priority traffic on the network.
Even within RAVENNA there are different priorities assigned to different classes of traffic: while traffic related to synchronization receives highest priority, immediately followed by any real-time media traffic, control and configuration traffic will be on a lower priority level. Any non-RAVENNA traffic would receive the lowest (standard) priority and will be treated as best-effort traffic.
A receiver can connect to any existing stream through RTSP / SDP protocol. Again, this scheme is supported by most common media players. While RTSP is used for control communication between receiver and sender, the SDP record contains any relevant information about one or more streams - like stream name, payload formats, number of channels, access information etc. Although a typical RAVENNA SDP contains some specific extensions (i.e. clock domain and sync information), any non RAVENNA-aware media player can still receive and play-out a RAVENNA stream by just ignoring the specific extensions.
In order to participate in an IP-based network communication, a device must obtain a unique IP address. Then, in order to be recognized by other RAVENNA nodes, a device must announce its existence and advertise information about available services (e.g. IP address and host name, supported protocols, access information, information about available streams etc.). Service advertisement & discovery is based on the DNS-SD protocol. In order to support a wide range of application environments, RAVENNA supports two different methods for device configuration and service advertisement & discovery: In managed networks usually DHCP and DNS services are operated under management and control of a network administrator. In small networks, where usually no DHCP / DNS server is present, the zeroconf mechanism - a fully automatic, self-configuring method - will be used for auto-IP assignment and service advertisement & discovery.
RAVENNA offers a highly flexible latency scheme, ranging from very low latency numbers in the sub-milliseconds area up to latency numbers large enough to suit the constraints of a WAN
infrastructure. Unlike in other solutions, RAVENNA does not force the latency to system-wide defaults. In fact, the latency can be set for any stream individually and depends on a number
A fundamental part of the Ravenna standard is the almost limitless configuration options that allow you to fine tune network audio streams between devices to best suit the application and hardware involved. In order to assist with operation and choice of these configuration options the concept of profiles has been designed. All Ravenna devices must have the ability to connect using a ‘generic’ profile which has been defined as follows: