RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Rejected (2)

RFC 4588, "RTP Retransmission Payload Format", July 2006

Source of RFC: avt (rai)

Errata ID: 48
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-08-14
Rejected by: Jose Rey

Section 8.1 says:

   The following MIME subtype name and parameters are introduced in this
   document: "rtx", "rtx-time", and "apt".

   The binding used for the retransmission stream to the payload type
   number is indicated by an rtpmap attribute.  The MIME subtype name
   used in the binding is "rtx".

   The "apt" (associated payload type) parameter MUST be used to map the
   retransmission payload type to the associated original stream payload
   type.  If multiple original payload types are used, then multiple
   "apt" parameters MUST be included to map each original payload type
   to a different retransmission payload type.

It should say:

   The following MIME subtype name and parameters are introduced in this
   document: "rtx", "rtx-time", and "apt".

   The binding used for the retransmission stream to the payload type
   number is indicated by an rtpmap attribute.  The MIME subtype name
   used in the binding is "rtx".  The MIME type of the retransmission
   stream MUST be the same as the MIME type of the original stream.

   The "apt" (associated payload type) parameter MUST be used to map the
   retransmission payload type to the associated original stream payload
   type.  If multiple original payload types are used, then multiple
   "apt" parameters MUST be included to map each original payload type
   to a different retransmission payload type.

Notes:

This text only addresses the use of the media *sub*-type. Apparently,
it is implied that the media *type* of the associated streams match,
but I could not find a statement to this end in the RFC.

(In accordance with the language of RFC 4588, but contrary to BCP 13,
RFC 4288, I have again used the traditional wording "MIME type" here
instead of the currently recommended "media type".)

from pending

--VERIFIER COMMENT--

Thanks for your comments. However, I don't consider them worth of correction. Most are just editorial nits, some of which are even wrong. So, for the time being as Joerg said:

"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: 759
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-08-14
Rejected by: Jose Rey
Date Rejected: 2006-08-29

 

(1)  [missing article]

Within Section 4 of RFC 4588, the second paragraph on page 8 says:

            [...].  See Section 8.1 for the specification of how the
   mapping between original and retransmission payload types is done
|  with Session Description Protocol (SDP).

It should say:

            [...].  See Section 8.1 for the specification of how the
   mapping between original and retransmission payload types is done
|  with the Session Description Protocol (SDP).
       ^^^^^


(2)  [improper wording]

The 4th paragraph of Section 6.3, on page 12, says:

            [...].  In such cases, an appropriate "reorder delay"
   algorithm may not actually be timer based, but packet based.  For
|  example, if n number of packets are received after a gap is detected,
   then it may be assumed that the packet was truly lost rather than out
   of order.  This may turn out to be far easier to code on some
   platforms as a very short fixed FIFO packet buffer as opposed to the
   timer-based mechanism.

It should say:

            [...].  In such cases, an appropriate "reorder delay"
   algorithm may not actually be timer based, but packet based.  For
|  example, if n packets are received after a gap is detected, then it
   may be assumed that the packet was truly lost rather than out of
   order.  This may turn out to be far easier to code on some platforms
   as a very short fixed FIFO packet buffer as opposed to the timer-
   based mechanism.

(Alternatively, use  "if a number n of packets ..."  instead of the
 offending "if n number of packets ..." )


(3)  [word omission]

In the first paragraph of Section 6.4, on page 13, RFC 4588 says:

   [...]                                      v
|  Sending NACKs only in regular RTCP compound decreases the maximum
   delay between detecting an original packet loss and being able to
   send a NACK for that packet.  Implementers should consider the
   possible implications of this fact for the application being used.

It should say:

   [...]                                      vvvvvvvvv
|  Sending NACKs only in regular RTCP compound packets decreases the
   maximum delay between detecting an original packet loss and being
   able to send a NACK for that packet.  Implementers should consider
   the possible implications of this fact for the application being
   used.


(4)  [[posted separately.]]


(5)  [word omission]

Later on in Section 8.1, on mid-page 15, the RFC says:

      v
|  The syntax is as follows:

      a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>

It should say:

      vvvvv
|  The SDP syntax is as follows:

      a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val>

(There also is a syntax for these parameters when written in a full
 MIME media type specification; this is not presented in the RFC,
 but it must be distinguished from the SDP syntax presented!)


(6)  [excessive text]

The final paragraph of Section 8.6, on mid-page 20, says:

   In the following sections, some example SDP descriptions are
|  presented.  In some of these examples, long lines are folded to meet
|  the column width constraints of this document; the backslash ("\") at
|  the end of a line and the carriage return that follows it should be
|  ignored.

It would suffice to say:

   In the following sections, some example SDP descriptions are
|  presented.

Rationale:
As will be shown below, in the examples given in Section 8.7,
there in fact is no need to perform this artificial line folding.


(7)  [simplification for improved clarity]

The artificial line folding in the examples in Section 8.7 can be
avoided without change in the indentation, while still conforming
with the line length limitations:

a) In the upper half of page 21, the lines,

   a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\
   0A21F

should read:

   a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F

b) In the lower half of page 21, the lines,

   a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
   0A21F

should read:

   a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F

c) In the upper half of page 22, the lines,

   a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
   0A21F

should read:

   a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F


(8)  [clarification]

On mid-page 21, the text in Section 8.7 says:

   A special case of the SDP description is a description that contains
   only one original session "m" line and one retransmission session "m"
   line, the grouping is then obvious and FID semantics MAY be omitted
   in this special case only.

It should better say:

   A special case of the SDP description is a description that contains
   only one original session "m" line and one retransmission session "m"
|  line, the grouping is then obvious and lines with grouping syntax
   (FID semantics) MAY be omitted in this special case only.

Rationale:
It is impossible to only omit *semantics*.
Certain *lines* are omitted there -- the lines with grouping syntax
(and FID semantics).
Alternatively, "(FID semantics)" might be omitted entirely from
the changed text, as well.


(9)  [word omission -- clarification]

The first paragraph of Section 10.2, on page 25, says:

   This section shows how to combine retransmissions with layered
   encoding in multicast sessions.  Note that the retransmission
   framework is offered only for small multicast applications.  Refer to
   RFC 2887 [10] for a discussion of the problems of NACK implosion,
   severe congestion caused by feedback traffic, in large-group reliable
   multicast applications.

It should better say:

   This section shows how to combine retransmissions with layered
   encoding in multicast sessions.  Note that the retransmission
   framework is offered only for small multicast applications.  Refer to
|  RFC 2887 [10] for a discussion of the problems of NACK implosion, and
   severe congestion caused by feedback traffic, in large-group reliable
   multicast applications.
                                                                     ^^^


(10)  [word omission]

In the first paragraph on page 27, text within Section 13 says:

                                            [...].  Refer to Section 9.1
   of the Secure Real-Time Transport Protocol (SRTP) [12] for a
|  discussion the implications of two-time pads and how to avoid them.
             ^

It should say:
                                                    vvvvvvvvvvvvvvv
                                            [...].  Refer to Section 9.1
|  of the Secure Real-Time Transport Protocol (SRTP) specification [12]
|  for a discussion of the implications of two-time pads and how to
   avoid them.
                   ^^^^

(11)  [inconsistency]

In the fourth bullet on page 29, Appendix A.1 says:

   * avg-rtcp-size is approximated by 120 bytes.  This is a rounded-up
     average of 2 SRs, one for each SSRC, containing 40/8/28/32 bytes
     for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; and a
     RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 bytes.
     [...]

I cannot follow these computations:
    40+8+28+32 = 105  ???   and   40+8+64+32 = 157  ???
What is wrong there?
Authors, please correct !

BTW:
What follows in the text essentially does not depend on the exact
figures, the rough order of magnitude is all that is needed.
But the presentation should be self-consistent.


(12)  [improvement of wording]

In the 6th bullet of Appendix A.1, the text on page 29/30 says:

        [...].  This means that if a packet is requested for
     retransmission a maximum of 2 times, the corresponding generic NACK
     report block requesting that particular packet is sent in two
 << page break >>
|    consecutive RTCP compounds; likewise, if it is requested for
     retransmission 10 times, then the generic NACK is sent 10 times.
     [...]

It should say:

        [...].  This means that if a packet is requested for
     retransmission a maximum of 2 times, the corresponding generic NACK
     report block requesting that particular packet is sent in two
 << page break >>
|    consecutive RTCP compound packets; likewise, if it is requested for
     retransmission 10 times, then the generic NACK is sent 10 times.
     [...]


(13)  [missing argument / clarification]

On page 31, Appendix A.2 says:
                                               vv
|  To find an estimate of the buffering time, T(), that a streaming
   server shall use in order to enable a given number of retransmissions
   for each packet, N.  [...]

It should say:
                                               vvv
|  To find an estimate of the buffering time, T(N), that a streaming
   server shall use in order to enable a given number of retransmissions
   for each packet, N.  [...]


(14)  [fractional sign]

Within the tables in Appendix A.4, on pages 32 and 33, the RFC text
uses the comma (",") as the fractional sign (central european style).
In IETF documents, the decimal point (".") should be used instead.


Authors, Please comment.
Items (4) / (11) need agreement / text correction from you.
Items (6) + (7) might be considered non-esssential.
All other items seem to be straightforward and suitable for
inclusion in an Errata Note.

Notes:

from pending

--VERIFIER COMMENT--


Thanks for your comments. However, I don't consider them worth of correction. Most are just editorial nits, some of which are even wrong. So, for the time being as Joerg said:

"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



Advanced Search