From internet-drafts@ietf.org Tue Sep 6 04:49:34 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF15721F86B1; Tue, 6 Sep 2011 04:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuhIUe8AM5fi; Tue, 6 Sep 2011 04:49:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CED221F86A8; Tue, 6 Sep 2011 04:49:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110906114934.2936.71443.idtracker@ietfa.amsl.com> Date: Tue, 06 Sep 2011 04:49:34 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rfc3016bis-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 11:49:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP Payload Format for MPEG-4 Audio/Visual Streams Author(s) : Malte Schmidt Frans de Bont Stefan Doehla Jaehwan Kim Filename : draft-ietf-payload-rfc3016bis-02.txt Pages : 33 Date : 2011-09-06 This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, for new system designs RFC 3640 is preferred, which does not have these restrictions. This document obsoletes RFC 3016. A revision of RFC 3016 was required because of some misalignments between RFC 3016 and the 3GPP PSS specification regarding the RTP payload format for MPEG-4 Audio. Changes from RFC 3016 are summarized in Section 11. Issues on backward compatibility to RFC 3016 are discussed in Section 1.3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc3016bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rfc3016bis-02.txt From frans.de.bont@philips.com Tue Sep 6 04:55:30 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6826D21F8680 for ; Tue, 6 Sep 2011 04:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ocm5Tca45+x for ; Tue, 6 Sep 2011 04:55:29 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id ABFF821F861A for ; Tue, 6 Sep 2011 04:55:26 -0700 (PDT) Received: from mail206-ch1-R.bigfish.com (216.32.181.174) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Sep 2011 11:57:11 +0000 Received: from mail206-ch1 (localhost.localdomain [127.0.0.1]) by mail206-ch1-R.bigfish.com (Postfix) with ESMTP id 5488B1760261; Tue, 6 Sep 2011 11:57:11 +0000 (UTC) X-SpamScore: -54 X-BigFish: VPS-54(zz217bL15d6O9251J936eK542M1432N14ffOzz1202hzz1033IL8275dhz2dh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail206-ch1 (localhost.localdomain [127.0.0.1]) by mail206-ch1 (MessageSwitch) id 1315310230963323_9497; Tue, 6 Sep 2011 11:57:10 +0000 (UTC) Received: from CH1EHSMHS033.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail206-ch1.bigfish.com (Postfix) with ESMTP id E07091A38051; Tue, 6 Sep 2011 11:57:10 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS033.bigfish.com (10.43.70.33) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 6 Sep 2011 11:57:10 +0000 Received: from NLAMSEXH05.connect1.local (172.16.153.68) by connect1.philips.com (172.16.156.42) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 6 Sep 2011 13:57:04 +0200 Received: from NLCLUEXM01.connect1.local ([172.16.153.50]) by NLAMSEXH05.connect1.local ([172.16.153.68]) with mapi; Tue, 6 Sep 2011 13:53:47 +0200 From: "Bont, Frans de" To: "payload@ietf.org" Date: Tue, 6 Sep 2011 13:57:05 +0200 Thread-Topic: [payload] I-D Action: draft-ietf-payload-rfc3016bis-02.txt Thread-Index: AcxsiuP/ts6Q4zaNSpKoJRijejDpeAAAItlg Message-ID: <19FE62CE8D62CF4B96C845DC556B8813A34EB0AE6E@NLCLUEXM01.connect1.local> References: <20110906114934.2936.71443.idtracker@ietfa.amsl.com> In-Reply-To: <20110906114934.2936.71443.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "adrian@olddog.co.uk" , "turners@ieca.com" , "stpeter@stpeter.im" Subject: Re: [payload] I-D Action: draft-ietf-payload-rfc3016bis-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 11:55:30 -0000 Hi all, The draft has been updated to address the comments received after the IESG = review. Besides a few nits the most important changes are a further clarification i= n the section describing the compatibility to RFC 3016, and the addition of a new section devoted to the relation between this draft and RFC 3640. Your comments are welcome! Best regards, Frans > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Tuesday 6 September 2011 13:50 > To: i-d-announce@ietf.org > Cc: payload@ietf.org > Subject: [payload] I-D Action: draft-ietf-payload-rfc3016bis-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Audio/Video Transport > Payloads Working Group of the IETF. > > Title : RTP Payload Format for MPEG-4 Audio/Visual > Streams > Author(s) : Malte Schmidt > Frans de Bont > Stefan Doehla > Jaehwan Kim > Filename : draft-ietf-payload-rfc3016bis-02.txt > Pages : 33 > Date : 2011-09-06 > > This document describes Real-Time Transport Protocol (RTP) payload > formats for carrying each of MPEG-4 Audio and MPEG-4 Visual > bitstreams without using MPEG-4 Systems. For the purpose of > directly > mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides > specifications for the use of RTP header fields and also specifies > fragmentation rules. It also provides specifications for Media Type > registration and the use of Session Description Protocol (SDP). The > audio payload format described in this document has some limitations > related to the signaling of audio codec parameters for the required > multiplexing format. Therefore, for new system designs RFC 3640 is > preferred, which does not have these restrictions. > > This document obsoletes RFC 3016. A revision of RFC 3016 was > required because of some misalignments between RFC 3016 and the 3GPP > PSS specification regarding the RTP payload format for MPEG-4 Audio. > Changes from RFC 3016 are summarized in Section 11. Issues on > backward compatibility to RFC 3016 are discussed in Section 1.3. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc3016bis- > 02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rfc3016bis-02.txt > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From kaz.mishima@gmail.com Wed Sep 7 00:14:21 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B7511E8081 for ; Wed, 7 Sep 2011 00:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.527 X-Spam-Level: X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zzhrZa-srb8 for ; Wed, 7 Sep 2011 00:14:20 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0811E8073 for ; Wed, 7 Sep 2011 00:14:19 -0700 (PDT) Received: by yie12 with SMTP id 12so5447931yie.31 for ; Wed, 07 Sep 2011 00:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nFq4RdkL2gaiyDx00SNOSrX+gM+KqwOCkw9PDt77GYA=; b=CHg4E0Ip13tJKkl4AuLiXdLF5XVp8ijQaYMJvK3EGrMurDQv8PaBJwLYvF2K/rxzuU B/AVdARDOh9PHqjqNHocvQ8KJ71HM+06MM5afK44saAt3AWP9ofbcnEP9HGA9dyMl0Q0 5hIyLt7QLgv7PwNml4Kwot/FQHZ4KKyCPbeS0= MIME-Version: 1.0 Received: by 10.236.176.33 with SMTP id a21mr29515145yhm.108.1315379766324; Wed, 07 Sep 2011 00:16:06 -0700 (PDT) Sender: kaz.mishima@gmail.com Received: by 10.147.170.16 with HTTP; Wed, 7 Sep 2011 00:16:06 -0700 (PDT) In-Reply-To: <3B8857F0-F4BB-411D-8B30-754D0C05E0B1@nostrum.com> References: <3B8857F0-F4BB-411D-8B30-754D0C05E0B1@nostrum.com> Date: Wed, 7 Sep 2011 16:16:06 +0900 X-Google-Sender-Auth: hVgfizkJsirYAqZJhVBYtlXm2PI Message-ID: From: Kazuhiro Mishima To: Robert Sparks Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-payload-rfc3189bis@tools.ietf.org, payload@ietf.org Subject: Re: [payload] AD review: draft-ietf-payload-rfc3189bis-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 07:14:21 -0000 Hi Robert, Thank you for your comment. I'll update our draft with 3 comments soon. 2011/9/1 Robert Sparks : > Summary: This draft needs a small revision before moving to IETF Last Call. > > Akimichi Ogawa was removed from the author list, and not credited in an acknowledgment section. > I think it would be appropriate to add one. This probably also means the draft should use the > pre-5378 boilerplate. Please issue a revision with those changes (or let me know why they are not needed). > > A minor point to consider while making that update: > > The 7th point in the Major changes section does not stand alone - what is it trying to say? Is it > just pointing to aligning with the advice in draft-ietf-payload-rtp-howto? > > RjS > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > From internet-drafts@ietf.org Wed Sep 7 15:32:06 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82FA21F8E07; Wed, 7 Sep 2011 15:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG5Iz3Pc7jp0; Wed, 7 Sep 2011 15:32:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338BB21F8DFE; Wed, 7 Sep 2011 15:32:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110907223206.21317.49639.idtracker@ietfa.amsl.com> Date: Wed, 07 Sep 2011 15:32:06 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-mvc-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 22:32:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP Payload Format for MVC Video Author(s) : Ye-Kui Wang Thomas Schierl Robert Skupin Filename : draft-ietf-payload-rtp-mvc-01.txt Pages : 27 Date : 2011-09-07 This memo describes an RTP payload format for the multiview extension of the ITU-T Recommendation H.264 video codec that is technically identical to ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units, produced by the video encoder, in each RTP payload. The payload format can be applied in RTP based 3D video transmissions such as such as 3D video streaming, free-viewpoint video, and 3DTV. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-mvc-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rtp-mvc-01.txt From chung.cheung.chu@ericsson.com Fri Sep 9 13:00:07 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8147821F87FC for ; Fri, 9 Sep 2011 13:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1MciwZQ47-B for ; Fri, 9 Sep 2011 13:00:06 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7878221F8726 for ; Fri, 9 Sep 2011 13:00:06 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p89K1l0C003745; Fri, 9 Sep 2011 15:02:02 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 9 Sep 2011 16:01:39 -0400 From: Chung Cheung Chu To: "payload@ietf.org" , "Fang, Zheng" Date: Fri, 9 Sep 2011 16:01:37 -0400 Thread-Topic: [payload] EVRC-NW wideband encoding capability identification in "draft-ietf-avt-rtp-evrc-nw-03" Thread-Index: Acv7cBLQOXCKYLYoShWDuO6AxsjItRy9+IyQ Message-ID: <26490BBDEEACA14EA1A0070367B3ADBDB9A56A164F@EUSAACMS0702.eamcs.ericsson.se> References: <26490BBDEEACA14EA1A0070367B3ADBDB77844EFD6@EUSAACMS0702.eamcs.ericsson.se> In-Reply-To: <26490BBDEEACA14EA1A0070367B3ADBDB77844EFD6@EUSAACMS0702.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_26490BBDEEACA14EA1A0070367B3ADBDB9A56A164FEUSAACMS0702e_" MIME-Version: 1.0 Subject: [payload] EVRC-NW wideband encoding capability identification in "draft-ietf-avt-rtp-evrc-nw-03" X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 20:00:07 -0000 --_000_26490BBDEEACA14EA1A0070367B3ADBDB9A56A164FEUSAACMS0702e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Background Per "draft-ietf-avt-rtp-evrc-nw-03", an EVRC-NW wideband-capable system usi= ng interleaved/bundled format would transmit MMM=3D0 to request the other e= nd to encode and transmit EVRC-NW wideband encoded traffic. If both the ne= ar end and the far end of a call are capable of EVRC-NW wideband support, t= his mechanism will lead to the exchange of wideband traffic in both directi= ons. If the far end of a call is not capable of wideband encoding, the far end w= ill only encode and transmit traffic in narrowband mode despite the near en= d's repeated requests for wideband traffic. Per "draft-ietf-avt-rtp-evrc-= nw-03.txt", the near end system will not know for certain of the far end's = wideband encoding capability/incapability. Should the near end system be a= ware of the far end's incapability of wideband encoding, the near end can u= pdate the MMM bit-field to request the preferred narrowband traffic meeting= the near end's local requirements. For example, the near end could reques= t Mode4 narrowband traffic if the near end system prefers bandwidth conserv= ation over better narrowband quality. The near end could alternatively req= uest Mode1 narrowband traffic if the near end system prefers better narrowb= and quality over bandwidth conservation. The issue can manifest itself in another way where end-to-end wideband comm= unication is established first but the far end becomes wideband encoding in= capable during the call, due to RF change or hand-over for example. Another potential issue is that in the event the near end wideband capable = system switches the mode request value in MMM from Mode0 to non-Mode0 for n= arrowband traffic in the scenarios above, the near end will not know if an= d when the far end would become wideband encoding capable again. End-to-en= d wideband communication, if desired, may never be realized again for the r= est of the call. Proposal In the EVRCNW interleaved/bundled format, define a dedicated bit-field to s= ignal the instantaneous local EVRC-NW wideband encoding capability. This i= nstantaneous wideband encoding capability identifier is sent together with = the MMM field in the payload of each EVRC-NW packet to the other end. For example, this bit-field can be allocated out of the existing 2-bit rese= rved bit-field. A value of 0 (default) indicates the sending system is ca= pable of EVRC-NW wideband encoding. A value of 1 indicates it is incapable= of wideband encoding. The instantaneous wideband encoding capability identifier in each incoming = packet is interpreted by the local control logic to determine the appropria= te MMM mode request to the far end for wideband or narrowband encoded traff= ic. While the far end is not capable of wideband encoding, the near end wi= ll request with an explicit mode request the preferrerd narrowband encoding= mode. Otherwise the near end can request wideband encoded traffic. The = preferred encoding mode equested can match the far end's capability dynamic= ally. The suggested change is for media subtype EVRCNW payload format only. It i= s not applicable to media subtype EVRCNW0 and EVRCNW1 payload formats where= the MMM mode request field is not supported. Regards, CC Chung-Cheung Chu Media Gateway DSP Design BCAM - Ericsson ECN: 810-16713 External: +514-461-6713 or +514 345-7900 x46489 This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. --_000_26490BBDEEACA14EA1A0070367B3ADBDB9A56A164FEUSAACMS0702e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Background
 
Per=20 "draft-ietf-avt-rtp-evrc-nw-03", an EVRC-NW wideband-capable system using interleaved/bundled= format=20 would transmit MMM=3D0 to request the other end to encode and transmit EVRC= -NW=20 wideband encoded traffic.  If both the near end and the far end of a c= all=20 are capable of EVRC-NW wideban= d=20 support, this mechanism will lead to the exchange of wideband traffic in bo= th=20 directions. 
 
If the far end of a call is not capable of w= ideband=20 encoding, the far end will only encode and transmit traffic in=20 narrowband mode despite the near end's repeated requests for wideband=20 traffic.   Per "draft-ietf-avt-rtp-evrc-nw-03.txt", the nea= r end=20 system will not know for certain of the far end's wideband encoding=20 capability/incapability.  Should the near end system be aware of the f= ar=20 end's incapability of wideband encoding,=20 the near end can update the MMM bit-field to request the preferred narrowba= nd=20 traffic meeting the near end's local requirements.  For example, the n= ear=20 end could request Mode4 narrowband traffic if the near end system prefers=20 bandwidth conservation over better narrowband quality.  The near end=20 could alternatively request Mo= de1=20 narrowband traffic if the near end system prefers better narrowband quality= over=20 bandwidth conservation.
 
The issue can manifest itself in = another=20 way where end-to-end wideband communication is established first but t= he=20 far end becomes wideband encoding incapable during the call, due to RF chan= ge or=20 hand-over for example.
 
Another po= tential=20 issue is that in the event the near end wideband capable system swit= ches=20 the mode request value in MMM from Mode0 to non-Mode0 for narrowband=20 traffic in the scenarios above,&nbs= p; the=20 near end will not know if and when the far end would become wideband encodi= ng=20 capable again.  End-to-end wideband communication, if desired, may never be realized<= SPAN=20 class=3D846254320-08092011> again for the rest of the=20 call.
 
Proposal
 
In the EVRCNW interleaved/bundled format, define a= =20 dedicated bit-field to signal the instantaneous local EVRC-NW wideband encodi= ng=20 capability.  This instantaneous= =20 wideband encoding capability identifier is sent together with the MM= M=20 field in the payload of each EVRC-NW packet to the other=20 end.
 
For example, this bit-field can be allocated out o= f the=20 existing 2-bit reserved bit-field.   A value of 0 (default) indic= ates=20 the sending system is capable of EVRC-NW wideband encoding.  A value o= f 1=20 indicates it is incapable of wideband encoding.
 
The instanta= neous=20 wideband encoding capability identifier in each incoming packet is=20 interpreted by the local control logic to determine the appropriate MMM mode request to the far end for wideb= and or=20 narrowband encoded traffic.  Whi= le=20 the far end is not capable of wideband encoding, the near end will=20 request with an explicit mode request the preferrerd narrowband encoding=20 mode.  Otherwise the near end can request wideband encoded=20 traffic.   The preferred encoding mode equested can match the far end's capability dynamically.
 
 
 
The= suggested=20 change is for media subtype EVRCNW payload format only.  It is no= t=20 applicable to media subtype EVRCNW0 and EVRCNW1 payload formats where the M= MM=20 mode request field is not supported.
 
 
Regards,
 
CC

Chung-Cheung Chu=20
Media Gateway DSP=20 Design
BCA= M -=20 Ericsson
ECN:       810-16713=20
External: +514-461-6713&= nbsp; =20 or   +514 345-7900 x46489

This Commu= nication is=20 Confidential.  We only send and receive email on the basis of the term= s set=20 out at www.ericsson.com/email_disclaimer.

--_000_26490BBDEEACA14EA1A0070367B3ADBDB9A56A164FEUSAACMS0702e_-- From internet-drafts@ietf.org Mon Sep 12 01:21:33 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0BA21F8569; Mon, 12 Sep 2011 01:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM8I3F6OPkBI; Mon, 12 Sep 2011 01:21:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2933221F847B; Mon, 12 Sep 2011 01:21:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110912082133.738.1161.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 01:21:33 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rfc3016bis-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 08:21:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP Payload Format for MPEG-4 Audio/Visual Streams Author(s) : Malte Schmidt Frans de Bont Stefan Doehla Jaehwan Kim Filename : draft-ietf-payload-rfc3016bis-03.txt Pages : 33 Date : 2011-09-12 This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. It is a revision of RFC 3016 and is needed because of some misalignments between RFC 3016 and the 3GPP PSS specification regarding the RTP payload format for MPEG-4 Audio. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, for new system designs should be utilize RFC 3640 which does not have these restrictions. Nevertheless, this revision of RFC 3016 is provided to update and complete the specification, and to enable interopeable implementations. This document obsoletes RFC 3016. It contains a summary of changes from RFC 3016 and discussed backward compatibility to RFC 3016. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc3016bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rfc3016bis-03.txt From frans.de.bont@philips.com Mon Sep 12 01:29:42 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7C621F86EC for ; Mon, 12 Sep 2011 01:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wk6cZWYkgcT for ; Mon, 12 Sep 2011 01:29:41 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 23DF121F86DD for ; Mon, 12 Sep 2011 01:29:40 -0700 (PDT) Received: from mail64-ch1-R.bigfish.com (216.32.181.170) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Mon, 12 Sep 2011 08:31:43 +0000 Received: from mail64-ch1 (localhost.localdomain [127.0.0.1]) by mail64-ch1-R.bigfish.com (Postfix) with ESMTP id 06B74102BC for ; Mon, 12 Sep 2011 08:31:43 +0000 (UTC) X-SpamScore: -47 X-BigFish: VPS-47(zz217bL15d6O9251J936eK542M1432Nzz1202hzz1033IL8275dhz2dh2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:168.87.56.20; KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail64-ch1 (localhost.localdomain [127.0.0.1]) by mail64-ch1 (MessageSwitch) id 1315816302796871_29444; Mon, 12 Sep 2011 08:31:42 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail64-ch1.bigfish.com (Postfix) with ESMTP id B54DD1AA0052 for ; Mon, 12 Sep 2011 08:31:42 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 12 Sep 2011 08:31:42 +0000 Received: from nlamsexh01.connect1.local (172.16.153.11) by connect1.philips.com (172.16.156.150) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 12 Sep 2011 10:31:09 +0200 Received: from NLCLUEXM01.connect1.local ([172.16.153.50]) by nlamsexh01.connect1.local ([172.16.153.11]) with mapi; Mon, 12 Sep 2011 10:27:39 +0200 From: "Bont, Frans de" To: "payload@ietf.org" Date: Mon, 12 Sep 2011 10:31:07 +0200 Thread-Topic: [payload] I-D Action: draft-ietf-payload-rfc3016bis-03.txt Thread-Index: AcxxJN6QqeO2/5U2R0ul9+G36T2YBwAAJD4A Message-ID: <19FE62CE8D62CF4B96C845DC556B8813A34EBAB8D4@NLCLUEXM01.connect1.local> References: <20110912082133.738.1161.idtracker@ietfa.amsl.com> In-Reply-To: <20110912082133.738.1161.idtracker@ietfa.amsl.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, nl-NL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [payload] I-D Action: draft-ietf-payload-rfc3016bis-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 08:29:42 -0000 The draft was revised to update the abstract accordingly a comment from Adr= ian Farrel (IESG review). Best regards, Frans > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Monday 12 September 2011 10:22 > To: i-d-announce@ietf.org > Cc: payload@ietf.org > Subject: [payload] I-D Action: draft-ietf-payload-rfc3016bis-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Audio/Video Transport > Payloads Working Group of the IETF. > > Title : RTP Payload Format for MPEG-4 Audio/Visual > Streams > Author(s) : Malte Schmidt > Frans de Bont > Stefan Doehla > Jaehwan Kim > Filename : draft-ietf-payload-rfc3016bis-03.txt > Pages : 33 > Date : 2011-09-12 > > This document describes Real-Time Transport Protocol (RTP) payload > formats for carrying each of MPEG-4 Audio and MPEG-4 Visual > bitstreams without using MPEG-4 Systems. It is a revision of RFC > 3016 and is needed because of some misalignments between RFC 3016 > and > the 3GPP PSS specification regarding the RTP payload format for > MPEG-4 Audio. > > For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams > onto RTP packets, this document provides specifications for the use > of RTP header fields and also specifies fragmentation rules. It > also > provides specifications for Media Type registration and the use of > Session Description Protocol (SDP). The audio payload format > described in this document has some limitations related to the > signaling of audio codec parameters for the required multiplexing > format. Therefore, for new system designs should be utilize RFC > 3640 > which does not have these restrictions. Nevertheless, this revision > of RFC 3016 is provided to update and complete the specification, > and > to enable interopeable implementations. > > This document obsoletes RFC 3016. It contains a summary of changes > from RFC 3016 and discussed backward compatibility to RFC 3016. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc3016bis- > 03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rfc3016bis-03.txt > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From internet-drafts@ietf.org Mon Sep 12 02:27:04 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5B321F8AF3; Mon, 12 Sep 2011 02:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj4yiirFVgJ7; Mon, 12 Sep 2011 02:27:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C4521F8AE1; Mon, 12 Sep 2011 02:27:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110912092704.17661.21453.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 02:27:04 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rfc3189bis-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 09:27:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP Payload Format for DV (IEC 61834) Video Author(s) : Katsushi Kobayashi Kazuhiro Mishima Stephen L. Casner Carsten Bormann Filename : draft-ietf-payload-rfc3189bis-02.txt Pages : 19 Date : 2011-09-12 This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV&quo= t; into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc3189bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rfc3189bis-02.txt From kaz.mishima@gmail.com Mon Sep 12 02:31:49 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7321F8AAA for ; Mon, 12 Sep 2011 02:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DupEH5-AIXWp for ; Mon, 12 Sep 2011 02:31:49 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4F02E21F889A for ; Mon, 12 Sep 2011 02:31:49 -0700 (PDT) Received: by gxk9 with SMTP id 9so3250029gxk.40 for ; Mon, 12 Sep 2011 02:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ZVIACVyGPBIUKwntya0J1jM4/kUl7az0cVqaqJT6JMo=; b=TmSO+WXUhhTfLo9WXJtRpzbC+/X4wRlYmvMNiKMH3ECvWQ9+V/bdrHKHMbGINgH2J4 h/qjPAMvkWopGygsK1tbxudMeNJ1RiKFl3qORvH0x6YEdLeoQwIIY7PHCrh66VZ2M2vP 6CGdLG9sTL8alSaHP5MNTmNQCxPgkKXAT5C/I= MIME-Version: 1.0 Received: by 10.236.191.71 with SMTP id f47mr7292400yhn.125.1315820031921; Mon, 12 Sep 2011 02:33:51 -0700 (PDT) Sender: kaz.mishima@gmail.com Received: by 10.147.170.16 with HTTP; Mon, 12 Sep 2011 02:33:51 -0700 (PDT) In-Reply-To: <20110912092704.17661.21453.idtracker@ietfa.amsl.com> References: <20110912092704.17661.21453.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 18:33:51 +0900 X-Google-Sender-Auth: rRULg90eOMEJ9-O1DAJT1HdBcQs Message-ID: From: Kazuhiro Mishima To: payload@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [payload] I-D Action: draft-ietf-payload-rfc3189bis-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 09:31:49 -0000 Dear All, The draft was revised by AD review(Robert's comment). Thank you. Kazuhiro 2011/9/12 : > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Audio/Video Transport Payloads Work= ing Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : RTP Payload Format for DV (IEC= 61834) Video > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Katsushi Kobayashi > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Kazuhiro Mishima > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stephen L. Casner > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Carsten Bormann > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-payload-rfc3189bis-02= .txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 19 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-09-12 > > =A0 This document specifies the packetization scheme for encapsulating > =A0 the compressed digital video data streams commonly known as "DV&= quot; into > =A0 a payload format for the Real-Time Transport Protocol (RTP). =A0This > =A0 document obsoletes RFC 3189. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc3189bis-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rfc3189bis-02.txt > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > From iesg-secretary@ietf.org Mon Sep 12 12:24:17 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB1C21F8C92; Mon, 12 Sep 2011 12:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGWndoM8GG+N; Mon, 12 Sep 2011 12:24:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DFC21F8C8E; Mon, 12 Sep 2011 12:24:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110912192416.8107.2460.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 12:24:16 -0700 Cc: payload@ietf.org Subject: [payload] Last Call: (RTP Payload Format for DV (IEC 61834) Video) to Proposed Standard X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 19:24:17 -0000 The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for DV (IEC 61834) Video' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Sep 12 12:38:41 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BB321F8CD3; Mon, 12 Sep 2011 12:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfAEbdMuXgsp; Mon, 12 Sep 2011 12:38:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950D521F8CCD; Mon, 12 Sep 2011 12:38:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110912193840.13846.17334.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 12:38:40 -0700 Cc: payload chair , payload mailing list , RFC Editor Subject: [payload] Protocol Action: 'RTP Payload Format for MPEG-4 Audio/Visual Streams' to Proposed Standard (draft-ietf-payload-rfc3016bis-03.txt) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 19:38:41 -0000 The IESG has approved the following document: - 'RTP Payload Format for MPEG-4 Audio/Visual Streams' (draft-ietf-payload-rfc3016bis-03.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Payloads Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3016bis/ Technical Summary "This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of Session Description Protocol (SDP). The audio payload format described in this document has some limitations for new system designs [RFC3640] is preferred." Working Group Summary The draft was submitted to address inconsistency between RFC3016 and its use in 3GPP that defined an additional parameter. The individual draft was submitted in February 2009. It had some reviews until the WGLC but there were no controversy. During the WGLC there were some comments that were addressed and there were no open issues before we submitted it to publication. Document Quality The media type review was posted on April 28, 2011. The document updates RFC3016 to support existing implementations that comply with the specification in 3GPP PSS. Based on the reviews we are not aware of any implementation that use RFC3016 not based on 3GPP PSS specification. RFC Editor Note (applies to -03) In the abstract: s/Therefore, for new/Therefore, new/ s/interopeable/interoperable/ s/discussed backwards/discusses backwards/ From bill.wu@huawei.com Mon Sep 19 23:15:41 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A22411E8082; Mon, 19 Sep 2011 23:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=-1.407, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIqja026nRfm; Mon, 19 Sep 2011 23:15:40 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2862D11E8073; Mon, 19 Sep 2011 23:15:39 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRT00J475FHRJ@szxga04-in.huawei.com>; Tue, 20 Sep 2011 14:16:29 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRT00FCQ5EXY7@szxga04-in.huawei.com>; Tue, 20 Sep 2011 14:16:29 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADU09907; Tue, 20 Sep 2011 14:16:29 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 20 Sep 2011 14:16:25 +0800 Received: from w53375q (10.138.41.130) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 20 Sep 2011 14:16:27 +0800 Date: Tue, 20 Sep 2011 14:16:25 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: ietf@ietf.org Message-id: <17D448F688A3446180420DCC3AE3F66A@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_eLz2toXVI2EA/5gtqRjBBQ)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected Cc: payload@ietf.org Subject: Re: [payload] [Payload] Last Call: (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 06:15:41 -0000 --Boundary_(ID_eLz2toXVI2EA/5gtqRjBBQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, I have just read this document and have some minor comments, hope it is not late to be taken into account. 1. Section 1: [Qin]: It looks this version extends RFC3189 to support some new features. However I can not see any dependency to RFC3189 in the introduction section until I read the last section in this document, is it more straigtforward and clear to merge the section 7,8 to the introduction section and clarify how this document is different from RFC3189. 2. Section 3.1.1 " 3.1.1. Media Type Registration for DV Video Type name: video Subtype name: DV Required parameters: encode: type of DV format. Permissible values for encode are SD-VCR/525-60, SD-VCR/625-50, HD-VCR/1125-60, HD-VCR/1250-50, SDL-VCR/525-60, SDL-VCR/625-50, 314M-25/525-60, 314M-25/625-50, 314M-50/525-60, 314M-50/625-50, 370M/1080-60i, 370M/1080-50i, 370M/720-60p, 370M/720-50p, 306M/525-60 (for backward compatibility), and 306M/625-50 (for backward compatibility). " [Qin]: In section 7, you claim you have removed SMPTE 306M, since it is covered by SMPTE 314M format. However in section 3.1.2, the value for SMPTE 306M is still kept in the encode list. So the question is where do you remove SMPTE 306M in this document? Why SMPTE 306M in the media type registration is still kept? Does this conflict with what you said in the section 7? The same comment applies in any place of this document where SMPTE 306M is still kept. 3. Section 3.1.1 " Optional parameters: audio: whether the DV stream includes audio data or not. Permissible values for audio are bundled and none. Defaults to none. Encoding considerations: DV video can be transmitted with RTP as specified in RFCXXXX (This document). Other transport methods are not specified. Security considerations: See Section 4 of RFCXXXX (This document). Interoperability considerations: NONE " [Qin]: Is it real that there is no interoperability consideration since Interoperability with Previous Implementations is discussed in the section 8 of this document? 4. Section 3.2.1 " Note that the examples in RFC3189 (older version of this document) provides incorrect SDP "a=fmtp" attribute usage. " [Qin]: I believe it is not appropriate to spell this note out when this document is published but you may put it as errata or in the section 7. 5. Section 3.2.1 " The required parameter specifies which type of DV format is used. The DV format name will be one of the following: SD-VCR/525-60 SD-VCR/625-50 HD-VCR/1125-60 HD-VCR/1250-50 SDL-VCR/525-60 SDL-VCR/625-50 314M-25/525-60 314M-25/625-50 314M-50/525-60 314M-50/625-50 370M/1080-60i 370M/1080-50i 370M/720-60p 370M/720-50p 306M/525-60 (for backward compatibility) 306M/625-50 (for backward compatibility) " [Qin]: Why you need to repeat the same text in the section 3.1, why not just simply reference it described in the section 3.1. 6. Section 3.2.1 " In order to show whether the audio data is bundled into the DV stream or not, a format specific parameter is defined as below: " [Qin]: s/ a format specifc parameter/ a format of specific parameter 7. Section 3.2.1 " The optional parameter