From magnus.westerlund@ericsson.com Wed Jun 1 01:12:12 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C75E0768 for ; Wed, 1 Jun 2011 01:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.29 X-Spam-Level: X-Spam-Status: No, score=-106.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WUQ7RlEZI5k for ; Wed, 1 Jun 2011 01:12:11 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 734FFE079E for ; Wed, 1 Jun 2011 01:12:11 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-9d-4de5f458b722 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F6.10.20773.854F5ED4; Wed, 1 Jun 2011 10:12:08 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 1 Jun 2011 10:12:06 +0200 Message-ID: <4DE5F455.8030608@ericsson.com> Date: Wed, 1 Jun 2011 10:12:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Magnus Westerlund References: <4DD10D68.1090302@ericsson.com> In-Reply-To: <4DD10D68.1090302@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Call for adopting document for mile stone "Support for multiple clock rates in an RTP session for Proposed Standard" X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 08:12:12 -0000 Hi, I hereby declare this document adopted as a WG document. The author is requested to submit a new version with a filename that indicate WG version. Cheers Magnus On 2011-05-16 13:41, Magnus Westerlund wrote: > WG, > > AVTEXT has one milestone: > > Dec 2011 Submit Support for multiple clock rates in an RTP session > for Proposed Standard > > We have one candidate document: > > https://datatracker.ietf.org/doc/draft-petithuguenin-avtext-multiple-clock-rates/ > > This is the call to the WG if we want to adopt this document as the > basis for meeting that milestone? Please provide comments even if it is > just "Yes". > > If you think there is some aspect of the issue or the solution that > hasn't been discussed and you want to ensure is covered, please comment > on that. > > The WG chairs will make a decision on 31st of May based on your comments. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Thu Jun 2 06:17:59 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302C0E07BB; Thu, 2 Jun 2011 06:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhGrzVJquifh; Thu, 2 Jun 2011 06:17:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55075E07B9; Thu, 2 Jun 2011 06:17:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110602131758.18470.85528.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2011 06:17:58 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio-level-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 13:17:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : A Real-Time Transport Protocol (RTP) Header Extension fo= r Client-to- Mixer Audio Level Indication Author(s) : Jonathan Lennox Emil Ivov Enrico Marocco Filename : draft-ietf-avtext-client-to-mixer-audio-level-02.txt Pages : 11 Date : 2011-06-02 This document defines a mechanism by which packets of Real-Time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox which wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer-audio= -level-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer-audio-= level-02.txt From emil@sip-communicator.org Thu Jun 2 06:19:11 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D501E07B9 for ; Thu, 2 Jun 2011 06:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqvEX+wNlmQu for ; Thu, 2 Jun 2011 06:19:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ECF91E079A for ; Thu, 2 Jun 2011 06:19:09 -0700 (PDT) Received: by wyb29 with SMTP id 29so703007wyb.31 for ; Thu, 02 Jun 2011 06:19:09 -0700 (PDT) Received: by 10.216.221.158 with SMTP id r30mr6212108wep.50.1307020748857; Thu, 02 Jun 2011 06:19:08 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id y3sm320570wec.34.2011.06.02.06.19.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2011 06:19:07 -0700 (PDT) Message-ID: <4DE78DCA.4050504@jitsi.org> Date: Thu, 02 Jun 2011 15:19:06 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: AVTEXT References: <20110509100550.21303.33389.idtracker@ietfa.amsl.com> <4DC7BEB5.6010002@jitsi.org> In-Reply-To: <4DC7BEB5.6010002@jitsi.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I-D Action: draft-ietf-avtext-mixer-to-client-audio-level-02.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 13:19:11 -0000 =D0=9D=D0=B0 09.05.11 12:15, Emil Ivov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= : > Hey all, >=20 > The authors are confident that all open issues and mailing list comment= s > have now been addressed and that this document is now ready to move for= ward. >=20 > We will be submitting the client-to-mixer draft in the following days. Done. We believe both documents are now ready to move forward. Cheers, Emil >=20 > =D0=9D=D0=B0 09.05.11 12:05, internet-drafts@ietf.org =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0: >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. This draft is a work item of the Audio/Video Transport Extensio= ns Working Group of the IETF. >> >> Title : A Real-Time Transport Protocol (RTP) Header Extensi= on for Mixer-to- Client Audio Level Indication >> Author(s) : Emil Ivov >> Enrico Marocco >> Jonathan Lennox >> Filename : draft-ietf-avtext-mixer-to-client-audio-level-02.tx= t >> Pages : 15 >> Date : 2011-05-09 >> >> This document describes a mechanism for RTP-level mixers in audio >> conferences to deliver information about the audio level of >> individual participants. Such audio level indicators are transport= ed >> in the same RTP packets as the audio data they pertain to. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-= audio-level-02.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-a= udio-level-02.txt >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext >> >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From keith.drage@alcatel-lucent.com Fri Jun 3 01:26:29 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B008EE06F8 for ; Fri, 3 Jun 2011 01:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.419 X-Spam-Level: X-Spam-Status: No, score=-104.419 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjRlgVANLPnx for ; Fri, 3 Jun 2011 01:26:28 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 852AFE0696 for ; Fri, 3 Jun 2011 01:26:28 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p538QDjk005825 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 3 Jun 2011 10:26:26 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 3 Jun 2011 10:26:20 +0200 From: "DRAGE, Keith (Keith)" To: Emil Ivov , AVTEXT Date: Fri, 3 Jun 2011 10:26:19 +0200 Thread-Topic: [avtext] mixer-to-client audio levels ready (Was: I-D Action: draft-ietf-avtext-mixer-to-client-audio-level-02.txt) Thread-Index: AcwhJ7YX2lkvcE3qT92tIeMRXNg0RgAEsW1w Message-ID: References: <20110509100550.21303.33389.idtracker@ietfa.amsl.com> <4DC7BEB5.6010002@jitsi.org> <4DE78DCA.4050504@jitsi.org> In-Reply-To: <4DE78DCA.4050504@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I-D Action: draft-ietf-avtext-mixer-to-client-audio-level-02.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 08:26:29 -0000 (As WG co-chair Can people do a rapid check and update their view of whether all open issue= s are adequately addressed or not. Are there any new ones? If there are none, we will start WGLC. If they are not, then we will have a= ppropriate rounds of discussions to close them. Keith > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of Emil Ivov > Sent: 02 June 2011 14:19 > To: AVTEXT > Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I-D Action= : > draft-ietf-avtext-mixer-to-client-audio-level-02.txt) >=20 > =EE=C1 09.05.11 12:15, Emil Ivov =CE=C1=D0=C9=D3=C1: > > Hey all, > > > > The authors are confident that all open issues and mailing list comment= s > > have now been addressed and that this document is now ready to move > forward. > > > > We will be submitting the client-to-mixer draft in the following days. >=20 > Done. We believe both documents are now ready to move forward. >=20 > Cheers, > Emil >=20 > > > > =EE=C1 09.05.11 12:05, internet-drafts@ietf.org =CE=C1=D0=C9=D3=C1: > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Audio/Video Transport > Extensions Working Group of the IETF. > >> > >> Title : A Real-Time Transport Protocol (RTP) Header > Extension for Mixer-to- Client Audio Level Indication > >> Author(s) : Emil Ivov > >> Enrico Marocco > >> Jonathan Lennox > >> Filename : draft-ietf-avtext-mixer-to-client-audio-level- > 02.txt > >> Pages : 15 > >> Date : 2011-05-09 > >> > >> This document describes a mechanism for RTP-level mixers in audio > >> conferences to deliver information about the audio level of > >> individual participants. Such audio level indicators are > transported > >> in the same RTP packets as the audio data they pertain to. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client- > audio-level-02.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> This Internet-Draft can be retrieved at: > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client- > audio-level-02.txt > >> _______________________________________________ > >> avtext mailing list > >> avtext@ietf.org > >> https://www.ietf.org/mailman/listinfo/avtext > >> > > >=20 > -- > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > Jitsi > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > http://jitsi.org FAX: +33.1.77.62.47.31 >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From musgravepj@gmail.com Sun Jun 5 12:33:38 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4992711E809B for ; Sun, 5 Jun 2011 12:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx3PN06tGQeI for ; Sun, 5 Jun 2011 12:33:37 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B959911E8070 for ; Sun, 5 Jun 2011 12:33:33 -0700 (PDT) Received: by fxm15 with SMTP id 15so2390485fxm.31 for ; Sun, 05 Jun 2011 12:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xw5rw0m6Bhs7edNa3DfOizCSH/7yuR2afDvXtnjoKVM=; b=MZ8EteQSoZCVmFWDW6i67kZVsqCajNmCH5BrhMSKQmIPq9HimTDQBqiQ3FrZhngCLj UZ+sLAvRYG8DYEgK3lx10+lFF/c6n0fG81UGupyyoSj7fKwrJEZkm3Onhhk+qK5e9B/x 76uaiMN5BgoxaY4vXogCxrUSZAR2f0B2v7Fu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dmf5xm5R28IwF+kpSRLYaEV/bYA8dC3/g8BM9WV7kei6iFZRjMRfJp8XV19u3JSo4+ df/0nyoEIokBv2sWlKJnl05AyPQkz1G4OpjLWehKCnzmh22gzUeiBQliBhw8GA4mdcX/ S+sMz33COCBNer63dd3iVs4LWYA1DYA99TDFI= MIME-Version: 1.0 Received: by 10.223.59.92 with SMTP id k28mr2429164fah.27.1307302412726; Sun, 05 Jun 2011 12:33:32 -0700 (PDT) Received: by 10.223.143.71 with HTTP; Sun, 5 Jun 2011 12:33:32 -0700 (PDT) In-Reply-To: References: <20110509100550.21303.33389.idtracker@ietfa.amsl.com> <4DC7BEB5.6010002@jitsi.org> <4DE78DCA.4050504@jitsi.org> Date: Sun, 5 Jun 2011 15:33:32 -0400 Message-ID: From: Peter Musgrave To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=00151744874eecb44704a4fc0f9f Cc: AVTEXT Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I-D Action: draft-ietf-avtext-mixer-to-client-audio-level-02.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 19:33:38 -0000 --00151744874eecb44704a4fc0f9f Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Hi, Looking through the diffs: In section 3 is now the statement "The two-byte header defined in RFC 5285 [RFC5285] may also be used." I am now a bit confused. I think that if len=3D2 then the RFC5285 header is implied? I think it would be good to make this explicit. Could I use a len= =3D2 and have some other level indication? Other than this, my previous comments have been addressed. Regards, Peter Musgrave 2011/6/3 DRAGE, Keith (Keith) > (As WG co-chair > > Can people do a rapid check and update their view of whether all open > issues are adequately addressed or not. Are there any new ones? > > If there are none, we will start WGLC. If they are not, then we will have > appropriate rounds of discussions to close them. > > Keith > > > -----Original Message----- > > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behal= f > > Of Emil Ivov > > Sent: 02 June 2011 14:19 > > To: AVTEXT > > Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I-D > Action: > > draft-ietf-avtext-mixer-to-client-audio-level-02.txt) > > > > =EE=C1 09.05.11 12:15, Emil Ivov =CE=C1=D0=C9=D3=C1: > > > Hey all, > > > > > > The authors are confident that all open issues and mailing list > comments > > > have now been addressed and that this document is now ready to move > > forward. > > > > > > We will be submitting the client-to-mixer draft in the following days= . > > > > Done. We believe both documents are now ready to move forward. > > > > Cheers, > > Emil > > > > > > > > =EE=C1 09.05.11 12:05, internet-drafts@ietf.org =CE=C1=D0=C9=D3=C1: > > >> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Audio/Video Transport > > Extensions Working Group of the IETF. > > >> > > >> Title : A Real-Time Transport Protocol (RTP) Header > > Extension for Mixer-to- Client Audio Level Indication > > >> Author(s) : Emil Ivov > > >> Enrico Marocco > > >> Jonathan Lennox > > >> Filename : draft-ietf-avtext-mixer-to-client-audio-level- > > 02.txt > > >> Pages : 15 > > >> Date : 2011-05-09 > > >> > > >> This document describes a mechanism for RTP-level mixers in audio > > >> conferences to deliver information about the audio level of > > >> individual participants. Such audio level indicators are > > transported > > >> in the same RTP packets as the audio data they pertain to. > > >> > > >> > > >> A URL for this Internet-Draft is: > > >> > http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client- > > audio-level-02.txt > > >> > > >> Internet-Drafts are also available by anonymous FTP at: > > >> ftp://ftp.ietf.org/internet-drafts/ > > >> > > >> This Internet-Draft can be retrieved at: > > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client= - > > audio-level-02.txt > > >> _______________________________________________ > > >> avtext mailing list > > >> avtext@ietf.org > > >> https://www.ietf.org/mailman/listinfo/avtext > > >> > > > > > > > -- > > Emil Ivov, Ph.D. 67000 Strasbourg, > > Project Lead France > > Jitsi > > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > > http://jitsi.org FAX: +33.1.77.62.47.31 > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --00151744874eecb44704a4fc0f9f Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Hi,=9A

Looking through the diffs:
In section 3= is now the statement "The two-byte header defined in RFC 5285 [RFC5285] may also be used."

I am now a bit confused. I think that= if len=3D2 then the RFC5285 header is implied? I think it would be good to= make this explicit. Could I use a len=3D2 and have some other level indica= tion?

Other than this, my previous comments have been address= ed.

Regards,=9A

Peter Mus= grave

2011/6/3 DRAGE, Keith (Keith= ) <k= eith.drage@alcatel-lucent.com>
(As WG co-chair

Can people do a rapid check and update their view of whether all open issue= s are adequately addressed or not. Are there any new ones?

If there are none, we will start WGLC. If they are not, then we will have a= ppropriate rounds of discussions to close them.

Keith

> -----Original Message-----
> From: avtext-bounces@ietf.o= rg [mailto:avtext-bounces@ie= tf.org] On Behalf
> Of Emil Ivov
> Sent: 02 June 2011 14:19
> To: AVTEXT
> Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I-D Act= ion:
> draft-ietf-avtext-mixer-to-client-audio-level-02.txt)
>
> =EE=C1 09.05.11 12:15, Emil Ivov =CE=C1=D0=C9=D3=C1:
> > Hey all,
> >
> > The authors are confident that all open issues and mailing list c= omments
> > have now been addressed and that this document is now ready to mo= ve
> forward.
> >
> > We will be submitting the client-to-mixer draft in the following = days.
>
> Done. We believe both documents are now ready to move forward.
>
> Cheers,
> Emil
>
> >
> > =EE=C1 09.05.11 12:05, internet-drafts@ietf.org =CE=C1=D0=C9=D3=C1:
> >> A New Internet-Draft is available from the on-line Internet-D= rafts
> directories. This draft is a work item of the Audio/Video Transport > Extensions Working Group of the IETF.
> >>
> >> =9A =9ATitle =9A =9A =9A =9A =9A : A Real-Time Transport Prot= ocol (RTP) Header
> Extension for Mixer-to- Client Audio Level Indication
> >> =9A =9AAuthor(s) =9A =9A =9A : Emil Ivov
> >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A Enrico Ma= rocco
> >> =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A Jonathan = Lennox
> >> =9A =9AFilename =9A =9A =9A =9A: draft-ietf-avtext-mixer-to-c= lient-audio-level-
> 02.txt
> >> =9A =9APages =9A =9A =9A =9A =9A : 15
> >> =9A =9ADate =9A =9A =9A =9A =9A =9A: 2011-05-09
> >>
> >> =9A =9AThis document describes a mechanism for RTP-level mixe= rs in audio
> >> =9A =9Aconferences to deliver information about the audio lev= el of
> >> =9A =9Aindividual participants. =9ASuch audio level indicator= s are
> transported
> >> =9A =9Ain the same RTP packets as the audio data they pertain= to.
> >>
> >>
> >> A URL for this Internet-Draft is:
> >> http://www.ietf.org/internet-drafts= /draft-ietf-avtext-mixer-to-client-
> audio-level-02.txt
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> This Internet-Draft can be retrieved at:
> >> ftp://ftp.ietf.org/internet-drafts/d= raft-ietf-avtext-mixer-to-client-
> audio-level-02.txt
> >> _______________________________________________
> >> avtext mailing list
> >> avtext@ietf.org
> >> https://www.ietf.org/mailman/listinfo/avtext
> >>
> >
>
> --
> Emil Ivov, Ph.D. =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A 67000 Str= asbourg,
> Project Lead =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A Franc= e
> Jitsi
> emcho@jitsi.org =9A =9A =9A =9A= =9A =9A =9A =9A =9A =9A =9A =9APHONE: +33.1.77.62.43.30
> http://jitsi.org = =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A FAX: =9A +33.1.77.62.47.31
>
> _______________________________________________
> avtext mailing list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext
_______________________________________________
avtext mailing list
avtext@ietf.org
= https://www.ietf.org/mailman/listinfo/avtext

--00151744874eecb44704a4fc0f9f-- From lennox@cs.columbia.edu Mon Jun 6 08:55:55 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711D311E8159 for ; Mon, 6 Jun 2011 08:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3tZhy5boCJZ for ; Mon, 6 Jun 2011 08:55:54 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id 3299A11E8163 for ; Mon, 6 Jun 2011 08:55:54 -0700 (PDT) Received: from irtcluster12.cs.columbia.edu (irtcluster12.cs.columbia.edu [128.59.11.141]) by mailbackend.panix.com (Postfix) with ESMTP id 23C8532FE0; Mon, 6 Jun 2011 11:55:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-5 Content-Transfer-Encoding: quoted-printable Message-ID: <19948.63623.447612.214609@irtcluster12.cs.columbia.edu> Date: Mon, 6 Jun 2011 11:55:51 -0400 To: Peter Musgrave In-Reply-To: References: <20110509100550.21303.33389.idtracker@ietfa.amsl.com> <4DC7BEB5.6010002@jitsi.org> <4DE78DCA.4050504@jitsi.org> X-Mailer: VM 7.19 under Emacs 22.1.1 From: lennox@cs.columbia.edu Cc: AVTEXT Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I-D Action: draft-ietf-avtext-mixer-to-client-audio-level-02.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 15:55:55 -0000 On Sunday, June 5 2011, "Peter Musgrave" wrote to "DRAGE, Keith (Keith)= , AVTEXT" saying: > Hi, >=20 > Looking through the diffs: > In section 3 is now the statement "The two-byte header defined in RFC= 5285 > [RFC5285] may also be used." >=20 > I am now a bit confused. I think that if len=3D2 then the RFC5285 hea= der is > implied=3F I think it would be good to make this explicit. Could I us= e a len=3D2 > and have some other level indication=3F >=20 > Other than this, my previous comments have been addressed. >=20 > Regards, >=20 > Peter Musgrave RFC 5285 has two forms for how it encodes its header extension elements= -- the form with "defined by profile" field 0xBEDE, with a four-bit ID and= four-bit length; and the form with "defined by profile" field 0x100x, w= ith eight-bit ID and eight-bit length. The point of this sentence is to ma= ke it clear that although the example uses the 0xBEDE form, the 0x100x form c= an also be used. It's nothing to do with the actual value that's encoded = in the "len" field. Is there alternative wording that would make this clearer=3F --=20 Jonathan Lennox lennox@cs.columbia.edu / jonathan@vidyo.com > 2011/6/3 DRAGE, Keith (Keith) >=20 > > (As WG co-chair > > > > Can people do a rapid check and update their view of whether all op= en > > issues are adequately addressed or not. Are there any new ones=3F > > > > If there are none, we will start WGLC. If they are not, then we wil= l have > > appropriate rounds of discussions to close them. > > > > Keith > > > > > -----Original Message----- > > > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On= Behalf > > > Of Emil Ivov > > > Sent: 02 June 2011 14:19 > > > To: AVTEXT > > > Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I-= D > > Action: > > > draft-ietf-avtext-mixer-to-client-audio-level-02.txt) > > > > > > =BD=D0 09.05.11 12:15, Emil Ivov =DD=D0=DF=D8=E1=D0: > > > > Hey all, > > > > > > > > The authors are confident that all open issues and mailing list= > > comments > > > > have now been addressed and that this document is now ready to = move > > > forward. > > > > > > > > We will be submitting the client-to-mixer draft in the followin= g days. > > > > > > Done. We believe both documents are now ready to move forward. > > > > > > Cheers, > > > Emil > > > > > > > > > > > =BD=D0 09.05.11 12:05, internet-drafts@ietf.org =DD=D0=DF=D8=E1= =D0: > > > >> A New Internet-Draft is available from the on-line Internet-Dr= afts > > > directories. This draft is a work item of the Audio/Video Transpo= rt > > > Extensions Working Group of the IETF. > > > >> > > > >> Title : A Real-Time Transport Protocol (RTP) Head= er > > > Extension for Mixer-to- Client Audio Level Indication > > > >> Author(s) : Emil Ivov > > > >> Enrico Marocco > > > >> Jonathan Lennox > > > >> Filename : draft-ietf-avtext-mixer-to-client-audio-l= evel- > > > 02.txt > > > >> Pages : 15 > > > >> Date : 2011-05-09 > > > >> > > > >> This document describes a mechanism for RTP-level mixers in= audio > > > >> conferences to deliver information about the audio level of= > > > >> individual participants. Such audio level indicators are > > > transported > > > >> in the same RTP packets as the audio data they pertain to. > > > >> > > > >> > > > >> A URL for this Internet-Draft is: > > > >> > > http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-clie= nt- > > > audio-level-02.txt > > > >> > > > >> Internet-Drafts are also available by anonymous FTP at: > > > >> ftp://ftp.ietf.org/internet-drafts/ > > > >> > > > >> This Internet-Draft can be retrieved at: > > > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-= client- > > > audio-level-02.txt > > > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F > > > >> avtext mailing list > > > >> avtext@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/avtext > > > >> > > > > > > > > > > -- > > > Emil Ivov, Ph.D. 67000 Strasbourg, > > > Project Lead France > > > Jitsi > > > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > > > http://jitsi.org FAX: +33.1.77.62.47.31 > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > > avtext mailing list > > > avtext@ietf.org > > > https://www.ietf.org/mailman/listinfo/avtext > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > > Hi,=A0

Looking through the diffs:
In sec= tion 3 is now the statement "The <= span class=3D"insert" style=3D"background-color: rgb(136, 255, 255); ">= two-byte header defined in RFC 5285 [RFC5285] may also b= e
I am now a bit confused. = I think that if len=3D2 then the RFC5285 header is implied=3F I think i= t would be good to make this explicit. Could I use a len=3D2 and have s= ome other level indication=3F
>

Other than this, my previous comments have been a= ddressed.

Regards,=A0

Peter Musgrave

2011/6/3 DRA= GE, Keith (Keith) <keith.drage@alcatel-lucent.com>
>
(As WG co-chair
>
> Can people do a rapid check and update their view of whether all open= issues are adequately addressed or not. Are there any new ones=3F
>
> If there are none, we will start WGLC. If they are not, then we will = have appropriate rounds of discussions to close them.
>
> Keith
>
> > -----Original Message-----
> > From: avtext-bounces@= ietf.org [mailto:avtext-= bounces@ietf.org] On Behalf
> > Of Emil Ivov
> > Sent: 02 June 2011 14:19
> > To: AVTEXT
> > Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I= -D Action:
> > draft-ietf-avtext-mixer-to-client-audio-level-02.txt)
>
>
> > =BD=D0 09.05.11 12:15, Emil Ivov =DD=D0=DF=D8=E1=D0:
> > > Hey all,
> > >
> > > The authors are confident that all open issues and mailing = list comments
> > > have now been addressed and that this document is now ready= to move
> > forward.
> > >
> > > We will be submitting the client-to-mixer draft in the foll= owing days.
> >
> > Done. We believe both documents are now ready to move forward. > >
> > Cheers,
> > Emil
> >
> > >
> > > =BD=D0 09.05.11 12:05, internet-drafts@ietf.org =DD=D0=DF=D8=E1=D0:
> > >> A New Internet-Draft is available from the on-line Inte= rnet-Drafts
> > directories. This draft is a work item of the Audio/Video Transp= ort
> > Extensions Working Group of the IETF.
> > >>
> > >> =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Real-Time Transpor= t Protocol (RTP) Header
> > Extension for Mixer-to- Client Audio Level Indication
> > >> =A0 =A0Author(s) =A0 =A0 =A0 : Emil Ivov
> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Enr= ico Marocco
> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jon= athan Lennox
> > >> =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-avtext-mixe= r-to-client-audio-level-
> > 02.txt
> > >> =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15
> > >> =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-09
> > >>
> > >> =A0 =A0This document describes a mechanism for RTP-leve= l mixers in audio
> > >> =A0 =A0conferences to deliver information about the aud= io level of
> > >> =A0 =A0individual participants. =A0Such audio level ind= icators are
> > transported
> > >> =A0 =A0in the same RTP packets as the audio data they p= ertain to.
> > >>
> > >>
> > >> A URL for this Internet-Draft is:
> > >> http://www.ietf.org/int= ernet-drafts/draft-ietf-avtext-mixer-to-client-
> > audio-level-02.txt
> > >>
> > >> Internet-Drafts are also available by anonymous FTP at:=
> > >> ftp://ftp.ietf.org/internet-drafts/
> > >>
> > >> This Internet-Draft can be retrieved at:
> > >> ftp://ftp.ietf.org/inter= net-drafts/draft-ietf-avtext-mixer-to-client-
> > audio-level-02.txt
> > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F
> > >> avtext mailing list
> > >> avtext@ietf.org<= br> > > >> https://www.ietf.org/mailman/listinfo/avtext<= br> > > >>
> > >
> >
> > --
> > Emil Ivov, Ph.D. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 670= 00 Strasbourg,
> > Project Lead =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= France
> > Jitsi
> > emcho@jitsi.org =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PHONE: +33.1.77.62.43.30
> > http://jitsi.or= g =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 FAX: =A0 +33.1.77.62.47.31 > >
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> > avtext mailing list
> > avtext@ietf.org
> > https://www.ietf.org/mailman/listinfo/avtext
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
> avtext mailing list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext
>

> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From musgravepj@gmail.com Mon Jun 6 16:40:14 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8B41F0C4D for ; Mon, 6 Jun 2011 16:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=0.664, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzLxa+QmCo54 for ; Mon, 6 Jun 2011 16:40:12 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E7AF21F0C46 for ; Mon, 6 Jun 2011 16:40:11 -0700 (PDT) Received: by fxm15 with SMTP id 15so3181102fxm.31 for ; Mon, 06 Jun 2011 16:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qG+6TQnXtgVMJ/X1TF94LDEZLYKmfpAhzmNpG4EmdGU=; b=OzWrzGTMkdK+8HF6HQEthRIJ52W1wwzSoVoVQ5bvSRPy7hVt9y532g+GVOMzUYpbw7 33fwJprSXlFBa+wsx1H41eIjjTLqshlswAHKhs985cEdIGPDZBlEHd6+JAM4Ilw9iccr cg5PgW+ek8pzONxOcSrlRlVfX00Yp0B/RvXwY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lKoBy2dUYnFSpLbCbiBb8T2XMlr7hxB27Ov6umItYyLLWEHMdMVPVhDg09z9jjWb+c V3i4psDK0Yp+N/Utb83CoYFbUkXxkSYENaNKRtgMBgHufqXq5q/gLEZbPO0bgPZWyZkY rLuFV3Um0z0U7sfHgvel+MVlN8Woim9CSfvmg= MIME-Version: 1.0 Received: by 10.223.71.204 with SMTP id i12mr3592516faj.65.1307403610883; Mon, 06 Jun 2011 16:40:10 -0700 (PDT) Received: by 10.223.143.71 with HTTP; Mon, 6 Jun 2011 16:40:10 -0700 (PDT) In-Reply-To: <19948.63623.447612.214609@irtcluster12.cs.columbia.edu> References: <20110509100550.21303.33389.idtracker@ietfa.amsl.com> <4DC7BEB5.6010002@jitsi.org> <4DE78DCA.4050504@jitsi.org> <19948.63623.447612.214609@irtcluster12.cs.columbia.edu> Date: Mon, 6 Jun 2011 19:40:10 -0400 Message-ID: From: Peter Musgrave To: lennox@cs.columbia.edu Content-Type: multipart/alternative; boundary=20cf3054a8c1ce075004a5139f6b Cc: AVTEXT Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I-D Action: draft-ietf-avtext-mixer-to-client-audio-level-02.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 23:40:14 -0000 --20cf3054a8c1ce075004a5139f6b Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable I think what you just said would work. I'll confess I was too lazy to go dig out the reference - and sadly I expec= t there are more people just as lazy as me out there... I can live with the text as it is. (If I was implementing it I would be les= s lazy). Peter 2011/6/6 > On Sunday, June 5 2011, "Peter Musgrave" wrote to "DRAGE, Keith (Keith), > AVTEXT" saying: > > > Hi, > > > > Looking through the diffs: > > In section 3 is now the statement "The two-byte header defined in RFC > 5285 > > [RFC5285] may also be used." > > > > I am now a bit confused. I think that if len=3D2 then the RFC5285 heade= r is > > implied? I think it would be good to make this explicit. Could I use a > len=3D2 > > and have some other level indication? > > > > Other than this, my previous comments have been addressed. > > > > Regards, > > > > Peter Musgrave > > RFC 5285 has two forms for how it encodes its header extension elements -= - > the form with "defined by profile" field 0xBEDE, with a four-bit ID and > four-bit length; and the form with "defined by profile" field 0x100x, wit= h > eight-bit ID and eight-bit length. The point of this sentence is to make > it > clear that although the example uses the 0xBEDE form, the 0x100x form can > also be used. It's nothing to do with the actual value that's encoded in > the "len" field. > > Is there alternative wording that would make this clearer? > > -- > Jonathan Lennox > lennox@cs.columbia.edu / jonathan@vidyo.com > > > 2011/6/3 DRAGE, Keith (Keith) > > > > > (As WG co-chair > > > > > > Can people do a rapid check and update their view of whether all open > > > issues are adequately addressed or not. Are there any new ones? > > > > > > If there are none, we will start WGLC. If they are not, then we will > have > > > appropriate rounds of discussions to close them. > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > Behalf > > > > Of Emil Ivov > > > > Sent: 02 June 2011 14:19 > > > > To: AVTEXT > > > > Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I-D > > > Action: > > > > draft-ietf-avtext-mixer-to-client-audio-level-02.txt) > > > > > > > > =CD=E0 09.05.11 12:15, Emil Ivov =ED=E0=EF=E8=F1=E0: > > > > > Hey all, > > > > > > > > > > The authors are confident that all open issues and mailing list > > > comments > > > > > have now been addressed and that this document is now ready to mo= ve > > > > forward. > > > > > > > > > > We will be submitting the client-to-mixer draft in the following > days. > > > > > > > > Done. We believe both documents are now ready to move forward. > > > > > > > > Cheers, > > > > Emil > > > > > > > > > > > > > > =CD=E0 09.05.11 12:05, internet-drafts@ietf.org =ED=E0=EF=E8=F1= =E0: > > > > >> A New Internet-Draft is available from the on-line Internet-Draf= ts > > > > directories. This draft is a work item of the Audio/Video Transport > > > > Extensions Working Group of the IETF. > > > > >> > > > > >> Title : A Real-Time Transport Protocol (RTP) Header > > > > Extension for Mixer-to- Client Audio Level Indication > > > > >> Author(s) : Emil Ivov > > > > >> Enrico Marocco > > > > >> Jonathan Lennox > > > > >> Filename : > draft-ietf-avtext-mixer-to-client-audio-level- > > > > 02.txt > > > > >> Pages : 15 > > > > >> Date : 2011-05-09 > > > > >> > > > > >> This document describes a mechanism for RTP-level mixers in > audio > > > > >> conferences to deliver information about the audio level of > > > > >> individual participants. Such audio level indicators are > > > > transported > > > > >> in the same RTP packets as the audio data they pertain to. > > > > >> > > > > >> > > > > >> A URL for this Internet-Draft is: > > > > >> > > > http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client= - > > > > audio-level-02.txt > > > > >> > > > > >> Internet-Drafts are also available by anonymous FTP at: > > > > >> ftp://ftp.ietf.org/internet-drafts/ > > > > >> > > > > >> This Internet-Draft can be retrieved at: > > > > >> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client- > > > > audio-level-02.txt > > > > >> _______________________________________________ > > > > >> avtext mailing list > > > > >> avtext@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/avtext > > > > >> > > > > > > > > > > > > > -- > > > > Emil Ivov, Ph.D. 67000 Strasbourg, > > > > Project Lead France > > > > Jitsi > > > > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > > > > http://jitsi.org FAX: +33.1.77.62.47.31 > > > > > > > > _______________________________________________ > > > > avtext mailing list > > > > avtext@ietf.org > > > > https://www.ietf.org/mailman/listinfo/avtext > > > _______________________________________________ > > > avtext mailing list > > > avtext@ietf.org > > > https://www.ietf.org/mailman/listinfo/avtext > > > > > Hi,

Looking through the diffs:
In section= 3 > is now the statement " style=3D"font-family: monospace; font-size: 11px; white-space: pre; ">The > t= wo-byte > header defined in rgb(136, 255, 255); ">RFC 5285 [RFC5285] may also be class=3D"insert" style=3D"background-color: rgb(136, 255, 255); > ">used."
> >
class=3D"Apple-style-span" style=3D"font-size: 11px; white-space: > pre;">
I am now a bit > confused. I think that if len=3D2 then the RFC5285 header is implied? I t= hink > it would be good to make this explicit. Could I use a len=3D2 and have so= me > other level indication?
> >

Other than this, my previous comments have been > addressed.

Regards,

Pe= ter > Musgrave

2011/6/3 DRAGE, Keith > (Keith) < ">keith.drage@alcatel-lucent.com>
> >
#ccc solid;padding-left:1ex;">(As WG co-chair
> >
> > Can people do a rapid check and update their view of whether all open > issues are adequately addressed or not. Are there any new ones?
> >
> > If there are none, we will start WGLC. If they are not, then we will ha= ve > appropriate rounds of discussions to close them.
> >
> > Keith
> >
> > > -----Original Message-----
> > > From: > avtext-bounces@ietf.org [mailto: avtext-bounces@ietf.org">avtext-bounces@ietf.org] On Behalf
> > > Of Emil Ivov
> > > Sent: 02 June 2011 14:19
> > > To: AVTEXT
> > > Subject: Re: [avtext] mixer-to-client audio levels ready (Was: I-D > Action:
> > > draft-ietf-avtext-mixer-to-client-audio-level-02.txt)
> >
>
> > > =CD=E0 09.05.11 12:15, Emil Ivov =ED=E0=EF=E8=F1=E0:
> > > > Hey all,
> > > >
> > > > The authors are confident that all open issues and mailing li= st > comments
> > > > have now been addressed and that this document is now ready t= o > move
> > > forward.
> > > >
> > > > We will be submitting the client-to-mixer draft in the > following days.
> > >
> > > Done. We believe both documents are now ready to move forward.
> > >
> > > Cheers,
> > > Emil
> > >
> > > >
> > > > =CD=E0 09.05.11 12:05, > internet-drafts@ietf.org =ED=E0=EF=E8=F1=E0:
> > > >> A New Internet-Draft is available from the on-line > Internet-Drafts
> > > directories. This draft is a work item of the Audio/Video > Transport
> > > Extensions Working Group of the IETF.
> > > >>
> > > >> Title : A Real-Time Transport Protocol (RTP) > Header
> > > Extension for Mixer-to- Client Audio Level Indication
> > > >> Author(s) : Emil Ivov
> > > >> Enrico Marocco
> > > >> Jonathan Lennox
> > > >> Filename : > draft-ietf-avtext-mixer-to-client-audio-level-
> > > 02.txt
> > > >> Pages : 15
> > > >> Date : 2011-05-09
> > > >>
> > > >> This document describes a mechanism for RTP-level mixe= rs > in audio
> > > >> conferences to deliver information about the audio lev= el > of
> > > >> individual participants. Such audio level indicators > are
> > > transported
> > > >> in the same RTP packets as the audio data they pertain > to.
> > > >>
> > > >>
> > > >> A URL for this Internet-Draft is:
> > > >> http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-" > target=3D"_blank"> > http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client- >
> > > audio-level-02.txt
> > > >>
> > > >> Internet-Drafts are also available by anonymous FTP at: > > > >> target=3D"_blank">ftp://ftp.ietf.org/internet-drafts/
> > > >>
> > > >> This Internet-Draft can be retrieved at:
> > > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-" > target=3D"_blank"> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client- >
> > > audio-level-02.txt
> > > >> _______________________________________________
> > > >> avtext mailing list
> > > >> avtext@ietf.org > > > >> target=3D"_blank">https://www.ietf.org/mailman/listinfo/avtext
> > > >>
> > > >
> > >
> > > --
> > > Emil Ivov, Ph.D. 67000 Strasbourg,
> > > Project Lead France
> > > Jitsi
> > > emcho@jitsi.org > PHONE: > +33.1.77.62.43.30
> > > http://jitsi.org > FAX: +33177624731">+33.1.77.62.47.31
> > >
> > > _______________________________________________
> > > avtext mailing list
> > > avtext@ietf.org
> > > target=3D"_blank">https://www.ietf.org/mailman/listinfo/avtext
> > _______________________________________________
> > avtext mailing list
> > avtext@ietf.org
> > > https://www.ietf.org/mailman/listinfo/avtext
> >

> > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > --20cf3054a8c1ce075004a5139f6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think what you just said would work.=C2=A0

I'll co= nfess I was too lazy to go dig out the reference - and sadly I expect there= are more people just as lazy as me out there...

I= can live with the text as it is. (If I was implementing it I would be less= lazy).=C2=A0

Peter


2011= /6/6 <lenno= x@cs.columbia.edu>
On Sunday, June 5 2011, "Peter Musgrave" wrote to "DRAGE, Ke= ith (Keith), AVTEXT" saying:

> Hi,
>
> Looking through the diffs:
> In section 3 is now the statement "The two-byte header defined in= RFC 5285
> [RFC5285] may also be used."
>
> I am now a bit confused. I think that if len=3D2 then the RFC5285 head= er is
> implied? I think it would be good to make this explicit. Could I use a= len=3D2
> and have some other level indication?
>
> Other than this, my previous comments have been addressed.
>
> Regards,
>
> Peter Musgrave

RFC 5285 has two forms for how it encodes its header extension elemen= ts --
the form with "defined by profile" field 0xBEDE, with a four-bit = ID and
four-bit length; and the form with "defined by profile" field 0x1= 00x, with
eight-bit ID and eight-bit length. =C2=A0The point of this sentence is to m= ake it
clear that although the example uses the 0xBEDE form, the 0x100x form can also be used. =C2=A0It's nothing to do with the actual value that's= encoded in
the "len" field.

Is there alternative wording that would make this clearer?

--
Jonathan Lennox
lennox@cs.columbia.edu / jonathan@vidyo.com

> 2011/6/3 DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com>
>
> > (As WG co-chair
> >
> > Can people do a rapid check and update their view of whether all = open
> > issues are adequately addressed or not. Are there any new ones? > >
> > If there are none, we will start WGLC. If they are not, then we w= ill have
> > appropriate rounds of discussions to close them.
> >
> > Keith
> >
> > > -----Original Message-----
> > > From: avtext-boun= ces@ietf.org [mailto:avtext-= bounces@ietf.org] On Behalf
> > > Of Emil Ivov
> > > Sent: 02 June 2011 14:19
> > > To: AVTEXT
> > > Subject: Re: [avtext] mixer-to-client audio levels ready (Wa= s: I-D
> > Action:
> > > draft-ietf-avtext-mixer-to-client-audio-level-02.txt)
> > >
> > > =D0=9D=D0=B0 09.05.11 12:15, Emil Ivov =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0:
> > > > Hey all,
> > > >
> > > > The authors are confident that all open issues and mail= ing list
> > comments
> > > > have now been addressed and that this document is now r= eady to move
> > > forward.
> > > >
> > > > We will be submitting the client-to-mixer draft in the = following days.
> > >
> > > Done. We believe both documents are now ready to move forwar= d.
> > >
> > > Cheers,
> > > Emil
> > >
> > > >
> > > > =D0=9D=D0=B0 09.05.11 12:05, internet-drafts@ietf.org =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0:
> > > >> A New Internet-Draft is available from the on-line = Internet-Drafts
> > > directories. This draft is a work item of the Audio/Video Tr= ansport
> > > Extensions Working Group of the IETF.
> > > >>
> > > >> =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : A Real-Time Transport Protocol (RTP) Header
> > > Extension for Mixer-to- Client Audio Level Indication
> > > >> =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Emil = Ivov
> > > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Enrico Marocco
> > > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jonathan Lennox
> > > >> =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: = draft-ietf-avtext-mixer-to-client-audio-level-
> > > 02.txt
> > > >> =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 15
> > > >> =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 2011-05-09
> > > >>
> > > >> =C2=A0 =C2=A0This document describes a mechanism fo= r RTP-level mixers in audio
> > > >> =C2=A0 =C2=A0conferences to deliver information abo= ut the audio level of
> > > >> =C2=A0 =C2=A0individual participants. =C2=A0Such au= dio level indicators are
> > > transported
> > > >> =C2=A0 =C2=A0in the same RTP packets as the audio d= ata they pertain to.
> > > >>
> > > >>
> > > >> A URL for this Internet-Draft is:
> > > >>
> > http://www.ietf.org/internet-drafts/dra= ft-ietf-avtext-mixer-to-client-
> > > audio-level-02.txt
> > > >>
> > > >> Internet-Drafts are also available by anonymous FTP= at:
> > > >> ftp://ftp.ietf.org/internet-drafts/
> > > >>
> > > >> This Internet-Draft can be retrieved at:
> > > >> ftp://ftp.ietf.org/interne= t-drafts/draft-ietf-avtext-mixer-to-client-
> > > audio-level-02.txt
> > > >> _______________________________________________
> > > >> avtext mailing list
> > > >> avtext@ietf.org<= /a>
> > > >> https://www.ietf.org/mailman/listinfo/avtext > > > >>
> > > >
> > >
> > > --
> > > Emil Ivov, Ph.D. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 67000 Strasbourg,
> > > Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 France
> > > Jitsi
> > > emcho@jitsi.org =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0PHONE: +33= .1.77.62.43.30
> > > http://jitsi.= org =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 FAX: =C2=A0 +33.1.77.62.47.31
> > >
> > > _______________________________________________
> > > avtext mailing list
> > > avtext@ietf.org
> > > https://www.ietf.org/mailman/listinfo/avtext
> > _______________________________________________
> > avtext mailing list
> > avtext@ietf.org
> > https://www.ietf.org/mailman/listinfo/avtext
> >
> Hi,=C2=A0<div><br></div><div>Looki= ng through the diffs:</div><div>In section 3 is now the stateme= nt &quot;<span class=3D"Apple-style-span" style=3D"fo= nt-family: monospace; font-size: 11px; white-space: pre; ">The <= span class=3D"insert" style=3D"background-color: rgb(136, 25= 5, 255); ">two-byte header</span> defined in <span class= =3D"insert" style=3D"background-color: rgb(136, 255, 255); &= quot;>RFC 5285 [RFC5285] may also</span> be <span class=3D"= ;insert" style=3D"background-color: rgb(136, 255, 255); ">= ;used.&quot;</span></span></div>
> <div><font class=3D"Apple-style-span" face=3D"= monospace"><span class=3D"Apple-style-span" style=3D&q= uot;font-size: 11px; white-space: pre;"><br></span><= /font></div><div><meta charset=3D"utf-8">I a= m now a bit confused. I think that if len=3D2 then the RFC5285 header is im= plied? I think it would be good to make this explicit. Could I use a len=3D= 2 and have some other level indication?</div>
> <div><br></div><div>Other than this, my previo= us comments have been addressed.</div><div><br></div&g= t;<div>Regards,=C2=A0</div><div><br></div><= ;div>Peter Musgrave</div><div><br><div class=3D&quo= t;gmail_quote">2011/6/3 DRAGE, Keith (Keith) <span dir=3D"l= tr">&lt;<a href=3D"mailto:keith.drage@alcatel-lucent.com">keith.drage@alcatel-lucent.com&= lt;/a>&gt;</span><br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">(As WG co-ch= air<br>
> <br>
> Can people do a rapid check and update their view of whether all open = issues are adequately addressed or not. Are there any new ones?<br> > <br>
> If there are none, we will start WGLC. If they are not, then we will h= ave appropriate rounds of discussions to close them.<br>
> <br>
> Keith<br>
> <br>
> &gt; -----Original Message-----<br>
> &gt; From: <a href=3D"mailto:avtext-bounces@ietf.org">avtext-bounces@ietf.org</a> [mailto:<a href= =3D"mailto:avtext-bounces@i= etf.org">avtext-boun= ces@ietf.org</a>] On Behalf<br>
> &gt; Of Emil Ivov<br>
> &gt; Sent: 02 June 2011 14:19<br>
> &gt; To: AVTEXT<br>
> &gt; Subject: Re: [avtext] mixer-to-client audio levels ready (Was= : I-D Action:<br>
> &gt; draft-ietf-avtext-mixer-to-client-audio-level-02.txt)<br&g= t;
> <div><div></div><div class=3D"h5">&a= mp;gt;<br>
> &gt; =D0=9D=D0=B0 09.05.11 12:15, Emil Ivov =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0:<br>
> &gt; &gt; Hey all,<br>
> &gt; &gt;<br>
> &gt; &gt; The authors are confident that all open issues and m= ailing list comments<br>
> &gt; &gt; have now been addressed and that this document is no= w ready to move<br>
> &gt; forward.<br>
> &gt; &gt;<br>
> &gt; &gt; We will be submitting the client-to-mixer draft in t= he following days.<br>
> &gt;<br>
> &gt; Done. We believe both documents are now ready to move forward= .<br>
> &gt;<br>
> &gt; Cheers,<br>
> &gt; Emil<br>
> &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; =D0=9D=D0=B0 09.05.11 12:05, <a href=3D"mail= to:internet-drafts@ietf.org= ">internet-drafts@ietf.= org</a> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<br>
> &gt; &gt;&gt; A New Internet-Draft is available from the o= n-line Internet-Drafts<br>
> &gt; directories. This draft is a work item of the Audio/Video Tra= nsport<br>
> &gt; Extensions Working Group of the IETF.<br>
> &gt; &gt;&gt;<br>
> &gt; &gt;&gt; =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : A Real-Time Transport Protocol (RTP) Header<br>
> &gt; Extension for Mixer-to- Client Audio Level Indication<br&g= t;
> &gt; &gt;&gt; =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 = : Emil Ivov<br>
> &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Enrico Marocco<br> > &gt; &gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jonathan Lennox<br><= br> > &gt; &gt;&gt; =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 = =C2=A0: draft-ietf-avtext-mixer-to-client-audio-level-<br>
> &gt; 02.txt<br>
> &gt; &gt;&gt; =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 15<br>
> &gt; &gt;&gt; =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: 2011-05-09<br>
> &gt; &gt;&gt;<br>
> &gt; &gt;&gt; =C2=A0 =C2=A0This document describes a mecha= nism for RTP-level mixers in audio<br>
> &gt; &gt;&gt; =C2=A0 =C2=A0conferences to deliver informat= ion about the audio level of<br>
> &gt; &gt;&gt; =C2=A0 =C2=A0individual participants. =C2=A0= Such audio level indicators are<br>
> &gt; transported<br>
> &gt; &gt;&gt; =C2=A0 =C2=A0in the same RTP packets as the = audio data they pertain to.<br>
> &gt; &gt;&gt;<br>
> &gt; &gt;&gt;<br>
> &gt; &gt;&gt; A URL for this Internet-Draft is:<br><= br> > &gt; &gt;&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-= " target=3D"_blank">http://www.= ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-</a>&l= t;br>
> &gt; audio-level-02.txt<br>
> &gt; &gt;&gt;<br>
> &gt; &gt;&gt; Internet-Drafts are also available by anonym= ous FTP at:<br>
> &gt; &gt;&gt; <a href=3D"ftp://ftp.ietf.org/internet-drafts= /" target=3D"_blank">ftp://ftp.ietf.org/internet-drafts/&l= t;/a><br>
> &gt; &gt;&gt;<br>
> &gt; &gt;&gt; This Internet-Draft can be retrieved at:<= br>
> &gt; &gt;&gt; <a href=3D"= ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-&q= uot; target=3D"_blank">ftp://ftp.ietf= .org/internet-drafts/draft-ietf-avtext-mixer-to-client-</a><br= >
> &gt; audio-level-02.txt<br>
> &gt; &gt;&gt; ____________________________________________= ___<br>
> &gt; &gt;&gt; avtext mailing list<br>
> &gt; &gt;&gt; <a href=3D"mailto:avtext@ietf.org">avtext@ietf.org</a><br>
> &gt; &gt;&gt; <a href=3D"https://www.ietf.org/mail= man/listinfo/avtext" target=3D"_blank">https://www.ie= tf.org/mailman/listinfo/avtext</a><br>
> &gt; &gt;&gt;<br>
> &gt; &gt;<br>
> &gt;<br>
> &gt; --<br>
> &gt; Emil Ivov, Ph.D. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 67000 Strasbourg,<br>
> &gt; Project Lead =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 France<br>
> &gt; Jitsi<br>
> &gt; <a href=3D"mailto:= emcho@jitsi.org">emcho@jitsi= .org</a> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0PHONE: <a href=3D"tel:%2B33.1.77.62.43.3= 0" value=3D"+33177624330">+33.1.77.62.43.30</a><br>
> &gt; <a href=3D"http://jitsi.org" target=3D"_blank">http://jitsi.org</a> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 FAX: = =C2=A0 <a href=3D"tel:%2B33.1.77.62.47.31" value=3D"+33177624731">= +33.1.77.62.47.3= 1</a><br>
> &gt;<br>
> &gt; _______________________________________________<br>
> &gt; avtext mailing list<br>
> &gt; <a href=3D"mailto:= avtext@ietf.org">avtext@ietf= .org</a><br>
> &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/avte= xt" target=3D"_blank">https://www.ietf.org/mailman/li= stinfo/avtext</a><br>
> _______________________________________________<br>
> avtext mailing list<br>
> <a href=3D"mailto:avtext@ie= tf.org">avtext@ietf.org&= lt;/a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/avtext&qu= ot; target=3D"_blank">https://www.ietf.org/mailman/listinfo/av= text</a><br>
> </div></div></blockquote></div><br></= div>
> ____________________________________= ___________
> avtext mailing list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext

--20cf3054a8c1ce075004a5139f6b-- From internet-drafts@ietf.org Tue Jun 7 00:35:30 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E5A21F856D; Tue, 7 Jun 2011 00:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pI1Mvw4XiiIQ; Tue, 7 Jun 2011 00:35:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CB721F8441; Tue, 7 Jun 2011 00:35:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110607073530.16031.92596.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2011 00:35:30 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-multiple-clock-rates-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 07:35:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : Support for multiple clock rates in an RTP session Author(s) : Marc Petit-Huguenin Filename : draft-ietf-avtext-multiple-clock-rates-00.txt Pages : 10 Date : 2011-06-01 This document clarifies the RTP specification when different clock rates are used in an RTP session. It also provides guidance on how to interoperate with legacy RTP implementations that use multiple clock rates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-= 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-multiple-clock-rates-0= 0.txt From iesg-secretary@ietf.org Wed Jun 8 08:36:22 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729D811E813C; Wed, 8 Jun 2011 08:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk8KgwrP6K+j; Wed, 8 Jun 2011 08:36:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F04C11E8141; Wed, 8 Jun 2011 08:36:21 -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: 3.55 Message-ID: <20110608153621.23408.6943.idtracker@ietfa.amsl.com> Date: Wed, 08 Jun 2011 08:36:21 -0700 Cc: avtext mailing list , avtext chair , RFC Editor Subject: [avtext] Protocol Action: 'Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)' to Proposed Standard (draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 15:36:22 -0000 The IESG has approved the following document: - 'Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)' (draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Extensions Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr/ Technical Summary In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one ore more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver can do a simple multicast join (in other cases it is compelled to do so). For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). Working Group Summary There was nothing contentious about this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? At the moment the shepherd is not aware of any protocol implementations, and no vendors have directly indicated they plan to implement, although he assumes that all RAMs implementations will ultimately include this, as it is essentially a mandatory part of RAMs. The reviewers are listed elsewhere in the PROTO writeup. There were no external reviews of the types mentioned, because there is no material requiring such review. Personnel Keith Drage is the document shepherd Gonzalo Camarillo is the responsible area director. From keith.drage@alcatel-lucent.com Fri Jun 10 04:09:22 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2784022800A for ; Fri, 10 Jun 2011 04:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.249 X-Spam-Level: X-Spam-Status: No, score=-105.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkmD1bQHt5ff for ; Fri, 10 Jun 2011 04:09:21 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id CA2FA228007 for ; Fri, 10 Jun 2011 04:09:18 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5AB99s3028949 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 10 Jun 2011 13:09:17 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 10 Jun 2011 13:09:04 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Fri, 10 Jun 2011 13:09:00 +0200 Thread-Topic: Any forthcoming new drafts Thread-Index: AcwnXsy4yRMNWN2lRoyqS3i1+ODXqg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [avtext] Any forthcoming new drafts X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:09:22 -0000 (As WG chair) As we are starting to get to the point of thinking about Quebec, it would b= e useful for the chairs to know about any forthcoming new author drafts you= intend to submit. If you have such plans, then please send a mail to the c= hairs giving us a rough idea of the intent. And please remember, also actually submitting the new draft is always bette= r performed earlier rather than later. Regards Keith From keith.drage@alcatel-lucent.com Fri Jun 10 04:10:11 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9527511E807B for ; Fri, 10 Jun 2011 04:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amsqC2m-puLv for ; Fri, 10 Jun 2011 04:10:10 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id B1358228008 for ; Fri, 10 Jun 2011 04:10:08 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5AB9xBI030339 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 10 Jun 2011 13:10:00 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 10 Jun 2011 13:10:00 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Fri, 10 Jun 2011 13:09:58 +0200 Thread-Topic: draft-williams-avtext-avbsync Thread-Index: AcwnXu+ZzniHwNxUSPKfF2BH0CF6Lw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [avtext] draft-williams-avtext-avbsync X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:10:11 -0000 (As WG cochair) The following author draft defines an RTP header extension https://datatracker.ietf.org/doc/draft-williams-avtext-avbsync/ Apart from a request for agenda time at the last meeting, there has not bee= n any discussion on the document. Q1: To the authors. Are you intending proceeding with this document. Is the= document still the direction you wish to go or do you have other ideas. Q2: To the WG. Is this document reasonable or heading in entirely the wrong= direction. Regards Keith From magnus.westerlund@ericsson.com Fri Jun 10 04:17:09 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397A911E80B8 for ; Fri, 10 Jun 2011 04:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nss6Y7nrf9Qh for ; Fri, 10 Jun 2011 04:17:08 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C10AD11E807E for ; Fri, 10 Jun 2011 04:17:07 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-37-4df1fd324a95 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0B.57.20773.23DF1FD4; Fri, 10 Jun 2011 13:17:06 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Fri, 10 Jun 2011 13:17:06 +0200 Message-ID: <4DF1FD31.6050906@ericsson.com> Date: Fri, 10 Jun 2011 13:17:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: avtext@ietf.org References: <4D78F240.8000002@ericsson.com> In-Reply-To: <4D78F240.8000002@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [avtext] WG adaptation of ID for Considerations for RAMS Scenarios X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:17:09 -0000 Hi, There has been some confusion around the adoption of the draft for the milestone below. This call was left hanging. But it is clear that there are no competitive draft for this milestone. So we WG chairs hereby declare draft-begen-avtext-rams-scenarios as adopted as WG item. Author, please submit a WG item draft. Regards Magnus On 2011-03-10 16:46, Magnus Westerlund wrote: > The WG has a milestone: > > Jun 2011 Submit Considerations for RAMS Scenarios for Informational > > To the WG chairs knowledge the only source material we have to meet this > milestone is the following individual draft: > > https://datatracker.ietf.org/doc/draft-begen-avtext-rams-scenarios/ > > This is a WG consensus call to adopt the above Internet Draft as > baseline text for this milestone. At this stage the text does not have > to be regarded perfect, the question is more "Does this text form a > better basis for completing the work in the working group that some text > yet to be submitted?" > > While the prime intention of this call is to adopt the entire text of > the individual draft, if you consider that some of the text is > appropriate, but that some of the text does not form a reasonable start > for the work, then please indicate that text and we will make a separate > call on it (and adopt the rest). > > Please respond by Sunday 27th of March 2011 with your positions. > > Best Regards > > Magnus Westerlund > AVTExt Chair > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Fri Jun 10 08:29:49 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180D611E81E6; Fri, 10 Jun 2011 08:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqI2peOSQVVy; Fri, 10 Jun 2011 08:29:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321C611E8107; Fri, 10 Jun 2011 08:29:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110610152948.26861.38539.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2011 08:29:48 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rams-scenarios-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 15:29:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : Considerations and Guidelines for Deploying the Rapid Ac= quisition of Multicast RTP Sessions (RAMS) Method Author(s) : Ali Begen Filename : draft-ietf-avtext-rams-scenarios-00.txt Pages : 11 Date : 2011-06-10 The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be taken to configure each RAMS session appropriately. This document provides example scenarios and offers guidelines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-rams-scenarios-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-rams-scenarios-00.txt From magnus.westerlund@ericsson.com Fri Jun 10 09:00:09 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F397011E8136 for ; Fri, 10 Jun 2011 09:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Sub57g+2QKT for ; Fri, 10 Jun 2011 09:00:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 63E0611E8201 for ; Fri, 10 Jun 2011 09:00:06 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-df-4df23f850f90 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 88.A6.20773.58F32FD4; Fri, 10 Jun 2011 18:00:05 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Fri, 10 Jun 2011 18:00:01 +0200 Message-ID: <4DF23F7E.2070903@ericsson.com> Date: Fri, 10 Jun 2011 17:59:58 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "avtext@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 16:00:09 -0000 Hi, We have had this ongoing discussion on the mailing list around the RTP Splicing and the pro-and-cons for two major solutions. To try to get to some decision on what the WG should focus on I would like to ask the WG to indicate their preference for what should be done here. The options are three on a high level. And this is for an informational document that explains how you use the existing RTP features to accomplish splicing. A) Focus only on RTP Translator based solution B) Focus only on RTP Mixer based solution C) Define both Mixer and Translator based solutions. A) is pretty well described in the individual draft: https://datatracker.ietf.org/doc/draft-xia-avtext-splicing-for-rtp/ The trade-offs and limiations of A and B has been fairly well discussed in the following email list discussion. http://www.ietf.org/mail-archive/web/avtext/current/msg00046.html So if you aren't familiar with the topic already please review the above and then indicate your position no later than the 26th of June. Independently of the choice that solution will have to discuss the pros and cons of that method and what properties it has. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From daveoran@orandom.net Sat Jun 11 07:33:46 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF1811E80B0 for ; Sat, 11 Jun 2011 07:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr8H0YZCMXmz for ; Sat, 11 Jun 2011 07:33:45 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2001:470:d:21b:3c00::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC311E80A1 for ; Sat, 11 Jun 2011 07:33:45 -0700 (PDT) Received: from [10.32.245.150] (c-24-62-229-193.hsd1.ma.comcast.net [24.62.229.193]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5BEXekl013132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jun 2011 07:33:42 -0700 Mime-Version: 1.0 (Apple Message framework v1237.1) Content-Type: text/plain; charset=us-ascii From: David R Oran In-Reply-To: Date: Sat, 11 Jun 2011 10:33:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <84599674-1BB4-4425-82B2-02C34E46232E@orandom.net> References: To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1237.1) Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-williams-avtext-avbsync X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 14:33:46 -0000 On Jun 10, 2011, at 7:09 AM, DRAGE, Keith (Keith) wrote: > (As WG cochair) >=20 > The following author draft defines an RTP header extension >=20 > https://datatracker.ietf.org/doc/draft-williams-avtext-avbsync/ >=20 > Apart from a request for agenda time at the last meeting, there has = not been any discussion on the document. >=20 >=20 > Q1: To the authors. Are you intending proceeding with this document. = Is the document still the direction you wish to go or do you have other = ideas. >=20 > Q2: To the WG. Is this document reasonable or heading in entirely the = wrong direction. >=20 Three thoughts: a) I don't get it. Just because the RTP wall clock is in NTP time format = doesn't mean that time could not have been synchronized to the accuracy = of an IEEE 1588 clock using those protocols to compute/adjust it as = opposed to or as augmentation of IEEE 1588. b) how can you tell whether or not the RTP session has both endpoints = within the scope/domain of a single instance of the AVB synchronization = protocol? c) We should ask the TICTOC working group for their opinions before = considering adoption. Thanks, DaveO. > Regards >=20 > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From gwz@net-zen.net Sat Jun 11 16:46:46 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95FD11E809D for ; Sat, 11 Jun 2011 16:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG+WtdXHQzSa for ; Sat, 11 Jun 2011 16:46:46 -0700 (PDT) Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by ietfa.amsl.com (Postfix) with SMTP id 2577F11E8097 for ; Sat, 11 Jun 2011 16:46:46 -0700 (PDT) Received: (qmail 12014 invoked from network); 11 Jun 2011 23:46:45 -0000 Received: from unknown (124.120.1.237) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 11 Jun 2011 23:46:44 -0000 Message-ID: <4DF3FE5E.4010705@net-zen.net> Date: Sun, 12 Jun 2011 06:46:38 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: David R Oran References: <84599674-1BB4-4425-82B2-02C34E46232E@orandom.net> In-Reply-To: <84599674-1BB4-4425-82B2-02C34E46232E@orandom.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------040906060307000708080300" Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-williams-avtext-avbsync X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 23:46:46 -0000 This is a multi-part message in MIME format. --------------040906060307000708080300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 6/11/2011 9:33 PM, David R Oran wrote: > > On Jun 10, 2011, at 7:09 AM, DRAGE, Keith (Keith) wrote: > >> (As WG cochair) >> >> The following author draft defines an RTP header extension >> >> https://datatracker.ietf.org/doc/draft-williams-avtext-avbsync/ >> >> Apart from a request for agenda time at the last meeting, there has not been any discussion on the document. >> >> >> Q1: To the authors. Are you intending proceeding with this document. Is the document still the direction you wish to go or do you have other ideas. >> >> Q2: To the WG. Is this document reasonable or heading in entirely the wrong direction. >> > Three thoughts: > > a) I don't get it. Just because the RTP wall clock is in NTP time format doesn't mean that time could not have been synchronized to the accuracy of an IEEE 1588 clock using those protocols to compute/adjust it as opposed to or as augmentation of IEEE 1588. True. > > b) how can you tell whether or not the RTP session has both endpoints within the scope/domain of a single instance of the AVB synchronization protocol? Why does it matter? > > c) We should ask the TICTOC working group for their opinions before considering adoption. Probably a good idea. ... --------------040906060307000708080300 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------040906060307000708080300-- From daveoran@orandom.net Sun Jun 12 06:00:33 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5043D11E807D for ; Sun, 12 Jun 2011 06:00:33 -0700 (PDT) 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=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIYt9WmmK7EF for ; Sun, 12 Jun 2011 06:00:32 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2001:470:d:21b:3c00::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6758711E807B for ; Sun, 12 Jun 2011 06:00:32 -0700 (PDT) Received: from [192.168.15.139] (c-24-62-229-30.hsd1.ma.comcast.net [24.62.229.30]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5CD0L0i030352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Jun 2011 06:00:25 -0700 References: <84599674-1BB4-4425-82B2-02C34E46232E@orandom.net> <4DF3FE5E.4010705@net-zen.net> In-Reply-To: <4DF3FE5E.4010705@net-zen.net> Mime-Version: 1.0 (iPad Mail 8J3) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <75D31691-E30E-4C56-B597-BE715DC6472B@orandom.net> X-Mailer: iPad Mail (8J3) From: David Oran Date: Sun, 12 Jun 2011 06:00:44 -0700 To: Glen Zorn Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-williams-avtext-avbsync X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 13:00:33 -0000 Answering your question below. On Jun 11, 2011, at 4:46 PM, Glen Zorn wrote: > On 6/11/2011 9:33 PM, David R Oran wrote: >=20 >>=20 >> On Jun 10, 2011, at 7:09 AM, DRAGE, Keith (Keith) wrote: >>=20 >>> (As WG cochair) >>>=20 >>> The following author draft defines an RTP header extension >>>=20 >>> https://datatracker.ietf.org/doc/draft-williams-avtext-avbsync/ >>>=20 >>> Apart from a request for agenda time at the last meeting, there has not b= een any discussion on the document. >>>=20 >>>=20 >>> Q1: To the authors. Are you intending proceeding with this document. Is t= he document still the direction you wish to go or do you have other ideas. >>>=20 >>> Q2: To the WG. Is this document reasonable or heading in entirely the wr= ong direction. >>>=20 >> Three thoughts: >>=20 >> a) I don't get it. Just because the RTP wall clock is in NTP time format d= oesn't mean that time could not have been synchronized to the accuracy of an= IEEE 1588 clock using those protocols to compute/adjust it as opposed to or= as augmentation of IEEE 1588. >=20 > True. >=20 >>=20 >> b) how can you tell whether or not the RTP session has both endpoints wit= hin the scope/domain of a single instance of the AVB synchronization protoco= l? >=20 > Why does it matter? >=20 If you are using the wall clocks for some purpose that actually depends on t= he Avb time properties, then you also probably also depend on the two or mor= e RTP endpoints actually residing within the same scope that the protocol is= running in. Since the Avb protocol runs at L2 and RTP at L4+, you would nee= d some outside knowledge to figure this out that is not in RTP, or SDP. For example, if you don't run NTP at all, it's perfectly possible for two in= stances of the AVB synch protocol running on LANs opposite sides of the plan= et having time bases that are skewed by an arbitrary amount. That wouldn't m= atter to applications confined to a single extended LAN, but clearly matters= over a wider scope like that of RTP applications. Make sense? >>=20 >> c) We should ask the TICTOC working group for their opinions before consi= dering adoption. >=20 > Probably a good idea. >=20 > ... > From xiajinwei@huawei.com Sun Jun 12 18:59:47 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81B01F0C50 for ; Sun, 12 Jun 2011 18:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLagzlUTrouc for ; Sun, 12 Jun 2011 18:59:47 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF881F0C4A for ; Sun, 12 Jun 2011 18:59:47 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMP003OFHJMBH@szxga03-in.huawei.com> for avtext@ietf.org; Mon, 13 Jun 2011 09:59:46 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMP008VJHJMXI@szxga03-in.huawei.com> for avtext@ietf.org; Mon, 13 Jun 2011 09:59:46 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 13 Jun 2011 09:59:43 +0800 Received: from x65217 (10.138.41.84) by smtpscn.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 13 Jun 2011 09:59:45 +0800 Date: Mon, 13 Jun 2011 09:59:51 +0800 From: Jinwei Xia In-reply-to: <4DF23F7E.2070903@ericsson.com> X-Originating-IP: [10.138.41.84] To: 'Magnus Westerlund' , avtext@ietf.org Message-id: <008001cc296d$9746b7b0$54298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acwnh35NUX627rdIQy+Wjliq6UP/zgB44MEg Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 01:59:47 -0000 Hi Chair, Thank you for activing the item, I prefer to use translator for user minimal-detectable case, i.e., option A. The reason is mixer may get = DoS attack once its address is exposed for some vicious users. I will update the new version ASAP according to the conclusion of this thread. Thank you Jinwei > -----Original Message----- > From: avtext-bounces@ietf.org=20 > [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus Westerlund > Sent: Saturday, June 11, 2011 12:00 AM > To: avtext@ietf.org > Subject: [avtext] Consensus call on RTP Splicing direction forward >=20 > Hi, >=20 > We have had this ongoing discussion on the mailing list=20 > around the RTP Splicing and the pro-and-cons for two major=20 > solutions. To try to get to some decision on what the WG=20 > should focus on I would like to ask the WG to indicate their=20 > preference for what should be done here. The options are=20 > three on a high level. And this is for an informational=20 > document that explains how you use the existing RTP features=20 > to accomplish splicing. >=20 > A) Focus only on RTP Translator based solution >=20 > B) Focus only on RTP Mixer based solution >=20 > C) Define both Mixer and Translator based solutions. >=20 > A) is pretty well described in the individual draft: > https://datatracker.ietf.org/doc/draft-xia-avtext-splicing-for-rtp/ >=20 > The trade-offs and limiations of A and B has been fairly well=20 > discussed in the following email list discussion. > http://www.ietf.org/mail-archive/web/avtext/current/msg00046.html >=20 > So if you aren't familiar with the topic already please=20 > review the above and then indicate your position no later=20 > than the 26th of June. >=20 > Independently of the choice that solution will have to=20 > discuss the pros and cons of that method and what properties it has. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From kevin.gross@comcast.net Sun Jun 12 20:33:58 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046A8228005 for ; Sun, 12 Jun 2011 20:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzRcyRbkXPBQ for ; Sun, 12 Jun 2011 20:33:57 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 53CBB228008 for ; Sun, 12 Jun 2011 20:33:57 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta02.westchester.pa.mail.comcast.net with comcast id vFXT1g0021c6gX852FZxZn; Mon, 13 Jun 2011 03:33:57 +0000 Received: from AVADesk2 ([76.120.76.232]) by omta23.westchester.pa.mail.comcast.net with comcast id vFZw1g00l50jATQ3jFZxcK; Mon, 13 Jun 2011 03:33:57 +0000 From: "Kevin Gross" To: References: <4DF23F7E.2070903@ericsson.com> In-Reply-To: <4DF23F7E.2070903@ericsson.com> Date: Sun, 12 Jun 2011 21:33:54 -0600 Organization: AVA Networks Message-ID: <002f01cc297a$b8e0c930$2aa25b90$@gross@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acwnh4MSiOa03lhWToO/+O0vtQttxAB8WIsQ Content-Language: en-us Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 03:33:58 -0000 I've reviewed the e-mails. I'm not certain I have a good grasp on the = issue. It appears the mixer (A) is the straightforward implementation. Why not = go with that? The arguments for B or C seem to center around delectability. = Detectability seems to be slippery. If delectability is a concern, couldn't you just insert, after the splicer, a translator with obfuscation level = appropriate for the application? Kevin Gross -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf = Of Magnus Westerlund Sent: Friday, June 10, 2011 10:00 AM To: avtext@ietf.org Subject: [avtext] Consensus call on RTP Splicing direction forward Hi, We have had this ongoing discussion on the mailing list around the RTP Splicing and the pro-and-cons for two major solutions. To try to get to some decision on what the WG should focus on I would like to ask the WG to indicate their preference for what should be done here. The options are three on a high level. And this is for an informational document that explains how you use the existing RTP features to accomplish = splicing. A) Focus only on RTP Translator based solution B) Focus only on RTP Mixer based solution C) Define both Mixer and Translator based solutions. A) is pretty well described in the individual draft: https://datatracker.ietf.org/doc/draft-xia-avtext-splicing-for-rtp/ The trade-offs and limiations of A and B has been fairly well discussed in the following email list discussion. http://www.ietf.org/mail-archive/web/avtext/current/msg00046.html So if you aren't familiar with the topic already please review the above and then indicate your position no later than the 26th of June. Independently of the choice that solution will have to discuss the pros and cons of that method and what properties it has. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From kevin.gross@comcast.net Sun Jun 12 20:43:07 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E452F9E8004 for ; Sun, 12 Jun 2011 20:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByJIQoyrdN3c for ; Sun, 12 Jun 2011 20:43:07 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 08B6C1F0C3B for ; Sun, 12 Jun 2011 20:43:06 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id vFZ31g0040QuhwU5DFj7hi; Mon, 13 Jun 2011 03:43:07 +0000 Received: from AVADesk2 ([76.120.76.232]) by omta02.westchester.pa.mail.comcast.net with comcast id vFj61g00950jATQ3NFj6MX; Mon, 13 Jun 2011 03:43:07 +0000 From: "Kevin Gross" To: References: <84599674-1BB4-4425-82B2-02C34E46232E@orandom.net> <4DF3FE5E.4010705@net-zen.net> <75D31691-E30E-4C56-B597-BE715DC6472B@orandom.net> In-Reply-To: <75D31691-E30E-4C56-B597-BE715DC6472B@orandom.net> Date: Sun, 12 Jun 2011 21:43:03 -0600 Organization: AVA Networks Message-ID: <003301cc297c$0082aff0$01880fd0$@gross@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwpALddDKjJhVa8S7uPveflK6SEyQAemIEw Content-Language: en-us Subject: Re: [avtext] draft-williams-avtext-avbsync X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 03:43:08 -0000 The draft text is perhaps missing some crucial justification. Point (a) below does need to be addressed. The answer on point (b) is that there is a globally unique 80-bit gmIdentity field in the RTCP packet used by the AVB transport (see section 4 of this draft). Observing this will tell you whether you're dealing with the same or different clock domain. Kevin Gross -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of David Oran Sent: Sunday, June 12, 2011 7:01 AM To: Glen Zorn Cc: avtext@ietf.org Subject: Re: [avtext] draft-williams-avtext-avbsync Answering your question below. On Jun 11, 2011, at 4:46 PM, Glen Zorn wrote: > On 6/11/2011 9:33 PM, David R Oran wrote: > >> >> On Jun 10, 2011, at 7:09 AM, DRAGE, Keith (Keith) wrote: >> >>> (As WG cochair) >>> >>> The following author draft defines an RTP header extension >>> >>> https://datatracker.ietf.org/doc/draft-williams-avtext-avbsync/ >>> >>> Apart from a request for agenda time at the last meeting, there has not been any discussion on the document. >>> >>> >>> Q1: To the authors. Are you intending proceeding with this document. Is the document still the direction you wish to go or do you have other ideas. >>> >>> Q2: To the WG. Is this document reasonable or heading in entirely the wrong direction. >>> >> Three thoughts: >> >> a) I don't get it. Just because the RTP wall clock is in NTP time format doesn't mean that time could not have been synchronized to the accuracy of an IEEE 1588 clock using those protocols to compute/adjust it as opposed to or as augmentation of IEEE 1588. > > True. > >> >> b) how can you tell whether or not the RTP session has both endpoints within the scope/domain of a single instance of the AVB synchronization protocol? > > Why does it matter? > If you are using the wall clocks for some purpose that actually depends on the Avb time properties, then you also probably also depend on the two or more RTP endpoints actually residing within the same scope that the protocol is running in. Since the Avb protocol runs at L2 and RTP at L4+, you would need some outside knowledge to figure this out that is not in RTP, or SDP. For example, if you don't run NTP at all, it's perfectly possible for two instances of the AVB synch protocol running on LANs opposite sides of the planet having time bases that are skewed by an arbitrary amount. That wouldn't matter to applications confined to a single extended LAN, but clearly matters over a wider scope like that of RTP applications. Make sense? >> >> c) We should ask the TICTOC working group for their opinions before considering adoption. > > Probably a good idea. > > ... > _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From csp@csperkins.org Mon Jun 13 04:06:40 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1E011E80B7 for ; Mon, 13 Jun 2011 04:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX6KwXQL9QKI for ; Mon, 13 Jun 2011 04:06:39 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7E97411E8075 for ; Mon, 13 Jun 2011 04:06:39 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QW4wt-0004l9-ko; Mon, 13 Jun 2011 11:04:51 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DF23F7E.2070903@ericsson.com> Date: Mon, 13 Jun 2011 12:04:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3D43C69A-6B46-48EA-BC4D-7AD3AD61C68C@csperkins.org> References: <4DF23F7E.2070903@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "avtext@ietf.org" Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 11:06:40 -0000 Hi, On 10 Jun 2011, at 16:59, Magnus Westerlund wrote: > We have had this ongoing discussion on the mailing list around the RTP = Splicing and the pro-and-cons for two major solutions. To try to get to = some decision on what the WG should focus on I would like to ask the WG = to indicate their preference for what should be done here. The options = are three on a high level. And this is for an informational document = that explains how you use the existing RTP features to accomplish = splicing. >=20 > A) Focus only on RTP Translator based solution >=20 > B) Focus only on RTP Mixer based solution >=20 > C) Define both Mixer and Translator based solutions. >=20 > A) is pretty well described in the individual draft: > https://datatracker.ietf.org/doc/draft-xia-avtext-splicing-for-rtp/ >=20 > The trade-offs and limiations of A and B has been fairly well = discussed in the following email list discussion. > http://www.ietf.org/mail-archive/web/avtext/current/msg00046.html >=20 > So if you aren't familiar with the topic already please review the = above and then indicate your position no later than the 26th of June. I'm not convinced this is the right question to ask. A better question = might focus on the requirement rather than the solution: do we describe = how to do splicing in a way that's not detectable by the receiver, or in = a way that allows the receiver to tell that content has been spliced in? --=20 Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Mon Jun 13 04:16:52 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F8C11E8075 for ; Mon, 13 Jun 2011 04:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBZVcGE2XWGN for ; Mon, 13 Jun 2011 04:16:52 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 142DC11E80AF for ; Mon, 13 Jun 2011 04:16:51 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-5c-4df5f1a2ad5c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B3.21.20773.2A1F5FD4; Mon, 13 Jun 2011 13:16:51 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 13 Jun 2011 13:16:50 +0200 Message-ID: <4DF5F1A2.5040801@ericsson.com> Date: Mon, 13 Jun 2011 13:16:50 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Colin Perkins References: <4DF23F7E.2070903@ericsson.com> <3D43C69A-6B46-48EA-BC4D-7AD3AD61C68C@csperkins.org> In-Reply-To: <3D43C69A-6B46-48EA-BC4D-7AD3AD61C68C@csperkins.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 11:16:53 -0000 On 2011-06-13 13:04, Colin Perkins wrote: > > I'm not convinced this is the right question to ask. A better > question might focus on the requirement rather than the solution: do > we describe how to do splicing in a way that's not detectable by the > receiver, or in a way that allows the receiver to tell that content > has been spliced in? > Maybe, but my understanding from the discussion is that unless one does media-transcoding, then it will be always possible to detect the splice. Yes it can be difficult and need to include media cues and not 100% accurate. But pretty well. So the question regarding requirements one can ask is on the level of: 1) Clearly detectable in RTP 2) Likely not detectable in RTP level And I think both A and B from the original question can accomplish either of these. Thus, for the question of what track to aim I don't see it as crucial question. For what the draft in the end contains, it is a very important question. But I would prefer to take one question at a time. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jun 13 06:07:44 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28A521F84FC for ; Mon, 13 Jun 2011 06:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFdfopYtae-R for ; Mon, 13 Jun 2011 06:07:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0371A21F84FB for ; Mon, 13 Jun 2011 06:07:43 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-50-4df60b9edbc7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 55.B1.20773.E9B06FD4; Mon, 13 Jun 2011 15:07:43 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 13 Jun 2011 15:07:42 +0200 Message-ID: <4DF60B9E.90909@ericsson.com> Date: Mon, 13 Jun 2011 15:07:42 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "avtext@ietf.org" References: <20110607073530.16031.92596.idtracker@ietfa.amsl.com> In-Reply-To: <20110607073530.16031.92596.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] Comments on draft-ietf-avtext-multiple-clock-rates-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 13:07:45 -0000 Hi, I have reviewed this WG 00 version, and thanks the other for taking my comments into consideration in the previous version. I have some additional comments and suggestions for improvements. However I think it is important that we get input from the WG on these questions. The below are my views as an individual, not WG chair. 1. Section 1: "This document first tries to list in Section 2 and subsections all the various algorithms used by existing RTP implementations." Wouldn't it better to state that this section "lists all known algorithms used in RTP implementations of the time of writing." Or something like this. To avoid using "all" without a qualifier. 2. Section 4.1: > Each time the clock rate changes, the start_offset and capture_start > values are calculated with the following formulas: > > start_offset = (capture_time - capture_start) * previous_clock_rate > capture_start = capture_time I think it is important to elaborate on what "capture_time" is in this formula. That it is the capture time of the first instant the new timestamp rate is going to be used. 3. Section 4.1: I am still not quite happy about these recommendations: An RTP Sender with RTCP turned on MUST use a different SSRC for each different clock rate. Because in more advanced applications like video conferencing with centralized mixing the impact of switching SSRC is so big. It can involved the following mechanisms that will be effected: - Any connection to application logic, side boards etc. - The issue that who a SSRC becomes unknown until an CNAME is distributed to everyone that needs to know, that include speaker indication using CSRC. - RTP retransmission, that needs to use another SSRC and then acquire the binding using CNAME is SSRC multiplexed. - The fact that switching and "BYE" an SSRC prevents an receiver to request retransmission of the packet that has been lost but not yet delivered when the SSRC is given up. - TMMBR limiations set on a SSRC value that needs to be transfered to the new one. So I think "MUST" is way to strict as rule. Especially as there are rules that make this problem much less an issue as soon as implementations has been updated. But that will be a bit more work as we should also include clarifications and fixes on the found issues around RTCP clock rate switches. And recommendations for how to avoid the issue in the future. 4. Section 4.2: D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j) - (arrival_time_i * clock_rate_i - timestamp_i) I think it is important that this is expanded a bit. First of all that we will only avoid an error if "j" is the first packet for the new Timestamp Rate. Thus we should likely discuss how one gets this value to be a sane one in any RTCP report. Likely by doing the calculation twice, one up to the switch and then a second time from the switch forward. If one doesn't get the packet which is first of the switch, then I think we should consider if we need to discuss how one use the two nearest SRs to calculate the actual point of the switch. If my math hasn't gone wrong I think NTP_of_Switch = (TS_j-TS_i+ R_i*N_i - R_j*N_j)/(R_i-R_j) Where i is an RTCP SR prior to the switch and j is an RTCP SR after the switch and TS is the timestamp value, N the NTP value and R the timestamp rate at that moment. What I don't know is how robust this is to a non-consistent method of timestamp value switch. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From daveoran@orandom.net Mon Jun 13 07:33:47 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C4511E808C for ; Mon, 13 Jun 2011 07:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-zOOCkL32YS for ; Mon, 13 Jun 2011 07:33:46 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2001:470:d:21b:3c00::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7500B11E8072 for ; Mon, 13 Jun 2011 07:33:46 -0700 (PDT) Received: from [10.32.245.150] (c-24-62-229-193.hsd1.ma.comcast.net [24.62.229.193]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5DEXjY5007944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Jun 2011 07:33:46 -0700 Mime-Version: 1.0 (Apple Message framework v1237.1) Content-Type: text/plain; charset=iso-8859-1 From: David R Oran In-Reply-To: <4DF23F7E.2070903@ericsson.com> Date: Mon, 13 Jun 2011 10:33:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90D059CA-2B47-4F5B-BD8D-F4F0A5E5816A@orandom.net> References: <4DF23F7E.2070903@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1237.1) Cc: "avtext@ietf.org" Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 14:33:47 -0000 Preference would be to start with (b) since it would be really helpful = to have a complete description of splicing in a way that permits enough = instrumentation to debug the system, and because most use cases do not = in fact require non-detectability by receivers. I have no objection to (c) since there is clearly interest in such a = solution for those use cases requiring non-detectability, despite my = personal skepticism about just how good a job can be done overall even = if the RTP part succeeds at obfuscating the splices. So, to summarize, work on mixer first and cone that's solid and well = documented, figure out what instrumentation and debuggability, if any, = we sacrifice in the process of doing a translator. DaveO. On Jun 10, 2011, at 11:59 AM, Magnus Westerlund wrote: > Hi, >=20 > We have had this ongoing discussion on the mailing list around the RTP > Splicing and the pro-and-cons for two major solutions. To try to get = to > some decision on what the WG should focus on I would like to ask the = WG > to indicate their preference for what should be done here. The options > are three on a high level. And this is for an informational document > that explains how you use the existing RTP features to accomplish = splicing. >=20 > A) Focus only on RTP Translator based solution >=20 > B) Focus only on RTP Mixer based solution >=20 > C) Define both Mixer and Translator based solutions. >=20 > A) is pretty well described in the individual draft: > https://datatracker.ietf.org/doc/draft-xia-avtext-splicing-for-rtp/ >=20 > The trade-offs and limiations of A and B has been fairly well = discussed > in the following email list discussion. > http://www.ietf.org/mail-archive/web/avtext/current/msg00046.html >=20 > So if you aren't familiar with the topic already please review the = above > and then indicate your position no later than the 26th of June. >=20 > Independently of the choice that solution will have to discuss the = pros > and cons of that method and what properties it has. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From csp@csperkins.org Tue Jun 14 04:01:04 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B134811E808E for ; Tue, 14 Jun 2011 04:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.461 X-Spam-Level: X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zq-kiiGwu6y for ; Tue, 14 Jun 2011 04:01:04 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id E5DE211E8071 for ; Tue, 14 Jun 2011 04:01:03 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QWRMl-0001i7-aK; Tue, 14 Jun 2011 11:01:03 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DF5F1A2.5040801@ericsson.com> Date: Tue, 14 Jun 2011 12:01:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <60445795-2009-403E-8CC7-0834CAA85B12@csperkins.org> References: <4DF23F7E.2070903@ericsson.com> <3D43C69A-6B46-48EA-BC4D-7AD3AD61C68C@csperkins.org> <4DF5F1A2.5040801@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "avtext@ietf.org" Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 11:01:04 -0000 On 13 Jun 2011, at 12:16, Magnus Westerlund wrote: > On 2011-06-13 13:04, Colin Perkins wrote: >>=20 >> I'm not convinced this is the right question to ask. A better >> question might focus on the requirement rather than the solution: do >> we describe how to do splicing in a way that's not detectable by the >> receiver, or in a way that allows the receiver to tell that content >> has been spliced in? >>=20 >=20 > Maybe, but my understanding from the discussion is that unless one = does media-transcoding, then it will be always possible to detect the = splice. Yes it can be difficult and need to include media cues and not = 100% accurate. But pretty well. That depends on the codec being used, but I agree that you'll likely be = able to see the splice in the media stream in many cases.=20 > So the question regarding requirements one can ask is on the level of: >=20 > 1) Clearly detectable in RTP >=20 > 2) Likely not detectable in RTP level >=20 > And I think both A and B from the original question can accomplish = either of these. Thus, for the question of what track to aim I don't see = it as crucial question. For what the draft in the end contains, it is a = very important question. But I would prefer to take one question at a = time. A mixer-based solution could be detectable or non-detectable at the RTP = layer, depending on whether a CSRC is included or not. Also, if we want = to focus on a detectable solution, then there are other approaches to = using mixers and translators that might be considered (e.g., something = like a stream-switching MCU could also work). --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Tue Jun 14 04:20:58 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9231F9E801B for ; Tue, 14 Jun 2011 04:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.472 X-Spam-Level: X-Spam-Status: No, score=-103.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPPdi2mtW9wG for ; Tue, 14 Jun 2011 04:20:57 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEBB9E801F for ; Tue, 14 Jun 2011 04:20:57 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QWRe9-0000Zi-l9; Tue, 14 Jun 2011 11:19:01 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DF23F7E.2070903@ericsson.com> Date: Tue, 14 Jun 2011 12:19:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51968CF4-6A8A-49C5-BD01-32346351DD9F@csperkins.org> References: <4DF23F7E.2070903@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "avtext@ietf.org" Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 11:20:58 -0000 On 10 Jun 2011, at 16:59, Magnus Westerlund wrote: > We have had this ongoing discussion on the mailing list around the RTP = Splicing and the pro-and-cons for two major solutions. To try to get to = some decision on what the WG should focus on I would like to ask the WG = to indicate their preference for what should be done here. The options = are three on a high level. And this is for an informational document = that explains how you use the existing RTP features to accomplish = splicing. >=20 > A) Focus only on RTP Translator based solution >=20 > B) Focus only on RTP Mixer based solution >=20 > C) Define both Mixer and Translator based solutions. >=20 > A) is pretty well described in the individual draft: > https://datatracker.ietf.org/doc/draft-xia-avtext-splicing-for-rtp/ >=20 > The trade-offs and limiations of A and B has been fairly well = discussed > in the following email list discussion. > http://www.ietf.org/mail-archive/web/avtext/current/msg00046.html >=20 > So if you aren't familiar with the topic already please review the = above and then indicate your position no later than the 26th of June. Actually answering the question this time... :-) If there is a requirement for non-detectability, which I understand the = authors of draft-xia-avtext-splicing-for-rtp have, then I think that an = RTP translator based solution is most appropriate, although an RTP mixer = could also be made to work.=20 If non-detectability is not a requirement, then a mixer based solution = could make debugging easier (as Dave Oran has noted), and so might be = more appropriate. --=20 Colin Perkins http://csperkins.org/ From xiajinwei@huawei.com Wed Jun 15 19:07:42 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FB411E8147 for ; Wed, 15 Jun 2011 19:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnPLn9rZ6Ke9 for ; Wed, 15 Jun 2011 19:07:42 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C8C3511E8079 for ; Wed, 15 Jun 2011 19:07:41 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMV00GEW1WL11@szxga03-in.huawei.com> for avtext@ietf.org; Thu, 16 Jun 2011 10:07:33 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMV0029K1WLDB@szxga03-in.huawei.com> for avtext@ietf.org; Thu, 16 Jun 2011 10:07:33 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 16 Jun 2011 10:07:27 +0800 Received: from x65217 (10.138.41.84) by smtpscn.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 16 Jun 2011 10:07:33 +0800 Date: Thu, 16 Jun 2011 10:07:26 +0800 From: Jinwei Xia In-reply-to: <4DF5F1A2.5040801@ericsson.com> X-Originating-IP: [10.138.41.84] To: 'Magnus Westerlund' , 'Colin Perkins' Message-id: <001b01cc2bca$24275f50$54298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acwpu2sjik3EtREWQVSggKQmQ7q8+QCBwFiw Cc: avtext@ietf.org Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 02:07:42 -0000 > Maybe, but my understanding from the discussion is that=20 > unless one does media-transcoding, then it will be always=20 > possible to detect the splice. > Yes it can be difficult and need to include media cues and=20 > not 100% accurate. But pretty well. >=20 > So the question regarding requirements one can ask is on the level of: >=20 > 1) Clearly detectable in RTP Mixer can use CSRC list to facilitate debugging, so I agree Dave's = option that mixer is more appropriate in this case. >=20 > 2) Likely not detectable in RTP level translator is more complex to handle bitrate adaptation compared to = mixer. If using mixer without CSRC list, mixer has similar complexity, = generating timing and RTCP reports even when splicing is end, modifying sequence numbers when main stream starts. Wheras translator only rewrites the sequence numbers after first splicing. So I littel incline to translator, but if the consensus of WG think = mixer is more appropriate, I'd like to follow the consensus. >=20 > And I think both A and B from the original question can=20 > accomplish either of these. Thus, for the question of what=20 > track to aim I don't see it as crucial question. For what the=20 > draft in the end contains, it is a very important question.=20 > But I would prefer to take one question at a time. Can we choose C to address both cases or have to use two separated = drafts for each case?=20 Thank you. Jinwei >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From magnus.westerlund@ericsson.com Wed Jun 22 06:07:17 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1263511E80F1 for ; Wed, 22 Jun 2011 06:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.722 X-Spam-Level: X-Spam-Status: No, score=-105.722 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VixuvfJK4tS6 for ; Wed, 22 Jun 2011 06:07:15 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6F311E80D4 for ; Wed, 22 Jun 2011 06:07:15 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-d2-4e01e901d4e5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FB.08.09774.109E10E4; Wed, 22 Jun 2011 15:07:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 22 Jun 2011 15:07:13 +0200 Message-ID: <4E01E8F5.6050808@ericsson.com> Date: Wed, 22 Jun 2011 15:07:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "avtext@ietf.org" , draft-ietf-avtext-mixer-to-client-audio-level@tools.ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 13:07:17 -0000 Hi, I reviewed the draft and have some comments. 1. The intended status says Informational. This document is intended for standards track. 2. Section 3, paqe 4: " Note that in some cases a mixer may be sending an RTP audio stream that only contains audio level information and no actual audio. Updating a (web) interface conference module may be one reason for this to happen." My question would what value you stick into the payload type field if you have no payload only header? It is not obvious that you can do this without configuring a payload format that either is valid for a zero length payload or define a specific for that case. 3. Section 4 and 5. I find the definition confusing, especially as important rules of the actual format comes in later sections. a) First of all it is not written in generic engough way to support both the short and long format. b) The actual extension formats that is the payload is in the next section. Including important rules, like that the CSRC list shall be mapped against the level list. I would recommend that Section 4 and 5 is merged and that a more ordered structure to the definition of the header extensions is made. Where field values are clearly defined including explicit length in bits. And where the rules around it is separated from the basic field definitions. 4. Section 5. I think the dBov definition needs to be really clear. Yes, the convention is amplitudes are squared when doing dB calculation. But it is not clear if this is done for the single highest value in the measured range, or if it is done as an average over the measured range. Please provide a definition or a reference. 5. Section 5 and Section 3: I would note that the folllowing text in section 5: The audio level header extension only carries the level of the audio in the RTP payload of the packet it is associated with, with no long- term averaging or smoothing applied. Makes it impossible for the following to be done: Note that in some cases a mixer may be sending an RTP audio stream that only contains audio level information and no actual audio. Updating a (web) interface conference module may be one reason for this to happen. This as there is no duration of audio indicated, only a first sample. 6. Section 5: "The audio level for digital silence, for example for a muted audio source, MAY be represented as 127 (-127 dBov), regardless of the dynamic range of the encoded audio format." I don't like this MAY. To me it appears to only complicate implementations. Either you mandate the behavior so that one can trust sources muted by the application to always carry value 127. Or one anyway need to have noise level detector so that one can determine when there is signal above the noise level. One may have to have that anyway, but I think we should consider if we want clear MUTED indication here or not. 7. Section 6. "Presence of the above attribute in the SDP description of a media stream indicates that some or all RTP packets in that stream would contain the audio level information RTP extension header." To me this sentence is a mix between a usage rule: "some or all packets may contain the header extension" and a signaling rule: The presence of the attribute indicates the usage of the audio level header extension. In addition it not is the attribute per say that indicate it, it is the attribute with the given URI is used to indicate that a particular value is bound to identify the header extension defined in this doc. 8. Section 6. "This speicification does not define use of the audio level extensions in video streams. Therefore, the extension defined in this document SHOULD NOT be advertised in anything but audio streams." First spelling error of specification. Secondly, we also have media types like text, where I also don't see a logical mapping. Thus I wonder if this should be formulated in a way that avoids being media specific. I also wonder if there is any point in leaving the hole with "SHOULD NOT"? Either skip using that and formulate that it is only defined for audio streams, or some other way? 9. Section 7: I am missing a reference to the VBR consideration that I think contains a much better and complete explanation to the issue with just energy level or similar phonetic structure indicators. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From keith.drage@alcatel-lucent.com Wed Jun 22 06:36:37 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F67821F849D for ; Wed, 22 Jun 2011 06:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.249 X-Spam-Level: X-Spam-Status: No, score=-105.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eDY-y34Vh6G for ; Wed, 22 Jun 2011 06:36:36 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 50E0921F849E for ; Wed, 22 Jun 2011 06:36:33 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5MDaVWl023393 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 22 Jun 2011 15:36:32 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 22 Jun 2011 15:36:31 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Wed, 22 Jun 2011 15:36:31 +0200 Thread-Topic: Comments on draft-ietf-avtext-client-to-mixer-audio-level-02 Thread-Index: Acww4WUwrbT26Ny/SLSgZd1FlGecmw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [avtext] Comments on draft-ietf-avtext-client-to-mixer-audio-level-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 13:36:37 -0000 One comment from my read through Section 3. Implementations MAY choose to measure audio levels prior to encoding them in the payload carried in the RTP payload, e.g. on raw linear PCM input. "MAY" defines an option. Is this really defining an option or just indicati= ng a possibility, as in "can". Regards Keith From keith.drage@alcatel-lucent.com Wed Jun 22 06:41:21 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F62621F84CF for ; Wed, 22 Jun 2011 06:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0RyPUIj5i0t for ; Wed, 22 Jun 2011 06:41:20 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2B26D21F84BD for ; Wed, 22 Jun 2011 06:41:12 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5MDadK3015653 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 22 Jun 2011 15:41:10 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 22 Jun 2011 15:40:59 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Wed, 22 Jun 2011 15:40:57 +0200 Thread-Topic: Comment on: draft-ietf-avtext-mixer-to-client-audio-level-02 Thread-Index: Acww4gQ40QyY/t+XQMODQ1k6HwcwAw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [avtext] Comment on: draft-ietf-avtext-mixer-to-client-audio-level-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 13:41:21 -0000 One minor comment from my readthrough. Section 6. This speicification does not define use of the audio level extensions in video streams. Therefore, the extension defined in this document SHOULD NOT be advertised in anything but audio streams. Typo: "specification" Regards Keith From magnus.westerlund@ericsson.com Wed Jun 22 06:43:09 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9292521F84D3 for ; Wed, 22 Jun 2011 06:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fryMUUAfW-Mb for ; Wed, 22 Jun 2011 06:43:08 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDD021F84BD for ; Wed, 22 Jun 2011 06:43:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-40-4e01f16b3fb0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 41.60.09774.B61F10E4; Wed, 22 Jun 2011 15:43:07 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Wed, 22 Jun 2011 15:43:07 +0200 Message-ID: <4E01F16A.2070901@ericsson.com> Date: Wed, 22 Jun 2011 15:43:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "avtext@ietf.org" , draft-ietf-avtext-client-to-mixer-audio-level@tools.ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] Comments on draft-ietf-avtext-client-to-mixer-audio-level-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 13:43:09 -0000 Hi, I have reviewed this draft and have a few comments. 1. Section 3. "The two-byte header defined in RFC 5285 [RFC5285] may also be used." I think that it should be stated up front that header extensions per definitions can be used with either of the header formats. In addition I think one needs to separate a bit clearer what is framework and what is the new parts. 2. Section 3. I think the dBov definition needs to be really clear. Yes, the convention is amplitudes are squared when doing dB calculation. But it is not clear if this is done for the single highest value in the measured range, or if it is done as an average over the measured range. Please provide a definition or a reference. 3. Section 5: "The audio level for digital silence, for example for a muted audio source, MAY be represented as 127 (-127 dBov), regardless of the dynamic range of the encoded audio format." I don't like this MAY. To me it appears to only complicate implementations. Either you mandate the behavior so that one can trust sources muted by the application to always carry value 127. Or one anyway need to have noise level detector so that one can determine when there is signal above the noise level. One may have to have that anyway, but I think we should consider if we want clear MUTED indication here or not. 4. Section 3: In addition, a flag bit (labeled V) indicates whether the encoder believes the audio packet contains voice activity (1) or does not (0). The voice activity detection algorithm is unspecified and left implementation-specific. Would it be of interest to have an signalling parameter for an implementation to indicate its algorithm? 5. Section 8.2: I think both the encrypted header extension and the VBR audio is likely normative references as they either is recommend solution or a description of the issue. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Jun 22 06:47:46 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C9B1F0C3B for ; Wed, 22 Jun 2011 06:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfJzpPoIDp8a for ; Wed, 22 Jun 2011 06:47:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D76E41F0C35 for ; Wed, 22 Jun 2011 06:47:45 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-29-4e01f27f7bff Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 23.A0.20773.F72F10E4; Wed, 22 Jun 2011 15:47:43 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 22 Jun 2011 15:47:41 +0200 Message-ID: <4E01F27C.1020803@ericsson.com> Date: Wed, 22 Jun 2011 15:47:40 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: avtext@ietf.org References: <20110610152948.26861.38539.idtracker@ietfa.amsl.com> In-Reply-To: <20110610152948.26861.38539.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rams-scenarios-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 13:47:46 -0000 Dear WG, According to the Miestone for this WG we should have completed the WG process by now. That is clearly not the case. However, to make progress we need WG members to review this documents. So please do that. Cheers Magnus Westerlund WG chair. On 2011-06-10 17:29, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. > > Title : Considerations and Guidelines for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method > Author(s) : Ali Begen > Filename : draft-ietf-avtext-rams-scenarios-00.txt > Pages : 11 > Date : 2011-06-10 > > The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a > method based on RTP and RTP Control Protocol (RTCP) that enables an > RTP receiver to rapidly acquire and start consuming the RTP multicast > data. Upon a request from the RTP receiver, an auxiliary unicast RTP > retransmission session is set up between a retransmission server and > the RTP receiver, over which the reference information about the new > multicast stream the RTP receiver is about to join is transmitted at > an accelerated rate. This often precedes, but may also accompany, > the multicast stream itself. When there is only one multicast stream > to be acquired, the RAMS solution works in a straightforward manner. > However, when there are two or more multicast streams to be acquired > from the same or different multicast RTP sessions, care should be > taken to configure each RAMS session appropriately. This document > provides example scenarios and offers guidelines. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtext-rams-scenarios-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-rams-scenarios-00.txt > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From petithug@acm.org Wed Jun 22 12:37:56 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCBD11E80CB for ; Wed, 22 Jun 2011 12:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+LruJyKq0wc for ; Wed, 22 Jun 2011 12:37:55 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A7BED11E808A for ; Wed, 22 Jun 2011 12:37:54 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id D721C226E9; Wed, 22 Jun 2011 21:37:42 +0200 (CEST) Message-ID: <4E024486.2050406@acm.org> Date: Wed, 22 Jun 2011 12:37:42 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 To: "avtext@ietf.org" References: <20110607073530.16031.92596.idtracker@ietfa.amsl.com> <4DF60B9E.90909@ericsson.com> In-Reply-To: <4DF60B9E.90909@ericsson.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [avtext] Comments on draft-ietf-avtext-multiple-clock-rates-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 19:37:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I plan to update and publish a new version of the draft this week-end, incorporating the comments below, so if someone else has comments on the document, please send them as soon as possible. Thanks. On 06/13/2011 06:07 AM, Magnus Westerlund wrote: > Hi, > > I have reviewed this WG 00 version, and thanks the other for taking my > comments into consideration in the previous version. > > I have some additional comments and suggestions for improvements. > However I think it is important that we get input from the WG on these > questions. > > The below are my views as an individual, not WG chair. > > 1. Section 1: > "This document first tries to list in Section 2 and subsections all > the various algorithms used by existing RTP implementations." > > Wouldn't it better to state that this section "lists all known > algorithms used in RTP implementations of the time of writing." Or > something like this. To avoid using "all" without a qualifier. > > 2. Section 4.1: >> Each time the clock rate changes, the start_offset and capture_start >> values are calculated with the following formulas: >> >> start_offset = (capture_time - capture_start) * previous_clock_rate >> capture_start = capture_time > > I think it is important to elaborate on what "capture_time" is in this > formula. That it is the capture time of the first instant the new > timestamp rate is going to be used. > > 3. Section 4.1: > > I am still not quite happy about these recommendations: > > An RTP Sender with RTCP turned on MUST use a different SSRC for each > different clock rate. > > Because in more advanced applications like video conferencing with > centralized mixing the impact of switching SSRC is so big. It can > involved the following mechanisms that will be effected: > > - Any connection to application logic, side boards etc. > - The issue that who a SSRC becomes unknown until an CNAME is > distributed to everyone that needs to know, that include speaker > indication using CSRC. > - RTP retransmission, that needs to use another SSRC and then acquire > the binding using CNAME is SSRC multiplexed. > - The fact that switching and "BYE" an SSRC prevents an receiver to > request retransmission of the packet that has been lost but not yet > delivered when the SSRC is given up. > - TMMBR limiations set on a SSRC value that needs to be transfered to > the new one. > > So I think "MUST" is way to strict as rule. Especially as there are > rules that make this problem much less an issue as soon as > implementations has been updated. But that will be a bit more work as we > should also include clarifications and fixes on the found issues around > RTCP clock rate switches. And recommendations for how to avoid the issue > in the future. > > 4. Section 4.2: > > D(i,j) = (arrival_time_j * clock_rate_i - timestamp_j) - > (arrival_time_i * clock_rate_i - timestamp_i) > > > I think it is important that this is expanded a bit. > > First of all that we will only avoid an error if "j" is the first packet > for the new Timestamp Rate. Thus we should likely discuss how one gets > this value to be a sane one in any RTCP report. Likely by doing the > calculation twice, one up to the switch and then a second time from the > switch forward. > > If one doesn't get the packet which is first of the switch, then I think > we should consider if we need to discuss how one use the two nearest SRs > to calculate the actual point of the switch. > > If my math hasn't gone wrong I think > > NTP_of_Switch = (TS_j-TS_i+ R_i*N_i - R_j*N_j)/(R_i-R_j) > > Where i is an RTCP SR prior to the switch and j is an RTCP SR after the > switch and TS is the timestamp value, N the NTP value and R the > timestamp rate at that moment. > > What I don't know is how robust this is to a non-consistent method of > timestamp value switch. > > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4CRIUACgkQ9RoMZyVa61fQfgCaAzm0xUf8kOweKcxuvRmskE/0 FcoAnAsnIOaSDZaXamGJKazQgOJtIwFP =FL43 -----END PGP SIGNATURE----- From keith.drage@alcatel-lucent.com Thu Jun 23 02:25:57 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A97E21F84C8 for ; Thu, 23 Jun 2011 02:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96Fi1iLIMqct for ; Thu, 23 Jun 2011 02:25:56 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6004D21F849A for ; Thu, 23 Jun 2011 02:25:56 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5N9PYb4008890 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 23 Jun 2011 11:25:53 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 23 Jun 2011 11:25:28 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Thu, 23 Jun 2011 11:25:27 +0200 Thread-Topic: [avtext] Consensus call on RTP Splicing direction forward Thread-Index: Acwnh4FBkyy8xdLASmWhGVojp31o8wJ/8+8w Message-ID: References: <4DF23F7E.2070903@ericsson.com> In-Reply-To: <4DF23F7E.2070903@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 09:25:57 -0000 [As WG chair] Magnus sent out this call a couple of weeks back and we haven't seen very m= any responses. If you have not already responded, please do so. Regards Keith > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of Magnus Westerlund > Sent: 10 June 2011 17:00 > To: avtext@ietf.org > Subject: [avtext] Consensus call on RTP Splicing direction forward >=20 > Hi, >=20 > We have had this ongoing discussion on the mailing list around the RTP > Splicing and the pro-and-cons for two major solutions. To try to get to > some decision on what the WG should focus on I would like to ask the WG > to indicate their preference for what should be done here. The options > are three on a high level. And this is for an informational document > that explains how you use the existing RTP features to accomplish > splicing. >=20 > A) Focus only on RTP Translator based solution >=20 > B) Focus only on RTP Mixer based solution >=20 > C) Define both Mixer and Translator based solutions. >=20 > A) is pretty well described in the individual draft: > https://datatracker.ietf.org/doc/draft-xia-avtext-splicing-for-rtp/ >=20 > The trade-offs and limiations of A and B has been fairly well discussed > in the following email list discussion. > http://www.ietf.org/mail-archive/web/avtext/current/msg00046.html >=20 > So if you aren't familiar with the topic already please review the above > and then indicate your position no later than the 26th of June. >=20 > Independently of the choice that solution will have to discuss the pros > and cons of that method and what properties it has. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From keith.drage@alcatel-lucent.com Thu Jun 23 02:38:07 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEA521F8564 for ; Thu, 23 Jun 2011 02:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.36 X-Spam-Level: X-Spam-Status: No, score=-105.36 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nsBspPDvUiq for ; Thu, 23 Jun 2011 02:38:06 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0DD21F8560 for ; Thu, 23 Jun 2011 02:38:05 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5N9bJfg030678 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 23 Jun 2011 11:38:03 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 23 Jun 2011 11:37:54 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Thu, 23 Jun 2011 11:37:53 +0200 Thread-Topic: Agenda for Quebec meeting Thread-Index: AcwxiTmSc6QyUD/uQLmm+5T5Pri82Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [avtext] Agenda for Quebec meeting X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 09:38:07 -0000 (As WG cochair) This meeting is starting to get close, and in a couple of weeks time we wil= l need to produce an agenda for the 1 hour slot we have requested. This is therefore a call for those who need agenda slots to send a mail to = the AVTEXT chairs (the alias avtext-chairs@tools.ietf.org will reach us) in= dicating - draft to be considered - time required - proposed presenter Also please note that if you request a slot, then we expect to see some lis= t activity on issues to be discussed before the meeting. Priority on the ag= enda will be fixed by what that list discussion indicates. Regards Keith From Even.roni@huawei.com Thu Jun 23 03:50:26 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1E79E8005 for ; Thu, 23 Jun 2011 03:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.621 X-Spam-Level: X-Spam-Status: No, score=-103.621 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqxQlRUCgYBD for ; Thu, 23 Jun 2011 03:50:25 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 96A949E8004 for ; Thu, 23 Jun 2011 03:50:25 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN800A0COPET5@szxga05-in.huawei.com> for avtext@ietf.org; Thu, 23 Jun 2011 18:48:51 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN800LPFOPEIK@szxga05-in.huawei.com> for avtext@ietf.org; Thu, 23 Jun 2011 18:48:50 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-35-190.red.bezeqint.net [79.176.35.190]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN800DUWOP8KP@szxml11-in.huawei.com>; Thu, 23 Jun 2011 18:48:50 +0800 (CST) Date: Thu, 23 Jun 2011 13:46:49 +0300 From: Roni Even In-reply-to: <4DF23F7E.2070903@ericsson.com> To: 'Magnus Westerlund' , avtext@ietf.org Message-id: <005201cc3192$de95d790$9bc186b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: Acwnh321gX/rUIv+QBW9P75+QtQu3gKCx8Lg References: <4DF23F7E.2070903@ericsson.com> Subject: Re: [avtext] Consensus call on RTP Splicing direction forward X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 10:50:26 -0000 Hi, I was inclining towards the mixer solution and having the CSRS = information optional depending if the RTP level splicing should be detectable = easily. I am not sure why not go to the C) solution since these will be an Informational RFC and I think it may also add, as a side effect, some information about RTP translators and Mixers. Regards Roni > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Friday, June 10, 2011 7:00 PM > To: avtext@ietf.org > Subject: [avtext] Consensus call on RTP Splicing direction forward >=20 > Hi, >=20 > We have had this ongoing discussion on the mailing list around the RTP > Splicing and the pro-and-cons for two major solutions. To try to get = to > some decision on what the WG should focus on I would like to ask the = WG > to indicate their preference for what should be done here. The options > are three on a high level. And this is for an informational document > that explains how you use the existing RTP features to accomplish > splicing. >=20 > A) Focus only on RTP Translator based solution >=20 > B) Focus only on RTP Mixer based solution >=20 > C) Define both Mixer and Translator based solutions. >=20 > A) is pretty well described in the individual draft: > https://datatracker.ietf.org/doc/draft-xia-avtext-splicing-for-rtp/ >=20 > The trade-offs and limiations of A and B has been fairly well = discussed > in the following email list discussion. > http://www.ietf.org/mail-archive/web/avtext/current/msg00046.html >=20 > So if you aren't familiar with the topic already please review the > above > and then indicate your position no later than the 26th of June. >=20 > Independently of the choice that solution will have to discuss the = pros > and cons of that method and what properties it has. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext >=20 > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6196 (20110610) __________ >=20 > The message was checked by ESET NOD32 Antivirus. >=20 > http://www.eset.com >=20 >=20 >=20 >=20 > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6196 (20110610) __________ >=20 > The message was checked by ESET NOD32 Antivirus. >=20 > http://www.eset.com >=20 From Aidan.Williams@audinate.com Tue Jun 28 23:23:04 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C089E8013 for ; Tue, 28 Jun 2011 23:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzZ0c43Pt3Aq for ; Tue, 28 Jun 2011 23:23:03 -0700 (PDT) Received: from sydney.audinate.com (sydney.audinate.com [150.101.200.21]) by ietfa.amsl.com (Postfix) with ESMTP id 68309228015 for ; Tue, 28 Jun 2011 23:23:02 -0700 (PDT) Received: from zimbra.audinate.com (zimbra.audinate.com [10.12.0.6]) by sydney.audinate.com (Postfix) with ESMTP id EA479180053; Wed, 29 Jun 2011 16:23:00 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by zimbra.audinate.com (Postfix) with ESMTP id 764199E03E8; Wed, 29 Jun 2011 16:15:08 +1000 (EST) X-Virus-Scanned: amavisd-new at zimbra.audinate.com Received: from zimbra.audinate.com ([127.0.0.1]) by localhost (zimbra.audinate.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaTcrFMtAkVM; Wed, 29 Jun 2011 16:15:07 +1000 (EST) Received: from praxis.local (audinate.audinate.com [10.12.0.140]) by zimbra.audinate.com (Postfix) with ESMTPSA id F17D29DFCB0; Wed, 29 Jun 2011 16:15:06 +1000 (EST) Message-ID: <4E0AC4C3.2080804@audinate.com> Date: Wed, 29 Jun 2011 16:22:59 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-williams-avtext-avbsync X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 06:23:05 -0000 Hi Keith, It is my intention to proceed with this document and to update it with additional material. The draft relates to work elsewhere around using the IEEE AVB protocols [1] with RTP transport. "Elsewhere" in this case means the IEEE, AVnu and the Audio Engineering Society (AES). The RTCP message described in the draft is what has been specified by the IEEE 1733 WG. I'm not aware that this has been brought to the attention of this WG, however I would certainly be interested in any feedback people may have. The header extension is a logical addition. At the time that IEEE 1733 had to make a choice, the header extension mechanism wasn't available. For high performance implementations (such as those I work on), media packets are processed at wire speed in hardware (e.g. by FPGA). It is very convenient to have the synchronization metadata available with the media payload since the control and data processing planes are distinct. It is a similar approach as the RFC6051 NTP timestamp header extension. I see there are a couple of other emails relating to the motivation for doing any of this this at all - I'll reply to them next. regards aidan ____ :wq! [1] The IEEE AVB task group: http://www.ieee802.org/1/pages/avbridges.html On 10/06/11 9:09 PM, DRAGE, Keith (Keith) wrote: > (As WG cochair) > > The following author draft defines an RTP header extension > > https://datatracker.ietf.org/doc/draft-williams-avtext-avbsync/ > > Apart from a request for agenda time at the last meeting, there has not been any discussion on the document. > > > Q1: To the authors. Are you intending proceeding with this document. Is the document still the direction you wish to go or do you have other ideas. > > Q2: To the WG. Is this document reasonable or heading in entirely the wrong direction. > > Regards > > Keith From Aidan.Williams@audinate.com Wed Jun 29 00:56:49 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF98521F875A for ; Wed, 29 Jun 2011 00:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7mCbwoGpbJN for ; Wed, 29 Jun 2011 00:56:49 -0700 (PDT) Received: from sydney.audinate.com (sydney.audinate.com [150.101.200.21]) by ietfa.amsl.com (Postfix) with ESMTP id AC3B921F875B for ; Wed, 29 Jun 2011 00:56:48 -0700 (PDT) Received: from zimbra.audinate.com (zimbra.audinate.com [10.12.0.6]) by sydney.audinate.com (Postfix) with ESMTP id 3EC7D180053; Wed, 29 Jun 2011 17:56:45 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by zimbra.audinate.com (Postfix) with ESMTP id 766E99E0432; Wed, 29 Jun 2011 17:48:52 +1000 (EST) X-Virus-Scanned: amavisd-new at zimbra.audinate.com Received: from zimbra.audinate.com ([127.0.0.1]) by localhost (zimbra.audinate.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-grPPIAhMld; Wed, 29 Jun 2011 17:48:51 +1000 (EST) Received: from praxis.local (audinate.audinate.com [10.12.0.140]) by zimbra.audinate.com (Postfix) with ESMTPSA id 7BCD09DFCB0; Wed, 29 Jun 2011 17:48:51 +1000 (EST) Message-ID: <4E0ADABB.6050307@audinate.com> Date: Wed, 29 Jun 2011 17:56:43 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: David R Oran References: <84599674-1BB4-4425-82B2-02C34E46232E@orandom.net> In-Reply-To: <84599674-1BB4-4425-82B2-02C34E46232E@orandom.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-williams-avtext-avbsync X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:56:50 -0000 On 12/06/11 12:33 AM, David R Oran wrote: > Three thoughts: > a) I don't get it. Just because the RTP wall clock is in NTP time format doesn't mean that time could not have been synchronized to the accuracy of an IEEE 1588 clock using those protocols to compute/adjust it as opposed to or as augmentation of IEEE 1588. You're right - it isn't the format of the NTP timestamp that is the issue, rather it is about having identifiable clocking domains, and performance. RTP does not assume synchronised clocks and does not assume that NTP timestamps refer to a synchronised clock (either rate or offset synchronised). There is no standard way of knowing that NTP timestamps coming from two or more senders are taken w.r.t. to a synchronised clock. In contrast, the RTCP message described in the draft can indicate that timestamps are coming from a single clock source via the gmIdentity field. The gmIdentity is based on the EUI64 of the master clock. A device receiving flows from senders with the same gmIdentity can be sure that the timestamps are being taken with a common clock. AVB systems are intended to time align signal playout and capture signal phase relationships accurately on all boxes connected to the network. Playout/capture on one device is intended to be accurately time aligned with playout/capture on a different device. Accurate time alignment is required between signal flows and between boxes, and to achieve that, accurate synchronised time is needed. To give you an idea of the requirement: for ProAV applications, +/-1us time alignment is required; for consumer applications, 80us time alignment is required between a left and right loudspeakers (say). Readily available hardware support in end-point chipsets and switches, absolute time alignment performance, fast lock time and identifiable clocking domains make IEEE 1588/802.1AS a good choice over NTP as a synchronisation protocol. If you're going to send an RTCP message binding an RTP timestamp, a 1588 timestamp and a gmIdentity together, the 1588 timestamp may as well be in a 1588 format. > b) how can you tell whether or not the RTP session has both endpoints within the scope/domain of a single instance of the AVB synchronization protocol? > See the above comment about gmIdentity. > c) We should ask the TICTOC working group for their opinions before considering adoption. > I haven't been following tictoc recently - I'll take a look. regards aidan ____ :wq!