[payload] Sending draft-ietf-avt-rtp-isac-03 - for publication - need a new revision
"Roni Even" <ron.even.tlv@gmail.com> Thu, 07 February 2013 12:29 UTC
Return-Path: <ron.even.tlv@gmail.com>
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 B67C821F8906 for <payload@ietfa.amsl.com>; Thu, 7 Feb 2013 04:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.292
X-Spam-Level:
X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, 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 vCaLEOTxRm1Z for <payload@ietfa.amsl.com>; Thu, 7 Feb 2013 04:29:40 -0800 (PST)
Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 64A2221F857C for <payload@ietf.org>; Thu, 7 Feb 2013 04:29:39 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id b15so1244086eek.25 for <payload@ietf.org>; Thu, 07 Feb 2013 04:29:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=zOcWmVkH6zkybT0z+l/lHOip5xCep6sutSKtY90hZn8=; b=x0zkQC4wP8aTHJhztMUpLGQpeqoCAVC2Eh+PKJTKbMEjGOqAeRdFHL5R/AJWAFOucw bxmkKURDJz2wkyVAEDulw0yfokoCbrhXb4SHGZQDnEJfJZ3qU/Ooxg10MI/HkVysIy9B 2ixoFAeGa/inpQE3xgf5KcN9eygtIDanyKvZa9e+aEM0WTy4YijhQCl1a5CTTW6YMuHT vDkNVm230wqNQ9pATORG6fNEvV2wIX5FCs/4BeSmA8hbdgxabcnDLGmktFmmBn5KvBxb 3QqMyclIosHVu2xJC5GWOCzbHTJ+ekzymiqcTETe2Mu0zLyYYLT+7r3yuEsCPxk99/aI bEZQ==
X-Received: by 10.14.174.73 with SMTP id w49mr3785840eel.17.1360240178445; Thu, 07 Feb 2013 04:29:38 -0800 (PST)
Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id q42sm32570998eem.14.2013.02.07.04.29.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Feb 2013 04:29:35 -0800 (PST)
From: Roni Even <ron.even.tlv@gmail.com>
To: payload@ietf.org
Date: Thu, 07 Feb 2013 14:26:42 +0200
Message-ID: <055e01ce052e$6546b410$2fd41c30$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_055F_01CE053F.28D24330"
X-Mailer: Microsoft Outlook 14.0
thread-index: Ac4FLcN977z8fDjfQuma7pco6xlvZw==
Content-Language: en-us
Cc: "'Pascal Huart (phuart)'" <phuart@cisco.com>
Subject: [payload] Sending draft-ietf-avt-rtp-isac-03 - for publication - need a new revision
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2013 12:29:43 -0000
Hi, While doing the write-up the document had an error when running idnits Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) Please fix the reference and you can also fix the nits from my previous mail and the one from Colin (all are below). I will send it to publication when the idnit error is fixed Thanks Roni Even Payload co-chair From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 30 January, 2013 11:46 AM To: 'payload@ietf.org' Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-isac-02 - review of 03 Hi, As individual Thanks for the update, it looks good now. One nit In section 3.2 second bullet "The payload header is generated (described in Section 3.2)", think it should be 3.1 Now as WG chair, I will prepare the write-up and send it to publication. Please note the nit and the one from Collin and fix it after the IETF LC Roni From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 03 January, 2013 6:52 PM To: 'Harald Alvestrand'; 'payload@ietf.org' Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-isac-02 Hi Harald, No problem, no hurry from my side. Comments inline Roni From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: 03 January, 2013 5:41 PM To: payload@ietf.org Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-isac-02 We'll get you an updated draft addressing these ASAP (but it's not the most urgent thing, so it may take some days). On 12/26/2012 01:42 PM, Roni Even wrote: Hi, I reviewed the draft and have some questions and comments 1. In section 2 there is a mention of target bit rate. It is not clear how is it calculated and what does average during peaks mean? How is this parameter related to the ibitrate parameter defined in the IANA section. 2. In section 2 "The available bandwidth is continuously estimated at the receiving iSAC and signaled in-band in the iSAC bit stream". How does it work? I'm not sure that needs to be specified in the payload format document. There are a number of things that are not specified; those who want that information can go check out the source. RE: I was asking about the signaling in-band by the receiver. What in-band means here? Since this is from receiver to sender does it mean that it is only relevant for bi-direction communication? 3. In section 3 second paragraph please discuss using dynamic payload type number maybe add "The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profiles in use currently mandate binding the payload type dynamically for this payload format." Nice to be explicit. I thought this was what we assumed by default. 4. In section 3.2 what are the BEI and FL values and how many bits each one uses. 5. In section 3.3 what is bandwidth probe, how does it work. Is it specified elsewhere, in which case provide a reference. 6. In section 3.3 "The user can choose to lower the maximum allowed payload length ". Who is the user(sender / receiver) and how is it done. 7. In section 3.4 how does a receiver know if he receives a wideband or super-wideband payload in order to decode correctly. 8. In section 3.5 "signaled inband". What is inband, any reference? 9. Looking at figure 6 I am not clear from the text how does the receiver know that there is padding and not payload? The decoding process will decode until it's decoded all the samples it wants. What follows is padding. Same process as section 3.3. 10. In section 4 change the beginning to "This RTP payload format is identified using the media type audio/isac, which is registered in accordance with [RFC4855 <http://tools.ietf.org/html/rfc4855> ] and uses the template of [RFC4288 <http://tools.ietf.org/html/rfc4288> ]." 11. Please verify that the registration follows the template. Currently the order is not correct and there are missing subscetions. Will fix. 12. Since ibitrate and maxbitrate are optional parameters what are the default values if not specified. I saw 20000 for ibitrate for channel adaptive mode in section 2. These are the requests from the recipient. In their absence, the sender will send what the sender wants to send. RE: Suggest to explain it. 13. What are the units for ibitrate and maxbitrate I've assumed bits per second, but I'll check. RE: the text should specify 14. In section 4 the change controller should be the payload working group. 15. In section 5 what is the clock rate in rtpmap. 16. Can you switch from wideband to super wideband without any signaling using the same payload type number. Can you use a 32000 clock rate also for the wideband. Section 3: 3. RTP Payload Format The iSAC codec in wideband mode uses a sampling rate clock of 16 kHz, so the RTP timestamp MUST be in units of 1/16000 of a second. In super-wideband mode, the iSAC codec uses a sampling rate clock of 32 kHz, so the RTP timestamp MUST be in units of 1/32000 of a second. Is this sufficient? RE: This is OK, so you need to specify both wide band and super wideband in the offer to allow the receiver to choose the one he wants. Maybe have in section 5 an example such an offer. 17. The document should have a congestion control section see http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-02 18. The security section need to be expanded see for example section 10 of RFC 5404. OK. Thanks Roni Even From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 13 December, 2012 8:35 AM To: 'payload@ietf.org' Cc: 'draft-ietf-avt-rtp-isac@tools.ietf.org' Subject: WGLC on draft-ietf-avt-rtp-isac-02 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avt-rtp-isac-02 , RTP Payload Format for the iSAC Codec The WGLC will end on January 2nd, 2013 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf-avt-rtp-isac-02? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publication. Thanks Roni Even Payload co-chair _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload
- [payload] Sending draft-ietf-avt-rtp-isac-03 - fo… Roni Even
- Re: [payload] Sending draft-ietf-avt-rtp-isac-03 … Harald Alvestrand