From phuart@cisco.com Thu Jan 3 05:31:58 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 7D7BD21F8C02 for ; Thu, 3 Jan 2013 05:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, 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 yPw-7ENqZfd1 for ; Thu, 3 Jan 2013 05:31:57 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB3121F8C01 for ; Thu, 3 Jan 2013 05:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28694; q=dns/txt; s=iport; t=1357219917; x=1358429517; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=XIiRnn3bkO6Oq2kXT9hrULUYc9OavUJ8qGIxqrzPB7A=; b=RG7BQEJnZ96tzNk7D9vuzUu0EA6yLwfd3Jsj0OwCOIVqRShWMcK6tbB+ 8AOw0UwzXbbG2ZzmNc3iibcck258luIxPW8cQB19PVWljDKTgROsEciuD c/jaxk3lxAWrtgRiHHgmMCtfEK7CUDHHIGtgk9+5z3ag1Z6TrADfhVU0X A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFADiH5VCtJV2a/2dsb2JhbABFgX9LsXMBiREWc4IeAQEBBC1MEgEIDgMDAQEBCxYBBigRFAkIAQEEAQ0FCId5Aw8MrxkNhiwGAotlaoNiYQOSWYFdgnKKG4URgnSCJg X-IronPort-AV: E=Sophos;i="4.84,403,1355097600"; d="scan'208,217";a="158433910" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 03 Jan 2013 13:31:56 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r03DVuVQ001371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jan 2013 13:31:56 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.50]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 07:31:55 -0600 From: "Pascal Huart (phuart)" To: Roni Even , "payload@ietf.org" Thread-Topic: WGLC on draft-ietf-avt-rtp-isac-02 Thread-Index: Ac3Y++h0UQghJ/PcRKOitadPT1ArYwKZcbWgAaPrk4A= Date: Thu, 3 Jan 2013 13:31:55 +0000 Message-ID: <5D39566A32EB774984E4B67C45453471112223@xmb-aln-x05.cisco.com> In-Reply-To: <01dd01cde366$6be0b3f0$43a21bd0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.55.199.105] Content-Type: multipart/alternative; boundary="_000_5D39566A32EB774984E4B67C45453471112223xmbalnx05ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 03 Jan 2013 06:06:38 -0800 Cc: "draft-ietf-avt-rtp-isac@tools.ietf.org" Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-isac-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 13:31:58 -0000 --_000_5D39566A32EB774984E4B67C45453471112223xmbalnx05ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Roni, I just noticed the emails, I'll follow up. Thanks, Pascal From: Roni Even > Date: Wednesday, December 26, 2012 1:42 PM To: "payload@ietf.org" > Cc: "draft-ietf-avt-rtp-isac@tools.ietf.org" > Subject: RE: WGLC on draft-ietf-avt-rtp-isac-02 Resent-From: > Resent-To: >, >, Cisco Employee >, >, > Resent-Date: Wednesday, December 26, 2012 1:45 PM 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 clea= r 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 =93The available bandwidth is continuously estimated= at the receiving iSAC and signaled in-band in the iSAC bit stream=94. How = does it work? 3. In section 3 second paragraph please discuss using dynamic payload= type number maybe add =93The assignment of an RTP payload type for the for= mat defined in this memo is outside the scope of this document. The RTP p= rofiles in use currently mandate binding the payload type dynamically for = this payload format.=94 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 sp= ecified elsewhere, in which case provide a reference. 6. In section 3.3 =93The user can choose to lower the maximum allowed= payload length =93. 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 =93signaled inband=94. What is inband, any referenc= e? 9. Looking at figure 6 I am not clear from the text how does the rece= iver know that there is padding and not payload? 10. In section 4 change the beginning to =93This RTP payload format is ide= ntified using the media type audio/isac, which is registered in accordance = with [RFC4855] and uses the template o= f [RFC4288].=94 11. Please verify that the registration follows the template. Currently th= e order is not correct and there are missing subscetions. 12. Since ibitrate and maxbitrate are optional parameters what are the def= ault values if not specified. I saw 20000 for ibitrate for channel adaptive= mode in section 2. 13. What are the units for ibitrate and maxbitrate 14. In section 4 the change controller should be the payload working grou= p. 15. In section 5 what is the clock rate in rtpmap. 16. Can you switch from wideband to super wideband without any signaling u= sing the same payload type number. Can you use a 32000 clock rate also for = the wideband. 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 o= f RFC 5404. 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 397= 9, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publica= tion. Thanks Roni Even Payload co-chair ________________________________ --_000_5D39566A32EB774984E4B67C45453471112223xmbalnx05ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Roni,
I just noticed the emails, I'll follow up.
Thanks,
Pascal

From: Roni Even <ron.even.tlv@gmail.com>
Date: Wednesday, December 26, 2012 = 1:42 PM
To: "payload@ietf.org" <payload@ietf.org>
Cc: "draft-ietf-avt-rtp-isac@tools.ietf.org= " <draft-= ietf-avt-rtp-isac@tools.ietf.org>
Subject: RE: WGLC on draft-ietf-avt= -rtp-isac-02
Resent-From: <draft-alias-bounces@tools.ietf.org&= gt;
Resent-To: <hta@google.com>, <paulej@packetizer.com>, Cisco Employee <phuart@cisco.com>, <tina.legrand@gipscorp.com>, <turajs@google.com>
Resent-Date: Wednesday, December 26= , 2012 1:45 PM

Hi,<= /p>

I reviewed the draft a= nd have some questions and comments

 

1.       In section 2 there is a mention of target bit rate. It is no= t clear how is it calculated and what does average during peaks mean? How i= s this parameter related to the ibitrate parameter defined in the IANA section.

2.    &nbs= p;  In section 2 =93The  available bandwidth is continuously estimated at the re= ceiving iSAC and signaled in-band in the iSAC bit stream=94. How does it wo= rk?

3.       In section 3 second paragraph please discuss using dynamic payload = type number maybe add =93The assignment of an RTP = payload type for the format defined in this  memo is outside the scope of this document.  The RTP profiles i= n use  currently mandate binding the payload type dynamically for this=   payload format.=94

4.    &nbs= p;  In section 3.2  what are the BEI and FL values  and how m= any bits each one uses.

5.    &nbs= p;  In section 3.3 what is bandwidth probe, how does it work. Is it spe= cified elsewhere, in which case provide a reference.

6.    &nbs= p;  In section 3.3 =93The = user can choose to lower the maximum allowed payload length =93. Who is the= user(sender / receiver) and how is it done.

7.    &nbs= p;  In section 3.4 how doe= s a receiver know if he receives a wideband or super-wideband payload in or= der to decode correctly.

8.    &nbs= p;  In section 3.5 =93sign= aled inband=94. What is inband, any reference?

9.    &nbs= p;  Looking at figure 6 I = am not clear from the text how does the receiver know that there is padding= and not payload?

10.  In section 4 ch= ange the beginning to =93This = RTP payload format is identified using the media type audio/isac, which is = registered in accordance with [RFC= 4855] and uses the  template of [RFC4288].=94

11.  Please verify that the registration follows t= he template. Currently the order is not correct and there are missing subsc= etions.

12.  Since ibitrate and maxbitrate are optional pa= rameters what are the default values if not specified. I saw 20000 for ibit= rate for channel adaptive mode in section 2.

13.  What are the units for ibitrate and maxbitrat= e

14.   In section 4 the change controller shou= ld be the payload working group.

15.  In section 5 what is the clock rate in rtpmap= .

16.  Can you switch from wideband to super wideban= d without any signaling using the same payload type number. Can you use a 3= 2000 clock rate also for the wideband.

17.   The document should have a congestion control sectio= n seehttp://tools.ietf.org/html/draft-ietf-payl= oad-rtp-howto-02

18.   The security section n= eed to be expanded see for example section 10 of RFC 5404.

Thanks=

Roni Even

 

 

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 13 December, 2012 8:35 AM
To: 'payload@ietf.org'
Cc: 'draf= t-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-is=
ac-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 lis= t.

 

For the draft authors;  Are you aware of any IPR th= at applies to draft-ietf-avt-rtp-isac-02? If so,

ha=
s this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979,=
 4879, 3669 and 5378 for more details)?
Th=
e above question is needed for the document write-up when sent to publicati=
on.
 

Thanks

 

Roni Even

Payload  co-chair

 

 

 

 --_000_5D39566A32EB774984E4B67C45453471112223xmbalnx05ciscocom_-- From harald@alvestrand.no Thu Jan 3 07:26: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 3493421F8CB4 for ; Thu, 3 Jan 2013 07:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.202 X-Spam-Level: X-Spam-Status: No, score=-110.202 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=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 tpgt7FmOkwWb for ; Thu, 3 Jan 2013 07:26:43 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DC9B321F8CA0 for ; Thu, 3 Jan 2013 07:26:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0A1CD39E176 for ; Thu, 3 Jan 2013 16:26:40 +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 Mb9LMGmFwbKd for ; Thu, 3 Jan 2013 16:26:38 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:29c0:ec01:f309:1358] (unknown [IPv6:2001:470:de0a:27:29c0:ec01:f309:1358]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DCAA039E0CE for ; Thu, 3 Jan 2013 16:26:37 +0100 (CET) Message-ID: <50E5A32C.6010205@alvestrand.no> Date: Thu, 03 Jan 2013 16:26:36 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: payload@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060101010100020307090104" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 15:26:44 -0000 This is a multi-part message in MIME format. --------------060101010100020307090104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/29/2012 09:02 PM, Ali C. Begen (abegen) wrote: > From: Patrik Westin > > Reply-To: "pwestin@webrtc.org " > > > Date: Wednesday, December 19, 2012 6:06 PM > To: Glen Zorn > > Cc: Stephan Wenger >, "Ali C. > Begen" >, Jonathan Lennox > >, "payload@ietf.org > " >, "draft-ietf-payload-vp8@tools.ietf.org > " > > > Subject: Re: [payload] WGLC for VP8 Payload > > Would you be happy with adding paragraph saying something like this? > > "People doing splicing of VP8 streams will have to make sure the > rules for incrementing TL0PICIDX and KEYIDX are obeyed across the > splice. This may require rewriting values of TL0PICIDX and KEYIDX > after the splice." > > > Slight rewording: > > Implementations doing splicing of VP8 streams will have to make sure > the rules for incrementing TL0PICIDX and KEYIDX are obeyed across the > splice. This will likely require rewriting values of TL0PICIDX and > KEYIDX after the splice. Sounds fine to me. > > BTW, just out of curiosity, as vp9 is surfacing soon, is there any > implication on this draft? > > No. The VP9 effort will eventually result in a stable codec, but it won't be VP8. --------------060101010100020307090104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/29/2012 09:02 PM, Ali C. Begen (abegen) wrote:
From: Patrik Westin <pwestin@webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org>
Date: Wednesday, December 19, 2012 6:06 PM
To: Glen Zorn <glenzorn@gmail.com>
Cc: Stephan Wenger <stewe@stewe.org>, "Ali C. Begen" <abegen@cisco.com>, Jonathan Lennox <jonathan@vidyo.com>, "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-vp8@tools.ietf.org" <draft-ietf-payload-vp8@tools.ietf.org>
Subject: Re: [payload] WGLC for VP8 Payload

Would you be happy with adding paragraph saying something like this?

"People doing splicing of VP8 streams will have to make sure the rules for incrementing TL0PICIDX and KEYIDX are obeyed across the splice. This may require rewriting values of TL0PICIDX and KEYIDX after the splice."

Slight rewording:

Implementations doing splicing of VP8 streams will have to make sure the rules for incrementing TL0PICIDX and KEYIDX are obeyed across the splice. This will likely require rewriting values of TL0PICIDX and KEYIDX after the splice.
Sounds fine to me.

BTW, just out of curiosity, as vp9 is surfacing soon, is there any implication on this draft? 


No. The VP9 effort will eventually result in a stable codec, but it won't be VP8.


--------------060101010100020307090104-- From harald@alvestrand.no Thu Jan 3 07:41:26 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 7D06321F868B for ; Thu, 3 Jan 2013 07:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.195 X-Spam-Level: X-Spam-Status: No, score=-110.195 tagged_above=-999 required=5 tests=[AWL=-0.197, 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 ABR54Sj9e7V1 for ; Thu, 3 Jan 2013 07:41:23 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3306821F8C9D for ; Thu, 3 Jan 2013 07:41:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3178339E176 for ; Thu, 3 Jan 2013 16:41:10 +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 b7rE5TAWi6sO for ; Thu, 3 Jan 2013 16:41:07 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:29c0:ec01:f309:1358] (unknown [IPv6:2001:470:de0a:27:29c0:ec01:f309:1358]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C823F39E0CE for ; Thu, 3 Jan 2013 16:41:06 +0100 (CET) Message-ID: <50E5A692.6040500@alvestrand.no> Date: Thu, 03 Jan 2013 16:41:06 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: payload@ietf.org References: <01dd01cde366$6be0b3f0$43a21bd0$@gmail.com> In-Reply-To: <01dd01cde366$6be0b3f0$43a21bd0$@gmail.com> Content-Type: multipart/alternative; boundary="------------090108020303090000060407" Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-isac-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 15:41:26 -0000 This is a multi-part message in MIME format. --------------090108020303090000060407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. > 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. > > 13.What are the units for ibitrate and maxbitrate > I've assumed bits per second, but I'll check. > > 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? > 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 --------------090108020303090000060407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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.

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.

13.  What are the units for ibitrate and maxbitrate

I've assumed bits per second, but I'll check.

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?

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

--------------090108020303090000060407-- From ron.even.tlv@gmail.com Thu Jan 3 08:54:58 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 A9AE421F8201 for ; Thu, 3 Jan 2013 08:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 IJyfZ0HpSh1l for ; Thu, 3 Jan 2013 08:54:52 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 58E0E21F8CEE for ; Thu, 3 Jan 2013 08:54:51 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e51so7494038eek.20 for ; Thu, 03 Jan 2013 08:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=m8K12CHq7F0WW5nJR0n15BvQ+Fl0zP+DXj8woMhwc/0=; b=N+OcbMzHltY65Fm6pjcrYvzO5fhFfhJNXPw3FbCJ2FIZh9woqMqgAUGgL8i5W6IBDm tOQp4KaE1sGSj3ISnsxXhLS/Jrm2Ll1NM06H2uMJidGDkhcnSKOprNX8C985ttZEK7mv n4xkmVO+Gw0l02vsCMpzc6o2XmSTxHTty+wUrTvFl7nLPWK7VUckf6vlLWsw9IhV+8C2 Uyjj7fNQkNQoNq8MsucuDK+C17YkynUNSwHp9HAHB2exjxczLn47+uNx6fmYKxs/FqFz lqlv/YyDEb8gpwb+y0aVJ/bXVwKeihZ57T0ai3tUBzFUte+roFGIgvr3FOsxS38WQjvl ZyeQ== X-Received: by 10.14.215.194 with SMTP id e42mr135853884eep.32.1357232090485; Thu, 03 Jan 2013 08:54:50 -0800 (PST) Received: from RoniE ([109.66.135.125]) by mx.google.com with ESMTPS id d3sm105060682eeo.13.2013.01.03.08.54.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Jan 2013 08:54:49 -0800 (PST) From: "Roni Even" To: "'Harald Alvestrand'" , References: <01dd01cde366$6be0b3f0$43a21bd0$@gmail.com> <50E5A692.6040500@alvestrand.no> In-Reply-To: <50E5A692.6040500@alvestrand.no> Date: Thu, 3 Jan 2013 18:51:59 +0200 Message-ID: <017301cde9d2$a784e1c0$f68ea540$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0174_01CDE9E3.6B1049D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE511bjKWJ+BaidpPEhslUVIH4tVgFlkcAGmVTGHlA= Content-Language: en-us Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-isac-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:54:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0174_01CDE9E3.6B1049D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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_0174_01CDE9E3.6B1049D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

<= 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_0174_01CDE9E3.6B1049D0-- From xavier.marjou@gmail.com Mon Jan 7 07:05:29 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 5831421F88B5 for ; Mon, 7 Jan 2013 07:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 GVuKbLq3ujnW for ; Mon, 7 Jan 2013 07:05:28 -0800 (PST) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id C403021F88CA for ; Mon, 7 Jan 2013 07:05:28 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id d1so12494826qca.16 for ; Mon, 07 Jan 2013 07:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=kBPGRJEOjyDkti6loB1wZx0gtSrqPTShAsTAuqGtx1w=; b=mkpG6aqaQxkznyGyjE8NQ+ZSBPo2UL27GjpMWPT2XcUVOIfuJKWydOWjUczbX2q/ux B1E//lSvzbBTVVmh+4TFkcln9m41vqEERM19tksn4FO7qq39/xv21E90THHyELwOn15R lJyDzdSP/jac1wR3JwfXrJLC1bwux8Vq4Jh4YmdYVfHMVsAPIesxOcEVfykyTX/3iJ6q u6VoES010f3i2EuMRJjPhOm0FcnAfHcP+VKqp0QsPVBkPxdqZL2H7YJCFTj+gNs2LbmK 6W5TnS+RMX6m7OLoVYGVRA+oGa0RSYDNpMtHa7ElRbgGCe5ptQXgEFnGD2oOoD0FigBv UoAQ== MIME-Version: 1.0 Received: by 10.224.223.17 with SMTP id ii17mr43219880qab.13.1357571128327; Mon, 07 Jan 2013 07:05:28 -0800 (PST) Sender: xavier.marjou@gmail.com Received: by 10.49.63.227 with HTTP; Mon, 7 Jan 2013 07:05:28 -0800 (PST) Date: Mon, 7 Jan 2013 16:05:28 +0100 X-Google-Sender-Auth: iBw_1PFJN1zH3SGV_MhoJm8pinc Message-ID: From: Xavier Marjou To: payload@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [payload] Errata proposal for RFC4733 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, 07 Jan 2013 15:05:29 -0000 Hi, During the last AVTEXT meeting (c.f. http://tools.ietf.org/wg/avtext/minutes?item=3Dminutes-85-avtext.html), we discussed one ambiguity in RFC4733 (RTP Payload for DTMF Digits) when using DTMF and WB audio codecs. Here is an errata proposal to clarify this ambiguity. What do you think ? CURRENT TEXT: 2. RTP Payload Format for Named Telephone Events 2.1. Introduction =85 Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. NEW PROPOSED TEXT: 2. RTP Payload Format for Named Telephone Events 2.1. Introduction =85 Named telephone events are carried as part of the audio stream and MUST use the same SSRC (therefore the same timing and sequence number space) and the same timestamp clock rate as the regular audio channel to simplify the generation of audio waveforms at a gateway. Cheers, Xavier From abegen@cisco.com Wed Jan 9 14:27: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 A748111E80A4 for ; Wed, 9 Jan 2013 14:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.191 X-Spam-Level: X-Spam-Status: No, score=-8.191 tagged_above=-999 required=5 tests=[AWL=2.408, 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 jrl3Q1VQC3km for ; Wed, 9 Jan 2013 14:27:52 -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 B881911E809C for ; Wed, 9 Jan 2013 14:27:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=905; q=dns/txt; s=iport; t=1357770470; x=1358980070; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=pVwncMB5Il/xgqqjV978KcTL6B0AV2UtPt0NnVUuox4=; b=kLpEneo5tmFk4+foJJF1zBZdWG+Do8/HJ6ERy479gBZGag0eRpLv6/cT j2cC5Cv33nMrx8mROxunHQSc9kdBIP8Ocu01TK35dpvU/SrsBjshOK4C2 SJKB9o8OY4ntspahw/XDwGpCrFhYJwbju314gAnwjnt3UUdggbH4UARwl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FACzt7VCtJXG8/2dsb2JhbABEgmuDB7dsFnOCHgEBAQQBAQE3NBcGAQgRAwECCxQ3Cx0IAgQTCIgRAQuYEZ4HjFeDYmEDlyiPLYJ0giQ X-IronPort-AV: E=Sophos;i="4.84,440,1355097600"; d="scan'208";a="160744799" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 09 Jan 2013 22:27:49 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r09MRn1L002021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 9 Jan 2013 22:27:49 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 16:27:49 -0600 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: [payload] Adopting draft-spittka-payload-rtp-opus Thread-Index: AQHN3I3cBUPTnvZxb0md0zQnypK00phByMIA Date: Wed, 9 Jan 2013 22:27:49 +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.2.5.121010 x-originating-ip: [10.86.253.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <8788FA4FAABB1C4F9956686D567B64ED@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] Adopting draft-spittka-payload-rtp-opus 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, 09 Jan 2013 22:27:53 -0000 There were no objections. Authors, go ahead and submit the wg version, please. Thanks. -----Original Message----- From: "Ali C. Begen" Date: Monday, December 17, 2012 2:36 PM To: "payload@ietf.org" Subject: [payload] Adopting draft-spittka-payload-rtp-opus >Hi everyone, > >The Opus draft has been pretty completed and the authors would like to see >it adopted and published. >http://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/ > > >We already have a milestone for this as: >Dec 2012 Submit RTP Payload Format for Opus Speech and Audio Codec as >proposed standard > > >Please speak up if you do not support adopting this draft by Dec. 24th. > >Thanks, >-acbegen (as a co-chair) > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload > From internet-drafts@ietf.org Thu Jan 10 01:55:39 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 B443321F88CC; Thu, 10 Jan 2013 01:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 SOZasIRQNgGW; Thu, 10 Jan 2013 01:55:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28B921F87A3; Thu, 10 Jan 2013 01:55:38 -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: <20130110095538.21798.62763.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2013 01:55:38 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-sbc-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: Thu, 10 Jan 2013 09:55:39 -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 Bluetooth's SBC Audio Codec Author(s) : Christian Hoene Frans de Bont Filename : draft-ietf-payload-rtp-sbc-04.txt Pages : 23 Date : 2013-01-10 Abstract: This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-sbc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-sbc-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-sbc-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jan 10 07:40:23 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 E489621F87FE; Thu, 10 Jan 2013 07:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 isKFIJvdgHCy; Thu, 10 Jan 2013 07:40:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A659721F87B9; Thu, 10 Jan 2013 07:40:21 -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: <20130110154021.27496.83392.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2013 07:40:21 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-opus-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: Thu, 10 Jan 2013 15:40:23 -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 Opus Speech and Audio Codec Author(s) : Julian Spittka Koen Vos Jean-Marc Valin Filename : draft-ietf-payload-rtp-opus-00.txt Pages : 22 Date : 2013-01-10 Abstract: This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data that is essential to integrate the codec in the most compatible way. Further, media type registrations are described for the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-opus-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hhhansen@MAYAH.com Mon Jan 14 12:06:18 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 F1C9C21F8B7D for ; Mon, 14 Jan 2013 12:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] 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 q8asQbnU0u1Z for ; Mon, 14 Jan 2013 12:06:17 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADE321F8B7C for ; Mon, 14 Jan 2013 12:06:16 -0800 (PST) Received: from [217.91.215.225] (helo=mayah-sbs.MAYAH.COM) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1TuqIR-0006zE-B7 for payload@ietf.org; Mon, 14 Jan 2013 21:06:15 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Mon, 14 Jan 2013 21:06:12 +0100 Message-ID: <031C6AD0F5FEAB449C77DF4E9D047A5C38F333@mayah-sbs.mayah.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mail regarding draft-lindsay-payload-rtp-aptx Thread-Index: Ac3vffGeC1iUnZYxQnaY03kcMkgMhQC/E+rQAAXCuZA= From: "Hans-Heinrich Hansen" To: X-Df-Sender: MzI2MjQx Subject: [payload] draft-lindsay-payload-rtp-aptx-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 20:06:18 -0000 MAYAH Communications will support this draft in all our - more than = twenty - products, which are supporting aptX! Hopefully this draft will = be become an official RFC ASAP! We're waiting since months for this RFC! = Why we and every other codec companies have to wait? Freundliche Gr=FC=DFe, Best regards, Hans-Heinrich Hansen Dipl.-Ing., Senior Development Engineer MAYAH Communications GmbH Lise-Meitner-Strasse 2 24941 Flensburg, Germany http://www.mayah.com =20 info@mayah.com Skype: hhhansen.mayah.com Live messenger: hhhansen@mayah.com Gesch=E4ftsf=FChrer, CEO, Dipl.-Ing. Detlef Wiese HRB 118601, Ust-IdNr DE193170106, Steuer-Nr Finanzamt Freising = 115/132/10789 Es gelten unsere Allgemeinen Gesch=E4ftsbedingungen = http://www.mayah.com/agb_de.pdf. We apply our General terms of delivery and business = http://www.mayah.com/agb_engl.pdf. Please note that this message and any included attachments are intended = only for the use of the addressee. It may contain information that is = confidential. If you are not the intended recipient, you are hereby = notified that any distribution or copying of this communication is = prohibited. If you have received this information by accident or due to = a misinterpretation of your e-mail address please be sure to erase the = original message and any copies or printouts hereof. Thank you.=20 From internet-drafts@ietf.org Wed Jan 16 13:43:02 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 EFBB521F84D9; Wed, 16 Jan 2013 13:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 jkQbeWb8dYT6; Wed, 16 Jan 2013 13:43:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CF221F844F; Wed, 16 Jan 2013 13:43:00 -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: <20130116214300.27292.59947.idtracker@ietfa.amsl.com> Date: Wed, 16 Jan 2013 13:43:00 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-isac-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 21:43:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for the iSAC Codec Author(s) : Tina le Grand Paul E. Jones Pascal Huart Turaj Zakizadeh Shabestary Harald Alvestrand Filename : draft-ietf-avt-rtp-isac-03.txt Pages : 15 Date : 2013-01-16 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-isac-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From csp@csperkins.org Thu Jan 17 03:43: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 F0EB521F8890 for ; Thu, 17 Jan 2013 03:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 x5iCTz93w63Q for ; Thu, 17 Jan 2013 03:43:43 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 58A8F21F87AB for ; Thu, 17 Jan 2013 03:43:43 -0800 (PST) Received: from [130.209.247.112] (helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tvnsj-0002b0-SY for payload@ietf.org; Thu, 17 Jan 2013 11:43:42 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Colin Perkins In-Reply-To: <20130116214300.27292.59947.idtracker@ietfa.amsl.com> Date: Thu, 17 Jan 2013 11:43:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130116214300.27292.59947.idtracker@ietfa.amsl.com> To: payload@ietf.org X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -13 X-Mythic-Debug: Threshold = On = Subject: Re: [payload] I-D Action: draft-ietf-avt-rtp-isac-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 11:43:44 -0000 On 16 Jan 2013, at 21:43, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Payloads = Working Group of the IETF. >=20 > 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-03.txt > Pages : 15 > Date : 2013-01-16 >=20 > 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). >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-isac One quick comment: the examples in Sections 6.1 and 6.2 use RFC 2119 = language ("SHOULD"), but I don't think an example is the right place to = define normative requirements for implementations. Can the RFC 2119 = terms be removed from these sections (and possibly be replaced by = references to a section where the response is defined)? --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Fri Jan 18 14:40:31 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 82CA421F870A; Fri, 18 Jan 2013 14:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 nHqklf7H8tA5; Fri, 18 Jan 2013 14:40:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087FE21F86D8; Fri, 18 Jan 2013 14:40:31 -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: <20130118224031.31560.7257.idtracker@ietfa.amsl.com> Date: Fri, 18 Jan 2013 14:40:31 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-08.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 22:40:31 -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 VP8 Video Author(s) : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-08.txt Pages : 29 Date : 2013-01-18 Abstract: This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-vp8-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abegen@cisco.com Sun Jan 20 01:59:57 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 3810221F850B for ; Sun, 20 Jan 2013 01:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.358 X-Spam-Level: X-Spam-Status: No, score=-7.358 tagged_above=-999 required=5 tests=[AWL=0.973, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666] 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 OBNTqvBCOFud for ; Sun, 20 Jan 2013 01:59:55 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9258C21F8505 for ; Sun, 20 Jan 2013 01:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42329; q=dns/txt; s=iport; t=1358675994; x=1359885594; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=YClGRCbXpEdA2xeWlg/JhFZ+OqDzWbArVA31G4cLi0k=; b=Yx8hDPbR2l1yvlBGFPC39WjEb/Ll09xq9uAEim3Ykwr8ggSfqjOZ81Zk L0sWved3uXYQ+/752gm4a4wL6TAjZU5umnPeOulbwCqVRndREKXKNg2t7 735ZSzH/nnOXgDSZv9GUDd58sZ3CvMDxRkXZkcy8Bmt7A6vnje9l/aHMp 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FALy/+1CtJXG+/2dsb2JhbABEgkgjgQqDa60whlGCWBZzgh4BAQEDAQEBARdUCwUHBgEIEQMBAQEBChYBBigGCxQJCAIEAQ0FCAGHfgMJBgEGBbIgDYhmjAltg2JhA5Q2gnKKG4USgS+BRoIk X-IronPort-AV: E=Sophos;i="4.84,500,1355097600"; d="scan'208,217";a="165093499" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 20 Jan 2013 09:59:53 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0K9xrSI003034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jan 2013 09:59:53 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Sun, 20 Jan 2013 03:59:52 -0600 From: "Ali C. Begen (abegen)" To: "pwestin@webrtc.org" , Glen Zorn Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: AQHNxpKRijb9Uyx1rkaO+XOA7twBQpgLNEKAgAkiCoCAAChLAIACfvJggAArcICAAjlHAP//to2AgABYcICAAAJqgIAAAxOA//+s+gCAAFjNAIAA5kGAgAbvuICAMX+AgA== Date: Sun, 20 Jan 2013 09:59:52 +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.2.5.121010 x-originating-ip: [10.86.247.215] Content-Type: multipart/alternative; boundary="_000_C15918F2FCDA0243A7C919DA7C4BE9940CEB79BFxmbalnx01ciscoc_" MIME-Version: 1.0 Cc: Jonathan Lennox , "draft-ietf-payload-vp8@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 09:59:57 -0000 --_000_C15918F2FCDA0243A7C919DA7C4BE9940CEB79BFxmbalnx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Is everybody happy with the following addition of informative text? http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-08 From: Patrik Westin > Reply-To: "pwestin@webrtc.org" > Date: Wednesday, December 19, 2012 6:06 PM To: Glen Zorn > Cc: Stephan Wenger >, "Ali C. Begen= " >, Jonathan Lennox >, "payload@ietf.org" >, "draft-ietf-payload-vp8@= tools.ietf.org" > Subject: Re: [payload] WGLC for VP8 Payload Would you be happy with adding paragraph saying something like this? "People doing splicing of VP8 streams will have to make sure the rules for = incrementing TL0PICIDX and KEYIDX are obeyed across the splice. This may re= quire rewriting values of TL0PICIDX and KEYIDX after the splice." On Sat, Dec 15, 2012 at 5:11 AM, Glen Zorn > wrote: On 12/15/2012 06:27 AM, Stephan Wenger wrote: Hi, I'm with Ali here. Me, too. The design choice that has been made in the VP8 payload is different > from the one in the SVC payload, despite similarity in codepoint > names and functionality. The reasoning for that ought to be > documented. In the SVC payload format, we didn't need to, because we > were first in describing something like this :-) A sentence or two > should suffice, along the lines Jonathan proposed. Stephan > > From: "Ali C. Begen (abegen)" > >> Date: Friday, 14 Dece= mber, 2012 15:09 To: > "pwestin@webrtc.org >" > >>, Jonathan Lennox = > >> Cc: > "draft-ietf-payload-vp8@tools.ietf.org > >" > > >>, "payload@ietf.org > >" > >> Subject: Re: [payload= ] WGLC for VP8 > Payload > > Personally (chair-hat off), I think we should. It does not harm > anything but provides clarification to someone who is not deep down > in every detail. > > From: Patrik Westin >> > Reply-To: "pwestin@webrtc.org >" > >> Date: Friday, > December 14, 2012 6:06 PM To: Jonathan Lennox > >> Cc: "Ali C. Begen= " > >>, "payload@ietf.org > >" > >>, "draft-ietf-payload-= vp8@tools.ietf.org > >" > > >> Subject: Re: > [payload] WGLC for VP8 Payload > > Ali do you really want me to add that to the draft? > > > On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox > >> wrote: > > What I think Ali meant was to add some text describing the > implications of this design choice for splicers =96 i.e., if these > features are in use, they must re-write packets indefinitely > following a splice. > > > > *From:*pwestin@google.com > > [mailto:pwestin@google.com >] *On Behalf Of > *Patrik Westin *Sent:* Friday, December 14, 2012 5:47 PM *To:* Ali C. > Begen (abegen) *Cc:* Jonathan Lennox; payload@ietf.org > >; draft-ietf-payload-vp= 8@tools.ietf.org > > > > > *Subject:* Re: [payload] WGLC for VP8 Payload > > > > Well he did not have a point in my mind. This is what he wrote. > > > > "The VP8 payload format's decision is a reasonable design choice -- > as compared to the H.264 SVC rules, it removes some ambiguity between > splice points and packet loss, giving decoders somewhat greater > visibility as to what's going on in the bitstream, and also allows > TL0PICIDX and KEYIDX to be orthogonal options because they increment > independently." > > > > The worst thing that can happen in a draft is to leave ambiguity, > which we don't have in the current draft. However if we do it the way > H.264 SVC do we could introduce such ambiguity > > > > On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) > >> wrote: > > Are you at least planning to put some text around the point Jonathan > brought up? > > > > *From: *Patrik Westin > >> *Reply-To: *"pwes= tin@webrtc.org > >" > >> *Date: *Friday, D= ecember 14, 2012 4:53 > PM > > > *To: *"Ali C. Begen" >> > > *Cc: *Jonathan Lennox > >>, "payload@ietf.or= g > >" > >>, "draft-ietf-payload-= vp8@tools.ietf.org > >" > > >> > > > *Subject: *Re: [payload] WGLC for VP8 Payload > > > > Trying to send this again since my previous message did not reach the > list. > > Thanks for pointing out the inconsistency. We've submitted a new > draft that fixes that problem. > > > The second issue was intentional. We'll keep it this way. > > > > On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) > >> wrote: > > Thanks, the authors just rev'ed the draft to fix the first issue. I > hope they will address the second issue first in the list and then > reflect the agreement in the next revision. I will hold on to the doc > write-up till then. > > > -acbegen > > -----Original Message----- From: Jonathan Lennox > >> > > Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" > >>, "payload@ietf.org > >" > >> Cc: "draft-ietf-paylo= ad-vp8@tools.ietf.org > >" > > >> > > Subject: RE: [payload] WGLC for VP8 Payload > >> Hi, Ali -- >> >> I just wanted to make sure the issue had been considered; if the >> WG agrees that the current design is okay given the limitations >> I've mentioned, I'm not going to object. >> >> Discussion of the issue might be helpful in the document. >> >> -----Original Message----- From: Ali C. Begen (abegen) >> [mailto:abegen@cisco.com >] Sent: Tuesday, >> December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org >> > Cc: draft-ietf-payloa= d-vp8@tools.ietf.org >> > Subject: Re: >> [payload] WGLC for VP8 Payload >> >> The first one should be fixed by the authors thru a quick revision. >> As for the second one, I will ask the authors reply. Also if there >> are others who strongly think one way or another, lets discuss it. >> >> Jonathan, are you ok if the authors simply acknowledge this in the >> draft (assuming they agree with you) or do you actually not like >> this at all? >> >> -acbegen >> >> -----Original Message----- From: Jonathan Lennox >> >> Date: Tuesday, >> December 11, 2012 11:49 AM To: "payload@ietf.org >> >" >> >> Subject: Re: [payloa= d] WGLC for VP8 >> Payload >> >>> Hi -- I have two comments on this draft. Sorry for being late. >>> >>> First of all, an editorial matter: Section 6 says the format has >>> no parameters, but section 6.1 lists two optional parameters >>> (max-fr and max-fs). >>> >>> >>> Secondly, more substantively, I note that the payload format's >>> rules on KEYIDX and TL0PICIDX impose a fair bit of overhead on >>> boxes that wish to splice together VP8 streams, since both values >>> are required to always increment consecutively in a bitstream (if >>> they're being used). >>> >>> By contrast, the equivalent fields of the H.264 SVC payload >>> format (in the PACSI) just say that IDRPICID must be different in >>> consecutive IDR frames, without requiring that the value >>> increment by 1; and TL0PICIDX resets to 0 on every IDR frame, >>> rather than carrying on continuously. (H.264's IDR frames are >>> analogous for these purposes to VP8's essential keyframes). >>> >>> This means that an H.264 SVC splicer -- as long as it doesn't >>> get unlucky, such that the two streams it's splicing happen to >>> have identical IDRPICID values at the splice point -- can just >>> transition from one bitstream to another at any IDR frame. >>> >>> By contrast, following a splice, a VP8 splicer must re-write both >>> these fields for the rest of the lifetime of the stream, since >>> they each have only one valid possible value following the >>> splice. >>> >>> The VP8 payload format's decision is a reasonable design choice >>> -- as compared to the H.264 SVC rules, it removes some ambiguity >>> between splice points and packet loss, giving decoders somewhat >>> greater visibility as to what's going on in the bitstream, and >>> also allows TL0PICIDX and KEYIDX to be orthogonal options because >>> they increment independently. However, I wanted to make sure >>> this had been considered explicitly by the working group, and we >>> had consensus that it was the right decision. >>> >>> (Note well disclaimer: Vidyo has an IPR declaration against the >>> VP8 payload -- see .) >>> >>> >>> On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: >>> >>>> I have not seen any comments on the list. Please review the >>>> draft and post your comments on the list. >>>> >>>> Thanks. -acbegen >>>> >>>> -----Original Message----- From: "Ali C. Begen" >>>> >> Date: Monday, >>>> November 19, 2012 3:15 PM To: "payload@ietf.org >>>> >" >>>> >> Subject: [payload]= WGLC for VP8 >>>> Payload >>>> >>>>> Hi everyone, >>>>> >>>>> We had a WGLC for this draft earlier this year and there have >>>>> been a few updates to the document. I am starting a 2nd >>>>> WGLC. Please review and comment on the list by December >>>>> 10th. >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex > >>>>> >>>> t=3D1 >>>>> >>>> https://www.ietf.org/mailman/listinfo/payload >>>> >>> >>> -- Jonathan Lennox jonathan@vidyo.com >>> > >>> >>> >>> _______________________________________________ payload mailing >>> list payload@ietf.org > >>> https://www.ietf.org/mailman/listinfo/payload >> > > _______________________________________________ payload mailing list > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > > > > > > > > > > > > > > _______________________________________________ payload mailing list > payload@ietf.org https://www.ietf.org/mailman/li= stinfo/payload --_000_C15918F2FCDA0243A7C919DA7C4BE9940CEB79BFxmbalnx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5F63E991D2DDF84DAB9DC1255B1F1860@cisco.com> Content-Transfer-Encoding: quoted-printable
Is everybody happy with the following addition of informative text?


From: Patrik Westin <pwestin@webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org>
Date: Wednesday, December 19, 2012 = 6:06 PM
To: Glen Zorn <glenzorn@gmail.com>
Cc: Stephan Wenger <stewe@stewe.org>, "Ali C. Begen" &l= t;abegen@cisco.com>, Jonathan Le= nnox <jonathan@vidyo.com>, "payload@ietf.org" <<= a href=3D"mailto:payload@ietf.org">payload@ietf.org>, "draft-ietf-payload-vp8@to= ols.ietf.org" <draft-ietf-payload-vp8@tools.ietf.org>
Subject: Re: [payload] WGLC for VP8= Payload

Would you be happy with adding = ;paragrap= h saying something like this?

"People doing splicing of VP8 stream= s will have to make sure the rules for incrementing TL0PICIDX and KEYIDX are obeyed across the splice. This may require rewriting val= ues of TL0PICIDX and KEYIDX after the splice."



On Sat, Dec 15, 2012 at 5:11 AM, Glen Zorn <glenzorn@gmail.= com> wrote:
On 12/15/2012 06:27 AM, Stephan Wenger wrote:

Hi, I'm with Ali here.

Me, too.


The design choice that has been  made in the VP8 payload is different<= br>
> from the one in the SVC payload, despite similarity in codepoint
> names and functionality. The reasoning for that ought to be
> documented. In the SVC payload format, we didn't need to, because we > were first in describing something like this :-) A sentence or two
> should suffice, along the lines Jonathan proposed. Stephan
>
> From: "Ali C. Begen (abegen)" <abegen@cisco.com
> <mailto:abege= n@cisco.com>> Date: Friday, 14 December, 2012 15:09 To:
> "pwestin@= webrtc.org <mailto:pwestin@webrtc.org>" <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>>, Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>> Cc:
> "draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>>, &= quot;payload@ietf.org=
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>> Subject: Re: [payload] WGLC for VP8

> Payload
>
> Personally (chair-hat off), I think we should. It does not harm
> anything but provides clarification to someone who is not deep down > in every detail.
>
> From: Patrik Westin <pwestin@webrtc.org <mailto:pwestin@webrtc.org>>
> Reply-To: "pwestin@webrtc.org <mailto:pwestin@webrtc.org>"
> <pwestin@we= brtc.org <mailto:pwestin@webrtc.org>> Date: Friday,

> December 14, 2012 6:06 PM To: Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>> Cc: "Ali C. Begen" <abegen@cisco.com
> <mailto:abege= n@cisco.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>>, "draft-ietf-payload-vp8@tools.ietf.org=
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>> Su= bject: Re:

> [payload] WGLC for VP8 Payload
>
> Ali do you really want me to add that to the draft?
>
>
> On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox <jonathan@vidyo.com
> <mailto:jonathan@vidyo.com>> wrote:
>
> What I think Ali meant was to add some text describing the
> implications of this design choice for splicers =96 i.e., if these
> features are in use, they must re-write packets indefinitely
> following a splice.
>
>
>
> *From:*pwestin= @google.com <mailto:pwestin@google.com>
> [mailto:pwesti= n@google.com <mailto:pwestin@google.com>] *On Behalf Of
> *Patrik Westin *Sent:* Friday, December 14, 2012 5:47 PM *To:* Ali C.<= br> > Begen (abegen) *Cc:* Jonathan Lennox; payload@ietf.org
> <mailto:paylo= ad@ietf.org>; = draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>
>
>
> *Subject:* Re: [payload] WGLC for VP8 Payload

>
>
>
> Well he did not have a point in my mind. This is what he wrote.
>
>
>
> "The VP8 payload format's decision is a reasonable design choice = --
> as compared to the H.264 SVC rules, it removes some ambiguity between<= br> > splice points and packet loss, giving decoders somewhat greater
> visibility as to what's going on in the bitstream, and also allows
> TL0PICIDX and KEYIDX to be orthogonal options because they increment > independently."
>
>
>
> The worst thing that can happen in a draft is to leave ambiguity,
> which we don't have in the current draft. However if we do it the way<= br> > H.264 SVC do we could introduce such ambiguity
>
>
>
> On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen)
> <abegen@cisco.com <mailto:abegen@cisco.com>> wrote:
>
> Are you at least planning to put some text around the point Jonathan > brought up?
>
>
>
> *From: *Patrik Westin <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>> *Reply-To: *"pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>" <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>> *Date: *Friday, December 14, 2012 4:53
> PM
>
>
> *To: *"Ali C. Begen" <abegen@cisco.com <mailto:abegen@cisco.com>>
>
> *Cc: *Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>>, "draft-ietf-payload-vp8@tools.ietf.org=
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>> >
>
> *Subject: *Re: [payload] WGLC for VP8 Payload

>
>
>
> Trying to send this again since my previous message did not reach the<= br> > list.
>
> Thanks for pointing out the inconsistency. We've submitted a new
> draft that fixes that problem.
>
>
> The second issue was intentional. We'll keep it this way.
>
>
>
> On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen)
> <abegen@cisco.com <mailto:abegen@cisco.com>> wrote:
>
> Thanks, the authors just rev'ed the draft to fix the first issue. I > hope they will address the second issue first in the list and then
> reflect the agreement in the next revision. I will hold on to the doc<= br> > write-up till then.
>
>
> -acbegen
>
> -----Original Message----- From: Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>>

>
> Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen"= ;
> <abegen@cisco= .com <mailto:a= begen@cisco.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>> Cc: "draft-ietf-payload-vp8@tools.ietf.= org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>>

>
> Subject: RE: [payload] WGLC for VP8 Payload
>
>> Hi, Ali --
>>
>> I just wanted to make sure the issue had been considered; if the >> WG agrees that the current design is okay given the limitations >> I've mentioned, I'm not going to object.
>>
>> Discussion of the issue might be helpful in the document.
>>
>> -----Original Message----- From: Ali C. Begen (abegen)
>> [mailto:abeg= en@cisco.com <mailto:abegen@cisco.com>] Sent: Tuesday,

>> December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org
>> <mailto:p= ayload@ietf.org> Cc: = draft-ietf-payload-vp8@tools.ietf.org
>> <mailto:draft-ietf-payload-vp8@tools.ietf.org> Su= bject: Re:

>> [payload] WGLC for VP8 Payload
>>
>> The first one should be fixed by the authors thru a quick revision= .
>> As for the second one, I will ask the authors reply. Also if there=
>> are others who strongly think one way or another, lets discuss it.=
>>
>> Jonathan, are you ok if the authors simply acknowledge this in the=
>> draft (assuming they agree with you) or do you actually not like >> this at all?
>>
>> -acbegen
>>
>> -----Original Message----- From: Jonathan Lennox
>> <jonath= an@vidyo.com <mailto:jonathan@vidyo.com>> Date: Tuesday,

>> December 11, 2012 11:49 AM To: "payload@ietf.org
>> <mailto:p= ayload@ietf.org>" <payload@ietf.org
>> <mailto:p= ayload@ietf.org>> Subject: Re: [payload] WGLC for VP8

>> Payload
>>
>>> Hi -- I have two comments on this draft. Sorry for being late.=
>>>
>>> First of all, an editorial matter: Section 6 says the format h= as
>>> no parameters, but section 6.1 lists two optional parameters >>> (max-fr and max-fs).
>>>
>>>
>>> Secondly, more substantively, I note that the payload format's=
>>> rules on KEYIDX and TL0PICIDX impose a fair bit of overhead on=
>>> boxes that wish to splice together VP8 streams, since both val= ues
>>> are required to always increment consecutively in a bitstream = (if
>>> they're being used).
>>>
>>> By contrast, the equivalent fields of the H.264 SVC payload >>> format (in the PACSI) just say that IDRPICID must be different= in
>>> consecutive IDR frames, without requiring that the value
>>> increment by 1; and TL0PICIDX resets to 0 on every IDR frame,<= br> >>> rather than carrying on continuously. (H.264's IDR frames are<= br> >>> analogous for these purposes to VP8's essential keyframes). >>>
>>> This means that an H.264 SVC splicer -- as long as it doesn't<= br> >>> get unlucky, such that the two streams it's splicing happen to=
>>> have identical IDRPICID values at the splice point -- can just=
>>> transition from one bitstream to another at any IDR frame.
>>>
>>> By contrast, following a splice, a VP8 splicer must re-write b= oth
>>> these fields for the rest of the lifetime of the stream, since=
>>> they each have only one valid possible value following the
>>> splice.
>>>
>>> The VP8 payload format's decision is a reasonable design choic= e
>>> -- as compared to the H.264 SVC rules, it removes some ambigui= ty
>>> between splice points and packet loss, giving decoders somewha= t
>>> greater visibility as to what's going on in the bitstream, and=
>>> also allows TL0PICIDX and KEYIDX to be orthogonal options beca= use
>>> they increment independently. However, I wanted to make sure >>> this had been considered explicitly by the working group, and = we
>>> had consensus that it was the right decision.
>>>
>>> (Note well disclaimer: Vidyo has an IPR declaration against th= e
>>> VP8 payload -- see <http://tracker.tools.ietf.org/ipr/162= 2/>.)
>>>
>>>
>>> On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:
>>>
>>>> I have not seen any comments on the list. Please review th= e
>>>> draft and post your comments on the list.
>>>>
>>>> Thanks. -acbegen
>>>>
>>>> -----Original Message----- From: "Ali C. Begen"<= br>
>>>> <= abegen@cisco.com <mailto:abegen@cisco.com>> Date: Monday,

>>>> November 19, 2012 3:15 PM To: "payload@ietf.org
>>>> <mailto:payload@ietf.org>" <payload@ietf.org
>>>> <mailto:payload@ietf.org>> Subject: [payload] WGLC for VP8

>>>> Payload
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We had a WGLC for this draft earlier this year and the= re have
>>>>> been a few updates to the document. I am starting a 2n= d
>>>>> WGLC. Please review and comment on the list by Decembe= r
>>>>> 10th.
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?incl= ude_tex
>
>>>>>
>>>> t=3D1
>>>>>
>>>> https://www.ietf.org/mailman/listinfo/payload<= br> >>>>
>>>
>>> -- Jonathan Lennox jonathan@vidyo.com
>>> <mailto:jonathan@vidyo.com>
>>>
>>>
>>> _______________________________________________ payload= mailing
>>> list pay= load@ietf.org <mailto:payload@ietf.org>

>>> https://www.ietf.org/mailman/listinfo/payload
>>
>
> _______________________________________________ payload mailing= list
> payload@ietf.org= <mailto:paylo= ad@ietf.org>

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


--_000_C15918F2FCDA0243A7C919DA7C4BE9940CEB79BFxmbalnx01ciscoc_-- From ron.even.tlv@gmail.com Sun Jan 20 03:14: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 8638221F8523 for ; Sun, 20 Jan 2013 03:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=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 I-fjyw8U0dDq for ; Sun, 20 Jan 2013 03:14:49 -0800 (PST) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 030C121F8512 for ; Sun, 20 Jan 2013 03:14:48 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b47so2480663eek.29 for ; Sun, 20 Jan 2013 03:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=F2JyA/GURjOD15/xF/PW4eeOZDydZA4tXxs6zjHifnA=; b=v2oOrp7GTKRHWQorWftJb1gjFLZQXtggf8oggm0iEb+N9n4ikTCItyp+p2LIPCNqoF z1TzS5MuEpElDjhnAeG8+aM+Jsf57qT6wVJnkfzZj8CiGtZC35xPjpMuUSfxTbmBuoMq jKiH4XCmDQJQuqfN2RmXGTVj4+QOMOLucsxgfT8YIp2ctzKfpRM4g1qq5zZ3gWqPoFsn sJxMdu/74Wtjf5mliBNobz8cw6Oz4JJlxfbTRyLn3gBoAtXy1PXSd3cEf5cMf3wkP7Da 2OTV5dkVcVGfjiBv9r8bgj9e2K+sRWg2vyjTBLFBnbLva9mQrfsJlQT3Y5xN09priYGR 30+A== X-Received: by 10.14.213.134 with SMTP id a6mr47974444eep.45.1358680487858; Sun, 20 Jan 2013 03:14:47 -0800 (PST) Received: from RoniE ([109.66.27.172]) by mx.google.com with ESMTPS id 6sm16806479eea.3.2013.01.20.03.14.43 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 20 Jan 2013 03:14:46 -0800 (PST) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , , "'Glen Zorn'" References: In-Reply-To: Date: Sun, 20 Jan 2013 13:11:52 +0200 Message-ID: <00be01cdf6fe$f5d4c320$e17e4960$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BF_01CDF70F.B9629C30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGjJW2uSu0FjS2lqCtX9XQ3JUWYeJinsvEA Content-Language: en-us Cc: 'Jonathan Lennox' , payload@ietf.org, draft-ietf-payload-vp8@tools.ietf.org Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 11:14:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BF_01CDF70F.B9629C30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am OK with this informative text Roni From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: 20 January, 2013 12:00 PM To: pwestin@webrtc.org; Glen Zorn Cc: Jonathan Lennox; draft-ietf-payload-vp8@tools.ietf.org; payload@ietf.org Subject: Re: [payload] WGLC for VP8 Payload Is everybody happy with the following addition of informative text? http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-08 From: Patrik Westin Reply-To: "pwestin@webrtc.org" Date: Wednesday, December 19, 2012 6:06 PM To: Glen Zorn Cc: Stephan Wenger , "Ali C. Begen" , Jonathan Lennox , "payload@ietf.org" , "draft-ietf-payload-vp8@tools.ietf.org" Subject: Re: [payload] WGLC for VP8 Payload Would you be happy with adding paragraph saying something like this? "People doing splicing of VP8 streams will have to make sure the rules for incrementing TL0PICIDX and KEYIDX are obeyed across the splice. This may require rewriting values of TL0PICIDX and KEYIDX after the splice." On Sat, Dec 15, 2012 at 5:11 AM, Glen Zorn wrote: On 12/15/2012 06:27 AM, Stephan Wenger wrote: Hi, I'm with Ali here. Me, too. The design choice that has been made in the VP8 payload is different > from the one in the SVC payload, despite similarity in codepoint > names and functionality. The reasoning for that ought to be > documented. In the SVC payload format, we didn't need to, because we > were first in describing something like this :-) A sentence or two > should suffice, along the lines Jonathan proposed. Stephan > > From: "Ali C. Begen (abegen)" > Date: Friday, 14 December, 2012 15:09 To: > "pwestin@webrtc.org " >, Jonathan Lennox > Cc: > "draft-ietf-payload-vp8@tools.ietf.org > " > >, "payload@ietf.org > " > Subject: Re: [payload] WGLC for VP8 > Payload > > Personally (chair-hat off), I think we should. It does not harm > anything but provides clarification to someone who is not deep down > in every detail. > > From: Patrik Westin > > Reply-To: "pwestin@webrtc.org " > > Date: Friday, > December 14, 2012 6:06 PM To: Jonathan Lennox > Cc: "Ali C. Begen" >, "payload@ietf.org > " >, "draft-ietf-payload-vp8@tools.ietf.org > " > > Subject: Re: > [payload] WGLC for VP8 Payload > > Ali do you really want me to add that to the draft? > > > On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox > wrote: > > What I think Ali meant was to add some text describing the > implications of this design choice for splicers - i.e., if these > features are in use, they must re-write packets indefinitely > following a splice. > > > > *From:*pwestin@google.com > [mailto:pwestin@google.com ] *On Behalf Of > *Patrik Westin *Sent:* Friday, December 14, 2012 5:47 PM *To:* Ali C. > Begen (abegen) *Cc:* Jonathan Lennox; payload@ietf.org > ; draft-ietf-payload-vp8@tools.ietf.org > > > > *Subject:* Re: [payload] WGLC for VP8 Payload > > > > Well he did not have a point in my mind. This is what he wrote. > > > > "The VP8 payload format's decision is a reasonable design choice -- > as compared to the H.264 SVC rules, it removes some ambiguity between > splice points and packet loss, giving decoders somewhat greater > visibility as to what's going on in the bitstream, and also allows > TL0PICIDX and KEYIDX to be orthogonal options because they increment > independently." > > > > The worst thing that can happen in a draft is to leave ambiguity, > which we don't have in the current draft. However if we do it the way > H.264 SVC do we could introduce such ambiguity > > > > On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) > > wrote: > > Are you at least planning to put some text around the point Jonathan > brought up? > > > > *From: *Patrik Westin > *Reply-To: *"pwestin@webrtc.org > " > *Date: *Friday, December 14, 2012 4:53 > PM > > > *To: *"Ali C. Begen" > > > *Cc: *Jonathan Lennox >, "payload@ietf.org > " >, "draft-ietf-payload-vp8@tools.ietf.org > " > > > > > *Subject: *Re: [payload] WGLC for VP8 Payload > > > > Trying to send this again since my previous message did not reach the > list. > > Thanks for pointing out the inconsistency. We've submitted a new > draft that fixes that problem. > > > The second issue was intentional. We'll keep it this way. > > > > On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) > > wrote: > > Thanks, the authors just rev'ed the draft to fix the first issue. I > hope they will address the second issue first in the list and then > reflect the agreement in the next revision. I will hold on to the doc > write-up till then. > > > -acbegen > > -----Original Message----- From: Jonathan Lennox > > > Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" > >, "payload@ietf.org > " > Cc: "draft-ietf-payload-vp8@tools.ietf.org > " > > > > Subject: RE: [payload] WGLC for VP8 Payload > >> Hi, Ali -- >> >> I just wanted to make sure the issue had been considered; if the >> WG agrees that the current design is okay given the limitations >> I've mentioned, I'm not going to object. >> >> Discussion of the issue might be helpful in the document. >> >> -----Original Message----- From: Ali C. Begen (abegen) >> [mailto:abegen@cisco.com ] Sent: Tuesday, >> December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org >> Cc: draft-ietf-payload-vp8@tools.ietf.org >> Subject: Re: >> [payload] WGLC for VP8 Payload >> >> The first one should be fixed by the authors thru a quick revision. >> As for the second one, I will ask the authors reply. Also if there >> are others who strongly think one way or another, lets discuss it. >> >> Jonathan, are you ok if the authors simply acknowledge this in the >> draft (assuming they agree with you) or do you actually not like >> this at all? >> >> -acbegen >> >> -----Original Message----- From: Jonathan Lennox >> > Date: Tuesday, >> December 11, 2012 11:49 AM To: "payload@ietf.org >> " > > Subject: Re: [payload] WGLC for VP8 >> Payload >> >>> Hi -- I have two comments on this draft. Sorry for being late. >>> >>> First of all, an editorial matter: Section 6 says the format has >>> no parameters, but section 6.1 lists two optional parameters >>> (max-fr and max-fs). >>> >>> >>> Secondly, more substantively, I note that the payload format's >>> rules on KEYIDX and TL0PICIDX impose a fair bit of overhead on >>> boxes that wish to splice together VP8 streams, since both values >>> are required to always increment consecutively in a bitstream (if >>> they're being used). >>> >>> By contrast, the equivalent fields of the H.264 SVC payload >>> format (in the PACSI) just say that IDRPICID must be different in >>> consecutive IDR frames, without requiring that the value >>> increment by 1; and TL0PICIDX resets to 0 on every IDR frame, >>> rather than carrying on continuously. (H.264's IDR frames are >>> analogous for these purposes to VP8's essential keyframes). >>> >>> This means that an H.264 SVC splicer -- as long as it doesn't >>> get unlucky, such that the two streams it's splicing happen to >>> have identical IDRPICID values at the splice point -- can just >>> transition from one bitstream to another at any IDR frame. >>> >>> By contrast, following a splice, a VP8 splicer must re-write both >>> these fields for the rest of the lifetime of the stream, since >>> they each have only one valid possible value following the >>> splice. >>> >>> The VP8 payload format's decision is a reasonable design choice >>> -- as compared to the H.264 SVC rules, it removes some ambiguity >>> between splice points and packet loss, giving decoders somewhat >>> greater visibility as to what's going on in the bitstream, and >>> also allows TL0PICIDX and KEYIDX to be orthogonal options because >>> they increment independently. However, I wanted to make sure >>> this had been considered explicitly by the working group, and we >>> had consensus that it was the right decision. >>> >>> (Note well disclaimer: Vidyo has an IPR declaration against the >>> VP8 payload -- see .) >>> >>> >>> On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: >>> >>>> I have not seen any comments on the list. Please review the >>>> draft and post your comments on the list. >>>> >>>> Thanks. -acbegen >>>> >>>> -----Original Message----- From: "Ali C. Begen" >>>> > Date: Monday, >>>> November 19, 2012 3:15 PM To: "payload@ietf.org >>>> " >>> > Subject: [payload] WGLC for VP8 >>>> Payload >>>> >>>>> Hi everyone, >>>>> >>>>> We had a WGLC for this draft earlier this year and there have >>>>> been a few updates to the document. I am starting a 2nd >>>>> WGLC. Please review and comment on the list by December >>>>> 10th. >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex > >>>>> >>>> t=1 >>>>> >>>> https://www.ietf.org/mailman/listinfo/payload >>>> >>> >>> -- Jonathan Lennox jonathan@vidyo.com >>> >>> >>> >>> _______________________________________________ payload mailing >>> list payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >> > > _______________________________________________ payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > > > > > > > > > > > > > > _______________________________________________ payload mailing list > payload@ietf.org https://www.ietf.org/mailman/listinfo/payload ------=_NextPart_000_00BF_01CDF70F.B9629C30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am OK with this informative text

Roni

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Ali C. Begen (abegen)
Sent: 20 January, 2013 12:00 = PM
To: pwestin@webrtc.org; Glen Zorn
Cc: Jonathan = Lennox; draft-ietf-payload-vp8@tools.ietf.org; = payload@ietf.org
Subject: Re: [payload] WGLC for VP8 = Payload

 

Is everybody happy with the following addition of informative = text?

 

 

From: Patrik Westin <pwestin@webrtc.org>
Reply= -To: "pwestin@webrtc.org" <pwestin@webrtc.org>
Date:= Wednesday, December 19, 2012 6:06 PM
To: Glen Zorn <glenzorn@gmail.com>
Cc: = Stephan Wenger <stewe@stewe.org>, "Ali C. = Begen" <abegen@cisco.com>, Jonathan = Lennox <jonathan@vidyo.com>, "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-= vp8@tools.ietf.org" <draft-ietf-payload-= vp8@tools.ietf.org>
Subject: Re: [payload] WGLC for VP8 = Payload

 

W= ould you be happy with adding paragraph saying something like = this?

<= o:p> 

&= quot;People doing splicing of VP8 streams will have to make sure = the rules for incrementing TL0PICIDX and KEYIDX are obeyed across = the splice. This may require rewriting values of TL0PICIDX and = KEYIDX after the splice."

<= o:p> 

<= o:p> 

O= n Sat, Dec 15, 2012 at 5:11 AM, Glen Zorn <glenzorn@gmail.com> = wrote:

O= n 12/15/2012 06:27 AM, Stephan Wenger wrote:

H= i, I'm with Ali here.

<= o:p> 

M= e, too.

<= o:p> 

T= he design choice that has been  made in the VP8 payload is = different

&= gt; from the one in the SVC payload, despite similarity in = codepoint
> names and functionality. The reasoning for that ought = to be
> documented. In the SVC payload format, we didn't need to, = because we
> were first in describing something like this :-) A = sentence or two
> should suffice, along the lines Jonathan = proposed. Stephan
>
> From: "Ali C. Begen = (abegen)" <abegen@cisco.com

&= gt; <mailto:abegen@cisco.com>> Date: Friday, 14 = December, 2012 15:09 To:
> "pwestin@webrtc.org <mailto:pwestin@webrtc.org>" <pwestin@webrtc.org
> <mailto:pwestin@webrtc.org>>, Jonathan Lennox <jonathan@vidyo.com
> <mailto:jonathan@vidyo.com>> Cc:
> "draft-ietf-payload-vp8@tools.ietf.org
> = <mailto:draft-ietf-payload-vp8@tools.ietf.org>"
= > <draft-ietf-payload-vp8@tools.ietf.org
> = <mailto:draft-ietf-payload-vp8@tools.ietf.org>>, = "payload@ietf.org
> <mailto:payload@ietf.org>" <payload@ietf.org
> <mailto:payload@ietf.org>> Subject: Re: [payload] = WGLC for VP8

<= br>> Payload
>
> Personally (chair-hat off), I think we = should. It does not harm
> anything but provides clarification to = someone who is not deep down
> in every = detail.
>

&= gt; From: Patrik Westin <pwestin@webrtc.org <mailto:pwestin@webrtc.org>>
> Reply-To: = "pwestin@webrtc.org <mailto:pwestin@webrtc.org>"
> <pwestin@webrtc.org <mailto:pwestin@webrtc.org>> Date: Friday, =

<= br>> December 14, 2012 6:06 PM To: Jonathan Lennox <jonathan@vidyo.com

&= gt; <mailto:jonathan@vidyo.com>> Cc: "Ali C. = Begen" <abegen@cisco.com
> <mailto:abegen@cisco.com>>, "payload@ietf.org
> <mailto:payload@ietf.org>" <payload@ietf.org
> <mailto:payload@ietf.org>>, "draft-ietf-payload-vp8@tools.ietf.org
> = <mailto:draft-ietf-payload-vp8@tools.ietf.org>"
= > <draft-ietf-payload-vp8@tools.ietf.org
> = <mailto:draft-ietf-payload-vp8@tools.ietf.org>> = Subject: Re:

<= br>> [payload] WGLC for VP8 Payload
>
> Ali do you really = want me to add that to the draft?
>
>
> On Fri, Dec = 14, 2012 at 2:55 PM, Jonathan Lennox <jonathan@vidyo.com

=

&= gt; <mailto:jonathan@vidyo.com>> wrote:
>
> = What I think Ali meant was to add some text describing the
> = implications of this design choice for splicers – i.e., if = these
> features are in use, they must re-write packets = indefinitely
> following a = splice.
>
>
>

&= gt; *From:*pwestin@google.com <mailto:pwestin@google.com>
> [mailto:pwestin@google.com <mailto:pwestin@google.com>] *On Behalf Of
> = *Patrik Westin *Sent:* Friday, December 14, 2012 5:47 PM *To:* Ali = C.
> Begen (abegen) *Cc:* Jonathan Lennox; payload@ietf.org
> <mailto:payload@ietf.org>; draft-ietf-payload-vp8@tools.ietf.org
> = <mailto:draft-ietf-payload-vp8@tools.ietf.org>
>>
> *Subject:* Re: [payload] WGLC for VP8 Payload =

<= br>>
>
>
> Well he did not have a point in my mind. = This is what he wrote.
>
>
>
> "The VP8 = payload format's decision is a reasonable design choice --
> as = compared to the H.264 SVC rules, it removes some ambiguity = between
> splice points and packet loss, giving decoders somewhat = greater
> visibility as to what's going on in the bitstream, and = also allows
> TL0PICIDX and KEYIDX to be orthogonal options = because they increment
> = independently."
>
>
>
> The worst thing = that can happen in a draft is to leave ambiguity,
> which we don't = have in the current draft. However if we do it the way
> H.264 SVC = do we could introduce such ambiguity
>
>
>
> On = Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen = (abegen)

&= gt; <abegen@cisco.com <mailto:abegen@cisco.com>> wrote:
>
> = Are you at least planning to put some text around the point = Jonathan
> brought = up?
>
>
>

&= gt; *From: *Patrik Westin <pwestin@webrtc.org
> <mailto:pwestin@webrtc.org>> *Reply-To: *"pwestin@webrtc.org
> <mailto:pwestin@webrtc.org>" <pwestin@webrtc.org
> <mailto:pwestin@webrtc.org>> *Date: *Friday, = December 14, 2012 4:53
> PM
>
>
> *To: = *"Ali C. Begen" <abegen@cisco.com <mailto:abegen@cisco.com>>
>
> *Cc: = *Jonathan Lennox <jonathan@vidyo.com
> <mailto:jonathan@vidyo.com>>, "payload@ietf.org
> <mailto:payload@ietf.org>" <payload@ietf.org
> <mailto:payload@ietf.org>>, "draft-ietf-payload-vp8@tools.ietf.org
> = <mailto:draft-ietf-payload-vp8@tools.ietf.org>"
= > <draft-ietf-payload-vp8@tools.ietf.org
> = <mailto:draft-ietf-payload-vp8@tools.ietf.org>>
&g= t;
>
> *Subject: *Re: [payload] WGLC for VP8 Payload =

<= br>>
>
>
> Trying to send this again since my = previous message did not reach the
> list.
>
> Thanks = for pointing out the inconsistency. We've submitted a new
> draft = that fixes that problem.
>
>
> The second issue was = intentional. We'll keep it this way.
>
>
>
> On = Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen = (abegen)

&= gt; <abegen@cisco.com <mailto:abegen@cisco.com>> wrote:
>
> = Thanks, the authors just rev'ed the draft to fix the first issue. = I
> hope they will address the second issue first in the list and = then
> reflect the agreement in the next revision. I will hold on = to the doc
> write-up till then.
>
>
> = -acbegen
>
> -----Original Message----- From: Jonathan = Lennox <jonathan@vidyo.com

&= gt; <mailto:jonathan@vidyo.com>> =

<= br>>
> Date: Thursday, December 13, 2012 11:29 AM To: "Ali = C. Begen"

&= gt; <abegen@cisco.com <mailto:abegen@cisco.com>>, "payload@ietf.org
> <mailto:payload@ietf.org>" <payload@ietf.org
> <mailto:payload@ietf.org>> Cc: "draft-ietf-payload-vp8@tools.ietf.org
> = <mailto:draft-ietf-payload-vp8@tools.ietf.org>"
= > <draft-ietf-payload-vp8@tools.ietf.org
> = <mailto:draft-ietf-payload-vp8@tools.ietf.org>> =

<= br>>
> Subject: RE: [payload] WGLC for VP8 = Payload
>
>> Hi, Ali --
>>
>> I just = wanted to make sure the issue had been considered; if the
>> WG = agrees that the current design is okay given the limitations
>> = I've mentioned, I'm not going to object.
>>
>> = Discussion of the issue might be helpful in the = document.
>>
>> -----Original Message----- From: Ali = C. Begen (abegen)

&= gt;> [mailto:abegen@cisco.com <mailto:abegen@cisco.com>] Sent: Tuesday, =

<= br>>> December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org

&= gt;> <mailto:payload@ietf.org> Cc: draft-ietf-payload-vp8@tools.ietf.org
>> = <mailto:draft-ietf-payload-vp8@tools.ietf.org> Subject: = Re:

<= br>>> [payload] WGLC for VP8 Payload
>>
>> The = first one should be fixed by the authors thru a quick = revision.
>> As for the second one, I will ask the authors = reply. Also if there
>> are others who strongly think one way = or another, lets discuss it.
>>
>> Jonathan, are you = ok if the authors simply acknowledge this in the
>> draft = (assuming they agree with you) or do you actually not like
>> = this at all?
>>
>> -acbegen
>>
>> = -----Original Message----- From: Jonathan = Lennox

&= gt;> <jonathan@vidyo.com <mailto:jonathan@vidyo.com>> Date: Tuesday, =

<= br>>> December 11, 2012 11:49 AM To: "payload@ietf.org

&= gt;> <mailto:payload@ietf.org>" <payload@ietf.org
>> <mailto:payload@ietf.org>> Subject: Re: [payload] = WGLC for VP8

<= br>>> Payload
>>
>>> Hi -- I have two = comments on this draft. Sorry for being = late.
>>>
>>> First of all, an editorial matter: = Section 6 says the format has
>>> no parameters, but section = 6.1 lists two optional parameters
>>> (max-fr and = max-fs).
>>>
>>>
>>> Secondly, more = substantively, I note that the payload format's
>>> rules on = KEYIDX and TL0PICIDX impose a fair bit of overhead on
>>> = boxes that wish to splice together VP8 streams, since both = values
>>> are required to always increment consecutively in = a bitstream (if
>>> they're being = used).
>>>
>>> By contrast, the equivalent = fields of the H.264 SVC payload
>>> format (in the PACSI) = just say that IDRPICID must be different in
>>> consecutive = IDR frames, without requiring that the value
>>> increment = by 1; and TL0PICIDX resets to 0 on every IDR frame,
>>> = rather than carrying on continuously. (H.264's IDR frames = are
>>> analogous for these purposes to VP8's essential = keyframes).
>>>
>>> This means that an H.264 SVC = splicer -- as long as it doesn't
>>> get unlucky, such that = the two streams it's splicing happen to
>>> have identical = IDRPICID values at the splice point -- can just
>>> = transition from one bitstream to another at any IDR = frame.
>>>
>>> By contrast, following a splice, = a VP8 splicer must re-write both
>>> these fields for the = rest of the lifetime of the stream, since
>>> they each have = only one valid possible value following the
>>> = splice.
>>>
>>> The VP8 payload format's = decision is a reasonable design choice
>>> -- as compared to = the H.264 SVC rules, it removes some ambiguity
>>> between = splice points and packet loss, giving decoders somewhat
>>> = greater visibility as to what's going on in the bitstream, = and
>>> also allows TL0PICIDX and KEYIDX to be orthogonal = options because
>>> they increment independently. However, I = wanted to make sure
>>> this had been considered explicitly = by the working group, and we
>>> had consensus that it was = the right decision.
>>>
>>> (Note well = disclaimer: Vidyo has an IPR declaration against the
>>> VP8 = payload -- see <http://tracker.tools.ietf.org/ipr/1622/>.)
&g= t;>>
>>>
>>> On Dec 5, 2012, at 9:20 PM, = Ali C. Begen (abegen) wrote:
>>>
>>>> I have = not seen any comments on the list. Please review the
>>>> = draft and post your comments on the = list.
>>>>
>>>> Thanks. = -acbegen
>>>>
>>>> -----Original = Message----- From: "Ali C. = Begen"

&= gt;>>> <abegen@cisco.com <mailto:abegen@cisco.com>> Date: Monday, =

<= br>>>>> November 19, 2012 3:15 PM To: "payload@ietf.org

&= gt;>>> <mailto:payload@ietf.org>" <payload@ietf.org
>>>> <mailto:payload@ietf.org>> Subject: [payload] WGLC = for VP8

<= br>>>>> Payload
>>>>
>>>>> = Hi everyone,
>>>>>
>>>>> We had a = WGLC for this draft earlier this year and there = have
>>>>> been a few updates to the document. I am = starting a 2nd
>>>>> WGLC. Please review and comment = on the list by December
>>>>> = 10th.
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8= /?include_tex
>
>>>>>
>>>> = t=3D1
>>>>>
>>>> https://www.ietf.org/mailman/listinfo/payload
&g= t;>>>
>>>
>>> -- Jonathan Lennox jonathan@vidyo.com

&= gt;>> <mailto:jonathan@vidyo.com>
>>>
>>&= gt;
>>> _______________________________________________ = payload mailing
>>> list payload@ietf.org <mailto:payload@ietf.org>

<= br>>>> https://www.ietf.org/mailman/listinfo/payload
&g= t;>
>
> _______________________________________________ = payload mailing list

&= gt; payload@ietf.org <mailto:payload@ietf.org> =

<= br>> https://www.ietf.org/mailman/listinfo/payload
&g= t;
>
>
>
>
>
>
>
>
>= ;
>
>
>
>
> = _______________________________________________ payload mailing = list
> payload@ietf.org https://www.ietf.org/mailman/listinfo/payload<= /o:p>

<= o:p> 

 

 

------=_NextPart_000_00BF_01CDF70F.B9629C30-- From internet-drafts@ietf.org Sun Jan 20 11:43:30 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 EB1ED21F8600; Sun, 20 Jan 2013 11:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 W9cUMn75wIJv; Sun, 20 Jan 2013 11:43:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD6F21F86D3; Sun, 20 Jan 2013 11:43:29 -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: <20130120194329.3854.90041.idtracker@ietfa.amsl.com> Date: Sun, 20 Jan 2013 11:43:29 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-10.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: Sun, 20 Jan 2013 19:43:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP payload format for Enhanced Variable Rate Narrowband= -Wideband Codec (EVRC-NW) Author(s) : Zheng Fang Filename : draft-ietf-avt-rtp-evrc-nw-10.txt Pages : 32 Date : 2013-01-20 Abstract: This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-evrc-nw There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-evrc-nw-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jonathan@vidyo.com Tue Jan 22 08:24:54 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 3CA8721F8A47 for ; Tue, 22 Jan 2013 08:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, SARE_HTML_USL_OBFU=1.666] 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 05WIPKp-Ntni for ; Tue, 22 Jan 2013 08:24:51 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 60BA521F8992 for ; Tue, 22 Jan 2013 08:24:50 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6C31A7A3282; Tue, 22 Jan 2013 10:56:08 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A8A267A3306; Tue, 22 Jan 2013 10:56:06 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Tue, 22 Jan 2013 11:24:43 -0500 From: Jonathan Lennox To: "Ali C. Begen (abegen)" Date: Tue, 22 Jan 2013 11:24:53 -0500 Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: Ac34vPsCJ9mL62WaTnu7Ca64HZ5wpg== Message-ID: <91CF2B2B-1951-4528-BB4D-5B569B22747C@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_91CF2B2B19514528BB4D5B569B22747Cvidyocom_" MIME-Version: 1.0 Cc: "draft-ietf-payload-vp8@tools.ietf.org" , "pwestin@webrtc.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:24:54 -0000 --_000_91CF2B2B19514528BB4D5B569B22747Cvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This looks reasonable to me. Thanks! On Jan 20, 2013, at 4:59 AM, Ali C. Begen (abegen) wrote: Is everybody happy with the following addition of informative text? http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-08 From: Patrik Westin > Reply-To: "pwestin@webrtc.org" > Date: Wednesday, December 19, 2012 6:06 PM To: Glen Zorn > Cc: Stephan Wenger >, "Ali C. Begen= " >, Jonathan Lennox >, "payload@ietf.org" >, "draft-ietf-payload-vp8@= tools.ietf.org" > Subject: Re: [payload] WGLC for VP8 Payload Would you be happy with adding paragraph saying something like this? "People doing splicing of VP8 streams will have to make sure the rules for = incrementing TL0PICIDX and KEYIDX are obeyed across the splice. This may re= quire rewriting values of TL0PICIDX and KEYIDX after the splice." On Sat, Dec 15, 2012 at 5:11 AM, Glen Zorn > wrote: On 12/15/2012 06:27 AM, Stephan Wenger wrote: Hi, I'm with Ali here. Me, too. The design choice that has been made in the VP8 payload is different > from the one in the SVC payload, despite similarity in codepoint > names and functionality. The reasoning for that ought to be > documented. In the SVC payload format, we didn't need to, because we > were first in describing something like this :-) A sentence or two > should suffice, along the lines Jonathan proposed. Stephan > > From: "Ali C. Begen (abegen)" > >> Date: Friday, 14 Dece= mber, 2012 15:09 To: > "pwestin@webrtc.org >" > >>, Jonathan Lennox = > >> Cc: > "draft-ietf-payload-vp8@tools.ietf.org > >" > > >>, "payload@ietf.org > >" > >> Subject: Re: [payload= ] WGLC for VP8 > Payload > > Personally (chair-hat off), I think we should. It does not harm > anything but provides clarification to someone who is not deep down > in every detail. > > From: Patrik Westin >> > Reply-To: "pwestin@webrtc.org >" > >> Date: Friday, > December 14, 2012 6:06 PM To: Jonathan Lennox > >> Cc: "Ali C. Begen= " > >>, "payload@ietf.org > >" > >>, "draft-ietf-payload-= vp8@tools.ietf.org > >" > > >> Subject: Re: > [payload] WGLC for VP8 Payload > > Ali do you really want me to add that to the draft? > > > On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox > >> wrote: > > What I think Ali meant was to add some text describing the > implications of this design choice for splicers =96 i.e., if these > features are in use, they must re-write packets indefinitely > following a splice. > > > > *From:*pwestin@google.com > > [mailto:pwestin@google.com >] *On Behalf Of > *Patrik Westin *Sent:* Friday, December 14, 2012 5:47 PM *To:* Ali C. > Begen (abegen) *Cc:* Jonathan Lennox; payload@ietf.org > >; draft-ietf-payload-vp= 8@tools.ietf.org > > > > > *Subject:* Re: [payload] WGLC for VP8 Payload > > > > Well he did not have a point in my mind. This is what he wrote. > > > > "The VP8 payload format's decision is a reasonable design choice -- > as compared to the H.264 SVC rules, it removes some ambiguity between > splice points and packet loss, giving decoders somewhat greater > visibility as to what's going on in the bitstream, and also allows > TL0PICIDX and KEYIDX to be orthogonal options because they increment > independently." > > > > The worst thing that can happen in a draft is to leave ambiguity, > which we don't have in the current draft. However if we do it the way > H.264 SVC do we could introduce such ambiguity > > > > On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) > >> wrote: > > Are you at least planning to put some text around the point Jonathan > brought up? > > > > *From: *Patrik Westin > >> *Reply-To: *"pwes= tin@webrtc.org > >" > >> *Date: *Friday, D= ecember 14, 2012 4:53 > PM > > > *To: *"Ali C. Begen" >> > > *Cc: *Jonathan Lennox > >>, "payload@ietf.or= g > >" > >>, "draft-ietf-payload-= vp8@tools.ietf.org > >" > > >> > > > *Subject: *Re: [payload] WGLC for VP8 Payload > > > > Trying to send this again since my previous message did not reach the > list. > > Thanks for pointing out the inconsistency. We've submitted a new > draft that fixes that problem. > > > The second issue was intentional. We'll keep it this way. > > > > On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) > >> wrote: > > Thanks, the authors just rev'ed the draft to fix the first issue. I > hope they will address the second issue first in the list and then > reflect the agreement in the next revision. I will hold on to the doc > write-up till then. > > > -acbegen > > -----Original Message----- From: Jonathan Lennox > >> > > Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" > >>, "payload@ietf.org > >" > >> Cc: "draft-ietf-paylo= ad-vp8@tools.ietf.org > >" > > >> > > Subject: RE: [payload] WGLC for VP8 Payload > >> Hi, Ali -- >> >> I just wanted to make sure the issue had been considered; if the >> WG agrees that the current design is okay given the limitations >> I've mentioned, I'm not going to object. >> >> Discussion of the issue might be helpful in the document. >> >> -----Original Message----- From: Ali C. Begen (abegen) >> [mailto:abegen@cisco.com >] Sent: Tuesday, >> December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org >> > Cc: draft-ietf-payloa= d-vp8@tools.ietf.org >> > Subject: Re: >> [payload] WGLC for VP8 Payload >> >> The first one should be fixed by the authors thru a quick revision. >> As for the second one, I will ask the authors reply. Also if there >> are others who strongly think one way or another, lets discuss it. >> >> Jonathan, are you ok if the authors simply acknowledge this in the >> draft (assuming they agree with you) or do you actually not like >> this at all? >> >> -acbegen >> >> -----Original Message----- From: Jonathan Lennox >> >> Date: Tuesday, >> December 11, 2012 11:49 AM To: "payload@ietf.org >> >" >> >> Subject: Re: [payloa= d] WGLC for VP8 >> Payload >> >>> Hi -- I have two comments on this draft. Sorry for being late. >>> >>> First of all, an editorial matter: Section 6 says the format has >>> no parameters, but section 6.1 lists two optional parameters >>> (max-fr and max-fs). >>> >>> >>> Secondly, more substantively, I note that the payload format's >>> rules on KEYIDX and TL0PICIDX impose a fair bit of overhead on >>> boxes that wish to splice together VP8 streams, since both values >>> are required to always increment consecutively in a bitstream (if >>> they're being used). >>> >>> By contrast, the equivalent fields of the H.264 SVC payload >>> format (in the PACSI) just say that IDRPICID must be different in >>> consecutive IDR frames, without requiring that the value >>> increment by 1; and TL0PICIDX resets to 0 on every IDR frame, >>> rather than carrying on continuously. (H.264's IDR frames are >>> analogous for these purposes to VP8's essential keyframes). >>> >>> This means that an H.264 SVC splicer -- as long as it doesn't >>> get unlucky, such that the two streams it's splicing happen to >>> have identical IDRPICID values at the splice point -- can just >>> transition from one bitstream to another at any IDR frame. >>> >>> By contrast, following a splice, a VP8 splicer must re-write both >>> these fields for the rest of the lifetime of the stream, since >>> they each have only one valid possible value following the >>> splice. >>> >>> The VP8 payload format's decision is a reasonable design choice >>> -- as compared to the H.264 SVC rules, it removes some ambiguity >>> between splice points and packet loss, giving decoders somewhat >>> greater visibility as to what's going on in the bitstream, and >>> also allows TL0PICIDX and KEYIDX to be orthogonal options because >>> they increment independently. However, I wanted to make sure >>> this had been considered explicitly by the working group, and we >>> had consensus that it was the right decision. >>> >>> (Note well disclaimer: Vidyo has an IPR declaration against the >>> VP8 payload -- see .) >>> >>> >>> On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: >>> >>>> I have not seen any comments on the list. Please review the >>>> draft and post your comments on the list. >>>> >>>> Thanks. -acbegen >>>> >>>> -----Original Message----- From: "Ali C. Begen" >>>> >> Date: Monday, >>>> November 19, 2012 3:15 PM To: "payload@ietf.org >>>> >" >>>> >> Subject: [payload]= WGLC for VP8 >>>> Payload >>>> >>>>> Hi everyone, >>>>> >>>>> We had a WGLC for this draft earlier this year and there have >>>>> been a few updates to the document. I am starting a 2nd >>>>> WGLC. Please review and comment on the list by December >>>>> 10th. >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex > >>>>> >>>> t=3D1 >>>>> >>>> https://www.ietf.org/mailman/listinfo/payload >>>> >>> >>> -- Jonathan Lennox jonathan@vidyo.com >>> > >>> >>> >>> _______________________________________________ payload mailing >>> list payload@ietf.org > >>> https://www.ietf.org/mailman/listinfo/payload >> > > _______________________________________________ payload mailing list > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > > > > > > > > > > > > > > _______________________________________________ payload mailing list > payload@ietf.org https://www.ietf.org/mailman/li= stinfo/payload -- Jonathan Lennox jonathan@vidyo.com --_000_91CF2B2B19514528BB4D5B569B22747Cvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
This looks reasonable= to me.  Thanks!

On Jan 20, 2013, at 4:59 AM, Ali C= . Begen (abegen) wrote:

Is everybody happy with the following addition of informative text?


From: Patrik Westin <pwestin@webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org>
Date: Wednesday, December 19, 2012 = 6:06 PM
To: Glen Zorn <glenzorn@gmail.com>
Cc: Stephan Wenger <stewe@stewe.org>, "Ali C. Begen" <abegen@cisco.com>, Jonathan Lennox <= jonathan@vidyo.com>, "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-vp8@tools.ietf.org= " <draft-ietf-p= ayload-vp8@tools.ietf.org>
Subject: Re: [payload] WGLC for VP8= Payload

Would you be happy with adding = ;paragrap= h saying something like this?

"People doing splicing of VP8 streams wil= l have to make sure the rules for incrementing TL0PICIDX and KEYIDX are obeyed across the splice. This may require rewriting val= ues of TL0PICIDX and KEYIDX after the splice."



On Sat, Dec 15, 2012 at 5:11 AM, Glen Zorn <glenzorn@gmail.= com> wrote:
On 12/15/2012 06:27 AM, Stephan Wenger wrote:

Hi, I'm with Ali here.

Me, too.


The design choice that has been  made in the VP8 payload is different<= br>
> from the one in the SVC payload, despite similarity in codepoint
> names and functionality. The reasoning for that ought to be
> documented. In the SVC payload format, we didn't need to, because we > were first in describing something like this :-) A sentence or two
> should suffice, along the lines Jonathan proposed. Stephan
>
> From: "Ali C. Begen (abegen)" <abegen@cisco.com
> <mailto:abege= n@cisco.com>> Date: Friday, 14 December, 2012 15:09 To:
> "pwestin@webrt= c.org <mailto:pwestin@webrtc.org>" <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>>, Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>> Cc:
> "draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"
> <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>>, "= payload@ietf.org<= br> > <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>> Subject: Re: [payload] WGLC for VP8

> Payload
>
> Personally (chair-hat off), I think we should. It does not harm
> anything but provides clarification to someone who is not deep down > in every detail.
>
> From: Patrik Westin <pwestin@webrtc.org <mailto:pwestin@webrtc.org>>
> Reply-To: "pwe= stin@webrtc.org <mailto:pwestin@webrtc.org>"
> <pwestin@we= brtc.org <mailto:pwestin@webrtc.org>> Date: Friday,

> December 14, 2012 6:06 PM To: Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>> Cc: "Ali C. Begen" <abegen@cisco.com
> <mailto:abege= n@cisco.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>>, "draft-ietf-payload-vp8@tools.ietf.org<= br> > <mailto:draft-ietf-payload-vp8@tools.ietf.org>"
> <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>> Su= bject: Re:

> [payload] WGLC for VP8 Payload
>
> Ali do you really want me to add that to the draft?
>
>
> On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox <jonathan@vidyo.com
> <mailto:jonathan@vidyo.com>> wrote:
>
> What I think Ali meant was to add some text describing the
> implications of this design choice for splicers =96 i.e., if these
> features are in use, they must re-write packets indefinitely
> following a splice.
>
>
>
> *From:*pwestin= @google.com <mailto:pwestin@google.com>
> [mailto:pwesti= n@google.com <mailto:pwestin@google.com>] *On Behalf Of
> *Patrik Westin *Sent:* Friday, December 14, 2012 5:47 PM *To:* Ali C.<= br> > Begen (abegen) *Cc:* Jonathan Lennox; payload@ietf.org
> <mailto:paylo= ad@ietf.org>; = draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>
>
>
> *Subject:* Re: [payload] WGLC for VP8 Payload

>
>
>
> Well he did not have a point in my mind. This is what he wrote.
>
>
>
> "The VP8 payload format's decision is a reasonable design choice -- > as compared to the H.264 SVC rules, it removes some ambiguity between<= br> > splice points and packet loss, giving decoders somewhat greater
> visibility as to what's going on in the bitstream, and also allows
> TL0PICIDX and KEYIDX to be orthogonal options because they increment > independently."
>
>
>
> The worst thing that can happen in a draft is to leave ambiguity,
> which we don't have in the current draft. However if we do it the way<= br> > H.264 SVC do we could introduce such ambiguity
>
>
>
> On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen)
> <abegen@cisco.com <mailto:abegen@cisco.com>> wrote:
>
> Are you at least planning to put some text around the point Jonathan > brought up?
>
>
>
> *From: *Patrik Westin <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>> *Reply-To: *"pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>" <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>> *Date: *Friday, December 14, 2012 4:53
> PM
>
>
> *To: *"Ali C. Begen" <abegen@cisco.com <mailto:abegen@cisco.com>>
>
> *Cc: *Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>>, "draft-ietf-payload-vp8@tools.ietf.org<= br> > <mailto:draft-ietf-payload-vp8@tools.ietf.org>"
> <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>> >
>
> *Subject: *Re: [payload] WGLC for VP8 Payload

>
>
>
> Trying to send this again since my previous message did not reach the<= br> > list.
>
> Thanks for pointing out the inconsistency. We've submitted a new
> draft that fixes that problem.
>
>
> The second issue was intentional. We'll keep it this way.
>
>
>
> On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen)
> <abegen@cisco.com <mailto:abegen@cisco.com>> wrote:
>
> Thanks, the authors just rev'ed the draft to fix the first issue. I > hope they will address the second issue first in the list and then
> reflect the agreement in the next revision. I will hold on to the doc<= br> > write-up till then.
>
>
> -acbegen
>
> -----Original Message----- From: Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>>

>
> Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen"
> <abegen@cisco= .com <mailto:a= begen@cisco.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>> Cc: "draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"
> <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>>

>
> Subject: RE: [payload] WGLC for VP8 Payload
>
>> Hi, Ali --
>>
>> I just wanted to make sure the issue had been considered; if the >> WG agrees that the current design is okay given the limitations >> I've mentioned, I'm not going to object.
>>
>> Discussion of the issue might be helpful in the document.
>>
>> -----Original Message----- From: Ali C. Begen (abegen)
>> [mailto:abeg= en@cisco.com <mailto:abegen@cisco.com>] Sent: Tuesday,

>> December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org
>> <mailto:p= ayload@ietf.org> Cc: = draft-ietf-payload-vp8@tools.ietf.org
>> <mailto:draft-ietf-payload-vp8@tools.ietf.org> Su= bject: Re:

>> [payload] WGLC for VP8 Payload
>>
>> The first one should be fixed by the authors thru a quick revision= .
>> As for the second one, I will ask the authors reply. Also if there=
>> are others who strongly think one way or another, lets discuss it.=
>>
>> Jonathan, are you ok if the authors simply acknowledge this in the=
>> draft (assuming they agree with you) or do you actually not like >> this at all?
>>
>> -acbegen
>>
>> -----Original Message----- From: Jonathan Lennox
>> <jonath= an@vidyo.com <mailto:jonathan@vidyo.com>> Date: Tuesday,

>> December 11, 2012 11:49 AM To: "payload@ietf.org
>> <mailto:p= ayload@ietf.org>" <payload@ietf.org
>> <mailto:p= ayload@ietf.org>> Subject: Re: [payload] WGLC for VP8

>> Payload
>>
>>> Hi -- I have two comments on this draft. Sorry for being late.=
>>>
>>> First of all, an editorial matter: Section 6 says the format h= as
>>> no parameters, but section 6.1 lists two optional parameters >>> (max-fr and max-fs).
>>>
>>>
>>> Secondly, more substantively, I note that the payload format's=
>>> rules on KEYIDX and TL0PICIDX impose a fair bit of overhead on=
>>> boxes that wish to splice together VP8 streams, since both val= ues
>>> are required to always increment consecutively in a bitstream = (if
>>> they're being used).
>>>
>>> By contrast, the equivalent fields of the H.264 SVC payload >>> format (in the PACSI) just say that IDRPICID must be different= in
>>> consecutive IDR frames, without requiring that the value
>>> increment by 1; and TL0PICIDX resets to 0 on every IDR frame,<= br> >>> rather than carrying on continuously. (H.264's IDR frames are<= br> >>> analogous for these purposes to VP8's essential keyframes). >>>
>>> This means that an H.264 SVC splicer -- as long as it doesn't<= br> >>> get unlucky, such that the two streams it's splicing happen to=
>>> have identical IDRPICID values at the splice point -- can just=
>>> transition from one bitstream to another at any IDR frame.
>>>
>>> By contrast, following a splice, a VP8 splicer must re-write b= oth
>>> these fields for the rest of the lifetime of the stream, since=
>>> they each have only one valid possible value following the
>>> splice.
>>>
>>> The VP8 payload format's decision is a reasonable design choic= e
>>> -- as compared to the H.264 SVC rules, it removes some ambigui= ty
>>> between splice points and packet loss, giving decoders somewha= t
>>> greater visibility as to what's going on in the bitstream, and=
>>> also allows TL0PICIDX and KEYIDX to be orthogonal options beca= use
>>> they increment independently. However, I wanted to make sure >>> this had been considered explicitly by the working group, and = we
>>> had consensus that it was the right decision.
>>>
>>> (Note well disclaimer: Vidyo has an IPR declaration against th= e
>>> VP8 payload -- see <http://tracker.tools.ietf.org/ipr/162= 2/>.)
>>>
>>>
>>> On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:
>>>
>>>> I have not seen any comments on the list. Please review th= e
>>>> draft and post your comments on the list.
>>>>
>>>> Thanks. -acbegen
>>>>
>>>> -----Original Message----- From: "Ali C. Begen"
>>>> <= abegen@cisco.com <mailto:abegen@cisco.com>> Date: Monday,

>>>> November 19, 2012 3:15 PM To: "payload@ietf.org
>>>> <mailto:payload@ietf.org>" <payload@ietf.org
>>>> <mailto:payload@ietf.org>> Subject: [payload] WGLC for VP8

>>>> Payload
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We had a WGLC for this draft earlier this year and the= re have
>>>>> been a few updates to the document. I am starting a 2n= d
>>>>> WGLC. Please review and comment on the list by Decembe= r
>>>>> 10th.
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?incl= ude_tex
>
>>>>>
>>>> t=3D1
>>>>>
>>>> https://www.ietf.org/mailman/listinfo/payload<= br> >>>>
>>>
>>> -- Jonathan Lennox jonathan@vidyo.com
>>> <mailto:jonathan@vidyo.com>
>>>
>>>
>>> _______________________________________________ payload= mailing
>>> list pay= load@ietf.org <mailto:payload@ietf.org>

>>> https://www.ietf.org/mailman/listinfo/payload
>>
>
> _______________________________________________ payload mailing= list
> payload@ietf.org= <mailto:paylo= ad@ietf.org>

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



--
Jonathan Lennox
jonathan@vidyo.com

= --_000_91CF2B2B19514528BB4D5B569B22747Cvidyocom_-- From iesg-secretary@ietf.org Tue Jan 22 09:02: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 2A51B21F8A45; Tue, 22 Jan 2013 09:02: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=[AWL=0.000, 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 sz6vNwCjxspG; Tue, 22 Jan 2013 09:02:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B38221F8A8E; Tue, 22 Jan 2013 09:02:54 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130122170254.27403.89559.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 09:02:54 -0800 Cc: payload chair , payload mailing list , RFC Editor Subject: [payload] Protocol Action: 'RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)' to Proposed Standard (draft-ietf-avt-rtp-evrc-nw-10.txt) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 17:02:55 -0000 The IESG has approved the following document: - 'RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)' (draft-ietf-avt-rtp-evrc-nw-10.txt) as Proposed Standard This document is the product of the Audio/Video Transport Payloads Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avt-rtp-evrc-nw/ Technical Summary: This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. Working Group Summary: This document went through two working group last call. As a result of the first one there were proposals to add some technical changes that were consented in the second working group last call. Document Quality: This is a payload specification for a 3GPP2 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. RFC Editor Note (for -10): Please add a URL to this reference: OLD [4] "Enhanced Variable Rate Codec, Speech Service Options 3, 68, 70, and 73 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-D v3.0, October 2010. NEW [4] "Enhanced Variable Rate Codec, Speech Service Options 3, 68, 70, and 73 for Wideband Spread Spectrum Digital Systems", 3GPP2 C.S0014-D v3.0, October 2010, . From harald@alvestrand.no Fri Jan 25 03:16:26 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 7A09721F8895 for ; Fri, 25 Jan 2013 03:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 vHBktrsDVmb4 for ; Fri, 25 Jan 2013 03:16:25 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A11FB21F8880 for ; Fri, 25 Jan 2013 03:16:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A7C239E1C8 for ; Fri, 25 Jan 2013 12:16:22 +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 ZZZTI-2Ve5iY for ; Fri, 25 Jan 2013 12:16:14 +0100 (CET) Received: from [172.16.11.124] (unknown [195.70.5.235]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 073CE39E03B for ; Fri, 25 Jan 2013 12:16:13 +0100 (CET) Message-ID: <5102697B.2030407@alvestrand.no> Date: Fri, 25 Jan 2013 12:16:11 +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: payload@ietf.org References: <20130116214300.27292.59947.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] I-D Action: draft-ietf-avt-rtp-isac-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 11:16:26 -0000 On 01/17/2013 12:43 PM, Colin Perkins wrote: > On 16 Jan 2013, at 21:43, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. >> >> Title : RTP Payload Format for the iSAC Codec >> Author(s) : Tina le Grand >> Paul E. Jones >> Pascal Huart >> Turaj Zakizadeh Shabestary >> Harald Alvestrand >> Filename : draft-ietf-avt-rtp-isac-03.txt >> Pages : 15 >> Date : 2013-01-16 >> >> 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 > > One quick comment: the examples in Sections 6.1 and 6.2 use RFC 2119 language ("SHOULD"), but I don't think an example is the right place to define normative requirements for implementations. Can the RFC 2119 terms be removed from these sections (and possibly be replaced by references to a section where the response is defined)? > n The normative language corrsponding to these examples is in section 5, where the parameters are defined. This language has been unchanged (including the use of uppercase MAY and SHOULD) since the July 2009 version of this draft, so the comment's definitely late. I'll lowercase the terms in the next version; I don't see a need to do so before an IETF Last Call, but will take instructions from the chairs. Harald From harald@alvestrand.no Fri Jan 25 03:18:49 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 986F821F869A for ; Fri, 25 Jan 2013 03:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 xYw6hRD0qBoQ for ; Fri, 25 Jan 2013 03:18:49 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 13A4921F8499 for ; Fri, 25 Jan 2013 03:18:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C08339E1C9 for ; Fri, 25 Jan 2013 12:18:48 +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 iO1WPVVr3Mi7 for ; Fri, 25 Jan 2013 12:18:47 +0100 (CET) Received: from [172.16.11.124] (unknown [195.70.5.235]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1D91139E1C8 for ; Fri, 25 Jan 2013 12:18:47 +0100 (CET) Message-ID: <51026A16.4090302@alvestrand.no> Date: Fri, 25 Jan 2013 12:18:46 +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: "payload@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [payload] New version of the iSAC internet-draft 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, 25 Jan 2013 11:18:49 -0000 As you have seen, there is a new version of the iSAC I-D available. I believe it addresses all comments that were made during WG Last Call, and that it's ready for IETF Last Call - but it does add some new information, so I expect that people will want at least a little time to read it and see that their comments are addressed. I'll await further instructions from the chairs. Harald From csp@csperkins.org Fri Jan 25 04:06:02 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 51B4B21F8A41 for ; Fri, 25 Jan 2013 04:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 mcNWc9NUoJ8Z for ; Fri, 25 Jan 2013 04:06:01 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9C721F8862 for ; Fri, 25 Jan 2013 04:06:01 -0800 (PST) Received: from [130.209.247.112] (helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Tyi2S-0005Zt-A2; Fri, 25 Jan 2013 12:05:44 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <5102697B.2030407@alvestrand.no> Date: Fri, 25 Jan 2013 12:05:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6B0380A8-644E-492E-A921-6A18CEFE0B9D@csperkins.org> References: <20130116214300.27292.59947.idtracker@ietfa.amsl.com> <5102697B.2030407@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -13 X-Mythic-Debug: Threshold = On = Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-avt-rtp-isac-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 12:06:02 -0000 On 25 Jan 2013, at 11:16, Harald Alvestrand wrote: > On 01/17/2013 12:43 PM, Colin Perkins wrote: >> On 16 Jan 2013, at 21:43, Internet-Drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Audio/Video Transport Payloads = Working Group of the IETF. >>>=20 >>> 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-03.txt >>> Pages : 15 >>> Date : 2013-01-16 >>>=20 >>> 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). >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-isac >>=20 >> One quick comment: the examples in Sections 6.1 and 6.2 use RFC 2119 = language ("SHOULD"), but I don't think an example is the right place to = define normative requirements for implementations. Can the RFC 2119 = terms be removed from these sections (and possibly be replaced by = references to a section where the response is defined)? >> n > The normative language corrsponding to these examples is in section 5, = where the parameters are defined. This language has been unchanged = (including the use of uppercase MAY and SHOULD) since the July 2009 = version of this draft, so the comment's definitely late. >=20 > I'll lowercase the terms in the next version; I don't see a need to do = so before an IETF Last Call, but will take instructions from the chairs. Just to be clear: no objections to normative language in Section 5, or = in the start of Section 6 where the mapping is defined, but I believe it = shouldn't be used in the examples in Sections 6.1 and 6.2. And no, I don't see any need to do this before IETF last call. It's a = nit after all. --=20 Colin Perkins http://csperkins.org/ From ron.even.tlv@gmail.com Wed Jan 30 00:53:58 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 5844821F88CB; Wed, 30 Jan 2013 00:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.282 X-Spam-Level: X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[AWL=2.317, 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 1WkJtNQR0k3G; Wed, 30 Jan 2013 00:53:57 -0800 (PST) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 38F0C21F8691; Wed, 30 Jan 2013 00:53:57 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id c50so678757eek.16 for ; Wed, 30 Jan 2013 00:53:56 -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:content-transfer-encoding:x-mailer:thread-index :content-language; bh=hJxpLxfinh7rPKvwgLktaDi7MoFU8A3i/pnV7O0Qmyo=; b=YXu7kxVGKGPOZjdpOY4azGjYMIKMa4bGF3ymVwZoJi94269Jw2zgc8Ey0q2nUAPEre ralijQofun3cQLGDAN8q5AilRim8RzMVJoRwFg1xI31iA2+U+paBB9puzBRZDz3dcGVD 89PAo9vp9u0t25qfZyjLW60bRwR5zB1GWy7FN+Xm0UeuAxJb6YLo48p12xhvunVQ2bV/ FUNcIsnFN+XwzzTvPu2Tplkti5otiOxk6uBrstzjlt6J2yvxv4q9dnixLSuFBb5cwspG rs7EOc2vrokNMw0E4RYIi+a3DIcqmwc5MeNazFOF+QxnmKfYEOXhEI0MjziYtAt7gBRi bq3A== X-Received: by 10.14.178.196 with SMTP id f44mr13101904eem.14.1359536036363; Wed, 30 Jan 2013 00:53:56 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id 6sm913548eea.3.2013.01.30.00.53.53 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 30 Jan 2013 00:53:55 -0800 (PST) From: "Roni Even" To: , Date: Wed, 30 Jan 2013 10:51:02 +0200 Message-ID: <011e01cdfec6$f1255db0$d3701910$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: Ac398b9Q6HF3wCKyQkupHpSzS9IZRA== Content-Language: en-us Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-avt-rtp-isac-03.txt -review 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, 30 Jan 2013 08:53:58 -0000 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. Pleas not the nit and the one from Collin and fix it after the IETF LC Roni -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: 16 January, 2013 11:43 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-isac-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for the iSAC Codec Author(s) : Tina le Grand Paul E. Jones Pascal Huart Turaj Zakizadeh Shabestary Harald Alvestrand Filename : draft-ietf-avt-rtp-isac-03.txt Pages : 15 Date : 2013-01-16 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avt-rtp-isac-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From ron.even.tlv@gmail.com Wed Jan 30 01: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 5538121F8613 for ; Wed, 30 Jan 2013 01:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=1.631, 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 7KWIVvhfoMXa for ; Wed, 30 Jan 2013 01:49:03 -0800 (PST) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id 293C821F85E7 for ; Wed, 30 Jan 2013 01:49:03 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id a12so604986eaa.13 for ; Wed, 30 Jan 2013 01:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=JFNcQ8mJnoLChi4KzAic7VXozcynHLbVrqg3BDpG8Qo=; b=JoyM3hH0UAkMOeohwt46MWoV8w+wJsCMg7YIHp0Gld2V8+9fvm1Mn9iTiEo8QH/xmW Cbq8XgoPb6IJRnKkU3xpIIew3Q8K0I2vdxSZg+hXxTARhoL5wXpV81ukyzeQMnd19u5y Jyq7bTl3OAfYtbqsuUjgIC8bIWId9PV9M9cfhtBZnFZiiN74mCJdHaA+mTzMiwx8/9zz M6DGO+SiFmJJxjSdiLQUc03VlMP0utxLSMihVP/KUb86+f5HRfjRjafyxI8mQIttseqf hBl9ZEae1NNEFdhTNaDLXJ1i/o8MTLlQv9UUN/mQ1v9csX8OXe7YQWSZzQqkYeKkr/5H BF3g== X-Received: by 10.14.218.7 with SMTP id j7mr13712134eep.0.1359539341822; Wed, 30 Jan 2013 01:49:01 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id 3sm1110049eej.6.2013.01.30.01.48.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 30 Jan 2013 01:49:00 -0800 (PST) From: "Roni Even" To: Date: Wed, 30 Jan 2013 11:46:07 +0200 Message-ID: <012a01cdfece$a2d0bf80$e8723e80$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012B_01CDFEDF.665C2790" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac3+zpGu26SFn1aAQL2bxs6jX/9DGw== Content-Language: en-us Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-isac-02 - review of 03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 09:49:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012B_01CDFEDF.665C2790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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_012B_01CDFEDF.665C2790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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_012B_01CDFEDF.665C2790-- From Lindsay@worldcastsystems.com Thu Jan 31 06:36:14 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 C542321F87D5 for ; Thu, 31 Jan 2013 06:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 LfVVhicNgYha for ; Thu, 31 Jan 2013 06:36:01 -0800 (PST) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id D6CAD21F85A1 for ; Thu, 31 Jan 2013 06:36:00 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Jan 2013 14:35:58 -0000 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02D580CF@APTSBS.apt.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-lindsay-payload-rtp-aptx-00 Thread-Index: Ac3/tGfZbbs/xCrXSbSreyQjqpUpmQACjV5A From: "John Lindsay" To: Cc: Foerster@worldcastsystems.com Subject: [payload] draft-lindsay-payload-rtp-aptx-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:36:14 -0000 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.=20 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