Search
Close this search box.

Demystifing Discovery

Introduction

In the world of audio networking the current buzzword is AES67. This is the interoperability standard that allows different audio networking protocols to pass audio to each other.

In the past there were different audio networking protocols but they were completely incompatible. Then it was realised that a number of these different protocols were in fact very similar. If they made small changes then they could communicate with one another.

What is Discovery and Connection Management?

In order for two networked devices to send audio to each other they need to know each other’s address and also how they should manage the connection between each other so they can communicate together.

If I need to make an international phone call I need to know two things – first the telephone number to call and then we need to agree what language we are going to speak in. The telephone number is the address and the language is the connection method.

SIP

AES67 uses a system called SIP for managing unicast connections. SIP stands for Session Initiation Protocol. It sets up a connection between two end points such as a mixer to an amplifier. The two devices signal to each other that they can accept connections of a particular type and they agree how they will communicate with each other. This process is essentially automatic and is unseen by the user.

However before SIP can do its job, the two devices have to know each other’s address, because SIP only deals with the method they will use to communicate.

You can of course just type in the addresses of the two devices, just like getting a telephone number and dialling manually. Another way to know the addresses of devices on the network would be to have a SIP server. This might be a PC sitting on the network. The server would contain details of all the connections on the network, a bit like having a phone book. When two devices want to start communicating they would ask the server for the address of the other.

Alternatives to SIP

As an alternative to a SIP server, you could have a discovery mechanism that would find and identify end points on the network. Discovery is the ability for equipment to automatically find other items. In an ideal world you would switch on your PC or mixing console and it would list all the other items by a friendly name, and say how they can communicate.

However our world is not ideal and discovery isn’t as elegant as that. The IT industry has invented different discovery methods and they each have different features and disadvantages.

Two common discovery mechanisms are Bonjour or SAP (don’t confuse it with SIP) and these could be used to show what is on the network. These methods automatically announce what is on the network rather than have a known list of connections like on a SIP server.

Bonjour was invented by Apple but is freeware for anyone to use. It was created to advertise/discover devices such as printers on a local network. It works well for simple networks but wasn’t really designed for large ones.

The SAP (Session Announcement Protocol) broadcasts information to all devices on a well-known multicast address. All devices listening to that port receive periodic information on available sessions. Essentially devices receive an updated business card from any participating device from time to time.

However things get a little more complicated. Bonjour is a very flexible and powerful mechanism for advertisement of different kind of services, while SAP is strictly related and limited to announcing available multicast connections sessions only.

Using Bonjour, you can announce the SIP URI for a unicast connection as well as relevant connection parameters for multicast sessions – plus lots of other useful services. But as mentioned above it doesn’t work well on large networks, especially not on corpoprate or routed networks.

Is Discovery Important?

AES67 is designed to be a lowest-common denominator to allow audio to pass. Normally this would be used to exchange audio signals between two completely different audio systems, such as between a broadcast truck and an installed sound installation. Its creators deliberately left out superfluous features and their intention was to make things as flexible as possible. Had they implemented a specific method of discovery, that might have prevented some protocols from becoming AES67 compatible.

Advertisement and discovery as well as directory services are used for lots of other services purposes on a network. In larger networks, these services are already in place and can be used for AES67 advertisement streams as well. If AES67 had mandated for a specific protocol, that protocol would have to be on place in parallel to any already existing service. This certainly does not impose a problem to a small self-contained live or install sound setup, but the IT guys managing the whole network wouldn’t like it.

The key to the future success of AES67 is to be as compatible as possible. If you want specific features, then you should specify equipment that uses your favourite protocol.

Whilst automatic detection of equipment is helpful, it’s not necessarily the most important thing when constructing an audio system. It’s very common for engineers to note down the IP addresses of their gear where they don’t want to have dynamic addressing. We all do detailed planning when designing systems, don’t we?

Sometimes we are required to use a particular IP addressing scheme so it fits into the larger IT plan, which again means we have to keep a log of IP addresses.

So whilst automatic discovery is helpful, it isn’t the most important feature when connecting audio networks together.