Subject: [AVTCORE] [Errata Rejected] RFC6184 (4714)

From: RFC Errata System <[email-masked]>
Date: Tue, 21 Jun 2016 11:30:24 -0700 (PDT)

The following errata report has been rejected for RFC6184,
"RTP Payload Format for H.264 Video".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6184&eid=4714

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Iñaki Baz Castillo <[email-masked]>
Date Reported: 2016-06-17
Rejected by: Ben Campbell (IESG)

Section: 8.2.2

Original Text
-------------
To simplify the handling and matching of these configurations, the
same RTP payload type number used in the offer SHOULD also be used
in the answer, as specified in [8]

[8] points to RFC 3264 "An Offer/Answer Model with the Session
Description Protocol (SDP)"

Corrected Text
--------------

Notes
-----
The above statement is wrong. RFC 3264 does not mandate the same payload
type in both the offer and the answer. In fact, RFC 3264 section 5.1 states:

   For sendonly RTP streams, the payload type
   numbers indicate the value of the payload type field in RTP packets
   the offerer is planning to send for that codec.  For sendrecv RTP
   streams, the payload type numbers indicate the value of the payload
   type field the offerer expects to receive, and would prefer to send.
   
   However, for sendonly and sendrecv streams, the answer might indicate
   different payload type numbers for the same codecs, in which case,
   the offerer MUST send with the payload type numbers from the answer.
 --VERIFIER NOTES-- 
   Rejected based on discussion on avtcore and payload lists. (3264 does in fact include the SHOULD).

--------------------------------------
RFC6184 (draft-ietf-avt-rtp-rfc3984bis-12)
--------------------------------------
Title               : RTP Payload Format for H.264 Video
Publication Date    : May 2011
Author(s)           : Y.-K. Wang, R. Even, T. Kristensen, R. Jesup
Category            : PROPOSED STANDARD
Source              : Audio/Video Transport
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG