RFC Errata
Found 5 records.
Status: Verified (3)
RFC 3611, "RTP Control Protocol Extended Reports (RTCP XR)", November 2003
Source of RFC: avt (rai)
Errata ID: 1759
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timur Friedman
Date Reported: 2009-04-07
Verifier Name: Cullen Jennings
Date Verified: 2009-04-07
Section 6.3 says:
"recv-rtt"
It should say:
"rcvr-rtt"
Notes:
Sec. 6.3 describes the SDP attribute in Sec. 5.1, but erroneously calls it "recv-rtt" whereas it is in fact "rcvr-rtt". The IANA, following Sec. 6.3, had recorded "recv-rtt" but has corrected this and now records "rcvr-rtt".
Errata ID: 3795
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Stephen James
Date Reported: 2013-11-11
Verifier Name: Ben Campbell
Date Verified: 2015-07-22
Section 5.1 says:
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
It should say:
rtcp-xr-attrib = "a=" "rtcp-xr" [ ":" xr-format *(SP xr-format)] CRLF
Notes:
The ABNF for the attribute is causing some interoperability issues.
The text as written shows that the colon is required while the parameters are optional.
This leaves the format: "a=rtcp-xr:" the required format. Vendors are using "a=rtcp-xr" which strictly violates the ABNF above. Moving the ':' into the optional part seems correct.
Errata ID: 4597
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Liu Yuanlong
Date Reported: 2016-01-22
Verifier Name: Ben Campbell
Date Verified: 2016-05-25
Section 4.7.2 says:
burst density 84, which corresponds to 33%
It should say:
burst density 85, which corresponds to 33%
Notes:
error calculation for burst density, burst density=4/12*256=85.33...?85
Status: Held for Document Update (2)
RFC 3611, "RTP Control Protocol Extended Reports (RTCP XR)", November 2003
Source of RFC: avt (rai)
Errata ID: 2262
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kamil Sarac
Date Reported: 2010-05-14
Held for Document Update by: Robert Sparks
Section 4.6 says:
min_jitter: 32 bits
The minimum relative transit time between two packets in the
above sequence number interval. All jitter values are measured
as the difference between a packet's RTP timestamp and the
reporter's clock at the time of arrival, measured in the same
units.
max_jitter: 32 bits
The maximum relative transit time between two packets in the
above sequence number interval.
mean_jitter: 32 bits
The mean relative transit time between each two packet series
in the above sequence number interval, rounded to the nearest
value expressible as an RTP timestamp.
dev_jitter: 32 bits
The standard deviation of the relative transit time between
each two packet series in the above sequence number interval.
It should say:
min_jitter: 32 bits
The minimum jitter measured for a pair of packets in the above
sequence number interval. The packet jitter is defined in [9,
Section 6.4.1] and measured in timestamp units.
max_jitter: 32 bits
The maximum jitter measured for a pair of packets in the above
sequence number interval.
mean_jitter: 32 bits
The mean jitter measured for a pair of packets in the above
sequence number interval, rounded to the nearest
value expressible as a timestamp.
dev_jitter: 32 bits
The standard deviation of the jitter measured for a pair of packets
in the above sequence number interval.
Notes:
In the original RFC 3611 in Section 4.6 where it defines "min_jitter", the jitter definition is different from the one given in RFC3550. This errata report is to correct this difference by referring to RFC 3550 for the proper definition of jitter and revises the definitions of "min_jitter", "max_jitter", "mean_jitter", and "dev_jitter" fields.
Errata ID: 4386
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tong Zhou
Date Reported: 2015-06-03
Held for Document Update by: Ben Campbell
Date Held: 2015-08-03
Section 4.7.2 says:
For example, a 1 denotes a received packet, 0 a lost packet, and X a
discarded packet in the following pattern covering 64 packets:
11110111111111111111111X111X1011110111111111111111111X111111111
|---------gap----------|--burst---|------------gap------------|
The burst consists of the twelve packets indicated above, starting at
a discarded packet and ending at a lost packet. The first gap starts
at the beginning of the session and the second gap ends at the time
of the report.
If the packet spacing is 10 ms and the Gmin value is the recommended
value of 16, the burst duration is 120 ms, the burst density 0.33,
the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.
It should say:
For example, a 1 denotes a received packet, 0 a lost packet, and X a
discarded packet in the following pattern covering 64 packets:
11110111111111111111111X111X1011110111111111111111111X1111111111
|---------gap----------|--burst---|------------gap------------|
The burst consists of the twelve packets indicated above, starting at
a discarded packet and ending at a lost packet. The first gap starts
at the beginning of the session and the second gap ends at the time
of the report.
If the packet spacing is 10 ms and the Gmin value is the recommended
value of 16, the burst duration is 120 ms, the burst density 0.33,
the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.
Notes:
The pattern in the example shows 63 packets rather than 64. Added a "1" at the end. Another option is to keep the pattern unchanged, and redo the math.