Anybody using SRT (Secure Reliable Transport) for video delivery is no stranger to the challenges of configuring and maintaining the SRT stream. Most users control only one end of the SRT stream as they are receiving content from local and remote sites, or they are in the business of streaming to others. The same challenges always remain: how to configure the SRT to the network condition taking into account requirements like: latency, Stream bitrate, available network bandwidth, setting special flags to fine tune the SRT.

Many users believe that the SRT is like TCP and no special configuration is in order, they tend to use factory defaults for streaming and fall short.  Many don’t read the instructions and documentation provided by the equipment vendor or widely available documentation and recommendation in the SRT github (Haivision.Github ).

Many put their trust in the SRT protocol to get them out of trouble, without taking the time to get familiar with the network and fine tune the SRT to perform at its most durable configuration.

The SRT protocol comes with API and statistics that can assist the user: RTT, packet loss, packets in flight and more. But many users don’t understand or care to dive into the information. User will blame the equipment manufacturer or the network provider for their hardship.

In this article I will try to show a different way to look at the network to discover the network conditions that are important for the optimal SRT configuration, furthermore what other short lived and historical information we should investigate, while running our SRT stream as a sender/receiver. 

Any reliable delivery protocol is based on function blocks within the sender and receiver:

Sending Packet buffer is used by the sender to cache sent packets for retransmission.

Receiver Packet buffer is used by the receiver for network jitter decoupling, lost packet detection, reordering of packets based on their original order.

Packet reading element that reads out packet from the receiver packet buffer, these packets are decoupled from the network artifacts and correspond to the original input stream in the sender.

The reliable delivery protocol works to establish a control channel between the receiver and sender to signal loss of packets and to measure network RTT (this is a key piece of information to control and pace packet retransmission).

The sending user may want to know the exact available bandwidth of the network. The bandwidth may need to be spread among multiple streams that he plans to send out.

The receiver will need to know the stream jitter behavior over time, this is critical for fine tuning retransmissions.

The RTT behavior, The SRT code uses RTT measurement to fine tune the retransmission messages. The user should measure ad hoc and long-term values of the RTT.

Network route changes impact the receiver ability to cope with bursty or lossy input stream. A user may elect to start with a more stable and fixed route than one which is ever changing.

Detection of the path elements (HOPS) that make the stream route is important for identifying weak spots that might be slow to respond (pointing to possible congestion).

Most SRT users today don’t have this information in hand and once a stream is broken, they guesstimate the nature of the problem or start a long and costly probing of the network using tools like Wireshark to find the issue.

Alvalinks SRT probe monitors the network traffic and focuses on user selected SRT flows (regardless if they are Listener or caller). A dedicated SRT probe tracks every SRT packet that belongs to an SRT session (data and control) to produce time correlated Charts and KPIs for the user. This KPI includes Stream bitrate, Control bitrate, retransmission bitrate, packet loss, Error rate, RTT, Jitter and more. In parallel the Alvalinks probe tracks the route make and gathers the HOPs information and RTT values. If a disconnect or SRT stream break up, the Alvalinks agent will track the new session and continue reporting the new stream statistics.

As with all Alvalinks probing, the ad hoc KPI are evaluated to produce a flow score to simplify the behavior to nonprofessional with a grade and color scheme.  All the data gathered is stored in a common database for chart drawing, analytics, alarming and historical information.

With this information in hand, the user can better fine tune the SRT stream configuration or suggest to his peer what configuration enhancements (for example; peer latency, rcv latency, multiplier, Max bandwidth, input bandwidth, TTL,  sender buffer size, RCV buffer size, loss max ttl and many more ). This way the user can improve the SRT application for example FFMPEG, RESREAM.IO, OBS or professional equipment offering these control options.

Multiple flows can be monitored in parallel on the same location.

The SRT monitor is perfect for cloud ingest of multitude streams, with a dedicate probe assigned for each SRT session. The same is true for SRT distribution and playout to multitude of destinations. The Service provider can use the SRT monitor to guide the remote peers on how to better configure his SRT stream for continuous and successful operation.

Contact [email protected] for more information.