From roni.even@mail01.huawei.com Thu Nov 1 07:48:46 2012 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 D9A2721F8D36; Thu, 1 Nov 2012 07:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KAmhUOhbAzh; Thu, 1 Nov 2012 07:48:46 -0700 (PDT) Received: from hwsga01-in.huaweimarine.com (unknown [119.145.15.223]) by ietfa.amsl.com (Postfix) with ESMTP id BC04B21F8D2E; Thu, 1 Nov 2012 07:48:43 -0700 (PDT) Received: from szxpml204-edg.exmail.huawei.com ([172.17.1.119]) by hwsga01-in.huaweimarine.com (MOS 4.1.3-GA) with ESMTP id AED23081; Thu, 1 Nov 2012 22:48:33 +0800 X-Mirapoint-Received-SPF: 172.17.1.119 szxpml204-edg.exmail.huawei.com 5 none X-Mirapoint-Received-SPF: 172.17.1.119 szxpml204-edg.exmail.huawei.com 5 none Received: from SZXPML404-HUB.exmail.huawei.com (10.82.67.165) by szxpml204-edg.exmail.huawei.com (172.24.2.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Nov 2012 22:48:19 +0800 Received: from SZXPML504-MBS.exmail.huawei.com ([169.254.4.23]) by szxpml404-hub.exmail.huawei.com ([10.82.67.165]) with mapi id 14.01.0323.003; Thu, 1 Nov 2012 22:48:32 +0800 From: Roni Even To: "avt@ietf.org" , "payload@ietf.org" Thread-Topic: CORRECTION: Help the NomCom Thread-Index: AQHNuDCgu11Va/GwQkSHgjeke/CnipfVDwn3 Date: Thu, 1 Nov 2012 14:48:31 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C205B622A9@szxpml504-mbs.exmail.huawei.com> References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> In-Reply-To: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [payload] FW: CORRECTION: Help the NomCom 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: Thu, 01 Nov 2012 14:48:47 -0000 Hi, Note that NomCopm will receive input till 11/11 and not till the 4th as was= stated in previous email Roni Even ________________________________________ From: wgchairs-bounces@ietf.org [wgchairs-bounces@ietf.org] on behalf of No= mCom Chair [nomcom-chair@ietf.org] Sent: Thursday, November 01, 2012 2:17 PM To: Working Group Chairs Subject: CORRECTION: Help the NomCom I sent a message several hours ago requesting that you help and make your working group aware that the NomCom is looking for input from the community. This message had a minor error. The NomCom needs to receive community input by November 11, 2012. The full text of the corrected message is below --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11= . The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org= From frans.de.bont@philips.com Thu Nov 8 07:11:29 2012 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 DE1A721F8460 for ; Thu, 8 Nov 2012 07:11:29 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOPDxN64Ut6M for ; Thu, 8 Nov 2012 07:11:29 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 0722121F85A1 for ; Thu, 8 Nov 2012 07:11:28 -0800 (PST) Received: from mail194-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 15:11:28 +0000 Received: from mail194-ch1 (localhost [127.0.0.1]) by mail194-ch1-R.bigfish.com (Postfix) with ESMTP id 8B12F4025F for ; Thu, 8 Nov 2012 15:11:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -39 X-BigFish: VPS-39(zz217bI98dI15d6O9251J936eI542M1432I179cMzz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received: from mail194-ch1 (localhost.localdomain [127.0.0.1]) by mail194-ch1 (MessageSwitch) id 1352387485774774_27266; Thu, 8 Nov 2012 15:11:25 +0000 (UTC) Received: from CH1EHSMHS040.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail194-ch1.bigfish.com (Postfix) with ESMTP id B97AA2A004C for ; Thu, 8 Nov 2012 15:11:25 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Nov 2012 15:11:25 +0000 Received: from 011-DB3MPN1-011.MGDPHG.emi.philips.com ([169.254.1.234]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.02.0318.003; Thu, 8 Nov 2012 15:11:24 +0000 From: "Bont, Frans de" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-sbc-03.txt Thread-Index: AQHNXUHUkTb6QRnBmEq8BRfEMeEAlJcjolVwgL0nNxA= Date: Thu, 8 Nov 2012 15:11:23 +0000 Message-ID: References: <20120708194131.19596.76821.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.100] 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-rtp-sbc-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: Thu, 08 Nov 2012 15:11:30 -0000 Hi, > We think this draft is now ready for WGLC. We did not receive any comment so far, please forward them if you have any. Otherwise, we can proceed with this draft. Best regards, Frans > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal= f > Of Bont, Frans de > Sent: Wednesday 11 July 2012 8:40 > To: payload@ietf.org > Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-sbc-03.txt > > Hi, > > In this version we have removed the sections which were mainly a duplicat= ion > of the Bluetooth A2DP specification. > This was in response to the only comment we received on the -02 version. > > On 5 Jan 2012, at 0:47, Colin Perkins wrote: > > The only outstanding issue I have is that there's a lot of duplication = with the > RTP payload format definition in Bluetooth A2DP specification. Can this b= e > removed, and done by reference, to avoid the risk of accidental changes? > > We think this draft is now ready for WGLC. > > Best regards, > Frans > > > -----Original Message----- > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > > Behalf Of internet-drafts@ietf.org > > Sent: Sunday 8 July 2012 21:42 > > To: i-d-announce@ietf.org > > Cc: payload@ietf.org > > Subject: [payload] I-D Action: draft-ietf-payload-rtp-sbc-03.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Audio/Video Transport Payloads > > Working Group of the IETF. > > > > Title : RTP Payload Format for Bluetooth's SBC Audio Co= dec > > Author(s) : Christian Hoene > > Frans de Bont > > Filename : draft-ietf-payload-rtp-sbc-03.txt > > Pages : 23 > > Date : 2012-07-08 > > > > Abstract: > > This document specifies a Real-time Transport Protocol (RTP) payload > > format to be used for the low complexity subband codec (SBC), which > > is the mandatory audio codec of the Advanced Audio Distribution > > Profile (A2DP) Specification written by the Bluetooth(r) Special > > Interest Group (SIG). The payload format is designed to be able to > > interoperate with existing Bluetooth A2DP devices, to provide high > > streaming audio quality, interactive audio transmission over the > > internet, and ultra-low delay coding for jam sessions on the > > internet. This document contains also a media type registration > > which specifies the use of the RTP payload format. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-sbc > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-payload-rtp-sbc-03 > > > > A diff from previous version is available at: > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-sbc-03 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notif= ied that > any use, forwarding, dissemination, or reproduction of this message is st= rictly > prohibited and may be unlawful. If you are not the intended recipient, pl= ease > contact the sender by return e-mail and destroy all copies of the origina= l > message. > > _______________________________________________ > 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 Thu Nov 15 15:54:02 2012 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 5DC601F041A; Thu, 15 Nov 2012 15:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQW8H3KX9qWd; Thu, 15 Nov 2012 15:54:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFE521F8485; Thu, 15 Nov 2012 15:54:01 -0800 (PST) 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: 4.36 Message-ID: <20121115235401.29863.76379.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 15:54:01 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-08.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: Thu, 15 Nov 2012 23:54:02 -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 Working Gr= oup of the IETF. Title : RTP payload format for Enhanced Variable Rate Narrowband= -Wideband Codec (EVRC-NW) Author(s) : Zheng Fang Filename : draft-ietf-avt-rtp-evrc-nw-08.txt Pages : 32 Date : 2012-11-15 Abstract: This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-evrc-nw There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-evrc-nw-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zfang@qualcomm.com Thu Nov 15 15:59:21 2012 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 35A651F0C44 for ; Thu, 15 Nov 2012 15:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shwyiglKXnbR for ; Thu, 15 Nov 2012 15:59:18 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id BF45D1F041A for ; Thu, 15 Nov 2012 15:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1353023053; x=1384559053; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; bh=S3qcJpl7x51O90anZczgbMOOnmLMUT4Hx8qV3TF51WA=; b=kGoNG1QPJrmEN3Y5Yd8PAKNaDAKuEWpArMktTuzxcLIUUhlMQf0Qmf2C ujVPopETOVqaa1g3Rq5mszYZuozYnVE+nF94hp3z508+46rKoA1Wq889m WZxMjCshjkAeV2ttA44lrWvIMuTpnYqSnA16mKc7Imb4NSBlpfKEYvajY A=; X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="7209657" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 15 Nov 2012 15:44:09 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="426689551" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Nov 2012 15:59:14 -0800 Received: from NASANEXD01A.na.qualcomm.com ([169.254.1.5]) by nasanexhc06.na.qualcomm.com ([172.30.48.21]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 15:59:13 -0800 From: "Fang, Zheng" To: Chung Cheung Chu , Robert Sparks , "payload@ietf.org" Thread-Topic: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 Thread-Index: AQHNsfOo390+zGVrdUqBUH2Af2DXXpfLACGAgAAGuQCAAS6VgIAfgDPQ Date: Thu, 15 Nov 2012 23:59:13 +0000 Message-ID: References: <5086FAD4.8070301@nostrum.com> <5087FABC.6010902@nostrum.com> <26490BBDEEACA14EA1A0070367B3ADBDC42E2FBFA7@EUSAACMS0702.eamcs.ericsson.se> <5089B412.9010505@nostrum.com> <26490BBDEEACA14EA1A0070367B3ADBDC42E38C6F6@EUSAACMS0702.eamcs.ericsson.se> In-Reply-To: <26490BBDEEACA14EA1A0070367B3ADBDC42E38C6F6@EUSAACMS0702.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_E23CE350F3C94C4A834B4E7069CA56792229CBBFnasanexd01anaqu_" MIME-Version: 1.0 Cc: "Sinder, Dan" Subject: Re: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 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: Thu, 15 Nov 2012 23:59:21 -0000 --_000_E23CE350F3C94C4A834B4E7069CA56792229CBBFnasanexd01anaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, Chung Cheung, Thanks again for your feedbacks. I've just submitted an updated version (d= raft-ietf-avt-rtp-evrc-nw-08) based on these feedbacks. Please let me know if you have any = additional suggestions. Thanks, Zheng From: Chung Cheung Chu [mailto:chung.cheung.chu@ericsson.com] Sent: Friday, October 26, 2012 8:53 AM To: Robert Sparks; payload@ietf.org Cc: Fang, Zheng Subject: RE: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 Hi Robert, The suggested text is good. I am okay with it. Thank you. Regards, CC Chung-Cheung Chu 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. ________________________________ From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: October-25-12 5:50 PM To: Chung Cheung Chu Cc: payload@ietf.org; Fang, Zheng Subject: Re: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 The important part is in the restructuring of the sentence. That said, I don't agree that instantaneous is the appropriate word to use = here, and it's usually a warning sign that the text needs clarification whe= n arguing about choosing words that have similar meanings. (Exactly what in= stant is this instantaneous capability describing?) So perhaps this instead: The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the local EVRC-NW wideband/narrowband encoding capability at the time of construction of= an RTP packet to the far end of a communication session. RjS On 10/25/12 4:26 PM, Chung Cheung Chu wrote: Hi Robert, Regarding the comment below relating to a text from Ericsson, I agree that = the proposed change does improve the readability of the sentence. Thank yo= u. However, I notice that the word "current" has been suggested to replace= "instantaneous". The word "Instantaneous" was chosen deliberately to refle= ct explicitly the dynamic nature of the encoding capability in a call sessi= on. Unless there is a strong objection, I would counter-propose to keep th= e use of "instantaneous" instead of "current". - This sentence from Section 6.1 does not parse well: The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the far end of a communication session of the instantaneous local EVRC-NW wideband/ narrowband encoding capability. Would this replacement work? The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the current local EVRC-NW wideband/narrowband encoding capability to the far end of a communication session. Regards, CC Chung-Cheung Chu Ericsson This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. ________________________________ From: payload-bounces@ietf.org [mailto:pay= load-bounces@ietf.org] On Behalf Of Robert Sparks Sent: October-24-12 10:27 AM To: payload@ietf.org Subject: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 Forwarding this to the correct list. RjS -------- Original Message -------- Subject: AD Review: draft-ietf-avt-rtp-evrc-nw-07 Date: Tue, 23 Oct 2012 15:15:16 -0500 From: Robert Sparks To: draft-ietf-avt-rtp-evrc-nw@tools.ietf.org, avt@ietf.org, avtcore-chairs@ietf.or= g CC: Gonzalo Camarillo Summary: The document should be revised before IETF LC. Primary Concern: - This document needs to point to RFC6562, at least in the security considerations section and possibly in section 11. I think the reference needs to be normative. Minor Concerns and Nits: - Section 8 refers backto a "mapping" in Section 4, but it's not clear that there's a mapping there. I suggest adding a note that ToC values are taken from the value column in the table of section 4. - This sentence from Section 6.1 does not parse well: The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the far end of a communication session of the instantaneous local EVRC-NW wideband/ narrowband encoding capability. Would this replacement work? The EVRC-NW interleaved/bundled format defines an encoding capability identification flag, which is used to signal the current local EVRC-NW wideband/narrowband encoding capability to the far end of a communication session. - in Section 9.1.1: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be used. In all other contexts, the file format defined in Section 8 SHALL be used. See Section 6 for details for EVRC-NW. It needs to be clearer that you are talking about Section 7 and 6 of _this_ document. I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX" and add a note to the RFC Editor asking them to replace XXXX with the RFC number of this document. - Section 5 paragraph 1: Suggest s/in a manner consistent with/as specified in/ --_000_E23CE350F3C94C4A834B4E7069CA56792229CBBFnasanexd01anaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert, Chung Cheung,<= o:p>

 <= /p>

Thanks again for your fee= dbacks.  I’ve just submitted an updated version (draft-ietf-avt-rtp-ev= rc-nw-08) based on these feedbacks.  Please let me know if you have any additio= nal suggestions.

 <= /p>

Thanks,=

Zheng

 <= /p>

 <= /p>

From: Chung Cheung Chu [mailto:chung.cheung.chu@ericsso= n.com]
Sent: Friday, October 26, 2012 8:53 AM
To: Robert Sparks; payload@ietf.org
Cc: Fang, Zheng
Subject: RE: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07=

 

Hi Robert,

 

The suggested text is good.&nb= sp; I am okay with it.  Thank you.

Regards,

CC

Chung-Cheung Chu
ECN:     &nbs= p; 810-16713
External: +514-461-6713  = ; or   +514 345-7900 x46489

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

 

 

From:<= /span> Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: October-25-12 5:50 PM
To: Chung Cheung Chu
Cc: payload@ietf.org; Fang, = Zheng
Subject: Re: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07=

The important part is in the restructuring of the se= ntence.

That said, I don't agree that instantaneous is the appropriate word to use = here, and it's usually a warning sign that the text needs clarification whe= n arguing about choosing words that have similar meanings. (Exactly what in= stant is this instantaneous capability describing?)

So perhaps this instead:
     The EVRC-NW interleaved/bundled format defines an = encoding capability
     identification flag, which is used to signal the l= ocal EVRC-NW
     wideband/narrowband encoding capability at the tim= e of construction of an RTP packet
     to the far end of a communication session.

RjS

On 10/25/12 4:26 PM, Chung Cheung Chu wrote:

Hi Robert,

 

Regarding the comment below re= lating to a text from Ericsson, I agree that the proposed change does impro= ve the readability of the sentence.  Thank you.  However,&nb= sp;I notice that the word "current" has been suggested to replace &qu= ot;instantaneous". The word "Instantaneous" was chosen = deliberately to reflect explicitly the dynamic nature of the enco= ding capability in a call session.  Unless there is a strong objection= , I would counter-propose to keep the use of "instantaneous" instead of &q= uot;current".

 

- This sentence from Section 6.1 does not parse well:      The EVRC-NW interleaved/bundled format defines an = encoding capability
     identification flag, which is used to signal the f= ar end of a
     communication session of the instantaneous local E= VRC-NW wideband/
     narrowband encoding capability.
  Would this replacement work?
     The EVRC-NW interleaved/bundled format defines an = encoding capability
     identification flag, which is used to signal the c= urrent local EVRC-NW
     wideband/narrowband encoding capability to the far= end of a
communication
     session.

Regards,

CC

Chung-Cheung Chu 
Ericsson

This Communication = is Confidential.  We only send and receive email on the basis of the t= erms set out at www.ericsson.com/email= _disclaimer.

 

 

From:<= /span> payload-bounces@ietf.org [<= a href=3D"mailto:payload-bounces@ietf.org">mailto:payload-bounces@ietf.org<= /a>] On Behalf Of Robert Sparks
Sent: October-24-12 10:27 AM
To: payload@ietf.org
Subject: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07

Forwarding this to the correct list.

RjS



-------- Original Message --------

Subjec= t:

AD Review: draft-ietf-avt-rtp-evrc-nw-07<= /p>

Date: =

Tue, 23 Oct 2012 15:15:16 -0500

From: =

Robert Sparks <rjsparks@nostrum.com>

To:

draft-ietf-avt-rtp-evrc-nw@tools.ietf.org, avt@ietf.org, avtcore-chairs@ietf.org

CC:

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>

 

Summary: The document should be revised before IETF LC.

 


Primary Concern:


 


- This document needs to point to RFC6562, at least in the security 


considerations section and


possibly in section 11. I think the reference needs to be normative.


 


Minor Concerns and Nits:


 


- Section 8 refers backto a "mapping" in Section 4, but it's=
 not clear 


that there's a mapping there.


I suggest adding a note that ToC values are taken from the value colum=
n 


in the table of section 4.


 


- This sentence from Section 6.1 does not parse well:


     The EVRC-NW interleaved/bundled format define=
s an encoding capability


     identification flag, which is used to signal =
the far end of a


     communication session of the instantaneous lo=
cal EVRC-NW wideband/


     narrowband encoding capability.

  Would this replacement work?


     The EVRC-NW interleaved/bundled format define=
s an encoding capability


     identification flag, which is used to signal =
the current local EVRC-NW


     wideband/narrowband encoding capability to th=
e far end of a 


communication


     session.


 


- in Section 9.1.1:


     When this media type is used in the context o=
f transfer over RTP, the


     RTP payload format specified in Section 4.1 o=
f RFC 3558 [6] SHALL be


     used.  In all other contexts, the file f=
ormat defined in Section 8


     SHALL be used.  See Section 6 for detail=
s for EVRC-NW.


  It needs to be clearer that you are talking about Section 7 and=
 6 of 


_this_ document.


  I suggest saying "Section 8 of RFCXXXX" and "Sec=
tion 6 of RFCXXXX" 


and add a note


  to the RFC Editor asking them to replace XXXX with the RFC numb=
er of 


this document.


 


- Section 5 paragraph 1: Suggest s/in a manner consistent with/as 


specified in/


 

 

 

--_000_E23CE350F3C94C4A834B4E7069CA56792229CBBFnasanexd01anaqu_-- From abegen@cisco.com Mon Nov 19 12:15:35 2012 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 BB9FA21F849F for ; Mon, 19 Nov 2012 12:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYrdRreI-H-o for ; Mon, 19 Nov 2012 12:15:31 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5E65A21F84CF for ; Mon, 19 Nov 2012 12:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=290; q=dns/txt; s=iport; t=1353356131; x=1354565731; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=EaK09QCoUm/KPr2euQAqfQlROdzWm7qK9F1ru6WJBS8=; b=SjERyHOX5jx1qgDvDVy/pvvSIzxWWwigeGqmkL/LhV8QEC8QXBBUfbX/ q3uOElOOUhZ6wEw2wv4Bx7WfUKmXCfhrmQBCOrFN2aecr244Fs4+4Ydcy TRFbhxseZ0QpRf6vGNl2QuDp3toMWw9rmIIel/Zf7+ecm/2L2Di7n4NnE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucKABOTqlCtJV2Y/2dsb2JhbABFgmyCbbx4gQEHgiABBBIBJ1EBKhRCJwQbGodrAQqeboEroAMEkGBhA6RUgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6901"; a="144117764" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 19 Nov 2012 20:15:08 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAJKF8Gv003323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 19 Nov 2012 20:15:08 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Mon, 19 Nov 2012 14:15:08 -0600 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: WGLC for VP8 Payload Thread-Index: AQHNxpKRijb9Uyx1rkaO+XOA7twBQg== Date: Mon, 19 Nov 2012 20:15:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.247.157] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [payload] WGLC for VP8 Payload 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, 19 Nov 2012 20:15:35 -0000 Hi everyone, We had a WGLC for this draft earlier this year and there have been a few updates to the document. I am starting a 2nd WGLC. Please review and comment on the list by December 10th. https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_text=3D1 -acbegen From jmvalin@mozilla.com Thu Nov 22 15:19:43 2012 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 E233521F843D for ; Thu, 22 Nov 2012 15:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlxKIUGeO7CF for ; Thu, 22 Nov 2012 15:19:43 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 26B1521F8432 for ; Thu, 22 Nov 2012 15:19:43 -0800 (PST) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 9DF72F217C for ; Thu, 22 Nov 2012 15:19:41 -0800 (PST) Message-ID: <50AEB30C.60609@mozilla.com> Date: Thu, 22 Nov 2012 18:19:40 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: payload@ietf.org References: <20121122230414.21226.9568.idtracker@ietfa.amsl.com> In-Reply-To: <20121122230414.21226.9568.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 X-Forwarded-Message-Id: <20121122230414.21226.9568.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [payload] Fwd: New Version Notification for draft-spittka-payload-rtp-opus-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: Thu, 22 Nov 2012 23:19:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, See this new version of the Opus payload draft. The main changes are the addition of sender properties (sprop-stereo and sprop-maxcapturerate) and the use of opus/48000/2 in all cases. Cheers, Jean-Marc - -------- Original Message -------- Subject: New Version Notification for draft-spittka-payload-rtp-opus-02.txt Date: Thu, 22 Nov 2012 15:04:14 -0800 From: internet-drafts@ietf.org To: jmvalin@jmvalin.ca CC: koenvos74@gmail.com, jspittka@gmail.com A new version of I-D, draft-spittka-payload-rtp-opus-02.txt has been successfully submitted by Jean-Marc Valin and posted to the IETF repository. Filename: draft-spittka-payload-rtp-opus Revision: 02 Title: RTP Payload Format for Opus Speech and Audio Codec Creation date: 2012-11-22 WG ID: Individual Submission Number of pages: 22 URL: http://www.ietf.org/internet-drafts/draft-spittka-payload-rtp-opus-02.txt Status: http://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus Htmlized: http://tools.ietf.org/html/draft-spittka-payload-rtp-opus-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-spittka-payload-rtp-opus-02 Abstract: This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data that is essential to integrate the codec in the most compatible way. Further, media type registrations are described for the RTP payload format. The IETF Secretariat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQrrMJAAoJEJ6/8sItn9q9SLkIAIfOcRf2meCgTQFBHYef2Qet 8e5L0qVWb9SjTw7z6M0rj4KLPScPM2iukLYLLUepd3oHcGsMN+tDn5GVguvTlAzE nhBEujWlkXzN4ZJTw27CqzI85THOJCZ1jvuyCrlDe7XioX1tnaACcUJy9G/cVQ3+ H5gZyiAdhlEcufyqoM5+ZsbWad6creK0DPD7kg8XQ9/jQlbz3By/AWyeW1vBiDzl o35+/+xBqCisj6KicbeOaUu0VZMOefyuABczM5K4batJXVZuD5mi97myyH4/fOgB s33IS2wu2TPJM0csyEfnBxBNh4TcPWwWPzkNVuVW3tvgdkHbJLemc7YwdQ1VR74= =Yn17 -----END PGP SIGNATURE----- From tlegrand@google.com Tue Nov 27 02:52:18 2012 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 AADD921F84D9 for ; Tue, 27 Nov 2012 02:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SviGGUbqdRE2 for ; Tue, 27 Nov 2012 02:52:17 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F2EAC21F84B5 for ; Tue, 27 Nov 2012 02:52:13 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so4858546vbb.31 for ; Tue, 27 Nov 2012 02:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=PakXh/n27isISkXpiZjyw7fztSw1sJhFTVtr5EDYf54=; b=DlpzA2d/KYXZiuedRuRr6+QUU8yukk+xH6kfOZ/cLpoW1tL+Hm4NQf7TkccpBd630Q nraqIKHUZablihXclfI+UBIZX88mC2knuy6+RudEiUwZ+HhdC/Lvp3o+iimzi83rb9nL 8BbmGrK/7YkYrrG/41gjbXMouR7KZdZWPDwPjfjCdB5YqSIefuKWIfOU+66fi4iLDOLv Y1CHm37Id8QaKiJQM6CYOx5IhuaCckk+dv7lAg2PRTF6PV2RlBVre8vLegwhltXok15N wYz//YGCvgLk0WLTqYg26SH05nOOihAX3BTFsQqtnI7rC49U0iXJBjVOq29vxiXyYLXK 5ouw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:x-gm-message-state; bh=PakXh/n27isISkXpiZjyw7fztSw1sJhFTVtr5EDYf54=; b=LE2q8xZ2uoVtW7+80D5MifvzObBNMF4SvNG84Pw3JBZME1ePZf2hjm+kiGio1CycHe 45GvdcI0uRSqiCFWPp9VcRWB22sUoSw8BWwcaiGMo8KptaKpv9YgvgCqnU5HfFYjq4d8 mcHHbw1gVdPylG1gDAgFAYabzI9eROJ/ELyesr3QpVGOiw1g27TEJW1dtEO1YG8k2Q3r sg2o2SHsQ3a+jCjG6BlAE8uczeXIfJZ56AZhcfBnH77aQ/PvEsSczJDLqdD+yDk9hif4 6G3gZRG+7Iq75XszRAKkFF5FrszX/a+p4VautidopHriIwrPPc0fmy6IckivVgpIb7w0 DrQA== MIME-Version: 1.0 Received: by 10.52.22.240 with SMTP id h16mr20876229vdf.82.1354013533200; Tue, 27 Nov 2012 02:52:13 -0800 (PST) Sender: tlegrand@google.com Received: by 10.220.116.133 with HTTP; Tue, 27 Nov 2012 02:52:13 -0800 (PST) Date: Tue, 27 Nov 2012 11:52:13 +0100 X-Google-Sender-Auth: SN3REPqeljfYoPmazYZkOd5Z7-U Message-ID: From: Tina le Grand To: payload@ietf.org Content-Type: multipart/alternative; boundary=20cf3079bb0aaae09904cf77d70a X-Gm-Message-State: ALoCoQmdQ6HKJZ/Dp6yUdMWxoFQV6kBJq5uDmEFK5rqhri5EFW6O4SCqnDMUPlc9O8GxYdBxaQR0st0L0VMqiKFrb8JgT2g+mtNj6th+TDefkPLqw24rRJe0WMQbMBdi0SNG4XqPFNnTBrDDrVJ2HW0pdnil0PTj5tXlZhh2aPBsTSp1djEbnVjHtrz0bgSri/FUWcC83YbE Subject: [payload] Review of draft-spittka-payload-rtp-opus-02 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, 27 Nov 2012 10:52:18 -0000 --20cf3079bb0aaae09904cf77d70a Content-Type: text/plain; charset=ISO-8859-1 Hi, I was reading through the Opus RTP draft, and I have a few comments I thought I'd share with you. - Section 1, page 3, section 1, line 3: "is is" -> "it is" - Section 2, page 4, abbreviation list: - PSTN never used in the document, can be removed - Add VBR - Variable bitrate - Add CBR - Constant bitrate - Add DTX - Discontinuous transmission - Add FEC - Forward error correction - Section 4.1, page 9, Table 2: The name of the table is odd. The table is already described in the text on the previous page, and the description below the table isn't needed. - Section 4.2, page 10, Table 3: - Again, the name of table is difficult to read. Consider moving the information to the section above instead. - This isn't really correct: "fs specifies the audio sampling frequency in Herz (Hz)". It's the abbreviations for audio bandwidth that is used in the table. - You might want to add that the duration is in milliseconds. - In the previous section it says "only one packet output from the Opus encoder MUST be used as a payload", but the last sentence in the table description talks about multiple frames in one packet. - Section 6.1, page 14, if the receiver says useinbandfec=0, is it okay for the sender to send FEC anyway? It doesn't explicitly say in the text. - Section 6.2, page 16: it isn't described in the bullet list where to include the optional parameter maxplaybackrate. - Section 6.2.1, page 18, second bullet: "sprop-maxcaptureerate" misspelled twice, should be "sprop-maxcapturerate". Thanks, Tina le Grand. --20cf3079bb0aaae09904cf77d70a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
H= i,

I was reading through the Opus RTP draft, and I have = a few comments I thought I'd share with you.
  • Section=A01, p= age 3, section 1, line 3: "is is" -> "it is"
  • Section=A02, page 4, abbreviation list:=A0
    • PSTN never used = in the document, can be removed
    • Add VBR - Variable bitrate
    • = Add CBR - Constant bitrate
    • Add DTX - Discontinuous transmission
    • Add FEC - Forward error correction
  • Section 4.1, page 9, Ta= ble 2: The name of the table is odd. The table is already described in the = text on the previous page, and the description below the table isn't ne= eded.
  • Section 4.2, page 10, Table 3:=A0
    • Again, the name of table = is difficult to read. Consider moving the information to the section above = instead.
    • This isn't really correct: "fs specifies the audi= o sampling frequency in Herz (Hz)". It's the abbreviations for aud= io bandwidth that is used in the table.
    • You might want to add that the duration is in milliseconds.
    • In = the previous section it says "only one packet output from the Opus enc= oder MUST be used as a payload", but the last sentence in the table de= scription talks about multiple frames in one packet.
  • Section 6.1, page 14, if the receiver says useinbandfec= =3D0, is it okay for the sender to send FEC anyway? It doesn't=A0explic= itly=A0say in the text.
  • Section 6.2, page 16: it isn't=A0descri= bed in the=A0bullet=A0list=A0where to include the optional parameter maxpla= ybackrate.
  • Section 6.2.1, page 18, second bullet: "sprop-maxcaptureerate" misspelled twice, should be =A0"= ;sprop-maxcapturerate".
=
Thanks,
Tina le Grand.
--20cf3079bb0aaae09904cf77d70a-- From rjsparks@nostrum.com Tue Nov 27 06:43:22 2012 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 7ADE521F855A for ; Tue, 27 Nov 2012 06:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo7hNqp5LwIY for ; Tue, 27 Nov 2012 06:43:19 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCDE21F8559 for ; Tue, 27 Nov 2012 06:43:19 -0800 (PST) Received: from unnumerable.local (pool-173-71-45-100.dllstx.fios.verizon.net [173.71.45.100]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAREhGjo066092 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 08:43:16 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50B4D183.8060700@nostrum.com> Date: Tue, 27 Nov 2012 08:43:15 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Fang, Zheng" References: <5086FAD4.8070301@nostrum.com> <5087FABC.6010902@nostrum.com> <26490BBDEEACA14EA1A0070367B3ADBDC42E2FBFA7@EUSAACMS0702.eamcs.ericsson.se> <5089B412.9010505@nostrum.com> <26490BBDEEACA14EA1A0070367B3ADBDC42E38C6F6@EUSAACMS0702.eamcs.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040401030506010804000605" Received-SPF: pass (nostrum.com: 173.71.45.100 is authenticated by a trusted mechanism) Cc: "Sinder, Dan" , "payload@ietf.org" Subject: Re: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 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, 27 Nov 2012 14:43:22 -0000 This is a multi-part message in MIME format. --------------040401030506010804000605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've requested IETF LC for this document - watch for its announcement soon. RjS On 11/15/12 5:59 PM, Fang, Zheng wrote: > > Hi Robert, Chung Cheung, > > Thanks again for your feedbacks. I've just submitted an updated > version (draft-ietf-avt-rtp-evrc-nw-08 > ) based on > these feedbacks. Please let me know if you have any additional > suggestions. > > Thanks, > > Zheng > > *From:*Chung Cheung Chu [mailto:chung.cheung.chu@ericsson.com] > *Sent:* Friday, October 26, 2012 8:53 AM > *To:* Robert Sparks; payload@ietf.org > *Cc:* Fang, Zheng > *Subject:* RE: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 > > Hi Robert, > > The suggested text is good. I am okay with it. Thank you. > > Regards, > > CC > > Chung-Cheung Chu > 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 > ./ > > ------------------------------------------------------------------------ > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* October-25-12 5:50 PM > *To:* Chung Cheung Chu > *Cc:* payload@ietf.org ; Fang, Zheng > *Subject:* Re: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 > > The important part is in the restructuring of the sentence. > > That said, I don't agree that instantaneous is the appropriate word to > use here, and it's usually a warning sign that the text needs > clarification when arguing about choosing words that have similar > meanings. (Exactly what instant is this instantaneous capability > describing?) > > So perhaps this instead: > The EVRC-NW interleaved/bundled format defines an encoding capability > identification flag, which is used to signal the local EVRC-NW > wideband/narrowband encoding capability at the time of > construction of an RTP packet > to the far end of a communication session. > > RjS > > On 10/25/12 4:26 PM, Chung Cheung Chu wrote: > > Hi Robert, > > Regarding the comment below relating to a text from Ericsson, I > agree that the proposed change does improve the readability of the > sentence. Thank you. However, I notice that the word "current" > has been suggested to replace "instantaneous". The word > "Instantaneous" was chosen deliberately to reflect explicitly the > dynamic nature of the encoding capability in a call session. > Unless there is a strong objection, I would counter-propose to > keep the use of "instantaneous" instead of "current". > > - This sentence from Section 6.1 does not parse well: > The EVRC-NW interleaved/bundled format defines an encoding > capability > identification flag, which is used to signal the far end of a > communication session of the instantaneous local EVRC-NW > wideband/ > narrowband encoding capability. > Would this replacement work? > The EVRC-NW interleaved/bundled format defines an encoding > capability > identification flag, which is used to signal the current > local EVRC-NW > wideband/narrowband encoding capability to the far end of a > communication > session. > > Regards, > > CC > > Chung-Cheung Chu > Ericsson > > /This Communication is Confidential. We only send and receive > email on the basis of the terms set out at > www.ericsson.com/email_disclaimer > ./ > > ------------------------------------------------------------------------ > > *From:*payload-bounces@ietf.org > [mailto:payload-bounces@ietf.org] *On Behalf Of *Robert Sparks > *Sent:* October-24-12 10:27 AM > *To:* payload@ietf.org > *Subject:* [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07 > > Forwarding this to the correct list. > > RjS > > > > -------- Original Message -------- > > *Subject: * > > > > AD Review: draft-ietf-avt-rtp-evrc-nw-07 > > *Date: * > > > > Tue, 23 Oct 2012 15:15:16 -0500 > > *From: * > > > > Robert Sparks > > *To: * > > > > draft-ietf-avt-rtp-evrc-nw@tools.ietf.org > , avt@ietf.org > , avtcore-chairs@ietf.org > > > *CC: * > > > > Gonzalo Camarillo > > > Summary: The document should be revised before IETF LC. > > > > Primary Concern: > > > > - This document needs to point to RFC6562, at least in the security > > considerations section and > > possibly in section 11. I think the reference needs to be normative. > > > > Minor Concerns and Nits: > > > > - Section 8 refers backto a "mapping" in Section 4, but it's not clear > > that there's a mapping there. > > I suggest adding a note that ToC values are taken from the value column > > in the table of section 4. > > > > - This sentence from Section 6.1 does not parse well: > > The EVRC-NW interleaved/bundled format defines an encoding capability > > identification flag, which is used to signal the far end of a > > communication session of the instantaneous local EVRC-NW wideband/ > > narrowband encoding capability. > > Would this replacement work? > > The EVRC-NW interleaved/bundled format defines an encoding capability > > identification flag, which is used to signal the current local EVRC-NW > > wideband/narrowband encoding capability to the far end of a > > communication > > session. > > > > - in Section 9.1.1: > > When this media type is used in the context of transfer over RTP, the > > RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be > > used. In all other contexts, the file format defined in Section 8 > > SHALL be used. See Section 6 for details for EVRC-NW. > > It needs to be clearer that you are talking about Section 7 and 6 of > > _this_ document. > > I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX" > > and add a note > > to the RFC Editor asking them to replace XXXX with the RFC number of > > this document. > > > > - Section 5 paragraph 1: Suggest s/in a manner consistent with/as > > specified in/ > --------------040401030506010804000605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I've requested IETF LC for this document - watch for its announcement soon.

RjS

On 11/15/12 5:59 PM, Fang, Zheng wrote:

Hi Robert, Chung Cheung,

 

Thanks again for your feedbacks.  I’ve just submitted an updated version (draft-ietf-avt-rtp-evrc-nw-08) based on these feedbacks.  Please let me know if you have any additional suggestions.

 

Thanks,

Zheng

 

 

From: Chung Cheung Chu [mailto:chung.cheung.chu@ericsson.com]
Sent: Friday, October 26, 2012 8:53 AM
To: Robert Sparks; payload@ietf.org
Cc: Fang, Zheng
Subject: RE: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07

 

Hi Robert,

 

The suggested text is good.  I am okay with it.  Thank you.

Regards,

CC

Chung-Cheung Chu
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.

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: October-25-12 5:50 PM
To: Chung Cheung Chu
Cc: payload@ietf.org; Fang, Zheng
Subject: Re: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07

The important part is in the restructuring of the sentence.

That said, I don't agree that instantaneous is the appropriate word to use here, and it's usually a warning sign that the text needs clarification when arguing about choosing words that have similar meanings. (Exactly what instant is this instantaneous capability describing?)

So perhaps this instead:
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the local EVRC-NW
     wideband/narrowband encoding capability at the time of construction of an RTP packet
     to the far end of a communication session.

RjS

On 10/25/12 4:26 PM, Chung Cheung Chu wrote:

Hi Robert,

 

Regarding the comment below relating to a text from Ericsson, I agree that the proposed change does improve the readability of the sentence.  Thank you.  However, I notice that the word "current" has been suggested to replace "instantaneous". The word "Instantaneous" was chosen deliberately to reflect explicitly the dynamic nature of the encoding capability in a call session.  Unless there is a strong objection, I would counter-propose to keep the use of "instantaneous" instead of "current".

 

- This sentence from Section 6.1 does not parse well:
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the far end of a
     communication session of the instantaneous local EVRC-NW wideband/
     narrowband encoding capability.
  Would this replacement work?
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the current local EVRC-NW
     wideband/narrowband encoding capability to the far end of a
communication
     session.

Regards,

CC

Chung-Cheung Chu 
Ericsson

This Communication is Confidential.  We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer.

 

 

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: October-24-12 10:27 AM
To: payload@ietf.org
Subject: [payload] Fwd: AD Review: draft-ietf-avt-rtp-evrc-nw-07

Forwarding this to the correct list.

RjS



-------- Original Message --------

Subject:

AD Review: draft-ietf-avt-rtp-evrc-nw-07

Date:

Tue, 23 Oct 2012 15:15:16 -0500

From:

Robert Sparks <rjsparks@nostrum.com>

To:

draft-ietf-avt-rtp-evrc-nw@tools.ietf.org, avt@ietf.org, avtcore-chairs@ietf.org

CC:

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>

 

Summary: The document should be revised before IETF LC.
 
Primary Concern:
 
- This document needs to point to RFC6562, at least in the security 
considerations section and
possibly in section 11. I think the reference needs to be normative.
 
Minor Concerns and Nits:
 
- Section 8 refers backto a "mapping" in Section 4, but it's not clear 
that there's a mapping there.
I suggest adding a note that ToC values are taken from the value column 
in the table of section 4.
 
- This sentence from Section 6.1 does not parse well:
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the far end of a
     communication session of the instantaneous local EVRC-NW wideband/
     narrowband encoding capability.
  Would this replacement work?
     The EVRC-NW interleaved/bundled format defines an encoding capability
     identification flag, which is used to signal the current local EVRC-NW
     wideband/narrowband encoding capability to the far end of a 
communication
     session.
 
- in Section 9.1.1:
     When this media type is used in the context of transfer over RTP, the
     RTP payload format specified in Section 4.1 of RFC 3558 [6] SHALL be
     used.  In all other contexts, the file format defined in Section 8
     SHALL be used.  See Section 6 for details for EVRC-NW.
  It needs to be clearer that you are talking about Section 7 and 6 of 
_this_ document.
  I suggest saying "Section 8 of RFCXXXX" and "Section 6 of RFCXXXX" 
and add a note
  to the RFC Editor asking them to replace XXXX with the RFC number of 
this document.
 
- Section 5 paragraph 1: Suggest s/in a manner consistent with/as 
specified in/

 

 

 


--------------040401030506010804000605-- From iesg-secretary@ietf.org Tue Nov 27 09:37:29 2012 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 5CE1621F863C; Tue, 27 Nov 2012 09:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBYJite3HaPD; Tue, 27 Nov 2012 09:37:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D696021F84BA; Tue, 27 Nov 2012 09:37:28 -0800 (PST) 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: 4.36 Message-ID: <20121127173728.21259.54604.idtracker@ietfa.amsl.com> Date: Tue, 27 Nov 2012 09:37:28 -0800 Cc: payload@ietf.org Subject: [payload] Last Call: (RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)) 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: Tue, 27 Nov 2012 17:37:29 -0000 The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)' as 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 2012-12-11. 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 real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avt-rtp-evrc-nw/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avt-rtp-evrc-nw/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1766/ From Lindsay@worldcastsystems.com Wed Nov 28 10:04:05 2012 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 8E91D21F87CB for ; Wed, 28 Nov 2012 10:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp81pXqPbbay for ; Wed, 28 Nov 2012 10:04:04 -0800 (PST) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id 3B26921F885C for ; Wed, 28 Nov 2012 10:04:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDCD92.BF7C8307" Date: Wed, 28 Nov 2012 18:04:02 -0000 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02CD8C8D@APTSBS.apt.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-lindsay-payload-rtp-aptx-00 Thread-Index: Ac3Nkr9ePmt7e0nRSNOosJVmf2lVIw== From: "John Lindsay" To: Cc: Foerster@worldcastsystems.com Subject: [payload] draft-lindsay-payload-rtp-aptx-00 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, 28 Nov 2012 18:04:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDCD92.BF7C8307 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 We have submitted a new draft on RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs to the payloads WG for review. =20 http://datatracker.ietf.org/doc/draft-lindsay-payload-rtp-aptx/ =20 Technically the document is identical to the previous expired draft RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs=20 draft-rea-payload-rtp-aptx-02. (This doc expired Sept 2012) =20 The previous drafts had numerous comments and existed in various revisions since the original draft in September 2007 by Greg Massey. =20 We would hope to push the doc forward for WGLC as soon as is practically possible and hence welcome all comments. =20 Regards =20 John Lindsay ------_=_NextPart_001_01CDCD92.BF7C8307 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

We have submitted a = new draft on RTP Payload Format = for Standard apt-X and Enhanced apt-X Codecs to the payloads WG for = review.

 

http://datatracker.ietf.org/doc/draft-lindsay-= payload-rtp-aptx/

 

Technically the document is = identical to the previous expired draft RTP Payload Format for Standard = apt-X and Enhanced apt-X Codecs

draft-rea-payload-rtp-aptx-02. (This doc = expired Sept 2012)

 

The previous drafts = had numerous comments and existed in various revisions since the = original draft in September 2007 by Greg Massey.

 

We would hope to push = the doc forward for WGLC as soon as is practically possible and hence = welcome all comments.

 

Regards

 

John = Lindsay

------_=_NextPart_001_01CDCD92.BF7C8307--