AWS Elemental Live SRT outputs configuration and workflows

Introduction

AWS Elemental Live version 2.21 introduced support for ingesting transport stream (TS) inputs using SRT. Now, version 2.22 supports delivering TS outputs using SRT.

The SRT (Secure Reliable Transport) protocol is an open-source transport technology optimized for live audio/video streaming. SRT enables secure and reliable transport of content across unpredictable, noisy networks, such as the Internet. SRT offers multiple benefits when transporting live video content over the internet:

• It helps compensate for jitter and bandwidth fluctuations.
• It minimizes the packet loss.
• It supports AES encryption to protect content in transit.

SRT is only one of the delivery content types and protocols that Live supports. For a complete list, see the AWS Elemental Live User Guide.

In this post, we are presenting current SRT support in Live, with particular attention to setting up a workflow with AWS Elemental MediaConnect as an SRT destination. We are also showing a few configuration aspects of SRT outputs in Elemental Live.

SRT support in AWS Elemental Live

Elemental Live supports ingest of SRT sources in caller mode. It supports delivery of SRT outputs in either caller or listener modes.

The following Table-1 provides an overview of current SRT protocol support in Live:

Caller and listener, sender and receiver

With SRT, the encoder and the downstream destination each have two roles – sender and receiver, and caller and listener.

• The send and receive roles cover the direction of the transmission of the content. With an SRT output, Elemental Live is always the sender of the output.
• The call and listen roles cover the handshake protocol. The caller initiates the handshake that precedes transmission. The listener listens for the handshake, and will respond when it receives the handshake request.

Typically, the decision to configure Live as the caller or as the listener is based on the role of the downstream system. If the downstream system is configured as the listener, you must configure Live as the caller, and vice versa.

Elemental Live as SRT caller

A typical scenario for setting up Live as the caller is when the downstream destination is a MediaConnect flow. A MediaConnect flow always works in listener mode, so Live must be the caller.

When you start the Live event, Live initiates the handshake to AWS Elemental MediaConnect. After the handshake is completed, Live automatically starts streaming video packets to MediaConnect.

In the following sections we are presenting how to set up the workflow in MediaConnect and Live. The MediaConnect flow and the Elemental Live event must work together.

Note: Elemental Live and MediaConnect can be configured seamlessly to work together using the flow ARN; however, in this post we are demonstrating the more generic configuration that will work with any SRT receiver.

Example of configuration on AWS Elemental MediaConnect (listener) side

The following is an illustration of the setup on the AWS Management console of a MediaConnect flow with a Standard source. The fields that relate to SRT are highlighted.

Consider the following when setting up the flow to listen for SRT requests:

• Protocol: select “SRT listener” from the drop-down list
• Inbound port:
  • The SRT protocol transports content via bidirectional UDP. On the SRT listener, you must designate a UDP port where the listener will listen for an inbound request to start the SRT streaming session.
  • Notice that a MediaConnect flow supports any inbound port from 1 to 65535 except 2077 or 2088. In addition, it’s recommended to avoid using system ports 1 to 1023.
  • In our example in figure 2, the inbound port is 5050.
• CIDR block:
  • Set up MediaConnect so that only your Live node can access the SRT listener flow. You therefore need the public IP address of the Live node.
  • To obtain this address, run the following command through SSH on the node: curl http://checkip.amazonaws.com
  • In the MediaConnect flow, create a CIDR block to allow this address, as shown in figure 2.
• Minimum latency:
  • The best value to use for latency depends on your workflow. Keep in mind that using higher latency results in higher stability.
  • Configure both the event and the flow with identical latency. In case of latency mismatch between the two, the higher value will be used on both sides.

Content encryption

If you want to use AES encryption for the content, keep in mind that SRT uses a passphrase to derive the AES key. MediaConnect uses the passphrase to decrypt content. To give MediaConnect access to the passphrase, you must set it up as a secret in AWS Secrets Manager, and you must grant permission for MediaConnect to access the secret, as explained here. Notice that:

• Both the SRT caller and listener must use the same passphrase.
• Live supports passphrases with a length of 10 to 72 characters.
• As an example, we will use the passphrase “AWS is Awesome” on both sides in this post as shown in figures 3 and 5.

Here is an illustration of the setup for decryption in the MediaConnect flow source. Notice that in MediaConnect, you set up with the Secret ARN. You don’t enter the actual passphrase anywhere in MediaConnect.

After the flow is created, MediaConnect will associate an inbound IP address with the flow. Live will use this address plus the inbound port as the destination, as shown in figure 5.

Example of configuration on the Elemental Live (caller) side

When configuring Live, keep in mind that the on-premises firewall must be configured to allow outbound UDP traffic to MediaConnect flow, and to allow inbound UDP traffic to Live.

In this example, we haven’t configured for redundancy, so only the fields for the primary destination are completed. Notice how the values we entered follow the preceding guidelines.

In the Live web interface, consider the following when creating the output:

• The SRT protocol is available via the “Reliable TS” output group tab.

• Delivery Protocol: Choose “Secure Reliable Transport”. Also note that the SRT Connection Mode is “Caller”.
• Destination:
  • The destination, consists of the protocol (srt://), the MediaConnect flow inbound IP address, and the port.
  • The IP address and port exactly match the values you listed in the MediaConnect flow. So, the source on the MediaConnect side is the destination on the Live side.
• Encryption fields: The passphrase is always in plaintext. The passphrase in AWS Secrets Manager and the passphrase you enter must be identical.
• Latency: Set to the same value we used for MediaConnect flow latency.

Monitoring the workflow

After both the MediaConnect flow and the Live event are started, you can monitor the workflow in the MediaConnect console (figure 7).

• In the Sources section for the flow, the “Source health” turns green and shows as “Connected”.
• In the Source health metrics page for the flow, the section includes a graph that provides a visual confirmation that the workflow is working as expected. The source bitrate indicates that bitrate coming into the flow.

In the sample graph in figure 7, the source bitrate shows as 6 mbps. Verify that this adds up. In our example, we know that we set up the output with a video bitrate of 5 mbps. When you add in the audio, the TS overhead, and the SRT control packets, a source bitrate of 6 mbps looks reasonable.

Troubleshooting tips: flow isn’t working

If the MediaConnect flow source health stays “Disconnected”, check the following:

• Verify that there are no typos or extra white spaces in the passphrase stored in AWS Secrets Manager and configured in the Live event. A good indicator of SRT passphrase mismatch could be seen in the Live event logs showing a “connection rejected” message:

[Log message]

SRT Connect error: Connection setup failure: connection rejected

• Perhaps the public IP address of the Live node is not configured properly in the MediaConnect CIDR block. Or perhaps the on-premises firewall is blocking the traffic. Look at the Live event logs for a “connection time out” messages.

[Log message]

SRT Connect error: Connection setup failure: connection time out

Elemental Live as SRT listener

A typical scenario for setting up Elemental Live in SRT listener mode is when the downstream destination or receiver is located behind a NAT or firewall. That is, the receiver is not reachable from external networks or the internet. Therefore, the Elemental Live cannot initiate the SRT session handshake as a caller.

In order to demonstrate this scenario, we will use another Elemental Live node as receiver. In the workflow, you have two Elemental Live nodes, which we will call “Live Sender” and “Live Receiver”.

The Live Receiver is accepting the SRT content as an input. Keep in mind that Elemental Live can only ingest SRT content when it is set up as the caller. Therefore, the Live Receiver node must be the caller and the Live Sender node must be the listener.

Configure the Live Sender and the Live Receiver so that they work together. Consider the following:

• The Live Sender is configured to listen to a specific UDP port. In our example in figure 9, we use port 5070.
• The Live Receiver must have a valid network route to the Live Sender in order to initiate the handshake. In our example in figure 10, the Live Receiver is configured to call the private IP address of the Live Sender.
• In case the Elemental Live built-in firewall is enabled on the Live Sender, you must add a rule to allow inbound UDP traffic to the UDP port designated for listening for SRT requests. To open the port on the Live Sender firewall, see Open ports on the firewall.

Example of configuration on the SRT listener (Live Sender) side

Here is an illustration of the setup of the SRT listener output in the Live Sender.

The configuration of SRT output in listener mode is similar to what was discussed previously for the caller mode, except for following two differences:

• The SRT Connection Mode is now set to “Listener”.
• For the Primary Destination, Live requires the same URI format with “srt://” prefix. However, what really matters is the inbound UDP port (5070) because upstream system (Live Sender) will be listening for SRT requests on that port on all its network interfaces. Therefore, we use the internal loopback IP address “127.0.0.1” as the destination.

Example of configuration on the SRT caller (Live receiver) side

Here is an illustration of the setup of the input in Live Receiver. Notice that the IP address “10.13.133.77” in figure 10 is the private IP address of the Live Sender.

Redundancy workflow using SRT listener mode

SRT outputs can be set up in a redundant configuration to implement redundant contribution streams to the downstream system. Configuring redundancy in an SRT caller scenario follows the same model as redundancy with other output types, including RTMP or Zixi outputs.

The redundancy configuration when Live is the SRT listener follows a different model, which we will now discuss.

We mentioned earlier that the SRT listener mode is used when the SRT receiver is not reachable by the SRT sender. Another use case for SRT listener mode is for redundancy, or more precisely, distributed output using redundancy. You can set up in SRT listener mode when multiple receiver nodes in the downstream remote system need to ingest the SRT source at a certain point. In other words, when the receiver IP address is changing over time.

Consider the workflow shown in figure 13 where the downstream system (the on-premises Location B) is an N+M cluster that consists of N primary Live nodes and M backup Live nodes. If the primary SRT receiver node chassis fails, then one the backup nodes will be promoted to replace the failed primary node.

In this scenario, the receiver node IP address will change, but from the SRT perspective, this change has no impact because the newly promoted receiver node is the party that calls the source to initiate the session.

Cleanup

If you followed the instructions and implemented the setup described in the “Live as Caller” scenario, make sure that you delete the AWS resources after your testing is completed, to avoid incurring any unnecessary cost in your AWS account.

• In MediaConnect, stop the flow then delete it.
• In AWS Secrets Manager, delete the secret where you stored the passphrase.

Conclusion

In this post, we presented the new SRT outputs feature released in AWS Elemental Live software version 2.22. We demonstrated the configuration of SRT outputs in both caller and listener modes using real life examples. We also discussed how to architect for redundancy using SRT listener outputs. For further details on these topics please get in touch with your AWS Elemental account team.

Additional Resources

• AWS Elemental Live User Guide
• Blog post: Getting started with SRT inputs in AWS Elemental Live