How to Streamline Remote Management

Systems that enable remote dialog, management or control have become indispensable, and the options offered by Audio over IP or even cloud services are increasingly gaining attention. But what’s the best way to set up a software-based workflow for optimal remote operation and to link the old and the new world of audio broadcast?

The implementation of Linux-based embedded multimedia over IP software is one approach. And users can easily install the software on hardware, PCs, VM or in the cloud to create a network connection. It also allows the transmission of on-demand contributions from central, mobile and remote sites regardless if connections are permanent or event-based.

In general, multimedia over IP software is able to support all protocols or standards for AoIP and a wide range of audio codecs, taking into account the different frame sizes in the case of AAC profiles or Opus. This removes major pain points for technical teams, such as interoperability or compatibility. What’s more, a modular choice of features lets users run various broadcast applications such as studio to WAN bridge, SIP network, MPEG-TS multiplexing, synchronized playout, FM or web radio to TS gateway and web radio steaming.

Network Operation

If fewer channels are needed for, say, reporters at home, local studios, OB vans or small networks such as parliaments, station staff can choose to run the solution on 19-inch hardware, pocket-sized boxes or via a PC. Using AES67, EBU Tech 3326, SIP, Dante, Livewire or Ravenna, the multimedia over IP software allows for on-demand augmentation of the required channels.

Take, for example, the headquarters of a radio network. Here, multimedia over IP software can operate as a server solution. And in order to achieve suitable scalability and reliability, the system should consist of several containers that run independently and are separated. In addition, the solution’s transcoding capacities permit the integration and reception of contributions into the distribution networks respectively, whether it is a CDN, DAB+, IP or satellite.

For streaming, the system should also be able to transform from Livewire, AES67 or Ravenna audio signals to Icecast or adaptive bitrate protocols like HLS and MPEG Dash. This type of “non-locked-in” design separates the contribution part and the distribution part, and allows technicians to replace one or the other if necessary.

Remote Management

To address the distances that need to be bridged, the above-mentioned options for network operation are worthless if it doesn’t imply the transformation of remote sites into virtual at home locations. For this purpose, a web-interface for the software offers some intelligent features.

Usability in general: The web-interface is accessible via defined IP addresses from the headquarters and each remote site in the field. This enables technicians to access all devices of a network and allows for centralized management of the system. The user administration allows defining the rights of each user group. This prevents artists or reporters, for example, from being overwhelmed with information or configuration parameters.

Dealing with use-case: Configuration of a network consisting of numerous devices can be time-consuming and sometimes impossible for reporters at home. This is particularly true when defining parameters for applications like synchronized playout, SIP networks, SRT streams or MPEG-TS multiplexing. Also, the configuration of devices located somewhere that’s not easily accessible like on a mountain peak can be challenging. Fortunately though, it’s possible to create a main settings file, which contains the respective parameters for each application.

Here are a few brief examples:

• Synchronized playout: External clock (1PPS or PTP), NTP (Network Time Protocol), global delay, send delay or de-jitter delay.
• SIP connections: SIP registrar, phone number, setup of a SIP phone book to support establishing connections with just one click.
• HLS streams: configuration of different audio qualities for the same source.
• SRT: Caller / Listener mode, latency or encryption.

Operators remotely or centrally manage the upload of the main settings. Likewise, it’s possible to upload features or channel activation licenses. The same applies to firmware updates or bug fix files or downloading a diagnostic report. Moreover, every parameter contained in the web interface is also part of the SNMP MIB, which allows for integration into network management systems.

Concentrating on the essential: For monitoring, information on the overview page varies depending on the applications. For synchronized playout purposes, parameters such as audio or IP buffer, clock source, network compensation delay or sync accuracy are displayed. When using the SRT protocol, the display provides information on, for example, calling/listening modes, received packets, lost packets and retransmitted packets.

And when different Elementary Streams have been multiplexed to an MPEG-TS for DVB-S/S2 distribution, then values such as Service ID, PMT PID, sample rate, audio source or codec are displayed on the overview page.

In conclusion, modularity, interoperability and well-designed user interfaces open the way to better workflows. Keep in mind that the more versatile a solution is, the longer it will be able to meet the needs of changing workflows.

That author is sales and marketing manager for 2wcom.