[AVTCORE] [Technical Errata Reported] RFC6184 (4714)
RFC Errata System <rfc-editor@rfc-editor.org> Fri, 17 June 2016 11:18 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6279212D181 for <avt@ietfa.amsl.com>; Fri, 17 Jun 2016 04:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.028
X-Spam-Level:
X-Spam-Status: No, score=-104.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVbxicwT2ZLE for <avt@ietfa.amsl.com>; Fri, 17 Jun 2016 04:18:02 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF17512B05D for <avt@ietf.org>; Fri, 17 Jun 2016 04:18:01 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id D0598B80D8D; Fri, 17 Jun 2016 04:18:01 -0700 (PDT)
To: yekuiwang@huawei.com, even.roni@huawei.com, tom.kristensen@tandberg.com, rjesup@wgate.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, keith.drage@alcatel-lucent.com, roni.even@mail01.huawei.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20160617111801.D0598B80D8D@rfc-editor.org>
Date: Fri, 17 Jun 2016 04:18:01 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/wZxcj-DQ8LYS5SxAVHP7M9cJeHM>
X-Mailman-Approved-At: Sat, 18 Jun 2016 20:33:21 -0700
Cc: avt@ietf.org, rfc-editor@rfc-editor.org
Subject: [AVTCORE] [Technical Errata Reported] RFC6184 (4714)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jun 2016 11:18:03 -0000
The following errata report has been submitted 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 -------------------------------------- Type: Technical Reported by: Iñaki Baz Castillo <ibc@aliax.net> 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. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- 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
- [AVTCORE] [Errata Rejected] RFC6184 (4714) RFC Errata System
- Re: [AVTCORE] [Technical Errata Reported] RFC6184… Magnus Westerlund
- Re: [AVTCORE] [Technical Errata Reported] RFC6184… Mo Zanaty (mzanaty)
- [AVTCORE] [Technical Errata Reported] RFC6184 (47… RFC Errata System