From nobody Wed Oct 1 08:34:40 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23ED31ACE54 for ; Wed, 1 Oct 2014 08:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P16n6PMvOgO for ; Wed, 1 Oct 2014 08:34:37 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783321ACE57 for ; Wed, 1 Oct 2014 08:34:37 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id r10so576510igi.8 for ; Wed, 01 Oct 2014 08:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=yyLP3NdT8b1ZRq319ksKf4I7N3MEATUC199csXOGZAg=; b=UuwsKwu9F5LpabPMydFrkNhdUQA/jJ4c3LvDyPAzr9dMiJ8EIkCDhKQbHkiOYu2VdL vDSu30/j8t6XJD0VI+COzXvTECinOITaQQ2s9S30ReyXNxFa7TEhenWgws3taocigie5 G8xV0s9sPbYSeO8yh10xOH3xCebf7K5PjstF61RM+nbr9hxJXG/Zc8UOSG9Tuxed4aPL TPZL2rS0lmkY3D//34EUAA2hNa2cMZ/TOQj/RwtiYQAVTSOjxNIgG1cALvnNfLv9T8/7 g0QIzNJh1sZTFr8hW0b5OVGd6z+C6JfcsCn03lPWn/7ulEXONUWHVDiVhhSUgXDmpwRc aRzA== X-Received: by 10.50.112.67 with SMTP id io3mr20699995igb.37.1412177676804; Wed, 01 Oct 2014 08:34:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.20.231 with HTTP; Wed, 1 Oct 2014 08:34:16 -0700 (PDT) From: Varun Singh Date: Wed, 1 Oct 2014 10:34:16 -0500 Message-ID: To: payload@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Qbn3-ML0J9TRKLnBdPaXWe4Cxrg Subject: [payload] FW: New Version Notification for draft-singh-payload-rtp-1d2d-parity-scheme-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 01 Oct 2014 15:34:39 -0000 Hi all, As per the discussions in Toronto, I have submitted an initial draft of a FEC draft. It is based on Ali's earlier draft in FECFRAME, but adapted to align it with the bit mask used in RFC5109. This is an initial version, the SDP in the draft has not been fixed and is most likely wrong. It will be fixed in an upcoming version. However, feedback on the header and source/reconstruction algorithm is deeply appreciated. Cheers, Varun (on behalf of the co-authors) > A new version of I-D, draft-singh-payload-rtp-1d2d-parity-scheme-00.txt > has been successfully submitted by Varun Singh and posted to the > IETF repository. > > Name: draft-singh-payload-rtp-1d2d-parity-scheme > Revision: 00 > Title: RTP Payload Format for Non-Interleaved and Interleaved Parity Forward Error > Correction (FEC) > Document date: 2014-10-01 > Group: Individual Submission > Pages: 39 > URL: http://www.ietf.org/internet-drafts/draft-singh-payload-rtp-1d2d-parity- > scheme-00.txt > Status: https://datatracker.ietf.org/doc/draft-singh-payload-rtp-1d2d-parity-scheme/ > Htmlized: http://tools.ietf.org/html/draft-singh-payload-rtp-1d2d-parity-scheme-00 > > Abstract: > This document defines new RTP payload formats for the Forward Error > Correction (FEC) packets that are generated by the non-interleaved > and interleaved parity codes from a source media encapsulated in RTP. > These parity codes are systematic codes, where a number of repair > symbols are generated from a set of source symbols. These repair > symbols are sent in a repair flow separate from the source flow that > carries the source symbols. The non-interleaved and interleaved > parity codes offer a good protection against random and bursty packet > losses, respectively, at a cost of decent complexity. The RTP > payload formats that are defined in this document address the > scalability issues experienced with the earlier specifications > including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several > improvements. Due to these changes, the new payload formats are not > backward compatible with the earlier specifications, but endpoints > that do not implement the scheme can still work by simply ignoring > the FEC packets. > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Thu Oct 2 09:25:10 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086111A87E8 for ; Thu, 2 Oct 2014 09:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0fv8l8kJ-oA for ; Thu, 2 Oct 2014 09:25:03 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239421A8847 for ; Thu, 2 Oct 2014 09:24:53 -0700 (PDT) Received: from [130.209.247.112] (port=53605 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XZjBT-0004Kj-5Z; Thu, 02 Oct 2014 17:24:51 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Thu, 2 Oct 2014 17:24:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <26B693FA-0D15-42A4-AE48-607942F34EB0@csperkins.org> References: To: Varun Singh X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/payload/0dbeEo6XvZC-Sr_CYeYezxMvWss Cc: payload@ietf.org Subject: Re: [payload] New Version Notification for draft-singh-payload-rtp-1d2d-parity-scheme-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 16:25:07 -0000 Hi Varun, This looks pretty nice from a quick read - I guess the goal is to be = something we can reference from draft-ietf-rtcweb-rtp-usage? I didn=92t see any examples of the FEC packets produced by the = protection and recovery procedures. Would it be possible to include some = in an appendix in a later version of the draft? In particular, it=92d be = good to see how packets containing =93advanced=94 features like CSRC = lists and RTP header extensions are protected, as well as the simple = cases.=20 Cheers, Colin On 1 Oct 2014, at 16:34, Varun Singh wrote: > Hi all, >=20 > As per the discussions in Toronto, I have submitted an initial draft = of a FEC draft. It is based on Ali=92s earlier draft in FECFRAME, but = adapted to align it with the bit mask used in RFC5109. This is an = initial version, the SDP in the draft has not been fixed and is most = likely wrong. It will be fixed in an upcoming version. However, feedback = on the header and source/reconstruction algorithm is deeply appreciated. >=20 > Cheers, > Varun (on behalf of the co-authors) >=20 >=20 >> A new version of I-D, = draft-singh-payload-rtp-1d2d-parity-scheme-00.txt >> has been successfully submitted by Varun Singh and posted to the >> IETF repository. >>=20 >> Name: draft-singh-payload-rtp-1d2d-parity-scheme >> Revision: 00 >> Title: RTP Payload Format for Non-Interleaved and Interleaved Parity = Forward Error >> Correction (FEC) >> Document date: 2014-10-01 >> Group: Individual Submission >> Pages: 39 >> URL: = http://www.ietf.org/internet-drafts/draft-singh-payload-rtp-1d2d-parity- >> scheme-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-singh-payload-rtp-1d2d-parity-schem= e/ >> Htmlized: = http://tools.ietf.org/html/draft-singh-payload-rtp-1d2d-parity-scheme-00 >>=20 >> Abstract: >> This document defines new RTP payload formats for the Forward Error >> Correction (FEC) packets that are generated by the non-interleaved >> and interleaved parity codes from a source media encapsulated in RTP. >> These parity codes are systematic codes, where a number of repair >> symbols are generated from a set of source symbols. These repair >> symbols are sent in a repair flow separate from the source flow that >> carries the source symbols. The non-interleaved and interleaved >> parity codes offer a good protection against random and bursty packet >> losses, respectively, at a cost of decent complexity. The RTP >> payload formats that are defined in this document address the >> scalability issues experienced with the earlier specifications >> including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several >> improvements. Due to these changes, the new payload formats are not >> backward compatible with the earlier specifications, but endpoints >> that do not implement the scheme can still work by simply ignoring >> the FEC packets. >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --=20 Colin Perkins https://csperkins.org/ From nobody Thu Oct 2 09:42:49 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110981A88DB for ; Thu, 2 Oct 2014 09:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2KjihRqlKtr for ; Thu, 2 Oct 2014 09:42:38 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC311A88A6 for ; Thu, 2 Oct 2014 09:42:38 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id a13so1937559igq.16 for ; Thu, 02 Oct 2014 09:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=K4bm7D8qlPFNk+xXWOolsSL5OK/hk67CN+aB79Llxzg=; b=Yh9HZCPI4BJsUIGrXrn4z1YtUT8mu0MPwuQkB3s4DfxSLhpVCY3YI2CiYxGjYn7fpY qATobuOq/IZ0rNfyGVcpuY8eWmwBjQGE3bJsEOyWhiFMhZwNz//u7nepeLW79fLTYFSz kKM2n3HIEjXDSMYzGiBtv6SiFFJhvwTcL/dW7xDNgzArfPNMk2YGlQz6kNUEz3tTS+Qr e1HSmZ9tc/+KoV4knNktVngFZaeQnVgqE6oFDi+pjW/YaRvwPqfhnZci8H65VChivM38 utPsnU4GZdNbjcdgnzHZ7CshiANaPfdYkRW2kCj4LuwidnRDbCNFBhsP2rP0WNm9qXU+ jBDg== X-Received: by 10.42.114.203 with SMTP id h11mr6492849icq.86.1412268158024; Thu, 02 Oct 2014 09:42:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.20.231 with HTTP; Thu, 2 Oct 2014 09:42:17 -0700 (PDT) In-Reply-To: <26B693FA-0D15-42A4-AE48-607942F34EB0@csperkins.org> References: <26B693FA-0D15-42A4-AE48-607942F34EB0@csperkins.org> From: Varun Singh Date: Thu, 2 Oct 2014 11:42:17 -0500 Message-ID: To: Colin Perkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/payload/b0xytavesTXbiQ43UTlf4M5M8kg Cc: payload@ietf.org, Justin Uberti Subject: Re: [payload] New Version Notification for draft-singh-payload-rtp-1d2d-parity-scheme-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2014 16:42:45 -0000 Hi Colin, comments inline. On Thu, Oct 2, 2014 at 11:24 AM, Colin Perkins wrote: > Hi Varun, > > This looks pretty nice from a quick read - I guess the goal is to be some= thing we can reference from draft-ietf-rtcweb-rtp-usage? > Thanks for reading the draft. My recollection of the side meeting is, there would be a draft-*-rtcweb-fec that will contain recommendations for FEC in audio (incl. inband FEC in opus) and video. This document fixes the issues identified with generic FEC and could be referenced by the rtcweb-rtp-usage draft and/or by the rtcweb-fec draft. Adding Justin to the cc, as he was leading the discussion on the FEC draft and may have additional guidance. > I didn=E2=80=99t see any examples of the FEC packets produced by the prot= ection and recovery procedures. Would it be possible to include some in an = appendix in a later version of the draft? In particular, it=E2=80=99d be go= od to see how packets containing =E2=80=9Cadvanced=E2=80=9D features like C= SRC lists and RTP header extensions are protected, as well as the simple ca= ses. > I will add this in an upcoming version of the draft. Thanks again for the i= nput. Cheers, Varun > Cheers, > Colin > > > > > On 1 Oct 2014, at 16:34, Varun Singh wrote: >> Hi all, >> >> As per the discussions in Toronto, I have submitted an initial draft of = a FEC draft. It is based on Ali=E2=80=99s earlier draft in FECFRAME, but ad= apted to align it with the bit mask used in RFC5109. This is an initial ver= sion, the SDP in the draft has not been fixed and is most likely wrong. It = will be fixed in an upcoming version. However, feedback on the header and s= ource/reconstruction algorithm is deeply appreciated. >> >> Cheers, >> Varun (on behalf of the co-authors) >> >> >>> A new version of I-D, draft-singh-payload-rtp-1d2d-parity-scheme-00.txt >>> has been successfully submitted by Varun Singh and posted to the >>> IETF repository. >>> >>> Name: draft-singh-payload-rtp-1d2d-parity-scheme >>> Revision: 00 >>> Title: RTP Payload Format for Non-Interleaved and Interleaved Parity Fo= rward Error >>> Correction (FEC) >>> Document date: 2014-10-01 >>> Group: Individual Submission >>> Pages: 39 >>> URL: http://www.ietf.org/internet-drafts/draft-singh-payload= -rtp-1d2d-parity- >>> scheme-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-singh-payload-rt= p-1d2d-parity-scheme/ >>> Htmlized: http://tools.ietf.org/html/draft-singh-payload-rtp-1d2d= -parity-scheme-00 >>> >>> Abstract: >>> This document defines new RTP payload formats for the Forward Error >>> Correction (FEC) packets that are generated by the non-interleaved >>> and interleaved parity codes from a source media encapsulated in RTP. >>> These parity codes are systematic codes, where a number of repair >>> symbols are generated from a set of source symbols. These repair >>> symbols are sent in a repair flow separate from the source flow that >>> carries the source symbols. The non-interleaved and interleaved >>> parity codes offer a good protection against random and bursty packet >>> losses, respectively, at a cost of decent complexity. The RTP >>> payload formats that are defined in this document address the >>> scalability issues experienced with the earlier specifications >>> including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several >>> improvements. Due to these changes, the new payload formats are not >>> backward compatible with the earlier specifications, but endpoints >>> that do not implement the scheme can still work by simply ignoring >>> the FEC packets. >>> >>> >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > > > > -- > Colin Perkins > https://csperkins.org/ > > > > --=20 http://www.netlab.tkk.fi/~varun/ From nobody Mon Oct 13 07:34:08 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892031A0049; Mon, 13 Oct 2014 07:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROxlIQ5uaxIP; Mon, 13 Oct 2014 07:34:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C04A1A00F7; Mon, 13 Oct 2014 07:32:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20141013143254.31387.90118.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 07:32:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/LfGo5u1BN-4ekzmNUmkCpLrNaIY Cc: payload@ietf.org Subject: [payload] Last Call: (RTP Payload Format for G.711.0) to Proposed Standard X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 13 Oct 2014 14:34:05 -0000 The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for G.711.0' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-10-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the Real-Time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-payload-g7110/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-payload-g7110/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Oct 15 09:28:45 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B149B1A890B; Wed, 15 Oct 2014 09:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PG69kMvpEy58; Wed, 15 Oct 2014 09:28:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE211A8940; Wed, 15 Oct 2014 09:28:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141015162837.8236.26182.idtracker@ietfa.amsl.com> Date: Wed, 15 Oct 2014 09:28:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/c9sEgqBgyNCwxKAyodUYL76rSeM Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-13.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2014 16:28:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for VP8 Video Authors : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-13.txt Pages : 25 Date : 2014-10-15 Abstract: This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-vp8-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 22 06:07:10 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E2F1A9114 for ; Wed, 22 Oct 2014 06:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MSGID_MULTIPLE_AT=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drwSQvuL3zSa for ; Wed, 22 Oct 2014 06:07:00 -0700 (PDT) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) by ietfa.amsl.com (Postfix) with ESMTP id 851CC1A910F for ; Wed, 22 Oct 2014 06:07:00 -0700 (PDT) X-ASG-Debug-ID: 1413983219-03d250199f769b0001-U2jSCT Received: from host101.olm1.com (host101.olm1.com [72.236.255.11]) by cuda.olm1.com with ESMTP id zlcEnwIOOLBukb5C; Wed, 22 Oct 2014 09:06:59 -0400 (EDT) X-Barracuda-Envelope-From: Victor.Demjanenko@vocal.com X-Barracuda-Apparent-Source-IP: 72.236.255.11 Received: from host101.olm1.com (unknown [127.0.0.1]) by host101.olm1.com (Postfix) with ESMTP id 05DC069708F6; Wed, 22 Oct 2014 09:07:00 -0400 (EDT) Received: from dev1PC (unknown [72.43.202.98]) by host101.olm1.com (Postfix) with ESMTP; Wed, 22 Oct 2014 09:06:59 -0400 (EDT) From: "Victor Demjanenko, Ph.D." To: "'Ian Coolidge'" , References: <37DA135E5DD3EC4F8BB70ED85119C04227671BAF@TWHQ-MAIL2.trellisware.com> In-Reply-To: <37DA135E5DD3EC4F8BB70ED85119C04227671BAF@TWHQ-MAIL2.trellisware.com> Date: Wed, 22 Oct 2014 09:07:11 -0400 X-ASG-Orig-Subj: RE: [payload] draft-demjanenko-payload-melpe Message-ID: <0d9201cfedf9$17f670a0$47e351e0$@Demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+LdoQNCk3eBiGdQOCRT7oFbo3z0RigWxUg Content-Language: en-us X-Barracuda-Connect: host101.olm1.com[72.236.255.11] X-Barracuda-Start-Time: 1413983219 X-Barracuda-URL: http://72.236.255.32:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.7500 X-Barracuda-Spam-Score: 0.76 X-Barracuda-Spam-Status: No, SCORE=0.76 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=MSGID_MULTIPLE_AT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.10826 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters Archived-At: http://mailarchive.ietf.org/arch/msg/payload/LTcn72N8l5JltwFaK0UHCnDG110 Cc: payload@ietf.org Subject: Re: [payload] draft-demjanenko-payload-melpe X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 13:07:02 -0000 Everyone, We have updated our proposed RTP payload/SDP exchanges for MELPe based on reviewer comments (thanks Ian and others) and SIP/SDP packet captures from another SIP/MELPe implementation. We would like to obtain support for advancing this draft to an RFC as several such SIP/MELPe systems will be interoperating shortly. Comments are always welcome. Regards, Victor Demjanenko -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Ian Coolidge Sent: Thursday, June 19, 2014 12:26 AM To: draft-demjanenko-payload-melpe@tools.ietf.org Cc: payload@ietf.org Subject: [payload] draft-demjanenko-payload-melpe Hello IETF Payload, My name's Ian Coolidge, and I work at TrellisWare Technologies. We are interested in interoperability of many codecs with RTP. We'd like to endorse this effort to standardize a source format for MELPe RTP payloading. Victor, I have the following comments on draft 0 of the document: 1) Considering the variety of systems that this packetization may occur on, it seems prudent to refer to the raw data as contained in octets, considering there are specific descriptions of bit offset quantities. Using RFC 4867 as reference, this is generally done except where describing endianness specification, as in network byte ordering. 2) The core of this document is trying to say that metadata about the raw MELPe frames can be found within the unused bits of the raw data, described as 'coder rate bits.' It seems like a passage in the introduction reflecting that might be useful, or at least in section 3.1. 3) In section 3.1, there is text, "Unused bits are coded as zeros." After adhering to the specification of this document, however, this should not be the case necessarily. It may be useful to clear up that distinction. 4) Is a contiguous sequence of MELPe frames ever to be handled? If I understand correctly, there could be some ambiguity about how an RTP payloader should interpret that data. Consider the case of 77 octets in a single buffer arriving to an RTP payloader. (77 is chosen because it is the LCM of 7 and 11, the size in octets of 2400bps/600bps and 1200 bps data, respectively) In this case, since both 7 and 11 divide 77 evenly, the length of the buffer alone cannot be used to infer which bits to use for interpreting the 'coder rate bits', since these are different between the two size-classes of MELPe frames. Thanks, Ian _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Wed Oct 22 12:35:16 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04B31AD3B8 for ; Wed, 22 Oct 2014 12:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlqCf0gh5FES for ; Wed, 22 Oct 2014 12:35:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB861AD3BF for ; Wed, 22 Oct 2014 12:35:04 -0700 (PDT) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9MJYdro060740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Oct 2014 14:34:47 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <544806CA.7090505@nostrum.com> Date: Wed, 22 Oct 2014 14:34:34 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Black, David" , "mramalho@cisco.com" , "Paul E. Jones (paulej@packetizer.com)" , "harada.noboru@lab.ntt.co.jp" , "muthu.arul@gmail.com" , "lei.miao@huawei.com" , Richard Barnes References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/payload/10Fy2JyNCTpnH63tmU1oB_VN5DA Cc: "payload@ietf.org" Subject: Re: [payload] [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 19:35:15 -0000 (Dropping the review teams and ietf general - if I've done it right, this will go to David, the authors, and the payload wg list - also explicitly adding Richard) I have not been following payload closely recently, and I apologize for that. The contents of this draft surprise me. I've only skimmed it so far, but finding a discussion of the internals of G.711.0 and how G.711 can be compressed into G.711.0 seems very out of place. Apologies if why this discussion is necessary will become apparent on a deeper read - if so, please call out the essence of why it's needed? Typically, when we've specified the payload format for a codec defined elsewhere, we've restricted the conversation to exactly what you need to do to carry abstract blocks from that payload in RTP. This document is going into much more detail of the insides of those blocks. Why did the group decide to take such a different approach with this payload? Why doesn't it look more like http://datatracker.ietf.org/doc/rfc5391/, for example? Can section 3, and any of section 4 that talks about how you make G.711.0 frames be removed, or at least moved to a different document? This document should just be talking about how to get G.711.0 frames in and out of RTP once you have them. RjS On 10/22/14 10:44 AM, Black, David wrote: > This is a combined Gen-ART and OPS-DIR review. Boilerplate for both follows ... > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at: > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These comments > were written primarily for the benefit of the operational area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > Document: draft-ietf-payload-g7110-03 > Reviewer: David Black > Review Date: October 22, 2014 > IETF LC End Date: October 27, 2014 > IESG Telechat date: October 30, 2014 > > Summary: This draft is on the right track, but has open issues > described in the review. > > Process note: This is the second draft that I've reviewed recently > that has been scheduled for an IESG telechat almost immediately > following the end of IETF Last Call. The resulting overlap of > IETF LC with IESG Evaluation can result in significant last-minute > changes to the draft when issues are discovered during IETF LC. > > This draft describes an RTP payload format for carrying G.711.0 > compressed G.711 voice. The details of G.711.0 compression are > left to the ITU-T G.711.0 spec (which is fine), and this draft > focuses on how to carry the compressed results in RTP and conversion > to/from uncompressed G.711 voice at the communication endpoints. > I found a few major issues and a couple of minor ones, although > a couple of the major issues depend on a meta-issue, - the intended > relationship of this draft be to the ITU-T G.711.0 spec. > > In general, I expect IETF RFCs to be stand-alone documents that make > sense on their own, although one may need to read related documents > to completely understand what's going on. For this draft, I would > expect the actual compression/decompression algorithms to be left to > the ITU-T spec, and this draft to stand on its own in explaining how > to deploy G.711.0 compression/decompression with RTP. If that > expectation is incorrect, and this draft is effectively an RTP Annex > to G.711.0 that must be read in concert with G.711.0, then the > first two major issues below are not problems as they should be > obvious in the G.711.0 spec, although the fact that this draft is > effectively an Annex to G.711.0 should be stated. Otherwise, those > two major issues need attention. > > -- Major Issues (4): > > [A] Section 4.2.3 specifies a detailed decoding algorithm covering > how G.711.0 decompression interacts with received RTP G.711.0 payloads. > A corresponding encoding algorithm specification is needed on the > sending side for G.711.0 compression interaction with RTP sending. > The algorithm will have some decision points in it that cannot be > fully specified, e.g., time coverage of the generated G.711.0 frames. > > [B] The G.711.0 frame format is not specified here, making it very > difficult to figure out what's going on when G.711.0 frames are > concatenated. A specific example is that the concept of a "prefix > code" that occurs at the start of a G.711.0 frame is far too important > to be hidden in step H5 of the decoding algorithm in Section 4.2.3. > > [C] The discussion of use of the SDP ptime parameter is spread out and > imprecise (is SDP REQUIRED?, when is ptime REQUIRED, RECOMMENDED, or > recommended? - it's not obvious). > > A specific example is that this sentence in Section 4.2.4 is an > invitation to interoperability problems ("could infer" - how is that > done and where do the inputs to that inference come from?): > > Similarly, if the number of > channels was not known, but the payload "ptime" was known, one could > infer (knowing the sampling rate) how many G.711 symbols each channel > contained; then with this knowledge determine how many channels of > data were contained in the payload. > > I would suggest that a subsection be added, possibly at the end of > Section 3, to gather/summarize all of the relevant ptime discussion > in one place. I suspect that the contents of this draft are mostly > correct wrt ptime, but it's hard to figure out what's going on from > the current spread-out text. It looks like "ptime" could provide a > cross-check on correctness of G.711.0 decoding - see minor issue [G] > below. > > This major issue [C] is independent of the relationship between this > draft and the G.711.0 spec. > > [D] Backwards compatibility. > > The problem here is that it's not clear that negotiation (e.g., via SDP) > is required. This sentence in Section 3.1 is a particular problem: > > G.711.0, being both lossless and stateless, may also be employed as a > lossless compression mechanism anywhere between end systems which > have negotiated use of G.711. > > That's definitely wrong. Use of G.711.0 when only G.711 has been > negotiated will fail to interoperate correctly. > > A subsection of section 3 on negotiation and SDP usage would help here. > > This major issue [D] is independent of the relationship between this > draft and the G.711.0 spec. > > -- Minor issues (3): > > [E] Section 4.1: > > The only significant difference is that the > payload type (PT) RTP header field will have a value corresponding to > the dynamic payload type assigned to the flow. This is in contrast > to most current uses of G.711 which typically use the static payload > assignment of PT = 0 (PCMU) or PT = 8 (PCMA) [RFC3551] even though > the negotiation and use of dynamic payload types is allowed for > G.711. > > I would change "will have" to "MUST have" and add the following sentence: > > The existing G.711 PT values of 0 and 8 MUST NOT be used for G.711.0 > content. > > I'm suspect that this is obvious to the authors, but it'll help a reader > who's not familiar with the importance of the difference between G.711 > and G.711.0 . > > [F] Section 4.1: > > PT - The assignment of an RTP payload type for the format defined > in this memo is outside the scope of this document. The RTP > profiles in use currently mandate binding the payload type > dynamically for this payload format. > > Good start, but not sufficient - cite the "RTP profiles currently > in use" and I would expect those citations to be normative references. > > Would that be just RFC 3551 and RFC 4585 (both are already normative > references), or are there more RTP profiles? > > [G] Framing errors > > Section 4 generally assumes that the G.711.0 decoder gets handed frames > generated by the G.711.0 encoder and can't get disaligned. I'm not > convinced that this "just works" based on the text in the draft - major > issue [B] is a significant reason why, and explaining that should help. > > Some discussion should be added on why the G.711.0 decoder can't get > disaligned wrt frame boundaries this can't happen, or what the G.711.0 > decoder will do when it discovers that it wasn't handed a complete G.711.0 > frame. For example, this error case and how to deal with it are not > covered by the algorithm in Section 4.2.3. > > -- Nits/editorial comments: > > Section 3.2: > > A6 Bounded expansion: Since attribute A2 above requires G.711.0 to > be lossless for any payload, by definition there exists at > least one potential G.711 payload which must be > "uncompressible". > > The "by definition" statement assumes that every possible bit string is > a valid G.711 input. If that is correct, it should be explicitly stated. > > A8 Low Complexity: Less than 1.0 WMOPS average and low memory > footprint (~5k octets RAM, ~5.7k octets ROM and ~3.6 basic > operations) [ICASSP] [G.711.0]. > > Expand WMOPS on first use, and check for other acronyms that need to be > expanded on first use. > > Section 3.3: > > Since the G.711.0 output frame is "self-describing", a G.711.0 > decoder (process "B") can losslessly reproduce the original G.711 > input frame with only the knowledge of which companding law was used > (A-law or mu-law). > > "companding law"? The term "compression law" is used elsewhere in > this draft, including two paragraphs earlier in this section - I suggest > using "compression law" consistently. > > Section 6: > > We note that something must be stored for any G.711.0 frames that not > received at the receiving endpoint, no matter what the cause. > > "that not" -> "that are not" > > Section 6.2: > > An entire frame of value 0++ or 0-- is expected to be > extraordinarily rare when the frame was in fact generated by a > natural signal (on the order of one in 2^{ptime in samples, minus > one}), as analog inputs such as speech and music are zero-mean and > are typically acoustically coupled to digital sampling systems. > > This doesn't explain where the 2^{ptime in samples, minus one} order > of magnitude estimation came from. What assumption(s) is(are) being > made about randomness and distribution thereof in the analog input? > It might be simpler to delete the parenthesized text. > > Section 11: Congestion Control > > This section is mis-named, as it basically (correctly) says that there > is nothing useful that can be done in G.711.0 compression to respond > to congestion. I would retitle this to "Congestion Considerations". > > Are there opportunities to respond to congestion elsewhere, e.g. > dynamically change the sampling rate? If so, a sentence mentioning > them would be good to add. > > idnits 2.13.01 didn't find anything to complain about ;-). > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > Most of these questions are N/A as this draft specifies a payload format > for RTP, so most of the operations and management concerns are wrt RTP > and SDP. > > A.1.3. Has the migration path been discussed? > > No, see major issue [D] above. > > A.1.4 Have the Requirements on other protocols and functional > components been discussed? > > Only in part - major issues [C] and [D] call out shortcomings in the > discussion of SDP interactions. > > A.1.8 Are there fault or threshold conditions that should be reported? > > Yes, the likelihood and consequences of framing problems at the G.711.0 > decoder (decoder is handed octet strings that are not G.711.0 frames > generated by the encoder) should be discussed. Major issue [B] needs > to be resolved first, and then see minor issue [G]. > > A.2. Management Considerations > > I would expect that the media type registration (Section 5.1 of this draft) > results in this new G.711.0 media type being usable in any relevant > management model and/or framework that has some notion of media type. > > A.3 Documentation > > By itself, this compressed payload format does not look like a likely > source of significant operational impacts on the Internet. > > The shepherd's writeup indicates that an implementation exists. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Oct 22 13:47:45 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF951ACD8D; Wed, 22 Oct 2014 08:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMAeqUiffQUb; Wed, 22 Oct 2014 08:44:26 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209AB1ACD85; Wed, 22 Oct 2014 08:44:25 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9MFiDIO021056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 11:44:16 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s9MFiDIO021056 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1413992657; bh=7b9ALeDMJ0Lk/G6N89JvHEGrj4U=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=BKBoH7P0w/Ug62P2ERyKApcX/UFrPeV7URTybrs6rIoWIL9e94nG2YuohJKvcIMmn ko2GIaOD7YQlOtKj2GsSKjVQofPteYTGv5LD/fEGWeIzSBcM48zOnF9kLp6MpvhuRi Lpbatopss+r8MEm5OP3HhN1Xwbx9IeRS5cDvxXVg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s9MFiDIO021056 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Wed, 22 Oct 2014 11:43:33 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9MFi6rd009197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 11:44:06 -0400 Received: from MXHUB106.corp.emc.com (10.253.58.23) by mxhub01.corp.emc.com (10.254.141.103) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 22 Oct 2014 11:44:06 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.131]) by MXHUB106.corp.emc.com ([10.253.58.23]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 11:44:06 -0400 From: "Black, David" To: "mramalho@cisco.com" , "Paul E. Jones (paulej@packetizer.com)" , "harada.noboru@lab.ntt.co.jp" , "muthu.arul@gmail.com" , "lei.miao@huawei.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03 Thread-Index: Ac/uDvwDXYp5WfZlQayJ5JnEo1/RLQ== Date: Wed, 22 Oct 2014 15:44:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.106] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Vq2NJ8DNsTBxGCjRjz_NsIEx-hg X-Mailman-Approved-At: Wed, 22 Oct 2014 13:47:37 -0700 Cc: "Black, David" , "ietf@ietf.org" , "payload@ietf.org" Subject: [payload] Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 22 Oct 2014 15:44:32 -0000 This is a combined Gen-ART and OPS-DIR review. Boilerplate for both follow= s ... I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at: . Please resolve these comments along with any other Last Call comments you may receive. I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. Document: draft-ietf-payload-g7110-03 Reviewer: David Black Review Date: October 22, 2014 IETF LC End Date: October 27, 2014 IESG Telechat date: October 30, 2014 Summary: This draft is on the right track, but has open issues described in the review. Process note: This is the second draft that I've reviewed recently that has been scheduled for an IESG telechat almost immediately following the end of IETF Last Call. The resulting overlap of IETF LC with IESG Evaluation can result in significant last-minute changes to the draft when issues are discovered during IETF LC. This draft describes an RTP payload format for carrying G.711.0 compressed G.711 voice. The details of G.711.0 compression are left to the ITU-T G.711.0 spec (which is fine), and this draft focuses on how to carry the compressed results in RTP and conversion to/from uncompressed G.711 voice at the communication endpoints. I found a few major issues and a couple of minor ones, although a couple of the major issues depend on a meta-issue, - the intended relationship of this draft be to the ITU-T G.711.0 spec. In general, I expect IETF RFCs to be stand-alone documents that make sense on their own, although one may need to read related documents to completely understand what's going on. For this draft, I would expect the actual compression/decompression algorithms to be left to the ITU-T spec, and this draft to stand on its own in explaining how to deploy G.711.0 compression/decompression with RTP. If that expectation is incorrect, and this draft is effectively an RTP Annex to G.711.0 that must be read in concert with G.711.0, then the first two major issues below are not problems as they should be obvious in the G.711.0 spec, although the fact that this draft is effectively an Annex to G.711.0 should be stated. Otherwise, those two major issues need attention. -- Major Issues (4): [A] Section 4.2.3 specifies a detailed decoding algorithm covering how G.711.0 decompression interacts with received RTP G.711.0 payloads. A corresponding encoding algorithm specification is needed on the sending side for G.711.0 compression interaction with RTP sending. The algorithm will have some decision points in it that cannot be fully specified, e.g., time coverage of the generated G.711.0 frames. [B] The G.711.0 frame format is not specified here, making it very difficult to figure out what's going on when G.711.0 frames are concatenated. A specific example is that the concept of a "prefix code" that occurs at the start of a G.711.0 frame is far too important to be hidden in step H5 of the decoding algorithm in Section 4.2.3. [C] The discussion of use of the SDP ptime parameter is spread out and imprecise (is SDP REQUIRED?, when is ptime REQUIRED, RECOMMENDED, or recommended? - it's not obvious). A specific example is that this sentence in Section 4.2.4 is an invitation to interoperability problems ("could infer" - how is that done and where do the inputs to that inference come from?): Similarly, if the number of channels was not known, but the payload "ptime" was known, one could infer (knowing the sampling rate) how many G.711 symbols each channel contained; then with this knowledge determine how many channels of data were contained in the payload. I would suggest that a subsection be added, possibly at the end of Section 3, to gather/summarize all of the relevant ptime discussion in one place. I suspect that the contents of this draft are mostly correct wrt ptime, but it's hard to figure out what's going on from the current spread-out text. It looks like "ptime" could provide a cross-check on correctness of G.711.0 decoding - see minor issue [G] below. This major issue [C] is independent of the relationship between this draft and the G.711.0 spec. [D] Backwards compatibility. The problem here is that it's not clear that negotiation (e.g., via SDP) is required. This sentence in Section 3.1 is a particular problem: G.711.0, being both lossless and stateless, may also be employed as a lossless compression mechanism anywhere between end systems which have negotiated use of G.711. That's definitely wrong. Use of G.711.0 when only G.711 has been negotiated will fail to interoperate correctly. A subsection of section 3 on negotiation and SDP usage would help here. This major issue [D] is independent of the relationship between this draft and the G.711.0 spec. -- Minor issues (3): [E] Section 4.1: The only significant difference is that the payload type (PT) RTP header field will have a value corresponding to the dynamic payload type assigned to the flow. This is in contrast to most current uses of G.711 which typically use the static payload assignment of PT =3D 0 (PCMU) or PT =3D 8 (PCMA) [RFC3551] even though the negotiation and use of dynamic payload types is allowed for G.711. =20 I would change "will have" to "MUST have" and add the following sentence: The existing G.711 PT values of 0 and 8 MUST NOT be used for G.711.0 content. I'm suspect that this is obvious to the authors, but it'll help a reader who's not familiar with the importance of the difference between G.711 and G.711.0 . [F] Section 4.1: PT - The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profiles in use currently mandate binding the payload type dynamically for this payload format. Good start, but not sufficient - cite the "RTP profiles currently in use" and I would expect those citations to be normative references. Would that be just RFC 3551 and RFC 4585 (both are already normative references), or are there more RTP profiles? [G] Framing errors Section 4 generally assumes that the G.711.0 decoder gets handed frames generated by the G.711.0 encoder and can't get disaligned. I'm not convinced that this "just works" based on the text in the draft - major issue [B] is a significant reason why, and explaining that should help. Some discussion should be added on why the G.711.0 decoder can't get disaligned wrt frame boundaries this can't happen, or what the G.711.0 decoder will do when it discovers that it wasn't handed a complete G.711.0 frame. For example, this error case and how to deal with it are not covered by the algorithm in Section 4.2.3. -- Nits/editorial comments: Section 3.2: A6 Bounded expansion: Since attribute A2 above requires G.711.0 to be lossless for any payload, by definition there exists at least one potential G.711 payload which must be "uncompressible". The "by definition" statement assumes that every possible bit string is a valid G.711 input. If that is correct, it should be explicitly stated. A8 Low Complexity: Less than 1.0 WMOPS average and low memory footprint (~5k octets RAM, ~5.7k octets ROM and ~3.6 basic operations) [ICASSP] [G.711.0]. Expand WMOPS on first use, and check for other acronyms that need to be expanded on first use. Section 3.3: Since the G.711.0 output frame is "self-describing", a G.711.0 decoder (process "B") can losslessly reproduce the original G.711 input frame with only the knowledge of which companding law was used (A-law or mu-law). "companding law"? The term "compression law" is used elsewhere in this draft, including two paragraphs earlier in this section - I suggest using "compression law" consistently. Section 6: We note that something must be stored for any G.711.0 frames that not received at the receiving endpoint, no matter what the cause. "that not" -> "that are not" Section 6.2: An entire frame of value 0++ or 0-- is expected to be extraordinarily rare when the frame was in fact generated by a natural signal (on the order of one in 2^{ptime in samples, minus one}), as analog inputs such as speech and music are zero-mean and are typically acoustically coupled to digital sampling systems. This doesn't explain where the 2^{ptime in samples, minus one} order of magnitude estimation came from. What assumption(s) is(are) being made about randomness and distribution thereof in the analog input? It might be simpler to delete the parenthesized text. Section 11: Congestion Control This section is mis-named, as it basically (correctly) says that there is nothing useful that can be done in G.711.0 compression to respond to congestion. I would retitle this to "Congestion Considerations". Are there opportunities to respond to congestion elsewhere, e.g. dynamically change the sampling rate? If so, a sentence mentioning them would be good to add. idnits 2.13.01 didn't find anything to complain about ;-). --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- Most of these questions are N/A as this draft specifies a payload format for RTP, so most of the operations and management concerns are wrt RTP and SDP. A.1.3. Has the migration path been discussed? No, see major issue [D] above. A.1.4 Have the Requirements on other protocols and functional components been discussed? Only in part - major issues [C] and [D] call out shortcomings in the discussion of SDP interactions. A.1.8 Are there fault or threshold conditions that should be reported? Yes, the likelihood and consequences of framing problems at the G.711.0 decoder (decoder is handed octet strings that are not G.711.0 frames generated by the encoder) should be discussed. Major issue [B] needs to be resolved first, and then see minor issue [G]. A.2. Management Considerations I would expect that the media type registration (Section 5.1 of this draft) results in this new G.711.0 media type being usable in any relevant management model and/or framework that has some notion of media type. A.3 Documentation By itself, this compressed payload format does not look like a likely source of significant operational impacts on the Internet. The shepherd's writeup indicates that an implementation exists. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Mon Oct 27 23:56:18 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AD21A0263 for ; Mon, 27 Oct 2014 23:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, TVD_FROM_1=0.999, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pno1H8WOd-TC for ; Mon, 27 Oct 2014 23:56:15 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BB71A0195 for ; Mon, 27 Oct 2014 23:56:15 -0700 (PDT) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id s9S6u5cU071611; Mon, 27 Oct 2014 23:56:06 -0700 (PDT) (envelope-from finlayson@live555.com) Content-Type: multipart/alternative; boundary="Apple-Mail=_D617B3DE-C991-4CDD-85EE-878336EB4C41" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ross Finlayson In-Reply-To: <013301cf9a71$2f863420$8e929c60$@gmail.com> Date: Mon, 27 Oct 2014 23:56:05 -0700 Message-Id: <39731C83-C883-4E7A-9F0F-C007C7B9AD0E@live555.com> References: <013301cf9a71$2f863420$8e929c60$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/payload/-rEM8n8DuqCAW2y4DFYmAwK0c70 Cc: payload@ietf.org Subject: Re: [payload] WGLC for VP8 (draft-ietf-payload-vp8-11) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 06:56:16 -0000 --Apple-Mail=_D617B3DE-C991-4CDD-85EE-878336EB4C41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 7, 2014, at 10:55 PM, Roni Even wrote: >=20 > Hi, > I reviewed the document and have some comments as individual [=E2=80=A6] > 6. In section 6.2.2 what is the meaning of max-fr and max-fs if the = stream > is sendonly? Ditto if a =E2=80=98declarative=E2=80=99 SDP description is generated = for a stream - e.g., for RTSP? Section 6.2.1 "Mapping of Media Subtype Parameters to SDP=E2=80=9D of = the latest VP8 payload format draft ("draft-ietf-payload-vp8-13=E2=80=9D) = says The parameters "max-fs", and "max-fr", MUST be included in the = "a=3Dfmtp" line of SDP I think this is too strong. IMHO it should be a MUST only if the SDP is = used in an =E2=80=98offer-answer=E2=80=99 environment, and the stream is = not =E2=80=98sendonly=E2=80=99 (i.e., the offerer is asking to receive = video). Also, BTW, the same language is in the corresponding section (7.2.1) of = the new VP9 RTP payload format draft: "draft-uberti-payload-vp9-00=E2=80=9D= Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_D617B3DE-C991-4CDD-85EE-878336EB4C41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jul 7, 2014, at 10:55 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi,
I = reviewed the document and have some comments as individual
[=E2=80=A6]
6. In section 6.2.2 what is the = meaning of max-fr and max-fs if the stream
is = sendonly?

Ditto if a = =E2=80=98declarative=E2=80=99 SDP description is generated for a stream = - e.g., for RTSP?

Section 6.2.1 = "Mapping of Media Subtype Parameters to SDP=E2=80=9D of the latest VP8 = payload format draft ("draft-ietf-payload-vp8-13=E2=80=9D) = says
= The parameters "max-fs", and "max-fr", MUST be included in the = "a=3Dfmtp" line of SDP
I think this is too strong.  IMHO = it should be a MUST only if the SDP is used in an =E2=80=98offer-answer=E2= =80=99 environment, and the stream is not =E2=80=98sendonly=E2=80=99 = (i.e., the offerer is asking to receive video).

Also, BTW, the same language is in the = corresponding section (7.2.1) of the new VP9 RTP payload format draft: = "draft-uberti-payload-vp9-00=E2=80=9D


Ross Finlayson
Live= Networks, Inc.
http://www.live555.com/

= --Apple-Mail=_D617B3DE-C991-4CDD-85EE-878336EB4C41-- From nobody Tue Oct 28 04:50:09 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F671A1BFB for ; Tue, 28 Oct 2014 04:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM1B-EV1WM1l for ; Tue, 28 Oct 2014 04:49:34 -0700 (PDT) Received: from BLU004-OMC2S16.hotmail.com (blu004-omc2s16.hotmail.com [65.55.111.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108261A1C06 for ; Tue, 28 Oct 2014 04:49:33 -0700 (PDT) Received: from BLU181-W94 ([65.55.111.71]) by BLU004-OMC2S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 28 Oct 2014 04:49:33 -0700 X-TMN: [4iWlqsLcC8Hvc25s0Xn2WFLqgkzgdKfC] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_3ff8f913-9608-4def-9f5f-97f650843fb0_" From: Bernard Aboba To: "payload@ietf.org" Date: Tue, 28 Oct 2014 04:49:32 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2014 11:49:33.0402 (UTC) FILETIME=[3D995BA0:01CFF2A5] Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Pf9PWymqnZQ7sz1u8legLWhB1_w Subject: [payload] Question about draft-singh-payload-rtp-1d2d-parity-scheme X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 11:49:35 -0000 --_3ff8f913-9608-4def-9f5f-97f650843fb0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can the masking scheme described in the draft support generation of multi-f= rame FEC such as is described in the paper below?http://static.googleuserco= ntent.com/media/research.google.com/en/us/pubs/archive/41611.pdf As an example=2C say it is desired to use the following 3-frame (6=2C3) FEC= scheme shown in Figure 3:=20 1 0 0 1 0 11 0 1 0 1 0 0 1 1 0 0 1 How would this be represented? It doesn't seem like this would fit within= a 16-bit mask (MSK =3D 00)=2C so does this mean that the 48-bit mask (MSK = =3D 01)is required? =20 = --_3ff8f913-9608-4def-9f5f-97f650843fb0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can the masking scheme described= in the draft support generation of multi-frame FEC such as is described in= the paper below?

As an example=2C say it is desired to= use the following 3-frame (6=2C3) FEC scheme shown in Figure 3: =3B

1 0 0 1 0 1
1 0 1 0 1 0 =3B
= 0 1 1 0 0 1

How would this be represented?  = =3B It doesn't seem like this would fit within a 16-bit mask (MSK =3D 00)= =2C so does this mean that the 48-bit mask (MSK =3D 01)
is requir= ed?  =3B =3B




= --_3ff8f913-9608-4def-9f5f-97f650843fb0_-- From nobody Tue Oct 28 08:56:24 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424E21A8F3B; Tue, 28 Oct 2014 08:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.22 X-Spam-Level: * X-Spam-Status: No, score=1.22 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_OUTLOOK_TAGS=0.052, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz2-dbs60Pwe; Tue, 28 Oct 2014 08:56:08 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140D31A8F37; Tue, 28 Oct 2014 08:56:07 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ex7so9760238wid.12 for ; Tue, 28 Oct 2014 08:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=bW+iuWhGYdsZmE6TqW67u89iWmh3/0IrZ3KOSNYnjTc=; b=BQKTtg1qmAwL35t7LJAEESE3iGciNF9pCYyBAk3A5G5eQ64slQDqqbjUr//BY3AR5S 5de/eCCRFaalcdFKZgsNst7U2Q1Co2cJJmucUhG9DjzruBmQ2iUh/X3AMnMlJWe4s41A E2Z1Yas6Tzl1I/acxo0ps6IgFozh3gnqFCBysTHLGDzhsibvL69XMovfcSesAgoPg1oi EHFMcelB2fy+8dfnWykiCi1G2DUcvMds00eo4tI+g1gjGw0An3J0+fLnGknGepcK+Yh4 BkcZT3iqsENEyk5UbIy0ydhRKPBs1yxSHMP00uQm6M0DtTG0qm23zDb1RuB4gUVMoAN4 NZJQ== X-Received: by 10.180.109.17 with SMTP id ho17mr5806637wib.4.1414511766229; Tue, 28 Oct 2014 08:56:06 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id dq7sm2646907wid.12.2014.10.28.08.56.04 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Oct 2014 08:56:05 -0700 (PDT) From: "Roni Even" To: Date: Tue, 28 Oct 2014 17:56:01 +0200 Message-ID: <087501cff2c7$adc05330$0940f990$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0876_01CFF2D8.7149E680" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/yx2tE3LGKto9LStm+Me39fidB1g== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/payload/iivhJObxH57bEUR1Vr8YYuM6VY0 Cc: payload@ietf.org Subject: [payload] AVTcore agenda for IETF91 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 15:56:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0876_01CFF2D8.7149E680 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0877_01CFF2D8.7149E680" ------=_NextPart_001_0877_01CFF2D8.7149E680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the preliminary agenda, if I missed any requests for agenda time or had wrong information please let me know Roni Even AVTcore & Payload co-chair ------=_NextPart_001_0877_01CFF2D8.7149E680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = preliminary agenda, if I missed any requests for agenda time or had = wrong information please let me know

Roni Even

AVTcore = & Payload co-chair

------=_NextPart_001_0877_01CFF2D8.7149E680-- ------=_NextPart_000_0876_01CFF2D8.7149E680 Content-Type: text/plain; name="a1410.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="a1410.txt" Audio/Video Transport Core Maintenance (AVTCore) Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Magnus Westerlund Roni Even AGENDA Monday, 10 November 2014 at 9:00-11:30 (Lehua Suite) ---------------------------------------------------- 09:00 AVTCore Status Update (Chairs, 20) 09:20 RTP Topologies (Stephan Wenger, 10) draft-ietf-avtcore-rtp-topologies-update-04 09:30 Encrypted Key Transport for Secure RTP (John Mattsson, 10) draft-ietf-avtcore-srtp-ekt-03 09:40 Requirements for Private Media in a Switched Conferencing = Environment(Nermeen Ismail, 30) draft-jones-avtcore-private-media-reqts-00 10:10 RTP Payload Format for Non-Interleaved and Interleaved Parity = FEC(Varun Singh, 10) draft-singh-payload-rtp-1d2d-parity-scheme-00 10:20 End ------=_NextPart_000_0876_01CFF2D8.7149E680 Content-Type: text/html; name="a1401.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="a1401.html" Audio/Video Transport Core Maintenance (AVTCore) Working Group = Agenda

Audio/Video Transport Core Maintenance = (AVTCore) Working Group Agenda

Chairs: Magnus Westerlund , Roni = Even

Monday, 10 November 2014 at 9:00-11:30 (Lehua Suite)

09:00 AVTCore Status UpdateChairs
09:20 RTP TopologiesStephan Wenger
draft-ietf-avtcore-rtp-topologies-update-04
09:30 Encrypted Key Transport for Secure RTPJohn Mattsson
draft-ie= tf-avtcore-srtp-ekt-03
09:40 Requirements for Private Media in a Switched = Conferencing EnvironmentNermeen Ismail
draft-jones-avtcore-private-media-reqts-00
10:10 RTP Payload Format for Non-Interleaved and = Interleaved Parity FECVarun Singh
draft-singh-payload-rtp-1d2d-parity-scheme-00
10:20 End
------=_NextPart_000_0876_01CFF2D8.7149E680-- From nobody Tue Oct 28 15:46:55 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F271A0393 for ; Tue, 28 Oct 2014 15:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5uIqiw_s2R0 for ; Tue, 28 Oct 2014 15:46:50 -0700 (PDT) Received: from BLU004-OMC2S6.hotmail.com (blu004-omc2s6.hotmail.com [65.55.111.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F59C1A0030 for ; Tue, 28 Oct 2014 15:46:50 -0700 (PDT) Received: from BLU181-W28 ([65.55.111.73]) by BLU004-OMC2S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 28 Oct 2014 15:46:49 -0700 X-TMN: [0nIE/zXnrJFsKSVaVGlmPL5E3aHVhMXA] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_77ed1c38-392a-4546-9938-ace8632de30d_" From: Bernard Aboba To: "payload@ietf.org" Date: Tue, 28 Oct 2014 15:46:48 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2014 22:46:49.0415 (UTC) FILETIME=[0F4B6570:01CFF301] Archived-At: http://mailarchive.ietf.org/arch/msg/payload/vArGn9c5BCSooUOaN2ESAMW7Z3Q Subject: [payload] Problem with draft-ietf-payload-rtp-h265 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2014 22:46:53 -0000 --_77ed1c38-392a-4546-9938-ace8632de30d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just noticed a bunch of problems introduced into the draft by the use of th= e "Single Stream Mode" and "Multiple Stream Mode" terminology.=20 Dependency of one RTP stream on another RTP stream is typically=0A= indicated as specified in [RFC5583]. When an RTP stream A=0A= depends on another RTP stream B=2C the RTP stream B is referred to=0A= as a dependee RTP stream of the RTP stream A.=0A= [BA] The statement above is wrong. RFC 5583 dependency groups based on theu= se of a=3Dgroup:DDP and a=3Dmid: lines and therefore can only deal with dep= endencies between m-lines (multiple RTP sessions). If the RTP streamsare s= ent within the same RTP session=2C the dependency cannot be indicated as sp= ecified in RFC 5583. =0A= Informative note: An MSM may involve one or more RTP sessions.=0A= Each RTP stream in an MSM may be in its own RTP session or a=0A= set of multiple RTP streams in an MSM may belong to the same=0A= RTP session=2C e.g. as indicated by the mechanism specified in=0A= the Internet-Draft [I-D.ietf-avtcore-rtp-multi-stream] or in=0A= [I-D.ietf-mmusic-sdp-bundle-negotiation].=0A= =0A= SSM SHOULD be used for point-to-point unicast scenarios=2C while=0A= MSM SHOULD be used for point-to-multipoint multicast scenarios=0A= where different receivers require different operation points of=0A= the same HEVC bitstream=2C to improve bandwidth utilizing=0A= efficiency. [BA] This is also wrong. While it was accurate that Multi-Session-Transport= should be used for point-to-multipoint multicast scenarios=2C Single-Sessio= n-Transportof multiple streams can be used in point-to-point unicast scenar= ios. =0A= The transmission mode is indicated by the tx-mode media parameter=0A= (see section 7.1). If tx-mode is equal to "SSM"=2C SSM MUST be=0A= used. Otherwise (tx-mode is equal to "MSM")=2C MSM MUST be used. [BA] This also does not make sense=2C because it will not allow for disting= uishingbetween multi-stream within a single session=2C and multi-session-tr= ansport. Within SDP this is critical because RFC 5583 is not designed to de= al withsingle session-multi stream transport=2C and therefore we will get n= egotiationfailures. =0A= =0A= Receivers MUST support both SSM and MSM.=0A= [BA] This is a nice statement=2C but by the above confusion created by bad = terminology will make itmeaningless. Overall=2C this document creates addi= tional confusion above and beyond that which wealready had in RFC 6190. =20 = --_77ed1c38-392a-4546-9938-ace8632de30d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Just noticed a bunch of problems= introduced into the draft by the use of the "Single Stream Mode" and "Mult= iple Stream Mode" terminology. =3B

=
   Dependency of one RTP stream on another RTP stream is typically=0A=
   indicated as specified in [RFC5583].  When an RTP stream A=0A=
   depends on another RTP stream B=2C the RTP stream B is referred to=0A=
   as a dependee RTP stream of the RTP stream A.=0A=



[BA] The state=
ment above is wrong. RFC 5583 dependency groups based on the
use of a=3Dgroup:DDP and a=3Dmid: line=
s and therefore can only deal with =3B
dependencies between m-lines (multiple RTP sessions).  I=
f the RTP streams
are sent=
 within the same RTP session=2C the dependency cannot be indicated as speci=
fied in RFC 5583.   
=0A=
      Informative note: An MSM may involve one or more RTP sessions.=0A=
      Each RTP stream in an MSM may be in its own RTP session or a=0A=
      set of multiple RTP streams in an MSM may belong to the same=0A=
      RTP session=2C e.g. as indicated by the mechanism specified in=0A=
      the Internet-Draft [I-D.ietf-avtcor=
e-rtp-multi-stream] or in=0A=
      [I-D.ietf-mmusic-sdp-bundle-ne=
gotiation].=0A=
=0A=
   SSM SHOULD be used for point-to-point unicast scenarios=2C while=0A=
   MSM SHOULD be used for point-to-multipoint multicast scenarios=0A=
   where different receivers require different operation points of=0A=
   the same HEVC bitstream=2C to improve bandwidth utilizing=0A=
   efficiency.

[BA] This is also wrong. Whi=
le it was accurate that Multi-Session-Transport
should be used for point-to-multipoint multicast sc=
enarios=2C Single-Session-Transport
of multiple streams can be used in point-to-point unicast scena=
rios. 
=0A=
   The transmission mode is indicated by the tx-mode media parameter=0A=
   (see section 7.1).  If tx-mode is equal to "SSM"=2C SSM MUST=
 be=0A=
   used.  Otherwise (tx-mode is equal to "MSM")=2C MSM MUST be used.
<=
pre class=3D"newpage" style=3D"font-size: 1em=3B margin-top: 0px=3B margin-=
bottom: 0px=3B page-break-before: always=3B">
[BA] This also does not make sense=2C because it =
will not allow for distinguishing
between multi-stream within a single session=2C and multi-session=
-transport. =3B
With=
in SDP this is critical because RFC 5583 is not designed to deal with
= 
single session-multi stream t=
ransport=2C and therefore we will get negotiation
failures. =0A=
=0A=
   Receivers MUST support both SSM and MSM.=0A=


[BA] This is a nice statement=2C but by t=
he above confusion created by bad terminology will make it
meaningless.  Overall=2C this document =
creates additional confusion above and beyond that which we
already had in RFC 6190.
<= div>
= --_77ed1c38-392a-4546-9938-ace8632de30d_-- From nobody Wed Oct 29 07:45:03 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D8D1A0177 for ; Wed, 29 Oct 2014 07:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY5Lwl9e8T_R for ; Wed, 29 Oct 2014 07:44:59 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264D01A017A for ; Wed, 29 Oct 2014 07:44:59 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so3142333ieb.32 for ; Wed, 29 Oct 2014 07:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1fXd9T0zjEVIjFooO6yBA2oevVqasumzE/Xhy7GFOGM=; b=0KIeE1wDJEjaGRbQGqRKg0ACLE+fTj3gyIFIuGvqhP23uDx1OQrOFOyVbznyRMotEv Yhwn7O1D6H1TgyAb41BVWlab+y3GeaSCbyjw4k/jCYE4oJal10K5tGsU2YpJqpZ//mvl SMONjV9Rn5DPrD0yQI77RSQ0cjDZ2tWbTKoxLRfZhCb3/7fHSaIkeXxYBfDksaXWObNJ P8EOiiELFzoPFM+gN9f/2vwOfpDp8Koo0ScCm9ZrlMOCvLi9mWDQSwMclIjLJ0WdfGx7 vKDSiVTSzpkjYZsOW8S/g75TpBqH6IV7bKzaP1OthWGP2R/cFMAtqT2wU6gePXJp3uQt 4fgg== X-Received: by 10.107.155.9 with SMTP id d9mr12416103ioe.12.1414593898501; Wed, 29 Oct 2014 07:44:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.95.199 with HTTP; Wed, 29 Oct 2014 07:44:38 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Wed, 29 Oct 2014 16:44:38 +0200 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/IP9zUvdePb_jBnERqSvmd9u1adI Cc: "payload@ietf.org" Subject: Re: [payload] Question about draft-singh-payload-rtp-1d2d-parity-scheme X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 14:45:02 -0000 Hi Bernard, See inline. -Varun On Tue, Oct 28, 2014 at 1:49 PM, Bernard Aboba wrote: > Can the masking scheme described in the draft support generation of > multi-frame FEC such as is described in the paper below? > http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/41611.pdf > > As an example, say it is desired to use the following 3-frame (6,3) FEC > scheme shown in Figure 3: > > 1 0 0 1 0 1 > 1 0 1 0 1 0 > 0 1 1 0 0 1 > The row FECs fit in 6, so that should be fine The columns have SN-base, and I think 13 bits should be enough. SN_base: 1 RLE Mask for offset packets 1, 7, 13 SN_base: 6 RLE Mask for offset packets 1, 13 If we wanted a FEC for all the packets, then that would need the larger mask. > How would this be represented? It doesn't seem like this would fit within > a 16-bit mask (MSK = 00), so does this mean that the 48-bit mask (MSK = 01) > is required? > See above, but for this example it doesn't seem like it. unless I miscalculated something. > > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -- http://www.netlab.tkk.fi/~varun/ From nobody Wed Oct 29 08:36:01 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4755E1A0179; Wed, 29 Oct 2014 08:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.811 X-Spam-Level: X-Spam-Status: No, score=-13.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A6Jof4lqapW; Wed, 29 Oct 2014 08:35:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E101A014E; Wed, 29 Oct 2014 08:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37377; q=dns/txt; s=iport; t=1414596937; x=1415806537; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=x1Wskr5iCrBOnMjXIb1qHWG0zdk03qs0kUz8aVr1oNQ=; b=dY9aM9NI1/UTSeGdYRTOjU4wjqaQ6jLko1NAym1aL52/m78JxE99zOBf pO2CsSu+LYmauNNw4fpL2FHUQOBY3SoyI3elzIubKgn9bWc92Co6nxpqu B0VOaqEJNuemROh0gjIpTIqvg/fZkuEvfs5qKAz7jX1KHAHl7Ejyrx/1F k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAD4IUVStJV2a/2dsb2JhbABZA4MOVFgEzhuHSwKBGxYBAQEBAX2EAgEBAQQaAQxLBwwEAgEIEQMBAQELHQchERQJCAEBBAENBQgBEgSIDQMSDcEFDYY4AQEBAQEBAQEBAQEBAQEBAQEBAQEBF45PJ4EwAREBHyEQBwYLgxyBHgWEYoFLhEI7hEOCHoRKgXdMgX5Bg0I8gw2DL4csgmCEA4N4bAGBBQYDFwQegQMBAQE X-IronPort-AV: E=Sophos;i="5.04,810,1406592000"; d="scan'208";a="364421503" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 29 Oct 2014 15:35:36 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9TFZZmV026023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 15:35:35 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.5]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 10:35:35 -0500 From: "Michael Ramalho (mramalho)" To: "Black, David" , "Paul E. Jones (paulej@packetizer.com)" , "harada.noboru@lab.ntt.co.jp" , "muthu.arul@gmail.com" , "lei.miao@huawei.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03 Thread-Index: Ac/uDvwDXYp5WfZlQayJ5JnEo1/RLQEnG7PQ Date: Wed, 29 Oct 2014 15:35:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.234.145] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/SxvGDjW34dVVr-Xpdnx_E72snJQ Cc: "ietf@ietf.org" , "payload@ietf.org" Subject: Re: [payload] Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 15:35:51 -0000 David, The authors of the G.711.0 RTP Payload Draft thank you for the comments bel= ow. It is clear from the caliber of your comments that you spent a lot of t= ime on this. G.711.0 being a variable length stateless and lossless compression for G.71= 1 (a sampled-oriented encoding) causes a lot of confusion to those who occa= sionally think of it as "a codec" instead of the lossless compression mecha= nism it is. Thus, this was a hard payload format to write due to some of the pre-concei= ved notions of what G.711.0 is and an even harder one for someone to review= (as it is not sample-based or fixed-length frame-based encoding that the a= uthors of RFC 3550/3511 assumed/envisioned). So, I really do thank you for the effort here, David. You must have drawn t= he short-straw. My response to your comments/questions are made in-line below (my comments = with "\begin {Reply to [issue]}" and my proposed fixes within these are hig= hlighted with ">>"). Regards, Michael A. Ramalho, Ph.D. -----Original Message----- From: Black, David [mailto:david.black@emc.com]=20 Sent: Wednesday, October 22, 2014 11:44 AM To: Michael Ramalho (mramalho); Paul E. Jones (paulej@packetizer.com); hara= da.noboru@lab.ntt.co.jp; muthu.arul@gmail.com; lei.miao@huawei.com; General= Area Review Team (gen-art@ietf.org); ops-dir@ietf.org Cc: ietf@ietf.org; payload@ietf.org; Black, David Subject: Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03 This is a combined Gen-ART and OPS-DIR review. Boilerplate for both follow= s ... I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at: . Please resolve these comments along with any other Last Call comments you m= ay receive. I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the operational area di= rectors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. Document: draft-ietf-payload-g7110-03 Reviewer: David Black Review Date: October 22, 2014 IETF LC End Date: October 27, 2014 IESG Telechat date: October 30, 2014 Summary: This draft is on the right track, but has open issues described in the review. Process note: This is the second draft that I've reviewed recently that has= been scheduled for an IESG telechat almost immediately following the end o= f IETF Last Call. The resulting overlap of IETF LC with IESG Evaluation ca= n result in significant last-minute changes to the draft when issues are di= scovered during IETF LC. This draft describes an RTP payload format for carrying G.711.0 compressed = G.711 voice. The details of G.711.0 compression are left to the ITU-T G.71= 1.0 spec (which is fine), and this draft focuses on how to carry the compre= ssed results in RTP and conversion to/from uncompressed G.711 voice at the = communication endpoints. I found a few major issues and a couple of minor ones, although a couple of= the major issues depend on a meta-issue, - the intended relationship of th= is draft be to the ITU-T G.711.0 spec. In general, I expect IETF RFCs to be stand-alone documents that make sense = on their own, although one may need to read related documents to completely= understand what's going on. For this draft, I would expect the actual com= pression/decompression algorithms to be left to the ITU-T spec, and this dr= aft to stand on its own in explaining how to deploy G.711.0 compression/dec= ompression with RTP. If that expectation is incorrect, and this draft is e= ffectively an RTP Annex to G.711.0 that must be read in concert with G.711.= 0, then the first two major issues below are not problems as they should be= obvious in the G.711.0 spec, although the fact that this draft is effectiv= ely an Annex to G.711.0 should be stated. Otherwise, those two major issue= s need attention. -- Major Issues (4): [A] Section 4.2.3 specifies a detailed decoding algorithm covering how G.71= 1.0 decompression interacts with received RTP G.711.0 payloads. A corresponding encoding algorithm specification is needed on the sending s= ide for G.711.0 compression interaction with RTP sending. The algorithm will have some decision points in it that cannot be fully spe= cified, e.g., time coverage of the generated G.711.0 frames. \begin {Reply to [A]} I believe you are correct. As with everything associated with G.711.0 , a l= onger answer is required. At the sender end, the G.711.0 encoder itself has decided exactly how it de= sires to send compressed G.711.0. As an example outlined earlier in Section= 3.3.1 (Multiple G.711.0 Output Frame per RTP Payload Considerations), a gi= ven G.711.0 encoder could choose to encode 20ms of input G.711 symbols as: = 1) a single 20ms G.711.0 frame, or 2) as two 10 ms G.711.0 frames, or 3) an= y combination of 5 ms or 10 ms G.711.0 frames. The decision criteria is NOT= SPECIFIED in the ITU-T G.711.0 standard; a G.711.0 encoder could choose b= ase on: 1) which encoding produced resulted in fewer bits, 2) simple operat= ion such as always using 20 ms G.711.0 frames, or 3) any other criteria of = its choosing. Thus the encoding process is NOT DETERMINISTIC in how many G.= 711.0 frames could represent a given ptime of G.711 symbols. [Aside: Using a 20 ms ptime example, there could be 1, 2, 3 or 4 G.711.0 fr= ames in a RTP payload in any one of six combinations in a G.711.0 payload (= [20ms],[ 10ms:10ms],[10ms:5ms:5ms], [5ms:10ms:5ms], [5ms:5ms:10ms],[5ms:5ms= :5ms:5ms]).] Thus, it is important to note that the >>G.711.0 STANDARD<< only specifies = the encoding of an individual input G.711 frame (which can only have length= s of 40, 80, 160, 240 or 320 G.711 symbols) to a valid G.711.0 frame. The authors of this draft assumed that the G.711.0 compressor/encoder provi= der has already made the encoding decision on the number of G.711.0 frames = INDEPENDENT of the decompressor/decoder and OUTSIDE any sender-side RTP pay= load processing. That is, the G.711.0 encoder just passed the result (any o= f the combinations above) the compressor/encoder made to the G.711.0 RTP la= yer at the sender to be incorporated into the G.711.0 payload. The RTP laye= r could then choose to add padding octets (0x00) to form the final G.711.0 = payload. >From that perspective, the co-authors of the draft believed what was import= ant for the draft was "what could be on-the-wire". However, since the ITU-T= G.711.0 standard only specifies the individual G.711 frame to G.711.0 mapp= ing, there is a benefit in explicitly calling out the possible "payload enc= oding process" in this section (4) as well. >>Proposed Action: If my co-authors agree, I could write a very small secti= on titled "G.711.0 RTP Payload Encoding Process" (inserted in-between the p= resent 4.2.2 and 4.2.3). This paragraph-long section will reverse reference= Section 3.3.1 and remind the implementer that they can - at their option -= chose to use any of the allowable encoding possibilities described in it. = I think David is correct, we assumed that some entity PURPOSELY NOT defined= by the G.711.0 standard (the provider of the "G.711.0 compressor/encoder")= already made those decisions and that explicit definition of that decision= is not specified anywhere in any SDO document (so why not here?). Indeed, = any "standard G.711.0 encoder" offered by a vendor would likely have that f= unctionality within it (so a RTP implementer wouldn't need to know it eithe= r). I could also remind the reader that one could use a single G.711.0 fram= e per ptime (if a G.711.0 frame supported that ptime) for the least complic= ated encoding case. Would that work David? Would that work co-authors? \end {Reply to [A]} [B] The G.711.0 frame format is not specified here, making it very difficul= t to figure out what's going on when G.711.0 frames are concatenated. A sp= ecific example is that the concept of a "prefix code" that occurs at the st= art of a G.711.0 frame is far too important to be hidden in step H5 of the = decoding algorithm in Section 4.2.3. \begin {Reply to [B]} We welcome comments on how to improve this section, as it is complicated. W= e did attempt to describe only what is necessary for understanding. At the beginning of Section 4.2.3 we IMMEDIATELY reference the ITU-T G.711.= 0 document - as it is that document that describes how to "decode a G.711.0= bit-stream". We really want the reader needing to know the details to go t= here first. Indeed, the entire G.711.0 payload could be provided to the G.7= 11.0 bit stream decoder in the ITU-T G.711.0 reference code and obtain all = the uncompressed G.711 samples in the RTP payload and be finished without k= nowing anything in this section. The bit-stream decoder in the ITU-T reference code was defined to parse the= individual compressed G.711.0 frames. However the G.711.0 >>STANDARD ITSEL= F<< defines only the mapping between the 40, 80, 160, 240 or 320 G.711 symb= ols presented to it and the G.711.0 frame produced from those 40, 80, 160, = 240 or 320 samples (i.e., only Section 3.3). In other words, someone designing a G.711.0 encoder could choose how to par= tition the uncompressed G.711 symbols into groups of 40, 80, 160, 240 or 32= 0 samples and then individually encode them into individual G.711.0 frames = as per my reply to [A]. Any arbitrary value corresponding to a valid "G.711.0 prefix code" is NOT u= nique (or otherwise special) in that it can be appear anywhere within a G.7= 11.0 frame; however a given value for a prefix code DOES have a unique mean= ing >>TO THE G.711.0 DECODER<< (not the RTP machinery) when it is present a= t the beginning of a G.711.0 frame.=20 The mention of the prefix code (with immediate reference back to the ITU-T= specification I might add) was simply side information conveyed to the rea= der for purposes of understanding. The G.711.0 decoder actually "reads it" = and then uses it to know how many source G.711 to produce (in this case exa= ctly M G.711 samples). The only thing the G.711.0 RTP implementer needs to = know is that the G.711 sample buffer returned by the G.711.0 decoder will c= ontain exactly M samples of G.711. To be precise, the ITU-T specified G.711.0 decoder returns not only the sam= ples themselves, but the number of samples, M upon its exit (we were not 10= 0% clear on this - fix proposed below). The value of M is important to the = RTP decoding process; the value, structure or meaning of "prefix code" isn'= t. The only exception is that 0x00 has a special meaning when it appears wh= ere a prefix code might otherwise be expected. To accommodate padding, 0x00 may be placed anywhere between the encoded G.7= 11.0 frames (we only recommend that any desired padding be placed at the en= d of the RTP payload). But to convey this "0x00" for padding, we needed to = describe that 0x00 could not be a valid prefix code. If it were not for the= desire for padding, we would not have even mentioned that a "prefix code" = existed in a G.711.0 frame. In the text we mention that a "0x00" where a prefix code is expected in a G= .711.0 bit stream is "silently ignored" by a G.711.0 frame decoder. The mention of the prefix code was only for general information of what the= G.711.0 decoder actually does (generally how it decodes the frame and that= "0x00" isn't a valid prefix code) and what is expected by the RTP machiner= y when the G.711.0 decoder is finished decoding (the value of M and the M i= ndividual G.711 symbols).=20 Summary: The interested reader desiring knowledge of how to decode a G.711= .0 bit stream should really read the ITU-T document first; that is why we p= ut the reference to the "ITU-T G.711.0 Reference code" as the FIRST sentenc= e in Section 4.2.3. They don't need to know what a "prefix code" is other t= han it is used by the G.711.0 decoder to know how many samples (M) it will = produce and that the value of M will be returned by the G.711.0 decoder. >>Proposed Action: I would suggest the following change in H5 to make this = clearer: From: The G.711.0 decoder will produce exactly M G.711 source symbols. To: Then the ITU-T specified G.711.0 decoder will produce exactly M G.711 s= ource symbols and return both the symbols (in a buffer up to 321 octets in = length if the in-place ITU-T reference code is used) and the value of M upo= n exit. That information - the samples and the value of M - is the only thing the r= eader needs to know. Does that work for you, David? \end {Reply to [B]} [C] The discussion of use of the SDP ptime parameter is spread out and impr= ecise (is SDP REQUIRED?, when is ptime REQUIRED, RECOMMENDED, or recommende= d? - it's not obvious). A specific example is that this sentence in Section 4.2.4 is an invitation = to interoperability problems ("could infer" - how is that done and where do= the inputs to that inference come from?): Similarly, if the number of channels was not known, but the payload "ptime" was known, one could infer (knowing the sampling rate) how many G.711 symbols each channel contained; then with this knowledge determine how many channels of data were contained in the payload. I would suggest that a subsection be added, possibly at the end of Section = 3, to gather/summarize all of the relevant ptime discussion in one place. = I suspect that the contents of this draft are mostly correct wrt ptime, but= it's hard to figure out what's going on from the current spread-out text. = It looks like "ptime" could provide a cross-check on correctness of G.711.= 0 decoding - see minor issue [G] below. This major issue [C] is independent of the relationship between this draft = and the G.711.0 spec. \begin {Reply to [C]} We underspecified the use of SDP on purpose, but I also agree that some te= xt on why we wish to leave it underspecified could be useful. In Section 5 = we simply say "parameters that may be used to configure [G.711.0 RTP transm= ission]". Perhaps the MAY should be capitalized? Or more text? As you know and appreciate, one could put an arbitrary number of G.711.0 fr= ames in a G.711.0 RTP payload and the decoder really won't know how many G.= 711 samples were compressed in that payload until it decodes the entire pay= load. Point A: For systems that use SDP and have specified a ptime (IANA registra= tion for ptime is as an OPTIONAL parameter per WG agreement), a check can b= e performed to see if the required number of G.711 samples is present. Point B: For systems that use SDP and have not specified ptime - the payloa= d can still be decoded. In this case there is no a priori expectation on th= e number of G.711 symbols contained within the G.711.0 RTP payload and thus= no check is possible. Point C: For systems that use SDP we RECOMMEND that ptime SHOULD be used (s= ee IANA registration text). The reason is that such a check can be made! All three points (A, B & C) have been agreed to during previous meetings/di= scussions. However, some USERS of the G.711.0 payload format may wish to use the RTP f= ormat itself but NOT use SDP! A good example is a "in-the-middle" compressi= on of a G.711 flow (into a G.711.0 flow) and a corresponding decompression = of the G.711.0 flow back into a G.711 flow. This is possible in many networ= k arrangements (e.g., enterprise to enterprise) where the compression and d= ecompression endpoints know the PT corresponding to G.711.0 use within thei= r administrative domain. [Aside: At one time this RTP Payload format had both the payload definition= (this draft) and G.711.0-specific use cases within it. Previous WG discuss= ion supported the splitting out of the use-cases into a separate draft (a "= G.711.0 use case" draft). I have such an expired draft, but we agreed to de= fer work on it until after the RTP payload format was complete. Thus some e= lements of uses outside of G.711.0 running in the endpoints would be descri= bed in the other use-case draft.] The SDP discussion is a little wordy, but this is a result of G.711.0 not b= eing a codec, but rather a variable length, frame-based lossless compressio= n/decompression. That is G.711.0 is NOT a (sample-based or frame-based) cod= ec in the usual sense that RFC 3550/3551 anticipated, but does require some= "G.711 specific" information to be passed to it (e.g., complaw). For the passage you quoted above, the FOLLOWING TWO SENTENCES in the draft = provide a forward reference in the document to when the "channels" and "pti= me" parameters are needed and referenced (Section 5.1); because we have had= no need prior to that point in the draft to discuss use of ANY particular = session negotiation protocol. SDP is a dominant IETF protocol for media negotiation; but even RFC 3551 me= ntions H.245 and the fact that other mapping methods are possible (includin= g "no negotiation" methods). Indeed, the "in-the-middle" use case described= in this email (and at earlier IETF Payload meetings) may or may not have a= ny a priori negotiation of PT at all within an administrative domain (e.g.,= the G.711.0 PT may be a network configured parameter specific to a company= network). >>Proposed Action: The discussion of ptime (and the channels parameter) in = this section is primarily for the purpose of a check. If it is any comfort,= that paragraph has had lots of input to it previously (so you responded to= a complicated issue). And since we have no need to describe "ptime issues"= or session negotiation issues prior to this point (Section 4.2.4) in the d= ocument AND ptime isn't a required negotiation parameter AND we put a forwa= rd reference to Section 5.1 for "ptime" when SDP is used, I hesitate to me= ntion such an optional parameter here in Section 3. >>Proposed action: No Change (the forward references are enough). \end {Reply to [C]} [D] Backwards compatibility. The problem here is that it's not clear that negotiation (e.g., via SDP) is= required. This sentence in Section 3.1 is a particular problem: G.711.0, being both lossless and stateless, may also be employed as a lossless compression mechanism anywhere between end systems which have negotiated use of G.711. That's definitely wrong. Use of G.711.0 when only G.711 has been negotiate= d will fail to interoperate correctly. A subsection of section 3 on negotiation and SDP usage would help here. This major issue [D] is independent of the relationship between this draft = and the G.711.0 spec. \begin {Reply to [D]} The passage you quote is in Section 3 which is "General Information and Us= e of ITU-T G.711.0 Codec) and is: 1) prior to ANY discussion of the use of = G.711.0 in RTP (or even packet networks), and 2) prior to any discussion of= media negotiation when using RTP (e.g., SDP). Thus the context for this se= ntence is at the codec bit stream (or packet payload) level of the ITU-T co= dec. It stands on its own and is definitely correct.=20 When the compression of a G.711 payload to a G.711.0 payload occurs somewhe= re on the end-to-end path and the corresponding decompression from a G.711.= 0 payload to a G.711 payload occurs prior to the receiving endpoint the rec= eiving endpoint doesn't know the (lossless) compression occurred on the PAY= LOAD (the context in this section). As mentioned previously, this is possib= le in many arrangements (in RTP) where the compression and decompression en= dpoints know the PT corresponding to G.711.0 use within their administrativ= e domain (a reserved or not-used-in-their-domain PT) and desire to do this. That is the beauty of lossless compression - the receiving endpoint doesn't= know (or need to know) that payload compression occurred. To imply otherwi= se is to dismiss lossless compression (e.g., CRTP, ECRTP, ROHC) that lossle= ssly compress and decompress arbitrary parts of packets (in the case of CRT= P/ECRTP/RHOC, the headers) in between the endpoints without the endpoints e= xplicit knowledge of the compression. Please note that this property isn't possible with lossy *CODECS*, as the t= ranscode will typically introduce some distortion which would be unknown to= the receiving endpoint but nevertheless present. This is one of the many s= ubtleties that people reading about G.711.0 have when considering it as if = it were a (lossy) codec - they ASSUME that G.711.0 is a TRANSCODE and not t= he lossless, STATELESS compression of the MEDIA PAYLOAD that it is. Again, we had working group agreement (I think in Quebec) that a use-case d= ocument could follow this G.711.0 RTP payload format document to describe h= ow to do the mapping in RTP for these "compression-in-the-middle" cases. Hi= gh level summary is that you copy the G.711 RTP header verbatim into the G.= 711.0 RTP header except for the PT. I have a draft on the use case document= which I let expire until this RTP payload definition is finished. >>Proposed Action: No Change. We have more than enough words in the documen= t to describe all the attributes of G.711.0 (Section 3.2) in this section o= f the document that discusses properties of the >>ITU-T specification<<. \end {Reply to [D]} -- Minor issues (3): [E] Section 4.1: The only significant difference is that the payload type (PT) RTP header field will have a value corresponding to the dynamic payload type assigned to the flow. This is in contrast to most current uses of G.711 which typically use the static payload assignment of PT =3D 0 (PCMU) or PT =3D 8 (PCMA) [RFC3551] even though the negotiation and use of dynamic payload types is allowed for G.711. =20 I would change "will have" to "MUST have" and add the following sentence: The existing G.711 PT values of 0 and 8 MUST NOT be used for G.711.0 content. I'm suspect that this is obvious to the authors, but it'll help a reader wh= o's not familiar with the importance of the difference between G.711 and G.= 711.0 . \begin {Reply to [E]} >>Proposed Action: Happy to fix both (for the reasons given). However, plea= se read my reply to [F] below, I believe the rules actually allow PT =3D [0= |8] in a specific corner case (result is: MUST NOT->SHOULD NOT in your sugg= estion). \end {Reply to [E]} [F] Section 4.1: PT - The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profiles in use currently mandate binding the payload type dynamically for this payload format. Good start, but not sufficient - cite the "RTP profiles currently in use" a= nd I would expect those citations to be normative references. Would that be just RFC 3551 and RFC 4585 (both are already normative refere= nces), or are there more RTP profiles? \begin {Reply to [F]} I think that wording was suggested somewhere along the way, but I can't rem= ember who provided it. It is boilerplate on many RTP payload formats, but o= thers (such as recent RFC 7310) are as simple as " PT - A dynamic payload t= ype; MUST be used" (which appears to be incorrect use of the semicolon, but= I digress). In any event, major edits of the first paragraph of 4.1 were m= ade to include the possibility of G.711 not having PT =3D 0 or PT =3D8 for = exceptional cases (so not even static payload types can be automatically as= sumed). According to IANA (http://www.iana.org/assignments/rtp-parameters/rtp-param= eters.xhtml#rtp-parameters-2 ) and RFC 3551, the FINAL set of static payloa= d assignments is contained in Table 4 and 5 of RFC 3551. And, according to RFC 3551, the PT assigned (for a new codec not having a s= tatic type) chosen SHOULD first attempt to use a dynamic PT - but there are= exceptions cited (e.g., dynamic PT exhaustion). Even codecs that have a st= atic PT assigned MAY negotiate a different PT (e.g., a dynamic PT). And new= codecs (after exhaustion of dynamic and other types) MAY actually use a st= atic PT not presently in use (at least I recall someone stated so in a meet= ing). So it appears there are a lot of exception cases that preclude knowi= ng (with 100% certainty) any particular PT mapping. And, according to RFC 3551, dynamic payload types SHOULD NOT be used withou= t a well-defined mechanism to indicate the mapping - SDP or ITU-T H.323/H.2= 45 negotiation or other pre-arrangement are cited (e.g., PT defined within = a certain scope or administrative domain) - and a well-defined RTP payload = format (this draft). Thus, not much can be said about the assignment other than what was stated.= I could put (yet another) RFC 3551 reference in this paragraph but it woul= d provide no more guidance than already provided a few paragraphs earlier (= which references RFC 3551). At a minimum I think I should say that PT of 0 = and 8 SHOULD NOT be used for G.711.0. Re: "PTs currently in use". It is hard to differentiate the profiles "curre= ntly IANA registered" and those "currently in use". That is, what is the de= finition of "currently in use" when you don't have insight into the registe= red-but-not-in-use profiles (e.g., historic codecs). >>Proposed Action: I think we should both defer to the Payload WG chairs on= this - as they can be expected to know all the exceptions AND the present = state of verbiage that goes on "PT -" line of an IANA media registration co= ming from the Payload WG. Ali and Roni: Please suggest alternate text if yo= u desire, I will accommodate; otherwise I will leave it as is. \end {Reply to [F]} [G] Framing errors Section 4 generally assumes that the G.711.0 decoder gets handed frames gen= erated by the G.711.0 encoder and can't get disaligned. I'm not convinced = that this "just works" based on the text in the draft - major issue [B] is = a significant reason why, and explaining that should help. Some discussion should be added on why the G.711.0 decoder can't get disali= gned wrt frame boundaries this can't happen, or what the G.711.0 decoder wi= ll do when it discovers that it wasn't handed a complete G.711.0 frame. Fo= r example, this error case and how to deal with it are not covered by the a= lgorithm in Section 4.2.3. \begin {Reply to [G]} The actual buffer handling to/from G.711.0 encoding/decoding logic is prett= y straightforward so I really doubt that an encoder that has been exercised= sufficiently wouldn't pass the G.711.0 frame(s) to the RTP payload incorre= ctly or the converse. However, you are correct in that we should always specify what happens when= things don't work as expected. Thanks for the catch. Consistent with an "error condition catch" Richard Barnes made in 4.2.4 - w= e do have some information for when an encoder and/or decoder error resulte= d in an unexpected number of G.711 decoded symbols. Assuming ptime was signaled, we expect the number of G.711 decoded symbols = to equal what we expect from the ptime value at the receiver/decoder. If it= doesn't then "we SHOULD discard the packet". [Aside: We discussed the SHOULD vs MUST on the decoder, the SHOULD won. Thi= s is because a given system design might temporarily send a packet inconsis= tent with the ptime previously signaled but which is structurally correct (= has the correct decoded G.711). Such a system might not desire to discard s= uch a packet (as it might appear otherwise correct in the number of samples= decoded). However, lacking such a design the usual operational choice is t= o discard the packet. Thus a SHOULD.] For the encoder, the length of the G.711.0 RTP payload - excluding padding = - should never be greater than the number of input G.711 symbols plus the n= umber of G.711.0 frames (as a given G.711.0 frame can be no greater than on= e octet more than the number of source symbols). If the number of frames is= known to the RTP layer (it may not be) and this constraint is not met, the= source packet MUST be discarded. [Aside: We did NOT discuss the SHOULD vs MAY on the encoder. In my opinion,= the MUST is more appropriate - as if the condition is met, you KNOW someth= ing is wrong.] >>Proposed Action: Add two sentences similar to the above to the end of Sec= tion 4.2.2+ (proposed earlier new section on Encoding Process) and Section = 4.2.3 (Decoding Process). \end {Reply to [G]} -- Nits/editorial comments: Section 3.2: A6 Bounded expansion: Since attribute A2 above requires G.711.0 to be lossless for any payload, by definition there exists at least one potential G.711 payload which must be "uncompressible". The "by definition" statement assumes that every possible bit string is a v= alid G.711 input. If that is correct, it should be explicitly stated. \begin{nit} Yes, because Attribute A2 referenced within this sentence quoted says as mu= ch. Every value of a G.711 symbol (2^8) corresponds to a discrete value. There = is no restriction from a sample-to-sample(octet to next octet) basis assum= ed in the G.711 encoding (no "illegal transitions"). Lastly, some "DS0 chan= nels" assume that all the bits can be used for arbitrary digital data (so-c= alled ISDN 64kbps B-channel). Thus it is widely known that, by definition, = that if something is random and can take ANY value of ANY possible concaten= ation of octets that there is no-redundancy to be exploited in the concaten= ation for the purposes of deterministic compression for all possible inputs= - there must exist at least one combination payload that is not compressib= le. This is an assertion from the G.711.0 ITU-T document that anyone who cares = to verify can go to the ITU-T, look up G.711 and instantly know that all th= e values are "assigned" and there are no illegal transitions specified; thu= s there is no redundancy to be exploited. I hesitate to insult my readers b= y giving them any more detail than Attribute A2 says. >>Proposed Change: None needed. However if you really feel strongly on this= , I could agree to something like the following ... or anything of your cho= osing that reads better and is accurate. Let me know what you want. A6 Bounded expansion: Since attribute A2 above requires G.711.0 to be lossless for any payload (which could consist of any concatenat= ion of octets each octet spanning the entire space of 2^8 values), by = definition there exists at least one potential G.711 payload which must be "uncompressible". \end {nit} A8 Low Complexity: Less than 1.0 WMOPS average and low memory footprint (~5k octets RAM, ~5.7k octets ROM and ~3.6 basic operations) [ICASSP] [G.711.0]. Expand WMOPS on first use, and check for other acronyms that need to be exp= anded on first use. \begin{nit} Note: The references define what a WMOPS is. >>Recommended Action: Since this is the only use of WMOPS, I will expand it= there (Weighted Million Operations Per Second) and skip the abbreviation e= ntirely. RAM and ROM is the only other non-expansion. I trust that these don't quali= fy as "needed" as not even the ITU-T document expands these. >>Recommended Action: No change to RAM and ROM. It is a reasonable expectat= ion that anyone reading this document will know those two based on context. \end {nit} Section 3.3: Since the G.711.0 output frame is "self-describing", a G.711.0 decoder (process "B") can losslessly reproduce the original G.711 input frame with only the knowledge of which companding law was used (A-law or mu-law). "companding law"? The term "compression law" is used elsewhere in this dra= ft, including two paragraphs earlier in this section - I suggest using "com= pression law" consistently. \begin{nit} Good catch. The law both forms of that G.711 uses (mu or A) is that of an input-to-outp= ut compander (http://en.wikipedia.org/wiki/Companding ), where the output f= ormat is discretized. I will change the one use of "compression law" to "companding law" in its s= ingular use in Section 3.3 (due to G.711 being a companding, sample-based c= odec). \end {nit} Section 6: We note that something must be stored for any G.711.0 frames that not received at the receiving endpoint, no matter what the cause. "that not" -> "that are not" \begin{nit} Thanks. Will do. \end {nit} Section 6.2: An entire frame of value 0++ or 0-- is expected to be extraordinarily rare when the frame was in fact generated by a natural signal (on the order of one in 2^{ptime in samples, minus one}), as analog inputs such as speech and music are zero-mean and are typically acoustically coupled to digital sampling systems. This doesn't explain where the 2^{ptime in samples, minus one} order of mag= nitude estimation came from. What assumption(s) is(are) being made about r= andomness and distribution thereof in the analog input? It might be simpler to delete the parenthesized text. \begin{nit} Agreed. Consider the parenthetical deleted. \end {nit} Section 11: Congestion Control This section is mis-named, as it basically (correctly) says that there is n= othing useful that can be done in G.711.0 compression to respond to congest= ion. I would retitle this to "Congestion Considerations". \begin{nit} I would, but the requirements for new RTP payload formats say that there MU= ST be a section named "Congestion Control" in all newly approved RTP Payloa= d formats! You are, of course, correct - as the text in this section basically says th= ere is no explicitly way to regulate the bit-rate for the purposes of conge= stion control. \end {nit} Are there opportunities to respond to congestion elsewhere, e.g. dynamically change the sampling rate? If so, a sentence mentioning them wo= uld be good to add. \begin{nit} I know of no use of G.711 that changes the sampling frequency from the defa= ult - although that is allowed in the SDP (as G.711 is a sample-based codec= ). The 8000 samples per second is hard-coded in many voice implementations. Since the whole purpose of G.711.0 is to send G.711 lossly with lower band= width, the use of G.711.0 could be triggered by G.711 negotiated sessions l= ooking for a lower bandwidth solution. Although we could mention this (obvi= ous) fact, the guidelines for this section instruct me to discuss things th= at can be done with the "codec" this payload format describes for the purpo= ses of congestion control. This is yet another artifact that the new RTP gu= idelines did not anticipate the use of a lossless and stateless compression= technique being defined for RTP. We broke a lot of new ground here, thanks= for wading through it! >>Proposed Action: None. I would not have this section in the document exce= pt that the new rules for RTP Payload definitions mandate such a section ex= ist. \end {nit} idnits 2.13.01 didn't find anything to complain about ;-). --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- Most of these questions are N/A as this draft specifies a payload format fo= r RTP, so most of the operations and management concerns are wrt RTP and SD= P. A.1.3. Has the migration path been discussed? No, see major issue [D] above. A.1.4 Have the Requirements on other protocols and functional components been discussed? Only in part - major issues [C] and [D] call out shortcomings in the discus= sion of SDP interactions. A.1.8 Are there fault or threshold conditions that should be reported? Yes, the likelihood and consequences of framing problems at the G.711.0 dec= oder (decoder is handed octet strings that are not G.711.0 frames generated= by the encoder) should be discussed. Major issue [B] needs to be resolved= first, and then see minor issue [G]. A.2. Management Considerations I would expect that the media type registration (Section 5.1 of this draft)= results in this new G.711.0 media type being usable in any relevant manage= ment model and/or framework that has some notion of media type. A.3 Documentation By itself, this compressed payload format does not look like a likely sourc= e of significant operational impacts on the Internet. The shepherd's writeup indicates that an implementation exists. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Wed Oct 29 13:54:16 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D001A8A04; Wed, 29 Oct 2014 12:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vzNtlhculwo; Wed, 29 Oct 2014 12:38:02 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027AE1A89FC; Wed, 29 Oct 2014 12:38:01 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id s9TJbnV5008114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 15:37:50 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s9TJbnV5008114 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1414611470; bh=hN3uG8IJ+6I46EbQJwcQsJa2Ba8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=En7WKV4BrfM78/LSICc4pBOieDBe+IQdCFFmTBimfRlfqJD9Rb3zU09n/MVsZ9CbC G7KvTG2Vb8XOdvqG71qvN47TYIlu+bq3hQei+PIa2FRyHkgU891iv9GczRC4z9LnuD vlTX2/Nh6oRup/vFugmmi+2k9BVHDIC1y2QPLmaE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s9TJbnV5008114 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 29 Oct 2014 15:36:51 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id s9TJbV10018752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 15:37:31 -0400 Received: from MXHUB106.corp.emc.com (10.253.58.23) by mxhub06.corp.emc.com (128.222.70.203) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 29 Oct 2014 15:37:31 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.131]) by MXHUB106.corp.emc.com ([10.253.58.23]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 15:37:31 -0400 From: "Black, David" To: "Michael Ramalho (mramalho)" , "Paul E. Jones (paulej@packetizer.com)" , "harada.noboru@lab.ntt.co.jp" , "muthu.arul@gmail.com" , "lei.miao@huawei.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03 Thread-Index: Ac/uDvwDXYp5WfZlQayJ5JnEo1/RLQEnG7PQAD9+X/A= Date: Wed, 29 Oct 2014 19:37:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/payload/ucQOAO1BKAOrw047EfVIukV7Ul8 X-Mailman-Approved-At: Wed, 29 Oct 2014 13:54:14 -0700 Cc: "Black, David" , "ietf@ietf.org" , "payload@ietf.org" Subject: Re: [payload] Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2014 19:38:10 -0000 Michael, Thank you for the comprehensive response. I'll summarize things here, as opposed to adding to the extensive inline discussion. At a high level, this is progress, as I'm fine with the proposals for issues [A], [E], [G] and all the nits. That leaves major issues [B], [C] and [D], plus minor issue [F]. Minor issue [F] was intended solely as a request to add citations - it looks like a lot more was read into it beyond what I originally intended. --- Major Issues --- -- [A] Encoding algorithm The proposed action looks reasonable; I'll review the text when it appears. -- [B] G.711.0 Frame Format >> [B] The G.711.0 frame format is not specified here, making it very diffi= cult >> to figure out what's going on when G.711.0 frames are concatenated. A >> specific example is that the concept of a "prefix code" that occurs at t= he >> start of a G.711.0 frame is far too important to be hidden in step H5 of= the >> decoding algorithm in Section 4.2.3. > We welcome comments on how to improve this section, as it is complicated.= We > did attempt to describe only what is necessary for understanding. The problem is not located in 4.2.3 - I think that the G.711.0 frame format should have been explained earlier, e.g., so that the notion of "prefix cod= e" is not a surprise to the reader. Please add an overview of the frame format generated by the G.711.0 encoder, and assumed by the G.711.0 decoder (including the "prefix code") somewhere in section 3. -- [C] SDP ptime >> [C] The discussion of use of the SDP ptime parameter is spread out and >> imprecise (is SDP REQUIRED?, when is ptime REQUIRED, RECOMMENDED, or >> recommended? - it's not obvious). > >>Proposed Action: The discussion of ptime (and the channels parameter) i= n > this section is primarily for the purpose of a check. If it is any comfor= t, > that paragraph has had lots of input to it previously (so you responded t= o a > complicated issue). And since we have no need to describe "ptime issues" = or > session negotiation issues prior to this point (Section 4.2.4) in the doc= ument > AND ptime isn't a required negotiation parameter AND we put a forward > reference to Section 5.1 for "ptime" when SDP is used, I hesitate to men= tion > such an optional parameter here in Section 3. > >>Proposed action: No Change (the forward references are enough). That does not address the concern. The concern is "Text on ptime is spread out and imprecise" and in particular the implementation requirements are unclear.=20 The explanation below of why the text is spread out, imprecise and unclear will not help make the draft clearer to other readers, sorry :-). I'm not convinced that this aspect of the draft is interoperably implementable as currently written. >> [D] Backwards compatibility. >>=20 >> The problem here is that it's not clear that negotiation (e.g., via SDP)= is >> required. This sentence in Section 3.1 is a particular problem: >>=20 >> G.711.0, being both lossless and stateless, may also be employed as a >> lossless compression mechanism anywhere between end systems which >> have negotiated use of G.711. >>=20 >> That's definitely wrong. Use of G.711.0 when only G.711 has been negoti= ated >> will fail to interoperate correctly. > The passage you quote is in Section 3 which is "General Information and = Use > of ITU-T G.711.0 Codec) and is: 1) prior to ANY discussion of the use of > G.711.0 in RTP (or even packet networks), and 2) prior to any discussion = of > media negotiation when using RTP (e.g., SDP). Thus the context for this > sentence is at the codec bit stream (or packet payload) level of the ITU-= T > codec. It stands on its own and is definitely correct. If this draft were an ITU-T document or otherwise clearly identified as an IETF Annex to G.711.0, I could agree with that rationale. However ... ... this is an IETF document, therefore that statement applies to use of SD= P for negotiation as discussed elsewhere in the draft; as applied to SDP, tha= t statement is and will result in interoperability problems. There is also the broader concern of what sort of negotiation is required, which is also unclear in the current draft text. --- Minor Issues --- -- [E] PT values 0 and 8 =20 >> The only significant difference is that the >> payload type (PT) RTP header field will have a value corresponding to >> the dynamic payload type assigned to the flow. This is in contrast >> to most current uses of G.711 which typically use the static payload >> assignment of PT =3D 0 (PCMU) or PT =3D 8 (PCMA) [RFC3551] even thoug= h >> the negotiation and use of dynamic payload types is allowed for >> G.711. >>=20 >> I would change "will have" to "MUST have" and add the following sentence= : >>=20 >> The existing G.711 PT values of 0 and 8 MUST NOT be used for G.711.0 >> content. >>=20 >> I suspect that this is obvious to the authors, but it'll help a reader w= ho's >> not familiar with the importance of the difference between G.711 and G.7= 11.0 . > >>Proposed Action: Happy to fix both (for the reasons given). However, pl= ease > read my reply to [F] below, I believe the rules actually allow PT =3D [0|= 8] in a > specific corner case (result is: MUST NOT->SHOULD NOT in your suggestion)= . I understand the concern, but I would suggest an alternate text structure f= or clarity: The existing G.711 PT values of 0 and 8 MUST NOT be used for G.711.0 content except when ... followed by an explanation of the corner case. A general "SHOULD NOT" invi= tes use of those values in situations outside that corner case. -- [F] RTP profiles >> PT - The assignment of an RTP payload type for the format defined >> in this memo is outside the scope of this document. The RTP >> profiles in use currently mandate binding the payload type >> dynamically for this payload format. >>=20 >> Good start, but not sufficient - cite the "RTP profiles currently in use= " and >> I would expect those citations to be normative references. >>=20 >> Would that be just RFC 3551 and RFC 4585 (both are already normative >> references), or are there more RTP profiles? It looks like entirely too much may have been read into this concern. Rephrasing in the hope of resolving this one quickly: When I read " The RTP profiles in use currently mandate ...", I want to kno= w which RTP profiles those are. I think that's a reasonable request - please cite the RTP profiles that are the foundation for that statement or delete = the sentence. -- [G] Framing errors The proposed action looks reasonable; I'll review the text when it appears. --- Nits --- All of the proposed actions on the nits are fine with me. Thanks, --David > -----Original Message----- > From: Michael Ramalho (mramalho) [mailto:mramalho@cisco.com] > Sent: Wednesday, October 29, 2014 11:36 AM > To: Black, David; Paul E. Jones (paulej@packetizer.com); > harada.noboru@lab.ntt.co.jp; muthu.arul@gmail.com; lei.miao@huawei.com; > General Area Review Team (gen-art@ietf.org); ops-dir@ietf.org > Cc: ietf@ietf.org; payload@ietf.org > Subject: RE: Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03 >=20 > David, >=20 > The authors of the G.711.0 RTP Payload Draft thank you for the comments b= elow. > It is clear from the caliber of your comments that you spent a lot of tim= e on > this. >=20 > G.711.0 being a variable length stateless and lossless compression for G.= 711 > (a sampled-oriented encoding) causes a lot of confusion to those who > occasionally think of it as "a codec" instead of the lossless compression > mechanism it is. >=20 > Thus, this was a hard payload format to write due to some of the pre-conc= eived > notions of what G.711.0 is and an even harder one for someone to review (= as it > is not sample-based or fixed-length frame-based encoding that the authors= of > RFC 3550/3511 assumed/envisioned). >=20 > So, I really do thank you for the effort here, David. You must have drawn= the > short-straw. >=20 > My response to your comments/questions are made in-line below (my comment= s > with "\begin {Reply to [issue]}" and my proposed fixes within these are > highlighted with ">>"). >=20 > Regards, >=20 > Michael A. Ramalho, Ph.D. >=20 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Wednesday, October 22, 2014 11:44 AM > To: Michael Ramalho (mramalho); Paul E. Jones (paulej@packetizer.com); > harada.noboru@lab.ntt.co.jp; muthu.arul@gmail.com; lei.miao@huawei.com; > General Area Review Team (gen-art@ietf.org); ops-dir@ietf.org > Cc: ietf@ietf.org; payload@ietf.org; Black, David > Subject: Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03 >=20 > This is a combined Gen-ART and OPS-DIR review. Boilerplate for both foll= ows > ... >=20 > I am the assigned Gen-ART reviewer for this draft. For background on Gen-= ART, > please see the FAQ at: >=20 > . >=20 > Please resolve these comments along with any other Last Call comments you= may > receive. >=20 > I have reviewed this document as part of the Operational directorate's on= going > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the operational area > directors. > Document editors and WG chairs should treat these comments just like any = other > last call comments. >=20 > Document: draft-ietf-payload-g7110-03 > Reviewer: David Black > Review Date: October 22, 2014 > IETF LC End Date: October 27, 2014 > IESG Telechat date: October 30, 2014 >=20 > Summary: This draft is on the right track, but has open issues > described in the review. >=20 > Process note: This is the second draft that I've reviewed recently that h= as > been scheduled for an IESG telechat almost immediately following the end = of > IETF Last Call. The resulting overlap of IETF LC with IESG Evaluation ca= n > result in significant last-minute changes to the draft when issues are > discovered during IETF LC. >=20 > This draft describes an RTP payload format for carrying G.711.0 compresse= d > G.711 voice. The details of G.711.0 compression are left to the ITU-T G.= 711.0 > spec (which is fine), and this draft focuses on how to carry the compress= ed > results in RTP and conversion to/from uncompressed G.711 voice at the > communication endpoints. > I found a few major issues and a couple of minor ones, although a couple = of > the major issues depend on a meta-issue, - the intended relationship of t= his > draft be to the ITU-T G.711.0 spec. >=20 > In general, I expect IETF RFCs to be stand-alone documents that make sens= e on > their own, although one may need to read related documents to completely > understand what's going on. For this draft, I would expect the actual > compression/decompression algorithms to be left to the ITU-T spec, and th= is > draft to stand on its own in explaining how to deploy G.711.0 > compression/decompression with RTP. If that expectation is incorrect, an= d > this draft is effectively an RTP Annex to G.711.0 that must be read in co= ncert > with G.711.0, then the first two major issues below are not problems as t= hey > should be obvious in the G.711.0 spec, although the fact that this draft = is > effectively an Annex to G.711.0 should be stated. Otherwise, those two m= ajor > issues need attention. >=20 > -- Major Issues (4): >=20 > [A] Section 4.2.3 specifies a detailed decoding algorithm covering how G.= 711.0 > decompression interacts with received RTP G.711.0 payloads. > A corresponding encoding algorithm specification is needed on the sending= side > for G.711.0 compression interaction with RTP sending. > The algorithm will have some decision points in it that cannot be fully > specified, e.g., time coverage of the generated G.711.0 frames. >=20 > \begin {Reply to [A]} >=20 > I believe you are correct. As with everything associated with G.711.0 , a > longer answer is required. >=20 > At the sender end, the G.711.0 encoder itself has decided exactly how it > desires to send compressed G.711.0. As an example outlined earlier in Sec= tion > 3.3.1 (Multiple G.711.0 Output Frame per RTP Payload Considerations), a g= iven > G.711.0 encoder could choose to encode 20ms of input G.711 symbols as: 1)= a > single 20ms G.711.0 frame, or 2) as two 10 ms G.711.0 frames, or 3) any > combination of 5 ms or 10 ms G.711.0 frames. The decision criteria is NOT > SPECIFIED in the ITU-T G.711.0 standard; a G.711.0 encoder could choose = base > on: 1) which encoding produced resulted in fewer bits, 2) simple operatio= n > such as always using 20 ms G.711.0 frames, or 3) any other criteria of it= s > choosing. Thus the encoding process is NOT DETERMINISTIC in how many G.71= 1.0 > frames could represent a given ptime of G.711 symbols. >=20 > [Aside: Using a 20 ms ptime example, there could be 1, 2, 3 or 4 G.711.0 > frames in a RTP payload in any one of six combinations in a G.711.0 paylo= ad > ([20ms],[ 10ms:10ms],[10ms:5ms:5ms], [5ms:10ms:5ms], > [5ms:5ms:10ms],[5ms:5ms:5ms:5ms]).] >=20 > Thus, it is important to note that the >>G.711.0 STANDARD<< only specifie= s the > encoding of an individual input G.711 frame (which can only have lengths = of > 40, 80, 160, 240 or 320 G.711 symbols) to a valid G.711.0 frame. >=20 > The authors of this draft assumed that the G.711.0 compressor/encoder pro= vider > has already made the encoding decision on the number of G.711.0 frames > INDEPENDENT of the decompressor/decoder and OUTSIDE any sender-side RTP > payload processing. That is, the G.711.0 encoder just passed the result (= any > of the combinations above) the compressor/encoder made to the G.711.0 RTP > layer at the sender to be incorporated into the G.711.0 payload. The RTP = layer > could then choose to add padding octets (0x00) to form the final G.711.0 > payload. >=20 > From that perspective, the co-authors of the draft believed what was impo= rtant > for the draft was "what could be on-the-wire". However, since the ITU-T > G.711.0 standard only specifies the individual G.711 frame to G.711.0 map= ping, > there is a benefit in explicitly calling out the possible "payload encodi= ng > process" in this section (4) as well. >=20 > >>Proposed Action: If my co-authors agree, I could write a very small sec= tion > titled "G.711.0 RTP Payload Encoding Process" (inserted in-between the pr= esent > 4.2.2 and 4.2.3). This paragraph-long section will reverse reference Sect= ion > 3.3.1 and remind the implementer that they can - at their option - chose = to > use any of the allowable encoding possibilities described in it. I think = David > is correct, we assumed that some entity PURPOSELY NOT defined by the G.71= 1.0 > standard (the provider of the "G.711.0 compressor/encoder") already made = those > decisions and that explicit definition of that decision is not specified > anywhere in any SDO document (so why not here?). Indeed, any "standard G.= 711.0 > encoder" offered by a vendor would likely have that functionality within = it > (so a RTP implementer wouldn't need to know it either). I could also remi= nd > the reader that one could use a single G.711.0 frame per ptime (if a G.71= 1.0 > frame supported that ptime) for the least complicated encoding case. Woul= d > that work David? Would that work co-authors? >=20 > \end {Reply to [A]} >=20 > [B] The G.711.0 frame format is not specified here, making it very diffic= ult > to figure out what's going on when G.711.0 frames are concatenated. A > specific example is that the concept of a "prefix code" that occurs at th= e > start of a G.711.0 frame is far too important to be hidden in step H5 of = the > decoding algorithm in Section 4.2.3. >=20 > \begin {Reply to [B]} >=20 > We welcome comments on how to improve this section, as it is complicated.= We > did attempt to describe only what is necessary for understanding. >=20 > At the beginning of Section 4.2.3 we IMMEDIATELY reference the ITU-T G.71= 1.0 > document - as it is that document that describes how to "decode a G.711.0= bit- > stream". We really want the reader needing to know the details to go ther= e > first. Indeed, the entire G.711.0 payload could be provided to the G.711.= 0 bit > stream decoder in the ITU-T G.711.0 reference code and obtain all the > uncompressed G.711 samples in the RTP payload and be finished without kno= wing > anything in this section. >=20 > The bit-stream decoder in the ITU-T reference code was defined to parse t= he > individual compressed G.711.0 frames. However the G.711.0 >>STANDARD ITSE= LF<< > defines only the mapping between the 40, 80, 160, 240 or 320 G.711 symbol= s > presented to it and the G.711.0 frame produced from those 40, 80, 160, 24= 0 or > 320 samples (i.e., only Section 3.3). >=20 > In other words, someone designing a G.711.0 encoder could choose how to > partition the uncompressed G.711 symbols into groups of 40, 80, 160, 240 = or > 320 samples and then individually encode them into individual G.711.0 fra= mes > as per my reply to [A]. >=20 > Any arbitrary value corresponding to a valid "G.711.0 prefix code" is NOT > unique (or otherwise special) in that it can be appear anywhere within a > G.711.0 frame; however a given value for a prefix code DOES have a unique > meaning >>TO THE G.711.0 DECODER<< (not the RTP machinery) when it is pre= sent > at the beginning of a G.711.0 frame. >=20 > The mention of the prefix code (with immediate reference back to the ITU= -T > specification I might add) was simply side information conveyed to the re= ader > for purposes of understanding. The G.711.0 decoder actually "reads it" an= d > then uses it to know how many source G.711 to produce (in this case exact= ly M > G.711 samples). The only thing the G.711.0 RTP implementer needs to know = is > that the G.711 sample buffer returned by the G.711.0 decoder will contain > exactly M samples of G.711. >=20 > To be precise, the ITU-T specified G.711.0 decoder returns not only the > samples themselves, but the number of samples, M upon its exit (we were n= ot > 100% clear on this - fix proposed below). The value of M is important to = the > RTP decoding process; the value, structure or meaning of "prefix code" is= n't. > The only exception is that 0x00 has a special meaning when it appears whe= re a > prefix code might otherwise be expected. >=20 > To accommodate padding, 0x00 may be placed anywhere between the encoded > G.711.0 frames (we only recommend that any desired padding be placed at t= he > end of the RTP payload). But to convey this "0x00" for padding, we needed= to > describe that 0x00 could not be a valid prefix code. If it were not for t= he > desire for padding, we would not have even mentioned that a "prefix code" > existed in a G.711.0 frame. >=20 > In the text we mention that a "0x00" where a prefix code is expected in a > G.711.0 bit stream is "silently ignored" by a G.711.0 frame decoder. >=20 > The mention of the prefix code was only for general information of what t= he > G.711.0 decoder actually does (generally how it decodes the frame and tha= t > "0x00" isn't a valid prefix code) and what is expected by the RTP machine= ry > when the G.711.0 decoder is finished decoding (the value of M and the M > individual G.711 symbols). >=20 > Summary: The interested reader desiring knowledge of how to decode a G.7= 11.0 > bit stream should really read the ITU-T document first; that is why we pu= t the > reference to the "ITU-T G.711.0 Reference code" as the FIRST sentence in > Section 4.2.3. They don't need to know what a "prefix code" is other than= it > is used by the G.711.0 decoder to know how many samples (M) it will produ= ce > and that the value of M will be returned by the G.711.0 decoder. >=20 > >>Proposed Action: I would suggest the following change in H5 to make thi= s > clearer: > From: The G.711.0 decoder will produce exactly M G.711 source symbols. > To: Then the ITU-T specified G.711.0 decoder will produce exactly M G.711 > source symbols and return both the symbols (in a buffer up to 321 octets = in > length if the in-place ITU-T reference code is used) and the value of M u= pon > exit. >=20 > That information - the samples and the value of M - is the only thing the > reader needs to know. >=20 > Does that work for you, David? >=20 > \end {Reply to [B]} >=20 > [C] The discussion of use of the SDP ptime parameter is spread out and > imprecise (is SDP REQUIRED?, when is ptime REQUIRED, RECOMMENDED, or > recommended? - it's not obvious). >=20 > A specific example is that this sentence in Section 4.2.4 is an invitatio= n to > interoperability problems ("could infer" - how is that done and where do = the > inputs to that inference come from?): >=20 > Similarly, if the number of > channels was not known, but the payload "ptime" was known, one could > infer (knowing the sampling rate) how many G.711 symbols each channel > contained; then with this knowledge determine how many channels of > data were contained in the payload. >=20 > I would suggest that a subsection be added, possibly at the end of Sectio= n 3, > to gather/summarize all of the relevant ptime discussion in one place. I > suspect that the contents of this draft are mostly correct wrt ptime, but= it's > hard to figure out what's going on from the current spread-out text. It = looks > like "ptime" could provide a cross-check on correctness of G.711.0 decodi= ng - > see minor issue [G] below. >=20 > This major issue [C] is independent of the relationship between this draf= t and > the G.711.0 spec. >=20 > \begin {Reply to [C]} >=20 > We underspecified the use of SDP on purpose, but I also agree that some = text > on why we wish to leave it underspecified could be useful. In Section 5 w= e > simply say "parameters that may be used to configure [G.711.0 RTP > transmission]". Perhaps the MAY should be capitalized? Or more text? >=20 > As you know and appreciate, one could put an arbitrary number of G.711.0 > frames in a G.711.0 RTP payload and the decoder really won't know how man= y > G.711 samples were compressed in that payload until it decodes the entire > payload. >=20 > Point A: For systems that use SDP and have specified a ptime (IANA > registration for ptime is as an OPTIONAL parameter per WG agreement), a c= heck > can be performed to see if the required number of G.711 samples is presen= t. >=20 > Point B: For systems that use SDP and have not specified ptime - the payl= oad > can still be decoded. In this case there is no a priori expectation on th= e > number of G.711 symbols contained within the G.711.0 RTP payload and thus= no > check is possible. >=20 > Point C: For systems that use SDP we RECOMMEND that ptime SHOULD be used = (see > IANA registration text). The reason is that such a check can be made! >=20 > All three points (A, B & C) have been agreed to during previous > meetings/discussions. >=20 > However, some USERS of the G.711.0 payload format may wish to use the RTP > format itself but NOT use SDP! A good example is a "in-the-middle" compre= ssion > of a G.711 flow (into a G.711.0 flow) and a corresponding decompression o= f the > G.711.0 flow back into a G.711 flow. This is possible in many network > arrangements (e.g., enterprise to enterprise) where the compression and > decompression endpoints know the PT corresponding to G.711.0 use within t= heir > administrative domain. >=20 > [Aside: At one time this RTP Payload format had both the payload definiti= on > (this draft) and G.711.0-specific use cases within it. Previous WG discus= sion > supported the splitting out of the use-cases into a separate draft (a "G.= 711.0 > use case" draft). I have such an expired draft, but we agreed to defer wo= rk on > it until after the RTP payload format was complete. Thus some elements of= uses > outside of G.711.0 running in the endpoints would be described in the oth= er > use-case draft.] >=20 > The SDP discussion is a little wordy, but this is a result of G.711.0 not > being a codec, but rather a variable length, frame-based lossless > compression/decompression. That is G.711.0 is NOT a (sample-based or fram= e- > based) codec in the usual sense that RFC 3550/3551 anticipated, but does > require some "G.711 specific" information to be passed to it (e.g., compl= aw). >=20 > For the passage you quoted above, the FOLLOWING TWO SENTENCES in the draf= t > provide a forward reference in the document to when the "channels" and "p= time" > parameters are needed and referenced (Section 5.1); because we have had n= o > need prior to that point in the draft to discuss use of ANY particular se= ssion > negotiation protocol. >=20 > SDP is a dominant IETF protocol for media negotiation; but even RFC 3551 > mentions H.245 and the fact that other mapping methods are possible (incl= uding > "no negotiation" methods). Indeed, the "in-the-middle" use case described= in > this email (and at earlier IETF Payload meetings) may or may not have any= a > priori negotiation of PT at all within an administrative domain (e.g., th= e > G.711.0 PT may be a network configured parameter specific to a company > network). >=20 > >>Proposed Action: The discussion of ptime (and the channels parameter) i= n > this section is primarily for the purpose of a check. If it is any comfor= t, > that paragraph has had lots of input to it previously (so you responded t= o a > complicated issue). And since we have no need to describe "ptime issues" = or > session negotiation issues prior to this point (Section 4.2.4) in the doc= ument > AND ptime isn't a required negotiation parameter AND we put a forward > reference to Section 5.1 for "ptime" when SDP is used, I hesitate to men= tion > such an optional parameter here in Section 3. > >>Proposed action: No Change (the forward references are enough). >=20 > \end {Reply to [C]} >=20 > [D] Backwards compatibility. >=20 > The problem here is that it's not clear that negotiation (e.g., via SDP) = is > required. This sentence in Section 3.1 is a particular problem: >=20 > G.711.0, being both lossless and stateless, may also be employed as a > lossless compression mechanism anywhere between end systems which > have negotiated use of G.711. >=20 > That's definitely wrong. Use of G.711.0 when only G.711 has been negotia= ted > will fail to interoperate correctly. >=20 > A subsection of section 3 on negotiation and SDP usage would help here. >=20 > This major issue [D] is independent of the relationship between this draf= t and > the G.711.0 spec. >=20 > \begin {Reply to [D]} >=20 > The passage you quote is in Section 3 which is "General Information and = Use > of ITU-T G.711.0 Codec) and is: 1) prior to ANY discussion of the use of > G.711.0 in RTP (or even packet networks), and 2) prior to any discussion = of > media negotiation when using RTP (e.g., SDP). Thus the context for this > sentence is at the codec bit stream (or packet payload) level of the ITU-= T > codec. It stands on its own and is definitely correct. >=20 > When the compression of a G.711 payload to a G.711.0 payload occurs somew= here > on the end-to-end path and the corresponding decompression from a G.711.0 > payload to a G.711 payload occurs prior to the receiving endpoint the > receiving endpoint doesn't know the (lossless) compression occurred on th= e > PAYLOAD (the context in this section). As mentioned previously, this is > possible in many arrangements (in RTP) where the compression and decompre= ssion > endpoints know the PT corresponding to G.711.0 use within their administr= ative > domain (a reserved or not-used-in-their-domain PT) and desire to do this. >=20 > That is the beauty of lossless compression - the receiving endpoint doesn= 't > know (or need to know) that payload compression occurred. To imply otherw= ise > is to dismiss lossless compression (e.g., CRTP, ECRTP, ROHC) that lossles= sly > compress and decompress arbitrary parts of packets (in the case of > CRTP/ECRTP/RHOC, the headers) in between the endpoints without the endpoi= nts > explicit knowledge of the compression. >=20 > Please note that this property isn't possible with lossy *CODECS*, as the > transcode will typically introduce some distortion which would be unknown= to > the receiving endpoint but nevertheless present. This is one of the many > subtleties that people reading about G.711.0 have when considering it as = if it > were a (lossy) codec - they ASSUME that G.711.0 is a TRANSCODE and not th= e > lossless, STATELESS compression of the MEDIA PAYLOAD that it is. >=20 > Again, we had working group agreement (I think in Quebec) that a use-case > document could follow this G.711.0 RTP payload format document to describ= e how > to do the mapping in RTP for these "compression-in-the-middle" cases. Hig= h > level summary is that you copy the G.711 RTP header verbatim into the G.7= 11.0 > RTP header except for the PT. I have a draft on the use case document whi= ch I > let expire until this RTP payload definition is finished. >=20 > >>Proposed Action: No Change. We have more than enough words in the docum= ent > to describe all the attributes of G.711.0 (Section 3.2) in this section o= f the > document that discusses properties of the >>ITU-T specification<<. >=20 > \end {Reply to [D]} >=20 > -- Minor issues (3): >=20 > [E] Section 4.1: >=20 > The only significant difference is that the > payload type (PT) RTP header field will have a value corresponding to > the dynamic payload type assigned to the flow. This is in contrast > to most current uses of G.711 which typically use the static payload > assignment of PT =3D 0 (PCMU) or PT =3D 8 (PCMA) [RFC3551] even though > the negotiation and use of dynamic payload types is allowed for > G.711. >=20 > I would change "will have" to "MUST have" and add the following sentence: >=20 > The existing G.711 PT values of 0 and 8 MUST NOT be used for G.711.0 > content. >=20 > I'm suspect that this is obvious to the authors, but it'll help a reader = who's > not familiar with the importance of the difference between G.711 and G.71= 1.0 . >=20 > \begin {Reply to [E]} >=20 > >>Proposed Action: Happy to fix both (for the reasons given). However, pl= ease > read my reply to [F] below, I believe the rules actually allow PT =3D [0|= 8] in a > specific corner case (result is: MUST NOT->SHOULD NOT in your suggestion)= . >=20 > \end {Reply to [E]} >=20 > [F] Section 4.1: >=20 > PT - The assignment of an RTP payload type for the format defined > in this memo is outside the scope of this document. The RTP > profiles in use currently mandate binding the payload type > dynamically for this payload format. >=20 > Good start, but not sufficient - cite the "RTP profiles currently in use"= and > I would expect those citations to be normative references. >=20 > Would that be just RFC 3551 and RFC 4585 (both are already normative > references), or are there more RTP profiles? >=20 > \begin {Reply to [F]} >=20 > I think that wording was suggested somewhere along the way, but I can't > remember who provided it. It is boilerplate on many RTP payload formats, = but > others (such as recent RFC 7310) are as simple as " PT - A dynamic payloa= d > type; MUST be used" (which appears to be incorrect use of the semicolon, = but I > digress). In any event, major edits of the first paragraph of 4.1 were ma= de to > include the possibility of G.711 not having PT =3D 0 or PT =3D8 for excep= tional > cases (so not even static payload types can be automatically assumed). >=20 > According to IANA (http://www.iana.org/assignments/rtp-parameters/rtp- > parameters.xhtml#rtp-parameters-2 ) and RFC 3551, the FINAL set of static > payload assignments is contained in Table 4 and 5 of RFC 3551. >=20 > And, according to RFC 3551, the PT assigned (for a new codec not having a > static type) chosen SHOULD first attempt to use a dynamic PT - but there = are > exceptions cited (e.g., dynamic PT exhaustion). Even codecs that have a s= tatic > PT assigned MAY negotiate a different PT (e.g., a dynamic PT). And new co= decs > (after exhaustion of dynamic and other types) MAY actually use a static P= T not > presently in use (at least I recall someone stated so in a meeting). So = it > appears there are a lot of exception cases that preclude knowing (with 10= 0% > certainty) any particular PT mapping. >=20 > And, according to RFC 3551, dynamic payload types SHOULD NOT be used with= out a > well-defined mechanism to indicate the mapping - SDP or ITU-T H.323/H.245 > negotiation or other pre-arrangement are cited (e.g., PT defined within a > certain scope or administrative domain) - and a well-defined RTP payload > format (this draft). >=20 > Thus, not much can be said about the assignment other than what was state= d. I > could put (yet another) RFC 3551 reference in this paragraph but it would > provide no more guidance than already provided a few paragraphs earlier (= which > references RFC 3551). At a minimum I think I should say that PT of 0 and = 8 > SHOULD NOT be used for G.711.0. >=20 > Re: "PTs currently in use". It is hard to differentiate the profiles > "currently IANA registered" and those "currently in use". That is, what i= s the > definition of "currently in use" when you don't have insight into the > registered-but-not-in-use profiles (e.g., historic codecs). >=20 > >>Proposed Action: I think we should both defer to the Payload WG chairs = on > this - as they can be expected to know all the exceptions AND the present > state of verbiage that goes on "PT -" line of an IANA media registration > coming from the Payload WG. Ali and Roni: Please suggest alternate text i= f you > desire, I will accommodate; otherwise I will leave it as is. >=20 > \end {Reply to [F]} >=20 > [G] Framing errors >=20 > Section 4 generally assumes that the G.711.0 decoder gets handed frames > generated by the G.711.0 encoder and can't get disaligned. I'm not convi= nced > that this "just works" based on the text in the draft - major issue [B] i= s a > significant reason why, and explaining that should help. >=20 > Some discussion should be added on why the G.711.0 decoder can't get > disaligned wrt frame boundaries this can't happen, or what the G.711.0 de= coder > will do when it discovers that it wasn't handed a complete G.711.0 frame.= For > example, this error case and how to deal with it are not covered by the > algorithm in Section 4.2.3. >=20 > \begin {Reply to [G]} >=20 > The actual buffer handling to/from G.711.0 encoding/decoding logic is pre= tty > straightforward so I really doubt that an encoder that has been exercised > sufficiently wouldn't pass the G.711.0 frame(s) to the RTP payload incorr= ectly > or the converse. >=20 > However, you are correct in that we should always specify what happens wh= en > things don't work as expected. Thanks for the catch. >=20 > Consistent with an "error condition catch" Richard Barnes made in 4.2.4 -= we > do have some information for when an encoder and/or decoder error resulte= d in > an unexpected number of G.711 decoded symbols. >=20 > Assuming ptime was signaled, we expect the number of G.711 decoded symbol= s to > equal what we expect from the ptime value at the receiver/decoder. If it > doesn't then "we SHOULD discard the packet". >=20 > [Aside: We discussed the SHOULD vs MUST on the decoder, the SHOULD won. T= his > is because a given system design might temporarily send a packet inconsis= tent > with the ptime previously signaled but which is structurally correct (has= the > correct decoded G.711). Such a system might not desire to discard such a > packet (as it might appear otherwise correct in the number of samples > decoded). However, lacking such a design the usual operational choice is = to > discard the packet. Thus a SHOULD.] >=20 > For the encoder, the length of the G.711.0 RTP payload - excluding paddin= g - > should never be greater than the number of input G.711 symbols plus the n= umber > of G.711.0 frames (as a given G.711.0 frame can be no greater than one oc= tet > more than the number of source symbols). If the number of frames is known= to > the RTP layer (it may not be) and this constraint is not met, the source > packet MUST be discarded. >=20 > [Aside: We did NOT discuss the SHOULD vs MAY on the encoder. In my opinio= n, > the MUST is more appropriate - as if the condition is met, you KNOW somet= hing > is wrong.] >=20 > >>Proposed Action: Add two sentences similar to the above to the end of > Section 4.2.2+ (proposed earlier new section on Encoding Process) and Sec= tion > 4.2.3 (Decoding Process). >=20 > \end {Reply to [G]} >=20 > -- Nits/editorial comments: >=20 > Section 3.2: >=20 > A6 Bounded expansion: Since attribute A2 above requires G.711.0 to > be lossless for any payload, by definition there exists at > least one potential G.711 payload which must be > "uncompressible". >=20 > The "by definition" statement assumes that every possible bit string is a > valid G.711 input. If that is correct, it should be explicitly stated. >=20 > \begin{nit} >=20 > Yes, because Attribute A2 referenced within this sentence quoted says as = much. >=20 > Every value of a G.711 symbol (2^8) corresponds to a discrete value. Ther= e is > no restriction from a sample-to-sample(octet to next octet) basis assume= d in > the G.711 encoding (no "illegal transitions"). Lastly, some "DS0 channels= " > assume that all the bits can be used for arbitrary digital data (so-calle= d > ISDN 64kbps B-channel). Thus it is widely known that, by definition, that= if > something is random and can take ANY value of ANY possible concatenation = of > octets that there is no-redundancy to be exploited in the concatenation f= or > the purposes of deterministic compression for all possible inputs - there= must > exist at least one combination payload that is not compressible. >=20 > This is an assertion from the G.711.0 ITU-T document that anyone who care= s to > verify can go to the ITU-T, look up G.711 and instantly know that all the > values are "assigned" and there are no illegal transitions specified; thu= s > there is no redundancy to be exploited. I hesitate to insult my readers b= y > giving them any more detail than Attribute A2 says. >=20 > >>Proposed Change: None needed. However if you really feel strongly on th= is, I > could agree to something like the following ... or anything of your choos= ing > that reads better and is accurate. Let me know what you want. >=20 > A6 Bounded expansion: Since attribute A2 above requires G.711.0 to > be lossless for any payload (which could consist of any concaten= ation > of octets each octet spanning the entire space of 2^8 values), b= y > definition > there exists at least one potential G.711 payload which must be > "uncompressible". >=20 > \end {nit} >=20 > A8 Low Complexity: Less than 1.0 WMOPS average and low memory > footprint (~5k octets RAM, ~5.7k octets ROM and ~3.6 basic > operations) [ICASSP] [G.711.0]. >=20 > Expand WMOPS on first use, and check for other acronyms that need to be > expanded on first use. >=20 > \begin{nit} >=20 > Note: The references define what a WMOPS is. >=20 > >>Recommended Action: Since this is the only use of WMOPS, I will expand = it > there (Weighted Million Operations Per Second) and skip the abbreviation > entirely. >=20 > RAM and ROM is the only other non-expansion. I trust that these don't qua= lify > as "needed" as not even the ITU-T document expands these. >=20 > >>Recommended Action: No change to RAM and ROM. It is a reasonable expect= ation > that anyone reading this document will know those two based on context. >=20 > \end {nit} >=20 > Section 3.3: >=20 > Since the G.711.0 output frame is "self-describing", a G.711.0 > decoder (process "B") can losslessly reproduce the original G.711 > input frame with only the knowledge of which companding law was used > (A-law or mu-law). >=20 > "companding law"? The term "compression law" is used elsewhere in this d= raft, > including two paragraphs earlier in this section - I suggest using > "compression law" consistently. >=20 > \begin{nit} >=20 > Good catch. >=20 > The law both forms of that G.711 uses (mu or A) is that of an input-to-ou= tput > compander (http://en.wikipedia.org/wiki/Companding ), where the output fo= rmat > is discretized. >=20 > I will change the one use of "compression law" to "companding law" in its > singular use in Section 3.3 (due to G.711 being a companding, sample-base= d > codec). >=20 > \end {nit} >=20 > Section 6: >=20 > We note that something must be stored for any G.711.0 frames that not > received at the receiving endpoint, no matter what the cause. >=20 > "that not" -> "that are not" >=20 > \begin{nit} > Thanks. Will do. > \end {nit} >=20 > Section 6.2: >=20 > An entire frame of value 0++ or 0-- is expected to be > extraordinarily rare when the frame was in fact generated by a > natural signal (on the order of one in 2^{ptime in samples, minus > one}), as analog inputs such as speech and music are zero-mean and > are typically acoustically coupled to digital sampling systems. >=20 > This doesn't explain where the 2^{ptime in samples, minus one} order of > magnitude estimation came from. What assumption(s) is(are) being made ab= out > randomness and distribution thereof in the analog input? > It might be simpler to delete the parenthesized text. >=20 > \begin{nit} > Agreed. Consider the parenthetical deleted. > \end {nit} >=20 > Section 11: Congestion Control >=20 > This section is mis-named, as it basically (correctly) says that there is > nothing useful that can be done in G.711.0 compression to respond to > congestion. I would retitle this to "Congestion Considerations". >=20 > \begin{nit} > I would, but the requirements for new RTP payload formats say that there = MUST > be a section named "Congestion Control" in all newly approved RTP Payload > formats! >=20 > You are, of course, correct - as the text in this section basically says = there > is no explicitly way to regulate the bit-rate for the purposes of congest= ion > control. > \end {nit} >=20 > Are there opportunities to respond to congestion elsewhere, e.g. > dynamically change the sampling rate? If so, a sentence mentioning them = would > be good to add. >=20 > \begin{nit} > I know of no use of G.711 that changes the sampling frequency from the de= fault > - although that is allowed in the SDP (as G.711 is a sample-based codec).= The > 8000 samples per second is hard-coded in many voice implementations. >=20 > Since the whole purpose of G.711.0 is to send G.711 lossly with lower > bandwidth, the use of G.711.0 could be triggered by G.711 negotiated sess= ions > looking for a lower bandwidth solution. Although we could mention this > (obvious) fact, the guidelines for this section instruct me to discuss th= ings > that can be done with the "codec" this payload format describes for the > purposes of congestion control. This is yet another artifact that the new= RTP > guidelines did not anticipate the use of a lossless and stateless compres= sion > technique being defined for RTP. We broke a lot of new ground here, thank= s for > wading through it! >=20 > >>Proposed Action: None. I would not have this section in the document ex= cept > that the new rules for RTP Payload definitions mandate such a section exi= st. > \end {nit} >=20 > idnits 2.13.01 didn't find anything to complain about ;-). >=20 > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- >=20 > Most of these questions are N/A as this draft specifies a payload format = for > RTP, so most of the operations and management concerns are wrt RTP and SD= P. >=20 > A.1.3. Has the migration path been discussed? >=20 > No, see major issue [D] above. >=20 > A.1.4 Have the Requirements on other protocols and functional > components been discussed? >=20 > Only in part - major issues [C] and [D] call out shortcomings in the > discussion of SDP interactions. >=20 > A.1.8 Are there fault or threshold conditions that should be reported? >=20 > Yes, the likelihood and consequences of framing problems at the G.711.0 > decoder (decoder is handed octet strings that are not G.711.0 frames gene= rated > by the encoder) should be discussed. Major issue [B] needs to be resolve= d > first, and then see minor issue [G]. >=20 > A.2. Management Considerations >=20 > I would expect that the media type registration (Section 5.1 of this draf= t) > results in this new G.711.0 media type being usable in any relevant manag= ement > model and/or framework that has some notion of media type. >=20 > A.3 Documentation >=20 > By itself, this compressed payload format does not look like a likely sou= rce > of significant operational impacts on the Internet. >=20 > The shepherd's writeup indicates that an implementation exists. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ----------------------------------------------------