WebRTC: Retransmission via RFC4588 RTX

[winlinvip]

I have roughly reviewed the relevant materials again, and there are actually three methods for Retransmission (packet retransmission):

WebRTC Legacy

WebRTC Legacy, reusing the same SSRC and PT. This method is a non-RFC 4588 defined RTX approach, which is currently supported by SRS. It is one of the earliest implemented methods and is relatively simple. Some MCU devices only support a single SSRC, which is why Chrome has continued to support this method. The current documentation clearly states that if RTX is not negotiated, it refers to this method of retransmission. Since there is no special definition in the RTP protocol part, relying only on the RTCP protocol to send NACK requests to retransmit lost packets, there is no separate RFC defining this method. In other words, the relevant RFCs are the standard RTP and RTCP packets.

a=rtpmap:109 H264/90000
a=rtcp-fb:109 nack
a=ssrc:579114133 cname:tS9Pk5AXuIefv5le

The definition according to the relevant documentation:

https://developer.mozilla.org/en-US/docs/Web/API/RTCOutboundRtpStreamStats/retransmittedBytesSent

If RTX has not been negotiated the retransmitted bytes will be sent over the same SSRC; otherwise the bytes are sent on a separate SSRC but are still accounted for in this property.

https://www.w3.org/TR/webrtc-stats/

If RTX is not negotiated, retransmitted bytes are sent over this ssrc. If RTX was negotiated, retransmitted bytes are sent over a separate SSRC but is still accounted for here.

The definition of the relevant code: In the libwebrtc code of Chrome, if an RTX SSRC is not configured, the receiver does not create a dedicated RtxReceiveStream to handle it. Instead, retransmit detection is enabled for the main stream.

        if (rtx_ssrc()) {
            rtx_receive_stream_ = std::make_unique<RtxReceiveStream>(
                &rtp_video_stream_receiver_, config_.rtp.rtx_associated_payload_types,
                remote_ssrc(), rtp_receive_statistics_.get());
        } else {
            rtp_receive_statistics_->EnableRetransmitDetection(remote_ssrc(), true);
        }

In fact, this method has been criticized in RFC 4588, which states that it causes confusion in the receiver's statistics.
One approach may be to retransmit the RTP packet with its original sequence number and send original and retransmission packets in the same RTP stream. The retransmission packet would then be identical to the original RTP packet, i.e., the same header (and thus same sequence number) and the same payload. However, such an approach is not acceptable because it would corrupt the RTCP statistics.

For instance, if a packet arrives slightly delayed and the receiver assumes it is lost, the sender will resend the lost packet. Consequently, the receiver might receive duplicate packets. Although the receiver can discard these duplicates, the packet loss count defined in RTP 3550 could become negative, which may lead to certain issues:

https://datatracker.ietf.org/doc/html/rfc3550

cumulative number of packets lost: 24 bits Thus, packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates.

WebRTC RTX

WebRTC supports RTX retransmission with multiplexing SSRC, which involves transmitting RTP video packets using two SSRCs and Payload Types (PT), as defined by RFC 4588's ssrc-multiplexing. Specifically, WebRTC mandates in RFC 8834 that receivers must implement this feature, while it is optional for senders. Typically, two SSRCs and PTs are negotiated in the SDP, for example, one might be PT 109 (SSRC 579114133) and the other PT 114 (SSRC 2751628478). These two are bound together through an ssrc-group, indicating they are part of the same RTP stream, which in this case is a video stream.

a=rtpmap:109 H264/90000
a=rtcp-fb:109 nack
a=ssrc:579114133 cname:tS9Pk5AXuIefv5le

a=rtpmap:114 rtx/90000
a=fmtp:114 apt=109
a=ssrc:2751628478 cname:tS9Pk5AXuIefv5le

a=ssrc-group:FID 579114133 2751628478

The implementation details for this aspect of WebRTC are defined in the document located at:
https://datatracker.ietf.org/doc/html/rfc8834#name-negative-acknowledgements-a

Compared to the legacy method of WebRTC, this approach sends dropped packets using a separate SSRC, with independent sequence numbers, payload types, and SSRC values. When tallying packets, this prevents the original SSRC's packet count from being duplicated, allowing for a more accurate calculation of packet loss. It also facilitates the convenient determination of the number of lost, late, and retransmitted packets.

Session Multiplexing

WebRTC does not support this method. RTX reuses the session, also known as the session-multiplexing defined in RFC 4588, using the same SSRC but different payload types (PT), and retransmits packets using a separate session and a distinct network 5-tuple. In RFC 8834, this is defined as an optional ("May") implementation, and in practice, it is seldom implemented.

Annex

The three methods mentioned utilize RTCP NACK. NACK is simply a notification from the receiving end indicating that it has not received a certain packet, which could either be due to the packet being lost or delayed in arrival.

TRANS_BY_GPT4

[winlinvip]

The status of the SRS (Software Requirements Specification).

According to the definition in RFC 8834: https://datatracker.ietf.org/doc/html/rfc8834#name-negative-acknowledgements-a

1. For the WHIP protocol, the SRS is the receiving end:

   • Implemented: Must support the WebRTC Legacy approach, as some MCUs only support this method.
   • Not implemented: It is good to also support the WebRTC RTX approach, which is the SSRC-multiplexing method defined in RFC 4588.
   • It is not necessary to support the session-multiplexing approach defined in RFC 4588, as this method is generally not supported.

2. For the WHEP protocol, the SSRC is the sender:

   • Implemented: Must support the WebRTC Legacy approach, as some MCUs only support this method.
   • Not implemented: Must support the WebRTC RTX approach, which is the SSRC-multiplexing method defined in RFC 4588.
   • It is not necessary to support the session-multiplexing approach defined in RFC 4588, as this method is generally not supported.

TRANS_BY_GPT4

[winlinvip]

If RTX is not supported, WebRTC will retransmit the original packet with new TWCC number.

Open the capture file nack-drop-seq8331-pt109.pcapng.zip by wireshark, check the packet:

• No. 40, Sequence=8331, TWCC-Number=0x7f, This is the original packet, arrived in delay.
• No. 42, Sequence=8331, TWCC-Number=0x83, This is the retransmission packet, with the same sequence number and new TWCC number.

Note: If the original packet is really lost in the network, SRS will only get the retransmission packet, then won't cause any problem.

Now, due to delay, both the original and retransmission packet are arrived, then the retransmission packet fail the SRTP decrypt:

[2025-06-25 21:27:41.367] #39 rtp seq=8331, pt=109, ssrc=1996593034: SRS got the delayed original packet, decrypt by SRTP ok.
[2025-06-25 21:27:41.367] #40 rtp seq=8332, pt=109, ssrc=1996593034
[2025-06-25 21:27:41.393] #41 rtp seq=8331, pt=109, ssrc=1996593034: SRS got the retransmission packet, failed to decrypt.

[2025-06-25 21:27:41.394][WARN][59390][5x166342][35] handle udp pkt, count=1/1, err: code=5015(RtcSrtpUnprotect)(Failed to decrypt data by SRTP for RTC) : size=997, data=[90 6d 20 8b cb 8c 81 fc] : rtp unprotect : rtp unprotect r0=9
thread [59390][5x166342]: cycle() [./src/app/srs_app_listener.cpp:741][errno=35]
thread [59390][855h148k]: on_rtp() [./src/app/srs_app_rtc_network.cpp:280][errno=35]
thread [59390][855h148k]: unprotect_rtp() [./src/app/srs_app_rtc_dtls.cpp:1053][errno=35]

Note that even enable the allow_repeat_tx, it also fail with 9 (srtp_err_status_replay_fail), because it only apply to encrypt/protect, not apply to decrypt/unprotect:

    bool allow_repeat_tx;       /**< Whether retransmissions of          */
                                /**< packets with the same sequence      */
                                /**< number are allowed.                 */
                                /**< (Note that such repeated            */
                                /**< transmissions must have the same    */
                                /**< RTP payload, or a severe security   */
                                /**< weakness is introduced!)            */

srtp_err_status_t srtp_protect(srtp_t ctx, ...) {
            if (status != srtp_err_status_replay_fail ||
                !stream->allow_repeat_tx)
                return status; /* we've been asked to reuse an index */
}

srtp_err_status_t srtp_unprotect(srtp_t ctx, ...) {
            status = srtp_rdbx_check(&stream->rtp_rdbx, delta);
            if (status) {
                return status; // <-- NO allow_repeat_tx check here!
}

• For sender using protect/encrypt, if RTX is not supported, it need to retransmit the original packet with the same sequence number. This is why protect/encrypt need to support allow_repeat_tx and succeed to encrypt the same sequence number multiple times.
• For receiver using unprotect/decrypt, it normally won't receive both the original and retransmission packet, so it won't support that flag. Or you can check and drop the retransmission packet if the original packet arrived in a delay.