RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search