From Even.roni@huawei.com Sat Aug 6 01:08:30 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F6421F87BC for ; Sat, 6 Aug 2011 01:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 D5MBsl+i4J2o for ; Sat, 6 Aug 2011 01:08:29 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id ADBF321F87AF for ; Sat, 6 Aug 2011 01:08:29 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPH00NDJYMN15@szxga04-in.huawei.com> for avtext@ietf.org; Sat, 06 Aug 2011 16:08:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPH00DXLYMN02@szxga04-in.huawei.com> for avtext@ietf.org; Sat, 06 Aug 2011 16:08:47 +0800 (CST) Received: from windows8d787f9 ([109.65.17.245]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LPH00FP5YMDHU@szxml11-in.huawei.com>; Sat, 06 Aug 2011 16:08:47 +0800 (CST) Date: Sat, 06 Aug 2011 11:05:43 +0300 From: Roni Even In-reply-to: <4E307C46.20003@ericsson.com> To: 'Magnus Westerlund' , avtext@ietf.org Message-id: <002001cc540f$aa0552e0$fe0ff8a0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AcxMoCg1zHK1NMpuRWycaxlbK2MenQHb1ylQ References: <4E307C46.20003@ericsson.com> Subject: Re: [avtext] Confirming WG consensus on draft-xia-avtext-splicing-for-rtp-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 08:08:30 -0000 Hi, I support this consensus and would like to see this work go forward Roni Even > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Thursday, July 28, 2011 12:00 AM > To: avtext@ietf.org > Subject: [avtext] Confirming WG consensus on = draft-xia-avtext-splicing- > for-rtp-00 >=20 > WG, >=20 > In todays AVTEXT WG session we had some discussion on the way forward > for the splicing solution. We did ask two consensus questions. >=20 > There was consensus to use mixer in user detectable case. >=20 > There was consensus to use mixer also in the user non-detectable case. >=20 > In other words using mixers in all cases of splicing. >=20 > This email is to confirm this WG consensus decision please provide any > comments within 2 weeks. >=20 > Magnus Westerlund > WG Chair >=20 >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From mramalho@cisco.com Wed Aug 10 09:41:41 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5932521F8A80; Wed, 10 Aug 2011 09:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXKAkddwUNvx; Wed, 10 Aug 2011 09:41:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E25F021F8A7D; Wed, 10 Aug 2011 09:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=16327; q=dns/txt; s=iport; t=1312994531; x=1314204131; h=mime-version:subject:date:message-id:from:to; bh=96lxnfSnmD8hW6B7ZW/8ER8b6EZs8R0EnIruqGR0p58=; b=UhlTwAzpew9EN7KQaYmpQMIalzKLGTe2cocrutIUGnwpRYGXAlOBNbOa RjXWYhjSpJDzwW2Y0wLVO4SrAl3ACBaM9U5Qm0MJL8M8k9nbP53k/oBcq eyKWlyibPuMqAQMDvsFlSsAKYs8y4noe5KHf+4aKqhNtwCnofy1kSxVm6 U=; X-Files: image001.gif, image002.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJa0Qk6tJV2Y/2dsb2JhbAA/A4JNpGl3gUIBAQMFAQwBCQkIAQI0IwQBJQEBAwYXAQcBBRAEAgkgEgEEAREBCBqHUJ9VAZ5UAoM+gidfBIddg0KCaIoVi3g X-IronPort-AV: E=Sophos;i="4.67,351,1309737600"; d="gif'147?scan'147,208,217,147";a="11819041" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 10 Aug 2011 16:42:10 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7AGgAKT022300; Wed, 10 Aug 2011 16:42:10 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 11:42:09 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CC577C.726454AF" Date: Wed, 10 Aug 2011 11:42:04 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A00465696D@XMB-RCD-209.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progressing draft-ramalho-payload-g7110-00 Thread-Index: AcxXfG9W/5jtSQ/AQb2T/Bl/207wew== From: "Michael Ramalho (mramalho)" To: , X-OriginalArrivalTime: 10 Aug 2011 16:42:09.0475 (UTC) FILETIME=[72754130:01CC577C] Subject: [avtext] Progressing draft-ramalho-payload-g7110-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 16:41:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC577C.726454AF Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC577C.726454AF" ------_=_NextPart_002_01CC577C.726454AF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear AVTEXT and PAYLOAD list members, =20 At IETF 81 I presented the initial draft for G.711.0 payload format (draft-ramalho-payload-g7110-00). This email solicits opinions for continuing the work in this draft. =20 This draft had the usual detail expected in a payload format draft PLUS some recommendations and use cases for employing the (lossless and stateless) G.711.0 compression "in the middle" of an end-to-end G.711 call/session. =20 The rough consensus I interpreted from presenting the G.711.0 draft was that this draft should be split into two drafts: =20 1 - A "G.711.0 only" payload format draft (mostly the existing draft without Section 6). =20 and =20 2 - A "G.711.0 use cases / best practices" draft describing use of G.711.0 in the middle of an end-to-end G.711 call (mostly Section 6). =20 >>>ISSUE 1: Any objection to this partitioning or other suggestion? =20 Furthermore, it has been suggested that the former be a AVT PAYLOAD draft (e.g. draft-ramalho-payload-g7110-01) and the latter be a AVT EXT draft (e.g., draft-ramalho-avtext-g7110usecases-00). =20 >>>>ISSUE 2: Any objection to partitioning the draft into two drafts targeted for two different IETF AVT WGs or other suggestion? =20 The idea (which I agree with) is that the payload draft be targeted to be an eventual standards track RFC and the avtext draft be targeted to be an informational RFC. This suggestion was only briefly mentioned at the meeting, but was supported in my discussions afterwards. =20 >>>>ISSUE 3: Any comments on this goal? =20 Assuming the partitioning proposed above is accepted, the only significant open items for the G.711.0 payload format draft are: =20 OPEN ITEM 1 - Is the specification of multiple G.711.0 "channels" within a single G.711.0 RTP session desired? If so, is the proposed method acceptable (reserving a presently unused "prefix code" as a channel delimiter and changing the decoding heuristic in Section 4.2.3)? =20 and =20 OPEN ITEM 2 - The specification of the storage mode for long recordings. =20 >>>>ISSUE 4: Any commentary on the above issues are welcome. =20 Thanks in advance for any comments or suggestions you have. =20 Michael Ramalho =20 =20 Michael Ramalho Technical Leader Product Development mramalho@cisco.com =20 Phone: +1 919 476 2038 Mobile: +1 941 544 2844 Cisco Systems, Inc. 4564 Tuscana Drive Sarasota, FL 34241-4201 United States http://ramalho.webhop.info Skype: mramalho_mar42 =20 =20 Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 =20 =20 ------_=_NextPart_002_01CC577C.726454AF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear AVTEXT and PAYLOAD list = members,

 

At IETF 81 I presented the initial draft for = G.711.0 payload format (draft-ramalho-payload-g7110-00). This email solicits opinions = for continuing the work in this draft.

 

This draft had the usual detail expected in a = payload format draft PLUS some recommendations and use cases for employing the = (lossless and stateless) G.711.0 compression “in the middle” of an = end-to-end G.711 call/session.

 

The rough consensus I interpreted from presenting = the G.711.0 draft was that this draft should be split into two = drafts:

 

1 – A “G.711.0 only” payload = format draft (mostly the existing draft without Section 6).

 

and

 

2 – A “G.711.0 use cases / best = practices” draft describing use of G.711.0 in the middle of an end-to-end G.711 = call (mostly Section 6).

 

>>>ISSUE 1: Any objection to this = partitioning or other suggestion?

 

Furthermore, it has been suggested that the former = be a AVT PAYLOAD draft (e.g. draft-ramalho-payload-g7110-01) and the latter be a = AVT EXT draft (e.g., draft-ramalho-avtext-g7110usecases-00).

 

>>>>ISSUE 2: Any objection to = partitioning the draft into two drafts targeted for two different IETF AVT WGs or other suggestion?

 

The idea (which I agree with) is that the payload = draft be targeted to be an eventual standards track RFC and the avtext draft be = targeted to be an informational RFC. This suggestion was only briefly mentioned = at the meeting, but was supported in my discussions afterwards.

 

>>>>ISSUE 3: Any comments on this = goal?

 

Assuming the partitioning proposed above is = accepted, the only significant open items for the G.711.0 payload format draft = are:

 

OPEN ITEM 1 – Is the specification of = multiple G.711.0 “channels” within a single G.711.0 RTP session desired? If = so, is the proposed method acceptable (reserving a presently unused = “prefix code” as a channel delimiter and changing the decoding heuristic = in Section 4.2.3)?

 

and

 

OPEN ITEM 2 – The specification of the = storage mode for long recordings.

 

>>>>ISSUE 4: Any commentary on the = above issues are welcome.

 

Thanks in advance for any comments or suggestions = you have.

 

Michael Ramalho

 

3D"http://www.cisco.com/swa/i/logo.gif"

= Michael Ramalho
Technical Leader
Product Development
mramalho@cisco.com
Phone: +1 919 476 2038
Mobile: +1 941 544 2844

= Cisco Systems, Inc.
4564 Tuscana Drive
Sarasota, FL 34241-4201
United States
http://ramalho.webhop.info
Skype: mramalho_mar42

 

 

3D"ThinkThink before you print.


This email may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact the sender = by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/= cri/index.html

 

 

------_=_NextPart_002_01CC577C.726454AF-- ------_=_NextPart_001_01CC577C.726454AF Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CC577C.726454AF Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CC577C.726454AF-- From harada.noboru@lab.ntt.co.jp Sat Aug 13 18:46:52 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133C221F8A4F; Sat, 13 Aug 2011 18:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.085 X-Spam-Level: X-Spam-Status: No, score=0.085 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AnntNWgBh1Y; Sat, 13 Aug 2011 18:46:50 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2C421F8A36; Sat, 13 Aug 2011 18:46:50 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.14.5/8.14.5) with ESMTP id p7E1lNcH027457; Sun, 14 Aug 2011 10:47:23 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 1D3856D67; Sun, 14 Aug 2011 10:47:23 +0900 (JST) Received: from imss1.kecl.ntt.co.jp (imss1.kecl.ntt.co.jp [129.60.199.16]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 09B756D5D; Sun, 14 Aug 2011 10:47:23 +0900 (JST) Received: from imss1.kecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by postfix-imss71 (Postfix) with ESMTP id D3EC0E73E3; Sun, 14 Aug 2011 10:47:22 +0900 (JST) Received: from lab-pop.k.ecl.ntt.co.jp (lab-pop1.k.ecl.ntt.co.jp [129.60.199.78]) by imss1.kecl.ntt.co.jp (Postfix) with ESMTP id C417DE7380; Sun, 14 Aug 2011 10:47:22 +0900 (JST) Received: from [129.60.199.172] (vpn-spl172.cslab.kecl.ntt.co.jp [129.60.199.172]) by lab-pop.k.ecl.ntt.co.jp (Postfix) with SMTP id 9EF379404D; Sun, 14 Aug 2011 10:47:22 +0900 (JST) Date: Sun, 14 Aug 2011 10:47:22 +0900 From: Noboru Harada To: "Michael Ramalho (mramalho)" , , In-Reply-To: <999109E6BC528947A871CDEB5EB908A00465696D@XMB-RCD-209.cisco.com> References: <999109E6BC528947A871CDEB5EB908A00465696D@XMB-RCD-209.cisco.com> Message-Id: <20110814104721.2013.24F8F98F@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.01 [ja] Cc: avtext@ietf.org, payload@ietf.org Subject: Re: [avtext] Progressing draft-ramalho-payload-g7110-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: harada.noboru@lab.ntt.co.jp List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 01:46:52 -0000 Dear Michael and all, Thanks for taking care of the G.711.0 payload format issues. According to the ISSUES 1 and 2, I'm fine with the proposal to have two separated documents. For ISSUE 3, please see my comments below. > >>>>ISSUE 3: Any comments on this goal? > > Assuming the partitioning proposed above is accepted, the only > significant open items for the G.711.0 payload format draft are: > > OPEN ITEM 1 - Is the specification of multiple G.711.0 "channels" within > a single G.711.0 RTP session desired? If so, is the proposed method > acceptable (reserving a presently unused "prefix code" as a channel > delimiter and changing the decoding heuristic in Section 4.2.3)? > > and > > OPEN ITEM 2 - The specification of the storage mode for long recordings. For OPEN ITEM 1, I'm not fully confident about that supporting multiple G.711.0 channels is really useful. As stated in the current draft, I'm not sure if there is any real application need to have more than one G.711 channel per a RTP session. I have never seen such multi-channel implementation in traditional G.711 systems. For teleconference applications, there may be several alternatives such as down-mix all channels into one channel at MCU server or mesh connection using NxN RTP sessions. Note that I'm fine with having the function if someone could show us that there is strong need and show us reasonable application scenarios. According to the proposed method, I don't think any channel delimiter required for the channel separation if we make use of given "ptime" and "channels" information. With following definition, no channel delimiter is needed. We can just decode all samples using the current decoding heuristic in Section 4.2.3 and then separate decoded samples. ---------------------------------------------------------- | left channel (160 samples) | right channel (160 samples) | | (G.711.0 frames +padding) | (G.711.0 frames +padding) | ---------------------------------------------------------- I believe that this number of channels issue should not be solved in G.711.0 bitstream level but should be solved in RTP payload level. Even though there are some RESERVED magic numbers available in the G.711.0 specification, we should restrict us to introduce as little magic numbers as possible for solving RTP payload issues. > OPEN ITEM 2 - The specification of the storage mode for long recordings. According to the storage mode, I had a discussion with some experts who are developing some VoIP services. They said that supporting 2-channel may be helpful for the storage mode. There is a need to store recorded down-link and up-link data into one file (e.g., recording conversation between a customer and an operator for some call-center application). Other comments on sections 7.1 and 7.2: We may want to amend ITU-T Rec. G.711.0 reference software in order to add a support of "0x01" defined in Section 7.1 G.711.0 Erasure Frame because implementing it without changing the G.711.0 decoder is quite complicated. --- The magic number for G.711.0 A-law corresponds to the ASCII character string "#!G7110A\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x30 0x41 0x0A". Likewise, the magic number for G.711.0 MU-law corresponds to the ASCII character string "#!G7110M\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x4E 0x4D 0x0A". --- I have no strong opinion but I think we'd better think of an advantage of using any RESERVED magic number for the G.711.0 Storage Mode header instead of "#". Starting from "#" looks good but "#" is already used as a pre-fix in the G.711.0 specification. Which means the short recordings storage mode file will never be able to be decoded by the ITU-T G.711.0 reference software. If we assigned any RESERVED prefix such as "0x01" or "0x47" as the first byte of the file, we could add the support to the ITU-T G.711.0 reference software (perhaps, as an informative appendix). Note that only the difference between the short recordings storage mode file and the file that the G.711.0 reference software generates is existence of this header part. On the other hand, this may not be a big issue because we can assign an unique file extension for the file so that the application can recognize it is the storage mode file. What do you think of it? Best Regards, Noboru > Dear AVTEXT and PAYLOAD list members, > > > > At IETF 81 I presented the initial draft for G.711.0 payload format > (draft-ramalho-payload-g7110-00). This email solicits opinions for > continuing the work in this draft. > > > > This draft had the usual detail expected in a payload format draft PLUS > some recommendations and use cases for employing the (lossless and > stateless) G.711.0 compression "in the middle" of an end-to-end G.711 > call/session. > > > > The rough consensus I interpreted from presenting the G.711.0 draft was > that this draft should be split into two drafts: > > > > 1 - A "G.711.0 only" payload format draft (mostly the existing draft > without Section 6). > > > > and > > > > 2 - A "G.711.0 use cases / best practices" draft describing use of > G.711.0 in the middle of an end-to-end G.711 call (mostly Section 6). > > > > >>>ISSUE 1: Any objection to this partitioning or other suggestion? > > > > Furthermore, it has been suggested that the former be a AVT PAYLOAD > draft (e.g. draft-ramalho-payload-g7110-01) and the latter be a AVT EXT > draft (e.g., draft-ramalho-avtext-g7110usecases-00). > > > > >>>>ISSUE 2: Any objection to partitioning the draft into two drafts > targeted for two different IETF AVT WGs or other suggestion? > > > > The idea (which I agree with) is that the payload draft be targeted to > be an eventual standards track RFC and the avtext draft be targeted to > be an informational RFC. This suggestion was only briefly mentioned at > the meeting, but was supported in my discussions afterwards. > > > > >>>>ISSUE 3: Any comments on this goal? > > > > Assuming the partitioning proposed above is accepted, the only > significant open items for the G.711.0 payload format draft are: > > > > OPEN ITEM 1 - Is the specification of multiple G.711.0 "channels" within > a single G.711.0 RTP session desired? If so, is the proposed method > acceptable (reserving a presently unused "prefix code" as a channel > delimiter and changing the decoding heuristic in Section 4.2.3)? > > > > and > > > > OPEN ITEM 2 - The specification of the storage mode for long recordings. > > > > >>>>ISSUE 4: Any commentary on the above issues are welcome. > > > > Thanks in advance for any comments or suggestions you have. > > > > Michael Ramalho > > > > > > Michael Ramalho > Technical Leader > Product Development > mramalho@cisco.com > Phone: +1 919 476 2038 > Mobile: +1 941 544 2844 > > > > Cisco Systems, Inc. > 4564 Tuscana Drive > Sarasota, FL 34241-4201 > United States > http://ramalho.webhop.info > Skype: mramalho_mar42 > > > > > > Think before you print. > > > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive for the recipient), please contact > the sender by reply email and delete all copies of this message. > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > -------------------------------------- Noboru Harada NTT Communication Science Laboratories Tel: +81 46 240 3676 FAX: +81 46 240 3145 E-mail: harada.noboru@lab.ntt.co.jp -------------------------------------- From mramalho@cisco.com Mon Aug 15 18:59:22 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195EF21F8B9F; Mon, 15 Aug 2011 18:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcRlmfyI-pWw; Mon, 15 Aug 2011 18:59:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5542621F8B94; Mon, 15 Aug 2011 18:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=13042; q=dns/txt; s=iport; t=1313460007; x=1314669607; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=x0Veg8LFLF51NqkSXCH46k6A3bI6BLGc1NJHpzCQDr8=; b=UNgLtK/36yWbvF9ML/nSQcAvjP/zF3UW4YQianLQkQ1KNoZNe+w8SY5f Dsj/2K3H8TG2CluHFGA7UyDgkrniXQcpeatyj3X0nyu+poKiTHK+33KGX FcZdLk3XAUGo/gjsK5ZIBw8R03H3u4B2DhKEhghTHfYvkJSvpj2l/ogQa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4AAAbPSU6tJXG9/2dsb2JhbAA+A5hIj013gUABAQEBAgESAR0KMRMHAgICAQgRBAEBCwYXAQYBGisJCAEBBAESCBqHTgSaQAGfEwKDPoIoXwSHX5BIi30 X-IronPort-AV: E=Sophos;i="4.67,378,1309737600"; d="scan'208";a="13404198" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 16 Aug 2011 01:59:58 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7G1xw1F010744; Tue, 16 Aug 2011 01:59:58 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Aug 2011 20:59:57 -0500 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: Mon, 15 Aug 2011 20:59:55 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A0046EE5BB@XMB-RCD-209.cisco.com> In-Reply-To: <20110814104721.2013.24F8F98F@lab.ntt.co.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progressing draft-ramalho-payload-g7110-00 Thread-Index: AcxaJCIdXaYmx94SRyequDEZB0OntwBZqwHg References: <999109E6BC528947A871CDEB5EB908A00465696D@XMB-RCD-209.cisco.com> <20110814104721.2013.24F8F98F@lab.ntt.co.jp> From: "Michael Ramalho (mramalho)" To: , , X-OriginalArrivalTime: 16 Aug 2011 01:59:57.0549 (UTC) FILETIME=[330CD1D0:01CC5BB8] Subject: Re: [avtext] Progressing draft-ramalho-payload-g7110-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 01:59:22 -0000 Hi Noboru, Thank you for your reply. My answers are in-line below with "MAR:". Michael Ramalho -----Original Message----- From: Noboru Harada [mailto:harada.noboru@lab.ntt.co.jp]=20 Sent: Saturday, August 13, 2011 9:47 PM To: Michael Ramalho (mramalho); avtext@ietf.org; payload@ietf.org Cc: harada.noboru@lab.ntt.co.jp; avtext@ietf.org; payload@ietf.org Subject: Re: Progressing draft-ramalho-payload-g7110-00 Dear Michael and all, Thanks for taking care of the G.711.0 payload format issues. According to the ISSUES 1 and 2,=20 I'm fine with the proposal to have two separated documents. MAR: Thanks. For ISSUE 3, please see my comments below. > >>>>ISSUE 3: Any comments on this goal? >=20 > Assuming the partitioning proposed above is accepted, the only > significant open items for the G.711.0 payload format draft are: >=20 > OPEN ITEM 1 - Is the specification of multiple G.711.0 "channels" within > a single G.711.0 RTP session desired? If so, is the proposed method > acceptable (reserving a presently unused "prefix code" as a channel > delimiter and changing the decoding heuristic in Section 4.2.3)? > > and >=20 > OPEN ITEM 2 - The specification of the storage mode for long recordings. For OPEN ITEM 1, I'm not fully confident about that supporting multiple G.711.0 channels is really useful. As stated in the current draft, I'm not sure if there is any real application need to have more than one G.711 channel per a RTP session. I have never seen such multi-channel implementation in traditional G.711 systems. For teleconference applications, there may be several alternatives such as down-mix all channels into one channel at MCU server or mesh connection using NxN RTP sessions. Note that I'm fine with having the function if someone could show us that there is strong need and show us reasonable application scenarios. MAR: I also agree with your statement that only single channel G.711 is traditionally used. Indeed, when PT =3D [0 | 8] is used RFC 3551 states (in Table 4) that channels =3D=3D 1 by definition for G.711. MAR: However, if you look closely at RFC 3551 ... and you use a DYNAMIC payload type for G.711 ... you could specify channel > 1 ... because it defines how to pack the payload for "sample-based encodings" (RFC 3551, Section 4.3). MAR: There are some applications (e.g., acceleration of real-time protocols over WANs) whereby "multiplexing multiple G.711 flows" is desired. Granted there are few, if any, products AT PRESENT doing this. However, for those applications, I think a "standardized method" to put multiple channels in one payload is desirable. According to the proposed method, I don't think any channel delimiter required for the channel separation if we make use of given "ptime" and "channels" information. With following definition, no channel delimiter is needed. We can just decode all samples using the current decoding heuristic in Section 4.2.3 and then separate decoded samples. ---------------------------------------------------------- | left channel (160 samples) | right channel (160 samples) | | (G.711.0 frames +padding) | (G.711.0 frames +padding) | ---------------------------------------------------------- MAR: YOU ARE RIGHT! MAR: My brain was so fixated on "not needing ptime" in writing the draft (I documented ptime as an optional parameter Section 5.1) that I neglected to consider that IF you considered ptime, THEN you would know where the channel boundaries were by the decoded G.711 bitstream! MAR: I agree with you ... there no need to add a delimiter for the channels if you know ptime. On the next revision I will have: 1: channels as an optional parameter (as it is now) 2: if optional channels parameter is present and > 1, then ptime becomes a required parameter (not specified in the present draft). MAR: Regarding your channel example above, this is similar to RFC 3551 already specifies for channel demarcation of sample based recordings ... from RFC 3551 .... channels description channel 1 2 3 4 5 6 2 stereo l r 3 l r c 4 l c r S 5 Fl Fr Fc Sl Sr 6 l lc c r rc S I believe that this number of channels issue should not be solved in G.711.0 bitstream level but should be solved in RTP payload level. Even though there are some RESERVED magic numbers available in the G.711.0 specification, we should restrict us to introduce as little magic numbers as possible for solving RTP payload issues. MAR: Agreed. MAR: If channels > 1, the buffers in the G.711 decoding process may need to be larger ... but that is easily accomplished with some #defines in the given application. > OPEN ITEM 2 - The specification of the storage mode for long recordings. According to the storage mode, I had a discussion with some experts who are developing some VoIP services. They said that supporting 2-channel may be helpful for the storage mode. There is a need to store recorded down-link and up-link data into one file (e.g., recording conversation between a customer and an operator for some call-center application). MAR: I can see the use case. And given that one side of this communication is typically "silence/background noise", this is a good application for G.711.0. MAR: Anticipating two channels for this application - do we need to introduce a parameter of "ptime" in the storage mode definition (in addition to channels) so that the channel boundaries are self-evident? MAR: Can you formulate a proposal for the long recording case? Perhaps we can write in 1 second chunks with a length byte for that 1 second. Something like (for N chunks of G.711.0 data in the file and "|" indicating concatenation here): | A | B1 | C1 | B2 | C2 | B3 | C3 | ... | B(N-1) | C(N-1) | B(N) | ... where A =3D Fixed length Preamble (has codec name, ptime and = number_of_channels) Ci =3D Variable length G.711.0 data for as many channels specified in chunk i Bi =3D 16 bit uint {if (Bi =3D=3D 65535) Indicates EoF; //for B(N) above elseif (Bi =3D=3D 65534) Indicates End_segment; //for B(N-1) above where you //have less than one second of data //in the last segment else Number_of_bytes in Ci; } MAR: The above with Bi a uint16 would accommodate a worst-case 8 channels. Other comments on sections 7.1 and 7.2: We may want to amend ITU-T Rec. G.711.0 reference software in order to add a support of "0x01" defined in Section 7.1 G.711.0 Erasure Frame because implementing it without changing the G.711.0 decoder is quite=20 complicated. MAR: I wish I had thought of the concept of an erasure frame when we did the ITU-T standardization ;-(. MAR: Assuming that we make an open-source version of G.711.0 available, we could make that small change in the code (to recognize and generate an erasure frame). And at a later time update the ITU-T documents. --- The magic number for G.711.0 A-law corresponds to the ASCII character string "#!G7110A\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x30 0x41 0x0A". Likewise, the magic number for G.711.0 MU-law corresponds to the ASCII character string "#!G7110M\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x4E 0x4D 0x0A". --- I have no strong opinion but I think we'd better think of an advantage of using any RESERVED magic number for the G.711.0 Storage Mode header instead of "#". Starting from "#" looks good but "#" is already used as a pre-fix in the G.711.0 specification. Which means the short recordings storage mode file will never be able to be decoded by the ITU-T G.711.0 reference software. MAR: I am a little confused. The magic number I chose for the draft simply used the existing IETF convention (look at the RFCs for iLBC and similar one-channel codecs). Consider this as a "preamble" to the entire file. If we assigned any RESERVED prefix such as "0x01" or "0x47" as the first byte of the file, we could add the support to the ITU-T G.711.0 reference software (perhaps, as an informative appendix). Note that only the difference between the short recordings storage mode file and the file that the G.711.0 reference software generates is existence of this header part. On the other hand, this may not be a big issue because we can assign an unique file extension for the file so that the application can recognize it is the storage mode file. What do you think of it? MAR: For adoption in the IETF ... I think using their existing convention is always better (unless you have a killer fault with it). I think the IETF wants someone with a "storage mode decoder" to see something like "#!\n" as the preamble to any storage mode recoding. MAR: Considering the fact that the encoded sound files may need to be encrypted for some sensitive applications - having the "decoder name" inside the (encrypted) file instead of the header will be necessary (although it may also help in cryptographic attacks - I have an outstanding question on this with an crypto expert in Cisco). Best Regards, Noboru MAR: Thanks Noboru! > Dear AVTEXT and PAYLOAD list members, >=20 > =20 >=20 > At IETF 81 I presented the initial draft for G.711.0 payload format > (draft-ramalho-payload-g7110-00). This email solicits opinions for > continuing the work in this draft. >=20 > =20 >=20 > This draft had the usual detail expected in a payload format draft PLUS > some recommendations and use cases for employing the (lossless and > stateless) G.711.0 compression "in the middle" of an end-to-end G.711 > call/session. >=20 > =20 >=20 > The rough consensus I interpreted from presenting the G.711.0 draft was > that this draft should be split into two drafts: >=20 > =20 >=20 > 1 - A "G.711.0 only" payload format draft (mostly the existing draft > without Section 6). >=20 > =20 >=20 > and >=20 > =20 >=20 > 2 - A "G.711.0 use cases / best practices" draft describing use of > G.711.0 in the middle of an end-to-end G.711 call (mostly Section 6). >=20 > =20 >=20 > >>>ISSUE 1: Any objection to this partitioning or other suggestion? >=20 > =20 >=20 > Furthermore, it has been suggested that the former be a AVT PAYLOAD > draft (e.g. draft-ramalho-payload-g7110-01) and the latter be a AVT EXT > draft (e.g., draft-ramalho-avtext-g7110usecases-00). >=20 > =20 >=20 > >>>>ISSUE 2: Any objection to partitioning the draft into two drafts > targeted for two different IETF AVT WGs or other suggestion? >=20 > =20 >=20 > The idea (which I agree with) is that the payload draft be targeted to > be an eventual standards track RFC and the avtext draft be targeted to > be an informational RFC. This suggestion was only briefly mentioned at > the meeting, but was supported in my discussions afterwards. >=20 > =20 >=20 > >>>>ISSUE 3: Any comments on this goal? >=20 > =20 >=20 > Assuming the partitioning proposed above is accepted, the only > significant open items for the G.711.0 payload format draft are: >=20 > =20 >=20 > OPEN ITEM 1 - Is the specification of multiple G.711.0 "channels" within > a single G.711.0 RTP session desired? If so, is the proposed method > acceptable (reserving a presently unused "prefix code" as a channel > delimiter and changing the decoding heuristic in Section 4.2.3)? >=20 > =20 >=20 > and >=20 > =20 >=20 > OPEN ITEM 2 - The specification of the storage mode for long recordings. >=20 > =20 >=20 > >>>>ISSUE 4: Any commentary on the above issues are welcome. >=20 > =20 >=20 > Thanks in advance for any comments or suggestions you have. >=20 > =20 >=20 > Michael Ramalho >=20 > =20 >=20 > =20 >=20 > Michael Ramalho > Technical Leader > Product Development > mramalho@cisco.com =20 > Phone: +1 919 476 2038 > Mobile: +1 941 544 2844 >=20 >=20 >=20 > Cisco Systems, Inc. > 4564 Tuscana Drive > Sarasota, FL 34241-4201 > United States > http://ramalho.webhop.info > Skype: mramalho_mar42 >=20 > =20 >=20 > =20 >=20 > Think before you print. >=20 >=20 > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive for the recipient), please contact > the sender by reply email and delete all copies of this message. >=20 > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > =20 >=20 > =20 >=20 > =20 >=20 -------------------------------------- Noboru Harada NTT Communication Science Laboratories Tel: +81 46 240 3676 FAX: +81 46 240 3145 E-mail: harada.noboru@lab.ntt.co.jp -------------------------------------- From harada.noboru@lab.ntt.co.jp Tue Aug 16 09:10:11 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7741621F8C13; Tue, 16 Aug 2011 09:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.041 X-Spam-Level: X-Spam-Status: No, score=0.041 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMDjFpagerSx; Tue, 16 Aug 2011 09:10:08 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1162121F8C12; Tue, 16 Aug 2011 09:10:07 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.5/8.14.5) with ESMTP id p7GGAowc020073; Wed, 17 Aug 2011 01:10:50 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 762346D67; Wed, 17 Aug 2011 01:10:50 +0900 (JST) Received: from imss1.kecl.ntt.co.jp (imss1.kecl.ntt.co.jp [129.60.199.16]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 5A0256D66; Wed, 17 Aug 2011 01:10:50 +0900 (JST) Received: from imss1.kecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by postfix-imss71 (Postfix) with ESMTP id 31CD4E73E3; Wed, 17 Aug 2011 01:10:50 +0900 (JST) Received: from lab-pop.k.ecl.ntt.co.jp (lab-pop1.k.ecl.ntt.co.jp [129.60.199.78]) by imss1.kecl.ntt.co.jp (Postfix) with ESMTP id 247CAE7380; Wed, 17 Aug 2011 01:10:50 +0900 (JST) Received: from [129.60.199.172] (vpn-spl172.cslab.kecl.ntt.co.jp [129.60.199.172]) by lab-pop.k.ecl.ntt.co.jp (Postfix) with SMTP id 10C0F941F3; Wed, 17 Aug 2011 01:10:50 +0900 (JST) Date: Wed, 17 Aug 2011 01:10:50 +0900 From: Noboru Harada To: "Michael Ramalho (mramalho)" In-Reply-To: <999109E6BC528947A871CDEB5EB908A0046EE5BB@XMB-RCD-209.cisco.com> References: <20110814104721.2013.24F8F98F@lab.ntt.co.jp> <999109E6BC528947A871CDEB5EB908A0046EE5BB@XMB-RCD-209.cisco.com> Message-Id: <20110817011050.DA5D.24F8F98F@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.01 [ja] Cc: avtext@ietf.org, payload@ietf.org Subject: Re: [avtext] Progressing draft-ramalho-payload-g7110-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: harada.noboru@lab.ntt.co.jp List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:10:11 -0000 Dear Michael, Thanks for the comments. > MAR: I also agree with your statement that only single channel G.711 is > traditionally used. Indeed, when PT = [0 | 8] is used RFC 3551 states > (in Table 4) that channels == 1 by definition for G.711. > > MAR: However, if you look closely at RFC 3551 ... and you use a DYNAMIC > payload type for G.711 ... you could specify channel > 1 ... because > it defines how to pack the payload for "sample-based encodings" > (RFC 3551, Section 4.3). > > MAR: There are some applications (e.g., acceleration of real-time > protocols > over WANs) whereby "multiplexing multiple G.711 flows" is desired. > Granted > there are few, if any, products AT PRESENT doing this. However, for > those > applications, I think a "standardized method" to put multiple channels > in one payload is desirable. If there was any strong need for the function, someone who desires the functionality would better propose a standardized method for "multiplexing multiple G.711 flows" within the G.711 payload first. Then we can discuss how to reflect the function in the G.711.0 payload based on the defined multiplexing multiple G.711 flows payload. This way, we can make sure what is the real requirements for the functionality. > MAR: I agree with you ... there no need to add a delimiter for the > channels > if you know ptime. On the next revision I will have: > > 1: channels as an optional parameter (as it is now) > 2: if optional channels parameter is present and > 1, then ptime becomes > a required parameter (not specified in the present draft). I'm fine with this proposal. > MAR: Regarding your channel example above, this is similar to RFC 3551 > already > specifies for channel demarcation of sample based recordings ... from > RFC > 3551 .... Note that this channel example proposed here is slightly different from what is described in RFC 3551 when any of channels contains more than one G.711.0 frames. > MAR: If channels > 1, the buffers in the G.711 decoding process may > need to be larger ... but that is easily accomplished with some #defines > in the given application. The G.711 decoding process does not require larger buffer size though buffer size for the decoded G.711 samples shall be large enough to accommodate the decoded samples, such as, "ptime octets" for each channels ("ptime * channels" octets in total). Therefore, we don't have to change the processing buffer size which the current G.711.0 reference software implementation uses. The bintstream can be processed frame by frame from the first frame to the last regardless if the bitstream contains multi-channel stream or not. > MAR: Can you formulate a proposal for the long recording case? Perhaps > we can write in 1 second chunks with a length byte for that 1 second. > Something like (for N chunks of G.711.0 data in the file and "|" > indicating concatenation here): > > | A | B1 | C1 | B2 | C2 | B3 | C3 | ... | B(N-1) | C(N-1) | B(N) | ... > where > > A = Fixed length Preamble (has codec name, ptime and number_of_channels) > > Ci = Variable length G.711.0 data for as many channels specified in > chunk i > > Bi = 16 bit uint > {if (Bi == 65535) > Indicates EoF; //for B(N) above > elseif (Bi == 65534) > Indicates End_segment; //for B(N-1) above where you > //have less than one > second of data > //in the last segment > else > Number_of_bytes in Ci; > } > > MAR: The above with Bi a uint16 would accommodate a worst-case 8 > channels. This proposal seems OK. I have no strong opinion on the long recording case payload. > MAR: For adoption in the IETF ... I think using their existing > convention > is always better (unless you have a killer fault with it). I think the > IETF > wants someone with a "storage mode decoder" to see something like > "#!\n" as the preamble to any storage mode recoding. I see your point. I agree. Current proposal is fine then. Best Regards, Noboru > Hi Noboru, > > Thank you for your reply. > > My answers are in-line below with "MAR:". > > Michael Ramalho > > -----Original Message----- > From: Noboru Harada [mailto:harada.noboru@lab.ntt.co.jp] > Sent: Saturday, August 13, 2011 9:47 PM > To: Michael Ramalho (mramalho); avtext@ietf.org; payload@ietf.org > Cc: harada.noboru@lab.ntt.co.jp; avtext@ietf.org; payload@ietf.org > Subject: Re: Progressing draft-ramalho-payload-g7110-00 > > Dear Michael and all, > > > Thanks for taking care of the G.711.0 payload format issues. > > According to the ISSUES 1 and 2, > I'm fine with the proposal to have two separated documents. > > MAR: Thanks. > > For ISSUE 3, please see my comments below. > > > >>>>ISSUE 3: Any comments on this goal? > > > > Assuming the partitioning proposed above is accepted, the only > > significant open items for the G.711.0 payload format draft are: > > > > OPEN ITEM 1 - Is the specification of multiple G.711.0 "channels" > within > > a single G.711.0 RTP session desired? If so, is the proposed method > > acceptable (reserving a presently unused "prefix code" as a channel > > delimiter and changing the decoding heuristic in Section 4.2.3)? > > > > and > > > > OPEN ITEM 2 - The specification of the storage mode for long > recordings. > > For OPEN ITEM 1, I'm not fully confident about that supporting multiple > G.711.0 channels is really useful. > > As stated in the current draft, I'm not sure if there is any real > application need to have more than one G.711 channel per a RTP session. > I have never seen such multi-channel implementation in traditional G.711 > systems. > > For teleconference applications, there may be several alternatives such > as down-mix all channels into one channel at MCU server or mesh > connection using NxN RTP sessions. > Note that I'm fine with having the function if someone could show us > that there is strong need and show us reasonable application scenarios. > > MAR: I also agree with your statement that only single channel G.711 is > traditionally used. Indeed, when PT = [0 | 8] is used RFC 3551 states > (in Table 4) that channels == 1 by definition for G.711. > > MAR: However, if you look closely at RFC 3551 ... and you use a DYNAMIC > payload type for G.711 ... you could specify channel > 1 ... because > it defines how to pack the payload for "sample-based encodings" > (RFC 3551, Section 4.3). > > MAR: There are some applications (e.g., acceleration of real-time > protocols > over WANs) whereby "multiplexing multiple G.711 flows" is desired. > Granted > there are few, if any, products AT PRESENT doing this. However, for > those > applications, I think a "standardized method" to put multiple channels > in one payload is desirable. > > According to the proposed method, I don't think any channel delimiter > required for the channel separation if we make use of given "ptime" and > "channels" information. > > With following definition, no channel delimiter is needed. > We can just decode all samples using the current decoding heuristic in > Section 4.2.3 and then separate decoded samples. > ---------------------------------------------------------- > | left channel (160 samples) | right channel (160 samples) | > | (G.711.0 frames +padding) | (G.711.0 frames +padding) | > ---------------------------------------------------------- > > MAR: YOU ARE RIGHT! > > MAR: My brain was so fixated on "not needing ptime" in writing the draft > (I documented ptime as an optional parameter Section 5.1) that I > neglected > to consider that IF you considered ptime, THEN you would know where the > channel boundaries were by the decoded G.711 bitstream! > > MAR: I agree with you ... there no need to add a delimiter for the > channels > if you know ptime. On the next revision I will have: > > 1: channels as an optional parameter (as it is now) > 2: if optional channels parameter is present and > 1, then ptime becomes > a required parameter (not specified in the present draft). > > MAR: Regarding your channel example above, this is similar to RFC 3551 > already > specifies for channel demarcation of sample based recordings ... from > RFC > 3551 .... > > > channels description channel > 1 2 3 4 5 6 > 2 stereo l r > 3 l r c > 4 l c r S > 5 Fl Fr Fc Sl Sr > 6 l lc c r rc S > > > I believe that this number of channels issue should not be solved in > G.711.0 bitstream level but should be solved in RTP payload level. > Even though there are some RESERVED magic numbers available in the > G.711.0 specification, we should restrict us to introduce as little > magic numbers as possible for solving RTP payload issues. > > MAR: Agreed. > > MAR: If channels > 1, the buffers in the G.711 decoding process may > need to be larger ... but that is easily accomplished with some #defines > in the given application. > > > OPEN ITEM 2 - The specification of the storage mode for long > recordings. > > According to the storage mode, I had a discussion with some experts who > are developing some VoIP services. > They said that supporting 2-channel may be helpful for the storage mode. > There is a need to store recorded down-link and up-link data into one > file (e.g., recording conversation between a customer and an operator > for some call-center application). > > MAR: I can see the use case. And given that one side of this > communication > is typically "silence/background noise", this is a good application for > G.711.0. > > MAR: Anticipating two channels for this application - do we need to > introduce a parameter of "ptime" in the storage mode definition > (in addition to channels) so that the channel boundaries are > self-evident? > > MAR: Can you formulate a proposal for the long recording case? Perhaps > we can write in 1 second chunks with a length byte for that 1 second. > Something like (for N chunks of G.711.0 data in the file and "|" > indicating concatenation here): > > | A | B1 | C1 | B2 | C2 | B3 | C3 | ... | B(N-1) | C(N-1) | B(N) | ... > where > > A = Fixed length Preamble (has codec name, ptime and number_of_channels) > > Ci = Variable length G.711.0 data for as many channels specified in > chunk i > > Bi = 16 bit uint > {if (Bi == 65535) > Indicates EoF; //for B(N) above > elseif (Bi == 65534) > Indicates End_segment; //for B(N-1) above where you > //have less than one > second of data > //in the last segment > else > Number_of_bytes in Ci; > } > > MAR: The above with Bi a uint16 would accommodate a worst-case 8 > channels. > > Other comments on sections 7.1 and 7.2: > > We may want to amend ITU-T Rec. G.711.0 reference software in order to > add a support of "0x01" defined in Section 7.1 G.711.0 Erasure Frame > because implementing it without changing the G.711.0 decoder is quite > complicated. > > MAR: I wish I had thought of the concept of an erasure frame when we did > the ITU-T standardization ;-(. > > MAR: Assuming that we make an open-source version of G.711.0 available, > we could make that small change in the code (to recognize and generate > an erasure frame). And at a later time update the ITU-T documents. > > --- > The magic number for G.711.0 A-law corresponds to the ASCII character > string "#!G7110A\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x30 0x41 > 0x0A". > Likewise, the magic number for G.711.0 MU-law corresponds to the ASCII > character string "#!G7110M\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x4E > 0x4D 0x0A". > --- > > I have no strong opinion but I think we'd better think of an advantage > of using any RESERVED magic number for the G.711.0 Storage Mode header > instead of "#". > Starting from "#" looks good but "#" is already used as a pre-fix in the > G.711.0 specification. > Which means the short recordings storage mode file will never be able to > be decoded by the ITU-T G.711.0 reference software. > > MAR: I am a little confused. The magic number I chose for the draft > simply > used the existing IETF convention (look at the RFCs for iLBC and similar > one-channel codecs). Consider this as a "preamble" to the entire file. > > If we assigned any RESERVED prefix such as "0x01" or "0x47" as the first > byte of the file, we could add the support to the ITU-T G.711.0 > reference software (perhaps, as an informative appendix). > Note that only the difference between the short recordings storage mode > file and the file that the G.711.0 reference software generates is > existence of this header part. > On the other hand, this may not be a big issue because we can assign an > unique file extension for the file so that the application can recognize > it is the storage mode file. > > What do you think of it? > > MAR: For adoption in the IETF ... I think using their existing > convention > is always better (unless you have a killer fault with it). I think the > IETF > wants someone with a "storage mode decoder" to see something like > "#!\n" as the preamble to any storage mode recoding. > > MAR: Considering the fact that the encoded sound files may need to be > encrypted for some sensitive applications - having the "decoder name" > inside > the (encrypted) file instead of the header will be necessary (although > it > may also help in cryptographic attacks - I have an outstanding question > on this with an crypto expert in Cisco). > > Best Regards, > > Noboru > > MAR: Thanks Noboru! > > > > Dear AVTEXT and PAYLOAD list members, > > > > > > > > At IETF 81 I presented the initial draft for G.711.0 payload format > > (draft-ramalho-payload-g7110-00). This email solicits opinions for > > continuing the work in this draft. > > > > > > > > This draft had the usual detail expected in a payload format draft > PLUS > > some recommendations and use cases for employing the (lossless and > > stateless) G.711.0 compression "in the middle" of an end-to-end G.711 > > call/session. > > > > > > > > The rough consensus I interpreted from presenting the G.711.0 draft > was > > that this draft should be split into two drafts: > > > > > > > > 1 - A "G.711.0 only" payload format draft (mostly the existing draft > > without Section 6). > > > > > > > > and > > > > > > > > 2 - A "G.711.0 use cases / best practices" draft describing use of > > G.711.0 in the middle of an end-to-end G.711 call (mostly Section 6). > > > > > > > > >>>ISSUE 1: Any objection to this partitioning or other suggestion? > > > > > > > > Furthermore, it has been suggested that the former be a AVT PAYLOAD > > draft (e.g. draft-ramalho-payload-g7110-01) and the latter be a AVT > EXT > > draft (e.g., draft-ramalho-avtext-g7110usecases-00). > > > > > > > > >>>>ISSUE 2: Any objection to partitioning the draft into two drafts > > targeted for two different IETF AVT WGs or other suggestion? > > > > > > > > The idea (which I agree with) is that the payload draft be targeted to > > be an eventual standards track RFC and the avtext draft be targeted to > > be an informational RFC. This suggestion was only briefly mentioned at > > the meeting, but was supported in my discussions afterwards. > > > > > > > > >>>>ISSUE 3: Any comments on this goal? > > > > > > > > Assuming the partitioning proposed above is accepted, the only > > significant open items for the G.711.0 payload format draft are: > > > > > > > > OPEN ITEM 1 - Is the specification of multiple G.711.0 "channels" > within > > a single G.711.0 RTP session desired? If so, is the proposed method > > acceptable (reserving a presently unused "prefix code" as a channel > > delimiter and changing the decoding heuristic in Section 4.2.3)? > > > > > > > > and > > > > > > > > OPEN ITEM 2 - The specification of the storage mode for long > recordings. > > > > > > > > >>>>ISSUE 4: Any commentary on the above issues are welcome. > > > > > > > > Thanks in advance for any comments or suggestions you have. > > > > > > > > Michael Ramalho > > > > > > > > > > > > Michael Ramalho > > Technical Leader > > Product Development > > mramalho@cisco.com > > Phone: +1 919 476 2038 > > Mobile: +1 941 544 2844 > > > > > > > > Cisco Systems, Inc. > > 4564 Tuscana Drive > > Sarasota, FL 34241-4201 > > United States > > http://ramalho.webhop.info > > Skype: mramalho_mar42 > > > > > > > > > > > > Think before you print. > > > > > > This email may contain confidential and privileged material for the > sole > > use of the intended recipient. Any review, use, distribution or > > disclosure by others is strictly prohibited. If you are not the > intended > > recipient (or authorized to receive for the recipient), please contact > > the sender by reply email and delete all copies of this message. > > > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > > > > > > > -------------------------------------- > Noboru Harada > NTT Communication Science Laboratories > Tel: +81 46 240 3676 > FAX: +81 46 240 3145 > E-mail: harada.noboru@lab.ntt.co.jp > -------------------------------------- -------------------------------------- Noboru Harada NTT Communication Science Laboratories Tel: +81 46 240 3676 FAX: +81 46 240 3145 E-mail: harada.noboru@lab.ntt.co.jp -------------------------------------- From mramalho@cisco.com Wed Aug 17 05:43:42 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0D021F8B52; Wed, 17 Aug 2011 05:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wozkN9NeEVUL; Wed, 17 Aug 2011 05:43:41 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 807B721F8ACA; Wed, 17 Aug 2011 05:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=3398; q=dns/txt; s=iport; t=1313585073; x=1314794673; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=FGV5eQZRT0g3NPtz1eMCcX2xxESXMDALJwQBeKKepDk=; b=W18k0JOLFWcryNqkxwq2ad6k2LmrjDOOGkQGtxI/+1iBpJvlbzI+SAe4 p0TPtuZrXcQhWdPE4O0y1oLO+59PwLGyQa1uuuYGAUDCPKz8+rqmHpbKC qe3E8uEU0NzcBl1XjCG1YOsANoskV57nqT5KpG51oSb3wEzlU5Wz+A1rM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADy3S06tJXHA/2dsb2JhbABCqGd3gUABAQEBAgESAR0KRAsCAQgiBhgGAVYBAQQBGhqHTpcuAZ8ohWlfBIdgkEiLfg X-IronPort-AV: E=Sophos;i="4.68,240,1312156800"; d="scan'208";a="13912696" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 17 Aug 2011 12:44:32 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7HCiWA5005875; Wed, 17 Aug 2011 12:44:32 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Aug 2011 07:44:31 -0500 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: Wed, 17 Aug 2011 07:44:25 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A0046EEA0E@XMB-RCD-209.cisco.com> In-Reply-To: <20110817011050.DA5D.24F8F98F@lab.ntt.co.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progressing draft-ramalho-payload-g7110-00 Thread-Index: AcxcLxOQZAnxkQWQSrOgR18a8L6KQAAC6HaQ References: <20110814104721.2013.24F8F98F@lab.ntt.co.jp> <999109E6BC528947A871CDEB5EB908A0046EE5BB@XMB-RCD-209.cisco.com> <20110817011050.DA5D.24F8F98F@lab.ntt.co.jp> From: "Michael Ramalho (mramalho)" To: , , X-OriginalArrivalTime: 17 Aug 2011 12:44:31.0976 (UTC) FILETIME=[6937CE80:01CC5CDB] Subject: Re: [avtext] Progressing draft-ramalho-payload-g7110-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 12:43:42 -0000 Hi Noboru, Thanks for your comments. Michael Ramalho > MAR: There are some applications (e.g., acceleration of real-time > protocols > over WANs) whereby "multiplexing multiple G.711 flows" is desired. > Granted > there are few, if any, products AT PRESENT doing this. However, for > those > applications, I think a "standardized method" to put multiple channels > in one payload is desirable. If there was any strong need for the function, someone who desires the functionality would better propose a standardized method for "multiplexing multiple G.711 flows" within the G.711 payload first. MAR: There are companies that are doing this (or planning to do this) type of multiplexing today for WAN acceleration. A characteristic of this type of product is to transport everything over UDP (yes, even TCP streams) in a tunnel and then congestion control the totality of UDP packets in the tunnel. The manner in which they do this is definitely "non-standard" in that they do things to "fake-out" the ends of the connections. In the case of TCP, they fake-out the state machines at the ends - thus the sequence numbers are even different in the TCP socket ends! [Although the basic end-to-end congestion control mechanisms of TCP - window sizes - are the same.] See next comment. Then we can discuss how to reflect the function in the G.711.0 payload based on the defined multiplexing multiple G.711 flows payload. This way, we can make sure what is the real requirements for the functionality. MAR: What I envision is that the association between the "channels" and the "RTP session endpoints" will be done in proprietary ways in this type of product. The capability we could give those designers is at least a standardized way to put multiple G.711.0 channels in one RTP payload. MAR: If there is an additional desire to standardize this application (multiplexing multiple G.711 or G.711.0 flows), we could go to mmusic to get input. The second draft I proposed (the "compression in the middle draft") could propose a particular method via header extensions ... but I have not thought that part out yet. MAR: IS there anyone out there on the avtext or payload lists have a comment here? Note that this channel example proposed here is slightly different from what is described in RFC 3551 when any of channels contains more than one G.711.0 frames. MAR: Not really ... as you state ... if the ptime of all the channels is identical ... then even if there are multiple G.711.0 frames per ptime for a given channel ... we should be OK. > MAR: If channels > 1, the buffers in the G.711 decoding process may > need to be larger ... but that is easily accomplished with some #defines > in the given application. The G.711 decoding process does not require larger buffer size though buffer size for the decoded G.711 samples shall be large enough to accommodate the decoded samples, such as, "ptime octets" for each channels ("ptime * channels" octets in total). MAR: Yep. That is what I meant to say. Therefore, we don't have to change the processing buffer size which=20 the current G.711.0 reference software implementation uses. The bintstream can be processed frame by frame from the first frame to the last regardless if the bitstream contains multi-channel stream or not. MAR: OK. From mramalho@cisco.com Sun Aug 21 10:10:10 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F5521F84E8; Sun, 21 Aug 2011 10:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqH9IsR2SBX3; Sun, 21 Aug 2011 10:10:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id ACCDF21F8A58; Sun, 21 Aug 2011 10:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=3302; q=dns/txt; s=iport; t=1313946651; x=1315156251; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Tm09NURkWTEbJ5HJYNPnYlJu0I4R4rekzOs7MkW9Es0=; b=JPOivz9iArx+nvYmwXz+oO1oEVKW2Mt3R0wtoNNb8BkX16AE+ihdzxzz aXv6lxqnzfRsYteyIkLaW5F7FJC+0lJLuOV3Qe/xBOCJ9NqoCmyF+uWzm xULL+j7cFWPsYiVFfnriucYzTPDGZ3ibVwQc2DieE3P7nAzZtidKxXMXK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8AAF07UU6tJV2b/2dsb2JhbABBmDGPYXeBQAEBAQEDAQEBDwEdCjQXBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAESCBqHU5c0AZ1qhWlfBIdgkEmLfw X-IronPort-AV: E=Sophos;i="4.68,259,1312156800"; d="scan'208";a="15118643" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 21 Aug 2011 17:10:47 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7LHAkJQ005901; Sun, 21 Aug 2011 17:10:46 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 21 Aug 2011 12:10:47 -0500 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: Sun, 21 Aug 2011 12:10:42 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A00478068C@XMB-RCD-209.cisco.com> In-Reply-To: <4E510A1F.5000708@jesup.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to bediscussed inAVTEXT Thread-Index: AcxgB9IQTFVPcgFRT6aMHkxxZMtp1QAGCBVg References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <4E510A1F.5000708@jesup.org> From: "Michael Ramalho (mramalho)" To: "Randell Jesup" , , X-OriginalArrivalTime: 21 Aug 2011 17:10:47.0140 (UTC) FILETIME=[44CF6240:01CC6025] Subject: Re: [avtext] [payload] draft-ramalho-payload-g7110-00 to bediscussed inAVTEXT X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 17:10:10 -0000 Randell, Thanks for the clarification. Small comment in-line below. Michael -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Randell Jesup Sent: Sunday, August 21, 2011 9:38 AM To: payload@ietf.org Subject: Re: [payload] draft-ramalho-payload-g7110-00 to bediscussed inAVTEXT On 7/26/2011 1:01 PM, Michael Ramalho (mramalho) wrote: > RE: "For one, just to be able to do this requires sniffing SDP " > > Not true. Virtually every implementation using G.711 I have found in > practice uses the STATIC payload type of 0 or 8 for G.711. > > Thus every RTP packet with PT =3D [ 0 | 8 ] can only have a G.711 payload > inside of it. Wrong. a=3Drtpmap:0 foo/8000 would cause payload 0 to be foo instead = of G.711 ulaw. Admittedly, I've never seen someone remap payload 0 - but they ARE=20 allowed to do so, and I can conceive of cases where someone might do so. Not likely, but=20 conceivable. Interesting. So an m-line such as .... m=3Daudio 49232 RTP/AVP 0 ... should not be mapped to PCMU until it is verified that there exists no remapping of PT =3D 0 via a a=3Drtpmap line within the m-line scope. Point taken ... and from RFC 3551: This profile reserves payload type numbers in the range 96-127 exclusively for dynamic assignment. Applications SHOULD first use values in this range for dynamic payload types. Those applications which need to define more than 32 dynamic payload types MAY bind codes below 96, in which case it is RECOMMENDED that unassigned payload type numbers be used first. However, the statically assigned payload types are default bindings and MAY be dynamically bound to new encodings if needed. Redefining payload types below 96 may cause incorrect operation if an attempt is made to join a session without obtaining session description information that defines the dynamic payload types. Given the logic on the RECOMMENDED sentence above ... it would seem that you would re-map the static types to the most probabilistically unused static payload type values ... which would probably make PT =3D 0 or PT = =3D 8 one of the last types to be chosen. Has anyone on the list has seen PT =3D 0 or PT =3D 8 be remapped to = other than PCMU or PCMA in practice? The RFC 3551 paragraph above seems to imply that PT 72 - 76 (reserved) may also be used ... even though they are "reserved" for a very good reason (to differentiate RTCP packets)? Thus, perhaps, the recommendation should read ... unassigned first ... then others excepting reserved PT (which should not be used). This allows people to get around the limited number of dynamic payloads, especially in the case of multiplexed RTP & RTCP (which restricts payloads further). Some uses require a fairly large number of payloads to encode variants of a codec (H.264),=20 which could cause someone to decide to remap static payloads. And as you mention indirectly, someone could put G.711 on other dynamic=20 payloads. --=20 Randell Jesup randell-ietf@jesup.org _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From keith.drage@alcatel-lucent.com Fri Aug 26 15:10:42 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13F821F87F0 for ; Fri, 26 Aug 2011 15:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.531 X-Spam-Level: X-Spam-Status: No, score=-105.531 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1WcjgKW0w31 for ; Fri, 26 Aug 2011 15:10:41 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5BF21F8770 for ; Fri, 26 Aug 2011 15:10:41 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p7QMBZ9X018453 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 27 Aug 2011 00:11:35 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 27 Aug 2011 00:11:35 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Sat, 27 Aug 2011 00:11:32 +0200 Thread-Topic: Proceedings from AVTEXT session in Quebec Thread-Index: AcxkPRyYOQ4YwC5SR5aG8+xI/QkicA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [avtext] Proceedings from AVTEXT session in Quebec X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 22:10:43 -0000 (As WG cochair) Somewhat late here follows the proceedings text for AVTEXT in Quebec. They = are also at: https://datatracker.ietf.org/meeting/81/materials.html=20 My thanks to the note takers Bill ver Steeg, Brian Rosen, and Stephen Botzk= o. Any comments to the list. Regards Keith ---------------------- Audio/Video Transport Extensions (avtext) working group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WEDNESDAY, July 27, 2011 1510-1610 Afternoon Session II 205 ABC Chaired by Keith Drage and Magnus Westerlund Notes taken by Bill ver Steeg, Brian Rosen, and Stephen Botzko Jabber scribe was Jonathan Lennox Agenda Bash and Status ----------------------------- Led by WG chairs [Slides avtext-0] Datatracker, current status, document status from slides The chairs identified that we need reviewers for draft-ietf-avtext-rams-sce= narios-00. Roni and Bill VerSteeg volunteer Presentation of issues of PAYLOAD working group ------------------------------------------------------------ Led by Roni Even [Slides avtext-4, avtext-5] Send comments to payload list, not avtext list. Proceedings will appear as = part of AVTEXT session. Magnus owns the "how to write a payload" document Glen: What are we doing about G718? comments about adding stuff from ITU an= d other stuff Roni: need to ask ITU-T about updates, Roni will send questions to ITU-T Ali: exchanged a few emails with current authors, one has left the company,= questions to ITU pending Volunteers requested to edit docs on XRBlock/monitoring Glen Zorn - volunteers to edit documents for XR blocks or other documents G711.0 Michael Ramhalo presenting Need more information on G711.0 compression segments, and need to decide if= it should be part of the payload specification. author maintains that SDP signalling might not be required. need the two use cases described (presently unspecified magic). Roni: need to have a way to negotiate the behavior Michael: in band and out of band Magnus: Need to have a payload type that says G711.0. Between the compresso= r and decompressor, that's it. Michael: PCMU and PCMA have distinct payloads Roni: Depends on behaviour in the end or in the middle. Payload type is awa= reness. May have other ways to do signalling unaware cases. Michael: current location in unspecified Jonathan: need to distinct PTs for .0 and .1 - the SDP generator needs to k= now the payload type in an unambiguous manner. If we need two payload types= , no problem. PT=3DQ is okay. May need an "antipayload" type signal from e= ndpoints (payload types I promise not to use). Hadriel: Endpoints are not going to say what they are not going to use in t= he future. Middlebox transcoding already can be done (like 729-711-729) - = this is just normal SDP, with G711 as the codec, this is the same as this c= ase, there is nothing to talk about. Michael: This is lossless. That makes it different. Hadriel Kaplan: any piece of work on SDP messing around doesn't belong in a= payload type draft. Michael: Will take this to the list, and include mmusic guys in the discuss= ion. Actions: more discussion on the list (PAYLOAD list) Open question on whether to split out the compression segment from the payl= oad draft. Audio Levels --------------- Led by Emil Ivov / Jonathan Lennox draft-ietf-avtext-client-to-mixer-audio-level-03 draft-ietf-avtext-mixer-to-client-audio-level-03 [slides avtext-1] Discussing VAD support, signal in V, add a bit, redefine V. Bill: Are bits so expensive we can't afford another? Jonathan: some complications involved, it's not just a bit. =20 Steve: Advantage of signaling is middle boxes can mess with it Magnus: signal the support / lack of support of V bit so that middleboxes c= an do the right thing. Stefan: Is there value in sending levels when there is no voice? if not, s= end a recognized pattern Jonathan: sometimes a "no voice" indicator is useful for deciding what to p= lay in the absence of voice. Yes, sometimes sending background is good Stefan: could use state tracking and more complication Cullen: make a choice Bill: Send it in the SDP, then do the best you can - VAD set to 1 if you ca= n't tell Chairs: who objects to signaling in SDP <> Action: - put in signaling to indicate VAD support (or lack of) in SDP. MM= USIC will need to review. Drafts will shortly move to publication request (when new version issued an= d after short review of new SDP by MMUSIC). Splicing --------- led by Jinwei Xia draft-xia-avtext-splicing-for-rtp-00 [slides avtext-2] Chairs: Anyone object to using mixer approach for user detectable case? <> Chairs: Who objects to mixer soln for non-user detectable case Colin: We talked about open mixer and translator on the list, I prefer the = translator, but mixer/translator is OK as long as the requirements have com= monality. <> Conclusion: Majority of WG prefers the RTP mixer approach for user-detectab= le case. Recommendation: use RTP mixer for all cases for simplicity. Consensus confirmed in room (no objections): Mixer to be specified in both = user detectable case and non-detectable case as well. Confirmation on the mailing list will be solicited. IEEE 1588/802.1AS Synchronisation for RTP Streams --------------------------------------------------------------- Aidan Williams was ill and not able to be present in Quebec, and not able t= o address this draft. draft-williams-avtext-avbsync-01 [slides avtext-3] - is this in scope - what are the issues with working on this - interest to the list Chairs: Is work in scope, what are the issues, is there any interest? Colin: is this like existing methods? Magnus: More like NTP providing a base clock. We also already have the RTCP= packet registered at IEEE. Colin: Not completely unreasonable? Would be interested to see in more deta= ils. Chairs: Do we make this a WG item, or have some f2f in Taipei before we ask= that? <> Does this need face-to-face time, or should this be on the list? Action - try to close on the list. Not discussed ---------------- The following documents were not separately discussed although comments are= always welcome on the mailing list.=20 draft-ietf-avtext-multiple-clock-rates-01 draft-ietf-avtext-rams-scenarios-00 --------------------------------- From xiajinwei@huawei.com Fri Aug 26 18:31:09 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F8521F8559 for ; Fri, 26 Aug 2011 18:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lItBuXBFuFXr for ; Fri, 26 Aug 2011 18:31:08 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5140921F85A1 for ; Fri, 26 Aug 2011 18:31:08 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQK004ZTC9ZVV@szxga05-in.huawei.com> for avtext@ietf.org; Sat, 27 Aug 2011 09:32:23 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQK00J1DC9YFF@szxga05-in.huawei.com> for avtext@ietf.org; Sat, 27 Aug 2011 09:32:23 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADK99408; Sat, 27 Aug 2011 09:32:22 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 27 Aug 2011 09:30:57 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.30]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Sat, 27 Aug 2011 09:32:21 +0800 Date: Sat, 27 Aug 2011 01:32:21 +0000 From: Xiajinwei X-Originating-IP: [10.138.41.79] To: "avtext@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-xia-avtext-splicing-for-rtp-01.txt Thread-index: AQHMYtSHp+upqSNDN0OkXIJJGHJNTpUuqpJg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [avtext] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-xia-avtext-splicing-for-rtp-01=2Etxt?= X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 01:31:09 -0000 SGkgYWxsLA0KDQpBY2NvcmRpbmcgdG8gdGhlIGRpc2N1c3Npb24gb2YgODF0aCBJRVRGIG1lZXRp bmcsIEkgaGF2ZSB1cGRhdGVkIFJUUCBzcGxpY2luZyBkcmFmdCB3aXRoIG1peGVyLWJhc2VkIHNv bHV0aW9uIGZvciBib3RoIHVzZXIgZGV0ZWN0YWJsZSBjYXNlIGFuZCBub24tZGV0ZWN0YWJsZSBj YXNlIGFzIHdlbGwuIFNpbmNlIHRoZXJlIGlzIG5vIG9iamVjdGlvbiB0byB1c2luZyBtaXhlciBh cHByb2FjaCBpbiB0aGUgbWVldGluZywgYXMgd2VsbCBhcyBpbiB0aGUgbWFpbGluZyBsaXN0LCBJ IGFzayBjaGFpcnMgdG8gYWRvcHQgdGhlIHdvcmssIHNvIHdlIGNhbiBmb3J3YXJkIGl0IHdlbGwu DQoNClRoZSBtYWpvciBjaGFuZ2VzIGNvbXBhcmVkIHRvIHByZXZpb3VzIHZlcnNpb24gYXJlIHVz aW5nIG1peGVyIGZvciBib3RoIGNhc2VzLCBhZGRpbmcgb25lIHN1YnNlY3Rpb24gdG8gZGVzY3Jp YmUgbWVkaWEgY2xpcHBpbmcgY29uc2lkZXJhdGlvbnMsIGFuZCBhZGRpbmcgb25lIHN1YnNlY3Rp b24gdG8gZGVzY3JpYmUgY29uZ2VzdGlvbiBjb250cm9sIGNvbnNpZGVyYXRpb25zLiANCg0KQW55 IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgdmVyeSBhcHByZWNpYXRlZCEgDQoNCg0KSmlu d2VpDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumX tDogMjAxMeW5tDjmnIgyNeaXpSAxMTowOQ0K5pS25Lu25Lq6OiBYaWFqaW53ZWkNCuaKhOmAgTog WGlhamlud2VpDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteGlh LWF2dGV4dC1zcGxpY2luZy1mb3ItcnRwLTAxLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQteGlhLWF2dGV4dC1zcGxpY2luZy1mb3ItcnRwLTAxLnR4dCBoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgc3VibWl0dGVkIGJ5IEppbndlaSBYaWEgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXhpYS1hdnRleHQtc3BsaWNpbmctZm9yLXJ0cA0K UmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgQ29udGVudCBTcGxpY2luZyBmb3IgUlRQIFNlc3Npb25z DQpDcmVhdGlvbiBkYXRlOgkgMjAxMS0wOC0yNA0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE2DQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1vIG91dGxp bmVzIFJUUCBzcGxpY2luZy4gIFNwbGljaW5nIGlzIGEgcHJvY2VzcyB0aGF0IHJlcGxhY2VzDQog ICB0aGUgY29udGVudCBvZiB0aGUgbWFpbiBtdWx0aW1lZGlhIHN0cmVhbSB3aXRoIG90aGVyIG11 bHRpbWVkaWENCiAgIGNvbnRlbnQsIGFuZCBkZWxpdmVycyB0aGUgc3Vic3RpdHV0aXZlIG11bHRp bWVkaWEgY29udGVudCB0byByZWNlaXZlcg0KICAgZm9yIGEgcGVyaW9kIG9mIHRpbWUuICBUaGlz IG1lbW8gcHJvdmlkZXMgc29tZSBSVFAgc3BsaWNpbmcgdXNlDQogICBjYXNlcywgdGhlbiB3ZSBl bnVtZXJhdGUgYSBzZXQgb2YgcmVxdWlyZW1lbnRzIGFuZCBhbmFseXplIHdoZXRoZXIgYW4NCiAg IGV4aXN0aW5nIFJUUCBsZXZlbCBtaWRkbGVib3ggY2FuIG1lZXQgdGhlc2UgcmVxdWlyZW1lbnRz LCBhdCBsYXN0IHdlDQogICBwcm92aWRlIGNvbmNyZXRlIGd1aWRlbGluZXMgZm9yIGhvdyB0aGUg Y2hvc2VuIG1pZGRsZWJveCB3b3JrcyB0bw0KICAgaGFuZGxlIFJUUCBzcGxpY2luZy4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From internet-drafts@ietf.org Sat Aug 27 14:33:24 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AE621F8B57; Sat, 27 Aug 2011 14:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvB4hk0x1ZuH; Sat, 27 Aug 2011 14:33:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F0D21F8B52; Sat, 27 Aug 2011 14:33:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110827213323.32648.19654.idtracker@ietfa.amsl.com> Date: Sat, 27 Aug 2011 14:33:23 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-mixer-to-client-audio-level-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 21:33:24 -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 Extensions Work= ing Group of the IETF. Title : A Real-Time Transport Protocol (RTP) Header Extension fo= r Mixer-to- Client Audio Level Indication Author(s) : Emil Ivov Enrico Marocco Jonathan Lennox Filename : draft-ietf-avtext-mixer-to-client-audio-level-04.txt Pages : 16 Date : 2011-08-27 This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-audio= -level-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-audio-= level-04.txt From internet-drafts@ietf.org Sat Aug 27 14:33:25 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF08121F8B56; Sat, 27 Aug 2011 14:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QGTerdYhdHY; Sat, 27 Aug 2011 14:33:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A17B21F8B57; Sat, 27 Aug 2011 14:33:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110827213325.32664.9493.idtracker@ietfa.amsl.com> Date: Sat, 27 Aug 2011 14:33:25 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio-level-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 21:33:26 -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 Extensions Work= ing Group of the IETF. Title : A Real-Time Transport Protocol (RTP) Header Extension fo= r Client-to- Mixer Audio Level Indication Author(s) : Jonathan Lennox Emil Ivov Enrico Marocco Filename : draft-ietf-avtext-client-to-mixer-audio-level-04.txt Pages : 12 Date : 2011-08-27 This document defines a mechanism by which packets of Real-Time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox which wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer-audio= -level-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer-audio-= level-04.txt From emil@sip-communicator.org Sat Aug 27 14:37:40 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF44B21F8B56 for ; Sat, 27 Aug 2011 14:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIVWQ0toOCdv for ; Sat, 27 Aug 2011 14:37:40 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C965021F8B51 for ; Sat, 27 Aug 2011 14:37:39 -0700 (PDT) Received: by wwf5 with SMTP id 5so3038731wwf.13 for ; Sat, 27 Aug 2011 14:38:59 -0700 (PDT) Received: by 10.216.221.102 with SMTP id q80mr2257211wep.37.1314481139164; Sat, 27 Aug 2011 14:38:59 -0700 (PDT) Received: from camionet.local (sud35-1-82-67-115-37.fbx.proxad.net [82.67.115.37]) by mx.google.com with ESMTPS id o57sm1893435weq.10.2011.08.27.14.38.56 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 27 Aug 2011 14:38:57 -0700 (PDT) Message-ID: <4E5963EF.9010903@jitsi.org> Date: Sat, 27 Aug 2011 23:38:55 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: "Audio/Video Transport Extensions List" Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Subject: [avtext] audio level drafts updated to version 04 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 21:37:41 -0000 Hey all, We have just updated the audio level drafts. Diff2 available here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtext-mixer-to-client-audio-level-04.txt http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtext-client-to-mixer-audio-level-04.txt We believe we have addressed all comments, most of which were editorial. The one technical change was the edition of a "vad" parameter in the client-to-mixer draft as per the discussion in the last meeting. We believe this closes the last open issue on the drafts and that they are now ready to move forward. Cheers, Emil -- http://jitsi.org