errata logo graphic

Found 4 records.

Status: Verified (2)

RFC4585, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", July 2006

Source of RFC: avt (rai)

Errata ID: 2853

Status: Verified
Type: Technical

Reported By: Ali Begen
Date Reported: 2011-07-05
Verifier Name: Robert Sparks
Date Verified: 2011-08-05

Section 4.2 says:

OLD:
      rtcp-fb-param      = SP "app" [SP byte-string]
                         / SP token [SP byte-string]
                         / ; empty
NEW:
      rtcp-fb-param      = [ SP "app" [SP byte-string]
                         / SP token [SP byte-string] ]


OLD:
      rtcp-fb-ack-param  = SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]
                         / ; empty
NEW:
      rtcp-fb-ack-param  = [ SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string] ]


OLD:
      rtcp-fb-nack-param = SP "pli"
                         / SP "sli"
                         / SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]
                         / ; empty
NEW:
      rtcp-fb-nack-param = [ SP "pli"
                         / SP "sli"
                         / SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string] ]

Notes:

During the AUTH48 of RFC 6285, we discovered a bug with the ABNF syntax in RFC 4585. The original ABNF in Section 4.2 (as noted above) is incorrect ("/ ;empty" is not a valid ABNF - RFC 5234 does not allow empty alternates).

The NEW text intends to fix it. There are 3 places where the same change should be applied (changes are identical).


Errata ID: 3313

Status: Verified
Type: Technical

Reported By: Mo Zanaty
Date Reported: 2012-08-11
Verifier Name: Robert Sparks
Date Verified: 2012-11-26

Section 4.2 says:

      rtcp-fb-ack-param  = SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]
                         / ; empty

It should say:

      rtcp-fb-ack-param  = SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]

Notes:

RFC 4585 defines and allows generic NACK (with no further parameters) but not generic ACK (which always requires further parameters). Section 4.2 says:
...
Parameters MUST be provided to further distinguish different types
of positive acknowledgement feedback.
...
The feedback type "nack", without parameters, indicates use of the
Generic NACK feedback format as defined in Section 6.2.1.
...
The ABNF incorrectly allows nothing after "ack", implying that generic ACK is valid. Even the approved errata, which replaces the invalid empty alternate with optional [], still allows nothing after "ack". Note that recent interest in RTP congestion control (e.g. RMCAT BOF) may lead to defining a standard ACK.


Status: Rejected (2)

RFC4585, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", July 2006

Source of RFC: avt (rai)

Errata ID: 51

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Rejected by: Joerg Ott
Date Rejected: 2006-08-17

Errors (11)-(19) of 19

(11)  [formatting issue]

In Section 6, the text around the page break from page 31 to page 32
is not formatted properly.
The RFC says:

      [...]
      audio and DTMF) or when codec changes occur, the payload type
      information may need to be conveyed explicitly as part of the FB
      message.  This applies to all
 << page break >>
      payload-specific as well as application layer FB messages.  It is
      up to the specification of an FB message to define how payload
      type information is transmitted.

It should say:

      [...]
      audio and DTMF) or when codec changes occur, the payload type
      information may need to be conveyed explicitly as part of the FB
      message.  This applies to all payload-specific as well as
 << page break >>
      application layer FB messages.  It is up to the specification of
      an FB message to define how payload type information is
      transmitted.


(12)  [inconsistent text]

Still in Section 6, the second paragraph on page 32 (immediately
following the text quotation in item (11) above) says:

                         vvv
|  This document defines two transport layer and three (video) payload-
   specific FB messages as well as a single container for application
   layer FB messages.  Additional transport layer and payload-specific
   FB messages MAY be defined in other documents and MUST be registered
   through IANA (see Section 9, "IANA Considerations").

It should say:
                         vvv
|  This document defines one transport layer and three (video) payload-
   specific FB messages as well as a single container for application
   layer FB messages.  Additional transport layer and payload-specific
   FB messages MAY be defined in other documents and MUST be registered
   through IANA (see Section 9, "IANA Considerations").

Rationale:
Cf. the third paragraph of Section 6, on page 31, and
the subsequent pages, in particular page 34, where the
second paragraph of Section 6.2 says:

|  A single general purpose transport layer FB message is defined in
   this document: Generic NACK.  It is identified by means of the FMT
   parameter as follows:

   [...]

(And so it does, per Section 6.2.1.)


(13)  [incomplete specification?]

Within Section 6.1, the last paragraph on page 33 says:

   Each RTCP feedback packet MUST contain at least one FB message in the
   FCI field.  Sections 6.2 and 6.3 define for each FCI type, whether or
   not multiple FB messages MAY be compressed into a single FCI field.
|  If this is the case, they MUST be of the same type, i.e., same FMT.
|  If multiple types of feedback messages, i.e., several FMTs, need to
   be conveyed, then several RTCP FB messages MUST be generated and
   SHOULD be concatenated in the same compound RTCP packet.

I strongly suspect -- and this is supported by the examples in the
RFC -- that feedback packets to be combined MUST also have the same
payload type (PT), not only agree in their FMT values.
Otherwise, there would be no way to carry the different PT values
in the FB message according to the format specified in Figure 3.

Therefore, the RFC should say:

   Each RTCP feedback packet MUST contain at least one FB message in the
   FCI field.  Sections 6.2 and 6.3 define for each FCI type, whether or
   not multiple FB messages MAY be compressed into a single FCI field.
|  If this is the case, they MUST be of the same type, i.e., same PT and
|  the same FMT.  If multiple types of feedback messages, i.e., several
|  PTs and/or several FMTs, need to be conveyed, then several RTCP FB
   messages MUST be generated and SHOULD be concatenated in the same
   compound RTCP packet.

(Authors, please supply alternative wording, if you desire.)

Note:
Perhaps, this issue arised because of the slightly differing
semantics implied for the various usages of the term "FB message"
in Section 6.1 -- (a) the whole RTCP FB message, and (b) a semantic
entity carried in the FCI field of that RTCP message.
Future updates to the RFC might try further clarifications of the
text to avoid this subtle sematic overloading.


(14)  [missing article]

The last paragraph of Section 6.3, at the bottom of page 35, says:

   The following subsections define the FCI formats for the payload-
|  specific FB messages, Section 6.4 defines FCI format for the
   application layer FB message.

It should say:

   The following subsections define the FCI formats for the payload-
|  specific FB messages, Section 6.4 defines the FCI format for the
   application layer FB message.


(15)  [extraneous words]

The second paragraph of Section 6.3.1.1, on page 36, says:

   Other RTP payload specifications such as RFC 2032 [6] already define
|  a feedback mechanism for some for certain codecs.  An application
   supporting both schemes MUST use the feedback mechanism defined in
   this specification when sending feedback.  For backward compatibility
   reasons, such an application SHOULD also be capable to receive and
   react to the feedback scheme defined in the respective RTP payload
   format, if this is required by that payload format.

It should say:

   Other RTP payload specifications such as RFC 2032 [6] already define
|  a feedback mechanism for certain codecs.  An application supporting
   both schemes MUST use the feedback mechanism defined in this
   specification when sending feedback.  For backward compatibility
   reasons, such an application SHOULD also be capable to receive and
   react to the feedback scheme defined in the respective RTP payload
   format, if this is required by that payload format.


(16)  [misleading wording]

The first paragraph of Section 6.3.2.2, on page 37, says:

                                                     vvvvv
|  The Slice Loss Indication uses one additional FCI field, the content
   of which is depicted in Figure 6.  The length of the FB message MUST
   be set to 2+n, with n being the number of SLIs contained in the FCI
   field.

To avoid the semantic overloading of the word "field", it should
perhaps better say:
                                                     vvvv
|  The Slice Loss Indication uses one additional FCI word, the content
   of which is depicted in Figure 6.  The length of the FB message MUST
   be set to 2+n, with n being the number of SLIs contained in the FCI
   field.


(17)  [typo]

The first paragraph of Section 6.3.3.1, on page 39, says:

                             v
                                   [...].  As this reference picture is
|  temporally further away then usual, the resulting predictively coded
   picture will use more bits.

It should say:
                             v
                                   [...].  As this reference picture is
|  temporally further away than usual, the resulting predictively coded
   picture will use more bits.


(18)  [inappropriate wording]

The first paragraph of Section 8, on page 42, says:

   RTP packets transporting information with the proposed payload format
   are subject to the security considerations discussed in the RTP
   specification [1] and in the RTP/AVP profile specification [2].  This
   profile does not specify any additional security services.

The wording of the first sentence is inappropriate for this RFC.
(It perhaps has been copied unchanged from an RFC with an RTP Payload
specification.)

RFC 4585 should say instead:

|  RTP packets transporting information as defined in various payload
|  formats supporting this profile are subject to the security
   considerations discussed in the RTP specification [1] and in the
   RTP/AVP profile specification [2].  This profile does not specify any
   additional security services.


(19)  [redundant Ref.]

The Normative Reference [7] (in Section 11.1, on page 48) and
the Informative Reference [20] (in Section 11.2, on page 49)
both point to RFC 3448.
([7] and [20] are referred to once each in the RFC text.)

This is unusual and unexpected.  Only one pointer to RFC 3448
should have been specified.  Authors, please check.

Notes:

from pending

--VERIFIER COMMENT--
Thanks for the review. I have only quickly skimmed your comments
and there does not seem to be anything serious.

We will be happy to archive these and migt consider them if
we do a revision of the RFC. But an errata document would
only make sense if there is something seriously hindering
interoperability. I have not seen anything falling into this
category (well, and there are implementations out there from
the spec).


Errata ID: 768

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Rejected by: Joerg Ott
Date Rejected: 2006-08-17

Errors (1)-(10) of 19

(1)

Section 1.1 of RFC 4585, on mid-page 4, says:

   Feedback (FB) message:
      An RTCP message as defined in this document is used to convey
      information about events observed at a receiver -- in addition to
      long-term receiver status information that is carried in RTCP
      receiver reports (RRs) -- back to the sender of the media stream.
|     For the sake of clarity, feedback message is referred to as FB
|     message throughout this document.

I do not see how and why using the abbreviation might have improved
*clarity* of the text; apparently, it has been used for *brevity* .
Therefore, the two tagged lines should better say:

|     For the sake of brevity, feedback message is referred to as FB
|     message throughout this document.

Similarly, at the bottom of page 4, where the RFC says:

   Feedback (FB) threshold:
      The FB threshold indicates the transition between Immediate
      Feedback and Early RTCP mode.  [...]
      [...]
      to application designers and is not used in any calculations.  For
|     the sake of clarity, the term feedback threshold is referred to as
      FB threshold throughout this document.

The last 3 lines should better say:

      to application designers and is not used in any calculations.  For
|     the sake of brevity, the term feedback threshold is referred to as
      FB threshold throughout this document.


(2)

The first bulleted item in Section 3.1, on page 7, says:
                                                    vvvvvvvvvvvvv
|  o  Status reports are contained in sender report (SR)/received report
      (RR) packets and are transmitted at regular intervals as part of
      compound RTCP packets (which also include source description
      (SDES) and possibly other messages); these status reports provide
      an overall indication for the recent reception quality of a media
      stream.

For *clarity*, it perhaps should better say -- not binding together the
words intended to being separated by the slash marking the alternative:
                                                        vvv
|  o  Status reports are contained in sender report (SR) / received
      report (RR) packets and are transmitted at regular intervals as
      part of compound RTCP packets (which also include source
      description (SDES) and possibly other messages); these status
      reports provide an overall indication for the recent reception
      quality of a media stream.


(3)  [missing article]

In Section 3.4, on mid-page 11, RFC 4585 says:

   j) Let T_fd be the actual (randomized) delay for the transmission of
      FB message in response to an event at time t0.

It should say:

   j) Let T_fd be the actual (randomized) delay for the transmission of
|     a FB message in response to an event at time t0.
      ^^

(4)  [inappropriate wording]

The algorithm in Section 3.5.2, at the bottom of page 16, contains
the sub-step:

      4b) If allow_early == TRUE, then R MUST schedule an Early RTCP
          packet for te = t0 + RND * T_dither_max with RND being a
|         pseudo random function evenly distributed between 0 and 1.
                        ^^^^^^^^

This wording is inappropriate.  RND is not a *function* (that's code!),
but a *number*, the function *value*.  Therefore, the RFC should say:

      4b) If allow_early == TRUE, then R MUST schedule an Early RTCP
          packet for te = t0 + RND * T_dither_max with RND being a
|         pseudo random number evenly distributed between 0 and 1.
                        ^^^^^^


(5)  [inappropriate wording]

The algorithm in Section 3.5.3, at the top of page 19, says:

   2. Otherwise, a temporary value T_rr_current_interval is calculated
      as follows:

         T_rr_current_interval = RND*T_rr_interval

|     with RND being a pseudo random function evenly distributed between
      0.5 and 1.5.  This dithered value is used to determine one of the
      following alternatives:

Similar to item (4) above, the RFC should say instead:

   2. Otherwise, a temporary value T_rr_current_interval is calculated
      as follows:

         T_rr_current_interval = RND*T_rr_interval

|     with RND being a pseudo random number evenly distributed between
      0.5 and 1.5.  This dithered value is used to determine one of the
      following alternatives:


(6)  [typo / dup. wording]

Section 3.6.2 of RFC 4585, on mid-page 21, says:

   Example: If a 256-kbit/s video with 30 fps is transmitted through a
   network with an MTU size of some 1,500 bytes, then, in most cases,
|  each frame would fit in into one packet leading to a packet rate of
   30 packets per second.  [...]

It should say:

   Example: If a 256-kbit/s video with 30 fps is transmitted through a
   network with an MTU size of some 1,500 bytes, then, in most cases,
|  each frame would fit into one packet leading to a packet rate of
   30 packets per second.  [...]


(7)  [wrong ref. tag]

On mid-page 23, Section 4.1 of RFC 4585 says:

                             vvv
|  The AV profile defined in [4] is referred to as "AVP" in the context
   of, e.g., the Session Description Protocol (SDP) [3].  The profile
   specified in this document is referred to as "AVPF".

There apparently is a confusion of the ref. tags used.
The RFC should say:
                             vvv
|  The AV profile defined in [2] is referred to as "AVP" in the context
   of, e.g., the Session Description Protocol (SDP) [3].  The profile
   specified in this document is referred to as "AVPF".


(8)  [missing article]

In Section 4.2, near the top of page 25, the ABNF production:

      rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
|                        / fmt   ; as defined in SDP spec

should better say, improving the ABNF comment text:

      rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
|                        / fmt   ; as defined in the SDP spec
                                                ^^^^^


(9)  [inconsistent specification]

In Section 4.2, the ABNF on page 25 contains the following productions:

      rtcp-fb-val        = "ack" rtcp-fb-ack-param
                         / [...]
and
      rtcp-fb-ack-param  = SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]
|                        / ; empty

This means that the feedback type "ack" *MAY* have parameters.

Contrary to that, below the ABNF, the RFC explains:

   Feedback type "ack":

      This feedback type indicates that positive acknowledgements for
      feedback are supported.

      The feedback type "ack" MUST only be used if the media session is
      allowed to operate in ACK mode as defined in Section 3.6.1.

|     Parameters MUST be provided to further distinguish different types
|     of positive acknowledgement feedback.

      [...]

The *MUST* in the tagged lines contradicts the ABNF.

Authors, please resolve the issue:

Either have the ABNF changed by omission of the tagged line above,

|                        / ; empty

or change the tagged explanation lines to say:

|     Parameters MAY be provided to further distinguish different types
|     of positive acknowledgement feedback.


(10)  [incomplete specification, and an extraneous word]

At the bottom of page 26, Section 4.2 of RFC 4585 says:

   Other feedback types <rtcp-fb-id>:

      Other documents MAY define additional types of feedback; to keep
      the grammar extensible for those cases, the rtcp-fb-id is
|     introduced as a placeholder.  A new feedback scheme name MUST to
      be unique (and thus MUST be registered with IANA).  Along with a
|     new name, its semantics, packet formats (if necessary), and rules
      for its operation MUST be specified.

It should say:

   Other feedback types <rtcp-fb-id>:

      Other documents MAY define additional types of feedback; to keep
      the grammar extensible for those cases, the rtcp-fb-id is
|     introduced as a placeholder.  A new feedback scheme name MUST be
      unique (and thus MUST be registered with IANA).  Along with a new
|     new name, its semantics, possible parameters, packet formats (if
      necessary), and rules for its operation MUST be specified.

Rationale:

a) "MUST to be unique" should be "MUST be unique".

b) Syntax and semantics of parameters (if any) obviously MUST be
   specified as well.  The RFC text in the IANA Considerations
   (Section 9) already reflects this requirement.
   For completeness and clarity, it should be stated here as well.
   I have proposed minimal additional wording -- you might choose
   alternative words.

Notes:

from pending

--VERIFIER COMMENT--
Thanks for the review. I have only quickly skimmed your comments
and there does not seem to be anything serious.

We will be happy to archive these and migt consider them if
we do a revision of the RFC. But an errata document would
only make sense if there is something seriously hindering
interoperability. I have not seen anything falling into this
category (well, and there are implementations out there from
the spec).


Report New Errata