RFC Errata
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)."