BEIT Paper Track: Recommendations for Professional Media Networking (PMN)

The speed and reliability of the internet has made it possible for broadcasters to use it as a cost-effective low-latency contribution link. A Monday afternoon BEIT session will explain what’s being done to make the internet perform best for broadcasters.

On Monday at NAB Shows, exhibits are always swamped with first-day visitors. Experienced broadcast engineers have learned that some of the most valuable engineering information isn’t often available in crowded exhibits, especially on opening day.

Upstairs in the quiet of meeting room N256 on Monday at 1:30 p.m. will be a presentation in the Cybersecurity and IP Transition Tracks “A performance Measurement Study of the Reliable Internet Stream Transport Protocol.” The topic will be presented by Dr. Ciro Noronha, Director of Technology, Compression Systems at Cobalt Digital and Jeff Littlejohn, Executive VP, Engineering and Systems Integration at iHeartMedia.

Dr. Noronha holds a BS and MS in Electrical Engineering from Instituto Tecnologico de Aeronautica, Brazil, and a Ph.D. in Electrical Engineering from Stanford University. He has worked in the compressed video over IP space since 1995. He shared an advanced copy of his BEIT 2019 paper with The Broadcast Bridge, which is the source of the following quotes and highlights.

“The speed and reliability of the Internet has made it possible for broadcasters to use the Internet as a cost-effective low-latency contribution link. Many companies have commercial products providing this functionality, and all these products are implemented as a variation of the ARQ (Automatic Repeat Query) protocol. The Video Services Forum (VSF) has published the TR-06-1 Reliable Internet Stream Transport protocol specification to provide interoperability between such products,” Dr. Noronha’s abstract says.

TR-06-1 Reliable Internet Stream Transport

There are numerous commercial products in the market that use ARQ to provide this functionality, some using proprietary implementations that do not interoperate. To address this interoperability issue, the Video Services Forum (VSF) started the Reliable Internet Stream Transport (RIST) Activity Group in 2017 to create a common protocol specification, and to promote interoperability between products from different vendors.

The RIST Activity Group selected the ARQ technique for packet recovery. ARQ was devised in the 1960s and can be found in most computer networking textbooks. The BEIT session will address how the ARQ protocol works, and what happens when a receiver detects a packet loss and requests retransmission.

RIST Activity Group also selected the Real Time Transport Protocol (RTP) [3] for the media transport. RTP is a very simple layer on top of UDP and provides sequence numbers to detect packet loss and timestamps to remove network jitter, if required. The use of RTP ensures that RIST-compliant systems can interoperate with non-RIST systems at a base level without packet loss recovery.

RIST selected the Real Time Transport Control Protocol (RTCP) [3] associated with RTP for the retransmission requests. Two types of retransmission request messages have been defined and will be explained in the session. A RIST receiver may use either type of message. An advanced RIST receiver may dynamically decide which message to use based on the loss pattern, thus optimizing the bandwidth utilization.

RIST and Firewalls

Typically, the sender and receiver are behind firewalls for security reasons. RIST Simple Profile only requires that UDP ports P and P+1 be opened at the firewall located at the receive site. The sender is configured to transmit to the public IP address at the receiving site.

The flow from the sender to UDP port P is unidirectional and will contain the audio/video content. The flow from the sender to UDP port P+1 establishes state in the firewalls at the sender and receiver sites; since the receiver directs its RTCP packets towards the source IP and UDP port of the traffic received in port P+1, these packets will be forwarded back to the sender. Since the RTCP flow from both sides is periodic, state is maintained in the firewalls.

RIST Simple Profile also includes IP Multicast support. Operation is very similar to unicast. RIST Simple Profile supports multiple paths between the sender and the receiver. The session will describe which scenarios are applicable for broadcasters.

At last fall’s IBC 2018, several companies participating in the RIST Activity Group presented a demonstration. Each company implemented the protocol directly from the Specification without shared libraries or code. A bank of RIST decoders were made available in Illinois. The various participating companies transmitted streams over the Internet from different parts of the world to the bank of decoders. The signal from the decoders was combined in a multi-viewer, and the output of the multi-viewer was published live to YouTube.

A set of measurements was performed using a real-time encoder transmitting actual audio/video content, a network simulator, and a real-time decoder. The results will be detailed in the session.

Packet Re-Ordering

The cost of adding a Reorder Section is added latency. The latency factor depends on the application. Some applications, such as live news, require low latency. Other applications, such as monitoring, may not. The cost of not having a Reorder Section is bandwidth efficiency: the receiver may request the retransmission of a packet that is still in flight and will arrive shortly. Since packets have sequence numbers, receivers can identify and discard duplicates, so other than the waste of bandwidth, there is no other penalty. More will be explained in the presentation.

RIST User Recommendations

When setting up a RIST Simple Profile link, a user will need to manually choose a few parameters to optimize the link. In the presentation, choices will be identified and explained, and recommendations outlined. For more details, attend the session.

Need a free exhibit hall pass? Click on this link and enter MP01 when requested.

Need a free exhibit hall pass? Click on this link and enter MP01 when requested.

Let us know what you think…

Log-in or Register for free to post comments…

You might also like...

Why We Need OTT Monitoring – Part 2

In the previous article in this series, “Understanding OTT Systems”, we looked at the fundamental differences between unidirectional broadcast and OTT delivery. We investigated the complexity of OTT delivery and observed an insight into the multi-service provider silo culture. In thi…

Data Recording and Transmission: RF

In part 8 of the series “Data transmission and storage”, consultant John Watkinson looks at some of the intricacies of RF transmission.

Essential Guide: When to Virtualize IP

Moving to IP opens a whole plethora of options for broadcasters. Engineers often speak of the advantages of scalability and flexibility in IP systems. But IP systems take on many flavors, from on-prem to off-prem, private and public cloud. And…

Understanding OTT Systems - Part 1

In this series of articles, we investigate OTT distribution networks to better understand the unique challenges ahead and how to solve them. Unlike traditional RF broadcast and cable platform delivery networks, OTT comprises of many systems operated by different companies…

Digital Advertising Surpasses TV and Print for the First Time

The times they are a changin’ and faster than ever. For the first time, digital advertising in the United States will surpass the amount of money spent on traditional ads used by television and print media, a research firm predicts.