Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D37D21F8787 for ; Tue, 20 Nov 2012 11:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6] 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 KnQmFGDW9ess for ; Tue, 20 Nov 2012 11:51:48 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8236521F873D for ; Tue, 20 Nov 2012 11:51:48 -0800 (PST) X-ASG-Debug-ID: 1353441106-03fc20119e82430001-mNOVBD Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by barracuda1.acmepacket.com with ESMTP id fK5wxG3N7FymB6H8 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Nov 2012 14:51:46 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Tue, 20 Nov 2012 14:51:33 -0500 From: Hadriel Kaplan To: Bernard Aboba Thread-Topic: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing X-ASG-Orig-Subj: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing Thread-Index: AQHNx1hxvSoC84ovvkqVvo+Zxh0CCw== Date: Tue, 20 Nov 2012 19:51:33 +0000 Message-ID: <535E4BAA-BE0C-47D1-A659-17B4043031EE@acmepacket.com> References: , <50ABCF23.9020605@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: multipart/alternative; boundary="_000_535E4BAABE0C47D1A65917B4043031EEacmepacketcom_" MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1353441106 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.114774 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Cc: "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 19:51:49 -0000 --_000_535E4BAABE0C47D1A65917B4043031EEacmepacketcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I take this is a "NO" vote? -hadriel On Nov 20, 2012, at 1:56 PM, Bernard Aboba > wrote: To Paul's point, there may be a scenario in which some m lines would be loo= ped back and others would not. For example, what if I want to do a loopbac= k test of audio/video but also want to be able to converse via RTT to discu= ss the results of the test in progress. In that case the audio and video m= lines would be looped back but the text line would not be. > Date: Tue, 20 Nov 2012 13:42:43 -0500 > From: pkyzivat@alum.mit.edu > To: mmusic@ietf.org > Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-nothing > > NO > > *Why* should the draft be limited this way if it need not be? > > Thanks, > Paul > > On 11/20/12 1:16 PM, Hadriel Kaplan wrote: > > Howdy, > > during IESG review of the media-loopback draft, a discussion arose rega= rding the language around indicating media-loopback support per media descr= iption (i.e., per m-line), in sections 3.1 and 3.2. > > > > My interpretation/understanding was we were requiring ALL m-lines to in= dicate media-loopback; in other words it's an all-or-nothing in both the of= fer+answer, and either every media stream is looped back, or none are. Howe= ver the text currently doesn't make this clear, and it could be argued eith= er way, with pro's/con's either way too; so I'd like the WG's consensus on = whether it should in fact be an all-or-none approach, or not. > > > > Please respond to this email by **Tuesday, December 4th** with a "YES" = if the draft should mandate ALL media be looped-back, or "NO" if it should = allow a hybrid approach of some streams being looped while others are not. > > > > For reference, the draft is here: > > http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-24 > > > > -hadriel > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_535E4BAABE0C47D1A65917B4043031EEacmepacketcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <70EB108B66248C4597D9E928C4B1AB9B@acmepacket.com> Content-Transfer-Encoding: quoted-printable

I take this is a "NO" vote? 

-hadriel


On Nov 20, 2012, at 1:56 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

To Paul's point, there may be a scenario in which some m l= ines would be looped back and others would not.  For example, what if = I want to do a loopback test of audio/video but also want to be able to con= verse via RTT to discuss the results of the test in progress.  In that case the audio and video m lines would= be looped back but the text line would not be. 

> Date: Tue, 20 Nov 2012 13:42:43 -0500
> From: pkyzivat@alum.mit.edu
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] NEED WG CONSENSUS: media-loopback is all-or-noth= ing
> 
> NO
> 
> *Why* should the draft be limited this way if it need not be?
> 
> Thanks,
> Paul
> 
> On 11/20/12 1:16 PM, Hadriel Kaplan wrote:
> > Howdy,
> > during IESG review of the media-loopback draft, a discussion aros= e regarding the language around indicating media-loopback support per media= description (i.e., per m-line), in sections 3.1 and 3.2.
> >
> > My interpretation/understanding was we were requiring ALL m-lines= to indicate media-loopback; in other words it's an all-or-nothing in both = the offer+answer, and either every media stream is looped back, or none= are. However the text currently doesn't make this clear, and it could be argued either way, with pro's/con's either way= too; so I'd like the WG's consensus on whether it should in fact be an all= -or-none approach, or not.
> >
> > Please respond to this email by **Tuesday, December 4th** with a = "YES" if the draft should mandate ALL media be looped-back, or &q= uot;NO" if it should allow a hybrid approach of some streams being loo= ped while others are not.
> >
> > For reference, the draft is here:
> > http://tools.ie= tf.org/html/draft-ietf-mmusic-media-loopback-24
> >
> > -hadriel
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/list= info/mmusic
> >
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/= mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic

--_000_535E4BAABE0C47D1A65917B4043031EEacmepacketcom_--