RFC Errata
Found 3 records.
Status: Verified (2)
RFC 8888, "RTP Control Protocol (RTCP) Feedback for Congestion Control", January 2021
Source of RFC: avtcore (wit)
Errata ID: 7894
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Harald Tveit Alvestrand
Date Reported: 2024-04-16
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2024-05-21
Section 3.1 says:
RTCP Congestion Control Feedback Packets SHOULD include a report block for every active SSRC.
It should say:
RTCP Congestion Control Feedback Packets SHOULD include a report block for every SSRC where packets have been received since the previous report was generated.
Notes:
The term "active" is ambiguous. Discussion on the avtcore mailing list indicates that this is the intended meaning.
Errata ID: 8166
Status: Verified
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Harald Alvestrand
Date Reported: 2024-11-04
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2024-12-25
Section 3.1 says:
Following this, the report block contains a
16-bit packet metric block for each RTP packet that has a sequence
number in the range begin_seq to begin_seq+num_reports inclusive
(calculated using arithmetic modulo 65536 to account for possible
sequence number wrap-around).
It should say:
Following this, the report block contains a
16-bit packet metric block for each RTP packet that has a sequence
number in the range begin_seq up to, but not including,
begin_seq+num_reports
(calculated using arithmetic modulo 65536 to account for possible
sequence number wrap-around).
Notes:
The text can be read as the range being [begin_seq, begin_seq+num_reports].
If "begin_seq" is taken as the first sequence number you are reporting on, the original text means that you would have to have num_reports be 0 when you are reporting on a single packet. This seems very strange.
Alternatively, if "begin_seq" is taken as the sequence number before the one you are reporting on, the num_reports is consistent, but you are then reporting on the range <begin_seq, begin_seq+num_reports], which also seems strange.
The suggested clarification would report on the sequence [begin_seq, begin_seq + num_reports>, which seems like the most natural interpretation.
This is also consistent with the format of an empty report, which is explicit that begin_seq is the sequence number of the last RTP packet received.
Status: Reported (1)
RFC 8888, "RTP Control Protocol (RTCP) Feedback for Congestion Control", January 2021
Source of RFC: avtcore (wit)
Errata ID: 8535
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Harald Alvestrand
Date Reported: 2025-08-21
Section 6 says:
When the SDP BUNDLE extension [RFC8843] is used for multiplexing, the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT [RFC8859].
It should say:
When the SDP BUNDLE extension [RFC8843] is used for multiplexing, the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT [RFC8859]. When using BUNDLE, all media sections in the bundle MUST have the same value for "a=rtcp-fb:*:ack ccfb" - it must either be present in all sections or in none of the sections.
Notes:
Since 8888 is transport-wide, bundled audio and video must be consistent in CCFB. But IDENTICAL-PER-PT does not enforce this, since audio and video do not share payload types.