From nobody Mon Nov 3 10:37:21 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 C25EF1A1BA4 for ; Mon, 3 Nov 2014 10:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.594] 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 rdXYD01hG9ya for ; Mon, 3 Nov 2014 10:37:14 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 042411A3BA5 for ; Mon, 3 Nov 2014 10:37:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id AC0307C508E for ; Mon, 3 Nov 2014 19:37:12 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t0um37t1d7T for ; Mon, 3 Nov 2014 19:37:10 +0100 (CET) Received: from [IPv6:2620:0:1000:167d:6812:cbc2:7be6:f60] (unknown [IPv6:2620:0:1000:167d:6812:cbc2:7be6:f60]) by mork.alvestrand.no (Postfix) with ESMTPSA id ED9F77C508D for ; Mon, 3 Nov 2014 19:37:09 +0100 (CET) Message-ID: <5457CB53.1080805@alvestrand.no> Date: Mon, 03 Nov 2014 10:37:07 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: payload@ietf.org References: <013301cf9a71$2f863420$8e929c60$@gmail.com> <39731C83-C883-4E7A-9F0F-C007C7B9AD0E@live555.com> In-Reply-To: <39731C83-C883-4E7A-9F0F-C007C7B9AD0E@live555.com> Content-Type: multipart/alternative; boundary="------------020604090100010302080201" Archived-At: http://mailarchive.ietf.org/arch/msg/payload/8d0Rkbjyv_45XUEUDRFMdG1yALc 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: Mon, 03 Nov 2014 18:37:18 -0000 This is a multi-part message in MIME format. --------------020604090100010302080201 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 10/27/2014 11:56 PM, Ross Finlayson wrote: >> On Jul 7, 2014, at 10:55 PM, Roni Even > > wrote: >> >> Hi, >> I reviewed the document and have some comments as individual > […] >> 6. In section 6.2.2 what is the meaning of max-fr and max-fs if the >> stream >> is sendonly? > > Ditto if a ‘declarative’ SDP description is generated for a stream - > e.g., for RTSP? > > Section 6.2.1 "Mapping of Media Subtype Parameters to SDP” of the > latest VP8 payload format draft ("draft-ietf-payload-vp8-13”) says > The parameters "max-fs", and "max-fr", MUST be included in the > "a=fmtp" line of SDP > I think this is too strong. IMHO it should be a MUST only if the SDP > is used in an ‘offer-answer’ environment, and the stream is not > ‘sendonly’ (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” > Thanks, this fix seems reasonable: - MUST be included if the SDP is used to declare receiver capabilities I don't want to get into the quagmire of describing all the situations where it is (or isn't) used in that way. I'm unsure what we should do on sendonly; MUST NOT would be logical and consistent, but seems to complicate implementations that just want to hardcode their SDP strings to the extent possible. MAY, and say that the a=fmtp parameters are then those that would have been used if the stream had been receive-only? I'm sure we can get the same fix into VP9. This is not where we want to be creative :-) > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload -- Surveillance is pervasive. Go Dark. --------------020604090100010302080201 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/27/2014 11:56 PM, Ross Finlayson wrote:
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
[…]
6. In section 6.2.2 what is the meaning of max-fr and max-fs if the stream
is sendonly?

Ditto if a ‘declarative’ SDP description is generated for a stream - e.g., for RTSP?

Section 6.2.1 "Mapping of Media Subtype Parameters to SDP” of the latest VP8 payload format draft ("draft-ietf-payload-vp8-13”) says
The parameters "max-fs", and "max-fr", MUST be included in the "a=fmtp" line of SDP
I think this is too strong.  IMHO it should be a MUST only if the SDP is used in an ‘offer-answer’ environment, and the stream is not ‘sendonly’ (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”


Thanks, this fix seems reasonable:

- MUST be included if the SDP is used to declare receiver capabilities

I don't want to get into the quagmire of describing all the situations where it is (or isn't) used in that way.

I'm unsure what we should do on sendonly; MUST NOT would be logical and consistent, but seems to complicate implementations that just want to hardcode their SDP strings to the extent possible. MAY, and say that the a=fmtp parameters are then those that would have been used if the stream had been receive-only?

I'm sure we can get the same fix into VP9. This is not where we want to be creative :-)



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



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



-- 
Surveillance is pervasive. Go Dark.
--------------020604090100010302080201-- From nobody Wed Nov 5 13:28: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 1A8ED1ACDF6 for ; Wed, 5 Nov 2014 13:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 6qCW3Y5gEQEW for ; Wed, 5 Nov 2014 13:28:13 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265631A86FC for ; Wed, 5 Nov 2014 13:28:13 -0800 (PST) Received: from CY1PR0701MB1275.namprd07.prod.outlook.com (25.160.149.18) by CY1PR0701MB1371.namprd07.prod.outlook.com (25.160.150.15) with Microsoft SMTP Server (TLS) id 15.1.11.14; Wed, 5 Nov 2014 21:27:49 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1275.namprd07.prod.outlook.com (25.160.149.18) with Microsoft SMTP Server (TLS) id 15.1.11.14; Wed, 5 Nov 2014 21:27:46 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0011.000; Wed, 5 Nov 2014 21:27:47 +0000 From: Stephan Wenger To: Bernard Aboba , "payload@ietf.org" Thread-Topic: [payload] Problem with draft-ietf-payload-rtp-h265 Thread-Index: AQHP8wEWO0S8gKMNgECMAePo1vpI/pxSEoeA Date: Wed, 5 Nov 2014 21:27:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1275;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(243025005)(189002)(199003)(19617315012)(87936001)(64706001)(20776003)(106116001)(105586002)(230783001)(4396001)(21056001)(46102003)(107046002)(99286002)(99396003)(16236675004)(120916001)(106356001)(31966008)(107886001)(66066001)(77156002)(19625215002)(19580395003)(101416001)(36756003)(76176999)(54356999)(62966003)(15975445006)(15202345003)(95666004)(86362001)(2501002)(50986999)(97736003)(40100003)(92726001)(77096003)(122556002)(92566001)(2656002)(19580405001)(95434003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1275; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: multipart/alternative; boundary="_000_D07FD0854A951stewesteweorg_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1371; X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/payload/UoYwhUUAx5EPFeNe4ZRVFk38w6A Subject: Re: [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: Wed, 05 Nov 2014 21:28:17 -0000 --_000_D07FD0854A951stewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bernard, Sorry for the late reply. In London, we agreed that the signaling aspects of (what was then called) M= ST within one RTP session are out of scope for this payload format. See he= re: http://www.ietf.org/proceedings/89/slides/slides-89-payload-6.pdf (pres= entation in London) and here http://www.ietf.org/proceedings/89/minutes/min= utes-89-payload (minutes, including quote =93The conclusion was to take MST= support out of the document in order to finish the payload.=94). This was= confirmed on the mailing list (by lack of objection to notes and my email = requesting for objections) sometime in late April/early May of 2014. Unless we change this agreement, the support for bundle-like mechanisms is = out of scope for this draft. In this light, I propose to modify our draft as shown inline and marked [St= W]. These changes mostly soften previously overly tight language and clari= fy the scope. For the I-D authors, Stephan From: Bernard Aboba > Date: Tuesday, October 28, 2014 at 14:46 To: "payload@ietf.org" > Subject: [payload] Problem with draft-ietf-payload-rtp-h265 Just noticed a bunch of problems introduced into the draft by the use of th= e "Single Stream Mode" and "Multiple Stream Mode" terminology. Dependency of one RTP stream on another RTP stream is typically indicated as specified in [RFC5583]= . When an RTP stream A depends on another RTP stream B, the RTP stream B is referred to as a dependee RTP stream of the RTP stream A. [BA] The statement above is wrong. RFC 5583 dependency groups based on the use of a=3Dgroup:DDP and a=3Dmid: lines and therefore can only deal with dependencies between m-lines (multiple RTP sessions). If the RTP streams are sent within the same RTP session, the dependency cannot be indicated as= specified in RFC 5583. [StW] Bernard=92s statement is correct. However, we had an agreement in Lo= ndon that this I-D does not deal with the complexities resulting from strea= ms being sent in the same session (SSRC mutilplexing). We concluded at the= time that the generic problem of signaling things like dependencies will n= eed to be addressed by a generic signaling mechanism, applicable to all pay= load formats. Therefore, we propose to to clarify as follows: In some systems, the dDependency of one RTP stream on another RTP stream= is typicallycan be indicated as specified in [RFC5583]= . In the future, signaling mechanisms may become available that offer similar functionality also when multiple RTP stream are carried in= the same RTP session, where the [RFC5583] mechanism does not apply. Regardless of the signali= ng details, wWhen an RTP stream A depends on another RTP stream B, the RTP stream B is referred to as a dependee RTP stream of the RTP stream A. [/StW] Informative note: An MSM may involve one or more RTP sessions. Each RTP stream in an MSM may be in its own RTP session or a set of multiple RTP streams in an MSM may belong to the same RTP session, e.g. as indicated by the mechanism specified in the Internet-Draft [I-D.ietf-avtcore-rtp-multi-stream] or in [I-D.ietf-mmusic-sdp-bundle-negotiation].= This document is not addressing MSM scenarios in which multiple RTP streams are conveyed in the same RTP session (SSRC multiplexing). SSM SHOULD be used for point-to-point unicast scenarios, while MSM SHOULD be used for point-to-multipoint multicast scenarios where different receivers require different operation points of the same HEVC bitstream, to improve bandwidth utilizing efficiency. [BA] This is also wrong. While it was accurate that Multi-Session-Transport should be used for point-to-multipoint multicast scenarios, Single-Session-= Transport of multiple streams can be used in point-to-point unicast scenarios. [StW] I think Bernard is right, again. From a bandwidth viewpoint, the use= of SSM and MSM do not necessarily make a difference. It=92s the same numb= er of packets with the same packet overhead that are being sent. When RoHC= is in the picture, things may be different (SSRC cannot be compressed away= ), but do we really care about that scenario? I start wondering why we wro= te about the bandwidth thing (probably was me who wrote this, carelessly=85= ) I propose to remove the paragraph. The note can stay, with the amendment s= hown. [/StW] The transmission mode is indicated by the tx-mode media parameter (see section 7.1). If tx-mode is equal to "SSM", SSM MUST be used. Otherwise (tx-mode is equal to "MSM"), MSM MUST be used. [BA] This also does not make sense, because it will not allow for distingui= shing between multi-stream within a single session, and multi-session-transport. Within SDP this is critical because RFC 5583 is not designed to deal with single session-multi stream transport, and therefore we will get negotiatio= n failures. [StW] As we are NOT addressing SSRC-based mutilplexing in this draft (excep= t by forward looking statements in informative notes, as per London agreeme= nt), I think the sentence as written is correct. However, I would agree th= at it is a bit misleading. How about adding a note: Informative note: This document is not addressing MSM scenarios in wh= ich multiple RTP streams are conveyed in the same RTP session (SSRC multi= plexing). [/StW] Receivers MUST support both SSM and MSM. [BA] This is a nice statement, but by the above confusion created by bad te= rminology will make it meaningless. Overall, this document creates additional confusion above and= beyond that which we already had in RFC 6190. [StW] with above changes, I hope there is no confusion anymore. Yes? --_000_D07FD0854A951stewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <398A8CADED43A04383B5FB272C519AC3@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Bernard,
Sorry for the late reply.  
In London, we agreed that the signaling aspects of (what was then called) M= ST within one RTP session are out of scope for this payload format.  S= ee here: http://www.ietf.org/proceedings/89/slides/slides-89-payload-6.pdf = (presentation in London) and here http://www.ietf.org/proceedings/89/minute= s/minutes-89-payload (minutes, including quote =93The conclusion was to take MST support out of= the document in order to finish the payload.=94).  This was confirmed= on the mailing list (by lack of objection to notes and my email requesting= for objections) sometime in late April/early May of 2014.
Unless we change this agreement, the support for bundle-like mechanisms is = out of scope for this draft.  
In this light, I propose to modify our draft as shown inline and marked [St= W].  These changes mostly soften previously overly tight language and = clarify the scope.
For the I-D authors,
Stephan 

From: Bernard Aboba <bernard_aboba@hotmail.com>
Date: Tuesday, October 28, 2014 at = 14:46
To: "payload@ietf.org" <payload@ietf.org>
Subject: [payload] Problem with dra= ft-ietf-payload-rtp-h265

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

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



[BA] The statement above is wrong. RF=
C 5583 dependency groups based on the
use of a=3Dgroup:DDP and a=3Dmid: lin=
es and therefore can only deal with 
dependencies between m-lines (multipl=
e RTP sessions).  If the RTP streams
are sent within the same RTP session, the dep=
endency cannot be indicated as specified in RFC 5583.

[StW] = Bernard=92s statement is correct.  However, we had an agreement in Lon= don that this I-D does not deal with the complexities resulting from stream= s being sent in the same session (SSRC mutilplexing).  We concluded at the time that the generic problem of signaling thing= s like dependencies will need to be addressed by a generic signaling mechan= ism, applicable to all payload formats.  
Theref= ore, we propose to to clarify as follows:
 

&nbs=
p;  In some systems, the dDependency of one RTP stream o=
n another RTP stream is typicallycan be

&nbs=
p;  indicated as specified in [RFC5583].&nb=
sp; In the future, signaling mechanisms may become available that


&=
nbsp;  offer similar functionality also when mult=
iple RTP stream are carried in the same RTP session,<=
/pre>

&=
nbsp;  where the [RFC=
5583] mechanism does not apply.  Regardless of the signaling details, =
wWhen an RTP stream A


&nbs=
p;  depends on another RTP stream B, the RTP stream B is referred to
&nbs=
p;  as a dependee RTP stream of the RTP stream A.
[/StW]

      Informat=
ive note: An MSM may involve one or more RTP sessions.
      Each RTP stream in an MSM may be in its own RTP session or a
      set of multiple RTP streams in an MSM may belong to the same
      RTP session, e.g. as indicated by the mechanism specified in
      the Internet-Draft [I-D.ietf-avtcor=
e-rtp-multi-stream] or in
      [I-D.ietf-mmusic-sdp-bundle-ne=
gotiation].  This document is not
      addressing MSM scenarios in which multiple RTP streams are conveyed=  
    &nbs= p; in the same RTP session (SSRC multiplexing).
   SSM SHOULD be used for point-to-point unicast scenarios, while
   MSM SHOULD be used for point-to-multipoint multicast scenarios
   where different receivers require different operation points of
   the same HEVC bitstream, to improve bandwidth utilizing
   efficiency.

[BA] This is also wrong. While it was=
 accurate that Multi-Session-Transport
should be used for point-to-multipoin=
t multicast scenarios, Single-Session-Transport
of multiple streams can be used in po=
int-to-point unicast scenarios.

[StW] I think Ber= nard is right, again.  From a bandwidth viewpoint, the use of SSM and = MSM do not necessarily make a difference.  It=92s the same number of p= ackets with the same packet overhead that are being sent.  When RoHC is in the picture, things may be different (SS= RC cannot be compressed away), but do we really care about that scenario? &= nbsp;I start wondering why we wrote about the bandwidth thing (probably was= me who wrote this, carelessly=85)
I propose to remo= ve the paragraph.  The note can stay,= with the amendment shown.
[/StW]


   The transmission mode is indicated=
 by the tx-mode media parameter
   (see section 7.1).  If tx-mode is equal to "SSM", =
SSM MUST be
   used.  Otherwise (tx-mode is equal to "MSM"), MSM MUST be used=
.

[BA] This also does not make sense, b=
ecause it will not allow for distinguishing
between multi-stream within a single =
session, and multi-session-transport. 
Within SDP this is critical because R=
FC 5583 is not designed to deal with
single session-multi stream transport=
, and therefore we will get negotiation
failures.

[StW] As we are NOT addressing SSRC-based mutilplexing in this draft (= except by forward looking statements in informative notes, as per London ag= reement), I think the sentence as written is correct.  However, I woul= d agree that it is a bit misleading.  How about adding a note:

      Informative note: This document=
 is not addressing MSM scenarios in which 
      multiple RTP streams are convey=
ed in the same RTP session (SSRC multiplexing).













[/StW]













   Receivers MUST support both SSM and MSM.






[BA] This is a nice statement, but by=
 the above confusion created by bad terminology will make it


meaningless.  Overall, this document =
creates additional confusion above and beyond that which we


already had in RFC 6190.  


















[StW] with above changes, I hope there is no confusion anymore.  =
Yes?
































--_000_D07FD0854A951stewesteweorg_--


From nobody Thu Nov 13 13:10:38 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 17B111AD567; Thu, 13 Nov 2014 13:09:56 -0800 (PST)
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 PsXuOGsHY0pP; Thu, 13 Nov 2014 13:09:53 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D61C1AD572; Thu, 13 Nov 2014 13:09:53 -0800 (PST)
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.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141113210953.11966.15193.idtracker@ietfa.amsl.com>
Date: Thu, 13 Nov 2014 13:09:53 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/payload/MgJ_b4Tl03FqiwB0nXhP1ZPZNYw
Cc: payload@ietf.org
Subject: [payload] I-D Action: draft-ietf-payload-rtp-opus-04.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: Thu, 13 Nov 2014 21:09:56 -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 Opus Speech and Audio Codec
        Authors         : Julian Spittka
                          Koen Vos
                          Jean-Marc Valin
	Filename        : draft-ietf-payload-rtp-opus-04.txt
	Pages           : 18
	Date            : 2014-11-13

Abstract:
   This document defines the Real-time Transport Protocol (RTP) payload
   format for packetization of Opus encoded speech and audio data
   necessary to integrate the codec in the most compatible way.
   Further, it describes media type registrations for the RTP payload
   format.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-payload-rtp-opus-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-opus-04


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 Thu Nov 13 17:30:37 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 26CD61A001C for ; Thu, 13 Nov 2014 17:30:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.095
X-Spam-Level: 
X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 J-7KHe2g0Wmp for ; Thu, 13 Nov 2014 17:30:34 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9E81A1A0F for ; Thu, 13 Nov 2014 17:30:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=263; q=dns/txt; s=iport; t=1415928636; x=1417138236; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=D+dFjn5u94cJi7C6+pHGbjQezIez7xFbqXhEPZupvAM=; b=MzOyUJgBIl4J0tiwz+2GP7k+eFFy8zgBSWB6J6Ehdcc0vCOt2s9wABSZ Fb9oY39R4XIprzTXs32nWqWPi8yYtMzQbNgTqN3leUT1xugDe37GR/NkK /bD/so/iO9NwCMa9qodwenOiHZ1ZgZPfSXhuG3AI0IxpS3o9b1TgnUTIB s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjsFADpaZVStJV2a/2dsb2JhbABbgmsjVF2NY78Th0aBLBYBAQEBAX2ECTpRAT5CJwSIVAEMqnulagEBAQEBAQQBAQEBAQEBARYEkDIRAYQEgR4FkjqEU4ckgTSDT5Fkg3yBfDmBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,381,1413244800"; d="scan'208";a="372085367"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 14 Nov 2014 01:30:35 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sAE1UYQD004044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Nov 2014 01:30:34 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 19:30:33 -0600
From: "Ali C. Begen (abegen)" 
To: "" 
Thread-Topic: WGLC for draft-ietf-payload-rtp-opus-04
Thread-Index: AQHP/6qVxzeDaesXAEW7xxhUMW5aHg==
Date: Fri, 14 Nov 2014 01:30:33 +0000
Message-ID: <6489862A-6941-4C49-B19C-C12FC1FD9DFC@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.120.114]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/payload/GK9PIF6lazBIqgp8IZ5YBjtPyiQ
Subject: [payload] WGLC for draft-ietf-payload-rtp-opus-04
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: Fri, 14 Nov 2014 01:30:36 -0000

This is to start WGLC for the opus draft.
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/

The WGLC will end Dec. 1st. Please review the draft and send an email to th=
e list even if you dont have any comments.

Thanks.
-acbegen (co-chair)=


From nobody Tue Nov 18 07:08:33 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 557E51A1A47 for ; Tue, 18 Nov 2014 07:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.594] 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 VPrTDRO_-KMe for ; Tue, 18 Nov 2014 07:08:19 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 946A11A03FF for ; Tue, 18 Nov 2014 07:06:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BFED07C04D5; Tue, 18 Nov 2014 16:06:44 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRN4pKHvkd2Q; Tue, 18 Nov 2014 16:06:43 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:d5ed:38ca:7efb:7f24] (unknown [IPv6:2001:470:de0a:27:d5ed:38ca:7efb:7f24]) by mork.alvestrand.no (Postfix) with ESMTPSA id 30FDE7C0456; Tue, 18 Nov 2014 16:06:43 +0100 (CET)
Message-ID: <546B6082.8030205@alvestrand.no>
Date: Tue, 18 Nov 2014 16:06:42 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: payload@ietf.org, Roni Even 
References:  <013301cf9a71$2f863420$8e929c60$@gmail.com> <39731C83-C883-4E7A-9F0F-C007C7B9AD0E@live555.com> <5457CB53.1080805@alvestrand.no>
In-Reply-To: <5457CB53.1080805@alvestrand.no>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/payload/ma_0uYaH5bve4ASjbNpougT1u98
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, 18 Nov 2014 15:08:26 -0000

Just a ping - want to check that the fix suggested is acceptable to Roni
and the WG before getting it committed.

Den 03. nov. 2014 19:37, skrev Harald Alvestrand:
> On 10/27/2014 11:56 PM, Ross Finlayson wrote:
>>> On Jul 7, 2014, at 10:55 PM, Roni Even >> > wrote:
>>>
>>> Hi,
>>> I reviewed the document and have some comments as individual
>> […]
>>> 6. In section 6.2.2 what is the meaning of max-fr and max-fs if the
>>> stream
>>> is sendonly?
>>
>> Ditto if a ‘declarative’ SDP description is generated for a stream -
>> e.g., for RTSP?
>>
>> Section 6.2.1 "Mapping of Media Subtype Parameters to SDP” of the
>> latest VP8 payload format draft ("draft-ietf-payload-vp8-13”) says
>> The parameters "max-fs", and "max-fr", MUST be included in the
>> "a=fmtp" line of SDP
>> I think this is too strong.  IMHO it should be a MUST only if the SDP
>> is used in an ‘offer-answer’ environment, and the stream is not
>> ‘sendonly’ (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”
>>
> 
> Thanks, this fix seems reasonable:
> 
> - MUST be included if the SDP is used to declare receiver capabilities
> 
> I don't want to get into the quagmire of describing all the situations
> where it is (or isn't) used in that way.
> 
> I'm unsure what we should do on sendonly; MUST NOT would be logical and
> consistent, but seems to complicate implementations that just want to
> hardcode their SDP strings to the extent possible. MAY, and say that the
> a=fmtp parameters are then those that would have been used if the stream
> had been receive-only?
> 
> I'm sure we can get the same fix into VP9. This is not where we want to
> be creative :-)
> 
>>
>>
>> Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/
>>
>>
>>
>> _______________________________________________
>> payload mailing list
>> payload@ietf.org
>> https://www.ietf.org/mailman/listinfo/payload
> 
> 
> -- 
> Surveillance is pervasive. Go Dark.
> 
> 
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
> 


From nobody Tue Nov 18 21:17:30 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 AF7AB1ACF85 for ; Tue, 18 Nov 2014 21:17:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] 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 mCo6gj1d6Aqa for ; Tue, 18 Nov 2014 21:17:28 -0800 (PST)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC891ACF67 for ; Tue, 18 Nov 2014 21:17:27 -0800 (PST)
Received: by mail-pd0-f178.google.com with SMTP id y13so9678255pdi.23 for ; Tue, 18 Nov 2014 21:17:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=P1Iay649Lm7T57M1u9B14VrBRah0ESFGdCiaW0s11iE=; b=aLUoQnTqaBs4xZW8kRJUvy5xmO33N+VPCuk/mfG+RoJtLeGLWZ33ckPDPa1h3NYMr0 29BYHNyd64dsx4sKSNNbZRwj+HuwmBrsavDfkL3QVVrOsxozCeBsbKT7a0cU0B9KHyzd 1k0sYhANAk6UcsTsmYM/VhZ9+yZY1LbVcGUpz8T0mrnllhnz0+uQoeYXhh9Xc+gUtm0g WGY8yvNsRpKxW85dahmTMnUT1H53xoQfMCOlinkfsuSqJOigoJyuyY7Yotai0pBvSxMP XgBsQTdRC9XYVm5BJOrEfzVq19HNmT5pTUsFFi70Jt+iQnyX3xyZKlpTgHLX05QFXzMf AXjQ==
X-Received: by 10.66.252.193 with SMTP id zu1mr8189981pac.153.1416374245973; Tue, 18 Nov 2014 21:17:25 -0800 (PST)
Received: from RoniE (rrcs-173-197-99-34.west.biz.rr.com. [173.197.99.34]) by mx.google.com with ESMTPSA id th7sm599890pac.47.2014.11.18.21.17.23 for  (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Nov 2014 21:17:24 -0800 (PST)
From: "Roni Even" 
To: "'Harald Alvestrand'" , , "'Roni Even'" 
References:  <013301cf9a71$2f863420$8e929c60$@gmail.com> <39731C83-C883-4E7A-9F0F-C007C7B9AD0E@live555.com> <5457CB53.1080805@alvestrand.no> <546B6082.8030205@alvestrand.no>
In-Reply-To: <546B6082.8030205@alvestrand.no>
Date: Wed, 19 Nov 2014 07:17:16 +0200
Message-ID: <00e801d003b8$18880ea0$49982be0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEF01AJCGwzyzlsWQjSYUEPAIEdlQHmhD3wAnj18i8B/AAq7QIUGNBlnbhM3qA=
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/payload/eenaQHaDuAykh-IoAf94Y9_YUI4
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: Wed, 19 Nov 2014 05:17:29 -0000

Hi,
I am OK with herald proposal
Roni

> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Harald
> Alvestrand
> Sent: 18 November, 2014 5:07 PM
> To: payload@ietf.org; Roni Even
> Subject: Re: [payload] WGLC for VP8 (draft-ietf-payload-vp8-11)
> 
> Just a ping - want to check that the fix suggested is acceptable to Roni
and the
> WG before getting it committed.
> 
> Den 03. nov. 2014 19:37, skrev Harald Alvestrand:
> > On 10/27/2014 11:56 PM, Ross Finlayson wrote:
> >>> On Jul 7, 2014, at 10:55 PM, Roni Even  >>> > wrote:
> >>>
> >>> Hi,
> >>> I reviewed the document and have some comments as individual
> >> [.]
> >>> 6. In section 6.2.2 what is the meaning of max-fr and max-fs if the
> >>> stream is sendonly?
> >>
> >> Ditto if a 'declarative' SDP description is generated for a stream -
> >> e.g., for RTSP?
> >>
> >> Section 6.2.1 "Mapping of Media Subtype Parameters to SDP" of the
> >> latest VP8 payload format draft ("draft-ietf-payload-vp8-13") says
> >> The parameters "max-fs", and "max-fr", MUST be included in the
> >> "a=fmtp" line of SDP I think this is too strong.  IMHO it should be a
> >> MUST only if the SDP is used in an 'offer-answer' environment, and
> >> the stream is not 'sendonly' (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"
> >>
> >
> > Thanks, this fix seems reasonable:
> >
> > - MUST be included if the SDP is used to declare receiver capabilities
> >
> > I don't want to get into the quagmire of describing all the situations
> > where it is (or isn't) used in that way.
> >
> > I'm unsure what we should do on sendonly; MUST NOT would be logical
> > and consistent, but seems to complicate implementations that just want
> > to hardcode their SDP strings to the extent possible. MAY, and say
> > that the a=fmtp parameters are then those that would have been used if
> > the stream had been receive-only?
> >
> > I'm sure we can get the same fix into VP9. This is not where we want
> > to be creative :-)
> >
> >>
> >>
> >> Ross Finlayson
> >> Live Networks, Inc.
> >> http://www.live555.com/
> >>
> >>
> >>
> >> _______________________________________________
> >> payload mailing list
> >> payload@ietf.org
> >> https://www.ietf.org/mailman/listinfo/payload
> >
> >
> > --
> > Surveillance is pervasive. Go Dark.
> >
> >
> >
> > _______________________________________________
> > payload mailing list
> > payload@ietf.org
> > https://www.ietf.org/mailman/listinfo/payload
> >
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload


From nobody Wed Nov 26 10:34:30 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 105D51A1A91 for ; Wed, 26 Nov 2014 10:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.612
X-Spam-Level: 
X-Spam-Status: No, score=-14.612 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 oz9x894kjLGL for ; Wed, 26 Nov 2014 10:34:25 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B251A1A6B for ; Wed, 26 Nov 2014 10:34:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17954; q=dns/txt; s=iport; t=1417026865; x=1418236465; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=3OvM/NacJ4m9n8/qPVZ+PE0O4SAGrVJSX2F33CbRbV8=; b=P228RU7siRYW50igyFV/IhmCJskCRNZy4B7U91UB0LvPBK/V3Hfjuy87 +fVsSwZlehsVJf/o//cf/MRPjrMsjrfXzX7gPiHOSEtJ/GQ+5Zt/60Nhv 1dAwwauAp4O/1qDi2e6Bd70wBD52x8q5FAWa7TbTaURzsbCxBC/JHtiXc w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUFADMcdlStJA2G/2dsb2JhbABYA4MGUlcExWOCLQqGTQKBDBYBAQEBAX2EAgEBAQQBAQEkEzQEBwwGAQgOAwMBAQEBChQJKAYLFAkJAQQBDQUIiCMDEg3MQw2GNwEBAQEBAQEBAQEBAQEBAQEBAQEBAReOQz6BSSEQDQuDHYEfBYR4gVWEYIUMgiyEZ4JUggdGg0k/gxqDOYdXgnSECoICIIFadwGBBQY8gQIBAQE
X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="100386944"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 26 Nov 2014 18:34:24 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAQIYNA7022246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 18:34:23 GMT
Received: from xmb-rcd-x12.cisco.com ([169.254.2.223]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 12:34:23 -0600
From: "Michael Ramalho (mramalho)" 
To: Robert Sparks , "Black, David" , "Paul E. Jones (paulej@packetizer.com)" , "harada.noboru@lab.ntt.co.jp" , "muthu.arul@gmail.com" , "lei.miao@huawei.com" , Richard Barnes 
Thread-Topic: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-payload-g7110-03
Thread-Index: AdAJp5Ir/SxmfS01TH2QKW4njxeGgw==
Date: Wed, 26 Nov 2014 18:34:23 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.221.67]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/payload/t1P58p7J6HR-M4KlVVBWr0W3AxE
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, 26 Nov 2014 18:34:29 -0000

Robert,

Thank you for your review/comments.

As you have likely seen, I have responded to David Black's initial review a=
nd am in the process of responding to his most recent review.

I think a lot of the verbosity of this payload format is due to its uniquen=
ess as a lossless and stateless compression and the path the ITU-T took in =
its design. In a manner similar to video codecs - but unlike traditional au=
dio codecs (such as RFC 5391) - there is flexibility in how the compression=
 is accomplished.=20

The ITU-T G.711.0 standard ONLY specifies the encoding of an individual inp=
ut G.711 frame (which can only have lengths of 40, 80, 160, 240 or 320 G.71=
1 symbols) into a singular G.711.0 frame.

As an example, 20 ms worth of G.711 input symbols is comprised of 160 bytes=
/octets (assuming the usual 8000 samples per second). These 160 bytes  can =
be encoded in 1, 2, 3 or 4 G.711.0 frames in any one of six combinations in=
 a G.711.0 payload ([20ms],[ 10ms:10ms],[10ms:5ms:5ms], [5ms:10ms:5ms], [5m=
s:5ms:10ms],[5ms:5ms:5ms:5ms]).

In a manner similar to many (lossy) video encoders, the encoding endpoint c=
an choose ANY of those six combinations. And any one of those combinations =
will be LOSSLESSLY decompressed into the same 160 source octets. In practic=
e we expect only two choices: 1) the encoding that is the most efficient (s=
mallest net G.711.0 RTP payload) or 2) the simplest (one G.711.0 frame from=
 160 source bytes). So, similar to video encoders, the output is not determ=
inistic from a given input (in this example it could be one of six possible=
 compression representations) for a given ptime of 20ms.

Thus, at the decoding end, the G.711.0 RTP process will need to parse throu=
ghout the individual frames to pass them to the ITU-T specified G.711.0 dec=
oder - as it only decodes individual G.711.0 frames. Unlike video encoding,=
 there is NOT a straightforward (bandwidth wasteful) delineation of the ind=
ividual building blocks analogous to "NAL Units". Instead we need to parse =
out the individual components (here, the individual G.711.0 frames) to find=
 the frame boundaries by recursively invoking the decoder as necessary.

Now here is the nuance; the ITU-T G.711.0 REFERENCE CODE decoder has the ab=
ility to take in a "bit stream" consisting of a concatenation of G.711.0 fr=
ames (i.e., the RTP payload) - but it is not a formal part of the standard!=
 If it were, we could consider the RTP payload as an "opaque compressed BIT=
 STREAM blob" to pass to the decoder. As David Black has noted in his revie=
w, the draft needs to have some additional text for how individual G.711.0 =
frames are presented to the RTP encoding process (I am working on that with=
 my co-authors, David).

Lastly, when we have more than one channel in an RTP packet payload, we nee=
d to know how to parse individual G.711.0 frames to determine the boundary =
of the channel information.

In summary, the detail of the individual G.711.0 frames is for four purpose=
s: 1) to convey that there can be one or more G.711.0 frames in a given RTP=
 payload (for a given fixed ptime) and that number of G.711.0 frames could =
change on a packet-by-packet basis, 2) because the G.711.0 standard itself =
only concerns itself with individual input G.711 symbols to individual G.71=
1.0 frames, 3) the reference code for the compressed bit stream isn't a for=
mal part of the standard, and 4) the multiple channel case.

The additional detail in Section 3 was decided during WG meetings to be inc=
luded as background, as many readers might have otherwise assumed that G.71=
1.0 was "just another (lossy) codec". In contrast, this is the first RTP pa=
yload format to specify the use of a lossless and stateless data compressio=
n algorithm for a sample-based codec (G.711) in RTP (which happens to have =
an ITU-T G.XXX.X moniker usually reserved for a "codec").

I hope this helps.

Michael Ramalho

-----Original Message-----
From: Robert Sparks [mailto:rjsparks@nostrum.com]=20
Sent: Wednesday, October 22, 2014 3:35 PM
To: Black, David; Michael Ramalho (mramalho); Paul E. Jones (paulej@packeti=
zer.com); harada.noboru@lab.ntt.co.jp; muthu.arul@gmail.com; lei.miao@huawe=
i.com; Richard Barnes
Cc: payload@ietf.org
Subject: Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-payload-g71=
10-03

(Dropping the review teams and ietf general - if I've done it right, this w=
ill go to David, the authors, and the payload wg list - also explicitly add=
ing Richard)

I have not been following payload closely recently, and I apologize for tha=
t.

The contents of this draft surprise me. I've only skimmed it so far, but fi=
nding a discussion of the internals of G.711.0 and how G.711 can be compres=
sed 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 else=
where, 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 payloa=
d? 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?=20
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 foll=
ows ...
>
> I am the assigned Gen-ART reviewer for this draft. For background on=20
> Gen-ART, please see the FAQ at:
>
> .
>
> Please resolve these comments along with any other Last Call comments=20
> you may receive.
>
> I have reviewed this document as part of the Operational directorate's=20
> ongoing effort to review all IETF documents being processed by the=20
> IESG.  These comments were written primarily for the benefit of the opera=
tional area directors.
> Document editors and WG chairs should treat these comments just like=20
> 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=20
> that has been scheduled for an IESG telechat almost immediately=20
> following the end of IETF Last Call.  The resulting overlap of IETF LC=20
> with IESG Evaluation can result in significant last-minute changes to=20
> the draft when issues are discovered during IETF LC.
>
> This draft describes an RTP payload format for carrying G.711.0=20
> compressed G.711 voice.  The details of G.711.0 compression are left=20
> to the ITU-T G.711.0 spec (which is fine), and this draft focuses on=20
> how to carry the compressed results in RTP and conversion to/from=20
> uncompressed G.711 voice at the communication endpoints.
> I found a few major issues and a couple of minor ones, although a=20
> couple of the major issues depend on a meta-issue, - the intended=20
> 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=20
> sense on their own, although one may need to read related documents to=20
> completely understand what's going on.  For this draft, I would expect=20
> the actual compression/decompression algorithms to be left to the=20
> ITU-T spec, and this draft to stand on its own in explaining how to=20
> deploy G.711.0 compression/decompression with RTP.  If that=20
> expectation is incorrect, and this draft is effectively an RTP Annex=20
> to G.711.0 that must be read in concert with G.711.0, then the first=20
> two major issues below are not problems as they should be obvious in=20
> the G.711.0 spec, although the fact that this draft is effectively an=20
> Annex to G.711.0 should be stated.  Otherwise, those two major issues=20
> need attention.
>
> -- Major Issues (4):
>
> [A] Section 4.2.3 specifies a detailed decoding algorithm covering how=20
> G.711.0 decompression interacts with received RTP G.711.0 payloads.
> A corresponding encoding algorithm specification is needed on the=20
> sending side for G.711.0 compression interaction with RTP sending.
> The algorithm will have some decision points in it that cannot be=20
> 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=20
> difficult to figure out what's going on when G.711.0 frames are=20
> concatenated.  A specific example is that the concept of a "prefix=20
> code" that occurs at the start of a G.711.0 frame is far too important=20
> 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=20
> imprecise (is SDP REQUIRED?, when is ptime REQUIRED, RECOMMENDED, or=20
> recommended? - it's not obvious).
>
> A specific example is that this sentence in Section 4.2.4 is an=20
> invitation to interoperability problems ("could infer" - how is that=20
> 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=20
> Section 3, to gather/summarize all of the relevant ptime discussion in=20
> one place.  I suspect that the contents of this draft are mostly=20
> correct wrt ptime, but it's hard to figure out what's going on from=20
> the current spread-out text.  It looks like "ptime" could provide a=20
> cross-check on correctness of G.711.0 decoding - see minor issue [G]=20
> below.
>
> This major issue [C] is independent of the relationship between this=20
> draft and the G.711.0 spec.
>
> [D] Backwards compatibility.
>
> The problem here is that it's not clear that negotiation (e.g., via=20
> 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=20
> 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=20
> 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 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:
>
>     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=20
> reader who's not familiar with the importance of the difference=20
> 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=20
> use" and I would expect those citations to be normative references.
>
> Would that be just RFC 3551 and RFC 4585 (both are already normative=20
> references), or are there more RTP profiles?
>
> [G] Framing errors
>
> Section 4 generally assumes that the G.711.0 decoder gets handed=20
> frames generated by the G.711.0 encoder and can't get disaligned.  I'm=20
> not convinced that this "just works" based on the text in the draft -=20
> major issue [B] is a significant reason why, and explaining that should h=
elp.
>
> Some discussion should be added on why the G.711.0 decoder can't get=20
> disaligned wrt frame boundaries this can't happen, or what the G.711.0=20
> decoder will do when it discovers that it wasn't handed a complete=20
> G.711.0 frame.  For example, this error case and how to deal with it=20
> 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=20
> is a valid G.711 input.  If that is correct, it should be explicitly stat=
ed.
>
>     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=20
> 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=20
> this draft, including two paragraphs earlier in this section - I=20
> 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=20
> of magnitude estimation came from.  What assumption(s) is(are) being=20
> 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=20
> is nothing useful that can be done in G.711.0 compression to respond=20
> 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=20
> 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=20
> format for RTP, so most of the operations and management concerns are=20
> 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=20
> 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=20
> G.711.0 decoder (decoder is handed octet strings that are not G.711.0=20
> frames generated by the encoder) should be discussed.  Major issue [B]=20
> 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=20
> draft) results in this new G.711.0 media type being usable in any=20
> 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=20
> 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.,=20
> 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