RFC Errata
Found 4 records.
Status: Held for Document Update (2)
RFC 3550, "RTP: A Transport Protocol for Real-Time Applications", July 2003
Note: This RFC has been updated by RFC 5506, RFC 5761, RFC 6051, RFC 6222, RFC 7022, RFC 7160, RFC 7164, RFC 8083, RFC 8108, RFC 8860
Source of RFC: avt (rai)
Errata ID: 3263
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Pieter Demuytere
Date Reported: 2012-06-18
Held for Document Update by: Robert Sparks
Section 6.4.1 says:
cumulative number of packets lost: 24 bits The total number of RTP data packets from source SSRC_n that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. Thus, packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. This may be calculated as shown in Appendix A.3.
It should say:
cumulative number of packets lost: 24 bits The total number of RTP data packets from source SSRC_n that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. Thus, packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The number of packets expected is defined to be the extended highest sequence number received, as defined next, less the initial sequence number received. This may be calculated as shown in Appendix A.3.
Notes:
Changed
The number of packets expected is defined to be the extended last sequence number received...
Into
The number of packets expected is defined to be the extended highest sequence number received...
Errata ID: 4770
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Petr Vaněk
Date Reported: 2016-08-08
Held for Document Update by: Ben Campbell
Date Held: 2016-08-08
Section 3. says:
RTP session: An association among a set of participants
communicating with RTP. A participant may be involved in multiple
RTP sessions at the same time. In a multimedia session, each
medium is typically carried in a separate RTP session with its own
RTCP packets unless the the encoding itself multiplexes multiple
media into a single data stream. A participant distinguishes
multiple RTP sessions by reception of different sessions using
different pairs of destination transport addresses, where a pair
of transport addresses comprises one network address plus a pair
of ports for RTP and RTCP. All participants in an RTP session may
share a common destination transport address pair, as in the case
of IP multicast, or the pairs may be different for each
participant, as in the case of individual unicast network
addresses and port pairs. In the unicast case, a participant may
receive from all other participants in the session using the same
pair of ports, or may use a distinct pair of ports for each.
It should say:
RTP session: An association among a set of participants
communicating with RTP. A participant may be involved in multiple
RTP sessions at the same time. In a multimedia session, each
medium is typically carried in a separate RTP session with its own
RTCP packets unless the encoding itself multiplexes multiple
media into a single data stream. A participant distinguishes
multiple RTP sessions by reception of different sessions using
different pairs of destination transport addresses, where a pair
of transport addresses comprises one network address plus a pair
of ports for RTP and RTCP. All participants in an RTP session may
share a common destination transport address pair, as in the case
of IP multicast, or the pairs may be different for each
participant, as in the case of individual unicast network
addresses and port pairs. In the unicast case, a participant may
receive from all other participants in the session using the same
pair of ports, or may use a distinct pair of ports for each.
Notes:
typo: double the in 5th line.
Status: Rejected (2)
RFC 3550, "RTP: A Transport Protocol for Real-Time Applications", July 2003
Note: This RFC has been updated by RFC 5506, RFC 5761, RFC 6051, RFC 6222, RFC 7022, RFC 7160, RFC 7164, RFC 8083, RFC 8108, RFC 8860
Source of RFC: avt (rai)
Errata ID: 3914
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Hani Mustafa
Date Reported: 2014-03-06
Rejected by: Richard Barnes
Date Rejected: 2014-03-06
Section A.1 says:
init_seq(s, seq);
s->max_seq = seq - 1;
s->probation = MIN_SEQUENTIAL;
It should say:
init_seq(s, seq);
s->max_seq = seq == 0 ? seq : seq - 1;
s->probation = MIN_SEQUENTIAL;
Notes:
If the first RTP packet has a sequence number of 0, the logic will cause cycles to increase by 1, which will affect "expected number of received packets" calculations.
--VERIFIER NOTES--
Submitter requested rejection.
Errata ID: 4192
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Julius Friedman
Date Reported: 2014-12-03
Rejected by: Ben Campbell
Date Rejected: 2015-07-22
Section 6.4.1 says:
sender's octet count: 32 bits
The total number of payload octets (i.e., not including header or
padding) transmitted in RTP data packets by the sender since
starting transmission up until the time this SR packet was
generated. The count SHOULD be reset if the sender changes its
SSRC identifier. This field can be used to estimate the average
payload data rate.
It should say:
sender's octet count: 32 bits
The total number of payload octets
transmitted in RTP data packets by the sender since
starting transmission up until the time this SR packet was
generated. The count SHOULD be reset if the sender changes its
SSRC identifier. This field can be used to estimate the average
payload data rate.
Notes:
Where as payload octets is defined as the total number of data octets contained in a Rtp Packet minus the 12 Header octets for Rtp Packets.
Padding octets as well as octets which occur in the contributing source list should also be included as they may differ on a per packet basis and would make the total calculation invalid.
During TCP communication any application layer header should NOT be included in the total bytes count when including the header length.
Any Rtcp packet counters should include the total length of the packet (header, padding and any other data).
--VERIFIER NOTES--
Rejected based on discussion in avtcore