Audio Over IP - Making It Work - Part 3

Multicasting is an incredibly powerful tool used in broadcast infrastructures to efficiently distribute streams of audio, video, and metadata. In this article, we look at the advantages of multicasting, how it works, and the alternatives that overcome some of its operational limitations.

Broadcasters use distribution amplifiers (DA) to deliver multiple baseband signals in “one to many” systems. Multicasting is operationally equivalent to the DA but works by duplicating packets so that we do not have to add extra cabling to a system.

To begin multicasting, network administrators define a set of IP-multicast addresses for the network they are operating with. Devices such as microphones are allocated one of the IP-multicast addresses and use them to stream packets to the network. The IPv4 multicast range spans from to, providing over 248 million possible groups. Each group is divided into scopes defining different usage. For Audio over IP, the scope freely available to network administrators ranges from to, just over 16 million addresses.

Multicasting is provided at layer-2 to keep latency and jitter low and is referred to as IGMP-Snooping. A mapping between layer-3 IP multicast addresses and layer-2 Ethernet MAC addresses is defined allowing a unique MAC addresses to be created for each IP-multicast stream.

Without IGMP-Snooping, any multicast traffic received by the switch will be flooded to all ports on that switch, resulting in a network broadcast. This is a consequence of a switch not knowing which port to send a frame to, so it defaults by sending the frame to all ports. In the extreme, this causes excessive network congestion.

IGMP hosts, such as IP-Audio-Monitoring stations, will issue an “IGMP Membership report” encapsulated in an IP-datagram. The report, often referred to as a “join” message, requests one specific multicast group and an IGMP-snooping enabled switch will forward all frames to that receiver.

Diagram 1 – IGMP-snooping runs on the switch to determine which specific ports to move the layer-2 Ethernet packets to. This avoids network flooding.

Diagram 1 – IGMP-snooping runs on the switch to determine which specific ports to move the layer-2 Ethernet packets to. This avoids network flooding.

To stop receiving a multicast stream, the receiving host will issue an “IGMP leave” message.

During forwarding, the IGMP Querier (typically the switch) will issue IGMP Queries to all hosts (perhaps audio desks or monitoring stations) to check whether the hosts are still interested in the stream. If they report do not, or the query times out, the switch will stop sending the stream to the unverified port.

Hosts on different subnets can exchange multicast traffic if routers between them support a multicast routing protocol, such as Protocol Independent Multicast (PIM). The routers will then forward the IGMP Messages to the subnet where the streams originate.

Using a recording studio as an example, each of the microphones would be configured to have its own multicast address. It is possible to use direct mapping from each microphone to each input on the desk but this would restrict operation since no other device would be able to listen to the microphones and configuration would be extremely complex. Multicasting allows multiple destinations, such as the audio desk input and a monitoring station, to receive the same microphone output.

Diagram 2 – Riedel Communications RSP-2318 SmartPanel and Extreme Networks X460-G2 with multicast L2 switching and IGMP-Snooping.

Diagram 2 – Riedel Communications RSP-2318 SmartPanel and Extreme Networks X460-G2 with multicast L2 switching and IGMP-Snooping.

Multiple microphones could be configured by the network administrator to each have their own multicast stream. For example, if studio-1 is using twelve microphones, mic-1 would have IP-multicast address, mic-2 would have, all the way up to mic-12 which would have IP-multicast address

To keep jitter and latency low, each microphone, audio console channel, and monitoring station for studio-1 would connect to a port on the same layer-2 switch to form a LAN. However, to control network congestion and maintain security, studio-1 would use VLAN-1 and studio-2 would get its own VLAN-2. Any devices connected on VLAN-1 would not be able to access devices on VLAN-2 and vice versa. There may be many VLAN’s in use depending on the granularity of security required.

As well as configuring the IP multicast address of each microphone, the source and destination MAC addresses of the frame must also be configured. The source MAC is set by the manufacturer of the microphone. But the destination MAC address is derived from a combination of the reserved MAC prefix 01.00.5E and the IP address of its multicast stream, this is usually set by the operating system or implemented by the vendor of the microphone. This forms the next three numbers of the MAC address derived from the IP address.

Diagram 3 – This diagram shows mapping of IPv4 multicast addresses to MAC multicast addresses.

Diagram 3 – This diagram shows mapping of IPv4 multicast addresses to MAC multicast addresses.

To receive a feed of the microphone outputs, each audio channel on the audio console must subscribe to its associated IP-multicast stream.

The audio console would have a unique IP address and each channel would subscribe to one of the IP-multicast addresses. The audio console would send a “report” message for each channel to the switch to request a copy of the microphones multicast stream and hence its output. In this scenario, each microphone would issue a mono audio stream on a specific multicast address.

Source Specific Multicast is used to stop the possibility of multicast duplication. Supporting switches and routers will only forward multicast traffic if, the receiving host issues “IGMPv3” messages, specifying not only the multicast address it wants to receive, but also the source IP of the sending device.

A device can only connect to one layer-3 router to exchange messages as the “Time to Live” of its IP header is set to one, thus stopping the datagram from moving on to another router. IGMP facilitates communication between routers to allow streams to be accessed outside of a devices LAN.

Although IP-multicasting is incredibly powerful and extensively used, its limitations soon become apparent. IGMP is a program running on a CPU on the router and is constantly fighting for CPU time along with all the other protocols running on the router. As multicast streams increase and the number of devices wanting to connect to them also increases, so does the demand on the switches CPU. The streamed data reliability of the actual microphone output is not affected by the protocol but the speed and response with which devices can opt to switch to and from different streams is.

Switches and routers state maximum numbers of multicast addresses to be used on the device for that reason. Typical values are between 1,024 and up to 10,000 addresses. But some devices exist that can only manage 128 addresses.

This is another reason software defined networking (SDN) is gathering momentum. SDN has a hierarchical view of the underlying hardware network and controls switchers and routers directly to overcome the speed limitations of protocols such as IGMP.

Vendors use different methods of remote control. Cisco use the command line interface (CLI) and REST (Representational State Transfer). Arista uses REST but it’s different from Cisco’s version. AMWAs IS-06 is looking to resolve these differences by providing a common interface for SDN’s.

Multicasting works well when a connection needs to be occasionally made but can become slow to respond when there is heavy demand on the routers’ CPU. These limitations will be overcome as SDN develops.

Let us know what you think…

Log-in or Register for free to post comments…

You might also like...

Articles You May Have Missed – June 20, 2018

Until now, 4K/UHD and high dynamic range (HDR), in many ways, has been little more than a science project, as manufacturers have struggled to convince production entities of the long-term practicality and viability. Fears of overly complex pipelines and…

Are Helium-Filled Hard Drives More Reliable Than Air-Filled Drives?

The first commercially available helium-filled hard drives were introduced by HGST, a Western Digital subsidiary, in November, 2013. At the time, the six terabyte device was the highest capacity hard drive available. Backblaze, a major hard drive user, wanted to find…

Broadcast For IT - Part 11 - Sensors

In this series of articles, we will explain broadcasting for IT engineers. Television is an illusion, there are no moving pictures and todays broadcast formats are heavily dependent on decisions engineers made in the 1930’s and 1940’s, and in this art…

A Brief History of IP - Putting It All Together

Building reliable, flexible IP networks requires an understanding of infrastructure components and the interoperability of systems that run on them, especially when working in fast-paced, dynamic studios. Protocol interfacing is relatively straightforward, but as we investigate application level connectivity further,…

Articles You May Have Missed – June 13, 2018

“Everything is software today,” said the marketer. “That’s the problem,” said the engineer. While every broadcast engineer has some story about crashing software, data leaks, and duct-tape solutions, today’s nascent software industry might be compared to the embryonic industry of…