Many existing on-premise broadcast workflows are based on the RTP protocol, but did you know that SRT can be used to extend the reach of those workflows by tunneling RTP through SRT over unreliable networks such as the public internet?

In this post, we’ll take you through a very simple end to end workflow as an example. The following diagram shows how RTP is used to send an MPEG2 transport stream from a video encoder to a video decoder within a protected network, for example, an enterprise LAN or an MPLS leased line.

RTP transmission over reliable networks such as a Local Area Network

Replacing the private network with public internet is not that straightforward as an unreliable network will introduce packet loss and jitter. In addition, the stream must traverse firewalls when leaving or entering an enterprise network. At the same time, the content is not protected along the way and is therefore easily exposed.

RTP transmission over unreliable networks such as the public internet

SRT is able to recover packet loss, encrypt content and traverse firewalls, making it well suited to use as a tunnel across the public internet.

Here’s how it works:

The RTP traffic is sent to a UDP receiver, which forwards the MPEG-TS payload, including the RTP headers, over an SRT connection. On the receiver side, the stream is played out as UDP, but as the RTP headers are still in place, it would be like sending a local RTP stream to an existing RTP decoder.

Tunneling RTP through SRT over unreliable networks such as the public internet

This setup can be evaluated using the srt-live-transmit sample application included in the Open Source SRT package. The source RTP stream coming from an encoder has to be pointed to the UDP input of the SRT sender. The UDP output of the receiver at the destination location is then sent to the RTP input port of the decoder.

Since the application expects MPEG-TS traffic without RTP headers when reading from UDP, by default, it’s configured to receive 1316 Bytes (7 MPEG-TS frames) of payload per UDP packet. A command line option is used to increase the SRT payload size.

These are two srt-live-transmit sample command lines for the sender (UDP to SRT) and the receiver (SRT to UDP):

.\srt-live-transmit "udp://192.168.0.20:2000“ "srt://:1000?mode=listener&latency=125&payloadsize=1456" -c 1456
.\srt-live-transmit "srt://192.168.0.10:1000?mode=caller “ "udp://192.168.0.30:3000“ -c 1456

In this example, a source (e.g. an RTP encoder) is sending an RTP stream to 192.168.0.20:2000. The sender-side srt-live-transmit receives the MPEG-TS stream, including the RTP headers on port 2000 and listens for incoming receiver connections on port 1000. In our example, the IP address of the machine running the sender application is 192.168.0.10. The receiver application on a different machine is connecting to the server as a caller, receives the SRT stream and outputs the stream as UDP data to an RTP receiver (e.g. a decoder) with IP address 192.168.0.30 and port 3000.

Note: With SRT version 1.4, it will no longer be necessary to specify the payload and/or chunk size (-c) when using-srt-live-transmit.

In a similar vein, redundant RTP with FEC (SMPTE 2022-1 Forward Error Correction) can be tunneled through an SRT connection. The extra UDP streams for the FEC column and row data packets can be routed over two extra SRT connections. However, all three SRT connections can be sent over a single UDP port by using SRT multiplexing, which is part of the core protocol.

Tunneling RTP with FEC through SRT using SRT multiplexing

This setup can be further extended to support redundant RTP (SMPTE 2022-7) workflows. Multiple RTP streams can still be synchronized on the receiver side since the RTP headers remain unchanged on either path of a redundant setup.

Tunneling multi-path RTP through SRT for redundancy

At this point, it’s worth mentioning that native redundant workflows are coming to the SRT protocol during the IBC2019 timeframe. This means that every SRT enabled endpoint will be able to make use of this functionality, dramatically simplifying the installation.

Multi-path redundancy is coming to SRT

To find out more, register to attend the SRT Open Source Technical panel on September 15th at IBC. Designed for current and future SRT developers, the panel will focus on the applications and workflows that SRT solves, the technical roadmap as well as real-world implementation stories.

Not going to IBC? No problem! Register to attend anyway and we’ll share the recording with you after the event.