From kevin.gross@avanw.com Wed Feb 6 16:56:46 2013 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 35D4521F8488 for ; Wed, 6 Feb 2013 16:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 lg+gSMdGdt6z for ; Wed, 6 Feb 2013 16:56:44 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 524FD21F8499 for ; Wed, 6 Feb 2013 16:56:40 -0800 (PST) Received: (qmail 13288 invoked by uid 0); 7 Feb 2013 00:56:18 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 7 Feb 2013 00:56:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=d7vuWhBkOn6BN6yBch0dHdlFI0pxAMqLMveAsJjGR7w=; b=jAAL2hJVyI5VTODaMPhkwnQahEs2eAXJ5G/JNgYpeeI/SaF+HdJAeATAyefJMkARBmGw/0L7II+bQRya2FIBU5jC2u48IQWRM597csSj8KXOmWipjZQ5H+2I8O5bMZdD; Received: from [209.85.210.170] (port=56458 helo=mail-ia0-f170.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1U3Fmk-00046m-6Z for payload@ietf.org; Wed, 06 Feb 2013 17:56:18 -0700 Received: by mail-ia0-f170.google.com with SMTP id k20so2398429iak.1 for ; Wed, 06 Feb 2013 16:56:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.43.117.136 with SMTP id fm8mr21805806icc.33.1360198577226; Wed, 06 Feb 2013 16:56:17 -0800 (PST) Received: by 10.50.183.163 with HTTP; Wed, 6 Feb 2013 16:56:16 -0800 (PST) In-Reply-To: <8C4E0C2409735E4FBC22D754A238F94D02D580CF@APTSBS.apt.local> References: <8C4E0C2409735E4FBC22D754A238F94D02D580CF@APTSBS.apt.local> Date: Wed, 6 Feb 2013 17:56:16 -0700 Message-ID: From: Kevin Gross To: John Lindsay Content-Type: multipart/alternative; boundary=bcaec51824880504b504d517e964 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.210.170 authed with kevin.gross@avanw.com} Cc: Foerster@worldcastsystems.com, payload@ietf.org Subject: Re: [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: Thu, 07 Feb 2013 00:56:46 -0000 --bcaec51824880504b504d517e964 Content-Type: text/plain; charset=ISO-8859-1 I support adoption. This codec has been around a long time and currently has good traction in broadcast and in consumer Bluetooth audio devices. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Thu, Jan 31, 2013 at 7:35 AM, John Lindsay wrote: > Hi > > We would like to ask for the doc "draft-lindsay-payload-rtp-aptx-00" to > be considered by the working group for adoption as a proposed standard. > > The document has been in existence since its first draft in April 2008 > and has been updated by various members of APT following comments within > the workgroup over the past 5 years and is now implemented by a number > of Audio Codec manufactures mainly in the Broadcast sphere. > > A brief history of the doc is as follows. > > draft-gmassey-avt-rtp-aptx-01, (Submitted 15th Apr 2008), (Expired 17th > October 2008). > draft-trainor-avt-rtp-aptx-00, (Submitted 22nd December 2009), (Expired > 25th June 2010) > draft-rea-payload-rtp-aptx-00 (Submitted 18th April 2011) > draft-rea-payload-rtp-aptx-01 (Submitted 7th October 2011) > draft-rea-payload-rtp-aptx-02 (Submitted 7th March 2011), (Expired 7th > September 2012) > draft-lindsay-payload-rtp-aptx-00 (Submitted 28th November 2012) > > The RFC was generated originally in response to our work with the EBU > (European Broadcasting Union) N/ACIP (Audio Contribution over IP) > workgroups and their attempts to standardise transmission of packetized > audio data over RTP to ensure compatibility between Audio Codec > manufacturers. > No standard method of packetizing the apt-X and Enhanced apt-X algorithm > was available and the doc seeks to address this along with the > appropriate SDP messages to facilitate compatible call signalling. > > http://www.ebu-acip.org/Main_Page > > Whilst the documents have generated a number of responses and driven a > number of the N/ACIP members and interested parties towards both the > payload and AVT workgroups, the number of interested parties is always > going to be limited as there are only a finite number of codec > manufacturers and hence N/ACIP members. > > As you can see from the above we hope the doc has reached a level of > maturity required for WG adoption. > > Many thanks for your time. > > Regards > > John Lindsay > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --bcaec51824880504b504d517e964 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support adoption. This codec has been around a long time and currently ha= s good traction in broadcast and in consumer Bluetooth audio devices.
<= br clear=3D"all">
Kevin Gross
+1-303-447-0517
Media N= etwork Consultant
AVA Networks -=A0w= ww.AVAnw.com,=A0www.X= 192.org


On Thu, Jan 31, 2013 at 7:35 AM, John Li= ndsay <Lindsay@worldcastsystems.com> wrote:
Hi

We would like to ask for the doc "draft-lindsay-payload-rtp-aptx-00&qu= ot; to
be considered by the working group for adoption as a proposed standard.

The document has been in existence since its first draft in April 2008
and has been updated by various members of APT following comments within the workgroup over the past 5 years and is now implemented by a number
of Audio Codec manufactures mainly in the Broadcast sphere.

A brief history of the doc is as follows.

draft-gmassey-avt-rtp-aptx-01, (Submitted 15th Apr 2008), (Expired 17th
October 2008).
draft-trainor-avt-rtp-aptx-00, (Submitted 22nd December 2009), (Expired
25th June 2010)
draft-rea-payload-rtp-aptx-00 (Submitted =A018th April 2011)
draft-rea-payload-rtp-aptx-01 (Submitted =A07th October 2011)
draft-rea-payload-rtp-aptx-02 (Submitted =A07th March 2011), (Expired 7th September 2012)
draft-lindsay-payload-rtp-aptx-00 (Submitted 28th November 2012)

The RFC was generated originally in response to our work with the EBU
(European Broadcasting Union) N/ACIP (Audio Contribution over IP)
workgroups and their attempts to standardise transmission of packetized
audio data over RTP to ensure compatibility between Audio Codec
manufacturers.
No standard method of packetizing the apt-X and Enhanced apt-X algorithm was available and the doc seeks to address this along with the
appropriate SDP messages to facilitate compatible call signalling.

http://www.= ebu-acip.org/Main_Page

Whilst the documents have generated a number of responses and driven a
number of the N/ACIP members and interested parties towards both the
payload and AVT workgroups, the number of interested parties is always
going to be limited as there are only a finite number of codec
manufacturers and hence N/ACIP members.

As you can see from the above we hope the doc has reached a level of
maturity required for WG adoption.

Many thanks for your time.

Regards

John Lindsay

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload

--bcaec51824880504b504d517e964-- From ron.even.tlv@gmail.com Thu Feb 7 04:29:43 2013 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 B67C821F8906 for ; 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 ; 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 ; Thu, 7 Feb 2013 04:29:39 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id b15so1244086eek.25 for ; 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" To: Date: Thu, 7 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\)'" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 12:29:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_055F_01CE053F.28D24330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ] and uses the template of [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 ------=_NextPart_000_055F_01CE053F.28D24330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

 

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] and uses the  template of [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

<= p class=3DMsoListParagraph = style=3D'text-indent:-.25in;page-break-before:always;mso-list:l0 level1 = lfo2'>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://too=
ls.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.o= rg/mailman/listinfo/payload

 

------=_NextPart_000_055F_01CE053F.28D24330-- From internet-drafts@ietf.org Fri Feb 8 08:43:55 2013 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 6194021F8815; Fri, 8 Feb 2013 08:43:55 -0800 (PST) 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=[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 ZEYQK-k2dOLU; Fri, 8 Feb 2013 08:43:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8DE21F8901; Fri, 8 Feb 2013 08:43:54 -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.37 Message-ID: <20130208164354.15132.1633.idtracker@ietfa.amsl.com> Date: Fri, 08 Feb 2013 08:43:54 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-isac-04.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: Fri, 08 Feb 2013 16:43:55 -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 the iSAC Codec Author(s) : Tina le Grand Paul E. Jones Pascal Huart Turaj Zakizadeh Shabestary Harald Alvestrand Filename : draft-ietf-avt-rtp-isac-04.txt Pages : 16 Date : 2013-02-08 Abstract: iSAC is a proprietary wideband speech and audio codec developed by Global IP Solutions (now part of Google), suitable for use in Voice over IP applications. This document describes the payload format for iSAC generated bit streams within a Real-Time Protocol (RTP) packet. Also included here are the necessary details for the use of iSAC with the Session Description Protocol (SDP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-isac There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avt-rtp-isac-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-isac-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From harald@alvestrand.no Fri Feb 8 08:44:38 2013 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 43A0C21F8A8F for ; Fri, 8 Feb 2013 08:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.093 X-Spam-Level: X-Spam-Status: No, score=-110.093 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8, 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 LOb5LFWvxyNK for ; Fri, 8 Feb 2013 08:44:35 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CD16721F8A94 for ; Fri, 8 Feb 2013 08:44:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AAA2639E125; Fri, 8 Feb 2013 17:44:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mvGJBtVGrzk; Fri, 8 Feb 2013 17:44:29 +0100 (CET) Received: from [IPv6:2620:0:1004:b:51b1:9f8:cce8:316f] (unknown [IPv6:2620:0:1004:b:51b1:9f8:cce8:316f]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DDBFC39E197; Fri, 8 Feb 2013 17:44:28 +0100 (CET) Message-ID: <51152B6B.7060603@alvestrand.no> Date: Fri, 08 Feb 2013 17:44:27 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roni Even References: <055e01ce052e$6546b410$2fd41c30$@gmail.com> In-Reply-To: <055e01ce052e$6546b410$2fd41c30$@gmail.com> Content-Type: multipart/alternative; boundary="------------080805000503060408040200" Cc: "'Pascal Huart \(phuart\)'" , payload@ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 16:44:38 -0000 This is a multi-part message in MIME format. --------------080805000503060408040200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/07/2013 01:26 PM, Roni Even wrote: > > 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 > -04 is now posted. Hope I got them all. > 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 ] and > uses the template of [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 > seehttp://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 onhttp://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 > --------------080805000503060408040200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/07/2013 01:26 PM, Roni Even wrote:

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


-04 is now posted. Hope I got them all.

 

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] and uses the  template of [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

 


--------------080805000503060408040200-- From ron.even.tlv@gmail.com Fri Feb 8 09:55:53 2013 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 E865421F8A0C; Fri, 8 Feb 2013 09:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Z7YDVl84YOi0; Fri, 8 Feb 2013 09:55:52 -0800 (PST) Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com [209.85.215.177]) by ietfa.amsl.com (Postfix) with ESMTP id A10EE21F859C; Fri, 8 Feb 2013 09:55:51 -0800 (PST) Received: by mail-ea0-f177.google.com with SMTP id n13so1686380eaa.36 for ; Fri, 08 Feb 2013 09:55:50 -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=y44mlcXlsy3L2QsmnIb+N8wnRVSwgxYNFU42xMGP8Mk=; b=hcL1kyIQaxOG1u1R05BgwLwoNkVQuTciheVBW2L6h4y03CiIqp3lNOh+ReqT90IKvE lSOtEZUhbiLUZFOQm9fSlUYe1x7r2ADFTqceOV7jzhKaTTB5lzNn0PPwoa+seNBOHcI0 PwwiGKakxsLykmOl66404pezKXA04nRjz7b2pF1HibWFifpGg9bRzUeGZ+hpxmsXOm/K nkklh+Mnc703tHD4cZ0t1gLX8nmD94Tb4uk3akeMjPnZqDqqXKVpKp0ox86jkt8hshq7 wk8byCb/XROh1klXqU0j0CpAuzCqyGnnE7b/Ykd34YSarrULIxvZAMAwPwgEKQ3tEaBS i4cA== X-Received: by 10.14.176.133 with SMTP id b5mr18242565eem.37.1360346150745; Fri, 08 Feb 2013 09:55:50 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id 3sm48503133eej.6.2013.02.08.09.55.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 Feb 2013 09:55:49 -0800 (PST) From: "Roni Even" To: "'Robert Sparks'" Date: Fri, 8 Feb 2013 19:52:57 +0200 Message-ID: <060201ce0625$235babd0$6a130370$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0603_01CE0635.E6E60270" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac4GJSC67aJA8JLYTQGcsCmP/C92Xg== Content-Language: en-us Cc: iesg-secretary@ietf.org, rai-ads@tools.ietf.org, payload@ietf.org Subject: [payload] Request for publication of draft-ietf-avt-rtp-isac-04 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, 08 Feb 2013 17:55:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0603_01CE0635.E6E60270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Robert, I'd like to request that draft-ietf-avt-rtp-isac-04, RTP Payload Format for the iSAC Codec. I've reviewed the draft in detail, and the Payload working group was given the opportunity to comment. The draft is documented in sufficient detail to meet the registration requirements, and doesn't conflict with other work in Payload. Accordingly, please consider it for publication. Thanks, Roni Even (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This is a standard track RFC. This is a typical RTP payload specification. The title page header indicates it. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: iSAC is a proprietary wideband speech and audio codec developed by Global IP Solutions (now part of Google), suitable for use in Voice over IP applications. This document describes the payload format for iSAC generated bit streams within a Real-Time Protocol (RTP) packet. Also included here are the necessary details for the use of iSAC with the Session Description Protocol (SDP). Working Group Summary: A previous draft-ietf-avt-rtp-isac-02 went through a working group last call. There were comments and the current version draft-ietf-avt-rtp-isac-04 addresses all the comments. There was no need for a second WGLC. Document Quality: This is a payload specification for the iSAC codec and it was reviewed by a couple of people in the payload working group. Personnel: Roni Even is the Document Shepherd and the Responsible Area Director is Robert Sparks. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd reviewed the document very carefully in version -02 during the WG last call. He has since reviewed the changes in the current version. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document got a decent review for an RTP payload specification by people who had interest in this work. Some of them were done when it was still an individual draft. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No need for any such review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes, the shepherd has confirmed with all authors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? A typical payload specification will be interesting to some of the WG participants who have interest in using this codec with RTP. As such this document had a review from individuals who have such interest and contributed text that was added after the WGLC. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No real ID nits in this document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The media subtype registration was reviewed by the shepherd and a request to review was sent to ietf-type mailing list. http://www.ietf.org/mail-archive/web/media-types/current/msg00464.html . No comments. (13) Have all references within this document been identified as either normative or informative? yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? no (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. no (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No change to other documents already published. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document adds a new media subtype iSAC. The document shepherd verified that the registration template is according to RFC 4855 and RFC4288 and that is consistent with the body of the document. No new IANA registries are defined. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language. ------=_NextPart_000_0603_01CE0635.E6E60270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

=  

Hi = Robert,

I'd like to request that = draft-ietf-avt-rtp-isac-04, = RTP Payload Format for the iSAC Codec.

I've reviewed the draft in detail, and the Payload = working group was given the opportunity to comment. The draft is = documented in sufficient detail to meet the registration requirements, = and doesn't conflict with other work in Payload. Accordingly, please = consider it for publication.

 

Thanks,

Roni = Even

 

 

(1) What type of RFC is = being requested (BCP, Proposed Standard, Internet Standard, = Informational, Experimental, or Historic)? Why is this the proper type = of RFC? Is this type of RFC indicated in the title page header? =

This is a standard track RFC.  This is a = typical RTP payload specification.

The title page header = indicates it.

(2) The IESG = approval announcement includes a Document Announcement Write-Up. Please = provide such a Document Announcement Write-Up. Recent examples can be = found in the "Action" announcements for approved documents. = The approval announcement contains the following sections: =

Technical Summary:

iSAC is a proprietary wideband speech and audio codec = developed by Global IP Solutions (now part of Google), suitable for use = in Voice over IP applications.  This document describes the payload = format for iSAC generated bit streams within a Real-Time Protocol (RTP) = packet. Also included here are the necessary details for the use of iSAC = with the Session Description Protocol (SDP).

Working Group = Summary:

A previous = draft-ietf-avt-rtp-isac-02 went through a = working group last call. There were comments and the current version = draft-ietf-avt-rtp-isac-04 addresses all the comments. There was = no need for a second WGLC.

Document Quality:

This is a payload = specification for the iSAC codec and it was reviewed by a couple of = people in the payload working group.

Personnel:

Roni Even is the Document Shepherd and the Responsible Area Director = is Robert Sparks.

(3) Briefly describe the review of this document = that was performed by the Document Shepherd. If this version of the = document is not ready for publication, please explain why the document = is being forwarded to the IESG.

The shepherd reviewed the document very carefully in version -02 = during
the WG last call. He has since reviewed the changes in the = current version.

(4) Does the document Shepherd have any concerns = about the depth or breadth of the reviews that have been performed? =

This document got a decent review for an RTP = payload specification by people who had interest in this work. Some of = them were done when it was still an individual = draft.

(5) Do portions of the document need review from a = particular or from broader perspective, e.g., security, operational = complexity, AAA, DNS, DHCP, XML, or internationalization? If so, = describe the review that took place.

No need for any such = review.

(6) Describe any specific concerns or issues that = the Document Shepherd has with this document that the Responsible Area = Director and/or the IESG should be aware of? For example, perhaps he or = she is uncomfortable with certain parts of the document, or has concerns = whether there really is a need for it. In any event, if the WG has = discussed those issues and has indicated that it still wishes to advance = the document, detail those concerns here.

No = concerns

(7) Has each author confirmed that any and all = appropriate IPR disclosures required for full conformance with the = provisions of BCP 78 and BCP 79 have already been filed. If not, explain = why?

Yes, the shepherd has confirmed with all authors.

(8) Has an IPR disclosure been filed that = references this document? If so, summarize any WG discussion and = conclusion regarding the IPR disclosures.

No = IPR

(9) How solid is the WG consensus behind this = document? Does it represent the strong concurrence of a few individuals, = with others being silent, or does the WG as a whole understand and agree = with it?

A typical payload specification will be = interesting to some of the WG participants who have interest in using = this codec with RTP. As such this document had a review from individuals = who have such interest and contributed text that was added after the = WGLC.

(10) Has anyone threatened an appeal or otherwise = indicated extreme discontent? If so, please summarise the areas of = conflict in separate email messages to the Responsible Area Director. = (It should be in a separate email because this questionnaire is publicly = available.)

No

(11) Identify any ID nits the Document Shepherd = has found in this document. (See http://www.ietf.org/tools/idnits/ and = the Internet-Drafts Checklist). Boilerplate checks are not enough; this = check needs to be thorough.

No real ID nits in this = document.

(12) Describe how the document meets any required = formal review criteria, such as the MIB Doctor, media type, and URI type = reviews.

The media subtype registration was reviewed by the = shepherd and a request to review was sent to ietf-type mailing = list.  http://www.ietf.org/mail-archive/web/media-types/current/msg00464.= html . No comments.

(13) Have all references within this document been = identified as either normative or informative?

yes

(14) Are there normative = references to documents that are not ready for advancement or are = otherwise in an unclear state? If such normative references exist, what = is the plan for their completion?

no

(15) Are there downward = normative references references (see RFC 3967)? If so, list these = downward references to support the Area Director in the Last Call = procedure.

no

(16) Will publication of this document change the = status of any existing RFCs? Are those RFCs listed on the title page = header, listed in the abstract, and discussed in the introduction? If = the RFCs are not listed in the Abstract and Introduction, explain why, = and point to the part of the document where the relationship of this = document to the other RFCs is discussed. If this information is not in = the document, explain why the WG considers it unnecessary. =

No change to other documents already published.

(17) Describe the Document Shepherd's review of = the IANA considerations section, especially with regard to its = consistency with the body of the document. Confirm that all protocol = extensions that the document makes are associated with the appropriate = reservations in IANA registries. Confirm that any referenced IANA = registries have been clearly identified. Confirm that newly created IANA = registries include a detailed specification of the initial contents for = the registry, that allocations procedures for future registrations are = defined, and a reasonable name for the new registry has been suggested = (see RFC 5226).

This document adds a new media subtype iSAC. The = document shepherd verified that the registration template is according = to RFC 4855 and RFC4288 and that is consistent with the body of the = document.

No new IANA registries are = defined.

 

(18) List any new IANA = registries that require Expert Review for future allocations. Provide = any public guidance that the IESG would find useful in selecting the = IANA Experts for these new registries.

No new IANA = registries.

(19) Describe reviews and automated checks = performed by the Document Shepherd to validate sections of the document = written in a formal language, such as XML code, BNF rules, MIB = definitions, etc.

No formal = language.

 

------=_NextPart_000_0603_01CE0635.E6E60270-- From jonathan@vidyo.com Mon Feb 18 15:07:38 2013 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 C787621F8778 for ; Mon, 18 Feb 2013 15:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] 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 CrWXWjSdBpLU for ; Mon, 18 Feb 2013 15:07:38 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF4921F8788 for ; Mon, 18 Feb 2013 15:07:38 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CC9518BF006 for ; Mon, 18 Feb 2013 18:07:37 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id E1D6D8BEF9B for ; Mon, 18 Feb 2013 18:07:32 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Mon, 18 Feb 2013 18:07:32 -0500 From: Jonathan Lennox To: "payload@ietf.org" Date: Mon, 18 Feb 2013 18:07:31 -0500 Thread-Topic: I-D Action: draft-lennox-payload-ulp-ssrc-mux-00.txt Thread-Index: Ac4OLLg3u78rusOXT1udSw5FPXiOQg== Message-ID: References: <20130218225054.23444.52245.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 Subject: [payload] Fwd: I-D Action: draft-lennox-payload-ulp-ssrc-mux-00.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, 18 Feb 2013 23:07:38 -0000 Hi, all -- Discussions at previous IETFs pointed out to me that RFC 5109 (the RTP Gene= ric FEC payload) forbids using it in SSRC-multiplexing, even though RFC 557= 6 (SSRC attributes/groups) defines a semantic to permit exactly that. This document updates RFC 5109 to permit source-multiplexing of FEC streams= with the payloads they protect, so long as the associations between the FE= C and original SSRCs are properly signaled. This not only fixes the incons= istency between RFC 5109 and RFC 5576, but also permits FEC's use with othe= r mechanisms for associating SSRCs in an RTP session, such as BUNDLE or SRC= NAME. Comments are welcome. Begin forwarded message: > From: "internet-drafts@ietf.org" > Subject: I-D Action: draft-lennox-payload-ulp-ssrc-mux-00.txt > Date: February 18, 2013 5:50:54 PM EST > To: "i-d-announce@ietf.org" > Reply-To: "internet-drafts@ietf.org" >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Supporting Source-Multiplexing of the Real-Time Transp= ort Protocol (RTP) Payload for Generic Forward Error Correction > Author(s) : Jonathan Lennox > Filename : draft-lennox-payload-ulp-ssrc-mux-00.txt > Pages : 6 > Date : 2013-02-18 >=20 > Abstract: > The Real-Time Transport Protocol (RTP) Payload format for Generic > Forward Error Correction (FEC), specified in RFC 5109, forbids > transmitting FEC repair flows as separate sources in the same RTP > session as the flows being repaired. This document updates RFC 5109 > to lift that restriction, as long as the association between original > and repair flows is properly signaled and negotiated. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lennox-payload-ulp-ssrc-mux >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 -- Jonathan Lennox jonathan@vidyo.com From fluffy@cisco.com Mon Feb 25 21:45:44 2013 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 1840521F8D05 for ; Mon, 25 Feb 2013 21:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 32cudDy5aVBg for ; Mon, 25 Feb 2013 21:45:40 -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 05D3B21F8937 for ; Mon, 25 Feb 2013 21:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2143; q=dns/txt; s=iport; t=1361857540; x=1363067140; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=3dKgosz8faqHFhScPIWUn64/erT1QapqqeHwhcr7wIo=; b=Qw3xACeeLyYRywO7jHb5ku8G5QQHrswXUbwl/WtKWp2EFFqqyGaNjwdc wYEXaTo7P7NuAGB7XDobymMT6hFqQ4lp0HitNLocsO8ydm5I9Oe5I07yh wKcNYpMwZfnAQqeXF/OEkgqFpcbPtsPHy/wxuXRmeWJNS2av+KtjQt/AS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJlKLFGtJV2c/2dsb2JhbABFwWSBAxZzgiEBBDpRASoUQicEGxOHeJ5lkRWQAo1EgRWDF2EDpySDB4FqPQ X-IronPort-AV: E=Sophos;i="4.84,737,1355097600"; d="scan'208";a="181182480" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 26 Feb 2013 05:45:39 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1Q5jdjf004716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Feb 2013 05:45:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 23:45:38 -0600 From: "Cullen Jennings (fluffy)" To: "" Thread-Topic: Review of draft-ietf-payload-vp8-08 Thread-Index: AQHOE+SBCBGG65gUD0CDCg9/8nULHw== Date: Tue, 26 Feb 2013 05:45:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.53] Content-Type: text/plain; charset="us-ascii" Content-ID: <2967122885AB6E41B7AEA811840F9652@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 26 Feb 2013 01:00:19 -0800 Subject: [payload] Review of draft-ietf-payload-vp8-08 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, 26 Feb 2013 05:45:45 -0000 My major issues is I think it is not appropriate to define a temperable sca= lable codec in the same draft as the payload. I'm fine with the payloads fo= r it but I think the temporal scalability stuff should be moved to a separa= te draft outside of payload - it's very confusing having the two mixed toge= ther.=20 Need to be able to negotiate upper bound on resolution and frame rates - ev= ery time I have brought this up in the past the authors have strongly objec= ted but I don't understand how hardware codecs work without this. The hardw= are codecs need to have the 4 image buffers and they will have a limit to t= he size of theses. My preferred way of dealing with resolution would be jus= t to mandate use of rfc6236 when using VP8.=20 I don't see a need for 7 bit pictureID, it just adds to complexity that wil= l not be tested The temporal stuff does not seem to be specified very well. To be more spec= ific, I think creating a layered codec from a non layered codec would bette= r be done in a spec other than the payload description. Among other things = that space is littered with IPR issues that should not be confused with the= base payload The SDP does not allow one to specify the color space's supported but is se= ems that VP8 does so seems like something is needed in SDP.=20 I'd like to see negotiation of the loop filter type used for a variety of r= easons=20 I'd like to see negotiation of the reconstrcuction filter type(s) used - am= ount other things new ones can be added to VP8 and we need a way to support= that.=20 I'd like to see what the limits are of google hardware implementation (or a= nyone else's if they exist) and make sure that all theses limits can be exp= ressed in SDP.=20 I'd like to see a way of describing upper bound on macro block rate instead= of the combined max-fs / max-fr solution. I don't see how to make hardware= decoders work without this.=20 It would be good to see more advice on how many partitions to use and why.= =20 I'm confused on the Y bit.=20 Unclear if receiver is supposed to send positive ACK RPSI=20 From abegen@cisco.com Tue Feb 26 01:36:03 2013 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 E96B521F89E2 for ; Tue, 26 Feb 2013 01:36:03 -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=[AWL=0.000, 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 ho5V2vBR2Glx for ; Tue, 26 Feb 2013 01:36:03 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 076E221F89E5 for ; Tue, 26 Feb 2013 01:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2715; q=dns/txt; s=iport; t=1361871363; x=1363080963; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=AqNpnJMYZbBlg8EMsm6a1/ptL9n0ai3pQ/tpBEKeAdc=; b=F9PFSTHpiE3+q582AmlI7jZhttwX1cdt5IRFH+W6HcaWMmqftdXpaO9n 1JjZuQwIyv4ZFw+tZC0rVwB3tB8SYFMGoKUvhmNUxTWlVXqmAgmi8w5lK vMfSyne9xo4txXz3Gszh5IyWX15ti0qFVj3PfS+em3+tZ8AW67tHWlNCM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAeBLFGtJV2c/2dsb2JhbABFgma+en4Wc4IfAQEBBAEBATc0FwYBCBEDAQILFDcLHQgCBAESCBOHeAELryaQBQSNOQuBFSYSBoJZYQOnJIMHgWoIFx4 X-IronPort-AV: E=Sophos;i="4.84,739,1355097600"; d="scan'208";a="181203978" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 26 Feb 2013 09:36:02 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1Q9a2Kf031820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Feb 2013 09:36:02 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 03:36:02 -0600 From: "Ali C. Begen (abegen)" To: "Cullen Jennings (fluffy)" , "" Thread-Topic: [payload] Review of draft-ietf-payload-vp8-08 Thread-Index: AQHOE+SBCBGG65gUD0CDCg9/8nULH5iMVuuA Date: Tue, 26 Feb 2013 09:36:01 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.86.247.16] Content-Type: text/plain; charset="us-ascii" Content-ID: <9A239E07A805174E9162CBB1459DB247@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] Review of draft-ietf-payload-vp8-08 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, 26 Feb 2013 09:36:04 -0000 Cullen, thanks for the review. I was just writing my pub-request email to the AD. I am hoping the authors can respond back to your comments shortly so that we don't delay this document any further. Thanks. -acbegen -----Original Message----- From: Cullen Jennings Date: Tuesday, February 26, 2013 12:45 AM To: "payload@ietf.org" Subject: [payload] Review of draft-ietf-payload-vp8-08 > >My major issues is I think it is not appropriate to define a temperable >scalable codec in the same draft as the payload. I'm fine with the >payloads for it but I think the temporal scalability stuff should be >moved to a separate draft outside of payload - it's very confusing having >the two mixed together. > >Need to be able to negotiate upper bound on resolution and frame rates - >every time I have brought this up in the past the authors have strongly >objected but I don't understand how hardware codecs work without this. >The hardware codecs need to have the 4 image buffers and they will have a >limit to the size of theses. My preferred way of dealing with resolution >would be just to mandate use of rfc6236 when using VP8. > >I don't see a need for 7 bit pictureID, it just adds to complexity that >will not be tested > >The temporal stuff does not seem to be specified very well. To be more >specific, I think creating a layered codec from a non layered codec would >better be done in a spec other than the payload description. Among other >things that space is littered with IPR issues that should not be confused >with the base payload > >The SDP does not allow one to specify the color space's supported but is >seems that VP8 does so seems like something is needed in SDP. > >I'd like to see negotiation of the loop filter type used for a variety of >reasons=20 > >I'd like to see negotiation of the reconstrcuction filter type(s) used - >amount other things new ones can be added to VP8 and we need a way to >support that.=20 > >I'd like to see what the limits are of google hardware implementation (or >anyone else's if they exist) and make sure that all theses limits can be >expressed in SDP.=20 > >I'd like to see a way of describing upper bound on macro block rate >instead of the combined max-fs / max-fr solution. I don't see how to make >hardware decoders work without this. > >It would be good to see more advice on how many partitions to use and >why.=20 > >I'm confused on the Y bit. > >Unclear if receiver is supposed to send positive ACK RPSI > > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload > From abegen@cisco.com Tue Feb 26 11:22:43 2013 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 1270F21F87FB for ; Tue, 26 Feb 2013 11:22:43 -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=[AWL=0.000, 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 svzeS6jz2CBr for ; Tue, 26 Feb 2013 11:22:42 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2252821F8746 for ; Tue, 26 Feb 2013 11:22:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2502; q=dns/txt; s=iport; t=1361906562; x=1363116162; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yKbianEcg00ayeqFVfc52PRncacQsC0xo7Iz6VrT5qs=; b=J2bCbVN+L0ea0rHfTCAC+Fs+3O/tDvIvKbHNkgvEwrtyoMZ9d/mlQp6z L56q2NvIQVysK7CVeGQ5RoRJISwAdxOqYXEiv/OeU8oc7iZldSDFONDOv 36P8KPaZzW2BEFaABphR1dW1c+VZgx7Vxey2uve/MklbgVwgwSsUDsbJb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEkKLVGtJXHB/2dsb2JhbABFgma/B38Wc4IfAQEBBDo/DAYBCBEDAQILFEIdCAEBBAENBQiICwELr3+QCo04FYEWBiALBwaCWWEDpyiDCIFpPg X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="181433375" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 26 Feb 2013 19:22:41 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1QJMf0R002116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Feb 2013 19:22:41 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 13:22:41 -0600 From: "Ali C. Begen (abegen)" To: John Lindsay , "payload@ietf.org" Thread-Topic: [payload] draft-lindsay-payload-rtp-aptx-00 Thread-Index: Ac3/tGfZbbs/xCrXSbSreyQjqpUpmQACjV5ABTSrZgA= Date: Tue, 26 Feb 2013 19:22:40 +0000 Message-ID: In-Reply-To: <8C4E0C2409735E4FBC22D754A238F94D02D580CF@APTSBS.apt.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.86.245.31] Content-Type: text/plain; charset="us-ascii" Content-ID: <3407E4F653F44C438729A94089E6FD62@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Foerster@worldcastsystems.com" Subject: Re: [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: Tue, 26 Feb 2013 19:22:43 -0000 Authors,=20 A new milestone for the aptx codecs has been added. When the submission site opens again, please submit the WG version of your document. Thanks. -acbegen -----Original Message----- From: John Lindsay Date: Thursday, January 31, 2013 9:35 AM To: "payload@ietf.org" Cc: Hartmut Foerster , "Ali C. Begen" Subject: [payload] draft-lindsay-payload-rtp-aptx-00 >Hi=20 > >We would like to ask for the doc "draft-lindsay-payload-rtp-aptx-00" to >be considered by the working group for adoption as a proposed standard. > >The document has been in existence since its first draft in April 2008 >and has been updated by various members of APT following comments within >the workgroup over the past 5 years and is now implemented by a number >of Audio Codec manufactures mainly in the Broadcast sphere. > >A brief history of the doc is as follows. > >draft-gmassey-avt-rtp-aptx-01, (Submitted 15th Apr 2008), (Expired 17th >October 2008). >draft-trainor-avt-rtp-aptx-00, (Submitted 22nd December 2009), (Expired >25th June 2010) >draft-rea-payload-rtp-aptx-00 (Submitted 18th April 2011) >draft-rea-payload-rtp-aptx-01 (Submitted 7th October 2011) >draft-rea-payload-rtp-aptx-02 (Submitted 7th March 2011), (Expired 7th >September 2012) >draft-lindsay-payload-rtp-aptx-00 (Submitted 28th November 2012) > >The RFC was generated originally in response to our work with the EBU >(European Broadcasting Union) N/ACIP (Audio Contribution over IP) >workgroups and their attempts to standardise transmission of packetized >audio data over RTP to ensure compatibility between Audio Codec >manufacturers. >No standard method of packetizing the apt-X and Enhanced apt-X algorithm >was available and the doc seeks to address this along with the >appropriate SDP messages to facilitate compatible call signalling. > >http://www.ebu-acip.org/Main_Page > >Whilst the documents have generated a number of responses and driven a >number of the N/ACIP members and interested parties towards both the >payload and AVT workgroups, the number of interested parties is always >going to be limited as there are only a finite number of codec >manufacturers and hence N/ACIP members. > >As you can see from the above we hope the doc has reached a level of >maturity required for WG adoption. > >Many thanks for your time. > >Regards > >John Lindsay > > From stewe@stewe.org Wed Feb 27 05:49:07 2013 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 1A45721F856D for ; Wed, 27 Feb 2013 05:49:07 -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=[AWL=0.000, 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 YKg5Bs6KTrlU for ; Wed, 27 Feb 2013 05:49:06 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 900F121F8546 for ; Wed, 27 Feb 2013 05:48:57 -0800 (PST) Received: from mail81-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE010.bigfish.com (10.3.84.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 13:48:56 +0000 Received: from mail81-db3 (localhost [127.0.0.1]) by mail81-db3-R.bigfish.com (Postfix) with ESMTP id 3B751E0142; Wed, 27 Feb 2013 13:48:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zz98dI1dbaI1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL8275dh8275bhz2fh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1155h) Received-SPF: pass (mail81-db3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail81-db3 (localhost.localdomain [127.0.0.1]) by mail81-db3 (MessageSwitch) id 1361972933549128_1156; Wed, 27 Feb 2013 13:48:53 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.239]) by mail81-db3.bigfish.com (Postfix) with ESMTP id 81A1D2A0075; Wed, 27 Feb 2013 13:48:53 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Feb 2013 13:48:53 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.145]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0263.000; Wed, 27 Feb 2013 13:48:51 +0000 From: Stephan Wenger To: "Cullen Jennings (fluffy)" , "" Thread-Topic: [payload] Review of draft-ietf-payload-vp8-08 Thread-Index: AQHOE+SBCBGG65gUD0CDCg9/8nULH5iNNG+A Date: Wed, 27 Feb 2013 13:48:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <33B2F38D5E52D04198D4E4AC908E6604@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [payload] Review of draft-ietf-payload-vp8-08 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, 27 Feb 2013 13:49:07 -0000 Hi Cullen, WG, On 2.25.2013 21:45 , "Cullen Jennings (fluffy)" wrote: > >My major issues is I think it is not appropriate to define a temperable >scalable codec in the same draft as the payload. I'm fine with the >payloads for it but I think the temporal scalability stuff should be >moved to a separate draft outside of payload - it's very confusing having >the two mixed together. [...] > >The temporal stuff does not seem to be specified very well. To be more >specific, I think creating a layered codec from a non layered codec would >better be done in a spec other than the payload description. Among other >things that space is littered with IPR issues that should not be confused >with the base payload I disagree. Strongly. If you have one version of one codec then there should also be only one payload spec that addresses all (or at least all sensible) operation points of that version of the codec. Ideally, the payload spec should cover all versions, but that's sometimes not feasible. =20 If we start creating multiple payload formats for the same spec based on application requirements, IPR considerations, implementation complexity, ..., we would encourage people in the future to worry only about their application rather than generic use cases, and the result would be tons of potentially incompatible payload formats for one media codec. Bad. (In H.264, we went this route for purely pragmatic reasons--3984 and 6184 are already close to unreadable due to their size and density.). As for the IPR, what do you think you would learn in addition to what you know now, by separating the two specs? For those who haven't followed the development of this draft, there is only one IPR disclosure posted, which is from us (Vidyo; see https://datatracker.ietf.org/ipr/1622/). The licensing terms should sound vaguely familiar to a person working on IETF matters in Cisco :-) Interpreting the scope of that patent application is left as an exercise to the interested reader; however, I will note that we filed our disclosure shortly after the temporal scalability stuff was added into the draft.=20 The right way to deal with IPR-tricky parts of specs that are not necessary for all implementations is to make them optional in the spec, which implies an SDP codepoint for their negotiation. However, given the nature of video codecs and their payload formats in general, I don't think you would gain or loose a lot in terms of commercial risk... [...] >I'd like to see a way of describing upper bound on macro block rate >instead of the combined max-fs / max-fr solution. I don't see how to make >hardware decoders work without this. I was arguing in favor of that also, but after a long discussion I believe we came to the conclusion that the computational complexity part of the negotiation story is solved by the combined max-fs / max-fr trick, and the memory aspect would be solved by the generic image attribute SDP. While I consider that solution suboptimal, I can live with it. It's no worse than the level concept of MPEG (which also mixes computational complexity and memory demand), and sometimes a one-dimensional solution space is easier to solve than a two-dimensional one. [...] Stephan P.s.: in case anyone wonders, I still do not like VP8.