From wwwrun@rfc-editor.org Mon Aug 8 12:11:44 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEC421F8C92; Mon, 8 Aug 2011 12:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 bftrj-h-9bfm; Mon, 8 Aug 2011 12:11:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6D321F8C87; Mon, 8 Aug 2011 12:11:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AEADB98C523; Mon, 8 Aug 2011 12:12:07 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110808191207.AEADB98C523@rfc-editor.org> Date: Mon, 8 Aug 2011 12:12:07 -0700 (PDT) Cc: payload@ietf.org, rfc-editor@rfc-editor.org Subject: [payload] RFC 6262 on RTP Payload Format for IP-MR Speech Codec X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 19:11:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6262 Title: RTP Payload Format for IP-MR Speech Codec Author: S. Ikonin Status: Standards Track Stream: IETF Date: August 2011 Mailbox: s.ikonin@gmail.com Pages: 19 Characters: 39511 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-ipmr-15.txt URL: http://www.rfc-editor.org/rfc/rfc6262.txt This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Payloads Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From mramalho@cisco.com Wed Aug 10 09:41:41 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [payload] Progressing draft-ramalho-payload-g7110-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [payload] Progressing draft-ramalho-payload-g7110-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: harada.noboru@lab.ntt.co.jp List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [payload] Progressing draft-ramalho-payload-g7110-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [payload] Progressing draft-ramalho-payload-g7110-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: harada.noboru@lab.ntt.co.jp List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 Even.roni@huawei.com Tue Aug 16 23:16:02 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D674521F8AC3; Tue, 16 Aug 2011 23:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.581 X-Spam-Level: X-Spam-Status: No, score=-105.581 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IMf2Da+ieRIo; Tue, 16 Aug 2011 23:15:59 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 81E4A11E8073; Tue, 16 Aug 2011 23:15:58 -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 <0LQ200AGC6R9N6@szxga05-in.huawei.com>; Wed, 17 Aug 2011 14:16:21 +0800 (CST) Received: from 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 <0LQ200A966R7SB@szxga05-in.huawei.com>; Wed, 17 Aug 2011 14:16:20 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-13-148.red.bezeqint.net [79.178.13.148]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQ200H1K6QVJX@szxml12-in.huawei.com>; Wed, 17 Aug 2011 14:16:19 +0800 (CST) Date: Wed, 17 Aug 2011 09:15:26 +0300 From: Roni Even To: iesg-secretary@ietf.org, 'Robert Sparks' Message-id: <02ca01cc5ca5$14d78690$3e8693b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_OuBRUzZBvYHNU7n5Tp97aA)" Content-language: en-us Thread-index: AcxcpQ00+b2rIMVZSpST3lPaRs48SQ== Cc: draft-ietf-payload-rfc3189bis.all@tools.ietf.org, payload@ietf.org Subject: [payload] request to publish draft-ietf-payload-rfc3189bis-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 06:16:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_OuBRUzZBvYHNU7n5Tp97aA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Robert, I'd like to request that draft-ietf-payload-rfc3189bis-01, RTP Payload Format for DV (IEC 61834) Video I've reviewed the draft in detail, and the AVT / Payload working groups were given the opportunity to comment. The draft is documented in sufficient detail to meet the registration requirements, and doesn't conflict with other work in AVT/Payload. Accordingly, please consider it for publication. Thanks, Roni Even (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Roni Even. I have reviewed the document, and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document went through a Working Group last call and people had enough time to review it. There were comments in the WGLC and they were addressed in this revision of the document. This document is an update to an existing RFC and the document Shepherd feels that the review was satisfactory. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No Concerns (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This is an update to an existing payload specification. It has consensus of a few individual who reviewed the draft. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits?(See the Checklist and idnits ).Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The idnits tool reports some comments which are OK. The media subtype registration was sent to review to ietf-types mailing list. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA consideration section exists and is inline with the body of the document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No such sections (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. "This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189." Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The draft updates RFC3189 the major changes are: 1. Removed SMPTE 306M, since it is covered by SMPTE 314M format. 2. Added SMPTE 370M 100Mbps HDTV (1080/60i, 1080/50i, 720/60p, and 720/50p) format. 3. Incorporated Source Specific Multicast (SSM) spec. for avoiding overloaded traffic source in multicast usage. Added a reference to the Source Specific Multicast (SSM) specifications as a way to reduce unwanted traffic in a multicast application. 4. Clarified the case where the sender omits subcode DIF block data from the stream. It has an interoperability with Previous Implementations section. No specific issues to report. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The media type review was posted on July 11, 2011. DV is used in The Society of Motion Picture and Television Engineers (SMPTE) stand --Boundary_(ID_OuBRUzZBvYHNU7n5Tp97aA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Robert,

I'd like to request that draft-ietf-payload-rfc3189bis-01, RTP Payload Format for DV (IEC 61834) = Video

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

 

Thanks,

Roni Even

 

  =

(1.a) Who is the Document = Shepherd for this document? Has the

        Document = Shepherd personally reviewed this version of the

        docu= ment and, in particular, does he or she believe this

        vers= ion is ready for forwarding to the IESG for publication? =

 

The document shepherd is = Roni Even. I have reviewed the document, and believe it is ready for = publication.

 

  = (1.b) Has the document had adequate review both from key WG members =

        and = from key non-WG members? Does the Document Shepherd have =

        any = concerns about the depth or breadth of the reviews that =

        have= been performed? 

 

The = document went through a Working Group last call and people had enough = time to review it. There were comments in the WGLC and they were = addressed in this revision of the document. This document is an update = to an existing RFC and the document Shepherd feels that the review was = satisfactory.

 

  = (1.c) Does the Document Shepherd have concerns that the document =

        need= s more review from a particular or broader perspective, =

        e.g.= , security, operational complexity, someone familiar with =

        AAA,= internationalization or XML?

 

No = concerns

 

 

  = (1.d) Does the Document Shepherd have any specific concerns or =

        issu= es with this document that the Responsible Area = Director

        and/or = the IESG should be aware of? For example, perhaps he

        or = she is uncomfortable with certain parts of the document, or =

        has = concerns whether there really is a need for it. In any

        even= t, if the WG has discussed those issues and has indicated =

        that= it still wishes to advance the document, detail those

        conc= erns here. Has an IPR disclosure related to this document =

        been= filed? If so, please include a reference to the

        disc= losure and summarize the WG discussion and conclusion on =

        this= issue.

 

No Concerns

 

(1.e) = How solid is the WG consensus behind this document? Does it =

        repr= esent the strong concurrence of a few individuals, with =

        othe= rs being silent, or does the WG as a whole understand and =

        agre= e with it?

 

This = is an update to an existing payload specification. It has consensus of a = few individual who reviewed the draft.

 

  (1.f) Has anyone threatened an appeal = or otherwise indicated extreme

        disc= ontent? If so, please summarise the areas of conflict in =

        sepa= rate email messages to the Responsible Area Director. (It =

        shou= ld be in a separate email because this questionnaire is =

        ente= red into the ID Tracker.)

 

No

=

  (1.g) Has the = Document Shepherd personally verified that the

document satisfies = all ID nits?(See the Checklist = and idnits).Boilerplate = checks are not enough; this check needs to be thorough. Has the document = met all formal review criteria it needs to, such as the MIB Doctor, = media type and URI type reviews?

 

The idnits tool = reports some comments which are OK.

The media subtype = registration was sent to review to ietf-types mailing = list.

 

  (1.h) Has the document split its references = into normative and

        info= rmative? Are there normative references to documents that =

        are = not ready for advancement or are otherwise in an unclear =

        stat= e? If such normative references exist, what is the

        stra= tegy for their completion? Are there normative references =

        that= are downward references, as described in [RFC3967]? If =

        so, = list these downward references to support the Area

        Dire= ctor in the Last Call procedure for them [RFC3967].

  

 

References are split

 

(1.i) = Has the Document Shepherd verified that the document IANA =

        cons= ideration section exists and is consistent with the body =

        of = the document? If the document specifies protocol

        exte= nsions, are reservations requested in appropriate IANA

        regi= stries? Are the IANA registries clearly identified? If

        the = document creates a new registry, does it define the

        prop= osed initial contents of the registry and an allocation =

        proc= edure for future registrations? Does it suggest a

        reas= onable name for the new registry? See [RFC5226]. If the =

        docu= ment describes an Expert Review process has Shepherd

        conf= erred with the Responsible Area Director so that the IESG =

        can = appoint the needed Expert during the IESG Evaluation?

 

 

The = IANA consideration section exists and is inline with the body of the = document.

 

  (1.j) Has the Document Shepherd = verified that sections of the

        docu= ment that are written in a formal language, such as XML =

        code= , BNF rules, MIB definitions, etc., validate correctly in =

        an = automated checker?

 

No = such sections

 

  = (1.k) The IESG approval announcement includes a Document =

        Anno= uncement Write-Up. Please provide such a Document

        Anno= uncement Write-Up? Recent examples can be found in the

        = "Action" announcements for approved documents. The approval =

        anno= uncement contains the following sections:

     Technical Summary =

        Rele= vant content can frequently be found in the abstract

        and/= or introduction of the document. If not, this may be

        an = indication that there are deficiencies in the abstract

        or = introduction.

     

“This document specifies the packetization = scheme for encapsulating the compressed digital video data streams = commonly known as "DV" into a payload format for the Real-Time = Transport Protocol (RTP). This document obsoletes RFC = 3189.”

 

Working Group Summary

        Was = there anything in WG process that is worth noting? For

        exam= ple, was there controversy about particular points or

        were= there decisions where the consensus was particularly

        roug= h?

     

The draft updates RFC3189 the major changes = are:

   1.  Removed = SMPTE 306M, since it is covered by SMPTE 314M format.

 

   2.  Added SMPTE 370M 100Mbps HDTV = (1080/60i, 1080/50i, 720/60p, and

       720/50p) = format.

 

   3.  Incorporated Source Specific = Multicast (SSM) spec. for avoiding

       overloaded = traffic source in multicast usage.  Added a = reference

       to the Source = Specific Multicast (SSM) specifications as a way to    = reduce unwanted traffic in a multicast application.

 

   4.  Clarified the case where the = sender omits subcode DIF block data

       from the = stream.

 

  

It has an interoperability with Previous = Implementations section. No specific issues to report.

 

 

Document Quality

        Are = there existing implementations of the protocol? Have a

        sign= ificant number of vendors indicated their plan to

        impl= ement the specification? Are there any reviewers that

        meri= t special mention as having done a thorough review,

        e.g.= , one that resulted in important changes or a

        conc= lusion that the document had no substantive issues? If

        ther= e was a MIB Doctor, Media Type or other expert review,

        what= was its course (briefly)? In the case of a Media Type

        revi= ew, on what date was the request posted?

 

The media type review was posted on July 11, 2011. DV is = used in The Society of Motion Picture and Television Engineers (SMPTE) = stand

= --Boundary_(ID_OuBRUzZBvYHNU7n5Tp97aA)-- From mramalho@cisco.com Wed Aug 17 05:43:42 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [payload] Progressing draft-ramalho-payload-g7110-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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 Even.roni@huawei.com Thu Aug 18 04:48:48 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F7021F8AE4 for ; Thu, 18 Aug 2011 04:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 CEHqaCluFLLB for ; Thu, 18 Aug 2011 04:48:48 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E1A5621F8AA9 for ; Thu, 18 Aug 2011 04:48:47 -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 <0LQ4004OCGUTFG@szxga05-in.huawei.com> for payload@ietf.org; Thu, 18 Aug 2011 19:49:41 +0800 (CST) Received: from 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 <0LQ400AT7GUSFU@szxga05-in.huawei.com> for payload@ietf.org; Thu, 18 Aug 2011 19:49:41 +0800 (CST) Received: from windows8d787f9 (bzq-109-65-33-161.red.bezeqint.net [109.65.33.161]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQ400D8NGUL8I@szxml12-in.huawei.com>; Thu, 18 Aug 2011 19:49:40 +0800 (CST) Date: Thu, 18 Aug 2011 14:49:11 +0300 From: Roni Even To: payload@ietf.org Message-id: <008801cc5d9c$dd1eb400$975c1c00$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NZ+tRsetTiDObK64iPL6tQ)" Content-language: en-us Thread-index: AcxdnNfq/+ON2T4BTFKgzifiLMZLbw== Subject: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 11:48:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_NZ+tRsetTiDObK64iPL6tQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I would like to start a Working Group Last Call on draft-ietf-avt-rtp-evrc-nw-03 , RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) The WGLC will end on September 9, 2011 Please review the draft and send comments to the list. Roni Even Payload co-chair --Boundary_(ID_NZ+tRsetTiDObK64iPL6tQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I would =
like to start a Working Group Last Call on draft-i=
etf-avt-rtp-evrc-nw-03 , RTP =
payload format for Enhanced Variable Rate Narrowband-Wideband =
Codec  (EVRC-NW)

 

The WGLC will end on September 9, 2011

Please review the draft and send comments to the = list.

 

 

Roni = Even

Payload = co-chair

 

= --Boundary_(ID_NZ+tRsetTiDObK64iPL6tQ)-- From randell-ietf@jesup.org Sun Aug 21 06:38:53 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E3121F8ACC for ; Sun, 21 Aug 2011 06:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 jrR1EQrr31FQ for ; Sun, 21 Aug 2011 06:38:53 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4454F21F8A97 for ; Sun, 21 Aug 2011 06:38:50 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qv8Fk-0001R3-2w for payload@ietf.org; Sun, 21 Aug 2011 08:39:52 -0500 Message-ID: <4E510A1F.5000708@jesup.org> Date: Sun, 21 Aug 2011 09:37:35 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: payload@ietf.org References: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> In-Reply-To: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 13:38:53 -0000 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 = [ 0 | 8 ] can only have a G.711 payload > inside of it. Wrong. a=rtpmap: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 allowed to do so, and I can conceive of cases where someone might do so. Not likely, but conceivable. 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), which could cause someone to decide to remap static payloads. And as you mention indirectly, someone could put G.711 on other dynamic payloads. -- Randell Jesup randell-ietf@jesup.org From mramalho@cisco.com Sun Aug 21 10:10:10 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [payload] draft-ramalho-payload-g7110-00 to bediscussed inAVTEXT X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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 Even.roni@huawei.com Mon Aug 29 04:05:23 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7418421F8AFC for ; Mon, 29 Aug 2011 04:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.308 X-Spam-Level: X-Spam-Status: No, score=-106.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uZ9F4cu3LRuJ for ; Mon, 29 Aug 2011 04:05:05 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id BC3EF21F8B0B for ; Mon, 29 Aug 2011 04:05:04 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQO005F3S6RP2@szxga03-in.huawei.com> for payload@ietf.org; Mon, 29 Aug 2011 19:06:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQO00LP7S6R7I@szxga03-in.huawei.com> for payload@ietf.org; Mon, 29 Aug 2011 19:06:27 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQO003Q8S6M8T@szxml12-in.huawei.com> for payload@ietf.org; Mon, 29 Aug 2011 19:06:27 +0800 (CST) Date: Mon, 29 Aug 2011 14:05:04 +0300 From: Roni Even In-reply-to: <008801cc5d9c$dd1eb400$975c1c00$%roni@huawei.com> To: payload@ietf.org Message-id: <02b001cc663b$8485da10$8d918e30$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_l7aZyvSIFiRxXGPA3/0rWA)" Content-language: en-us Thread-index: AcxdnNfq/+ON2T4BTFKgzifiLMZLbwInpfIw References: <008801cc5d9c$dd1eb400$975c1c00$%roni@huawei.com> Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 - reminder X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 11:05:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_l7aZyvSIFiRxXGPA3/0rWA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Please review From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: Thursday, August 18, 2011 2:49 PM To: payload@ietf.org Subject: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi, I would like to start a Working Group Last Call on draft-ietf-avt-rtp-evrc-nw-03 , RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) The WGLC will end on September 9, 2011 Please review the draft and send comments to the list. Roni Even Payload co-chair --Boundary_(ID_l7aZyvSIFiRxXGPA3/0rWA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Please review

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Roni Even
Sent: Thursday, August 18, 2011 2:49 = PM
To: payload@ietf.org
Subject: [payload] WGLC on = draft-ietf-avt-rtp-evrc-nw-03

 

Hi,

I would =
like to start a Working Group Last Call on draft-i=
etf-avt-rtp-evrc-nw-03 , RTP =
payload format for Enhanced Variable Rate Narrowband-Wideband =
Codec  (EVRC-NW)

 

The WGLC will end on September 9, 2011

Please review the draft and send comments to the = list.

 

 

Roni = Even

Payload = co-chair

 

= --Boundary_(ID_l7aZyvSIFiRxXGPA3/0rWA)-- From Even.roni@huawei.com Mon Aug 29 04:34:36 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3130C21F8ACC for ; Mon, 29 Aug 2011 04:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.332 X-Spam-Level: X-Spam-Status: No, score=-106.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7UcIqKfqaZaj for ; Mon, 29 Aug 2011 04:34:35 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6C921F8AC9 for ; Mon, 29 Aug 2011 04:34:35 -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 <0LQO00BTNTJYYZ@szxga04-in.huawei.com> for payload@ietf.org; Mon, 29 Aug 2011 19:35:58 +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 <0LQO00ML0TJYIB@szxga04-in.huawei.com> for payload@ietf.org; Mon, 29 Aug 2011 19:35:58 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQO003A3TJS8T@szxml12-in.huawei.com>; Mon, 29 Aug 2011 19:35:58 +0800 (CST) Date: Mon, 29 Aug 2011 14:34:35 +0300 From: Roni Even In-reply-to: <008801cc5d9c$dd1eb400$975c1c00$%roni@huawei.com> To: payload@ietf.org Message-id: <02b501cc663f$a40278e0$ec076aa0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_RBMT5ETOlUvzcSJCdp80gw)" Content-language: en-us Thread-index: AcxdnNfq/+ON2T4BTFKgzifiLMZLbwIopyFw References: <008801cc5d9c$dd1eb400$975c1c00$%roni@huawei.com> Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 11:34:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_RBMT5ETOlUvzcSJCdp80gw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I reviewed the draft and have some comments. 1. It looks to me that this draft updates RFC3558 similar to RFC 4788 and RFC 5188. It should be referenced in the header and in the text 2. In section 6 first paragraph why not reference 3788 where ToC is defined. 3. In second 9 in the registration template you have sendmode deprecated. This is strange since this registration is a new registration so there is nothing to deprecate . If you want to state that this optional parameter that is used in other EVRC modes is not used, please do it in another section and not in the registration section. 4. In section 9 in the published specification you mention RFC3558 without a reference. I think that this document need also to be specified since it defines the RTP header and the usage. 5. In section 9 in the author field add your email address 6. In section 9 change controller should be " IETF Audio/Video Transport working group delegated from the IESG." 7. In section 13 how is "mode-set-recv" used in declarative SDP since it is a decoder capability and not an encoder one. Thanks Roni Even From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: Thursday, August 18, 2011 2:49 PM To: payload@ietf.org Subject: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi, I would like to start a Working Group Last Call on draft-ietf-avt-rtp-evrc-nw-03 , RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) The WGLC will end on September 9, 2011 Please review the draft and send comments to the list. Roni Even Payload co-chair --Boundary_(ID_RBMT5ETOlUvzcSJCdp80gw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I reviewed the draft and = have some comments.

 

1.       = It looks to me that this draft updates RFC3558 = similar to RFC 4788 and RFC 5188.  It should be referenced in the = header and in the text

2.       = In section 6 first paragraph why not reference = 3788 where ToC is defined.

3.       = In second 9 in the registration template you = have sendmode deprecated. This is strange since this registration is a = new registration so there is nothing to deprecate . If you want to state = that this optional parameter that is used in other EVRC modes is not = used, please do it in another section and not in the registration = section.

4.       = In section 9 in the published specification you = mention RFC3558 without a reference. I think that this document need = also to be specified since it defines the RTP header and the = usage.

5.       = In section 9 in the author field add your email = address

6.      = In section 9  change controller should be = " IETF Audio/Video Transport working group delegated from = the IESG."

7.      = In section 13 how is "mode-set-recv" = used in declarative SDP since it is a decoder capability and not an = encoder one.

 

Thanks

Roni Even =

 

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Roni Even
Sent: Thursday, August 18, 2011 2:49 = PM
To: payload@ietf.org
Subject: [payload] WGLC on = draft-ietf-avt-rtp-evrc-nw-03

 

Hi,

I would =
like to start a Working Group Last Call on draft-i=
etf-avt-rtp-evrc-nw-03 , RTP =
payload format for Enhanced Variable Rate Narrowband-Wideband =
Codec  (EVRC-NW)

 

The WGLC will end on September 9, 2011

Please review the draft and send comments to the = list.

 

 

Roni = Even

Payload = co-chair

 

= --Boundary_(ID_RBMT5ETOlUvzcSJCdp80gw)-- From rjsparks@nostrum.com Wed Aug 31 11:08:20 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B494621F8E00 for ; Wed, 31 Aug 2011 11:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, SPF_PASS=-0.001, 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 ZgLRGq6LKmHL for ; Wed, 31 Aug 2011 11:08:20 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B55821F8DFF for ; Wed, 31 Aug 2011 11:08:20 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p7VI9omY089760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Aug 2011 13:09:50 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Aug 2011 13:10:03 -0500 Message-Id: <3B8857F0-F4BB-411D-8B30-754D0C05E0B1@nostrum.com> To: payload@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-payload-rfc3189bis@tools.ietf.org Subject: [payload] AD review: draft-ietf-payload-rfc3189bis-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 18:08:20 -0000 Summary: This draft needs a small revision before moving to IETF Last = Call. Akimichi Ogawa was removed from the author list, and not credited in an = acknowledgment section. I think it would be appropriate to add one. This probably also means the = draft should use the=20 pre-5378 boilerplate. Please issue a revision with those changes (or let = me know why they are not needed). A minor point to consider while making that update: The 7th point in the Major changes section does not stand alone - what = is it trying to say? Is it just pointing to aligning with the advice in = draft-ietf-payload-rtp-howto? RjS