SRT (Secure Reliable Transport) statistics are crucial for monitoring and optimizing streaming performance. These statistics are divided into three main types: accumulated, interval-based, and instantaneous.

1. Accumulated Statistics measure data over the entire duration of the socket's existence, such as the total number of packets sent (pktSentTotal) and received (pktRecvTotal).
2. Interval-Based Statistics measure data over specific intervals, like packets sent in the last 100 milliseconds (pktSent).
3. Instantaneous Statistics provide real-time data at the moment of query, such as round-trip time (msRTT).

Metrics used in Callaba’s SRT Statistics

Below, we’ll list the SRT statistics parameters that you can currently observe in Callaba's dashboard within the SRT stats section. These parameters provide critical insights into the performance and reliability of your streaming connections, helping you optimize and troubleshoot your streams effectively. 

Metrics used in the Graph 

In. Bitrate  | mbpsRecvRate

Incoming bitrate in kilobits per second (Kbit/s).

Out. Bitrate | mbpsSendRate

Outgoing bitrate in kilobits per second (Kbit/s).

Bandwidth  |  mbpsBandwidth

Estimated bandwidth of the network link, in Mbps. Sender only.

RTT (Round Trip Time)  | msRTT

Round-trip time in milliseconds (ms). Round Trip Time is the duration it takes for a signal to travel from the sender to the receiver and back again.

Drops  |  pktRcvDropTotal | pktSndDropTotal

• pktSndDropTotal:Total packets dropped by the sender because they couldn't be delivered in time.

• pktRcvDropTotal:Total packets dropped by the receiver due to late delivery.

 

Metrics used in the unfolding Details Section

Packets sent  |  pktSentTotal

–  The total number of data packets transmitted by the sender, including any retransmissions.

Round Trip Time  |  msRTT

– Round-trip time in milliseconds (ms). Round Trip Time is the duration it takes for a signal to travel from the sender to the receiver and back again.

Retransmit rate  | pktRetransTotal / pktSentTotal

–  The ratio of retransmitted packets to total packets sent, showing the percentage of packets that had to be resent

Packets lost  |  pktSndLossTotal

– The number of data packets that were lost during transmission from the sender to the receiver.

Buffer  |  byteAvailSndBuf  | byteAvailRcvBuf

• byteAvailSndBuf: The available space in the sender's buffer, in bytes. Sender only. This value decreases with data scheduled for sending by the application, and increases with every ACK received from the receiver, after the packets are sent over the UDP link.
• byteAvailRcvBuf: The available space in the receiver's buffer, in bytes. Receiver only. This value increases after the application extracts the data from the socket (uses one of srt_recv* functions) and decreases with every packet received from the sender over the UDP link.

Re-sent Packets   |  pktRetransTotal

The total number of data packets retransmitted by the sender due to initial transmission failure.

Send Rate  |  mbpsSendRate

The current rate at which data is being sent, measured in megabits per second (Mbps).

Connection time  |  msTimeStamp

The total time, in milliseconds, that the SRT connection has been active.

SRT Statistics Usage

There are two types of messages you can subscribe to in order to receive up-to-date statistics.

1. MODULE_SRT_SERVERS_STATS
   Use this message to get statistical data about your live streams. This is especially useful when you need to monitor anomalies such as bitrate or round-trip delay during the broadcast.
   
   
2. MODULE_SRT_SERVERS_ACTIVE_STREAMS
   Use this message to get active working streams as well as a timeline of stream connection or disconnection events. This is especially useful for monitoring the current state of the pipeline and tracking reconnection anomalies.

Accumulated SRT Statistics Overview

Accumulated SRT statistics measure data over the entire duration of the socket's existence.

msTimeStamp

This parameter tracks the time in milliseconds since the SRT socket was created, starting from a successful connection or binding. It is available for both sender and receiver.

Example: If msTimeStamp = 5000, the socket has been active for 5000 milliseconds (5 seconds).

pktSentTotal

Represents the total number of data packets sent by the SRT sender, including retransmitted packets. If the packet filter option is enabled, this also includes control packets generated by the filter. Introduced in SRT v1.4.0.

Example: If pktSentTotal = 1500, it means 1500 packets were sent, including retries.

pktRecvTotal

Denotes the total number of data packets received, including retransmissions. Similar to pktSentTotal, it includes control packets from the packet filter if enabled. Available for receivers since SRT v1.4.0.

Example: If pktRecvTotal = 1400, it means 1400 packets were received, including retries.

pktSentUniqueTotal

Shows the count of unique data packets sent, excluding retransmissions and packet filter control packets. This metric is crucial for understanding how many original packets were transmitted over the network for the first time. 

It can be calculated as pktSentTotal - pktRetransTotal or pktSentTotal - (pktRetransTotal + pktSndFilterExtraTotal) if the packet filter is enabled.

Example: If pktSentUniqueTotal = 1200, it indicates 1200 original packets were sent. 

pktRecvUniqueTotal

Indicates the total number of unique data packets received in time, decrypted without errors, and prepared for delivery to the application. This includes the first-arrived packets, regardless of whether they are original, retransmitted, or recovered by the packet filter. This metric excludes duplicates, late arrivals, and packets that failed decryption.

Example: If pktRecvUniqueTotal = 1100, 1100 unique packets were received without errors.

pktSndLossTotal

This metric measures the number of data packets lost at the sender’s side. Losses are identified either through loss reports from the receiver or when the sender initiates retransmissions due to a lack of acknowledgment within a specified timeout. Available for senders.

Example: If pktSndLossTotal = 50, it means 50 packets were lost during sending.

pktRcvLossTotal

Tracks total number of data packets currently missing at the receiver's end. This is detected when a newly received data packet's sequence number indicates that previous packets are missing. This metric focuses on packets that are either genuinely lost or currently missing in the sequence but does not account for packets that are simply received out of order.

Example: Let’s say we received packets 5, 6, 9, 10, 7,  the metric pktRcvLossTotal would not count packet 7 as lost. It detects missing packets when there is a gap in the sequence, so it would note packets 7 and 8 as currently missing when packet 9 is received. However, once packet 7 is received out of order, it adjusts the missing packet count accordingly. This metric specifically tracks gaps where packets are genuinely lost or delayed, not simply out of order.

pktRetransTotal

Counts the number of retransmitted packets sent by the sender. This metric is not interchangeable with the receiver’s pktRcvRetransTotal. Available for senders.

Example: If pktRetransTotal = 300, it means 300 packets had to be resent.

pktRcvRetransTotal

Measures the number of retransmitted packets registered at the receiver side. This is distinct from pktRetransTotal at the sender. Available for receivers.

Example: If pktRcvRetransTotal = 150, it means the receiver has registered 150 retransmitted packets.

pktSentACKTotal

Total number of acknowledgment (ACK) control packets sent by the receiver.

Example: If pktSentACKTotal = 200, the receiver has sent 200 acknowledgments.

pktRecvACKTotal

Total number of acknowledgment (ACK) control packets received by the sender.

Example: If pktRecvACKTotal = 180, the sender has received 180 acknowledgments.

pktSentNAKTotal

Total number of negative acknowledgment (NAK) control packets sent by the receiver.

Example: If pktSentNAKTotal = 50, the receiver has sent 50 negative acknowledgments.

pktRecvNAKTotal

Total number of negative acknowledgment (NAK) control packets received by the sender.

Example: If pktRecvNAKTotal = 45, the sender has received 45 negative acknowledgments.

usSndDurationTotal

Accumulates the total time in microseconds during which the sender has data to transmit. This includes time when packets are sent but not yet acknowledged. Available for senders.

Example: If usSndDurationTotal = 300000, it means 300,000 microseconds were spent transmitting data.

pktSndDropTotal

Tracks the number of data packets dropped by the sender because they couldn't be delivered in time. This uses the Too-Late Packet Drop (TLPKTDROP) mechanism and depends on certain socket options being enabled. Available for senders.

Example: If pktSndDropTotal = 20, it means 20 packets were dropped because they couldn't be delivered in time.

pktRcvDropTotal

Counts the data packets dropped by the receiver, including those not arriving in time, decrypted with errors, or signaled to be dropped by the sender. Available for receivers.

Example: If pktRcvDropTotal = 30, the receiver dropped 30 packets for various reasons.

pktRcvUndecryptTotal

Total number of packets that the receiver failed to decrypt. This statistic includes packets expected to be encrypted but found unencrypted, leading to their drop. Available for receivers.

Example: If pktRcvUndecryptTotal = 10, it means 10 packets couldn't be decrypted and were dropped.

pktSndFilterExtraTotal

Measures the number of control packets generated by the packet filter, essential for packet filtering and Forward Error Correction (FEC). Available for senders.

Example: If pktSndFilterExtraTotal = 25, it means 25 control packets were created by the filter.

pktRcvFilterExtraTotal

Counts the control packets received by the packet filter. Available for receivers.

Example: If pktRcvFilterExtraTotal = 20, it means the filter received 20 control packets.

pktRcvFilterSupplyTotal

Tracks the number of lost data packets recovered by the packet filter, such as FEC-rebuilt packets. Available for receivers.

Example: If pktRcvFilterSupplyTotal = 15, it means 15 lost packets were recovered by the filter.

pktRcvFilterLossTotal

Measures the number of lost data packets that the packet filter could not recover. Available for receivers.

Example: If pktRcvFilterLossTotal = 5, it means 5 packets were lost and couldn't be recovered by the filter.

byteSentTotal

Total bytes sent, including payload and headers (IPv4, UDP, SRT). Available for senders.

Example: If byteSentTotal = 1,500,000, it means 1.5 million bytes were sent.

byteRecvTotal

Total bytes received, including payload and headers. Available for receivers.

Example: If byteRecvTotal = 1,400,000, it means 1.4 million bytes were received.

byteSentUniqueTotal

Total unique bytes sent, excluding retransmissions and control packets, including payload and headers. Available for senders.

Example: If byteSentUniqueTotal = 1,200,000, it means 1.2 million unique bytes were sent.

byteRecvUniqueTotal

Total unique bytes received, excluding duplicates, late, and undecrypted packets, including payload and headers. Available for receivers.

Example: If byteRecvUniqueTotal = 1,100,000, it means 1.1 million unique bytes were received.

byteRcvLossTotal

Bytes of currently missing packets, including payload and headers, estimated based on the average packet size. Available for receivers.

Example: If byteRcvLossTotal = 50,000, it means 50,000 bytes are missing.

byteRetransTotal

Total retransmitted bytes, including payload and headers. Available for senders.

Example: If byteRetransTotal = 300,000, it means 300,000 bytes had to be resent.

byteSndDropTotal

Bytes of data packets dropped by the sender, including payload and headers. Available for senders.

Example: If byteSndDropTotal = 20,000, it means 20,000 bytes were dropped because they couldn't be delivered in time.

byteRcvDropTotal

Bytes of data packets dropped by the receiver, including payload and headers, estimated based on the average packet size. Available for receivers.

Example: If byteRcvDropTotal = 30,000, it means 30,000 bytes were dropped for various reasons.

byteRcvUndecryptTotal

Bytes of packets that the receiver failed to decrypt, including payload and headers. Available for receivers.

Understanding these parameters allows for detailed monitoring and optimization of SRT streaming performance, helping identify issues like packet loss, latency, and bandwidth usage effectively. 

Example: If byteRcvUndecryptTotal = 10,000, it means 10,000 bytes couldn't be decrypted and were dropped.

Interval-Based SRT Statistics Overview

Packets and Data

• pktSent: Total packets sent during a specific interval.
• pktRecv: Total packets received during a specific interval.
• pktSentUnique: Unique packets sent, excluding retransmissions, for a specific interval.
• pktRecvUnique: Unique packets received, excluding duplicates, for a specific interval.

Loss and Retransmission

• pktSndLoss: Packets lost by the sender during a specific interval.
• pktRcvLoss: Packets missing at the receiver during a specific interval.
• pktRetrans: Retransmitted packets by the sender in a specific interval.
• pktRcvRetrans: Retransmitted packets detected by the receiver in a specific interval.

Acknowledgements

• pktSentACK: ACK packets sent during a specific interval.
• pktRecvACK: ACK packets received during a specific interval.
• pktSentNAK: NAK packets sent during a specific interval.
• pktRecvNAK: NAK packets received during a specific interval.

Packet Filtering

• pktSndFilterExtra: Packet filter control packets sent during a specific interval.
• pktRcvFilterExtra: Packet filter control packets received during a specific interval.
• pktRcvFilterSupply: Packets recovered by the packet filter during a specific interval.
• pktRcvFilterLoss: Lost packets not recovered by the packet filter during a specific interval.

Bandwidth and Rate

• mbpsSendRate: Sending rate in Mbps.
• mbpsRecvRate: Receiving rate in Mbps.
• usSndDuration: Time in microseconds the sender had data to transmit during a specific interval.

Packet Handling

• pktReorderDistance: Sequence number gap between out-of-order packets at the receiver.
• pktRcvBelated: Packets received too late to be processed during a specific interval.

Dropped and Undecrypted

• pktSndDrop: Packets dropped by the sender during a specific interval.
• pktRcvDrop: Packets dropped by the receiver during a specific interval.
• pktRcvUndecrypt: Packets that failed decryption at the receiver during a specific interval.

Bytes Transferred

• byteSent: Total bytes sent during a specific interval.
• byteRecv: Total bytes received during a specific interval.
• byteSentUnique: Unique bytes sent during a specific interval.
• byteRecvUnique: Unique bytes received during a specific interval.
• byteRcvLoss: Bytes of lost packets during a specific interval.
• byteRetrans: Retransmitted bytes during a specific interval.
• byteSndDrop: Bytes of dropped packets by the sender during a specific interval.
• byteRcvDrop: Bytes of dropped packets by the receiver during a specific interval.
• byteRcvUndecrypt: Bytes of packets that failed decryption during a specific interval.

Instantaneous SRT SRT Statistics Overview

usPktSndPeriod

Current minimum time interval between consecutive packets sent (in microseconds). For the sender only.

Example: If packets must be sent at least 10 microseconds apart, usPktSndPeriod = 10.

pktFlowWindow

Maximum number of packets that can be "in flight." Indicates available buffer space at the receiver. For the sender only. 

Example: If pktFlowWindow = 1000, the sender can send up to 1000 packets before waiting for receiver ACKs.

pktCongestionWindow

Limits the maximum number of packets in flight to prevent congestion. For the sender only. 

Example: Starts at 16 and adjusts based on network conditions.

pktFlightSize

Number of packets currently "in flight" awaiting ACKs. For the sender only. 

Example: If pktFlightSize = 200, there are 200 unacknowledged packets currently in transit.

msRTT

Smoothed round-trip time in milliseconds, showing average network delay. Round Trip Time is the duration it takes for a signal to travel from the sender to the receiver and back again. Available for both sender and receiver. 

Example: msRTT = 50 ms means it takes 50 milliseconds for a packet to travel to the receiver and back.

mbpsBandwidth

Estimated network bandwidth in Mbps. For the sender only. 

byteAvailSndBuf

Available space in the sender's buffer in bytes. 

Example: If byteAvailSndBuf = 5000 bytes, there's 5000 bytes of space for new data.

byteAvailRcvBuf

Available space in the receiver's buffer in bytes. 

Example: If byteAvailRcvBuf = 10000 bytes, the receiver can accept 10000 bytes of new data.

mbpsMaxBW

Maximum transmission bandwidth in Mbps, usually from the SRTO_MAXBW setting. 

Example: mbpsMaxBW = 0 indicates no limit, while a non-zero value caps the bandwidth.

byteMSS

Maximum Segment Size in bytes. Should not exceed MTU. 

Example: Default is 1500 bytes, including all headers.

*MTU (Maximum Transmission Unit) refers to the largest size of a packet or frame, in bytes, that can be sent in a single network transmission. It includes the payload and all headers.

pktSndBuf

Number of packets in the sender's buffer awaiting acknowledgment. 

Example: If pktSndBuf = 50, there are 50 unacknowledged packets in the sender’s buffer.

byteSndBuf

Current value of pktSndBuf in bytes. 

Example: byteSndBuf = 7500 bytes, including payload and all headers.

msSndBuf

This parameter measures the timespan in milliseconds that packets remain in the sender's buffer before they are acknowledged by the receiver. 

Packets stay in the sender's buffer until the receiver acknowledges their receipt. This is to ensure reliability, as the sender can retransmit packets if acknowledgments are not received within a certain time frame.

Example: If msSndBuf = 200 ms, packets have been waiting for up to 200 milliseconds.

msSndTsbPdDelay

Timestamp-based Packet Delivery Delay (TsbPdDelay) value. This value shows the configured delay in milliseconds for delivering packets, set by the peer.

This setting helps ensure smooth playback by adding a controlled delay. It is set on the sender's side but indicates the delay expected by the receiver. For instance, in live streaming, it buffers the stream for a specified time (e.g., 100 milliseconds) to maintain continuous playback even if there are minor network issues.

Example: If msSndTsbPdDelay = 100 ms, it means packets are delayed by 100 milliseconds before they are processed.

pktRcvBuf

Number of acknowledged packets in the receiver's buffer. 

Example: If pktRcvBuf = 30, there are 30 packets ready for processing.

byteRcvBuf

Current value of acknowledged packets in the receiver's buffer (pktRcvBuf) in bytes. 

Example: byteRcvBuf = 4500 bytes, including payload and all headers.

msRcvBuf

Timespan of acknowledged packets in the receiver's buffer. I.e this parameter measures how long acknowledged packets stay in the receiver's buffer before being processed or played.

Example: If msRcvBuf = 150 ms, it means packets have been acknowledged and are waiting in the receiver's buffer for up to 150 milliseconds.

msRcvTsbPdDelay

Timestamp-based Packet Delivery Delay value, indicates the delay, in milliseconds, that the receiver applies to incoming data based on the configured latency settings (SRTO_RCVLATENCY or SRTO_LATENCY).

This setting ensures smoother playback by delaying the processing of received data. It helps manage network fluctuations and maintain a continuous stream.

Example: If msRcvTsbPdDelay = 100 ms, it means the receiver intentionally delays processing incoming data by 100 milliseconds.

pktReorderTolerance

Current packet reorder tolerance value. This value indicates how many out-of-order packets the receiver can tolerate before considering them lost.

This setting helps manage the reordering of packets that may arrive in a different order than sent. For instance, if packets 1, 2, 4, 3, 5 arrive, the receiver can reorder them correctly if the tolerance is set high enough. If more packets arrive out of order than the tolerance allows, those packets will be considered lost.

Example: If pktReorderTolerance is set to 5, the receiver can handle up to 5 out-of-order packets. If more than 5 packets arrive out of sequence, the extra ones are marked as lost.

pktRcvAvgBelatedTime

This value represents the accumulated delay of packets that arrived later than expected.

This setting tracks how much later packets are arriving compared to when they were supposed to. So, if packets are expected to arrive every 10 milliseconds but are arriving every 15 milliseconds, the pktRcvAvgBelatedTime measures that 5-millisecond delay. This helps in understanding the average lateness of packets, which can affect the smoothness of data streaming.

SRT Group Statistics Overview

SRT group statistics are available since SRT v1.5.0 and are used for the SRT Connection Bonding feature. Most statistics will be zero, except for specific fields listed below. 

Accumulated Statistics

msTimeStamp

Time in milliseconds since the initial group connection started.

Example: If msTimeStamp = 30000, the group has been connected for 30 seconds.

pktSentUniqueTotal

Total number of unique data packets sent by the group, excluding retransmissions.

If pktSentUniqueTotal = 2000, 2000 unique packets have been sent by the group.

pktRecvUniqueTotal

Total number of unique data packets received in time by the group.

Example: If pktRecvUniqueTotal = 1800, the group received 1800 unique packets first across multiple links.

pktRcvDropTotal

Total number of data packets that the socket group failed to deliver to the application because they were dropped on all connection links within the group.

Why the packets may be dropped : 

1. If packets are too late to be useful, they are dropped to maintain streaming quality (TLPKTDROP mechanism).
2. A packet is lost on every link in the group and thus “dropped”.
3. Sometimes packets are duplicates or contain errors, leading to their drop.

Example: If pktRcvDropTotal = 50, the group dropped 50 packets that were undeliverable across all links.

byteSentUniqueTotal

Total unique bytes sent, including headers.

Example: If byteSentUniqueTotal = 2,500,000 bytes, the group sent 2.5 million bytes of unique data.

byteRecvUniqueTotal

Total unique bytes received, including headers.

Example: If byteRecvUniqueTotal = 2,200,000 bytes, the group received 2.2 million bytes of unique data.

byteRcvDropTotal

Total bytes of data packets dropped by the group, including headers.

Example: If byteRcvDropTotal = 100,000 bytes, 100,000 bytes were dropped by the group.

Interval-Based Statistics

pktSentUnique

Unique data packets sent during a specified interval.

Example: If pktSentUnique = 500 in the last 10 seconds, 500 unique packets were sent.

pktRecvUnique

Unique data packets received during a specified interval.

Example: If pktRecvUnique = 450 in the last 10 seconds, 450 unique packets were received.

pktRcvDrop

Data packets dropped during a specified interval.

Example: If pktRcvDrop = 10 in the last 10 seconds, 10 packets were dropped.

byteSentUnique

Unique bytes sent during a specified interval.

Example: If byteSentUnique = 600,000 bytes in the last 10 seconds, 600,000 bytes were sent.

byteRecvUnique

Unique bytes received during a specified interval.

Example: If byteRecvUnique = 540,000 bytes in the last 10 seconds, 540,000 bytes were received.

byteRcvDrop

Bytes of data packets dropped during a specified interval.

Example: If byteRcvDrop = 20,000 bytes in the last 10 seconds, 20,000 bytes were dropped.

Dropped Packets Ratio

Formula: pktRcvDropTotal / pktSentUniqueTotal

Example: If pktRcvDropTotal = 50 and pktSentUniqueTotal = 2000, the Dropped Packets Ratio = 50 / 2000 = 0.025.

Dropped Packets Ratio (Receiver only)

Formula: pktRcvDropTotal / (pktRecvUniqueTotal + pktRcvDropTotal)

Example: If pktRcvDropTotal = 50 and pktRecvUniqueTotal = 1800, the Dropped Packets Ratio = 50 / (1800 + 50) = 0.027.

Understanding these parameters helps in monitoring and optimizing SRT streaming performance, allowing for effective identification and resolution of issues like packet loss and latency.