From espeberg@cisco.com Mon Apr 2 06:52:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED9821F855B for ; Mon, 2 Apr 2012 06:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRHhsN5S2vmw for ; Mon, 2 Apr 2012 06:52:23 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CD55321F854D for ; Mon, 2 Apr 2012 06:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=3219; q=dns/txt; s=iport; t=1333374743; x=1334584343; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=KjL7+9LzrNON9dTpHKB1IbUnie/mO+gRxGcTCqkihfM=; b=OYxEpjL6QEPwpBtVzJY1IXhCqzEW1cy2jzEyypkfd+4Ev8MTikp8x/5Z LEtX280EkINWrzqMb0I7FvFIRx7JyF0y8POEeAXEXrqa8qa1Avj5h+eft u/BrORMCMsRLpxDUxPtrUyfB7zt6YRha4Ldz+bXLbP3VQ5mUrvPE7/GO6 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKWueU+Q/khR/2dsb2JhbABEDrkCgQeCCQEBAQMBAQEBDwEdCjQXBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQBEggah2IFC5ssnmEEkDljBKQogWiCMDk X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208";a="69916658" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 02 Apr 2012 13:52:21 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q32DqLCT021629; Mon, 2 Apr 2012 13:52:21 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 15:52:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 15:52:20 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com> In-Reply-To: <4F74BDDD.1010100@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] audio mixed attribute Thread-Index: Ac0N5bwlGVsQ1hwzQzuTn2B2Nr6MkACzJHJg References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com><20120329152600.GB67516@verdi><92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com><20120329171843.GC67516@verdi> <4F74BDDD.1010100@alum.mit.edu> From: "Espen Berger (espeberg)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 02 Apr 2012 13:52:21.0567 (UTC) FILETIME=[D37ADCF0:01CD10D7] Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 13:52:23 -0000 An audio mixing attribute is useful in the scenario where an MCU can support both transcoding and switching.=20 Given this scenario: A MCU supports transcoding and switching off audio streams. The MCU can offer 3x loudest audio streams or 3x pre-mixed audio streams that can be played out on left, Center, Right speakers.=20 Example advertisement=20 AC1, AC2, AC3 audio_type =3D natural // Audio is switched between the natural sources=20 AC4, AC5, AC6 audio_type =3D mixed // Audio is mixed into three fixed positions=20 =20 CaptureSet // AC4 - AC6 belongs together { AC4, AC5, AC6 }=20 A consumer chooses either to request AC1 - AC3, does local mixing and play out placement. If the endpoint chooses stream AC4 - AC6 the audio should be played out on speaker that matches a left to right position. =20 In this scheme it might be better to have a multi value attribute describing audio_type, to avoid the possible confusion multiple Boolean might have. Audio_type =3D { natural | mixed }=20 Regards=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 29. mars 2012 21:54 To: clue@ietf.org Subject: Re: [clue] audio mixed attribute I think you all have very clearly demonstrated that just being told that a stream is mixed or not-mixed is insufficient to make any useful decision about what to do with it. Thanks, Paul (as individual) On 3/29/12 7:18 PM, John Leslie wrote: > Espen Berger (espeberg) wrote: >> >> John, you have listed a set of valid acoustical challenges which I=20 >> recognize from our experience. Some of the acoustical challenges will >> be present if a room use 1 or 2+ microphones to record, e.g. when a=20 >> person moves around in the room. > > This is true. > >> We should thrust endpoints that chooses to use multiple microphones=20 >> for capture to do proper audio pre-processing, and keep the audio quality. > > I do not intend anything other than trusting endpoint operators. > But there are inherent differences between single-pickup and multiple=20 > pickups mixed. For many purposes, multiple pickups will be better... > >> I would suggest that we reserve the mixed attribute to scenarios=20 >> where a middle box mix audio captures from different endpoints. > > I don't believe it helpful to define "mixed" based on where the=20 > mixing is done. > > You raise a valid point about "mixing" audio from different rooms. > This, indeed, is something to "hardly-ever" prefer. Thus, to me, I'd=20 > rather it not be an ordinary offer. > > When I describe "mixed" as a warning-label, I did not mean to=20 > infer that "mixed" means "low-quality". > > It sounds to me as if we should seriously consider including a=20 > description of _what_ is being mixed... > > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Mon Apr 2 07:40:39 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A686B21F85B7 for ; Mon, 2 Apr 2012 07:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R41u67XsGsde for ; Mon, 2 Apr 2012 07:40:38 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA8C21F854F for ; Mon, 2 Apr 2012 07:40:35 -0700 (PDT) Received: by dady13 with SMTP id y13so3211833dad.27 for ; Mon, 02 Apr 2012 07:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IqCdvzXEpGqu8I1n6qoYFYUf2GBC3HEWdzlIBFwSVpo=; b=VH68tnzsEIpgn4h9OyDK+ubiJwvFFssGxrwbnlO2uVjTE3dtw90TQaVYzFD6wJ/c1r YBpoSLeMe/IPJ9tivh08H7WsZm4IspP376D7J3UbXp/2WUinIEdAdoSQgET+GigeaFtB mjPz7EqpWd1xMlCQLVYfyVsOnV4INPKaJK0QobAi9bUQU6CpUckb5tZauM8Z3ztgEGFp sVNt/A1bLmd7oigR6YnFNYbvgZCyk5S64x3JE2ICXIdTjLeFyuf6PHy/MbKbOlHZFvQ9 +aBeNAZg7zv/camw5UTCDlzt1PG1ArV1TvTE8PFMSlxUJsqTjG7JSM+kt7zjjgSEsj3w C0Cw== MIME-Version: 1.0 Received: by 10.68.200.199 with SMTP id ju7mr21215552pbc.122.1333377634800; Mon, 02 Apr 2012 07:40:34 -0700 (PDT) Received: by 10.68.32.37 with HTTP; Mon, 2 Apr 2012 07:40:34 -0700 (PDT) In-Reply-To: <92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com> <20120329152600.GB67516@verdi> <92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com> <20120329171843.GC67516@verdi> <4F74BDDD.1010100@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com> Date: Mon, 2 Apr 2012 10:40:34 -0400 Message-ID: From: Stephen Botzko To: "Espen Berger (espeberg)" Content-Type: multipart/alternative; boundary=047d7b15ae3b46135204bcb32c6d Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:40:39 -0000 --047d7b15ae3b46135204bcb32c6d Content-Type: text/plain; charset=ISO-8859-1 in-line On Mon, Apr 2, 2012 at 9:52 AM, Espen Berger (espeberg) wrote: > An audio mixing attribute is useful in the scenario where an MCU can > support both transcoding and switching. > > Given this scenario: A MCU supports transcoding and switching off audio > streams. The MCU can offer 3x loudest audio streams or 3x pre-mixed > audio streams that can be played out on left, Center, Right speakers. > > Example advertisement > AC1, AC2, AC3 audio_type = natural // Audio is switched between the > natural sources > [sb] perhaps you mean "original" sources? Also, are you thinking that AC1, AC2, AC3 vary in their spatial position (that AC1 will suddenly switch from right to left???) AC4, AC5, AC6 audio_type = mixed // Audio is mixed into three fixed > positions > > CaptureSet // AC4 - AC6 belongs together > { AC4, AC5, AC6 } > [sb] - I am wondering if you are implying that AC1, AC2, AC3 can not be > advertised in a capture set???? > > A consumer chooses either to request AC1 - AC3, does local mixing and > play out placement. If the endpoint chooses stream AC4 - AC6 the audio > should be played out on speaker that matches a left to right position. > > In this scheme it might be better to have a multi value attribute > describing audio_type, to avoid the possible confusion multiple Boolean > might have. > > Audio_type = { natural | mixed } > [sb] "natural" seems to imply that it is somehow preferred (that "mixed" is somehow un-natural). One benefit of the mixed version is that you are more likely to hear onset speech from participants who are not presently seen (assuming I understand what switching algorithm you have in mind). I am not yet convinced that we need signaling for this. Though if we are thinking that a capture's spatial position can change w/o notice, that might be worth further discussion. That will complicate Jonathan's disaggregated media requirement. > > Regards > > -Espen > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 29. mars 2012 21:54 > To: clue@ietf.org > Subject: Re: [clue] audio mixed attribute > > I think you all have very clearly demonstrated that just being told that > a stream is mixed or not-mixed is insufficient to make any useful > decision about what to do with it. > > Thanks, > Paul (as individual) > > On 3/29/12 7:18 PM, John Leslie wrote: > > Espen Berger (espeberg) wrote: > >> > >> John, you have listed a set of valid acoustical challenges which I > >> recognize from our experience. Some of the acoustical challenges will > > >> be present if a room use 1 or 2+ microphones to record, e.g. when a > >> person moves around in the room. > > > > This is true. > > > >> We should thrust endpoints that chooses to use multiple microphones > >> for capture to do proper audio pre-processing, and keep the audio > quality. > > > > I do not intend anything other than trusting endpoint operators. > > But there are inherent differences between single-pickup and multiple > > pickups mixed. For many purposes, multiple pickups will be better... > > > >> I would suggest that we reserve the mixed attribute to scenarios > >> where a middle box mix audio captures from different endpoints. > > > > I don't believe it helpful to define "mixed" based on where the > > mixing is done. > > > > You raise a valid point about "mixing" audio from different rooms. > > This, indeed, is something to "hardly-ever" prefer. Thus, to me, I'd > > rather it not be an ordinary offer. > > > > When I describe "mixed" as a warning-label, I did not mean to > > infer that "mixed" means "low-quality". > > > > It sounds to me as if we should seriously consider including a > > description of _what_ is being mixed... > > > > -- > > John Leslie > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --047d7b15ae3b46135204bcb32c6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line

On Mon, Apr 2, 2012 at 9:52 AM, E= spen Berger (espeberg) <espeberg@cisco.com> wrote:
An audio mixing attribute is useful in the scenario where an MCU can
support both transcoding and =A0switching.

Given this scenario: A MCU supports transcoding and switching off audio
streams. The MCU can offer 3x loudest audio streams or 3x pre-mixed
audio streams that can be played out on left, Center, Right speakers.

Example advertisement
=A0AC1, AC2, AC3 audio_type =3D natural // Audio is switched between the natural sources
[sb] perhaps you mean "original&q= uot; sources?
Also, are you thinking that AC1, AC2, AC3 vary in their sp= atial position (that AC1 will suddenly switch from right to left???)

=A0AC4, AC5, AC6 audio_type =3D mixed // Audio is mixed into three fixed positions

=A0CaptureSet // AC4 - AC6 belongs together
=A0 { AC4, AC5, AC6 }
[sb] - I am wondering if you are implying that AC1, AC2, AC3 can not be adv= ertised in a capture set????
=A0
A consumer chooses either to request AC1 - AC3, does local mixing and
play out placement. If the endpoint chooses stream AC4 - AC6 the audio
should be played out on speaker that matches a left to right position.

In this scheme it might be better to have a multi value attribute
describing audio_type, to avoid the possible confusion multiple Boolean
might have.

Audio_type =3D =A0{ natural | mixed }
[sb] "natur= al" seems to imply that it is somehow preferred (that "mixed"= ; is somehow un-natural).
One benefit of the mixed version is that you a= re more likely to hear onset speech from participants who are not presently= seen (assuming I understand what switching algorithm you have in mind).
I am not yet convinced that we need signaling for this. Though if we ar= e thinking that a capture's spatial position can change w/o notice, tha= t might be worth further discussion. That will complicate Jonathan's di= saggregated media requirement.

Regards

-Espen


-----Original Message-----
From: clue-bounces@ietf.org [m= ailto:clue-bounces@ietf.org] O= n Behalf Of
Paul Kyzivat
Sent: 29. mars 2012 21:54
To: clue@ietf.org
Subject: Re: [clue] audio mixed attribute

I think you all have very cle= arly demonstrated that just being told that
a stream is mixed or not-mixed is insufficient to make any useful
decision about what to do with it.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul (as individual)

On 3/29/12 7:18 PM, John Leslie wrote:
> Espen Berger (espeberg)<espeb= erg@cisco.com> =A0wrote:
>>
>> John, you have listed a set of valid acoustical challenges which I=
>> recognize from our experience. Some of the acoustical challenges w= ill

>> be present if a room use 1 or 2+ microphones to record, e.g. when = a
>> person moves around in the room.
>
> =A0 =A0 This is true.
>
>> We should thrust endpoints that chooses to use multiple microphone= s
>> for capture to do proper audio pre-processing, and keep the audio<= br> quality.
>
> =A0 =A0 I do not intend anything other than trusting endpoint operator= s.
> But there are inherent differences between single-pickup and multiple<= br> > pickups mixed. For many purposes, multiple pickups will be better... >
>> I would suggest that we reserve the mixed attribute to scenarios >> where a middle box mix audio captures from different endpoints. >
> =A0 =A0 I don't believe it helpful to define "mixed" bas= ed on where the
> mixing is done.
>
> =A0 =A0 You raise a valid point about "mixing" audio from di= fferent rooms.
> This, indeed, is something to "hardly-ever" prefer. Thus, to= me, I'd
> rather it not be an ordinary offer.
>
> =A0 =A0 When I describe "mixed" as a warning-label, I did no= t mean to
> infer that "mixed" means "low-quality".
>
> =A0 =A0 It sounds to me as if we should seriously consider including a=
> description of _what_ is being mixed...
>
> --
> John Leslie<john@jlc.net> > _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--047d7b15ae3b46135204bcb32c6d-- From stephen.botzko@gmail.com Mon Apr 2 08:33:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736AF21F8584 for ; Mon, 2 Apr 2012 08:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8tYz+dA6zik for ; Mon, 2 Apr 2012 08:33:15 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E54F21F8581 for ; Mon, 2 Apr 2012 08:33:15 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2104641vbb.31 for ; Mon, 02 Apr 2012 08:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=duKUTQf/xJzo4Ux0ZRAZ6M3OmGDrwlH1LmruyhFRwuw=; b=i+03dgVdV6vTNCh4522a8XZ7nXEwzZl5y+YypmecaR9Q7qmqy7BCYhH6H6PDD7kVhx 50jIWC192jEig3qhp3iThyaqwna2A+WnNeUxPDAKrKy80rBa9f8HTHpOfn2wsmboF1BP 6fm+JLaqe27Gztv3YUN3Z+33zq0Om7dkB014msVQOv4vP6SYI6KLxpLeGohpHU2XZBKl YtjY/FquDOVLqQMzwldKntMAGaFnt0J6Xrh3R7hVypAIG/ZfjLcNggXRqVu+96rYhep3 xq7nFBkg7j1l8O8KzrmYxOpf6IO4luH7UMkBfy3FwrLimiDw4mUJdqOCSshOEJDjXIO3 awow== MIME-Version: 1.0 Received: by 10.52.91.16 with SMTP id ca16mr3375369vdb.125.1333380634976; Mon, 02 Apr 2012 08:30:34 -0700 (PDT) Received: by 10.52.70.174 with HTTP; Mon, 2 Apr 2012 08:30:34 -0700 (PDT) In-Reply-To: <20120329152600.GB67516@verdi> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com> <20120329152600.GB67516@verdi> Date: Mon, 2 Apr 2012 11:30:34 -0400 Message-ID: From: Stephen Botzko To: John Leslie Content-Type: multipart/alternative; boundary=20cf307f3be21921c604bcb3df68 Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:33:16 -0000 --20cf307f3be21921c604bcb3df68 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 29, 2012 at 11:26 AM, John Leslie wrote: > Duckworth, Mark wrote: > > > > Hi John, > > I'm trying to understand your view on labeling audio as mixed. > > Here is one example scenario that might help me understand. > > Suppose I am a provider, and I can capture and send audio in two > > different ways: > > Option 1: I can send one mono audio capture. It comes from one > > microphone element that picks up audio from the whole room. > > Option 2: I can send one mono audio capture. It comes from several > > microphone elements mixed together, that collectively pick > > up audio from the whole room. > > > > I think you are saying it would be useful to label option 1 as not > > mixed, and label option 2 as mixed. Is that correct? > > Yes. > > > What might a receiver do differently if it receives option 1 vs. > > receiving option 2? > > (To answer, I need to assume the receiver can to some degree choose > which to receive.) > > The receiver, for example, could reasonably guess that the "mixed" > version will have a more uniform level when speakers are in different > parts of the room. There's always a trade-off in applyinng level > "correction" in order to improve comprehension -- this might be more > necessary for the "unmixed" audio. > [sb] Whether level correction is useful depends on the actual level being received at the moment [and whether the original human speaker intended their whispered comment to be heard by everyone!]. I do not think that the pick-up pattern is the primary consideration here. In most telepresence rooms, the microphones are intentionally placed to give proper pickup of the entire room. So I would not make the guess that you are making. > > My concern, actually, is more with how to "audibly" "place" the > received audio in a virtual room. I believe the "mixed" version needs > to be given a less-distinct "place" than the "unmixed". YMMV, of course. > [sb]I don't really get this. How does the renderer give an audio stream a "less distinct" placement? And why would it do so? In my view, it gives every audio stream the placement it's capture information describes. In some cases, the audio might have better spatial separation than others. But I don't see how the renderer can determine this from a "mixed" attribute, and I certainly don't get how or why a renderer would post-process the streams differently. > > There's another issue, hopefully less abstruse: when working from > _both_ mixed and unmixed audio captures: the receiver needs to be > careful about mixing pre-mixed sources. > > The nature of sound is a very slow propagation rate in air: roughly > one foot per millisecond. The echo of blending sound from one speaker > with 100 millisecond propagation difference is obvious -- but the ear > can be confused by apparent acoustic effects with differences much > smaller than that. The human ear adjusts pretty well to different > acoustics if they're constant, but gets confused about apparent position > if these acoustic effects change unpredictably. > [sb] You are making an assumption here - in particular you are assuming that the audio mix done at the source does not take the propagation into account. I am not sure why you are envisioning that the source processing is naive, but the render processing is sophisticated. I do agree that the way the human ear perceives sound location is quite complex. With multiple loudspeakers, generally the first arriving sound dominates (which is a well known effect that auditorium sound-reinforcement systems use to their advantage). If the second sound arrives too late, it will not be fused, resulting in reverberance or even echo. Of course in Mark's scenario, the captured sound (from however many microphones) is converted to monophonic *at the source*. The apparent position of the audio stream will always be stable, as long as it is rendered consistently at the receiver. Multiple human voices within the capture will all sound like they are coming from the same place- which is artificial, but is also something we are all used to and hear every day in audio bridges. This perception does not depend on the number of microphones blended in the original capture. > > This is probably not anything most of us want to worry about in our > initial release: I am thinking ahead, hoping to avoid need to kludge > something later on. Folks are already used to "surround-sound" home > theatres: we should have some idea how to use such sound systems when > we get a round-tuit. ;^) > > [sb] I would agree here. Though my surround-sound system has no idea if the original sound comes from independent single microphones [or not]. The calibration in my receiver takes care of local delay and equalization issues due to the placement of my speakers in my room. The producer is responsible for providing sound tracks that sound appropriate when rendered in the standard speaker positions. I am imagining a similar model here. As long as the producer provides sound that is consistent with its advertisement for the streams, we should be fine. > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307f3be21921c604bcb3df68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 29, 2012 at 11:26 AM, John L= eslie <john@jlc.net> wrote:
Duckworth, Mark <Mark.Duckworth@polycom.com> wrote:
>
> Hi John,
> I'm trying to understand your view on labeling audio as mixed.
> Here is one example scenario that might help me understand.
> Suppose I am a provider, and I can capture and send audio in two
> different ways:
> Option 1: I can send one mono audio capture. =A0It comes from one
> =A0 =A0 =A0 =A0 =A0 microphone element that picks up audio from the wh= ole room.
> Option 2: I can send one mono audio capture. =A0It comes from several<= br> > =A0 =A0 =A0 =A0 =A0 microphone elements mixed together, that collectiv= ely pick
> =A0 =A0 =A0 =A0 =A0 up audio from the whole room.
>
> I think you are saying it would be useful to label option 1 as not
> mixed, and label option 2 as mixed. =A0Is that correct?

=A0 Yes.

> What might a receiver do differently if it receives option 1 vs.
> receiving option 2?

=A0 (To answer, I need to assume the receiver can to some degree cho= ose
which to receive.)

=A0 The receiver, for example, could reasonably guess that the "mixed= "
version will have a more uniform level when speakers are in different
parts of the room. There's always a trade-off in applyinng level
"correction" in order to improve comprehension -- this might be m= ore
necessary for the "unmixed" audio.
=A0
=
[sb] Whether level correction is useful depends on the actual level be= ing received at the moment [and whether the original human speaker intended= their whispered comment to be heard by everyone!].
I do not think that the pick-up pattern is the primary consideration here.= =A0 In most telepresence rooms, the microphones are intentionally placed to= give proper pickup of the entire room.=A0 So I would not make the guess th= at you are making.

=A0 My concern, actually, is more with how to "audibly" "pl= ace" the
received audio in a virtual room. I believe the "mixed" version n= eeds
to be given a less-distinct "place" than the "unmixed".= YMMV, of course.

[sb]I don't really get this.= =A0 How does the renderer give an audio stream a "less distinct" = placement?=A0 And why would it do so?
In my view, it gives every audio stream the placement it's capture info= rmation describes.=A0 In some cases, the audio might have better spatial se= paration than others.
But I don't see how the renderer can determin= e this from a "mixed" attribute, and I certainly don't get ho= w or why a renderer would post-process the streams differently.

=A0 There's another issue, hopefully less abstruse: when working from<= br> _both_ mixed and unmixed audio captures: the receiver needs to be
careful about mixing pre-mixed sources.

=A0 The nature of sound is a very slow propagation rate in air: roughly one foot per millisecond. The echo of blending sound from one speaker
with 100 millisecond propagation difference is obvious -- but the ear
can be confused by apparent acoustic effects with differences much
smaller than that. The human ear adjusts pretty well to different
acoustics if they're constant, but gets confused about apparent positio= n
if these acoustic effects change unpredictably.
=A0
[sb] You are making an assumption here - in particular you are assu= ming that the audio mix done at the source does not take the propagation in= to account. I am not sure why you are envisioning that the source processin= g is naive, but the render processing is sophisticated.

I do agree that the way the human ear perceives sound location is quite= complex.=A0 With multiple loudspeakers, generally the first arriving sound= dominates (which is a well known effect that auditorium sound-reinforcemen= t systems use to their advantage). If the second sound arrives too late, it= will not be fused, resulting in reverberance or even echo.

Of course in Mark's scenario, the captured sound (from however many= microphones) is converted to monophonic at the source. The apparent= position of the audio stream will always be stable, as long as it is rende= red consistently at the receiver.=A0 Multiple human voices within the captu= re will all sound like they are coming from the same place- which is artifi= cial, but is also something we are all used to and hear every day in audio = bridges.=A0 This perception does not depend on the number of microphones bl= ended in the original capture.

=A0 This is probably not anything most of us want to worry about in our initial release: I am thinking ahead, hoping to avoid need to kludge
something later on. Folks are already used to "surround-sound" ho= me
theatres: we should have some idea how to use such sound systems when
we get a round-tuit. ;^)

[= sb]=A0 I would agree here.=A0 Though my surround-sound system has no idea i= f the original sound comes from independent single microphones [or not].=A0= The calibration in my receiver takes care of local delay and equalization = issues due to the placement of my speakers in my room.=A0 The producer is r= esponsible for providing sound tracks that sound appropriate when rendered = in the standard speaker positions.=A0 I am imagining a similar model here.= =A0 As long as the producer provides sound that is consistent with its adve= rtisement for the streams, we should be fine.
--
John Leslie <john@jlc.net>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf307f3be21921c604bcb3df68-- From stephen.botzko@gmail.com Mon Apr 2 09:02:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD2621F8607 for ; Mon, 2 Apr 2012 09:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3MnRZ7zb21m for ; Mon, 2 Apr 2012 09:02:58 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B54F221F8604 for ; Mon, 2 Apr 2012 09:02:57 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2142097vcb.31 for ; Mon, 02 Apr 2012 09:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ow6esSWUbFHSI5PWpnuDyt3R/QLSoVpA1lFEQ9rsHKI=; b=MrAEC4Jquvh7DA+B8968+iCBFCviFHmi/VeSU4FUqub5Iuvuztlpkrjt78YE47x7wd fuj8UK6f8D+kOap1EokHMUdZfXI8NO5nm9/f9logL+wOtiHavZGyoDVVyTQYle8LC2WI uv4OZPksRP9xWAaZxPC+eTN2iIZYYNWkB78osRceJq0SEUuYBlHmdzIZ0u0an3O0l/aR 2S98isDNcAvTzLy8R43c0CuChKb3oH7XPtlFgHFHX++pmLAbh/+ZRlxxRz0vEyFdLW2h X2/USGwV4VvVraWdQDyN/bfdZ+Z1UOHm2GL3j6K7DpdzLA4yP3D6dLOhC75K91PF+NIT /g1Q== MIME-Version: 1.0 Received: by 10.220.140.200 with SMTP id j8mr4283634vcu.17.1333382577231; Mon, 02 Apr 2012 09:02:57 -0700 (PDT) Received: by 10.52.70.174 with HTTP; Mon, 2 Apr 2012 09:02:57 -0700 (PDT) In-Reply-To: <20120327223212.GC5206@verdi> References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> <20120327223212.GC5206@verdi> Date: Mon, 2 Apr 2012 12:02:57 -0400 Message-ID: From: Stephen Botzko To: John Leslie Content-Type: multipart/alternative; boundary=f46d04389369dd97a404bcb4520a Cc: clue@ietf.org Subject: Re: [clue] Steered microphone arrays X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:02:58 -0000 --f46d04389369dd97a404bcb4520a Content-Type: text/plain; charset=ISO-8859-1 in-line On Tue, Mar 27, 2012 at 6:32 PM, John Leslie wrote: > Stephen Botzko wrote: > > On Tue, Mar 27, 2012 at 6:12 AM, John Leslie wrote: > >> Stephen Botzko wrote: > >> > >>> [sb] Are you suggesting that every system using a steered microphone > >>> array would be tagged as "mixed"? > >> > >> Actually, yes: in the case of a steered _array_ of microphones, the > >> arrival-time information will be lost, just as in an audio mixer with > >> multiple microphones. > >> > >> This is distinct from the case of a steered "shotgun" microphone where > >> the mike position is fixed (though its directional pattern changes), > thus > >> arrival-time information is preserved. > >> > >> [sb] I believe steered microphone arrays are used commonly in sonar > >> acquisition, > > This is true... > > >> so I don't believe arrival time information has to be lost. > >> Usually the microphones in such an array are in fixed positions. > > As usual, the devil is in the details... > > In sonar, there's a very clearly-positioned sound source, and the > return times of the microphone array are calibrated to that source. > (Actually, the source likely produces a "chirp" of varying wavelength > and the phase differences are processed during the chirp response.) > > In our microphone array, the position of the sound source is > variable and there's no control of its wavelengths. It is technically > possible to compare phase information of several microphones and > process the sound output to that which "would be received" by a mike > at a given position (within the range of the microphone array, of > course); but if any existing system does that, I haven't heard of it. > [sb] we have built systems that do that, and that is exactly what I mean by a steerable array. > > Again, we're going to have to trust operators to set the "mixed" > bit: we can only offer guidance... > > -- > John Leslie > --f46d04389369dd97a404bcb4520a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line

On Tue, Mar 27, 2012 at 6:32 PM, = John Leslie <john@jlc.= net> wrote:
Stephen Botzko <stephen.botz= ko@gmail.com> wrote:
> On Tue, Mar 27, 2012 at 6:12 AM, John Leslie <john@jlc.net> wrote:
>> Stephen Botzko <ste= phen.botzko@gmail.com> wrote:
>>
>>> [sb] =A0Are you suggesting that every system using a steered m= icrophone
>>> array would be tagged as "mixed"?
>>
>> Actually, yes: in the case of a steered _array_ of microphones, th= e
>> arrival-time information will be lost, just as in an audio mixer w= ith
>> multiple microphones.
>>
>> This is distinct from the case of a steered "shotgun" mi= crophone where
>> the mike position is fixed (though its directional pattern changes= ), thus
>> arrival-time information is preserved.
>>
>> [sb] I believe steered microphone arrays are used commonly in sona= r
>> acquisition,

=A0 This is true...

>> so I don't believe arrival time information has to be lost. >> Usually the microphones in such an array are in fixed positions.
=A0 As usual, the devil is in the details...

=A0 In sonar, there's a very clearly-positioned sound source, and the<= br> return times of the microphone array are calibrated to that source.
(Actually, the source likely produces a "chirp" of varying wavele= ngth
and the phase differences are processed during the chirp response.)

=A0 In our microphone array, the position of the sound source is
variable and there's no control of its wavelengths. It is technically possible to compare phase information of several microphones and
process the sound output to that which "would be received" by a m= ike
at a given position (within the range of the microphone array, of
course); but if any existing system does that, I haven't heard of it.
[sb] we have built systems that do that, and that is ex= actly what I mean by a steerable array.

=A0 Again, we're going to have to trust operators to set the "mix= ed"
bit: we can only offer guidance...

--
John Leslie <john@jlc.net>

--f46d04389369dd97a404bcb4520a-- From espeberg@cisco.com Mon Apr 2 09:35:31 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4266821F8674 for ; Mon, 2 Apr 2012 09:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOauesPp+B-x for ; Mon, 2 Apr 2012 09:35:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3718B21F8668 for ; Mon, 2 Apr 2012 09:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=18739; q=dns/txt; s=iport; t=1333384516; x=1334594116; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=NZWYFAFI1Q2X/O3f4/PH0Vc3ZrSuk19SMDGY2NgGGsk=; b=QqVQslLfDvO7CHNtCa2e4WIsw+O1Wn3sd/g3seMY/PaFlqdbdHq7iS2A 7K6DY8sw+kQ6BpIl1y4Uv05Ka8Iit9df5VFyLtsJss116zoh+FM21kDiB 4gN6oBOqKs27MAOy1LRKtFtU/Tne5luDeAnEZ/jpxRsEw+XJ0TMuiSERQ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAODUeU+Q/khR/2dsb2JhbABFgka2JYEHggkBAQEDAQEBAQ8BCREDOAYLDAQCAQgRBAEBAQoGFwEGASAGHwkIAQEECgkIGodiBQubWZ5+BIoWhiNjBKEUgxSBaIJp X-IronPort-AV: E=Sophos;i="4.75,357,1330905600"; d="scan'208,217";a="134056990" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2012 16:35:14 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q32GZEV9031268; Mon, 2 Apr 2012 16:35:14 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 18:35:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD10EE.94905049" Date: Mon, 2 Apr 2012 18:35:13 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E0110F67B@XMB-AMS-214.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] audio mixed attribute Thread-Index: Ac0Q3p7FZ4i6qhfLQzyqCiPwL+EsIQACtSQQ References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com><20120329152600.GB67516@verdi><92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com><20120329171843.GC67516@verdi><4F74BDDD.1010100@alum.mit.edu><92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com> From: "Espen Berger (espeberg)" To: "Stephen Botzko" X-OriginalArrivalTime: 02 Apr 2012 16:35:14.0755 (UTC) FILETIME=[94C10130:01CD10EE] Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:35:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD10EE.94905049 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 With a natural source I mean a audio capture that is not changed from the original endpoint, through the switched MCU. An endpoint receiving multiple natural (or original) audio captures should be able to decode and mix together all audio streams, if not it should request the mixed audio capture where the MCU has already done that work. A receiving endpoint could also mix locally and play out the audio at the position matching the position of video from the same endpoint, e.g. by using SDES CNAME and/or SRCNAME.=20 =20 The rest of the comments inline =20 =20 -Espen=20 =20 =20 From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: 2. april 2012 16:41 To: Espen Berger (espeberg) Cc: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] audio mixed attribute =20 in-line On Mon, Apr 2, 2012 at 9:52 AM, Espen Berger (espeberg) wrote: An audio mixing attribute is useful in the scenario where an MCU can support both transcoding and switching. Given this scenario: A MCU supports transcoding and switching off audio streams. The MCU can offer 3x loudest audio streams or 3x pre-mixed audio streams that can be played out on left, Center, Right speakers. Example advertisement AC1, AC2, AC3 audio_type =3D natural // Audio is switched between the natural sources [sb] perhaps you mean "original" sources? [Espen] Original source might be a better name, should mean the same thing Also, are you thinking that AC1, AC2, AC3 vary in their spatial position (that AC1 will suddenly switch from right to left???)=20 [Espen] Yes. In a switched conference the audio captures does not need a fixed position. If the MCU chooses to replace the content in AC1 with endpoint A instead of B, the audio could be moved from right to left based on where the video is displayed. AC4, AC5, AC6 audio_type =3D mixed // Audio is mixed into three fixed positions =09 CaptureSet // AC4 - AC6 belongs together { AC4, AC5, AC6 } [sb] - I am wondering if you are implying that AC1, AC2, AC3 can not be advertised in a capture set???? [Espen] They can be in a capture set, but in this example they do not share any information. =20 =20 A consumer chooses either to request AC1 - AC3, does local mixing and play out placement. If the endpoint chooses stream AC4 - AC6 the audio should be played out on speaker that matches a left to right position. =09 In this scheme it might be better to have a multi value attribute describing audio_type, to avoid the possible confusion multiple Boolean might have. =09 Audio_type =3D { natural | mixed } [sb] "natural" seems to imply that it is somehow preferred (that "mixed" is somehow un-natural). One benefit of the mixed version is that you are more likely to hear onset speech from participants who are not presently seen (assuming I understand what switching algorithm you have in mind). [Espen] The MCU could use a N-loudest selection mechanism, so a receiver could receive the 5x loudest audio streams based on audio level. Audio level can be transferred in the RTP extension headers to avoid audio decoding on the server.=20 I am not yet convinced that we need signaling for this. Though if we are thinking that a capture's spatial position can change w/o notice, that might be worth further discussion. That will complicate Jonathan's disaggregated media requirement. [Espen] If not signalled, how do you differentiate between 'original' and 'mixed' audio?=20 =20 =09 Regards =09 -Espen =09 =09 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 29. mars 2012 21:54 To: clue@ietf.org Subject: Re: [clue] audio mixed attribute I think you all have very clearly demonstrated that just being told that a stream is mixed or not-mixed is insufficient to make any useful decision about what to do with it. =09 Thanks, Paul (as individual) =09 On 3/29/12 7:18 PM, John Leslie wrote: > Espen Berger (espeberg) wrote: >> >> John, you have listed a set of valid acoustical challenges which I >> recognize from our experience. Some of the acoustical challenges will =09 >> be present if a room use 1 or 2+ microphones to record, e.g. when a >> person moves around in the room. > > This is true. > >> We should thrust endpoints that chooses to use multiple microphones >> for capture to do proper audio pre-processing, and keep the audio quality. > > I do not intend anything other than trusting endpoint operators. > But there are inherent differences between single-pickup and multiple > pickups mixed. For many purposes, multiple pickups will be better... > >> I would suggest that we reserve the mixed attribute to scenarios >> where a middle box mix audio captures from different endpoints. > > I don't believe it helpful to define "mixed" based on where the > mixing is done. > > You raise a valid point about "mixing" audio from different rooms. > This, indeed, is something to "hardly-ever" prefer. Thus, to me, I'd > rather it not be an ordinary offer. > > When I describe "mixed" as a warning-label, I did not mean to > infer that "mixed" means "low-quality". > > It sounds to me as if we should seriously consider including a > description of _what_ is being mixed... > > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > =09 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CD10EE.94905049 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

With a natural source I mean a audio capture that is not changed from = the original endpoint, through the switched MCU. An endpoint receiving = multiple natural (or original) audio captures should be able to decode = and mix together all audio streams, if not it should request the mixed = audio capture where the MCU has already done that work. A receiving = endpoint could also mix locally and play out the audio at the position = matching the position of video from the same endpoint, e.g. by using = SDES CNAME and/or SRCNAME.

 

The rest of the comments inline 

 

-Espen

 

 

From:= Stephen = Botzko [mailto:stephen.botzko@gmail.com]
Sent: 2. april 2012 = 16:41
To: Espen Berger (espeberg)
Cc: Paul Kyzivat; = clue@ietf.org
Subject: Re: [clue] audio mixed = attribute

 

in-line

On Mon, Apr 2, 2012 at 9:52 AM, Espen Berger = (espeberg) <espeberg@cisco.com> = wrote:

An audio mixing attribute is = useful in the scenario where an MCU can
support both transcoding and =  switching.

Given this scenario: A MCU supports transcoding = and switching off audio
streams. The MCU can offer 3x loudest audio = streams or 3x pre-mixed
audio streams that can be played out on left, = Center, Right speakers.

Example advertisement
 AC1, AC2, = AC3 audio_type =3D natural // Audio is switched between the
natural = sources

[sb] perhaps you mean = "original" sources?
[Espen] = Original source might be a better name, should mean the same = thing

Also, are you thinking that AC1, AC2, AC3 = vary in their spatial position (that AC1 will suddenly switch from right = to left???)
[Espen] Yes. In a switched = conference the audio captures does not need a fixed position. If the MCU = chooses to replace the content in AC1 with endpoint A instead of B, the = audio could be moved from right to left based on where the video is = displayed.

 AC4, AC5, AC6 audio_type =3D mixed // Audio is = mixed into three fixed
positions

 CaptureSet // AC4 - AC6 = belongs together
  { AC4, AC5, AC6 }
[sb] - I am wondering if = you are implying that AC1, AC2, AC3 can not be advertised in a capture = set????
[Espen] They can be in a = capture set, but in this example they do not share any information. =  

 

A = consumer chooses either to request AC1 - AC3, does local mixing = and
play out placement. If the endpoint chooses stream AC4 - AC6 the = audio
should be played out on speaker that matches a left to right = position.

In this scheme it might be better to have a multi value = attribute
describing audio_type, to avoid the possible confusion = multiple Boolean
might have.

Audio_type =3D  { natural | = mixed }

[sb] = "natural" seems to imply that it is somehow preferred (that = "mixed" is somehow un-natural).
One benefit of the mixed = version is that you are more likely to hear onset speech from = participants who are not presently seen (assuming I understand what = switching algorithm you have in mind).

[Espen] The MCU could use a N-loudest selection mechanism, so a = receiver could receive the 5x loudest audio streams based on audio = level. Audio level can be transferred in the RTP extension headers to = avoid audio decoding on the server.

I am not yet = convinced that we need signaling for this. Though if we are thinking = that a capture's spatial position can change w/o notice, that might be = worth further discussion. That will complicate Jonathan's disaggregated = media requirement.
[Espen] If not = signalled, how do you differentiate between ‘original’ and = ‘mixed’ audio?

 


Regards


-Espen


-----Original = Message-----
From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On = Behalf Of

Paul Kyzivat
Sent: 29. mars 2012 = 21:54
To: clue@ietf.org
Subject: Re: [clue] = audio mixed attribute

I think you all have very clearly demonstrated that = just being told that
a stream is mixed or not-mixed is insufficient = to make any useful
decision about what to do with it.

  =      Thanks,
       Paul (as = individual)

On 3/29/12 7:18 PM, John Leslie wrote:
> Espen = Berger (espeberg)<espeberg@cisco.com> =  wrote:
>>
>> John, you have listed a set of = valid acoustical challenges which I
>> recognize from our = experience. Some of the acoustical challenges will

>> be = present if a room use 1 or 2+ microphones to record, e.g. when = a
>> person moves around in the room.
>
>   =   This is true.
>
>> We should thrust endpoints that = chooses to use multiple microphones
>> for capture to do proper = audio pre-processing, and keep the audio
quality.
>
> =     I do not intend anything other than trusting endpoint = operators.
> But there are inherent differences between = single-pickup and multiple
> pickups mixed. For many purposes, = multiple pickups will be better...
>
>> I would suggest = that we reserve the mixed attribute to scenarios
>> where a = middle box mix audio captures from different endpoints.
>
> =     I don't believe it helpful to define "mixed" = based on where the
> mixing is done.
>
>     = You raise a valid point about "mixing" audio from different = rooms.
> This, indeed, is something to "hardly-ever" = prefer. Thus, to me, I'd
> rather it not be an ordinary = offer.
>
>     When I describe "mixed" = as a warning-label, I did not mean to
> infer that = "mixed" means "low-quality".
>
>   =   It sounds to me as if we should seriously consider including = a
> description of _what_ is being mixed...
>
> = --
> John Leslie<john@jlc.net>
> = _______________________________________________
> clue mailing = list
> clue@ietf.org
> = https://www.ietf.org/mailman/listinfo/clue
><= br>
_______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue
_____= __________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

------_=_NextPart_001_01CD10EE.94905049-- From stephen.botzko@gmail.com Mon Apr 2 09:49:33 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A1921F86AF for ; Mon, 2 Apr 2012 09:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChVf4cHVSZhm for ; Mon, 2 Apr 2012 09:49:31 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A033421F85E7 for ; Mon, 2 Apr 2012 09:49:31 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2170816vbb.31 for ; Mon, 02 Apr 2012 09:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nSufE9zUdfiCD1hRGe0iFtP50WyY+1O+XGhflOR/nKk=; b=djXGSTo7ifJGvJcDBQGdJrFHGWzk14H/Jv+/gNLu7Y5R66QMacgm89pXF7lAWxm89z d5eXX1MsgLG6BKpnH4qtBkn/9C5SK+nJ/FN4Fwy5kSPK+M+xyR/Z1zVrcty6IZqCYlOB B9+b9DIQ7WH//+j+OdWSc3cCWcntRawbGGiWlTt++ToLBS0e27PjaZD33F5Y3N0e3WVE b5hAbzivTNDrEAH1WnV1XshWbmKxu5wS2jrUOhjU0qDYz43kB7AkE0cJa3SLshJt4BOm lZTtkaoOcVCUPv8S5DdViydq9JswdeSVOGET/E+Zd0nNqHpWGCLW+v2HbeVf4HaxdBq2 18rA== MIME-Version: 1.0 Received: by 10.52.91.16 with SMTP id ca16mr3485414vdb.125.1333385371154; Mon, 02 Apr 2012 09:49:31 -0700 (PDT) Received: by 10.52.70.174 with HTTP; Mon, 2 Apr 2012 09:49:31 -0700 (PDT) In-Reply-To: <92DF9533227FC14F946C7321074B8C9E0110F67B@XMB-AMS-214.cisco.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com> <20120329152600.GB67516@verdi> <92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com> <20120329171843.GC67516@verdi> <4F74BDDD.1010100@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0110F67B@XMB-AMS-214.cisco.com> Date: Mon, 2 Apr 2012 12:49:31 -0400 Message-ID: From: Stephen Botzko To: "Espen Berger (espeberg)" Content-Type: multipart/alternative; boundary=20cf307f3be26579a304bcb4f9ae Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:49:33 -0000 --20cf307f3be26579a304bcb4f9ae Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [Espen] If not signalled, how do you differentiate between =91original=92 a= nd =91mixed=92 audio? I am not sure we need to differentiate them. We don't have any use cases that show the need. However, if some switched captures can suddenly change position (whether audio or video), then we do have a problem I think we agreed to Jonathan's RTP requirement that disaggregated receivers needed to receive the capture attributes prior to receiving the first RTP packet. Also, that it needed to be possible to direct left, right, center streams to different transport addresses, so they could be sent to specific decoder instances running in dedicated hardware. Changing a capture position on the fly would therefore also imply changing its destination transport address w/o signaling. Using an "original" or "mixed" attribute doesn't accomplish those requirements, so changing position on the fly needs more discussion. Stephen Botzko On Mon, Apr 2, 2012 at 12:35 PM, Espen Berger (espeberg) wrote: > ** ** > > With a natural source I mean a audio capture that is not changed from the > original endpoint, through the switched MCU. An endpoint receiving multip= le > natural (or original) audio captures should be able to decode and mix > together all audio streams, if not it should request the mixed audio > capture where the MCU has already done that work. A receiving endpoint > could also mix locally and play out the audio at the position matching th= e > position of video from the same endpoint, e.g. by using SDES CNAME and/or > SRCNAME. **** > > ** ** > > The rest of the comments inline **** > > ** ** > > -Espen **** > > ** ** > > ** ** > > *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Sent:* 2. april 2012 16:41 > *To:* Espen Berger (espeberg) > *Cc:* Paul Kyzivat; clue@ietf.org > > *Subject:* Re: [clue] audio mixed attribute**** > > ** ** > > in-line**** > > On Mon, Apr 2, 2012 at 9:52 AM, Espen Berger (espeberg) < > espeberg@cisco.com> wrote:**** > > An audio mixing attribute is useful in the scenario where an MCU can > support both transcoding and switching. > > Given this scenario: A MCU supports transcoding and switching off audio > streams. The MCU can offer 3x loudest audio streams or 3x pre-mixed > audio streams that can be played out on left, Center, Right speakers. > > Example advertisement > AC1, AC2, AC3 audio_type =3D natural // Audio is switched between the > natural sources**** > > [sb] perhaps you mean "original" sources? > > [Espen] Original source might be a better name, should mean the same thin= g > **** > > Also, are you thinking that AC1, AC2, AC3 vary in their spatial position > (that AC1 will suddenly switch from right to left???) > > [Espen] Yes. In a switched conference the audio captures does not need a > fixed position. If the MCU chooses to replace the content in AC1 with > endpoint A instead of B, the audio could be moved from right to left base= d > on where the video is displayed.**** > > AC4, AC5, AC6 audio_type =3D mixed // Audio is mixed into three fixed > positions > > CaptureSet // AC4 - AC6 belongs together > { AC4, AC5, AC6 } > [sb] - I am wondering if you are implying that AC1, AC2, AC3 can not be > advertised in a capture set???? > > [Espen] They can be in a capture set, but in this example they do not > share any information. **** > > **** > > A consumer chooses either to request AC1 - AC3, does local mixing and > play out placement. If the endpoint chooses stream AC4 - AC6 the audio > should be played out on speaker that matches a left to right position. > > In this scheme it might be better to have a multi value attribute > describing audio_type, to avoid the possible confusion multiple Boolean > might have. > > Audio_type =3D { natural | mixed }**** > > [sb] "natural" seems to imply that it is somehow preferred (that "mixed" > is somehow un-natural). > One benefit of the mixed version is that you are more likely to hear onse= t > speech from participants who are not presently seen (assuming I understan= d > what switching algorithm you have in mind).**** > > [Espen] The MCU could use a N-loudest selection mechanism, so a receiver > could receive the 5x loudest audio streams based on audio level. Audio > level can be transferred in the RTP extension headers to avoid audio > decoding on the server. > > I am not yet convinced that we need signaling for this. Though if we are > thinking that a capture's spatial position can change w/o notice, that > might be worth further discussion. That will complicate Jonathan's > disaggregated media requirement. > > [Espen] If not signalled, how do you differentiate between =91original=92= and > =91mixed=92 audio? **** > > ** ** > > > Regards**** > > > -Espen > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of**= * > * > > Paul Kyzivat > Sent: 29. mars 2012 21:54 > To: clue@ietf.org > Subject: Re: [clue] audio mixed attribute**** > > I think you all have very clearly demonstrated that just being told that > a stream is mixed or not-mixed is insufficient to make any useful > decision about what to do with it. > > Thanks, > Paul (as individual) > > On 3/29/12 7:18 PM, John Leslie wrote: > > Espen Berger (espeberg) wrote: > >> > >> John, you have listed a set of valid acoustical challenges which I > >> recognize from our experience. Some of the acoustical challenges will > > >> be present if a room use 1 or 2+ microphones to record, e.g. when a > >> person moves around in the room. > > > > This is true. > > > >> We should thrust endpoints that chooses to use multiple microphones > >> for capture to do proper audio pre-processing, and keep the audio > quality. > > > > I do not intend anything other than trusting endpoint operators. > > But there are inherent differences between single-pickup and multiple > > pickups mixed. For many purposes, multiple pickups will be better... > > > >> I would suggest that we reserve the mixed attribute to scenarios > >> where a middle box mix audio captures from different endpoints. > > > > I don't believe it helpful to define "mixed" based on where the > > mixing is done. > > > > You raise a valid point about "mixing" audio from different rooms. > > This, indeed, is something to "hardly-ever" prefer. Thus, to me, I'd > > rather it not be an ordinary offer. > > > > When I describe "mixed" as a warning-label, I did not mean to > > infer that "mixed" means "low-quality". > > > > It sounds to me as if we should seriously consider including a > > description of _what_ is being mixed... > > > > -- > > John Leslie > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --20cf307f3be26579a304bcb4f9ae Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [Espen] If not signalled, how do you differen= tiate between =91original=92 and =91mixed=92 audio?
I am not sure we ne= ed to differentiate them.=A0 We don't have any use cases that show the = need.

However, if some switched captures can suddenly change position (whethe= r audio or video), then we do have a problem=A0=A0 I think we agreed to Jon= athan's RTP requirement that disaggregated receivers needed to receive = the capture attributes prior to receiving the first RTP packet.=A0 Also, th= at it needed to be possible to direct left, right, center streams to differ= ent transport addresses, so they could be sent to specific decoder instance= s running in dedicated hardware.=A0 Changing a capture position on the fly = would therefore also imply changing its destination transport address w/o s= ignaling.=A0 Using an "original" or "mixed" attribute d= oesn't accomplish those requirements, so changing position on the fly n= eeds more discussion.

Stephen Botzko

On Mon, Apr 2, = 2012 at 12:35 PM, Espen Berger (espeberg) <espeberg@cisco.com> wrote:

=A0

With a natural source I mean a audio capt= ure that is not changed from the original endpoint, through the switched MC= U. An endpoint receiving multiple natural (or original) audio captures shou= ld be able to decode and mix together all audio streams, if not it should r= equest the mixed audio capture where the MCU has already done that work. A = receiving endpoint could also mix locally and play out the audio at the pos= ition matching the position of video from the same endpoint, e.g. by using = SDES CNAME and/or SRCNAME.

=A0<= /p>

The rest of the commen= ts inline=A0

=A0<= /p>

-Espen <= /span>

=A0<= /p>

=A0

From:<= /b> Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: 2. april 2012 16:41
To: Espen Berger (espeberg)
<= b>Cc: Paul Kyzivat; = clue@ietf.org


Subject: Re: [clue= ] audio mixed attribute

=A0

in-line

On Mon, Apr 2, 2012 at 9:52 AM, Espen Berge= r (espeberg) <es= peberg@cisco.com> wrote:

An audio mixing attribute is useful in the scenario = where an MCU can
support both transcoding and =A0switching.

Given= this scenario: A MCU supports transcoding and switching off audio
strea= ms. The MCU can offer 3x loudest audio streams or 3x pre-mixed
audio streams that can be played out on left, Center, Right speakers.
Example advertisement
=A0AC1, AC2, AC3 audio_type =3D natural // Audio= is switched between the
natural sources

[sb] perhaps you mean "original" sources?
[Espen] Original source might be a be= tter name, should mean the same thing

Also, are you thinking that AC1, AC2, AC3 vary in the= ir spatial position (that AC1 will suddenly switch from right to left???) <= /div>
[Espen] Yes. In a switched conferenc= e the audio captures does not need a fixed position. If the MCU chooses to = replace the content in AC1 with endpoint A instead of B, the audio could be= moved from right to left based on where the video is displayed.<= /u>

=A0AC4, AC5, AC6 audio_type =3D mixed // Au= dio is mixed into three fixed
positions

=A0CaptureSet // AC4 - AC6 belongs together
=A0 { AC4, = AC5, AC6 }
[sb] - I am wondering if you are implying that AC1, AC2, AC3 = can not be advertised in a capture set????

[Espen] They can be in a capture set, but in this example they do not share= any information. =A0

=A0

A consumer chooses either to request AC1 - AC3, does= local mixing and
play out placement. If the endpoint chooses stream AC4= - AC6 the audio
should be played out on speaker that matches a left to = right position.

In this scheme it might be better to have a multi value attribute
de= scribing audio_type, to avoid the possible confusion multiple Boolean
mi= ght have.

Audio_type =3D =A0{ natural | mixed }

[sb] "natural"= ; seems to imply that it is somehow preferred (that "mixed" is so= mehow un-natural).
One benefit of the mixed version is that you are more= likely to hear onset speech from participants who are not presently seen (= assuming I understand what switching algorithm you have in mind).

[Espen] The MCU cou= ld use a N-loudest selection mechanism, so a receiver could receive the 5x = loudest audio streams based on audio level. Audio level can be transferred = in the RTP extension headers to avoid audio decoding on the server. =


I am not yet convinced that we need signaling for= this. Though if we are thinking that a capture's spatial position can = change w/o notice, that might be worth further discussion. That will compli= cate Jonathan's disaggregated media requirement.

[Espen] If not signalled, how do you diff= erentiate between =91original=92 and =91mixed=92 audio?

=A0


Regards


-Espen


-----Original Message-----
From: clue-bounces@ietf.org [mailto= :clue-bounces@ie= tf.org] On Behalf Of

Paul Kyziv= at
Sent: 29. mars 2012 21:54
To: clue@ietf.org
Subject: Re: [clue] audio mixed attribu= te

I think you all have very clearly de= monstrated that just being told that
a stream is mixed or not-mixed is i= nsufficient to make any useful
decision about what to do with it.
=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul (as individual)

On 3/2= 9/12 7:18 PM, John Leslie wrote:
> Espen Berger (espeberg)<espeberg@cisco.com>= =A0wrote:
>>
>> John, you have listed a set of valid acoustical challenges which I=
>> recognize from our experience. Some of the acoustical challeng= es will

>> be present if a room use 1 or 2+ microphones to rec= ord, e.g. when a
>> person moves around in the room.
>
> =A0 =A0 This is t= rue.
>
>> We should thrust endpoints that chooses to use mul= tiple microphones
>> for capture to do proper audio pre-processing= , and keep the audio
quality.
>
> =A0 =A0 I do not intend anything other than trusti= ng endpoint operators.
> But there are inherent differences between s= ingle-pickup and multiple
> pickups mixed. For many purposes, multipl= e pickups will be better...
>
>> I would suggest that we reserve the mixed attribute to sce= narios
>> where a middle box mix audio captures from different end= points.
>
> =A0 =A0 I don't believe it helpful to define &q= uot;mixed" based on where the
> mixing is done.
>
> =A0 =A0 You raise a valid point about = "mixing" audio from different rooms.
> This, indeed, is som= ething to "hardly-ever" prefer. Thus, to me, I'd
> rath= er it not be an ordinary offer.
>
> =A0 =A0 When I describe "mixed" as a warning-label, = I did not mean to
> infer that "mixed" means "low-qual= ity".
>
> =A0 =A0 It sounds to me as if we should seriousl= y consider including a
> description of _what_ is being mixed...
>
> --
> Joh= n Leslie<john@jlc.net<= /a>>
> _______________________________________________
> clu= e mailing list
> clue@ietf.org> https://www.ietf.org/mailman/listinfo/clue
>

________= _______________________________________
clue mailing list
clu= e@ietf.org
https://www.ietf.org/mailman/listinfo/clue
_________= ______________________________________
clue mailing list
clu= e@ietf.org
https://www.ietf.org/mailman/listinfo/clue

= =A0


--20cf307f3be26579a304bcb4f9ae-- From espeberg@cisco.com Mon Apr 2 12:28:53 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239B021F86C2 for ; Mon, 2 Apr 2012 12:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qNpXHft5RV4 for ; Mon, 2 Apr 2012 12:28:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5A36321F86BE for ; Mon, 2 Apr 2012 12:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=28510; q=dns/txt; s=iport; t=1333394927; x=1334604527; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=S7naRk6m4/iyMPswWbAoGtYIXwpNnhZkX1rKVdKrmtg=; b=jZXJUfpBNkK1UOtyPAtel3OXLgpaNeP+swu0NuZ3DcYXSj2rrPrV95Kl ZRePZ3ln7oCkjCrZwyp8C+NPpSzxzaDOU3sbR9KFFMQFDf1joocuM959n EIMkswfRXX68PWYQXHOfEqhmA28GFuJgEIBx1kWpNI1e4hYzlyHwdHxj2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHz4eU+Q/khL/2dsb2JhbABFgka1NoEHggkBAQEDAQEBAQ8BCREDOAYLDAQCAQgRBAEBAQoGEAcBBgEgBh8JCAEBBAoJCBqHYgULm0mfCwSKFoV1YwShFIMUgWiCaQ X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208,217";a="134070571" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2012 19:28:44 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q32JSiqr010836; Mon, 2 Apr 2012 19:28:44 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 21:28:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1106.D111D545" Date: Mon, 2 Apr 2012 21:28:43 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E0110F68F@XMB-AMS-214.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] audio mixed attribute Thread-Index: Ac0Q8J8EfU5sx56ITYKwtKo3OfTvxAAFHR5A References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com><20120329152600.GB67516@verdi><92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com><20120329171843.GC67516@verdi><4F74BDDD.1010100@alum.mit.edu><92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com><92DF9533227FC14F946C7321074B8C9E0110F67B@XMB-AMS-214.cisco.com> From: "Espen Berger (espeberg)" To: "Stephen Botzko" X-OriginalArrivalTime: 02 Apr 2012 19:28:44.0036 (UTC) FILETIME=[D12B3C40:01CD1106] Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 19:28:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1106.D111D545 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An MCU can basically give me two types of audio streams,=20 * Mixed - The MCU mixes together audio and deliver a single audio stream based on some MCU cleverness=20 * Original - The MCU forward a audio stream un-modified from the source (based on VAD-level selection) =20 The purpose of the audio_type is only to make this distinction.=20 =20 How to model and implement various spatial audio scenarios need further discussions, not the audio-type attribute.=20 =20 -Espen=20 =20 =20 From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: 2. april 2012 18:50 To: Espen Berger (espeberg) Cc: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] audio mixed attribute =20 [Espen] If not signalled, how do you differentiate between 'original' and 'mixed' audio?=20 I am not sure we need to differentiate them. We don't have any use cases that show the need. However, if some switched captures can suddenly change position (whether audio or video), then we do have a problem I think we agreed to Jonathan's RTP requirement that disaggregated receivers needed to receive the capture attributes prior to receiving the first RTP packet. Also, that it needed to be possible to direct left, right, center streams to different transport addresses, so they could be sent to specific decoder instances running in dedicated hardware. Changing a capture position on the fly would therefore also imply changing its destination transport address w/o signaling. Using an "original" or "mixed" attribute doesn't accomplish those requirements, so changing position on the fly needs more discussion. Stephen Botzko On Mon, Apr 2, 2012 at 12:35 PM, Espen Berger (espeberg) wrote: =20 With a natural source I mean a audio capture that is not changed from the original endpoint, through the switched MCU. An endpoint receiving multiple natural (or original) audio captures should be able to decode and mix together all audio streams, if not it should request the mixed audio capture where the MCU has already done that work. A receiving endpoint could also mix locally and play out the audio at the position matching the position of video from the same endpoint, e.g. by using SDES CNAME and/or SRCNAME.=20 =20 The rest of the comments inline =20 =20 -Espen=20 =20 =20 From: Stephen Botzko [mailto:stephen.botzko@gmail.com]=20 Sent: 2. april 2012 16:41 To: Espen Berger (espeberg) Cc: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] audio mixed attribute =20 in-line On Mon, Apr 2, 2012 at 9:52 AM, Espen Berger (espeberg) wrote: An audio mixing attribute is useful in the scenario where an MCU can support both transcoding and switching. Given this scenario: A MCU supports transcoding and switching off audio streams. The MCU can offer 3x loudest audio streams or 3x pre-mixed audio streams that can be played out on left, Center, Right speakers. Example advertisement AC1, AC2, AC3 audio_type =3D natural // Audio is switched between the natural sources [sb] perhaps you mean "original" sources? [Espen] Original source might be a better name, should mean the same thing Also, are you thinking that AC1, AC2, AC3 vary in their spatial position (that AC1 will suddenly switch from right to left???)=20 [Espen] Yes. In a switched conference the audio captures does not need a fixed position. If the MCU chooses to replace the content in AC1 with endpoint A instead of B, the audio could be moved from right to left based on where the video is displayed. AC4, AC5, AC6 audio_type =3D mixed // Audio is mixed into three fixed positions =09 CaptureSet // AC4 - AC6 belongs together { AC4, AC5, AC6 } [sb] - I am wondering if you are implying that AC1, AC2, AC3 can not be advertised in a capture set???? =09 [Espen] They can be in a capture set, but in this example they do not share any information. =20 =20 A consumer chooses either to request AC1 - AC3, does local mixing and play out placement. If the endpoint chooses stream AC4 - AC6 the audio should be played out on speaker that matches a left to right position. =09 In this scheme it might be better to have a multi value attribute describing audio_type, to avoid the possible confusion multiple Boolean might have. =09 Audio_type =3D { natural | mixed } [sb] "natural" seems to imply that it is somehow preferred (that "mixed" is somehow un-natural). One benefit of the mixed version is that you are more likely to hear onset speech from participants who are not presently seen (assuming I understand what switching algorithm you have in mind). [Espen] The MCU could use a N-loudest selection mechanism, so a receiver could receive the 5x loudest audio streams based on audio level. Audio level can be transferred in the RTP extension headers to avoid audio decoding on the server.=20 I am not yet convinced that we need signaling for this. Though if we are thinking that a capture's spatial position can change w/o notice, that might be worth further discussion. That will complicate Jonathan's disaggregated media requirement. [Espen] If not signalled, how do you differentiate between 'original' and 'mixed' audio?=20 =20 =09 Regards =09 -Espen =09 =09 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 29. mars 2012 21:54 To: clue@ietf.org Subject: Re: [clue] audio mixed attribute I think you all have very clearly demonstrated that just being told that a stream is mixed or not-mixed is insufficient to make any useful decision about what to do with it. =09 Thanks, Paul (as individual) =09 On 3/29/12 7:18 PM, John Leslie wrote: > Espen Berger (espeberg) wrote: >> >> John, you have listed a set of valid acoustical challenges which I >> recognize from our experience. Some of the acoustical challenges will =09 >> be present if a room use 1 or 2+ microphones to record, e.g. when a >> person moves around in the room. > > This is true. > >> We should thrust endpoints that chooses to use multiple microphones >> for capture to do proper audio pre-processing, and keep the audio quality. > > I do not intend anything other than trusting endpoint operators. > But there are inherent differences between single-pickup and multiple > pickups mixed. For many purposes, multiple pickups will be better... > >> I would suggest that we reserve the mixed attribute to scenarios >> where a middle box mix audio captures from different endpoints. > > I don't believe it helpful to define "mixed" based on where the > mixing is done. > > You raise a valid point about "mixing" audio from different rooms. > This, indeed, is something to "hardly-ever" prefer. Thus, to me, I'd > rather it not be an ordinary offer. > > When I describe "mixed" as a warning-label, I did not mean to > infer that "mixed" means "low-quality". > > It sounds to me as if we should seriously consider including a > description of _what_ is being mixed... > > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > =09 _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 =20 ------_=_NextPart_001_01CD1106.D111D545 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An MCU can basically give me two types of audio streams, =

·         = Mixed – The MCU mixes together audio and deliver a single audio = stream based on some MCU cleverness

·         = Original – The MCU forward a audio stream un-modified from the = source (based on VAD-level selection)

 

The purpose of the audio_type is only to make this distinction. =

 

How to model and implement various spatial audio scenarios need = further discussions, not the audio-type attribute. =

 

-Espen

 

 

From:= Stephen = Botzko [mailto:stephen.botzko@gmail.com]
Sent: 2. april 2012 = 18:50
To: Espen Berger (espeberg)
Cc: Paul Kyzivat; = clue@ietf.org
Subject: Re: [clue] audio mixed = attribute

 

[Espen] If = not signalled, how do you differentiate between ‘original’ = and ‘mixed’ audio?
I am not sure we need to = differentiate them.  We don't have any use cases that show the = need.

However, if some switched captures can suddenly change = position (whether audio or video), then we do have a problem   = I think we agreed to Jonathan's RTP requirement that disaggregated = receivers needed to receive the capture attributes prior to receiving = the first RTP packet.  Also, that it needed to be possible to = direct left, right, center streams to different transport addresses, so = they could be sent to specific decoder instances running in dedicated = hardware.  Changing a capture position on the fly would therefore = also imply changing its destination transport address w/o = signaling.  Using an "original" or "mixed" = attribute doesn't accomplish those requirements, so changing position on = the fly needs more discussion.


Stephen = Botzko

On Mon, Apr 2, = 2012 at 12:35 PM, Espen Berger (espeberg) <espeberg@cisco.com> = wrote:

 

With a natural source I mean a audio capture that is not changed from = the original endpoint, through the switched MCU. An endpoint receiving = multiple natural (or original) audio captures should be able to decode = and mix together all audio streams, if not it should request the mixed = audio capture where the MCU has already done that work. A receiving = endpoint could also mix locally and play out the audio at the position = matching the position of video from the same endpoint, e.g. by using = SDES CNAME and/or SRCNAME.

 

The rest of the comments inline 

 

-Espen

 

 

From:= Stephen = Botzko [mailto:stephen.botzko@gmail.com]
Sent: 2. = april 2012 16:41
To: Espen Berger (espeberg)
Cc: = Paul Kyzivat; clue@ietf.org


Subject: Re: [clue] audio mixed = attribute

 <= /o:p>

in-line=

On Mon, Apr = 2, 2012 at 9:52 AM, Espen Berger (espeberg) <espeberg@cisco.com> wrote:

An audio = mixing attribute is useful in the scenario where an MCU can
support = both transcoding and  switching.

Given this scenario: A MCU = supports transcoding and switching off audio
streams. The MCU can = offer 3x loudest audio streams or 3x pre-mixed
audio streams that can = be played out on left, Center, Right speakers.

Example = advertisement
 AC1, AC2, AC3 audio_type =3D natural // Audio is = switched between the
natural sources

[sb] perhaps you mean "original" = sources?


[Espen] Original source might be a better = name, should mean the same thing

Also, are you thinking that AC1, AC2, AC3 vary in = their spatial position (that AC1 will suddenly switch from right to = left???)


[Espen] Yes. In a switched conference the = audio captures does not need a fixed position. If the MCU chooses to = replace the content in AC1 with endpoint A instead of B, the audio could = be moved from right to left based on where the video is = displayed.

 AC4, AC5, AC6 audio_type =3D mixed = // Audio is mixed into three fixed
positions

 CaptureSet = // AC4 - AC6 belongs together
  { AC4, AC5, AC6 }
[sb] - I am = wondering if you are implying that AC1, AC2, AC3 can not be advertised = in a capture set????


[Espen] They can be in a capture set, but in = this example they do not share any information. =  

 <= /o:p>

A consumer = chooses either to request AC1 - AC3, does local mixing and
play out = placement. If the endpoint chooses stream AC4 - AC6 the audio
should = be played out on speaker that matches a left to right = position.

In this scheme it might be better to have a multi value = attribute
describing audio_type, to avoid the possible confusion = multiple Boolean
might have.

Audio_type =3D  { natural | = mixed }

[sb] = "natural" seems to imply that it is somehow preferred (that = "mixed" is somehow un-natural).
One benefit of the mixed = version is that you are more likely to hear onset speech from = participants who are not presently seen (assuming I understand what = switching algorithm you have in mind).

[Espen] The MCU could use a N-loudest selection mechanism, so a = receiver could receive the 5x loudest audio streams based on audio = level. Audio level can be transferred in the RTP extension headers to = avoid audio decoding on the server.


I am not yet convinced that we need signaling for = this. Though if we are thinking that a capture's spatial position can = change w/o notice, that might be worth further discussion. That will = complicate Jonathan's disaggregated media = requirement.


[Espen] If not signalled, how do you = differentiate between ‘original’ and ‘mixed’ = audio?

 


Regards<= o:p>


-Espen

-----Original Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of

Paul = Kyzivat
Sent: 29. mars 2012 21:54
To: clue@ietf.org
Subject: Re: [clue] audio mixed = attribute

I think you = all have very clearly demonstrated that just being told that
a stream = is mixed or not-mixed is insufficient to make any useful
decision = about what to do with it.

      =  Thanks,
       Paul (as = individual)

On 3/29/12 7:18 PM, John Leslie wrote:
> Espen = Berger (espeberg)<espeberg@cisco.com> =  wrote:
>>
>> John, you have listed a set of = valid acoustical challenges which I
>> recognize from our = experience. Some of the acoustical challenges will

>> be = present if a room use 1 or 2+ microphones to record, e.g. when = a
>> person moves around in the room.
>
>   =   This is true.
>
>> We should thrust endpoints that = chooses to use multiple microphones
>> for capture to do proper = audio pre-processing, and keep the audio
quality.
>
> =     I do not intend anything other than trusting endpoint = operators.
> But there are inherent differences between = single-pickup and multiple
> pickups mixed. For many purposes, = multiple pickups will be better...
>
>> I would suggest = that we reserve the mixed attribute to scenarios
>> where a = middle box mix audio captures from different endpoints.
>
> =     I don't believe it helpful to define "mixed" = based on where the
> mixing is done.
>
>     = You raise a valid point about "mixing" audio from different = rooms.
> This, indeed, is something to "hardly-ever" = prefer. Thus, to me, I'd
> rather it not be an ordinary = offer.
>
>     When I describe "mixed" = as a warning-label, I did not mean to
> infer that = "mixed" means "low-quality".
>
>   =   It sounds to me as if we should seriously consider including = a
> description of _what_ is being mixed...
>
> = --
> John Leslie<john@jlc.net>
> = _______________________________________________
> clue mailing = list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
><= br>
_______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue
_____= __________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 <= /o:p>

 

------_=_NextPart_001_01CD1106.D111D545-- From pkyzivat@alum.mit.edu Mon Apr 2 12:37:06 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4728921F86D0 for ; Mon, 2 Apr 2012 12:37:06 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG+5ByhVASEO for ; Mon, 2 Apr 2012 12:37:05 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id C648621F86C7 for ; Mon, 2 Apr 2012 12:37:04 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta01.westchester.pa.mail.comcast.net with comcast id t6Vm1i00C1uE5Es517d5BK; Mon, 02 Apr 2012 19:37:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id t7d41i00z07duvL3c7d413; Mon, 02 Apr 2012 19:37:05 +0000 Message-ID: <4F79FFDF.3030405@alum.mit.edu> Date: Mon, 02 Apr 2012 15:37:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Espen Berger (espeberg)" References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com><20120329152600.GB67516@verdi><92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com><20120329171843.GC67516@verdi><4F74BDDD.1010100@alum.mit.edu><92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com><92DF9533227FC14F946C7321074B8C9E0110F67B@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0110F68F@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E0110F68F@XMB-AMS-214.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 19:37:06 -0000 On 4/2/12 3:28 PM, Espen Berger (espeberg) wrote: > An MCU can basically give me two types of audio streams, > > ·Mixed – The MCU mixes together audio and deliver a single audio stream > based on some MCU cleverness > > ·Original – The MCU forward a audio stream un-modified from the source > (based on VAD-level selection) > > The purpose of the audio_type is only to make this distinction. I'm pretty sure I'm more of a neophyte on the details of this than anybody else in the wg. But based on what I've observed, I still get the feeling that being aware of this distinction is insufficient to make any useful decisions about how to choose and use audio media. Every example I've seen requires making additional, and unmotivated, assumptions about what has been mixed, or how, or both. Thanks, Paul > How to model and implement various spatial audio scenarios need further > discussions, not the audio-type attribute. > > -Espen > > *From:*Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Sent:* 2. april 2012 18:50 > *To:* Espen Berger (espeberg) > *Cc:* Paul Kyzivat; clue@ietf.org > *Subject:* Re: [clue] audio mixed attribute > > [Espen] If not signalled, how do you differentiate between ‘original’ > and ‘mixed’ audio? > I am not sure we need to differentiate them. We don't have any use cases > that show the need. > > However, if some switched captures can suddenly change position (whether > audio or video), then we do have a problem I think we agreed to > Jonathan's RTP requirement that disaggregated receivers needed to > receive the capture attributes prior to receiving the first RTP packet. > Also, that it needed to be possible to direct left, right, center > streams to different transport addresses, so they could be sent to > specific decoder instances running in dedicated hardware. Changing a > capture position on the fly would therefore also imply changing its > destination transport address w/o signaling. Using an "original" or > "mixed" attribute doesn't accomplish those requirements, so changing > position on the fly needs more discussion. > > > Stephen Botzko > > On Mon, Apr 2, 2012 at 12:35 PM, Espen Berger (espeberg) > > wrote: > > With a natural source I mean a audio capture that is not changed from > the original endpoint, through the switched MCU. An endpoint receiving > multiple natural (or original) audio captures should be able to decode > and mix together all audio streams, if not it should request the mixed > audio capture where the MCU has already done that work. A receiving > endpoint could also mix locally and play out the audio at the position > matching the position of video from the same endpoint, e.g. by using > SDES CNAME and/or SRCNAME. > > The rest of the comments inline > > -Espen > > *From:*Stephen Botzko [mailto:stephen.botzko@gmail.com > ] > *Sent:* 2. april 2012 16:41 > *To:* Espen Berger (espeberg) > *Cc:* Paul Kyzivat; clue@ietf.org > > > *Subject:* Re: [clue] audio mixed attribute > > in-line > > On Mon, Apr 2, 2012 at 9:52 AM, Espen Berger (espeberg) > > wrote: > > An audio mixing attribute is useful in the scenario where an MCU can > support both transcoding and switching. > > Given this scenario: A MCU supports transcoding and switching off audio > streams. The MCU can offer 3x loudest audio streams or 3x pre-mixed > audio streams that can be played out on left, Center, Right speakers. > > Example advertisement > AC1, AC2, AC3 audio_type = natural // Audio is switched between the > natural sources > > [sb] perhaps you mean "original" sources? > > > [Espen] Original source might be a better name, should mean the same thing > > Also, are you thinking that AC1, AC2, AC3 vary in their spatial position > (that AC1 will suddenly switch from right to left???) > > > [Espen] Yes. In a switched conference the audio captures does not need a > fixed position. If the MCU chooses to replace the content in AC1 with > endpoint A instead of B, the audio could be moved from right to left > based on where the video is displayed. > > AC4, AC5, AC6 audio_type = mixed // Audio is mixed into three fixed > positions > > CaptureSet // AC4 - AC6 belongs together > { AC4, AC5, AC6 } > [sb] - I am wondering if you are implying that AC1, AC2, AC3 can not > be advertised in a capture set???? > > > [Espen] They can be in a capture set, but in this example they do > not share any information. > > A consumer chooses either to request AC1 - AC3, does local mixing and > play out placement. If the endpoint chooses stream AC4 - AC6 the audio > should be played out on speaker that matches a left to right position. > > In this scheme it might be better to have a multi value attribute > describing audio_type, to avoid the possible confusion multiple Boolean > might have. > > Audio_type = { natural | mixed } > > [sb] "natural" seems to imply that it is somehow preferred (that "mixed" > is somehow un-natural). > One benefit of the mixed version is that you are more likely to hear > onset speech from participants who are not presently seen (assuming I > understand what switching algorithm you have in mind). > > [Espen] The MCU could use a N-loudest selection mechanism, so a receiver > could receive the 5x loudest audio streams based on audio level. Audio > level can be transferred in the RTP extension headers to avoid audio > decoding on the server. > > > I am not yet convinced that we need signaling for this. Though if we are > thinking that a capture's spatial position can change w/o notice, that > might be worth further discussion. That will complicate Jonathan's > disaggregated media requirement. > > > [Espen] If not signalled, how do you differentiate between ‘original’ > and ‘mixed’ audio? > > > Regards > > > -Espen > > > -----Original Message----- > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] On > Behalf Of > > Paul Kyzivat > Sent: 29. mars 2012 21:54 > To: clue@ietf.org > Subject: Re: [clue] audio mixed attribute > > I think you all have very clearly demonstrated that just being told that > a stream is mixed or not-mixed is insufficient to make any useful > decision about what to do with it. > > Thanks, > Paul (as individual) > > On 3/29/12 7:18 PM, John Leslie wrote: > > Espen Berger (espeberg) > wrote: > >> > >> John, you have listed a set of valid acoustical challenges which I > >> recognize from our experience. Some of the acoustical challenges > will > > >> be present if a room use 1 or 2+ microphones to record, e.g. when a > >> person moves around in the room. > > > > This is true. > > > >> We should thrust endpoints that chooses to use multiple microphones > >> for capture to do proper audio pre-processing, and keep the audio > quality. > > > > I do not intend anything other than trusting endpoint operators. > > But there are inherent differences between single-pickup and multiple > > pickups mixed. For many purposes, multiple pickups will be better... > > > >> I would suggest that we reserve the mixed attribute to scenarios > >> where a middle box mix audio captures from different endpoints. > > > > I don't believe it helpful to define "mixed" based on where the > > mixing is done. > > > > You raise a valid point about "mixing" audio from different rooms. > > This, indeed, is something to "hardly-ever" prefer. Thus, to me, I'd > > rather it not be an ordinary offer. > > > > When I describe "mixed" as a warning-label, I did not mean to > > infer that "mixed" means "low-quality". > > > > It sounds to me as if we should seriously consider including a > > description of _what_ is being mixed... > > > > -- > > John Leslie> > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From br@brianrosen.net Mon Apr 2 12:47:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7C321F86CF for ; Mon, 2 Apr 2012 12:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjYcc2t6ArKP for ; Mon, 2 Apr 2012 12:47:20 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0237F21F85FB for ; Mon, 2 Apr 2012 12:47:07 -0700 (PDT) X-ASG-Debug-ID: 1333396020-04d035034b31cac0001-dOUo1C Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id zXxW2GNd77oWDE3F; Mon, 02 Apr 2012 12:47:00 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.23]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SEnDQ-000DXe-3T; Mon, 02 Apr 2012 12:47:00 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [clue] audio mixed attribute Content-Type: text/plain; charset=windows-1252 From: Brian Rosen In-Reply-To: <4F79FFDF.3030405@alum.mit.edu> Date: Mon, 2 Apr 2012 15:46:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <702403BB-B1DA-449E-992F-DABD1A7C3656@brianrosen.net> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com><20120329152600.GB67516@verdi><92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com><20120329171843.GC67516@verdi><4F74BDDD.1010100@alum.mit.edu><92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com><92DF9533227FC14F946C7321074B8C9E0110F67B@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0110F68F@XMB-AMS-214.cisco.com> <4F79FFDF.3030405@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1333396020 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.82 X-Barracuda-Spam-Status: No, SCORE=0.82 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.92999 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 19:47:22 -0000 Agree. To illustrate: Top 4 speakers (switched) mixed to a stereo stream based on placement on = the screen(s).=20 Mixed or Original? And regardless, is it sufficient to do ANYTHING? Brian On Apr 2, 2012, at 3:37 PM, Paul Kyzivat wrote: > On 4/2/12 3:28 PM, Espen Berger (espeberg) wrote: >> An MCU can basically give me two types of audio streams, >>=20 >> =B7Mixed =96 The MCU mixes together audio and deliver a single audio = stream >> based on some MCU cleverness >>=20 >> =B7Original =96 The MCU forward a audio stream un-modified from the = source >> (based on VAD-level selection) >>=20 >> The purpose of the audio_type is only to make this distinction. >=20 > I'm pretty sure I'm more of a neophyte on the details of this than = anybody else in the wg. But based on what I've observed, I still get the = feeling that being aware of this distinction is insufficient to make any = useful decisions about how to choose and use audio media. >=20 > Every example I've seen requires making additional, and unmotivated, = assumptions about what has been mixed, or how, or both. >=20 > Thanks, > Paul >=20 >> How to model and implement various spatial audio scenarios need = further >> discussions, not the audio-type attribute. >>=20 >> -Espen >>=20 >> *From:*Stephen Botzko [mailto:stephen.botzko@gmail.com] >> *Sent:* 2. april 2012 18:50 >> *To:* Espen Berger (espeberg) >> *Cc:* Paul Kyzivat; clue@ietf.org >> *Subject:* Re: [clue] audio mixed attribute >>=20 >> [Espen] If not signalled, how do you differentiate between =91original=92= >> and =91mixed=92 audio? >> I am not sure we need to differentiate them. We don't have any use = cases >> that show the need. >>=20 >> However, if some switched captures can suddenly change position = (whether >> audio or video), then we do have a problem I think we agreed to >> Jonathan's RTP requirement that disaggregated receivers needed to >> receive the capture attributes prior to receiving the first RTP = packet. >> Also, that it needed to be possible to direct left, right, center >> streams to different transport addresses, so they could be sent to >> specific decoder instances running in dedicated hardware. Changing a >> capture position on the fly would therefore also imply changing its >> destination transport address w/o signaling. Using an "original" or >> "mixed" attribute doesn't accomplish those requirements, so changing >> position on the fly needs more discussion. >>=20 >>=20 >> Stephen Botzko >>=20 >> On Mon, Apr 2, 2012 at 12:35 PM, Espen Berger (espeberg) >> > wrote: >>=20 >> With a natural source I mean a audio capture that is not changed from >> the original endpoint, through the switched MCU. An endpoint = receiving >> multiple natural (or original) audio captures should be able to = decode >> and mix together all audio streams, if not it should request the = mixed >> audio capture where the MCU has already done that work. A receiving >> endpoint could also mix locally and play out the audio at the = position >> matching the position of video from the same endpoint, e.g. by using >> SDES CNAME and/or SRCNAME. >>=20 >> The rest of the comments inline >>=20 >> -Espen >>=20 >> *From:*Stephen Botzko [mailto:stephen.botzko@gmail.com >> ] >> *Sent:* 2. april 2012 16:41 >> *To:* Espen Berger (espeberg) >> *Cc:* Paul Kyzivat; clue@ietf.org >>=20 >>=20 >> *Subject:* Re: [clue] audio mixed attribute >>=20 >> in-line >>=20 >> On Mon, Apr 2, 2012 at 9:52 AM, Espen Berger (espeberg) >> > wrote: >>=20 >> An audio mixing attribute is useful in the scenario where an MCU can >> support both transcoding and switching. >>=20 >> Given this scenario: A MCU supports transcoding and switching off = audio >> streams. The MCU can offer 3x loudest audio streams or 3x pre-mixed >> audio streams that can be played out on left, Center, Right speakers. >>=20 >> Example advertisement >> AC1, AC2, AC3 audio_type =3D natural // Audio is switched between the >> natural sources >>=20 >> [sb] perhaps you mean "original" sources? >>=20 >>=20 >> [Espen] Original source might be a better name, should mean the same = thing >>=20 >> Also, are you thinking that AC1, AC2, AC3 vary in their spatial = position >> (that AC1 will suddenly switch from right to left???) >>=20 >>=20 >> [Espen] Yes. In a switched conference the audio captures does not = need a >> fixed position. If the MCU chooses to replace the content in AC1 with >> endpoint A instead of B, the audio could be moved from right to left >> based on where the video is displayed. >>=20 >> AC4, AC5, AC6 audio_type =3D mixed // Audio is mixed into three = fixed >> positions >>=20 >> CaptureSet // AC4 - AC6 belongs together >> { AC4, AC5, AC6 } >> [sb] - I am wondering if you are implying that AC1, AC2, AC3 can = not >> be advertised in a capture set???? >>=20 >>=20 >> [Espen] They can be in a capture set, but in this example they do >> not share any information. >>=20 >> A consumer chooses either to request AC1 - AC3, does local mixing = and >> play out placement. If the endpoint chooses stream AC4 - AC6 the = audio >> should be played out on speaker that matches a left to right = position. >>=20 >> In this scheme it might be better to have a multi value attribute >> describing audio_type, to avoid the possible confusion multiple = Boolean >> might have. >>=20 >> Audio_type =3D { natural | mixed } >>=20 >> [sb] "natural" seems to imply that it is somehow preferred (that = "mixed" >> is somehow un-natural). >> One benefit of the mixed version is that you are more likely to hear >> onset speech from participants who are not presently seen (assuming I >> understand what switching algorithm you have in mind). >>=20 >> [Espen] The MCU could use a N-loudest selection mechanism, so a = receiver >> could receive the 5x loudest audio streams based on audio level. = Audio >> level can be transferred in the RTP extension headers to avoid audio >> decoding on the server. >>=20 >>=20 >> I am not yet convinced that we need signaling for this. Though if we = are >> thinking that a capture's spatial position can change w/o notice, = that >> might be worth further discussion. That will complicate Jonathan's >> disaggregated media requirement. >>=20 >>=20 >> [Espen] If not signalled, how do you differentiate between =91original=92= >> and =91mixed=92 audio? >>=20 >>=20 >> Regards >>=20 >>=20 >> -Espen >>=20 >>=20 >> -----Original Message----- >> From: clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org ] On >> Behalf Of >>=20 >> Paul Kyzivat >> Sent: 29. mars 2012 21:54 >> To: clue@ietf.org >> Subject: Re: [clue] audio mixed attribute >>=20 >> I think you all have very clearly demonstrated that just being = told that >> a stream is mixed or not-mixed is insufficient to make any useful >> decision about what to do with it. >>=20 >> Thanks, >> Paul (as individual) >>=20 >> On 3/29/12 7:18 PM, John Leslie wrote: >> > Espen Berger (espeberg)> > wrote: >> >> >> >> John, you have listed a set of valid acoustical challenges = which I >> >> recognize from our experience. Some of the acoustical = challenges >> will >>=20 >> >> be present if a room use 1 or 2+ microphones to record, e.g. = when a >> >> person moves around in the room. >> > >> > This is true. >> > >> >> We should thrust endpoints that chooses to use multiple = microphones >> >> for capture to do proper audio pre-processing, and keep the = audio >> quality. >> > >> > I do not intend anything other than trusting endpoint = operators. >> > But there are inherent differences between single-pickup and = multiple >> > pickups mixed. For many purposes, multiple pickups will be = better... >> > >> >> I would suggest that we reserve the mixed attribute to = scenarios >> >> where a middle box mix audio captures from different = endpoints. >> > >> > I don't believe it helpful to define "mixed" based on where the >> > mixing is done. >> > >> > You raise a valid point about "mixing" audio from different = rooms. >> > This, indeed, is something to "hardly-ever" prefer. Thus, to = me, I'd >> > rather it not be an ordinary offer. >> > >> > When I describe "mixed" as a warning-label, I did not mean to >> > infer that "mixed" means "low-quality". >> > >> > It sounds to me as if we should seriously consider including a >> > description of _what_ is being mixed... >> > >> > -- >> > John Leslie> >> > _______________________________________________ >> > clue mailing list >> > clue@ietf.org >> > https://www.ietf.org/mailman/listinfo/clue >> > >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Mon Apr 2 12:56:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5404221F872D for ; Mon, 2 Apr 2012 12:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm3ZwCbE5Tyk for ; Mon, 2 Apr 2012 12:56:03 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6E421F8723 for ; Mon, 2 Apr 2012 12:55:56 -0700 (PDT) Received: by dady13 with SMTP id y13so3683227dad.27 for ; Mon, 02 Apr 2012 12:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/2rnM9v7uZQrwra1q+YWUznxVC1hjfpffiJLwf0ao8Y=; b=djB1SJrwf55KNK+SB96Io7Nm769iD9c9UhOT8DU60wo2DA/xcuHpBJtVboDAshyaBI k3w/OjgXa+URRMpJU6EG2ddSTGJEmGiQlE22Q5NzJMBI7wZf0sl/O27cD4ZwzcpIg+WR rCYoszEEBwA8Vc1O6o9SLkY6s2/wKcZmrtaF1fhrLUbQlexxevOIswSeMt4N3klFu8yp +H24onhFRvCfmmbhCiM+Npsr9+nucjro/wLt2+Ops3UUthUHSgMW7gfG26IZAkp/UQCl f40x+EeaXEO+sTC/5ohxbohCPPGXmG+n8xm8mgCHPNYaxVC/w2jkhaYJ5ou4OciUKrOS 3jRA== MIME-Version: 1.0 Received: by 10.68.213.73 with SMTP id nq9mr22947286pbc.143.1333396555801; Mon, 02 Apr 2012 12:55:55 -0700 (PDT) Received: by 10.68.32.37 with HTTP; Mon, 2 Apr 2012 12:55:55 -0700 (PDT) In-Reply-To: <4F79FFDF.3030405@alum.mit.edu> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com> <20120329152600.GB67516@verdi> <92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com> <20120329171843.GC67516@verdi> <4F74BDDD.1010100@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0110F67B@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0110F68F@XMB-AMS-214.cisco.com> <4F79FFDF.3030405@alum.mit.edu> Date: Mon, 2 Apr 2012 15:55:55 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8ff1c3fc0da3d404bcb79446 Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 19:56:04 -0000 --e89a8ff1c3fc0da3d404bcb79446 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable in-line, snipped... On Mon, Apr 2, 2012 at 3:37 PM, Paul Kyzivat wrote: > On 4/2/12 3:28 PM, Espen Berger (espeberg) wrote: > >> An MCU can basically give me two types of audio streams, >> >> =B7Mixed =96 The MCU mixes together audio and deliver a single audio str= eam >> based on some MCU cleverness >> >> =B7Original =96 The MCU forward a audio stream un-modified from the sour= ce >> (based on VAD-level selection) >> >> The purpose of the audio_type is only to make this distinction. >> > > I'm pretty sure I'm more of a neophyte on the details of this than anybod= y > else in the wg. But based on what I've observed, I still get the feeling > that being aware of this distinction is insufficient to make any useful > decisions about how to choose and use audio media. > > Every example I've seen requires making additional, and unmotivated, > assumptions about what has been mixed, or how, or both. > [sb] This is one of the points I am trying to make as well. I am certainly open to signaling attributes that aid rendering, but am not seeing how this one helps either selection or rendering. I do understand the goal of the composition flag for video - the idea there is to prevent nested hollywood squares. The definition may need some work, but the goal is clear. > > Thanks, > Paul > > How to model and implement various spatial audio scenarios need further >> discussions, not the audio-type attribute. >> >> -Espen >> >> >> --e89a8ff1c3fc0da3d404bcb79446 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable in-line, snipped...

On Mon, Apr 2, 2012 a= t 3:37 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 4/2/12 3:28 PM, Espen Berger (espeberg) wrote:
An MCU can basically give me two types of audio streams,

=B7Mixed =96 The MCU mixes together audio and deliver a single audio stream=
based on some MCU cleverness

=B7Original =96 The MCU forward a audio stream un-modified from the source<= br> (based on VAD-level selection)

The purpose of the audio_type is only to make this distinction.

I'm pretty sure I'm more of a neophyte on the details of this than = anybody else in the wg. But based on what I've observed, I still get th= e feeling that being aware of this distinction is insufficient to make any = useful decisions about how to choose and use audio media.

Every example I've seen requires making additional, and unmotivated, as= sumptions about what has been mixed, or how, or both.
=
[sb] This is one of the points I am trying to make as well.=A0 I am cer= tainly open to signaling attributes that aid rendering, but am not seeing h= ow this one helps either selection or rendering.

I do understand the goal of the composition flag for video - the idea t= here is to prevent nested hollywood squares. The definition may need some w= ork, but the goal is clear.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

How to model and implement various spatial audio scenarios need further
discussions, not the audio-type attribute.

-Espen



--e89a8ff1c3fc0da3d404bcb79446-- From johaniel@cisco.com Tue Apr 3 00:37:41 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E660221F855D for ; Tue, 3 Apr 2012 00:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjWf92Sx35bm for ; Tue, 3 Apr 2012 00:37:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A2D6821F852B for ; Tue, 3 Apr 2012 00:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johaniel@cisco.com; l=3929; q=dns/txt; s=iport; t=1333438660; x=1334648260; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3wxcaaQ9bTs1lkqQBaYL7WTJB2TyyAhGseBOJMaa4Ec=; b=Xj/9KfVaDH5RWrGBcdZtGfpVZStyfGpGKNusm366mOY3t+Gd4VrjRrP0 tjt5eUlPlQesgQm5iFBpCHI+JgTBvcsy/o/1cMrN17xcgt7IotQGCbt8I WitvktZQ3LqTAjIEvkCHvY9wx45d1dtoDLT889jmJUmfR3UF1WDPTXrQt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI2oek+Q/khM/2dsb2JhbABCuAaBB4IJAQEBAwESAR1JEAIBCBEEAQEBCgYXAQYBICUJCAEBBAESCBqHYgWgK5cgihaFdWMEiCWYb4MUgWiCaQ X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="134104373" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2012 07:37:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q337bFwd001920; Tue, 3 Apr 2012 07:37:15 GMT Received: from xmb-ams-206.cisco.com ([144.254.75.17]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 09:37:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 09:37:14 +0200 Message-ID: <05DD269BD82AA549BC4B2619BBAC466AFBE92C@XMB-AMS-206.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Steered microphone arrays Thread-Index: Ac0Q6hgoauno5kyZQrWNXyxNkWfP2QAflfVQ References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com><20120321202355.GJ79816@verdi><20120327041255.GB5206@verdi><20120327223212.GC5206@verdi> From: "Johan Ludvig Nielsen (johaniel)" To: "Stephen Botzko" , "John Leslie" X-OriginalArrivalTime: 03 Apr 2012 07:37:15.0124 (UTC) FILETIME=[9701F340:01CD116C] Cc: clue@ietf.org Subject: Re: [clue] Steered microphone arrays X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 07:37:42 -0000 Hi A microphone array can behave similar to a steered directional = microphone, with a fixed position (center of array) and focussing its = beam in different directions. Like a passive sonar. The concept of preserving arrival-time information seems to me to be = useful only when you have several microphones somehow translating into = several output streams, in which case an array with a single processed = output and a shotgun would behave equally as one of those microphones. An array can also have several output streams, looking in several = directions and picking up spatially separated sound sources = simultaneously. However, the effective mic position would still be fixed = and the same for the different sources, no inherent arrival-time = differences. The array can, however, know which direction it is looking, and use this = to embed time (and/or level) differences in output streams. Or (perhaps = better) add meta data about direction or even position to the streams. I would not tag the single stream output of a (steered or not steered) = microphone array as "mixed". Logically it is a single audio capture with = potentially high (and time-varying) directivity, but a fixed position. However, John's goal of preserving sound source direction information is = important and should definitely be worked on further. The "virtual microphone" is a slightly different thing, where an array = in one position is processed to a single output with the illusion of = being a microphone placed somewhere else. I agree with Stephen that it = can be done, but it has some challenges and I doubt that it will be an = important usecase in telepresence anytime soon. Regards Johan From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko Sent: 2. april 2012 18:03 To: John Leslie Cc: clue@ietf.org Subject: Re: [clue] Steered microphone arrays in-line On Tue, Mar 27, 2012 at 6:32 PM, John Leslie wrote: Stephen Botzko wrote: > On Tue, Mar 27, 2012 at 6:12 AM, John Leslie wrote: >> Stephen Botzko wrote: >> >>> [sb] =A0Are you suggesting that every system using a steered = microphone >>> array would be tagged as "mixed"? >> >> Actually, yes: in the case of a steered _array_ of microphones, the >> arrival-time information will be lost, just as in an audio mixer with >> multiple microphones. >> >> This is distinct from the case of a steered "shotgun" microphone = where >> the mike position is fixed (though its directional pattern changes), = thus >> arrival-time information is preserved. >> >> [sb] I believe steered microphone arrays are used commonly in sonar >> acquisition, =A0 This is true... >> so I don't believe arrival time information has to be lost. >> Usually the microphones in such an array are in fixed positions. =A0 As usual, the devil is in the details... =A0 In sonar, there's a very clearly-positioned sound source, and the return times of the microphone array are calibrated to that source. (Actually, the source likely produces a "chirp" of varying wavelength and the phase differences are processed during the chirp response.) =A0 In our microphone array, the position of the sound source is variable and there's no control of its wavelengths. It is technically possible to compare phase information of several microphones and process the sound output to that which "would be received" by a mike at a given position (within the range of the microphone array, of course); but if any existing system does that, I haven't heard of it. [sb] we have built systems that do that, and that is exactly what I mean = by a steerable array.=20 =A0 Again, we're going to have to trust operators to set the "mixed" bit: we can only offer guidance... -- John Leslie From johaniel@cisco.com Tue Apr 3 01:48:12 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E552221F85F0 for ; Tue, 3 Apr 2012 01:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJATkEkvkDHg for ; Tue, 3 Apr 2012 01:48:11 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4919221F8421 for ; Tue, 3 Apr 2012 01:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johaniel@cisco.com; l=9934; q=dns/txt; s=iport; t=1333442890; x=1334652490; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=2ADh68E7ke85Qwaxe6VTY08X4XdGzhfVcu7aaMBK2Zs=; b=d4D1ZQJdaKxiZDHdVUpFgz5tMS/OSZzTovYB0du8zoPZ3cReMIqKUYVP /sTZqAo2ck8pyujZ68MFcQzX/3vt6lWm7STqdIvD23TPkgvGjSkc3fMzO ndnk4+Fp0hz/ydMWgI/vYAFJYJtJrlPcLOZWLhWfMoXlLcQjekoG74lIh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGO4ek+Q/khR/2dsb2JhbABCDoJFtSOBB4IJAQEBBBIBCREDQgcQAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHZ6AqlyeQA2MEpCqBaYIwOQ X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208,217";a="69981627" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 03 Apr 2012 08:48:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q338m84n000670; Tue, 3 Apr 2012 08:48:08 GMT Received: from xmb-ams-206.cisco.com ([144.254.75.17]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 10:48:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1176.7E1E1452" Date: Tue, 3 Apr 2012 10:48:07 +0200 Message-ID: <05DD269BD82AA549BC4B2619BBAC466AFBE95B@XMB-AMS-206.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] audio mixed attribute Thread-Index: Ac0RCqaah1VVw0hISFCFWRSwHD6gcwAZSfTQ References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com><20120329152600.GB67516@verdi><92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com><20120329171843.GC67516@verdi> <4F74BDDD.1010100@alum.mit.edu><92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com><92DF9533227FC14F946C7321074B8C9E0110F67B@XMB-AMS-214.cisco.com><92DF9533227FC14F946C7321074B8C9E0110F68F@XMB-AMS-214.cisco.com><4F79FFDF.3030405@alum.mit.edu> From: "Johan Ludvig Nielsen (johaniel)" To: "Stephen Botzko" , "Paul Kyzivat" X-OriginalArrivalTime: 03 Apr 2012 08:48:08.0825 (UTC) FILETIME=[7E693690:01CD1176] Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 08:48:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1176.7E1E1452 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will highlight one potential use for the audio type, which Espen has actually already pointed out. =20 If the audio stream is natural/original, it can be expected to correspond to a single video stream. The renderer can go search for this connection in other attributes, and then render the audio at the correct position. An important feature in a complex layout on a wide display setup. =20 If the audio is mixed by the MCU there is no point in searching for a connection, play audio in the center or across all loudspeakers. =20 The same function could be accomplished without the audio attribute if there were mechanisms for explicitly announcing spatial relationships from the MCU to the renderer. I don't think the capture area concept is well suited for this. =20 Regards Johan =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: 2. april 2012 21:56 To: Paul Kyzivat Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute =20 in-line, snipped... On Mon, Apr 2, 2012 at 3:37 PM, Paul Kyzivat wrote: On 4/2/12 3:28 PM, Espen Berger (espeberg) wrote: An MCU can basically give me two types of audio streams, *Mixed - The MCU mixes together audio and deliver a single audio stream based on some MCU cleverness *Original - The MCU forward a audio stream un-modified from the source (based on VAD-level selection) The purpose of the audio_type is only to make this distinction. =20 I'm pretty sure I'm more of a neophyte on the details of this than anybody else in the wg. But based on what I've observed, I still get the feeling that being aware of this distinction is insufficient to make any useful decisions about how to choose and use audio media. Every example I've seen requires making additional, and unmotivated, assumptions about what has been mixed, or how, or both. [sb] This is one of the points I am trying to make as well. I am certainly open to signaling attributes that aid rendering, but am not seeing how this one helps either selection or rendering.=20 I do understand the goal of the composition flag for video - the idea there is to prevent nested hollywood squares. The definition may need some work, but the goal is clear.=20 =09 Thanks, Paul How to model and implement various spatial audio scenarios need further discussions, not the audio-type attribute. =09 -Espen =20 =20 ------_=_NextPart_001_01CD1176.7E1E1452 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I will highlight one potential use for the audio type, which Espen = has actually already pointed out.

 

If the audio stream is natural/original, it can be expected to = correspond to a single video stream. The renderer can go search for this = connection in other attributes, and then render the audio at the correct = position. An important feature in a complex layout on a wide display = setup.

 

If the audio is mixed by the MCU there is no point in searching for a = connection, play audio in the center or across all = loudspeakers.

 

The same function could be accomplished without the audio attribute = if there were mechanisms for explicitly announcing spatial relationships = from the MCU to the renderer. I don’t think the capture area = concept is well suited for this.

 

Regards

Johan

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko
Sent: 2. april 2012 21:56
To: = Paul Kyzivat
Cc: clue@ietf.org
Subject: Re: [clue] = audio mixed attribute

 

in-line, snipped...

On Mon, Apr 2, 2012 at 3:37 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

On 4/2/12 3:28 PM, Espen = Berger (espeberg) wrote:

An MCU can = basically give me two types of audio streams,

·Mixed = – The MCU mixes together audio and deliver a single audio = stream
based on some MCU cleverness

·Original – = The MCU forward a audio stream un-modified from the source
(based on = VAD-level selection)

The purpose of the audio_type is only to = make this distinction.

 

I'm = pretty sure I'm more of a neophyte on the details of this than anybody = else in the wg. But based on what I've observed, I still get the feeling = that being aware of this distinction is insufficient to make any useful = decisions about how to choose and use audio media.

Every example = I've seen requires making additional, and unmotivated, assumptions about = what has been mixed, or how, or both.


[sb] This is one of the points I am trying to make = as well.  I am certainly open to signaling attributes that aid = rendering, but am not seeing how this one helps either selection or = rendering.

I do understand the goal of the composition flag for = video - the idea there is to prevent nested hollywood squares. The = definition may need some work, but the goal is clear. =


      =  Thanks,
       Paul

How to model and = implement various spatial audio scenarios need further
discussions, = not the audio-type attribute.

-Espen

 

 

------_=_NextPart_001_01CD1176.7E1E1452-- From johaniel@cisco.com Tue Apr 3 03:44:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D9121F855A for ; Tue, 3 Apr 2012 03:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFVFZbqowQjP for ; Tue, 3 Apr 2012 03:44:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 59F8E21F8585 for ; Tue, 3 Apr 2012 03:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johaniel@cisco.com; l=24153; q=dns/txt; s=iport; t=1333449884; x=1334659484; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=WTuGwqfOpedDoZUlBJtGYtUeSjvZMk4oPmYV4qptKtk=; b=DAj2mSPfbubXTbMnch8LCQySHxjR3tQZVPm5lFk4UMtjDr/Ko+BRMVNZ kveJPTpzhXy4TddjNgyt2cxnTiE6mm1VeNnWZgtLIG0T2e5LlI4XUoMWh EPmDW9pcD+oaTmRjEHDxJeR0UzAbT9h0GEXhhTdSp+HyWJSwKnl/P3daT Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAB3Uek+Q/khM/2dsb2JhbABFgka1J4EHggkBAQEDAQEBAQ8BCREDPAIIAwULAgEIEQQBAQEKBgUSAQYBJh8JCAEBBAESCBMHh2IFC5wKnw4EjTaCTWMEpCqBaYJp X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208,217";a="134130608" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2012 10:44:40 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q33Aid42012695; Tue, 3 Apr 2012 10:44:39 GMT Received: from xmb-ams-206.cisco.com ([144.254.75.17]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 12:44:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1186.C50EEDCB" Date: Tue, 3 Apr 2012 12:44:35 +0200 Message-ID: <05DD269BD82AA549BC4B2619BBAC466AFBE9B3@XMB-AMS-206.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] audio mixed attribute - from sending endpoint side Thread-Index: Ac0Q5fWO5yU5rsyiRVqE/dotM1rKCAAk/2FQ References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com><20120329152600.GB67516@verdi> From: "Johan Ludvig Nielsen (johaniel)" To: "Stephen Botzko" , "John Leslie" X-OriginalArrivalTime: 03 Apr 2012 10:44:39.0914 (UTC) FILETIME=[C56CBCA0:01CD1186] Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute - from sending endpoint side X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 10:44:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1186.C50EEDCB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A mono audio capture can originate from a several microphones mixed in external gear that the telepresence system don't know about. This is very common. So even a single microphone input can be mixed. =20 The idea of a middle box or renderer applying automatic gain corrections to a non-mixed signal due to expected larger level differences from talkers at different distances to the microphone is admirable. However, normally AGC would be applied by the provider, and this is also the preferred way as there can be extra data available in the mic processing enabling better AGC designs. Network or receiver AGCs have a tendency to perform less well, especially if they process on streams that are already level corrected by the senders and partially corrupted by coding or other processing artefacts. =20 So an audio stream marked "non-mixed" may actually be both mixed and already gain-corrected. Trusting the sender to provide the best possible pick-up and processing is in my view the best strategy, I agree with Stephen. =20 I like John's suggestion about a "less distinct" placement. It can be done by rendering an audio stream on several loudspeakers instead of one. And it should be done for those streams where there is no spatial information, or where the stream is known to represent a large pickup area like a whole room which is rendered on a wide display area. However, I think it should be connected to spatial information (or lack of such), and not to a mixed attribute, which may be ambigious. =20 I also think John's comments about the multitude of audio captures, mixed and unmixed, is important. Not necessarily for position effects, but for quality. We should trust the provider to mix in a sensible way. But the framework must prevent the MCU or the renderer choosing and mixing audio captures that shouldn't be mixed later on. A mixed attribute could help, but I guess other mechanisms in the capture set announcements could solve it too, ref. the mutually-exclusive discussion. =20 I think the goal that John keeps referring to of keeping positional information deserves much more discussion and solutions. It should be clarified in the framework. Preserving timing info between multiple audio captures is one way, but requires taking care of microphone and loudspeaker layouts.=20 =20 In my view a more abstract and general model would find more applications. The model in the protocols should be abstract and totally independent on the microphone pickup system and the loudspeaker rendering system, very much like for surround sound that Stephen is referring to, and other multichannel audio formats. Provide information that is useful for the renderer, leave out the rest.=20 =20 Regards Johan =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: 2. april 2012 17:31 To: John Leslie Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute =20 =20 On Thu, Mar 29, 2012 at 11:26 AM, John Leslie wrote: Duckworth, Mark wrote: > > Hi John, > I'm trying to understand your view on labeling audio as mixed. > Here is one example scenario that might help me understand. > Suppose I am a provider, and I can capture and send audio in two > different ways: > Option 1: I can send one mono audio capture. It comes from one > microphone element that picks up audio from the whole room. > Option 2: I can send one mono audio capture. It comes from several > microphone elements mixed together, that collectively pick > up audio from the whole room. > > I think you are saying it would be useful to label option 1 as not > mixed, and label option 2 as mixed. Is that correct? Yes. > What might a receiver do differently if it receives option 1 vs. > receiving option 2? (To answer, I need to assume the receiver can to some degree choose which to receive.) The receiver, for example, could reasonably guess that the "mixed" version will have a more uniform level when speakers are in different parts of the room. There's always a trade-off in applyinng level "correction" in order to improve comprehension -- this might be more necessary for the "unmixed" audio. =20 [sb] Whether level correction is useful depends on the actual level being received at the moment [and whether the original human speaker intended their whispered comment to be heard by everyone!]. I do not think that the pick-up pattern is the primary consideration here. In most telepresence rooms, the microphones are intentionally placed to give proper pickup of the entire room. So I would not make the guess that you are making. =09 My concern, actually, is more with how to "audibly" "place" the received audio in a virtual room. I believe the "mixed" version needs to be given a less-distinct "place" than the "unmixed". YMMV, of course. [sb]I don't really get this. How does the renderer give an audio stream a "less distinct" placement? And why would it do so? In my view, it gives every audio stream the placement it's capture information describes. In some cases, the audio might have better spatial separation than others.=20 But I don't see how the renderer can determine this from a "mixed" attribute, and I certainly don't get how or why a renderer would post-process the streams differently. =09 There's another issue, hopefully less abstruse: when working from _both_ mixed and unmixed audio captures: the receiver needs to be careful about mixing pre-mixed sources. =09 The nature of sound is a very slow propagation rate in air: roughly one foot per millisecond. The echo of blending sound from one speaker with 100 millisecond propagation difference is obvious -- but the ear can be confused by apparent acoustic effects with differences much smaller than that. The human ear adjusts pretty well to different acoustics if they're constant, but gets confused about apparent position if these acoustic effects change unpredictably. =20 [sb] You are making an assumption here - in particular you are assuming that the audio mix done at the source does not take the propagation into account. I am not sure why you are envisioning that the source processing is naive, but the render processing is sophisticated. I do agree that the way the human ear perceives sound location is quite complex. With multiple loudspeakers, generally the first arriving sound dominates (which is a well known effect that auditorium sound-reinforcement systems use to their advantage). If the second sound arrives too late, it will not be fused, resulting in reverberance or even echo. Of course in Mark's scenario, the captured sound (from however many microphones) is converted to monophonic at the source. The apparent position of the audio stream will always be stable, as long as it is rendered consistently at the receiver. Multiple human voices within the capture will all sound like they are coming from the same place- which is artificial, but is also something we are all used to and hear every day in audio bridges. This perception does not depend on the number of microphones blended in the original capture.=20 =09 This is probably not anything most of us want to worry about in our initial release: I am thinking ahead, hoping to avoid need to kludge something later on. Folks are already used to "surround-sound" home theatres: we should have some idea how to use such sound systems when we get a round-tuit. ;^) =20 [sb] I would agree here. Though my surround-sound system has no idea if the original sound comes from independent single microphones [or not]. The calibration in my receiver takes care of local delay and equalization issues due to the placement of my speakers in my room. The producer is responsible for providing sound tracks that sound appropriate when rendered in the standard speaker positions. I am imagining a similar model here. As long as the producer provides sound that is consistent with its advertisement for the streams, we should be fine. -- John Leslie _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CD1186.C50EEDCB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A mono audio capture can originate from a several microphones mixed = in external gear that the telepresence system don’t know about. = This is very common. So even a single microphone input can be = mixed.

 

The idea of a middle box or renderer applying automatic gain = corrections to a non-mixed signal due to expected larger level = differences from talkers at different distances to the microphone is = admirable. However, normally AGC would be applied by the provider, and = this is also the preferred way as there can be extra data available in = the mic processing enabling better AGC designs. Network or receiver AGCs = have a tendency to perform less well, especially if they process on = streams that are already level corrected by the senders and partially = corrupted by coding or other processing = artefacts.

 

So an audio stream marked “non-mixed” may actually be = both mixed and already gain-corrected. Trusting the sender to provide = the best possible pick-up and processing is in my view the best = strategy, I agree with Stephen.

 

I like John’s suggestion about a “less distinct” = placement. It can be done by rendering an audio stream on several = loudspeakers instead of one. And it should be done for those streams = where there is no spatial information, or where the stream is known to = represent a large pickup area like a whole room which is rendered on a = wide display area. However, I think it should be connected to spatial = information (or lack of such), and not to a mixed attribute, which may = be ambigious.

 

I also think John’s comments about the multitude of audio = captures, mixed and unmixed, is important. Not necessarily for position = effects, but for quality. We should trust the provider to mix in a = sensible way. But the framework must prevent the MCU or the renderer = choosing and mixing audio captures that shouldn’t be mixed later = on. A mixed attribute could help, but I guess other mechanisms in the = capture set announcements could solve it too, ref. the = mutually-exclusive discussion.

 

I think the goal that John keeps referring to of keeping positional = information deserves much more discussion and solutions. It should be = clarified in the framework. Preserving timing info between multiple = audio captures is one way, but requires taking care of microphone and = loudspeaker layouts.

 

In my view a more abstract and general model would find more = applications. The model in the protocols should be abstract and totally = independent on the microphone pickup system and the loudspeaker = rendering system, very much like for surround sound that Stephen is = referring to, and other multichannel audio formats. Provide information = that is useful for the renderer, leave out the rest. =

 

Regards

Johan

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko
Sent: 2. april 2012 17:31
To: = John Leslie
Cc: clue@ietf.org
Subject: Re: [clue] = audio mixed attribute

 

 

On Thu, Mar 29, 2012 at 11:26 AM, John Leslie <john@jlc.net> = wrote:

Duckworth, Mark <Mark.Duckworth@polycom.com= > wrote:
>
> Hi John,
> I'm trying to understand = your view on labeling audio as mixed.
> Here is one example = scenario that might help me understand.
> Suppose I am a provider, = and I can capture and send audio in two
> different ways:
> = Option 1: I can send one mono audio capture.  It comes from = one
>           microphone element that = picks up audio from the whole room.
> Option 2: I can send one = mono audio capture.  It comes from several
>     =       microphone elements mixed together, that = collectively pick
>           up audio = from the whole room.
>
> I think you are saying it would be = useful to label option 1 as not
> mixed, and label option 2 as = mixed.  Is that correct?

  Yes.


> What might a receiver do = differently if it receives option 1 vs.
> receiving option = 2?

  (To answer, I need to = assume the receiver can to some degree choose
which to = receive.)

  The receiver, for example, could reasonably = guess that the "mixed"
version will have a more uniform = level when speakers are in different
parts of the room. There's = always a trade-off in applyinng level
"correction" in order = to improve comprehension -- this might be more
necessary for the = "unmixed" audio.

 

[sb] Whether level correction is useful depends on the = actual level being received at the moment [and whether the original = human speaker intended their whispered comment to be heard by = everyone!].
I do not think that the pick-up pattern is the primary = consideration here.  In most telepresence rooms, the microphones = are intentionally placed to give proper pickup of the entire room.  = So I would not make the guess that you are = making.


  My concern, actually, is more with how to = "audibly" "place" the
received audio in a virtual = room. I believe the "mixed" version needs
to be given a = less-distinct "place" than the "unmixed". YMMV, of = course.


[sb]I = don't really get this.  How does the renderer give an audio stream = a "less distinct" placement?  And why would it do = so?
In my view, it gives every audio stream the placement it's = capture information describes.  In some cases, the audio might have = better spatial separation than others.
But I don't see how the = renderer can determine this from a "mixed" attribute, and I = certainly don't get how or why a renderer would post-process the streams = differently.


  There's another issue, hopefully less = abstruse: when working from
_both_ mixed and unmixed audio captures: = the receiver needs to be
careful about mixing pre-mixed = sources.

  The nature of sound is a very slow propagation = rate in air: roughly
one foot per millisecond. The echo of blending = sound from one speaker
with 100 millisecond propagation difference is = obvious -- but the ear
can be confused by apparent acoustic effects = with differences much
smaller than that. The human ear adjusts pretty = well to different
acoustics if they're constant, but gets confused = about apparent position
if these acoustic effects change = unpredictably.

 

[sb] You are making an assumption here - in particular = you are assuming that the audio mix done at the source does not take the = propagation into account. I am not sure why you are envisioning that the = source processing is naive, but the render processing is = sophisticated.

I do agree that the way the human ear perceives = sound location is quite complex.  With multiple loudspeakers, = generally the first arriving sound dominates (which is a well known = effect that auditorium sound-reinforcement systems use to their = advantage). If the second sound arrives too late, it will not be fused, = resulting in reverberance or even echo.

Of course in Mark's = scenario, the captured sound (from however many microphones) is = converted to monophonic at the source. The apparent position of = the audio stream will always be stable, as long as it is rendered = consistently at the receiver.  Multiple human voices within the = capture will all sound like they are coming from the same place- which = is artificial, but is also something we are all used to and hear every = day in audio bridges.  This perception does not depend on the = number of microphones blended in the original capture. =


  This is probably not anything most of us = want to worry about in our
initial release: I am thinking ahead, = hoping to avoid need to kludge
something later on. Folks are already = used to "surround-sound" home
theatres: we should have some = idea how to use such sound systems when
we get a round-tuit. = ;^)

 

[sb]  I would agree here.  Though my = surround-sound system has no idea if the original sound comes from = independent single microphones [or not].  The calibration in my = receiver takes care of local delay and equalization issues due to the = placement of my speakers in my room.  The producer is responsible = for providing sound tracks that sound appropriate when rendered in the = standard speaker positions.  I am imagining a similar model = here.  As long as the producer provides sound that is consistent = with its advertisement for the streams, we should be = fine.

--
John Leslie <john@jlc.net>
____________________= ___________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

------_=_NextPart_001_01CD1186.C50EEDCB-- From stephen.botzko@gmail.com Tue Apr 3 03:46:01 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272DD21F858F for ; Tue, 3 Apr 2012 03:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciNF4C6yNmzu for ; Tue, 3 Apr 2012 03:46:00 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D949021F8585 for ; Tue, 3 Apr 2012 03:45:54 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so5309962pbb.31 for ; Tue, 03 Apr 2012 03:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4jS1B9JBDVKTsgousaXh8VGhtGQTwyCLLGy2+gyyo5M=; b=cT7TM7Ubr+S9mvwcF1W6ZgxVqCLumDE4cLkONjLVt/LgG/+IVBu5ZtSBQTgZqsK6tc oaarvecGwAEoqjFrOYUI8iAhZKxqA9+YvrWWEzmFZUhPfqZp+l5ijx+04TnGnAmG8A3p MMONHlBpanWdT0E6bUk4WW+A1oKNo+Hv2A+AIzmu46V9UBfYHs+XD12TLR2n7sSNEn1j 7unVWCHjCA1TBqqPn+xQZDYUbwD3YJP+QUZfeWJo3v3Mw46lSoqC0sHvWk4qdHYGTc5g fxLbTlZFvWm500z6JrJN1HCBHNgVJhKeBALnoW2RgA0Jhxr1M9OLBVLGY4RivoA80vvV KvSg== MIME-Version: 1.0 Received: by 10.68.125.226 with SMTP id mt2mr28034830pbb.38.1333449954579; Tue, 03 Apr 2012 03:45:54 -0700 (PDT) Received: by 10.68.32.37 with HTTP; Tue, 3 Apr 2012 03:45:54 -0700 (PDT) In-Reply-To: <05DD269BD82AA549BC4B2619BBAC466AFBE95B@XMB-AMS-206.cisco.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com> <20120329152600.GB67516@verdi> <92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com> <20120329171843.GC67516@verdi> <4F74BDDD.1010100@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0110F67B@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0110F68F@XMB-AMS-214.cisco.com> <4F79FFDF.3030405@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466AFBE95B@XMB-AMS-206.cisco.com> Date: Tue, 3 Apr 2012 06:45:54 -0400 Message-ID: From: Stephen Botzko To: "Johan Ludvig Nielsen (johaniel)" Content-Type: multipart/alternative; boundary=047d7b2e4822de537304bcc402b5 Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 10:46:01 -0000 --047d7b2e4822de537304bcc402b5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [inline] Stephen On Tue, Apr 3, 2012 at 4:48 AM, Johan Ludvig Nielsen (johaniel) < johaniel@cisco.com> wrote: > I will highlight one potential use for the audio type, which Espen has > actually already pointed out.**** > > ** ** > > If the audio stream is natural/original, it can be expected to correspond > to a single video stream. The renderer can go search for this connection = in > other attributes, and then render the audio at the correct position. An > important feature in a complex layout on a wide display setup. > [sb] Actually CLUE does not require a 1-1 correspondence between audio and video captures. You can for instance use 3 audio captures to span 2 video captures. As displays continue to get larger, I am thinking this configuration will occur in real systems. > **** > > ** ** > > If the audio is mixed by the MCU there is no point in searching for a > connection, play audio in the center or across all loudspeakers.**** > [sb] If the MCU is composing video on multiple sites on the displays, then it could also re-process the audio so that the audio and video positioning is preserved. It is just as capable of doing this as the receiving endpoint. Of course, if the audio in a capture has no correspondence to the video, the MCU can choose to signal it as being centered if it wishes, and it can adjust the capture area to the full range. It has other options though - for instance It could also position it off-screen. I see no reason for the receiver to second-guess the position, since (like sourcing endpoints) the MCU is advertising the position of the audio and video in a common coordinate space. ** > > The same function could be accomplished without the audio attribute if > there were mechanisms for explicitly announcing spatial relationships fro= m > the MCU to the renderer. I don=92t think the capture area concept is well > suited for this. > [sb]The capture scene concept is the mechanism for advertising spatial relationships both for original captures and mixed/composed captures, for both MCUs and endpoints. If you think it is not well suited, then it would be extremely helpful to hear more. > **** > > ** ** > > Regards**** > > Johan**** > > ** ** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Stephen Botzko > *Sent:* 2. april 2012 21:56 > *To:* Paul Kyzivat > *Cc:* clue@ietf.org > > *Subject:* Re: [clue] audio mixed attribute**** > > ** ** > > in-line, snipped...**** > > On Mon, Apr 2, 2012 at 3:37 PM, Paul Kyzivat > wrote:**** > > On 4/2/12 3:28 PM, Espen Berger (espeberg) wrote:**** > > An MCU can basically give me two types of audio streams, > > =B7Mixed =96 The MCU mixes together audio and deliver a single audio stre= am > based on some MCU cleverness > > =B7Original =96 The MCU forward a audio stream un-modified from the sourc= e > (based on VAD-level selection) > > The purpose of the audio_type is only to make this distinction.**** > > ** ** > > I'm pretty sure I'm more of a neophyte on the details of this than anybod= y > else in the wg. But based on what I've observed, I still get the feeling > that being aware of this distinction is insufficient to make any useful > decisions about how to choose and use audio media. > > Every example I've seen requires making additional, and unmotivated, > assumptions about what has been mixed, or how, or both.**** > > > [sb] This is one of the points I am trying to make as well. I am > certainly open to signaling attributes that aid rendering, but am not > seeing how this one helps either selection or rendering. > > I do understand the goal of the composition flag for video - the idea > there is to prevent nested hollywood squares. The definition may need som= e > work, but the goal is clear. **** > > > Thanks, > Paul**** > > How to model and implement various spatial audio scenarios need further > discussions, not the audio-type attribute. > > -Espen**** > > ** ** > > ** ** > --047d7b2e4822de537304bcc402b5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [inline]
Stephen

On Tue, Apr 3, 2012 a= t 4:48 AM, Johan Ludvig Nielsen (johaniel) <johaniel@cisco.com> wrote:

I will highlight one potential use for the a= udio type, which Espen has actually already pointed out.

=A0<= /p>

If the audio stream is= natural/original, it can be expected to correspond to a single video strea= m. The renderer can go search for this connection in other attributes, and = then render the audio at the correct position. An important feature in a co= mplex layout on a wide display setup.

[sb] Actually CLUE does not require a 1-1 cor= respondence between audio and video captures.=A0 You can for instance use 3= audio captures to span 2 video captures. As displays continue to get large= r, I am thinking this configuration will occur in real systems.

=A0<= /p>

If the audio is mixed = by the MCU there is no point in searching for a connection, play audio in t= he center or across all loudspeakers.

[sb] If the MCU is composing video on multipl= e sites on the displays, then it could also re-process the audio so that th= e audio and video positioning is preserved. It is just as capable of doing = this as the receiving endpoint.=A0 Of course, if the audio in a capture has= no correspondence to the video, the MCU can choose to signal it as being c= entered if it wishes, and it can adjust the capture area to the full range.= =A0 It has other options though - for instance It could also position it of= f-screen.=A0 I see no reason for the receiver to second-guess the position,= since (like sourcing endpoints) the MCU is advertising the position of the= audio and video in a common coordinate space.

The same function could b= e accomplished without the audio attribute if there were mechanisms for exp= licitly announcing spatial relationships from the MCU to the renderer. I do= n=92t think the capture area concept is well suited for this.

[sb]The capture scene concept is the mechanis= m for advertising spatial relationships both for original captures and mixe= d/composed captures, for both MCUs and endpoints.=A0 If you think it is not= well suited, then it would be extremely helpful to hear more.

=A0<= /p>

Regards<= /span>

Johan

=A0

=A0<= /p>

From: clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf Of Stephen Botzko
Sent: 2. april 2012 21:56
To: Paul Kyzivat
Cc: <= a href=3D"mailto:clue@ietf.org" target=3D"_blank">clue@ietf.org<= /p>


Subject: Re: [clue] audio mixed attribute

=A0

in-line, snipped...

On Mon, Apr 2, 2012 at 3:3= 7 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 4/2/12 3:28 PM, Espen Berger (espeberg) wrot= e:

An MCU can basically give me two= types of audio streams,

=B7Mixed =96 The MCU mixes together audio a= nd deliver a single audio stream
based on some MCU cleverness

=B7Original =96 The MCU forward a audio= stream un-modified from the source
(based on VAD-level selection)
The purpose of the audio_type is only to make this distinction.=

=A0

I&= #39;m pretty sure I'm more of a neophyte on the details of this than an= ybody else in the wg. But based on what I've observed, I still get the = feeling that being aware of this distinction is insufficient to make any us= eful decisions about how to choose and use audio media.

Every example I've seen requires making additional, and unmotivated= , assumptions about what has been mixed, or how, or both.

=


[sb] This is one of the points I am trying = to make as well.=A0 I am certainly open to signaling attributes that aid re= ndering, but am not seeing how this one helps either selection or rendering= .

I do understand the goal of the composition flag for video - the idea t= here is to prevent nested hollywood squares. The definition may need some w= ork, but the goal is clear.


=A0 =A0 =A0 =A0Th= anks,
=A0 =A0 =A0 =A0Paul

How to model and implement various spatial au= dio scenarios need further
discussions, not the audio-type attribute.

-Espen

<= /div>

=A0

=A0

<= /div>
--047d7b2e4822de537304bcc402b5-- From johaniel@cisco.com Tue Apr 3 04:19:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69B721F8732 for ; Tue, 3 Apr 2012 04:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0HYaxSaussR for ; Tue, 3 Apr 2012 04:19:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 244DE21F8720 for ; Tue, 3 Apr 2012 04:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johaniel@cisco.com; l=20469; q=dns/txt; s=iport; t=1333451994; x=1334661594; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ZMBwIk1QC025ibC1+K07/viR+2YqHh2Rm9kUY8NkMlQ=; b=ZgoVjFSMGipLC6mVpk5ZUG17aWZJMebnIGXa6H09xdwHvZl6t6M2EkoO jLFq+qB2hKvRbNOU3RpHmZG5SusBp4C1vbbZXC47RzxfyzKQTQNlIbL8V CToSb5uCinHv3tCq1EZ7wzzD/W+wXO66fizZF/lbT4iLnEelueq8GUPXi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEPcek+Q/khR/2dsb2JhbABFgka1J4EHggkBAQEEEgEJEQNCBxACAQgRBAEBCwYXAQYBRQkIAQEEEwgah2ecI58PkANjBKQqgWmCaQ X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208,217";a="134135810" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2012 11:19:52 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q33BJq0J005856; Tue, 3 Apr 2012 11:19:52 GMT Received: from xmb-ams-206.cisco.com ([144.254.75.17]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 13:19:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD118B.B0669847" Date: Tue, 3 Apr 2012 13:19:51 +0200 Message-ID: <05DD269BD82AA549BC4B2619BBAC466AFBE9CD@XMB-AMS-206.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] audio mixed attribute Thread-Index: Ac0Rhvm7gbY2R8OFSPSTUK5tqLLvpwAAQ1SQ References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com><20120329152600.GB67516@verdi><92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com><20120329171843.GC67516@verdi> <4F74BDDD.1010100@alum.mit.edu><92DF9533227FC14F946C7321074B8C9E0110F612@XMB-AMS-214.cisco.com><92DF9533227FC14F946C7321074B8C9E0110F67B@XMB-AMS-214.cisco.com><92DF9533227FC14F946C7321074B8C9E0110F68F@XMB-AMS-214.cisco.com><4F79FFDF.3030405@alum.mit.edu><05DD269BD82AA549BC4B2619BBAC466AFBE95B@XMB-AMS-206.cisco.com> From: "Johan Ludvig Nielsen (johaniel)" To: "Stephen Botzko" X-OriginalArrivalTime: 03 Apr 2012 11:19:52.0769 (UTC) FILETIME=[B0C8D310:01CD118B] Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 11:19:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD118B.B0669847 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen, =20 I think we have a common goal, I agree with what you write including the expansion beyond 1:1 relationships, the features you describe are great. =20 If the capture scene / area concepts are meant to solve these features for the MCU case, I would very much like to see an example of how, as I am not able to figure it out from the framework description. I have asked for that on this list before without response. The example in the framework doesn't encompass spatial audio. =20 For the MCU composing layouts on multiple displays and multiple sites, how would the MCU construct and announce capture scene and areas to the renderers to signal the spatial connections? And how will CLUE signalling be done to be sufficiently fast to keep up with changes in the connections and spatial positions when active speakers constantly change? =20 The same questions are even more interesting with a fully switched MCU. =20 Regards Johan =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: 3. april 2012 12:46 To: Johan Ludvig Nielsen (johaniel) Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute =20 [inline] Stephen On Tue, Apr 3, 2012 at 4:48 AM, Johan Ludvig Nielsen (johaniel) wrote: I will highlight one potential use for the audio type, which Espen has actually already pointed out. =20 If the audio stream is natural/original, it can be expected to correspond to a single video stream. The renderer can go search for this connection in other attributes, and then render the audio at the correct position. An important feature in a complex layout on a wide display setup. [sb] Actually CLUE does not require a 1-1 correspondence between audio and video captures. You can for instance use 3 audio captures to span 2 video captures. As displays continue to get larger, I am thinking this configuration will occur in real systems. =20 If the audio is mixed by the MCU there is no point in searching for a connection, play audio in the center or across all loudspeakers. [sb] If the MCU is composing video on multiple sites on the displays, then it could also re-process the audio so that the audio and video positioning is preserved. It is just as capable of doing this as the receiving endpoint. Of course, if the audio in a capture has no correspondence to the video, the MCU can choose to signal it as being centered if it wishes, and it can adjust the capture area to the full range. It has other options though - for instance It could also position it off-screen. I see no reason for the receiver to second-guess the position, since (like sourcing endpoints) the MCU is advertising the position of the audio and video in a common coordinate space. The same function could be accomplished without the audio attribute if there were mechanisms for explicitly announcing spatial relationships from the MCU to the renderer. I don't think the capture area concept is well suited for this. [sb]The capture scene concept is the mechanism for advertising spatial relationships both for original captures and mixed/composed captures, for both MCUs and endpoints. If you think it is not well suited, then it would be extremely helpful to hear more. =20 Regards Johan =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: 2. april 2012 21:56 To: Paul Kyzivat Cc: clue@ietf.org =09 Subject: Re: [clue] audio mixed attribute =20 in-line, snipped... On Mon, Apr 2, 2012 at 3:37 PM, Paul Kyzivat wrote: On 4/2/12 3:28 PM, Espen Berger (espeberg) wrote: An MCU can basically give me two types of audio streams, =09 *Mixed - The MCU mixes together audio and deliver a single audio stream based on some MCU cleverness =09 *Original - The MCU forward a audio stream un-modified from the source (based on VAD-level selection) =09 The purpose of the audio_type is only to make this distinction. =20 I'm pretty sure I'm more of a neophyte on the details of this than anybody else in the wg. But based on what I've observed, I still get the feeling that being aware of this distinction is insufficient to make any useful decisions about how to choose and use audio media. =09 Every example I've seen requires making additional, and unmotivated, assumptions about what has been mixed, or how, or both. =09 [sb] This is one of the points I am trying to make as well. I am certainly open to signaling attributes that aid rendering, but am not seeing how this one helps either selection or rendering.=20 =09 I do understand the goal of the composition flag for video - the idea there is to prevent nested hollywood squares. The definition may need some work, but the goal is clear.=20 =09 Thanks, Paul How to model and implement various spatial audio scenarios need further discussions, not the audio-type attribute. =09 -Espen =20 =20 =20 ------_=_NextPart_001_01CD118B.B0669847 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephen,

 

I think we have a common goal, I agree with what you write including = the expansion beyond 1:1 relationships, the features you describe are = great.

 

If the capture scene / area concepts are meant to solve these = features for the MCU case, I would very much like to see an example of = how, as I am not able to figure it out from the framework description. I = have asked for that on this list before without response. The example in = the framework doesn’t encompass spatial = audio.

 

For the MCU composing layouts on multiple displays and multiple = sites, how would the MCU construct and announce capture scene and areas = to the renderers to signal the spatial connections? And how will CLUE = signalling be done to be sufficiently fast to keep up with changes in = the connections and spatial positions when active speakers constantly = change?

 

The same questions are even more interesting with a fully switched = MCU.

 

Regards

Johan

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko
Sent: 3. april 2012 12:46
To: = Johan Ludvig Nielsen (johaniel)
Cc: = clue@ietf.org
Subject: Re: [clue] audio mixed = attribute

 

[inline]
Stephen

On Tue, Apr 3, 2012 at 4:48 AM, Johan Ludvig Nielsen = (johaniel) <johaniel@cisco.com> = wrote:

I will highlight one potential use for the audio type, which Espen = has actually already pointed out.

 

If the audio stream is natural/original, it can be expected to = correspond to a single video stream. The renderer can go search for this = connection in other attributes, and then render the audio at the correct = position. An important feature in a complex layout on a wide display = setup.

[sb] = Actually CLUE does not require a 1-1 correspondence between audio and = video captures.  You can for instance use 3 audio captures to span = 2 video captures. As displays continue to get larger, I am thinking this = configuration will occur in real = systems.

 

If the audio is mixed by the MCU there is no point in searching for a = connection, play audio in the center or across all = loudspeakers.

[sb] If the MCU is = composing video on multiple sites on the displays, then it could also = re-process the audio so that the audio and video positioning is = preserved. It is just as capable of doing this as the receiving = endpoint.  Of course, if the audio in a capture has no = correspondence to the video, the MCU can choose to signal it as being = centered if it wishes, and it can adjust the capture area to the full = range.  It has other options though - for instance It could also = position it off-screen.  I see no reason for the receiver to = second-guess the position, since (like sourcing endpoints) the MCU is = advertising the position of the audio and video in a common coordinate = space.

The same function could be accomplished without the audio attribute = if there were mechanisms for explicitly announcing spatial relationships = from the MCU to the renderer. I don’t think the capture area = concept is well suited for = this.

[sb]The capture scene concept is the mechanism for = advertising spatial relationships both for original captures and = mixed/composed captures, for both MCUs and endpoints.  If you think = it is not well suited, then it would be extremely helpful to hear = more.

 

Regards

Johan

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephen = Botzko
Sent: 2. april 2012 21:56
To: Paul = Kyzivat
Cc: clue@ietf.org


Subject: Re: [clue] audio mixed = attribute

 <= /o:p>

in-line, = snipped...

On Mon, Apr = 2, 2012 at 3:37 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

On 4/2/12 = 3:28 PM, Espen Berger (espeberg) wrote:

An MCU can = basically give me two types of audio streams,

·Mixed = – The MCU mixes together audio and deliver a single audio = stream
based on some MCU cleverness

·Original – = The MCU forward a audio stream un-modified from the source
(based on = VAD-level selection)

The purpose of the audio_type is only to = make this distinction.

 <= /o:p>

I'm pretty = sure I'm more of a neophyte on the details of this than anybody else in = the wg. But based on what I've observed, I still get the feeling that = being aware of this distinction is insufficient to make any useful = decisions about how to choose and use audio media.

Every example = I've seen requires making additional, and unmotivated, assumptions about = what has been mixed, or how, or both.


[sb] = This is one of the points I am trying to make as well.  I am = certainly open to signaling attributes that aid rendering, but am not = seeing how this one helps either selection or rendering.

I do = understand the goal of the composition flag for video - the idea there = is to prevent nested hollywood squares. The definition may need some = work, but the goal is clear.


    =    Thanks,
      =  Paul

How to model and = implement various spatial audio scenarios need further
discussions, = not the audio-type attribute.

-Espen

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CD118B.B0669847-- From stephen.botzko@gmail.com Tue Apr 3 04:22:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1DC21F8570 for ; Tue, 3 Apr 2012 04:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-3ZP6e+iS6w for ; Tue, 3 Apr 2012 04:22:15 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4F821F854E for ; Tue, 3 Apr 2012 04:22:15 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so5337665pbb.31 for ; Tue, 03 Apr 2012 04:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bgy8gXCpj999YDPpGOK57KQwHHvpZubekhyz/qSNWjI=; b=FJSKQ6ubilWkkOgjuX+pnQ5sCJw4A+QqqIXOjY4irqeAZC2KqmqXOol+YptAoqv+MA lVWoLbsmGaHsVGfhHcF0Vsj9TiV6qqvnTyvRQSAODMlgQVKJhh/aSUsZJhJSUrDVtPLh 8h+MNJY3i9wn9jsOC088jxqFKLXaVI6TZVb/JQ54cdTj8L5/2g2ap9h1282NYZ38mTmF 6V76fJWwpA+fEqYSLEVe1uEwi0NhNPs+S8DWIpXXk7m65yghAtCPGPEvytaQHWx4KiRh dpkVr6OnNOlbTTRZM3ZftHaBwl9s6WiYqVQYCYyiLVbnCsd7Of7qwSHVN/hvmipz7eDR KXiw== MIME-Version: 1.0 Received: by 10.68.200.104 with SMTP id jr8mr25193401pbc.164.1333452135339; Tue, 03 Apr 2012 04:22:15 -0700 (PDT) Received: by 10.68.32.37 with HTTP; Tue, 3 Apr 2012 04:22:15 -0700 (PDT) In-Reply-To: <05DD269BD82AA549BC4B2619BBAC466AFBE92C@XMB-AMS-206.cisco.com> References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> <20120327223212.GC5206@verdi> <05DD269BD82AA549BC4B2619BBAC466AFBE92C@XMB-AMS-206.cisco.com> Date: Tue, 3 Apr 2012 07:22:15 -0400 Message-ID: From: Stephen Botzko To: "Johan Ludvig Nielsen (johaniel)" Content-Type: multipart/alternative; boundary=047d7b10cff3da17b804bcc4840f Cc: clue@ietf.org Subject: Re: [clue] Steered microphone arrays X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 11:22:16 -0000 --047d7b10cff3da17b804bcc4840f Content-Type: text/plain; charset=ISO-8859-1 [in line] On Tue, Apr 3, 2012 at 3:37 AM, Johan Ludvig Nielsen (johaniel) < johaniel@cisco.com> wrote: > Hi > > A microphone array can behave similar to a steered directional microphone, > with a fixed position (center of array) and focussing its beam in different > directions. Like a passive sonar. > > The concept of preserving arrival-time information seems to me to be > useful only when you have several microphones somehow translating into > several output streams, in which case an array with a single processed > output and a shotgun would behave equally as one of those microphones. > > An array can also have several output streams, looking in several > directions and picking up spatially separated sound sources simultaneously. > However, the effective mic position would still be fixed and the same for > the different sources, no inherent arrival-time differences. > > The array can, however, know which direction it is looking, and use this > to embed time (and/or level) differences in output streams. Or (perhaps > better) add meta data about direction or even position to the streams. > > [sb]generally agree I would rather see the source send the proper level rather than force receivers to adjust. One reason is that VAD detection generally includes energy, so VAD will be mismatched if senders use mismatched levels. This biases switching decisions. Though I think this is out of scope for CLUE. I would not tag the single stream output of a (steered or not steered) > microphone array as "mixed". Logically it is a single audio capture with > potentially high (and time-varying) directivity, but a fixed position. > [sb] I agree it is not mixed. Time-varying directivity is a problem - signaling in the media plane would help, but there is still the disaggregated media challenge. Another option is to generate multiple captures from the steered array, to allow the capture attributes to be fixed. For instance, generate a stereo capture, using panning to get the current position correct. The directivity then results in good noise rejection. Some future codecs (SAOC) would allow the position of each human speaker in the capture to be signaled in the audio stream - which should not be precluded. > > However, John's goal of preserving sound source direction information is > important and should definitely be worked on further > [sb] We have talked much more about video than audio so far. It is good to see more audio discussion. The "virtual microphone" is a slightly different thing, where an array in > one position is processed to a single output with the illusion of being a > microphone placed somewhere else. I agree with Stephen that it can be done, > but it has some challenges and I doubt that it will be an important usecase > in telepresence anytime soon. [sb]The protocol will hopefully be relevant for many years. We have used microphone arrays for a long time to do automatic camera steering, It is forseeable that such arrays will be used for telepresence. One advantage they have is they allow multiple capture advertisements to be generated from a single set of sensors. > Regards > Johan > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Stephen Botzko > Sent: 2. april 2012 18:03 > To: John Leslie > Cc: clue@ietf.org > Subject: Re: [clue] Steered microphone arrays > > in-line > On Tue, Mar 27, 2012 at 6:32 PM, John Leslie wrote: > Stephen Botzko wrote: > > On Tue, Mar 27, 2012 at 6:12 AM, John Leslie wrote: > >> Stephen Botzko wrote: > >> > >>> [sb] Are you suggesting that every system using a steered microphone > >>> array would be tagged as "mixed"? > >> > >> Actually, yes: in the case of a steered _array_ of microphones, the > >> arrival-time information will be lost, just as in an audio mixer with > >> multiple microphones. > >> > >> This is distinct from the case of a steered "shotgun" microphone where > >> the mike position is fixed (though its directional pattern changes), > thus > >> arrival-time information is preserved. > >> > >> [sb] I believe steered microphone arrays are used commonly in sonar > >> acquisition, > > This is true... > > >> so I don't believe arrival time information has to be lost. > >> Usually the microphones in such an array are in fixed positions. > > As usual, the devil is in the details... > > In sonar, there's a very clearly-positioned sound source, and the > return times of the microphone array are calibrated to that source. > (Actually, the source likely produces a "chirp" of varying wavelength > and the phase differences are processed during the chirp response.) > > In our microphone array, the position of the sound source is > variable and there's no control of its wavelengths. It is technically > possible to compare phase information of several microphones and > process the sound output to that which "would be received" by a mike > at a given position (within the range of the microphone array, of > course); but if any existing system does that, I haven't heard of it. > [sb] we have built systems that do that, and that is exactly what I mean > by a steerable array. > > Again, we're going to have to trust operators to set the "mixed" > bit: we can only offer guidance... > > -- > John Leslie > > --047d7b10cff3da17b804bcc4840f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [in line]

On Tue, Apr 3, 2012 at 3:37 AM,= Johan Ludvig Nielsen (johaniel) <johaniel@cisco.com> wrote:
Hi

A microphone array can behave similar to a steered directional microphone, = with a fixed position (center of array) and focussing its beam in different= directions. Like a passive sonar.

The concept of preserving arrival-time information seems to me to be useful= only when you have several microphones somehow translating into several ou= tput streams, in which case an array with a single processed output and a s= hotgun would behave equally as one of those microphones.

An array can also have several output streams, looking in several direction= s and picking up spatially separated sound sources simultaneously. However,= the effective mic position would still be fixed and the same for the diffe= rent sources, no inherent arrival-time differences.

The array can, however, know which direction it is looking, and use this to= embed time (and/or level) differences in output streams. Or (perhaps bette= r) add meta data about direction or even position to the streams.

[sb]generally agree=A0 I would rather see the source = send the proper level rather than force receivers to adjust.=A0 One reason = is that VAD detection generally includes energy, so VAD will be mismatched = if senders use mismatched levels.=A0 This biases switching decisions.=A0 Th= ough I think this is out of scope for CLUE.

I would not tag the single stream output of a (steered or not steered) micr= ophone array as "mixed". Logically it is a single audio capture w= ith potentially high (and time-varying) directivity, but a fixed position.<= br>
=A0
[sb] I agree it is not mixed.=A0 Time-varyi= ng directivity is a problem - signaling in the media plane would help, but = there is still the disaggregated media challenge.=A0 Another option is to g= enerate multiple captures from the steered array, to allow the capture attr= ibutes to be fixed.=A0 For instance, generate a stereo capture, using panni= ng to get the current position correct.=A0 The directivity then results in = good noise rejection.=A0 Some future codecs (SAOC) would allow the position= of each human speaker in the capture to be signaled in the audio stream - = which should not be precluded.=A0

However, John's goal of preserving sound source direction information i= s important and should definitely be worked on further
[sb] We have talked much more about video than audio so far.=A0 It is good= to see more audio discussion.

The "virtual microphone" is a slightly different thing, where an = array in one position is processed to a single output with the illusion of = being a microphone placed somewhere else. I agree with Stephen that it can = be done, but it has some challenges and I doubt that it will be an importan= t usecase in telepresence anytime soon.
=A0
[sb]The protocol will hopefully be relevant for many years.=A0 = We have used microphone arrays for a long time to do automatic camera steer= ing,=A0 It is forseeable that such arrays will be used for telepresence.=A0= One advantage they have is they allow multiple capture advertisements to b= e generated from a single set of sensors.
=A0
Regards
Johan


From: clue-bounces@ietf.org [m= ailto:clue-bounces@ietf.org] O= n Behalf Of Stephen Botzko
Sent: 2. april 2012 18:03
To: John Leslie
Cc: clue@ietf.org
Subject: Re: [clue] Steered microphone arrays

in-line
On Tue, Mar 27, 2012 at 6:32 PM, John Leslie <john@jlc.net> wrote:
Stephen Botzko <stephen.botz= ko@gmail.com> wrote:
> On Tue, Mar 27, 2012 at 6:12 AM, John Leslie <john@jlc.net> wrote:
>> Stephen Botzko <ste= phen.botzko@gmail.com> wrote:
>>
>>> [sb] =A0Are you suggesting that every system using a steered m= icrophone
>>> array would be tagged as "mixed"?
>>
>> Actually, yes: in the case of a steered _array_ of microphones, th= e
>> arrival-time information will be lost, just as in an audio mixer w= ith
>> multiple microphones.
>>
>> This is distinct from the case of a steered "shotgun" mi= crophone where
>> the mike position is fixed (though its directional pattern changes= ), thus
>> arrival-time information is preserved.
>>
>> [sb] I believe steered microphone arrays are used commonly in sona= r
>> acquisition,

=A0 This is true...

>> so I don't believe arrival time information has to be lost. >> Usually the microphones in such an array are in fixed positions.
=A0 As usual, the devil is in the details...

=A0 In sonar, there's a very clearly-positioned sound source, and the return times of the microphone array are calibrated to that source.
(Actually, the source likely produces a "chirp" of varying wavele= ngth
and the phase differences are processed during the chirp response.)

=A0 In our microphone array, the position of the sound source is
variable and there's no control of its wavelengths. It is technically possible to compare phase information of several microphones and
process the sound output to that which "would be received" by a m= ike
at a given position (within the range of the microphone array, of
course); but if any existing system does that, I haven't heard of it. [sb] we have built systems that do that, and that is exactly what I mean by= a steerable array.

=A0 Again, we're going to have to trust operators to set the "mixe= d"
bit: we can only offer guidance...

--
John Leslie <john@jlc.net>


--047d7b10cff3da17b804bcc4840f-- From mary.ietf.barnes@gmail.com Tue Apr 3 10:56:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05BB21F8534 for ; Tue, 3 Apr 2012 10:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXOxJ2QHbIj8 for ; Tue, 3 Apr 2012 10:56:24 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA91721F8471 for ; Tue, 3 Apr 2012 10:56:23 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3058115vcb.31 for ; Tue, 03 Apr 2012 10:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=jp++jgqOq5htbrgVa9Z14rq0lGyxbnLPpHbenfpNiCg=; b=IXgF9PFeEDS1EmXsimK3gPHv2jLob1qkiNJwU6WCdzMnhuELjKFBuN3J7aZvL8D6Af 4baITr5YxgiOGm29BkmmMiAC+xbPmP6gPFc3j3lHRdXS3Dn9ga+9lVNQt1WqeenWKAox aMXERIlBhiBmUTMjCZMwK/rjgK1FjxU2FfwDXOq/oYm8z7+i+Z/1Zo8Ct+Dk74fFU40W YCVbGTjNgkZr5ApT60swdiu0z4drbz/hRuzunq5zXPpU3zPHxmBJsmkkISlsOp3S/7Fr bxl6z9CZdPZrHgr0QQFDEpnPjw73I/ns7v46FUc8hlxkcJgKa0feDrZA+ekwZQbhJjC1 VGoQ== MIME-Version: 1.0 Received: by 10.52.28.200 with SMTP id d8mr5337045vdh.38.1333475783168; Tue, 03 Apr 2012 10:56:23 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Tue, 3 Apr 2012 10:56:23 -0700 (PDT) Date: Tue, 3 Apr 2012 12:56:23 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf3079bc9e5f510a04bcca0665 Subject: [clue] Poll for "CLUE WG Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 17:56:25 -0000 --20cf3079bc9e5f510a04bcca0665 Content-Type: text/plain; charset=ISO-8859-1 As discussed during the 2nd CLUE WG session, we are planning an interim meeting in the late May/early June timeframe. We would like to coordinate this with an RTCWEB interim meeting which is also in the planning stages: http://doodle.com/nm3pp69znr3286cy Thus, the date options are designed around meeting the same week as RTCWEB. Please indicate your availability in the following doodle poll no later than Friday, April 13th. http://www.doodle.com/zd4mhfsb63wkm7ww Note, that we will determine the location based upon whether we meet the same week as RTCWEB. If we don't then we can separately decide what is the best location. Thanks, Mary. WG co-chair --20cf3079bc9e5f510a04bcca0665 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As discussed during the 2nd CLUE WG session, we are planning an interim mee= ting in the late May/early June timeframe. =A0We would like to coordinate t= his with an RTCWEB interim meeting which is also in the planning stages:

Thus, the date options are de= signed around meeting the same week as RTCWEB. =A0Please indicate your avai= lability in the following doodle poll no later than Friday, April 13th.

Note, th= at we will determine the location based upon whether we meet the same week = as RTCWEB. =A0If we don't then we can separately decide what is the bes= t location. =A0

Thanks,
Mary.
WG co-chair








--20cf3079bc9e5f510a04bcca0665-- From ron.even.tlv@gmail.com Tue Apr 3 14:59:39 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCDF21F8522 for ; Tue, 3 Apr 2012 14:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-VQRBSrwKFh for ; Tue, 3 Apr 2012 14:59:39 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 84D9921F851D for ; Tue, 3 Apr 2012 14:59:38 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so116931wgb.13 for ; Tue, 03 Apr 2012 14:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=hs3J2YAzuK7w6mqvjmx8FtVEOo1O0Ta7pBPl7e8m3lI=; b=sRx5Ss/xHK4MqFy0GA37lw+hjGwsF2jFZn2FA0B3Lz47ZeedfQ9W9VlV9il+z82yAh GehBvUA0wYc8sPt59HhiDvZqySALg/1lHvenY5xv7Dt4tfQjRK1+JDE/Z2n2xzv4pkZ3 S2HkU/OkCDXdVD3ZcHjn8Bh+6g3oVdS4BfyqOndC9OuLAVY9RPun2cHynabX9dTMy6w+ VKs5TmaRwZUXxYLSFeA2XRPjrEMP5AEb7sEKy4CNtYfGBD4g/+JaHrqir92U1dyb9xRq kz78bESvzDfTwLNig316SeLtknWJU4ahGsSGrPxjeo5dGhF0XOIXYkwUuxnxlKVYBQNJ SNUA== Received: by 10.180.104.231 with SMTP id gh7mr40422841wib.10.1333490377623; Tue, 03 Apr 2012 14:59:37 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id 17sm55638520wis.0.2012.04.03.14.59.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 14:59:36 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Wed, 4 Apr 2012 00:58:14 +0300 Message-ID: <4f7b72c8.5102b40a.12b3.ffffbab7@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0174_01CD11FE.056912F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0Rwxo7dIezmy2mQQy6hR21pywq0QAIXwug Content-Language: en-us Subject: Re: [clue] Poll for "CLUE WG Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 21:59:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0174_01CD11FE.056912F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, May 26th is a Jewish Holiday and it is not possible for me to get back from the US if the meeting is on the 24th Thanks Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Tuesday, April 03, 2012 8:56 PM To: CLUE Subject: [clue] Poll for "CLUE WG Interim meeting" As discussed during the 2nd CLUE WG session, we are planning an interim meeting in the late May/early June timeframe. We would like to coordinate this with an RTCWEB interim meeting which is also in the planning stages: http://doodle.com/nm3pp69znr3286cy Thus, the date options are designed around meeting the same week as RTCWEB. Please indicate your availability in the following doodle poll no later than Friday, April 13th. http://www.doodle.com/zd4mhfsb63wkm7ww Note, that we will determine the location based upon whether we meet the same week as RTCWEB. If we don't then we can separately decide what is the best location. Thanks, Mary. WG co-chair ------=_NextPart_000_0174_01CD11FE.056912F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

May 26th is a Jewish Holiday and it is not possible for me = to get back from the US if the meeting is on the = 24th

Thanks

Roni Even

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: Tuesday, April 03, 2012 8:56 = PM
To: CLUE
Subject: [clue] Poll for "CLUE WG = Interim meeting"

 

As discussed = during the 2nd CLUE WG session, we are planning an interim meeting in = the late May/early June timeframe.  We would like to coordinate = this with an RTCWEB interim meeting which is also in the planning = stages:

 

Thus, the date options are designed around meeting the = same week as RTCWEB.  Please indicate your availability in the = following doodle poll no later than Friday, April = 13th.

 

Note, that we will determine the location based upon = whether we meet the same week as RTCWEB.  If we don't then we can = separately decide what is the best location. =  

 

Thanks,

Mary.

WG co-chair






<= p = class=3DMsoNormal> 

------=_NextPart_000_0174_01CD11FE.056912F0-- From mary.ietf.barnes@gmail.com Tue Apr 3 15:37:54 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BD711E80F4 for ; Tue, 3 Apr 2012 15:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IO2e-LRUk2q for ; Tue, 3 Apr 2012 15:37:53 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1FE511E8086 for ; Tue, 3 Apr 2012 15:37:53 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so168466vbb.31 for ; Tue, 03 Apr 2012 15:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CA2tXvoveldD34dF8zuEnciRiHbmr8zhVW+zlaMogLs=; b=itPVwbrwndKxEjvG6OXSdXYD40v9M53W4TSsetj1UhoLfjOvgs/zO/8Fvb3XADYjqO jbooTchcbGy4AmceSuMj7YedeuwOsGwAPgUgK77PdoSSxjGIykrTsL3j4B3NjB/GLzrl d9ML8nxNQId1aViWJQQYAxZdJ5KtwhuOubq4zNHR7Grc9Jy9tDJ/aoXmHZCsATOsPnHb 9cj/yekQwO/JV22BsLKyeKfCAhRIbejU2bihzio6EmG1yZsqBUh+JEXfDgYScVDnWoiK kAkWUOPhkrDlDqPjJyyjiyABdGt+ih3Pi/V4VfDjbmxnje3g1/4gZi6jkaH7zRW9sgS3 oRMQ== MIME-Version: 1.0 Received: by 10.220.115.82 with SMTP id h18mr6612560vcq.18.1333492673251; Tue, 03 Apr 2012 15:37:53 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Tue, 3 Apr 2012 15:37:53 -0700 (PDT) In-Reply-To: <4f7b72c8.5102b40a.12b3.ffffbab7@mx.google.com> References: <4f7b72c8.5102b40a.12b3.ffffbab7@mx.google.com> Date: Tue, 3 Apr 2012 17:37:53 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=f46d043c7c781989ee04bccdf563 Cc: CLUE Subject: Re: [clue] Poll for "CLUE WG Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 22:37:54 -0000 --f46d043c7c781989ee04bccdf563 Content-Type: text/plain; charset=ISO-8859-1 Then put those dates as not available for you. Those aren't optimal dates for many of us in the U.S. either as it's very common to travel on that 3 day weekend, so getting home late on Friday night isn't ideal. Mary. On Tue, Apr 3, 2012 at 4:58 PM, Roni Even wrote: > Hi,**** > > May 26th is a Jewish Holiday and it is not possible for me to get back > from the US if the meeting is on the 24th**** > > Thanks**** > > Roni Even**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* Tuesday, April 03, 2012 8:56 PM > *To:* CLUE > *Subject:* [clue] Poll for "CLUE WG Interim meeting"**** > > ** ** > > As discussed during the 2nd CLUE WG session, we are planning an interim > meeting in the late May/early June timeframe. We would like to coordinate > this with an RTCWEB interim meeting which is also in the planning stages:* > *** > > http://doodle.com/nm3pp69znr3286cy**** > > ** ** > > Thus, the date options are designed around meeting the same week as > RTCWEB. Please indicate your availability in the following doodle poll no > later than Friday, April 13th.**** > > http://www.doodle.com/zd4mhfsb63wkm7ww**** > > ** ** > > Note, that we will determine the location based upon whether we meet the > same week as RTCWEB. If we don't then we can separately decide what is the > best location. **** > > ** ** > > Thanks,**** > > Mary.**** > > WG co-chair**** > > > > > > > **** > > ** ** > --f46d043c7c781989ee04bccdf563 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Then put those dates as not available for you. =A0Those aren't optimal = dates for many of us in the U.S. either as it's very common to travel o= n that 3 day weekend, so getting home late on Friday night isn't ideal.= =A0

Mary.=A0

On Tue, Apr = 3, 2012 at 4:58 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi,

May 26th is a Jewish Holiday a= nd it is not possible for me to get back from the US if the meeting is on t= he 24th

Thanks

Roni Even=

=A0<= /p>

From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Tuesday, April 03, 2012 8:56 PM
To: CLUE
Subje= ct: [clue] Poll for "CLUE WG Interim meeting"

=A0

As discussed during the 2nd CLU= E WG session, we are planning an interim meeting in the late May/early June= timeframe. =A0We would like to coordinate this with an RTCWEB interim meet= ing which is also in the planning stages:

=A0

=

Thus, the date options are designed around meeting the same week as RTCWEB.= =A0Please indicate your availability in the following doodle poll no later= than Friday, April 13th.

=A0

Note,= that we will determine the location based upon whether we meet the same we= ek as RTCWEB. =A0If we don't then we can separately decide what is the = best location. =A0

=A0

Thanks,

M= ary.

WG co-chair






=A0

<= /blockquote>

--f46d043c7c781989ee04bccdf563-- From ron.even.tlv@gmail.com Tue Apr 3 23:27:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC7721F86F2 for ; Tue, 3 Apr 2012 23:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMU+zOnkvlDV for ; Tue, 3 Apr 2012 23:27:37 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3598421F86A5 for ; Tue, 3 Apr 2012 23:27:30 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so291639wgb.13 for ; Tue, 03 Apr 2012 23:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=M575rA9IlRrOph42yoqc88Liy65gWZ9E+b43EfUyzP4=; b=Sr3Oa6yFboY6xyAg/dDjh0bsuyfEWGuSJVcPW+K/8s+OoD6aGuSwipMmfCSwEJM20h XtnnjUAv6HefHTb3o0Tzbn/sQdQ6zfawjtm/4qQhtc1koFGyLdnxug+ExFp9PmOcbR3V eFFKKEbKrCzwlPU6UVCccnnkrapEppxa2RNRrRGQ7PWZ2bZ28dToDMpOasiWN/Yf/BR6 XpDRAUUlFU6eOooODw8cwFahEKdiwUyB00Oe1DGTDUy49BA7r3YF7MlDy+6N1aHlmffQ ud258DZjZ1fPz6/YsT0TAxMYmlzhKL+rU01tQAzPd3QJns718WIxrGGde7PW1kSd54CS 9sww== Received: by 10.180.92.71 with SMTP id ck7mr2207487wib.21.1333520849442; Tue, 03 Apr 2012 23:27:29 -0700 (PDT) Received: from windows8d787f9 (bzq-109-65-204-117.red.bezeqint.net. [109.65.204.117]) by mx.google.com with ESMTPS id fz9sm2345303wib.3.2012.04.03.23.27.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 23:27:28 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" References: <4f7b72c8.5102b40a.12b3.ffffbab7@mx.google.com> In-Reply-To: Date: Wed, 4 Apr 2012 09:26:06 +0300 Message-ID: <4f7be9d0.e967b40a.1c6b.67db@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01CD1244.F7C3E8E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0R6mgXNf7xJzm4Tkyv3zDn3foQYAAQPT2A Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Poll for "CLUE WG Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 06:27:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002B_01CD1244.F7C3E8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mary, This is not equivalent to a three days weekend, this is a Holiday when the whole family meets like your thanksgiving and I do not believe that you will plan an interim meeting that will prevent U.S. guys from being with their family on such a day. Thanks Roni From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Wednesday, April 04, 2012 1:38 AM To: Roni Even Cc: CLUE Subject: Re: [clue] Poll for "CLUE WG Interim meeting" Then put those dates as not available for you. Those aren't optimal dates for many of us in the U.S. either as it's very common to travel on that 3 day weekend, so getting home late on Friday night isn't ideal. Mary. On Tue, Apr 3, 2012 at 4:58 PM, Roni Even wrote: Hi, May 26th is a Jewish Holiday and it is not possible for me to get back from the US if the meeting is on the 24th Thanks Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Tuesday, April 03, 2012 8:56 PM To: CLUE Subject: [clue] Poll for "CLUE WG Interim meeting" As discussed during the 2nd CLUE WG session, we are planning an interim meeting in the late May/early June timeframe. We would like to coordinate this with an RTCWEB interim meeting which is also in the planning stages: http://doodle.com/nm3pp69znr3286cy Thus, the date options are designed around meeting the same week as RTCWEB. Please indicate your availability in the following doodle poll no later than Friday, April 13th. http://www.doodle.com/zd4mhfsb63wkm7ww Note, that we will determine the location based upon whether we meet the same week as RTCWEB. If we don't then we can separately decide what is the best location. Thanks, Mary. WG co-chair ------=_NextPart_000_002B_01CD1244.F7C3E8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mary,

This is not equivalent to a three days weekend, this is a Holiday = when the whole family meets like your thanksgiving  and I do not = believe that you will plan an interim meeting that will prevent U.S. = guys from being with their family on such a day.

Thanks

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: = Wednesday, April 04, 2012 1:38 AM
To: Roni Even
Cc: = CLUE
Subject: Re: [clue] Poll for "CLUE WG Interim = meeting"

 

Then put = those dates as not available for you.  Those aren't optimal dates = for many of us in the U.S. either as it's very common to travel on that = 3 day weekend, so getting home late on Friday night isn't = ideal. 

 

Mary. 

On Tue, Apr 3, 2012 at 4:58 PM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi,

May 26th is a Jewish Holiday and it is not possible for me = to get back from the US if the meeting is on the = 24th

Thanks

Roni Even

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: Tuesday, April 03, 2012 8:56 PM
To: = CLUE
Subject: [clue] Poll for "CLUE WG Interim = meeting"

 <= /o:p>

As = discussed during the 2nd CLUE WG session, we are planning an interim = meeting in the late May/early June timeframe.  We would like to = coordinate this with an RTCWEB interim meeting which is also in the = planning stages:

http://doodle.com/nm3pp69znr3286cy

 <= /o:p>

Thus, the = date options are designed around meeting the same week as RTCWEB. =  Please indicate your availability in the following doodle poll no = later than Friday, April 13th.

 <= /o:p>

Note, that = we will determine the location based upon whether we meet the same week = as RTCWEB.  If we don't then we can separately decide what is the = best location.  

 <= /o:p>

Thanks,=

Mary.

WG = co-chair





 <= /o:p>

 

------=_NextPart_000_002B_01CD1244.F7C3E8E0-- From allyn@cisco.com Wed Apr 4 00:06:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F58921F8454 for ; Wed, 4 Apr 2012 00:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB9LdMGvK6SN for ; Wed, 4 Apr 2012 00:06:24 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B4F6021F847E for ; Wed, 4 Apr 2012 00:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=6797; q=dns/txt; s=iport; t=1333523183; x=1334732783; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=4MHEZ3NOhQqySp+4kg7HsVRPXcxp/Aw0Q41XiAFyLhA=; b=j5/H9zr10iEBtRWNywyg4RpnwPdvatcfNPnIM7N8kvlMFsMCj4zaVcMo QwY8v0vP55zTQDI/w/4npYEFnq2jBpBZDjdkBe8mRUhpsA8Phr9IzJOfg mr6QD6hjI2t5XtfHTGLyFzZ8M5DBtpuNJMRXChCAN5EQAUU0OzXpG689X 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAFfye0+rRDoH/2dsb2JhbABFgkasWoh3gQeCCQEBAQQSAQkRA0QVAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHZgELmwueb49xYwSIJTOOHI02gWmDBw X-IronPort-AV: E=Sophos;i="4.75,366,1330905600"; d="scan'208,217";a="36410828" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 04 Apr 2012 07:06:22 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3476MLu006398; Wed, 4 Apr 2012 07:06:22 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 00:06:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1231.70A13AA1" Date: Wed, 4 Apr 2012 00:06:20 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC072C8204@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Poll for "CLUE WG Interim meeting" Thread-Index: Ac0RwxmCvhVE+3iqS5OFn45di1LA2wAbUR3A References: From: "Allyn Romanow (allyn)" To: "Mary Barnes" , "CLUE" X-OriginalArrivalTime: 04 Apr 2012 07:06:22.0262 (UTC) FILETIME=[71076560:01CD1231] Subject: Re: [clue] Poll for "CLUE WG Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 07:06:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1231.70A13AA1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mary, I was wondering why the meeting is scheduled for day and =BD instead of = 2 days? It seemed to me more productive at the last meeting which was = scheduled for 2 days, even though some people left a bit early to catch = flights. When it's scheduled for 1.5 days, people will leave early, = making it more of a one day meeting. If most of us are traveling, I feel = like 1.5 days is a bit short if we have work that will fill the time for = 2 days. =20 Thanks, Allyn From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes Sent: Tuesday, April 03, 2012 10:56 AM To: CLUE Subject: [clue] Poll for "CLUE WG Interim meeting" =20 As discussed during the 2nd CLUE WG session, we are planning an interim = meeting in the late May/early June timeframe. We would like to = coordinate this with an RTCWEB interim meeting which is also in the = planning stages: http://doodle.com/nm3pp69znr3286cy =20 Thus, the date options are designed around meeting the same week as = RTCWEB. Please indicate your availability in the following doodle poll = no later than Friday, April 13th. http://www.doodle.com/zd4mhfsb63wkm7ww =20 Note, that we will determine the location based upon whether we meet the = same week as RTCWEB. If we don't then we can separately decide what is = the best location. =20 =20 Thanks, Mary. WG co-chair =20 ------_=_NextPart_001_01CD1231.70A13AA1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Mary,

I was wondering why the meeting is scheduled for day and =BD instead = of 2 days? It seemed to me more productive at the last meeting which was = scheduled for 2 days, even though some people left a bit early to catch = flights. When it’s scheduled for 1.5 days, people will leave = early, making it more of a one day meeting. If most of us are traveling, = I feel like 1.5 days is a bit short if we have work that will fill the = time for 2 days.

 

Thanks,

Allyn

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: Tuesday, April 03, 2012 10:56 = AM
To: CLUE
Subject: [clue] Poll for "CLUE WG = Interim meeting"

 

As discussed = during the 2nd CLUE WG session, we are planning an interim meeting in = the late May/early June timeframe.  We would like to coordinate = this with an RTCWEB interim meeting which is also in the planning = stages:

 

Thus, the date options are designed around meeting the = same week as RTCWEB.  Please indicate your availability in the = following doodle poll no later than Friday, April = 13th.

 

Note, that we will determine the location based upon = whether we meet the same week as RTCWEB.  If we don't then we can = separately decide what is the best location. =  

 

Thanks,

Mary.

WG co-chair






<= p = class=3DMsoNormal> 

------_=_NextPart_001_01CD1231.70A13AA1-- From mary.ietf.barnes@gmail.com Wed Apr 4 07:51:06 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D2C21F87EB for ; Wed, 4 Apr 2012 07:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgAkWynVDBf6 for ; Wed, 4 Apr 2012 07:51:05 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C8DE021F851A for ; Wed, 4 Apr 2012 07:51:04 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so249825vbb.31 for ; Wed, 04 Apr 2012 07:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rKeo9f/6PwoaQHLXANj8k+mXpD6YvEFoe8w2/N3oges=; b=MH3KEKUiBl0PG8xXVDQFeJyY+Rix7xT0piGYNaC48RRXU+B8Ho8MyhW+Ks8kXe4UB5 ZPePQIkIFwxUHWYwvd+CjNMBq3+a7YEUH14NJbiHMBC3F2AD+PahZIi29TL/Ud5qjftu BG+97wcmxUm4QsU6jfyUlkiB1XcCbuPng4/83pL/t12nFb13iWUSz45mQwtV/QWZlcgX LYTuSaecLMEAXmkW5nywz32sqnBPHognFXdUQ3vy8tillHScmosLnjKg7Yg9wi49xjSS +1qQUkby/ldcGJtSTIJvcdsgHXSGrtz/ebkIwifTrgTQZOCZLV+0bEwnkX/paLHH26rM Uznw== MIME-Version: 1.0 Received: by 10.52.72.169 with SMTP id e9mr6741266vdv.21.1333551064303; Wed, 04 Apr 2012 07:51:04 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Wed, 4 Apr 2012 07:51:04 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC072C8204@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC072C8204@xmb-sjc-221.amer.cisco.com> Date: Wed, 4 Apr 2012 09:51:04 -0500 Message-ID: From: Mary Barnes To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=20cf3071d0a27a47f204bcdb8d17 Cc: CLUE Subject: Re: [clue] Poll for "CLUE WG Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:51:06 -0000 --20cf3071d0a27a47f204bcdb8d17 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Last time, everyone was totally brain fried by around 1pm even though we had planned for the meeting to go til 5pm, which is about how late I would anticipate to run the meeting - i.e., starting at 8:30 am and go straight through to 1pm with a couple breaks (or we'll start at noon if it's the day after memorial day). So, many of us ended up staying an extra nite as we couldn't get the late flights. With 4 of the date options having us end on Friday, I would prefer that we stick with the 1.5+. However, if we get one of the mid-week dates, perhaps we can consider two full days. Mary. On Wed, Apr 4, 2012 at 2:06 AM, Allyn Romanow (allyn) wrot= e: > Hi Mary,**** > > I was wondering why the meeting is scheduled for day and =BD instead of 2 > days? It seemed to me more productive at the last meeting which was > scheduled for 2 days, even though some people left a bit early to catch > flights. When it=92s scheduled for 1.5 days, people will leave early, mak= ing > it more of a one day meeting. If most of us are traveling, I feel like 1.= 5 > days is a bit short if we have work that will fill the time for 2 days.**= * > * > > ** ** > > Thanks,**** > > Allyn**** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* Tuesday, April 03, 2012 10:56 AM > > *To:* CLUE > *Subject:* [clue] Poll for "CLUE WG Interim meeting"**** > > ** ** > > As discussed during the 2nd CLUE WG session, we are planning an interim > meeting in the late May/early June timeframe. We would like to coordinat= e > this with an RTCWEB interim meeting which is also in the planning stages:= * > *** > > http://doodle.com/nm3pp69znr3286cy**** > > ** ** > > Thus, the date options are designed around meeting the same week as > RTCWEB. Please indicate your availability in the following doodle poll n= o > later than Friday, April 13th.**** > > http://www.doodle.com/zd4mhfsb63wkm7ww**** > > ** ** > > Note, that we will determine the location based upon whether we meet the > same week as RTCWEB. If we don't then we can separately decide what is t= he > best location. **** > > ** ** > > Thanks,**** > > Mary.**** > > WG co-chair**** > > > > > > > **** > > ** ** > --20cf3071d0a27a47f204bcdb8d17 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Last time, everyone was totally brain fried by around 1pm even though we ha= d planned for the meeting to go til 5pm, which is about how late I would an= ticipate to run the meeting - i.e., starting at 8:30 am and go straight thr= ough to 1pm with a couple breaks (or we'll start at noon if it's th= e day after memorial day). =A0 So, many of us ended up staying an extra nit= e as we couldn't get the late flights. =A0With 4 of the date options ha= ving us end on Friday, I would prefer that we stick with the 1.5+. =A0Howev= er, if we get one of the mid-week dates, perhaps we can consider two full d= ays.=A0

Mary.=A0

On Wed, Apr 4, 20= 12 at 2:06 AM, Allyn Romanow (allyn) <allyn@cisco.com> wrote:

Hi Mary,

I was wondering why the meeting is scheduled for= day and =BD instead of 2 days? It seemed to me more productive at the last= meeting which was scheduled for 2 days, even though some people left a bit= early to catch flights. When it=92s scheduled for 1.5 days, people will le= ave early, making it more of a one day meeting. If most of us are traveling= , I feel like 1.5 days is a bit short if we have work that will fill the ti= me for 2 days.

=A0<= /p>

Thanks,<= /span>

Allyn

From: clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Tuesday, April 03, 2012 10:56 AM

<= br>To: CLUE
Subject: [clue] Poll for "CLUE WG Interim= meeting"

=A0

As discussed during the 2nd CLUE WG session, we are = planning an interim meeting in the late May/early June timeframe. =A0We wou= ld like to coordinate this with an RTCWEB interim meeting which is also in = the planning stages:

=A0

Thus, the date options are designed aroun= d meeting the same week as RTCWEB. =A0Please indicate your availability in = the following doodle poll no later than Friday, April 13th.

=A0

<= div>

Note, that we will determine the location based upon whether we meet the sa= me week as RTCWEB. =A0If we don't then we can separately decide what is= the best location. =A0

= =A0

Thanks,

Mary.

WG co-chair






= =A0

=
--20cf3071d0a27a47f204bcdb8d17-- From mary.ietf.barnes@gmail.com Wed Apr 4 07:55:05 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46A121F86CB for ; Wed, 4 Apr 2012 07:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WalLj2OiBTcL for ; Wed, 4 Apr 2012 07:55:05 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5B9421F86AD for ; Wed, 4 Apr 2012 07:55:04 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so255167vbb.31 for ; Wed, 04 Apr 2012 07:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T44oIJ499FC5oCPb7o0uJbuRP214DhjGilW9vO/BgeU=; b=dQvmX4vyZrrOPnSnlVlhkmbMV35/O+x5J5KX7+f8V9ilKKeWksB17ELyS7zXrNpCeh kijSjZLRz8dySOWayBFn1bjJncP27VcDm09CsXXxaX+1+Umf+a2jOmzpJdW/Sq5t0s9n dDLkdE6f2irVufLd17K8bZoyMUsMSjhGUXBHLP6W1sAiX73zyvJk+NTCK2otFQG0j/Ot +tkJmu0TJDCosXLBk72JbCkN4pd7kteWSgqKuu6pog7ESN5aw8AECqnDw5B7zWEiUmeU xIhvcDqBoqeiUqtxpHQOj5pvLm5I0fITajDGRuAJwSmg65ftjHlnXVIZ8aiciauxCDiD 4g7Q== MIME-Version: 1.0 Received: by 10.52.72.169 with SMTP id e9mr6749933vdv.21.1333551304286; Wed, 04 Apr 2012 07:55:04 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Wed, 4 Apr 2012 07:55:04 -0700 (PDT) In-Reply-To: <4f7be9d0.e967b40a.1c6b.67db@mx.google.com> References: <4f7b72c8.5102b40a.12b3.ffffbab7@mx.google.com> <4f7be9d0.e967b40a.1c6b.67db@mx.google.com> Date: Wed, 4 Apr 2012 09:55:04 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=20cf3071d0a2c821dd04bcdb9b61 Cc: CLUE Subject: Re: [clue] Poll for "CLUE WG Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:55:06 -0000 --20cf3071d0a2c821dd04bcdb9b61 Content-Type: text/plain; charset=ISO-8859-1 That's actually not true. If the meeting were to end up being in Stockholm and the best date was May 29th, then the folks in the U.S. would need to travel to Stockholm on the U.S. holiday. And, there are people (on this list) who attend other SDOs (i.e., that one in Geneva) that do regularly miss U.S. Thanksgiving (and birthday and wedding anniversaries) to attend meetings. At this point, however, in looking at the polls, that's not an optimal date anyways (nor is the 24th) so I think there is no need to worry. Mary. On Wed, Apr 4, 2012 at 1:26 AM, Roni Even wrote: > Mary,**** > > This is not equivalent to a three days weekend, this is a Holiday when the > whole family meets like your thanksgiving and I do not believe that you > will plan an interim meeting that will prevent U.S. guys from being with > their family on such a day.**** > > Thanks**** > > Roni **** > > ** ** > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Wednesday, April 04, 2012 1:38 AM > *To:* Roni Even > *Cc:* CLUE > *Subject:* Re: [clue] Poll for "CLUE WG Interim meeting"**** > > ** ** > > Then put those dates as not available for you. Those aren't optimal dates > for many of us in the U.S. either as it's very common to travel on that 3 > day weekend, so getting home late on Friday night isn't ideal. **** > > ** ** > > Mary. **** > > On Tue, Apr 3, 2012 at 4:58 PM, Roni Even wrote:* > *** > > Hi,**** > > May 26th is a Jewish Holiday and it is not possible for me to get back > from the US if the meeting is on the 24th**** > > Thanks**** > > Roni Even**** > > **** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* Tuesday, April 03, 2012 8:56 PM > *To:* CLUE > *Subject:* [clue] Poll for "CLUE WG Interim meeting"**** > > **** > > As discussed during the 2nd CLUE WG session, we are planning an interim > meeting in the late May/early June timeframe. We would like to coordinate > this with an RTCWEB interim meeting which is also in the planning stages:* > *** > > http://doodle.com/nm3pp69znr3286cy**** > > **** > > Thus, the date options are designed around meeting the same week as > RTCWEB. Please indicate your availability in the following doodle poll no > later than Friday, April 13th.**** > > http://www.doodle.com/zd4mhfsb63wkm7ww**** > > **** > > Note, that we will determine the location based upon whether we meet the > same week as RTCWEB. If we don't then we can separately decide what is the > best location. **** > > **** > > Thanks,**** > > Mary.**** > > WG co-chair**** > > > > > > **** > > **** > > ** ** > --20cf3071d0a2c821dd04bcdb9b61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's actually not true. =A0If the meeting were to end up being in Sto= ckholm and the best date was May 29th, then the folks in the U.S. would nee= d to travel to Stockholm on the U.S. holiday. =A0And, there are people (on = this list) who attend other SDOs (i.e., that one in Geneva) that do regular= ly miss U.S. Thanksgiving (and birthday and wedding anniversaries) to atten= d meetings. =A0

=A0At this point, however, in looking at the polls, that'= ;s not an optimal date anyways (nor is the 24th) so I think there is no nee= d to worry.=A0

Mary.=A0

On Wed, Apr 4, 2012 at 1:26 AM, Roni Even <ron.even.tlv@gmail.com> wrote:=

Mary,

This is not equivalent to a three days weekend, = this is a Holiday when the whole family meets like your thanksgiving =A0and= I do not believe that you will plan an interim meeting that will prevent U= .S. guys from being with their family on such a day.

Thanks

Roni =

=A0<= /p>

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Wednesday, April 04, 2012 1:38 AM
To: Roni Even
<= b>Cc: CLUE
Subject: Re: [clue] Poll for "CLUE WG Interim= meeting"

=A0

Then put= those dates as not available for you. =A0Those aren't optimal dates fo= r many of us in the U.S. either as it's very common to travel on that 3= day weekend, so getting home late on Friday night isn't ideal.=A0

=A0

Mary.=A0

On Tue, Apr 3, 2012 at 4:58 PM, Roni Even <ron.even.tlv@gmail.= com> wrote:

Hi,

May 26t= h is a Jewish Holiday and it is not possible for me to get back from = the US if the meeting is on the 24th

Thanks

Roni Even=

=A0<= /p>

From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Tuesday, April 03, 2012 8:56 PM
To: CLUE
Subje= ct: [clue] Poll for "CLUE WG Interim meeting"

=A0

As discussed during the 2nd CLUE WG session, we are = planning an interim meeting in the late May/early June timeframe. =A0We wou= ld like to coordinate this with an RTCWEB interim meeting which is also in = the planning stages:

=A0

=

Thus, the date options are designed around meeting the same week as RTCWEB.= =A0Please indicate your availability in the following doodle poll no later= than Friday, April 13th.

=A0

Note,= that we will determine the location based upon whether we meet the same we= ek as RTCWEB. =A0If we don't then we can separately decide what is the = best location. =A0

=A0

Thanks,

M= ary.

WG co-chair





=A0

=A0


--20cf3071d0a2c821dd04bcdb9b61-- From allyn@cisco.com Wed Apr 4 09:22:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C0E21F8767 for ; Wed, 4 Apr 2012 09:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4mYV+GGhE+0 for ; Wed, 4 Apr 2012 09:22:24 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id EB44421F8751 for ; Wed, 4 Apr 2012 09:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=12042; q=dns/txt; s=iport; t=1333556544; x=1334766144; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=uloG3B3SDR1yNfU/lnA89HMTY2ZN/cl9QEjGTgnz49M=; b=ZvgxFdGqHcKU1O3yLK6buczTjzG9KQQuCJnZEAxygupL+vGof/dkhVev E+cPKrt2lCmI2umq9kOdWCYYmmjWCLl72BDJiKfKJNJQg/rCwd00D5fui yliJ/Uj09u0hC35JnOenwCoumpJ5I3GHvMLYjGD16Z02kzEcsyVHDSZoP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFJ0fE+rRDoI/2dsb2JhbABFgka1W4EHggkBAQEEEgEJEQNEBRACAQgRBAEBCwYXAQYBICUJCAEBBBMIGodmAQubPZ5hihiFWWMEiCUzjhyKIoMUgWmDBw X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208,217";a="36468697" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 04 Apr 2012 16:22:23 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q34GMNr8003804; Wed, 4 Apr 2012 16:22:23 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 09:22:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD127F.1D8B1965" Date: Wed, 4 Apr 2012 09:22:20 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC072C82E7@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Poll for "CLUE WG Interim meeting" Thread-Index: Ac0ScmPVbHQ5Hf7sSeWcMSkfloF8GgADJFHw References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC072C8204@xmb-sjc-221.amer.cisco.com> From: "Allyn Romanow (allyn)" To: "Mary Barnes" X-OriginalArrivalTime: 04 Apr 2012 16:22:23.0238 (UTC) FILETIME=[1DB85A60:01CD127F] Cc: CLUE Subject: Re: [clue] Poll for "CLUE WG Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:22:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD127F.1D8B1965 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Okay, if it didn't work out well last time, then it's a good idea not = to try 2 days again. thanks =20 From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Sent: Wednesday, April 04, 2012 7:51 AM To: Allyn Romanow (allyn) Cc: CLUE Subject: Re: [clue] Poll for "CLUE WG Interim meeting" =20 Last time, everyone was totally brain fried by around 1pm even though we = had planned for the meeting to go til 5pm, which is about how late I = would anticipate to run the meeting - i.e., starting at 8:30 am and go = straight through to 1pm with a couple breaks (or we'll start at noon if = it's the day after memorial day). So, many of us ended up staying an = extra nite as we couldn't get the late flights. With 4 of the date = options having us end on Friday, I would prefer that we stick with the = 1.5+. However, if we get one of the mid-week dates, perhaps we can = consider two full days.=20 =20 Mary.=20 On Wed, Apr 4, 2012 at 2:06 AM, Allyn Romanow (allyn) = wrote: Hi Mary, I was wondering why the meeting is scheduled for day and =BD instead of = 2 days? It seemed to me more productive at the last meeting which was = scheduled for 2 days, even though some people left a bit early to catch = flights. When it's scheduled for 1.5 days, people will leave early, = making it more of a one day meeting. If most of us are traveling, I feel = like 1.5 days is a bit short if we have work that will fill the time for = 2 days. =20 Thanks, Allyn From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes Sent: Tuesday, April 03, 2012 10:56 AM To: CLUE Subject: [clue] Poll for "CLUE WG Interim meeting" =20 As discussed during the 2nd CLUE WG session, we are planning an interim = meeting in the late May/early June timeframe. We would like to = coordinate this with an RTCWEB interim meeting which is also in the = planning stages: http://doodle.com/nm3pp69znr3286cy =20 Thus, the date options are designed around meeting the same week as = RTCWEB. Please indicate your availability in the following doodle poll = no later than Friday, April 13th. http://www.doodle.com/zd4mhfsb63wkm7ww =20 Note, that we will determine the location based upon whether we meet the = same week as RTCWEB. If we don't then we can separately decide what is = the best location. =20 =20 Thanks, Mary. WG co-chair =20 =20 ------_=_NextPart_001_01CD127F.1D8B1965 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Okay, if it didn’t work out well last time, then = =A0it’s a good idea not to try 2 days again.

thanks

 

From:= Mary = Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Wednesday, April 04, 2012 7:51 AM
To: Allyn Romanow (allyn)
Cc: CLUE
Subject: Re: [clue] Poll for "CLUE WG Interim = meeting"

 

Last time, everyone was totally brain fried by = around 1pm even though we had planned for the meeting to go til 5pm, which is about = how late I would anticipate to run the meeting - i.e., starting at 8:30 am = and go straight through to 1pm with a couple breaks (or we'll start at noon if = it's the day after memorial day).   So, many of us ended up staying an = extra nite as we couldn't get the late flights.  With 4 of the date = options having us end on Friday, I would prefer that we stick with the 1.5+.  However, if we get one of the mid-week dates, perhaps we can = consider two full days. 

 

Mary. 

On Wed, Apr 4, 2012 at 2:06 AM, Allyn Romanow = (allyn) <allyn@cisco.com> = wrote:

Hi Mary,

I was wondering why the meeting is scheduled for day and =BD instead of 2 = days? It seemed to me more productive at the last meeting which was scheduled for = 2 days, even though some people left a bit early to catch flights. When it’s scheduled for 1.5 days, people will leave early, making it = more of a one day meeting. If most of us are traveling, I feel like 1.5 days is a = bit short if we have work that will fill the time for 2 = days.

 

Thanks,

Allyn

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Tuesday, April 03, 2012 10:56 AM


To: CLUE
Subject: [clue] Poll for "CLUE WG Interim = meeting"

 <= /o:p>

As discussed during the 2nd CLUE WG session, we are planning an interim = meeting in the late May/early June timeframe.  We would like to coordinate = this with an RTCWEB interim meeting which is also in the planning = stages:

 <= /o:p>

Thus, the date options are designed around meeting the same week as RTCWEB.  Please indicate your availability in the following doodle poll no = later than Friday, April 13th.

 <= /o:p>

Note, that we will determine the location based upon whether we meet the same = week as RTCWEB.  If we don't then we can separately decide what is the best location.  

 <= /o:p>

Thanks,=

Mary.

WG co-chair





 <= /o:p>

 

------_=_NextPart_001_01CD127F.1D8B1965-- From ron.even.tlv@gmail.com Wed Apr 4 12:55:21 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF44C11E80FA for ; Wed, 4 Apr 2012 12:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuDy6NJnKs1K for ; Wed, 4 Apr 2012 12:55:20 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 27A7611E80D2 for ; Wed, 4 Apr 2012 12:55:19 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so524488wib.13 for ; Wed, 04 Apr 2012 12:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=mMtYAvdYmLlYn6MT3gUK4EkKtIiNEbsT76aR9rxjhKI=; b=JKT/N4erOwjXR8FKZtlij/DHN4l9ze2XbrJTr3X8GOFDr/Br+VYB2L5zTVUsa+ZV7R CPNSdMX9TTeJmeyYHsLZNadL90QbV0I1dluWxmrij5ht1IPkGc2ECQDzI5NOYPrPTYST QX1ZDT7XpOv80m3x6dQss5SVfB/E8U2HNI1yjtYYOoaUEDvu80i+6YvhMeLPyTNjKKF+ EPmxlShW3ULZK8QKYR3cRaBMUzS27wcy2MlMMglDDFZezodxtd36CwOvbdCB1+ekcKIa jIsqT1wAlb6chyxnSIFfiKe7qoJQu75oH3vKRrbl5s5xItAsNzhLaSSXyoPCyLU8vjJM UUKA== Received: by 10.216.135.102 with SMTP id t80mr2164177wei.59.1333569319353; Wed, 04 Apr 2012 12:55:19 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id e6sm7339929wix.8.2012.04.04.12.55.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Apr 2012 12:55:18 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" References: <4f7b72c8.5102b40a.12b3.ffffbab7@mx.google.com> <4f7be9d0.e967b40a.1c6b.67db@mx.google.com> In-Reply-To: Date: Wed, 4 Apr 2012 22:53:54 +0300 Message-ID: <4f7ca726.e64eb40a.1f41.ffffb138@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01CD12B5.D1478C00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0ScurkOx1h75OISEyu89vNz3EiUwAKUhIQ Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Poll for "CLUE WG Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 19:55:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_008E_01CD12B5.D1478C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mary, If you are comparing then you should know by now that Friday is my weekend and I never say anything about having to work on the weekend, some of the options include Friday, so I hope the dates will work so I will be able to attend. Roni From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Wednesday, April 04, 2012 5:55 PM To: Roni Even Cc: CLUE Subject: Re: [clue] Poll for "CLUE WG Interim meeting" That's actually not true. If the meeting were to end up being in Stockholm and the best date was May 29th, then the folks in the U.S. would need to travel to Stockholm on the U.S. holiday. And, there are people (on this list) who attend other SDOs (i.e., that one in Geneva) that do regularly miss U.S. Thanksgiving (and birthday and wedding anniversaries) to attend meetings. At this point, however, in looking at the polls, that's not an optimal date anyways (nor is the 24th) so I think there is no need to worry. Mary. On Wed, Apr 4, 2012 at 1:26 AM, Roni Even wrote: Mary, This is not equivalent to a three days weekend, this is a Holiday when the whole family meets like your thanksgiving and I do not believe that you will plan an interim meeting that will prevent U.S. guys from being with their family on such a day. Thanks Roni From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Wednesday, April 04, 2012 1:38 AM To: Roni Even Cc: CLUE Subject: Re: [clue] Poll for "CLUE WG Interim meeting" Then put those dates as not available for you. Those aren't optimal dates for many of us in the U.S. either as it's very common to travel on that 3 day weekend, so getting home late on Friday night isn't ideal. Mary. On Tue, Apr 3, 2012 at 4:58 PM, Roni Even wrote: Hi, May 26th is a Jewish Holiday and it is not possible for me to get back from the US if the meeting is on the 24th Thanks Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Tuesday, April 03, 2012 8:56 PM To: CLUE Subject: [clue] Poll for "CLUE WG Interim meeting" As discussed during the 2nd CLUE WG session, we are planning an interim meeting in the late May/early June timeframe. We would like to coordinate this with an RTCWEB interim meeting which is also in the planning stages: http://doodle.com/nm3pp69znr3286cy Thus, the date options are designed around meeting the same week as RTCWEB. Please indicate your availability in the following doodle poll no later than Friday, April 13th. http://www.doodle.com/zd4mhfsb63wkm7ww Note, that we will determine the location based upon whether we meet the same week as RTCWEB. If we don't then we can separately decide what is the best location. Thanks, Mary. WG co-chair ------=_NextPart_000_008E_01CD12B5.D1478C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mary,

If you are comparing then you should know by now that Friday is my = weekend and I never say anything about having to work on the weekend, = some of the options include Friday, so I hope the dates will work so I = will be able to attend.

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: = Wednesday, April 04, 2012 5:55 PM
To: Roni Even
Cc: = CLUE
Subject: Re: [clue] Poll for "CLUE WG Interim = meeting"

 

That's = actually not true.  If the meeting were to end up being in = Stockholm and the best date was May 29th, then the folks in the U.S. = would need to travel to Stockholm on the U.S. holiday.  And, there = are people (on this list) who attend other SDOs (i.e., that one in = Geneva) that do regularly miss U.S. Thanksgiving (and birthday and = wedding anniversaries) to attend meetings.  

 

 At this point, however, in looking at the polls, = that's not an optimal date anyways (nor is the 24th) so I think there is = no need to worry. 

 

Mary. 

On Wed, Apr 4, 2012 at 1:26 AM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Mary,

This is not equivalent to a three days weekend, this is a Holiday = when the whole family meets like your thanksgiving  and I do not = believe that you will plan an interim meeting that will prevent U.S. = guys from being with their family on such a day.

Thanks

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: = Wednesday, April 04, 2012 1:38 AM
To: Roni Even
Cc: = CLUE
Subject: Re: [clue] Poll for "CLUE WG Interim = meeting"

 <= /o:p>

Then put = those dates as not available for you.  Those aren't optimal dates = for many of us in the U.S. either as it's very common to travel on that = 3 day weekend, so getting home late on Friday night isn't = ideal. 

 <= /o:p>

Mary. 

On Tue, Apr = 3, 2012 at 4:58 PM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi,

May 26th is a Jewish Holiday and it is not possible for me = to get back from the US if the meeting is on the = 24th

Thanks

Roni Even

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: Tuesday, April 03, 2012 8:56 PM
To: = CLUE
Subject: [clue] Poll for "CLUE WG Interim = meeting"

 <= /o:p>

As = discussed during the 2nd CLUE WG session, we are planning an interim = meeting in the late May/early June timeframe.  We would like to = coordinate this with an RTCWEB interim meeting which is also in the = planning stages:

http://doodle.com/nm3pp69znr3286cy

 <= /o:p>

Thus, the = date options are designed around meeting the same week as RTCWEB. =  Please indicate your availability in the following doodle poll no = later than Friday, April 13th.

 <= /o:p>

Note, that = we will determine the location based upon whether we meet the same week = as RTCWEB.  If we don't then we can separately decide what is the = best location.  

 <= /o:p>

Thanks,=

Mary.

WG = co-chair




<= /o:p>

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_008E_01CD12B5.D1478C00-- From mary.ietf.barnes@gmail.com Wed Apr 4 13:04:42 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1104011E80D7 for ; Wed, 4 Apr 2012 13:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOR5l+OACXG4 for ; Wed, 4 Apr 2012 13:04:41 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB6B111E80D2 for ; Wed, 4 Apr 2012 13:04:40 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so623945vbb.31 for ; Wed, 04 Apr 2012 13:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VzPYD/m/ZiIKaPagS2Phy6GQQw50koZduDzi6zRqQJg=; b=gOMtmpek726o+KPjGh6DwmPWTYgk/gkXRPT5DjPDlTD/k5mqfeh+xHswk3h6CTq6Qm fu0/fUJWHsyQWEY49MIARzs6CKdtM+StGFIU6qsA0l54QkJFMNgcWDBsgFoLO/IV1WLm bkLLujUHH1tdNJxxjC6lALmtsEYLqb9BErNmtjo67HjVreHmQG21O3RvO6ZsIZkkR5Au duLyss9xOFJq1iMumPbQaAS9vLJYBzhmu50LaDtydHatb2fF1V2oyHTszUUfLPrtJO/O Z7S3IufzLxjntUKIxkcJ9mJiWVmhhG2sGZidykMwtUlsU0KNZgr1VGk4fpgsoRf5EO1J LKGg== MIME-Version: 1.0 Received: by 10.52.240.171 with SMTP id wb11mr7261424vdc.106.1333569880211; Wed, 04 Apr 2012 13:04:40 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Wed, 4 Apr 2012 13:04:40 -0700 (PDT) In-Reply-To: <4f7ca726.e64eb40a.1f41.ffffb138@mx.google.com> References: <4f7b72c8.5102b40a.12b3.ffffbab7@mx.google.com> <4f7be9d0.e967b40a.1c6b.67db@mx.google.com> <4f7ca726.e64eb40a.1f41.ffffb138@mx.google.com> Date: Wed, 4 Apr 2012 15:04:40 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=20cf307ca3dcfe42b404bcdfee92 Cc: CLUE Subject: Re: [clue] Poll for "CLUE WG Interim meeting" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 20:04:42 -0000 --20cf307ca3dcfe42b404bcdfee92 Content-Type: text/plain; charset=ISO-8859-1 Yes, I understand and we can try to avoid Friday, but in general IETF does have meetings on Friday. Mary. On Wed, Apr 4, 2012 at 2:53 PM, Roni Even wrote: > Mary, **** > > If you are comparing then you should know by now that Friday is my weekend > and I never say anything about having to work on the weekend, some of the > options include Friday, so I hope the dates will work so I will be able to > attend.**** > > Roni**** > > ** ** > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Wednesday, April 04, 2012 5:55 PM > > *To:* Roni Even > *Cc:* CLUE > *Subject:* Re: [clue] Poll for "CLUE WG Interim meeting"**** > > ** ** > > That's actually not true. If the meeting were to end up being in > Stockholm and the best date was May 29th, then the folks in the U.S. would > need to travel to Stockholm on the U.S. holiday. And, there are people (on > this list) who attend other SDOs (i.e., that one in Geneva) that do > regularly miss U.S. Thanksgiving (and birthday and wedding anniversaries) > to attend meetings. **** > > ** ** > > At this point, however, in looking at the polls, that's not an optimal > date anyways (nor is the 24th) so I think there is no need to worry. **** > > ** ** > > Mary. **** > > On Wed, Apr 4, 2012 at 1:26 AM, Roni Even wrote:* > *** > > Mary,**** > > This is not equivalent to a three days weekend, this is a Holiday when the > whole family meets like your thanksgiving and I do not believe that you > will plan an interim meeting that will prevent U.S. guys from being with > their family on such a day.**** > > Thanks**** > > Roni **** > > **** > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Wednesday, April 04, 2012 1:38 AM > *To:* Roni Even > *Cc:* CLUE > *Subject:* Re: [clue] Poll for "CLUE WG Interim meeting"**** > > **** > > Then put those dates as not available for you. Those aren't optimal dates > for many of us in the U.S. either as it's very common to travel on that 3 > day weekend, so getting home late on Friday night isn't ideal. **** > > **** > > Mary. **** > > On Tue, Apr 3, 2012 at 4:58 PM, Roni Even wrote:* > *** > > Hi,**** > > May 26th is a Jewish Holiday and it is not possible for me to get back > from the US if the meeting is on the 24th**** > > Thanks**** > > Roni Even**** > > **** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* Tuesday, April 03, 2012 8:56 PM > *To:* CLUE > *Subject:* [clue] Poll for "CLUE WG Interim meeting"**** > > **** > > As discussed during the 2nd CLUE WG session, we are planning an interim > meeting in the late May/early June timeframe. We would like to coordinate > this with an RTCWEB interim meeting which is also in the planning stages:* > *** > > http://doodle.com/nm3pp69znr3286cy**** > > **** > > Thus, the date options are designed around meeting the same week as > RTCWEB. Please indicate your availability in the following doodle poll no > later than Friday, April 13th.**** > > http://www.doodle.com/zd4mhfsb63wkm7ww**** > > **** > > Note, that we will determine the location based upon whether we meet the > same week as RTCWEB. If we don't then we can separately decide what is the > best location. **** > > **** > > Thanks,**** > > Mary.**** > > WG co-chair**** > > > > > **** > > **** > > **** > > ** ** > --20cf307ca3dcfe42b404bcdfee92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I understand and we can try to avoid Friday, but in general IETF does = have meetings on Friday.=A0

Mary.=A0

On Wed, Apr 4, 2012 at 2:53 PM, Roni Even <ron.even.tlv@gmail.com&= gt; wrote:

Mary, =

If you are comparing then= you should know by now that Friday is my weekend and I never say anything = about having to work on the weekend, some of the options include Friday, so= I hope the dates will work so I will be able to attend.

Roni=

=A0

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Wednesday, April 04, 2012 5:55 PM


To: Roni Even
Cc: CLUE
Subject:<= /b> Re: [clue] Poll for "CLUE WG Interim meeting"

=A0

That's actually not = true. =A0If the meeting were to end up being in Stockholm and the best date= was May 29th, then the folks in the U.S. would need to travel to Stockholm= on the U.S. holiday. =A0And, there are people (on this list) who attend ot= her SDOs (i.e., that one in Geneva) that do regularly miss U.S. Thanksgivin= g (and birthday and wedding anniversaries) to attend meetings. =A0

=A0

=A0At this point, however, in looking at the polls, that's not = an optimal date anyways (nor is the 24th) so I think there is no need to wo= rry.=A0

=A0

Mary.=A0

On Wed, Apr 4, 2012 at 1:26 AM, Roni Even <ron.even.tlv@gmail.= com> wrote:

Mary,=

This is no= t equivalent to a three days weekend, this is a Holiday when the whole fami= ly meets like your thanksgiving =A0and I do not believe that you will plan = an interim meeting that will prevent U.S. guys from being with their family= on such a day.

Thanks

Roni =

=A0<= /p>

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Wednesday, April 04, 2012 1:38 AM
To: Roni Even
<= b>Cc: CLUE
Subject: Re: [clue] Poll for "CLUE WG Interim= meeting"

=A0

Then put those dates as not ava= ilable for you. =A0Those aren't optimal dates for many of us in the U.S= . either as it's very common to travel on that 3 day weekend, so gettin= g home late on Friday night isn't ideal.=A0

=A0

Mary.=A0

On Tue, Apr 3, 2012 at 4:58 PM, Roni Even <ron.even.tlv@gmail.= com> wrote:

Hi,

May 26t= h is a Jewish Holiday and it is not possible for me to get back from = the US if the meeting is on the 24th

Thanks

Roni Even=

=A0<= /p>

From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Tuesday, April 03, 2012 8:56 PM
To: CLUE
Subje= ct: [clue] Poll for "CLUE WG Interim meeting"

=A0

As discussed during the 2nd CLUE WG session, we are = planning an interim meeting in the late May/early June timeframe. =A0We wou= ld like to coordinate this with an RTCWEB interim meeting which is also in = the planning stages:

=A0

=

Thus, the date options are designed around meeting the same week as RTCWEB.= =A0Please indicate your availability in the following doodle poll no later= than Friday, April 13th.

=A0

Note,= that we will determine the location based upon whether we meet the same we= ek as RTCWEB. =A0If we don't then we can separately decide what is the = best location. =A0

=A0

Thanks,

M= ary.

WG co-chair




=A0=

=A0

=A0

<= /blockquote>

--20cf307ca3dcfe42b404bcdfee92-- From apeppere@gmail.com Fri Apr 6 01:16:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C977721F85D7 for ; Fri, 6 Apr 2012 01:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3jcmpxeaORP for ; Fri, 6 Apr 2012 01:16:34 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0DB21F8421 for ; Fri, 6 Apr 2012 01:16:34 -0700 (PDT) Received: by yenm5 with SMTP id m5so1345453yen.31 for ; Fri, 06 Apr 2012 01:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=L0Q71ZgHFDeJFCBNnlcypigZUjgkv/PdA8i4aFq332Q=; b=Gvc+ARLbna8INFZWW4Cpa4AAIU6S5LOtvmie4mMoIQOLWBxwZJjL1EJa/5eB0KNLM1 YUAlwQI4ldmf6ZMl1zZUFow+1mv5Lqjiiuc1I/LX5FcdqGm9Dpfk8QTVii6SHzN8yZsI eCyHDAzubrGlO9yCgQUmxo/ktoh81T9+H9IUjPRdq2/JAkHVf0JsRBUE32GkqXznHmq/ WNZQLpkTag87nEXAq0Mj8h6cNlTi66RDTK01zoKhmN5tUoqxxBSLL5hkKCpRUU/BjO5Q 4Jafyl3ZRBhacBfgVJ0xwD5/J4b8qW816++tHK0ngWprjavVhRXhz9rcw3rZFgyTJpEY c0Xg== MIME-Version: 1.0 Received: by 10.236.73.169 with SMTP id v29mr6211390yhd.12.1333700194261; Fri, 06 Apr 2012 01:16:34 -0700 (PDT) Received: by 10.220.84.205 with HTTP; Fri, 6 Apr 2012 01:16:34 -0700 (PDT) In-Reply-To: References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> <4F723272.4040409@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7B@CRPMBOXPRD01.polycom.com> <4F738516.2000209@alum.mit.edu> Date: Fri, 6 Apr 2012 09:16:34 +0100 Message-ID: From: Andy Pepperell To: clue@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 08:16:35 -0000 It's clear from the discussions that there's some contention over the proposed use of the "composed" attribute. While I maintain that there is use in a consumer knowing that a video stream is not suitable for use in a new composed, multiple pane arrangement, it's also clear that a capture could be composed / mixed without this being true (the simple case of 2 adjacent seats covered by a single camera [capture]). Perhaps there's some merit in separating these concepts? Specifically, we could have a "composed" attribute which the provider would use to mean "this capture can be broken down into constituent elements" and a separate "artificial" attribute to signify "this is something that shouldn't be recombined with other captures if there's an alternative". This would leave the composed / mixed attribute open for all provider devices to use (i.e. not just those performing MCU-style layout compositions), and open to being extended to cover the dynamic update case (a provider indicating changes in who's being shown where as that changes, which could be said to be equally applicable to, say, the 4 panes of a 2 x 2 MCU layout as to 2 people sat next to each other at a desk covered by a single camera [capture]). Regards, Andy On Fri, Mar 30, 2012 at 2:52 PM, Charles Eckel (eckelcu) wrote: > Reiterating a comment I made a the mic, I would like to see the addition > of semantics that describe the composed/mixed media capture in terms of > other media captures, when applicable. I think this would be very useful > information for a consumer. > > Cheers, > Charles > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of >> Paul Kyzivat >> Sent: Wednesday, March 28, 2012 11:40 PM >> To: Duckworth, Mark >> Cc: clue@ietf.org >> Subject: Re: [clue] Use of the media capture "composed" attribute >> >> I think this further verifies that we need a better explanation of the >> intended purpose(s) of these (mixed/composed) attributes so that we > can >> assess whether we have an actionable definition sufficient to the > need. >> >> =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 Paul >> >> On 3/28/12 10:52 AM, Duckworth, Mark wrote: >> > Paul asked: >> >> If mixed and composed aren't intended to drive decisions about >> further >> >> mixing and composing, then what *are* they for? >> > >> > I was thinking one other case where the composed attribute would be >> used is when a consumer (an endpoint in this case) is choosing which >> media captures to receive from a provider. =A0Suppose the provider >> advertises capture scene entries that are the same except one of them >> has video captures that use composed=3Dtrue, and the other uses >> composed=3Dfalse. =A0I think the consumer can reasonably assume the one >> with composed=3Dtrue includes more information somehow, possibly with >> "Hollywood squares" or picture-in-picture video layout. =A0The consumer >> can use this limited information to make a choice. =A0This choice has >> nothing to do with whether or not the receiving endpoint is going to >> re-compose the images. >> > >> > Mark >> > >> >> -----Original Message----- >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf >> Of >> >> Paul Kyzivat >> >> Sent: Tuesday, March 27, 2012 11:35 PM >> >> To: clue@ietf.org >> >> Subject: Re: [clue] Use of the media capture "composed" attribute >> >> >> >> [I don't know if this is as chair or individual. Maybe both.] >> >> >> >> The discussion of the composed and mixed attributes today exposed a >> lot of >> >> vagueness about what they mean. I think this needs to be firmed up >> >> considerably. >> >> >> >> Here are some thoughts of my own just to keep the discussion going: >> >> >> >> Regarding mixed (audio): >> >> >> >> The fact that an audio capture has mixed content doesn't preclude >> mixing it >> >> again. But there are properties of it that might make such mixing >> >> unsatisfactory. For instance, if AC3 is a mix of (AC1, AC2), then > it >> is ok to mix >> >> AC3 and independent capture AC4. But it would be unwise to mix it >> with AC2 >> >> again. And it would also be unwise to mix it with AC5 that is > itself >> a mix of >> >> (AC1, AC4). >> >> >> >> It *might* also be the case that a mix is unwise if it includes >> >> (transitively) too many original inputs. >> >> >> >> Fundamentally it seems like the decision of whether a mix makes >> sense >> >> requires some complex decision making based on way more data than >> >> whether the immediate inputs are themselves mixed or not. >> >> >> >> Regarding composed (video): >> >> >> >> This seems potentially more complex. So far the only use I have >> heard for >> >> this attribute is to drive a decision about whether it makes sense >> to compose >> >> this capture with others. But I expect that isn't always true >> either. You could >> >> have one uncomposed capture that shows two people >> >> (heads) side by side. You could have another *composed* capture > that >> also >> >> shows two people in independently side by side each inside a frame, >> that >> >> were assembled from other captures. (Would anyone argue that this >> isn't >> >> composed?) But I can't see why it would be any more or less >> desirable to >> >> compose one of these captures than another. >> >> >> >> Again it seems like you need more information about what has been >> >> composed, and at what scale (and maybe position) before you can > make >> a >> >> decision about whether it makes sense to compose it. And then that >> may >> >> also depend on *how* you want to compose it. >> >> >> >> If mixed and composed aren't intended to drive decisions about >> further >> >> mixing and composing, then what *are* they for? >> >> >> >> =A0 =A0Thanks, >> >> =A0 =A0Paul >> >> _______________________________________________ >> >> clue mailing list >> >> clue@ietf.org >> >> https://www.ietf.org/mailman/listinfo/clue >> > >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From apeppere@gmail.com Fri Apr 6 01:24:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794921F8618 for ; Fri, 6 Apr 2012 01:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9bEWK0tNt0B for ; Fri, 6 Apr 2012 01:24:03 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDAA621F85EE for ; Fri, 6 Apr 2012 01:24:03 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1357036ghb.31 for ; Fri, 06 Apr 2012 01:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=alLTY+OwJeN1M6OomEmF9zT3DR9x7o4WJZNgNDBMjrE=; b=X7PpXNYqRpeZLsY1gLsPzTOrp51+8KCMMbszQc5eAe0OLryEL3W21YQzMlm41Nn3nH EOExxJ7mXbHI26gd5TIaz3sPU0vDrp3gPwL60N/34bxL/RhuU6UmFbHjpl52ju+2XKgF VeJEDo8ZKcHwVVpwUQffat4/9nyFHn/bs/P+Lr+dTW8wguXI3ZFIQrCrDRf5/VHHyu2g m0nbriNbfOom5H5ajKyYu94xfQiJcggVfUgml9TRBDzlPiLbM56Ge7CvTW10INwJLROp nKLKGJ/cUBkH8XMjEWFUW/AVhsIbslzkX6yUxuq5AjgYhqRGTKhJGF5eImoF+FwR4uEk 5tqQ== MIME-Version: 1.0 Received: by 10.236.184.102 with SMTP id r66mr6106674yhm.46.1333700643330; Fri, 06 Apr 2012 01:24:03 -0700 (PDT) Received: by 10.220.84.205 with HTTP; Fri, 6 Apr 2012 01:24:03 -0700 (PDT) In-Reply-To: References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> <4F723272.4040409@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7B@CRPMBOXPRD01.polycom.com> <4F738516.2000209@alum.mit.edu> Date: Fri, 6 Apr 2012 09:24:03 +0100 Message-ID: From: Andy Pepperell To: "Charles Eckel (eckelcu)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: clue@ietf.org Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 08:24:05 -0000 Hi Charles, re: this specific point, it could be said that to an extent the structure / semantics of the capture scene entries do give you this information, in that each such entry in a capture scene captures "equivalent" data, so, if, say, you have a capture scene entry consisting of just VC1 and there's another entry in the same capture scene consisting of VC2, VC3 and VC4 then, whether or not VC1 is tagged as composed/mixed, it to an extent "covers" VC2, VC3 and VC4 (and the area of capture co-ordinates can be used to determine this in more detail). One issue with separate semantics for describing captures in terms of other captures, to my mind, is that it wouldn't give as fine-grained information as one might want. In the case of a single VCn being supplied from a single-camera endpoint, presumably a fairly common case, we might want to have a provider -> consumer mechanism for describing who's on the left and right of the image without the need to invent new sub-captures for this purpose. Andy On Fri, Mar 30, 2012 at 2:52 PM, Charles Eckel (eckelcu) wrote: > Reiterating a comment I made a the mic, I would like to see the addition > of semantics that describe the composed/mixed media capture in terms of > other media captures, when applicable. I think this would be very useful > information for a consumer. > > Cheers, > Charles > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of >> Paul Kyzivat >> Sent: Wednesday, March 28, 2012 11:40 PM >> To: Duckworth, Mark >> Cc: clue@ietf.org >> Subject: Re: [clue] Use of the media capture "composed" attribute >> >> I think this further verifies that we need a better explanation of the >> intended purpose(s) of these (mixed/composed) attributes so that we > can >> assess whether we have an actionable definition sufficient to the > need. >> >> =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 Paul >> >> On 3/28/12 10:52 AM, Duckworth, Mark wrote: >> > Paul asked: >> >> If mixed and composed aren't intended to drive decisions about >> further >> >> mixing and composing, then what *are* they for? >> > >> > I was thinking one other case where the composed attribute would be >> used is when a consumer (an endpoint in this case) is choosing which >> media captures to receive from a provider. =A0Suppose the provider >> advertises capture scene entries that are the same except one of them >> has video captures that use composed=3Dtrue, and the other uses >> composed=3Dfalse. =A0I think the consumer can reasonably assume the one >> with composed=3Dtrue includes more information somehow, possibly with >> "Hollywood squares" or picture-in-picture video layout. =A0The consumer >> can use this limited information to make a choice. =A0This choice has >> nothing to do with whether or not the receiving endpoint is going to >> re-compose the images. >> > >> > Mark >> > >> >> -----Original Message----- >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf >> Of >> >> Paul Kyzivat >> >> Sent: Tuesday, March 27, 2012 11:35 PM >> >> To: clue@ietf.org >> >> Subject: Re: [clue] Use of the media capture "composed" attribute >> >> >> >> [I don't know if this is as chair or individual. Maybe both.] >> >> >> >> The discussion of the composed and mixed attributes today exposed a >> lot of >> >> vagueness about what they mean. I think this needs to be firmed up >> >> considerably. >> >> >> >> Here are some thoughts of my own just to keep the discussion going: >> >> >> >> Regarding mixed (audio): >> >> >> >> The fact that an audio capture has mixed content doesn't preclude >> mixing it >> >> again. But there are properties of it that might make such mixing >> >> unsatisfactory. For instance, if AC3 is a mix of (AC1, AC2), then > it >> is ok to mix >> >> AC3 and independent capture AC4. But it would be unwise to mix it >> with AC2 >> >> again. And it would also be unwise to mix it with AC5 that is > itself >> a mix of >> >> (AC1, AC4). >> >> >> >> It *might* also be the case that a mix is unwise if it includes >> >> (transitively) too many original inputs. >> >> >> >> Fundamentally it seems like the decision of whether a mix makes >> sense >> >> requires some complex decision making based on way more data than >> >> whether the immediate inputs are themselves mixed or not. >> >> >> >> Regarding composed (video): >> >> >> >> This seems potentially more complex. So far the only use I have >> heard for >> >> this attribute is to drive a decision about whether it makes sense >> to compose >> >> this capture with others. But I expect that isn't always true >> either. You could >> >> have one uncomposed capture that shows two people >> >> (heads) side by side. You could have another *composed* capture > that >> also >> >> shows two people in independently side by side each inside a frame, >> that >> >> were assembled from other captures. (Would anyone argue that this >> isn't >> >> composed?) But I can't see why it would be any more or less >> desirable to >> >> compose one of these captures than another. >> >> >> >> Again it seems like you need more information about what has been >> >> composed, and at what scale (and maybe position) before you can > make >> a >> >> decision about whether it makes sense to compose it. And then that >> may >> >> also depend on *how* you want to compose it. >> >> >> >> If mixed and composed aren't intended to drive decisions about >> further >> >> mixing and composing, then what *are* they for? >> >> >> >> =A0 =A0Thanks, >> >> =A0 =A0Paul >> >> _______________________________________________ >> >> clue mailing list >> >> clue@ietf.org >> >> https://www.ietf.org/mailman/listinfo/clue >> > >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From marshall.eubanks@gmail.com Fri Apr 6 05:03:03 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7567521F859F for ; Fri, 6 Apr 2012 05:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.578 X-Spam-Level: X-Spam-Status: No, score=-103.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmSeWcDuHPhl for ; Fri, 6 Apr 2012 05:03:02 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9F421F859A for ; Fri, 6 Apr 2012 05:03:02 -0700 (PDT) Received: by lbok13 with SMTP id k13so688480lbo.31 for ; Fri, 06 Apr 2012 05:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GBe5/OL1wS3/4hDhj2Ho+Bo5FcJnL467I9aKhNcDBSU=; b=ymVs/bjvYn8bNhPK4/iD184HM1RIych74SOBY9s700pWAjnGNfnGWf7g8NJibbtK0j 1RS77iTdhalqTsen32u6qawIiIpcvaJPzSUvIlXCZSkubB9e16hpLFgMHIeyZWnSUkZ6 hQ4XpJYBe1qZ5asWpWnnYfO7QFhzBqdpmqf6Vmm+oFbWw6Dsx4+HUb1CEaBmR53Vb/tp fbjEAX2Erznugf6gwPNw9WN+uxi6QktcWMpm7vsAPzywZzIk35+s0z3srrEes0DcE73G awMiiPhpbKeLL8UGzVSI5gc7q6KRPB7GEKF32zqLxkSVttrEYgvNmRjRxXDlEqV2CI5a matQ== MIME-Version: 1.0 Received: by 10.152.110.193 with SMTP id ic1mr8448883lab.4.1333713781163; Fri, 06 Apr 2012 05:03:01 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Fri, 6 Apr 2012 05:03:01 -0700 (PDT) In-Reply-To: References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> Date: Fri, 6 Apr 2012 08:03:01 -0400 Message-ID: From: Marshall Eubanks To: Stephen Botzko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: clue@ietf.org Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:03:03 -0000 On Tue, Mar 27, 2012 at 10:14 AM, Stephen Botzko wrote: > > > On Tue, Mar 27, 2012 at 6:12 AM, John Leslie wrote: >> >> Stephen Botzko wrote: >> > On Wed, Mar 21, 2012 at 9:23 PM, John Leslie wrote: >> >> Roni Even wrote: >> >>> [Andy Pepperell wrote:] >> >>>> >> >>>> With more thought on this, we also came to the conclusion that the >> >>>> use >> >>>> for this attribute for video captures doesn't necessarily translate >> >>>> exactly equivalently to audio captures. In a network of cascaded MC= Us >> >>>> it *would* often be perfectly acceptable to use a pre-mixed audio >> >>>> stream from a peer MCU whereas it would be highly desirable to not >> >>>> use pre-composed, multi-pane, video from those media providers. >> >> =A0 (I agree that pre-mixed audio may sometimes be preferred to doing >> your own mixing, for the same room where pre-composed video would _not_ >> be preferred.) >> >> >>>> Largely because of the potential different use of the attribute by >> >>>> media stream consumers, our thinking is that we *shouldn't* define >> >>>> the "composed" attribute to apply to both video and audio captures, >> >>>> and instead use, if required, a separate "mixed" attribute for the >> >>>> audio case. >> >> >> >> I'm not sure it needs to be "separate", but I would hope we have a >> >> tag to show that two or more microphones in different positions were >> >> "mixed" into a single audio stream. >> >> >> >> I view this as a warning label -- and a single bit suffices unless >> >> we include details of the microphones being mixed (which I don't >> >> believe >> >> is the current plan). >> >> >> > [sb] =A0Are you suggesting that every system using a steered microphon= e >> > array >> > would be tagged as "mixed"? >> >> =A0 Actually, yes: in the case of a steered _array_ of microphones, the >> arrival-time information will be lost, just as in an audio mixer with >> multiple microphones. >> >> =A0 This is distinct from the case of a steered "shotgun" microphone whe= re >> the mike position is fixed (though its directional pattern changes), thu= s >> arrival-time information is preserved. >> > [sb] I believe steered microphone arrays are used commonly in sonar > acquisition, so I don't believe arrival time information has to be lost. > Usually the microphones in such an array are in fixed positions. > In a steered array there has to be an array phase reference location (where all of the signals are delayed to be in phase at). It doesn't have to be the same location for each steered beam, but I think it generally is in practice. (It also doesn't have to be the location of any physical microphone.) Note that if it is in the middle of the array, then in general some inputs would need to be retarded, some advanced, to be in sync, and so (for a real time system) the output will actually be what a virtual microphone at the array phase reference would have heard some time before (that time being at least the delay to the last receiver to receive that phase). So, if the phased array picks some convenient spot in the middle to be the phase reference, it will of necessity output the sound delayed by some amount (at least the phase delay between that spot and the last receiver). Of course, this phase shift delay has to be added to any processing delays and digitization delays, but these are probably similar to those for conventional microphones. Suppose the array is 1 meter in radius; then the array phase delay will be < or ~ 3 msec. That would be a tiny delay for two telepresence systems not located in the same building, so could probably be ignored. Even if the array spanned the entire telepresence space (say, 10 meters), the delay is only 30 msec. Only if the array was spanning, say, an entire IETF plenary would the delay become problematic. (Note, however, that arrays surrounding sources can give rise to more complexities.) Given all of this, I don't see any intrinsic reason why an array system can't be regarded as giving proper arrival time information. Regards Marshall >> >> > I don't see that as helpful, so I think we would need to define the >> > meaning of "mixed" here carefully. >> >> =A0 We probably do need a careful definition... >> >> =A0 To me, the essential point is that a mixer greatly obscures any >> ability to process for actual physical location of the microphone -- >> thus I'm probably going to fail if I try to aid the listeners in >> recovering the actual physical location of the speaker(s). >> >> =A0 Of course, regardless of our definition, such a "mixed" bit will end >> up being set wrong sometimes -- but I'd still like the warning label. >> >> =A0 In an actual room, listeners with binaural hearing determine the >> speaker's location quite unconsciously -- but they do use physical >> position as one input into speaker recognition (and where to focus >> their attention). When a remote speaker is presented through a >> monophonic speaker, they describe it as a "dissociated voice" and >> are subconsciously confused. >> >> =A0 Given "mixed" audio, I can still process it to a single apparent >> position, but I can't relate that position to any other sound source; >> nor can I usefully vary it as different speakers are included in that >> audio stream. >> >> -- >> John Leslie > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Fri Apr 6 05:53:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB1C21F8603 for ; Fri, 6 Apr 2012 05:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDqGL3qcBWdc for ; Fri, 6 Apr 2012 05:53:23 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id D60C121F85F4 for ; Fri, 6 Apr 2012 05:53:22 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta01.westchester.pa.mail.comcast.net with comcast id ucn81i00A0Fqzac51ctPNe; Fri, 06 Apr 2012 12:53:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta08.westchester.pa.mail.comcast.net with comcast id uctP1i00607duvL3UctPaC; Fri, 06 Apr 2012 12:53:23 +0000 Message-ID: <4F7EE741.9010002@alum.mit.edu> Date: Fri, 06 Apr 2012 08:53:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> <4F723272.4040409@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7B@CRPMBOXPRD01.polycom.com> <4F738516.2000209@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:53:24 -0000 On 4/6/12 4:16 AM, Andy Pepperell wrote: > It's clear from the discussions that there's some contention over the > proposed use of the "composed" attribute. While I maintain that there > is use in a consumer knowing that a video stream is not suitable for > use in a new composed, multiple pane arrangement, it's also clear that > a capture could be composed / mixed without this being true (the > simple case of 2 adjacent seats covered by a single camera [capture]). > > Perhaps there's some merit in separating these concepts? Specifically, > we could have a "composed" attribute which the provider would use to > mean "this capture can be broken down into constituent elements" and a > separate "artificial" attribute to signify "this is something that > shouldn't be recombined with other captures if there's an > alternative". I'm still confused by these. You are stating these definitions from the perspective of the recipient, but without much of an operational definition for the provider. And even from the point of view of the recipient this is rather unmotivated. (What does "this capture can be broken down into constituent elements" mean to the recipient? Without some added data about where the constituent elements are in the composed image, and what they represent, this is not helpful. And how does one decide whether "this is something that shouldn't be recombined"?) ISTM that it would be more helpful to define attributes in operational terms that the provider can use to decide the value of the attribute. If that is well defined (rather than being subjective) then the recipient can then make its own decisions about what is appropriate to do with the capture. Thanks, Paul (as individual) > This would leave the composed / mixed attribute open for all provider > devices to use (i.e. not just those performing MCU-style layout > compositions), and open to being extended to cover the dynamic update > case (a provider indicating changes in who's being shown where as that > changes, which could be said to be equally applicable to, say, the 4 > panes of a 2 x 2 MCU layout as to 2 people sat next to each other at a > desk covered by a single camera [capture]). > > Regards, > > Andy > > > On Fri, Mar 30, 2012 at 2:52 PM, Charles Eckel (eckelcu) > wrote: >> Reiterating a comment I made a the mic, I would like to see the addition >> of semantics that describe the composed/mixed media capture in terms of >> other media captures, when applicable. I think this would be very useful >> information for a consumer. >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>> Paul Kyzivat >>> Sent: Wednesday, March 28, 2012 11:40 PM >>> To: Duckworth, Mark >>> Cc: clue@ietf.org >>> Subject: Re: [clue] Use of the media capture "composed" attribute >>> >>> I think this further verifies that we need a better explanation of the >>> intended purpose(s) of these (mixed/composed) attributes so that we >> can >>> assess whether we have an actionable definition sufficient to the >> need. >>> >>> Thanks, >>> Paul >>> >>> On 3/28/12 10:52 AM, Duckworth, Mark wrote: >>>> Paul asked: >>>>> If mixed and composed aren't intended to drive decisions about >>> further >>>>> mixing and composing, then what *are* they for? >>>> >>>> I was thinking one other case where the composed attribute would be >>> used is when a consumer (an endpoint in this case) is choosing which >>> media captures to receive from a provider. Suppose the provider >>> advertises capture scene entries that are the same except one of them >>> has video captures that use composed=true, and the other uses >>> composed=false. I think the consumer can reasonably assume the one >>> with composed=true includes more information somehow, possibly with >>> "Hollywood squares" or picture-in-picture video layout. The consumer >>> can use this limited information to make a choice. This choice has >>> nothing to do with whether or not the receiving endpoint is going to >>> re-compose the images. >>>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>> Of >>>>> Paul Kyzivat >>>>> Sent: Tuesday, March 27, 2012 11:35 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] Use of the media capture "composed" attribute >>>>> >>>>> [I don't know if this is as chair or individual. Maybe both.] >>>>> >>>>> The discussion of the composed and mixed attributes today exposed a >>> lot of >>>>> vagueness about what they mean. I think this needs to be firmed up >>>>> considerably. >>>>> >>>>> Here are some thoughts of my own just to keep the discussion going: >>>>> >>>>> Regarding mixed (audio): >>>>> >>>>> The fact that an audio capture has mixed content doesn't preclude >>> mixing it >>>>> again. But there are properties of it that might make such mixing >>>>> unsatisfactory. For instance, if AC3 is a mix of (AC1, AC2), then >> it >>> is ok to mix >>>>> AC3 and independent capture AC4. But it would be unwise to mix it >>> with AC2 >>>>> again. And it would also be unwise to mix it with AC5 that is >> itself >>> a mix of >>>>> (AC1, AC4). >>>>> >>>>> It *might* also be the case that a mix is unwise if it includes >>>>> (transitively) too many original inputs. >>>>> >>>>> Fundamentally it seems like the decision of whether a mix makes >>> sense >>>>> requires some complex decision making based on way more data than >>>>> whether the immediate inputs are themselves mixed or not. >>>>> >>>>> Regarding composed (video): >>>>> >>>>> This seems potentially more complex. So far the only use I have >>> heard for >>>>> this attribute is to drive a decision about whether it makes sense >>> to compose >>>>> this capture with others. But I expect that isn't always true >>> either. You could >>>>> have one uncomposed capture that shows two people >>>>> (heads) side by side. You could have another *composed* capture >> that >>> also >>>>> shows two people in independently side by side each inside a frame, >>> that >>>>> were assembled from other captures. (Would anyone argue that this >>> isn't >>>>> composed?) But I can't see why it would be any more or less >>> desirable to >>>>> compose one of these captures than another. >>>>> >>>>> Again it seems like you need more information about what has been >>>>> composed, and at what scale (and maybe position) before you can >> make >>> a >>>>> decision about whether it makes sense to compose it. And then that >>> may >>>>> also depend on *how* you want to compose it. >>>>> >>>>> If mixed and composed aren't intended to drive decisions about >>> further >>>>> mixing and composing, then what *are* they for? >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Fri Apr 6 06:01:18 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D372021F85C6 for ; Fri, 6 Apr 2012 06:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyeXM41obEZB for ; Fri, 6 Apr 2012 06:01:18 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id EA9B921F8576 for ; Fri, 6 Apr 2012 06:01:17 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id ubg91i0031swQuc51d1J8t; Fri, 06 Apr 2012 13:01:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id ud1J1i00907duvL3bd1JhG; Fri, 06 Apr 2012 13:01:18 +0000 Message-ID: <4F7EE91B.1050201@alum.mit.edu> Date: Fri, 06 Apr 2012 09:01:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Andy Pepperell References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> <4F723272.4040409@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7B@CRPMBOXPRD01.polycom.com> <4F738516.2000209@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 13:01:18 -0000 On 4/6/12 4:24 AM, Andy Pepperell wrote: > Hi Charles, > > re: this specific point, it could be said that to an extent the > structure / semantics of the capture scene entries do give you this > information, in that each such entry in a capture scene captures > "equivalent" data, so, if, say, you have a capture scene entry > consisting of just VC1 and there's another entry in the same capture > scene consisting of VC2, VC3 and VC4 then, whether or not VC1 is > tagged as composed/mixed, it to an extent "covers" VC2, VC3 and VC4 > (and the area of capture co-ordinates can be used to determine this in > more detail). ISTM that the area of capture is more meaningful here. Its a leap of faith to assume that just because VC1 is an alternative to VC2+VC3+VC4 that it must contain a rendition of everything in VC2+VC3+VC4. It might just show the active speaker, or it might just show the most important person, or just the presentation. > One issue with separate semantics for describing captures in terms of > other captures, to my mind, is that it wouldn't give as fine-grained > information as one might want. This is all hypothetical right now. Presumably it can give as detailed a description as clue makes provision for describing. > In the case of a single VCn being > supplied from a single-camera endpoint, presumably a fairly common > case, we might want to have a provider -> consumer mechanism for > describing who's on the left and right of the image without the need > to invent new sub-captures for this purpose. AFAIK we don't currently have any mechanism to describe who is where, regardless of how many captures there are. (Though perhaps we should.) Thanks, Paul (as individual) > Andy > > > On Fri, Mar 30, 2012 at 2:52 PM, Charles Eckel (eckelcu) > wrote: >> Reiterating a comment I made a the mic, I would like to see the addition >> of semantics that describe the composed/mixed media capture in terms of >> other media captures, when applicable. I think this would be very useful >> information for a consumer. >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>> Paul Kyzivat >>> Sent: Wednesday, March 28, 2012 11:40 PM >>> To: Duckworth, Mark >>> Cc: clue@ietf.org >>> Subject: Re: [clue] Use of the media capture "composed" attribute >>> >>> I think this further verifies that we need a better explanation of the >>> intended purpose(s) of these (mixed/composed) attributes so that we >> can >>> assess whether we have an actionable definition sufficient to the >> need. >>> >>> Thanks, >>> Paul >>> >>> On 3/28/12 10:52 AM, Duckworth, Mark wrote: >>>> Paul asked: >>>>> If mixed and composed aren't intended to drive decisions about >>> further >>>>> mixing and composing, then what *are* they for? >>>> >>>> I was thinking one other case where the composed attribute would be >>> used is when a consumer (an endpoint in this case) is choosing which >>> media captures to receive from a provider. Suppose the provider >>> advertises capture scene entries that are the same except one of them >>> has video captures that use composed=true, and the other uses >>> composed=false. I think the consumer can reasonably assume the one >>> with composed=true includes more information somehow, possibly with >>> "Hollywood squares" or picture-in-picture video layout. The consumer >>> can use this limited information to make a choice. This choice has >>> nothing to do with whether or not the receiving endpoint is going to >>> re-compose the images. >>>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>> Of >>>>> Paul Kyzivat >>>>> Sent: Tuesday, March 27, 2012 11:35 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] Use of the media capture "composed" attribute >>>>> >>>>> [I don't know if this is as chair or individual. Maybe both.] >>>>> >>>>> The discussion of the composed and mixed attributes today exposed a >>> lot of >>>>> vagueness about what they mean. I think this needs to be firmed up >>>>> considerably. >>>>> >>>>> Here are some thoughts of my own just to keep the discussion going: >>>>> >>>>> Regarding mixed (audio): >>>>> >>>>> The fact that an audio capture has mixed content doesn't preclude >>> mixing it >>>>> again. But there are properties of it that might make such mixing >>>>> unsatisfactory. For instance, if AC3 is a mix of (AC1, AC2), then >> it >>> is ok to mix >>>>> AC3 and independent capture AC4. But it would be unwise to mix it >>> with AC2 >>>>> again. And it would also be unwise to mix it with AC5 that is >> itself >>> a mix of >>>>> (AC1, AC4). >>>>> >>>>> It *might* also be the case that a mix is unwise if it includes >>>>> (transitively) too many original inputs. >>>>> >>>>> Fundamentally it seems like the decision of whether a mix makes >>> sense >>>>> requires some complex decision making based on way more data than >>>>> whether the immediate inputs are themselves mixed or not. >>>>> >>>>> Regarding composed (video): >>>>> >>>>> This seems potentially more complex. So far the only use I have >>> heard for >>>>> this attribute is to drive a decision about whether it makes sense >>> to compose >>>>> this capture with others. But I expect that isn't always true >>> either. You could >>>>> have one uncomposed capture that shows two people >>>>> (heads) side by side. You could have another *composed* capture >> that >>> also >>>>> shows two people in independently side by side each inside a frame, >>> that >>>>> were assembled from other captures. (Would anyone argue that this >>> isn't >>>>> composed?) But I can't see why it would be any more or less >>> desirable to >>>>> compose one of these captures than another. >>>>> >>>>> Again it seems like you need more information about what has been >>>>> composed, and at what scale (and maybe position) before you can >> make >>> a >>>>> decision about whether it makes sense to compose it. And then that >>> may >>>>> also depend on *how* you want to compose it. >>>>> >>>>> If mixed and composed aren't intended to drive decisions about >>> further >>>>> mixing and composing, then what *are* they for? >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Apr 9 13:51:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7F421F87EE for ; Mon, 9 Apr 2012 13:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.598 X-Spam-Level: X-Spam-Status: No, score=-104.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzzvPm+zKJBU for ; Mon, 9 Apr 2012 13:51:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 14E7321F87F4 for ; Mon, 9 Apr 2012 13:51:18 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3004749vbb.31 for ; Mon, 09 Apr 2012 13:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=iC1yuF8GZcuKoIE0sbkttRQzP2wEfEDlKs0hzng9j+4=; b=q9KYGQ0pkoBpAsV5PIV3XQmsvEyZuL+RPKwSU2x/rOkmFanoqCZ8/WV/J+VIT6FV9K JZGwu290h6KveVay4CzmNrDrWMme7wBIFHsIINXoIYl40GvVj1bv0Qs7846L5KkTtY3M EREzvhUk6TRnJ+vGgLxwH2YSFvdx07a+kqMQsAZUL8V6qKPCl4c0iNx6XIB7H5KfMt6g wMgXyWvB1gEQgF/MIM0S5cLvbUxqOG+fNY6dHmUNmYnrFacrpjzD1HeP3VnzertWeCV0 u4XxiLZSK/qnQov6h3YAfkeJusogfrSNJ3DA02hC6mduKf2ktyKU/GMm1ckTIcVHbErk jrkA== MIME-Version: 1.0 Received: by 10.52.73.132 with SMTP id l4mr3538280vdv.4.1334004677447; Mon, 09 Apr 2012 13:51:17 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Mon, 9 Apr 2012 13:51:17 -0700 (PDT) In-Reply-To: <205835231.1334003836566.JavaMail.nobody@jva2wl001.webex.com> References: <205835231.1334003836566.JavaMail.nobody@jva2wl001.webex.com> Date: Mon, 9 Apr 2012 15:51:17 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf3071c7e0ed8e2d04bd452a2b Subject: [clue] Fwd: Meeting invitation: CLUE WG Design Team X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 20:51:19 -0000 --20cf3071c7e0ed8e2d04bd452a2b Content-Type: text/plain; charset=ISO-8859-1 Hi folks, Below please find the webex details for tomorrow's Design team call. These details should apply to the calls through July 17th, 2012, so please either save this email or add this to your calendar by clicking the link below. We'll send the topic for tomorrow shortly. Thanks, Mary. ---------- Forwarded message ---------- From: Clue Working Group Date: Mon, Apr 9, 2012 at 3:37 PM Subject: Meeting invitation: CLUE WG Design Team To: mary.ietf.barnes@gmail.com Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG Design Team Date: Every Tuesday, from Tuesday, April 10, 2012 to Tuesday, July 17, 2012 Time: 9:00 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 641 658 366 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=152424912&UID=1244287392&PW=NZTliYmY5NDA4&RT=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=152424912&UID=1244287392&PW=NZTliYmY5NDA4&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code:641 658 366 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=152424912&UID=1244287392&ICS=MI&LD=1&RD=2&ST=1&SHA2=FcyzMIRvFFq-rm7Ros88rwGpeYrVAOhJutQlkgKgFrc=&RT=MiM3 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14086003600x641658366# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --20cf3071c7e0ed8e2d04bd452a2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,=A0

Below please find the webex details for tom= orrow's Design team call. =A0These details should apply to the calls th= rough July 17th, 2012, so please either save this email or add this to your= calendar by clicking the link below. =A0

We'll send the topic for tomorrow shortly.

Thanks,
Mary.=A0

---------- Forwarded message ----------
From: Clue Working Group <messenger@webex.com>
Date: Mon, Apr 9, 2012 at 3:37 PM
Subject: Meeting invitation: CLUE WG D= esign Team
To: mary.ietf.b= arnes@gmail.com



Hello ,

Clue Working Group invites you to attend this online mee= ting.

Topic: CLUE WG Design Team
Date: Every Tuesday, from T= uesday, April 10, 2012 to Tuesday, July 17, 2012
Time: 9:00 am, Centra= l Daylight Time (Chicago, GMT-05:00)
Meeting Number: 641 658 366
Meeting Password: 1234


---= ----------------------------------------------------
To join the onlin= e meeting (Now from mobile devices!)
---------------------------------= ----------------------
1. Go to htt= ps://ietf.webex.com/ietf/j.php?ED=3D152424912&UID=3D1244287392&PW= =3DNZTliYmY5NDA4&RT=3DMiM3
2. If requested, enter your name and email address.
3. If a password = is required, enter the meeting password: 1234
4. Click "Join"= ;.

To view in other time zones or languages, please click the lin= k:
https://iet= f.webex.com/ietf/j.php?ED=3D152424912&UID=3D1244287392&PW=3DNZTliYm= Y5NDA4&ORT=3DMiM3

-------------------------------------------------------
To join = the audio conference only
--------------------------------------------= -----------
Call-in toll number (US/Canada): +1-408-600-3600

Access code:641 658 366

-----------------------------------= --------------------
For assistance
-----------------------------= --------------------------
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You ca= n contact me at:
clue-chairs@tools.ietf.org


To add this meeti= ng to your calendar program (for example Microsoft Outlook), click this lin= k:
https:= //ietf.webex.com/ietf/j.php?ED=3D152424912&UID=3D1244287392&ICS=3DM= I&LD=3D1&RD=3D2&ST=3D1&SHA2=3DFcyzMIRvFFq-rm7Ros88rwGpeYrVA= OhJutQlkgKgFrc=3D&RT=3DMiM3

The playback of UCF (Universal Communications Format) rich media file= s requires appropriate players. To view this type of rich media files in th= e meeting, please check whether you have the players installed on your comp= uter by going to https://ietf.webex.com/ietf/systemdiagnosis.php.
Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial=

http://ww= w.webex.com

CCP:+14086003600x641658366#

IMPORTANT NOTICE: This WebEx se= rvice includes a feature that allows audio and any documents and other mate= rials exchanged or viewed during the session to be recorded. By joining thi= s session, you automatically consent to such recordings. If you do not cons= ent to the recording, discuss your concerns with the meeting host prior to = the start of the recording or do not join the session. Please note that any= such recordings may be subject to discovery in the event of litigation.

--20cf3071c7e0ed8e2d04bd452a2b-- From trac+clue@trac.tools.ietf.org Tue Apr 10 06:17:48 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A80221F8606 for ; Tue, 10 Apr 2012 06:17:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPYVnh9jzELI for ; Tue, 10 Apr 2012 06:17:47 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 748D021F8604 for ; Tue, 10 Apr 2012 06:17:47 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SHawt-0003te-7X; Tue, 10 Apr 2012 09:17:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, marshall.eubanks@gmail.com X-Trac-Project: clue Date: Tue, 10 Apr 2012 13:17:30 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/7#comment:4 Message-ID: <083.0f61a255e64e6f1a288dafab8141842b@trac.tools.ietf.org> References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, marshall.eubanks@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120410131747.748D021F8604@ietfa.amsl.com> Resent-Date: Tue, 10 Apr 2012 06:17:47 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:17:48 -0000 #7: Is composed attribute a boolean or data structure Changes (by mary.ietf.barnes@…): * status: new => closed * resolution: => fixed Old description: > Need to determine WG consensus as to whether the composed attribute is a > boolean (currently in the framework) or whether it should be a data > structure describing the composed image. > (Note: this ticket is a result of closing Issue #2). New description: Need to determine WG consensus as to whether the composed attribute is a boolean (currently in the framework) or whether it should be a data structure describing the composed image. (Note: this ticket is a result of closing Issue #2). Proposal to close ticket with conclusion that composed attribute is a boolean on March 9th: http://www.ietf.org/mail-archive/web/clue/current/msg01172.html Confirmed at IETF-83 (chart 9): http://www.ietf.org/proceedings/83/slides/slides-83-clue-2.pptx -- -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: task | Status: closed Priority: major | Milestone: Component: framework | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From mary.ietf.barnes@gmail.com Tue Apr 10 07:04:59 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B76411E80E1 for ; Tue, 10 Apr 2012 07:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.832 X-Spam-Level: X-Spam-Status: No, score=-103.832 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtYCDiypXhvF for ; Tue, 10 Apr 2012 07:04:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1A611E80CA for ; Tue, 10 Apr 2012 07:04:57 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3548430vbb.31 for ; Tue, 10 Apr 2012 07:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qN4UA89hajKo3k27z328zEOhOpr3wwdEEX0oWlNz1y4=; b=Fgifp+cpslONk9cdUMCHFFs4h9DNcHrmS8gkHotFztFyx5Y/ZIqeTueHaxE4uQBo/l 4oZEe/Gda7ET8erVvfeIPwJPlojw66XxycAgufH1hNWoYB4SZRrMatMfCXC65X/K8KdW q7KqE4xwOe3keNNwLw6Kd6MdD0yorZZLNxVXmuq4Zwn0r6TuGK7iuxppv1cuHIMdCxAO Rd2QnE07Tylvp5TO2Rd5hB8HUyRN45h5aa14nXgvTOzugm300zwiqlH0rM1O6j2tH2SE db5XlWBD1hCPDl4XLBAPPAujcy9reixIrY5OmrrY9siNTK7TDCoD6b6KRut0Ut3Mot12 Zrjw== MIME-Version: 1.0 Received: by 10.52.73.132 with SMTP id l4mr4683761vdv.4.1334066697570; Tue, 10 Apr 2012 07:04:57 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Tue, 10 Apr 2012 07:04:57 -0700 (PDT) Date: Tue, 10 Apr 2012 09:04:57 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf3071c7e09d889e04bd539b2a Subject: [clue] Agenda: CLUE WG Design Team X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:04:59 -0000 --20cf3071c7e09d889e04bd539b2a Content-Type: text/plain; charset=ISO-8859-1 Agenda: 1) Review list of open action items. 2) Discuss current open items and decide if we need an issue opened in the tracker or whether these aren't real issues: - mixed/composed - simultaneous sets 3) Way forward for signaling solution(s) and data model. Thanks, Mary. >> >> ---------- Forwarded message ---------- >> From: *Clue Working Group* > > >> Date: Mon, Apr 9, 2012 at 3:37 PM >> Subject: Meeting invitation: CLUE WG Design Team >> To: mary.ietf.barnes@gmail.com >> > >> >> >> >> Hello , >> >> Clue Working Group invites you to attend this online meeting. >> >> Topic: CLUE WG Design Team >> Date: Every Tuesday, from Tuesday, April 10, 2012 to Tuesday, July 17, >> 2012 >> Time: 9:00 am, Central Daylight Time (Chicago, GMT-05:00) >> Meeting Number: 641 658 366 >> Meeting Password: 1234 >> >> >> ------------------------------**------------------------- >> To join the online meeting (Now from mobile devices!) >> ------------------------------**------------------------- >> 1. Go to >> https://ietf.webex.com/ietf/j.**php?ED=152424912&UID=** >> 1244287392&PW=NZTliYmY5NDA4&**RT=MiM3 >> > 1244287392&PW=NZTliYmY5NDA4&**RT=MiM3 >> > >> >> 2. If requested, enter your name and email address. >> 3. If a password is required, enter the meeting password: 1234 >> 4. Click "Join". >> >> To view in other time zones or languages, please click the link: >> https://ietf.webex.com/ietf/j.**php?ED=152424912&UID=** >> 1244287392&PW=NZTliYmY5NDA4&**ORT=MiM3 >> > 1244287392&PW=NZTliYmY5NDA4&**ORT=MiM3 >> > >> >> >> ------------------------------**------------------------- >> To join the audio conference only >> ------------------------------**------------------------- >> Call-in toll number (US/Canada): +1-408-600-3600 >> >> >> Access code:641 658 366 >> >> ------------------------------**------------------------- >> For assistance >> ------------------------------**------------------------- >> 1. Go to https://ietf.webex.com/ietf/mc >> 2. On the left navigation bar, click "Support". >> >> You can contact me at: >> clue-chairs@tools.ietf.org >> > >> >> >> >> To add this meeting to your calendar program (for example Microsoft >> Outlook), click this link: >> https://ietf.webex.com/ietf/j.**php?ED=152424912&UID=** >> 1244287392&ICS=MI&LD=1&RD=2&**ST=1&SHA2=FcyzMIRvFFq-** >> rm7Ros88rwGpeYrVAOhJutQlkgKgFr**c=&RT=MiM3 >> > 1244287392&ICS=MI&LD=1&RD=2&**ST=1&SHA2=FcyzMIRvFFq-** >> rm7Ros88rwGpeYrVAOhJutQlkgKgFr**c=&RT=MiM3 >> > >> >> >> The playback of UCF (Universal Communications Format) rich media files >> requires appropriate players. To view this type of rich media files in >> the meeting, please check whether you have the players installed on your >> computer by going to https://ietf.webex.com/ietf/**systemdiagnosis.php >> . >> >> Sign up for a free trial of WebEx >> http://www.webex.com/go/**mcemfreetrial >> >> http://www.webex.com >> >> CCP:+14086003600x641658366# >> >> IMPORTANT NOTICE: This WebEx service includes a feature that allows >> audio and any documents and other materials exchanged or viewed during >> the session to be recorded. By joining this session, you automatically >> consent to such recordings. If you do not consent to the recording, >> discuss your concerns with the meeting host prior to the start of the >> recording or do not join the session. Please note that any such >> recordings may be subject to discovery in the event of litigation. >> >> > --20cf3071c7e09d889e04bd539b2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Agenda:
1) Review list of open action items.<= /div>
2) Discuss current open items and decide if we need an issue open= ed in the tracker or whether these aren't real issues:
- mixed/composed
- simultaneous sets
3) Way forwar= d for signaling solution(s) and data model.

Thanks= ,
Mary.=A0




---------- Forwarded message ----------
From: *Clue Working Group* <messenger@webex.com
<mailto:messeng= er@webex.com>>
Date: Mon, Apr 9, 2012 at 3:37 PM
Subject: Meeting invitation: CLUE WG Design Team
<= div> To: mary.ie= tf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com>



Hello ,

Clue Working Group invites you to attend this online meeting.

Topic: CLUE WG Design Team
Date: Every Tuesday, from Tuesday, April 10, 2012 to Tuesday, July 17, 2012=
Time: 9:00 am, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 641 658 366
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to
https://ietf.= webex.com/ietf/j.php?ED=3D152424912&UID=3D1244287392&= PW=3DNZTliYmY5NDA4&RT=3DMiM3
<https://i= etf.webex.com/ietf/j.php?ED=3D152424912&UID=3D1244287392&= amp;PW=3DNZTliYmY5NDA4&RT=3DMiM3>

2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf= .webex.com/ietf/j.php?ED=3D152424912&UID=3D1244287392&= ;PW=3DNZTliYmY5NDA4&ORT=3DMiM3
<https://= ietf.webex.com/ietf/j.php?ED=3D152424912&UID=3D1244287392= &PW=3DNZTliYmY5NDA4&ORT=3DMiM3>


-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
Call-in toll number (US/Canada): +1-408-600-3600 <tel:%2B1-408-600-3= 600>


Access code:641 658 366

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https= ://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You can contact me at:
clue-= chairs@tools.ietf.org <mailto:clue-chairs@tools.ietf.org>



To add this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https:/= /ietf.webex.com/ietf/j.php?ED=3D152424912&UID=3D124428739= 2&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DFcyzMIRvF= Fq-rm7Ros88rwGpeYrVAOhJutQlkgKgFrc=3D&RT=3DMiM3
<htt= ps://ietf.webex.com/ietf/j.php?ED=3D152424912&UID=3D12442= 87392&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DFcyzM= IRvFFq-rm7Ros88rwGpeYrVAOhJutQlkgKgFrc=3D&RT=3DMiM3&g= t;


The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in
the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.= php.

Sign up for a free trial of WebEx
http://= www.webex.com/go/mcemfreetrial

http://www.webex.com=

CCP:+14086003600x641658366#

IMPORTANT NOTICE: This WebEx service includes a feature that allows
audio and any documents and other materials exchanged or viewed during
the session to be recorded. By joining this session, you automatically
consent to such recordings. If you do not consent to the recording,
discuss your concerns with the meeting host prior to the start of the
recording or do not join the session. Please note that any such
recordings may be subject to discovery in the event of litigation.




--20cf3071c7e09d889e04bd539b2a-- From marshall.eubanks@gmail.com Tue Apr 10 08:29:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B746A11E80F1 for ; Tue, 10 Apr 2012 08:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.58 X-Spam-Level: X-Spam-Status: No, score=-104.58 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUKkU2bqjWXc for ; Tue, 10 Apr 2012 08:29:36 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E10711E80F3 for ; Tue, 10 Apr 2012 08:29:36 -0700 (PDT) Received: by lbok13 with SMTP id k13so2915595lbo.31 for ; Tue, 10 Apr 2012 08:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kk0WoD5DHDvxEpUIKDEORA1ddYFfKukXNcsbXdTVrPQ=; b=OOkxJ+3ChRxJzS41EeILYwKWMIORysfjiCmNqtbHItKrx30jROdvSTwkzbY5v7Gcg4 9LXvxyf162qFvKrjZe3BNfBKBbl+SJPCEgmxwOcl9rKiIPlNhjzK7yUSHEX9btv5iDgN SbjeuvCYEVeXjCCCAxGHFaQMunaa/pr7x/AaP+FCs1gSWWjulhAgA8eQkPcYP3y0YmfP Up4cfPAvpyk8525+J7M0Qo9HRgO9vfG/77W3379g0IqkHO6uBdwXXzxfVEnZiG3Zoe8U gfGyyi14Q0gQJn73qGAtIQXYckLKajgRoibqzkDDZ0ri0YYZQacKBDltd3OypLz7Wg12 waDQ== MIME-Version: 1.0 Received: by 10.152.147.100 with SMTP id tj4mr15081871lab.39.1334071775261; Tue, 10 Apr 2012 08:29:35 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Tue, 10 Apr 2012 08:29:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 11:29:35 -0400 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] Agenda: CLUE WG Design Team X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:29:37 -0000 (Fairly) raw notes from today's call. Regards Marshall On Tue, Apr 10, 2012 at 10:04 AM, Mary Barnes wrote: > > > Agenda: > 1) Review list of open action items. > 2) Discuss current open items and decide if we need an issue opened in the > tracker or whether these aren't real issues: > - mixed/composed > - simultaneous sets > 3) Way forward for signaling solution(s) and data model. > > Thanks, > Mary. > > >>> >>> >>> ---------- Forwarded message ---------- >>> From: *Clue Working Group* >> > >>> Date: Mon, Apr 9, 2012 at 3:37 PM >>> Subject: Meeting invitation: CLUE WG Design Team >>> To: mary.ietf.barnes@gmail.com >>> >>> >>> > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > CLUE Design Team Tue Apr 10 10:03:01 EDT 2012 Marshall Eubanks Allyn Romanow Brian Baldino John Leslie Jonathan Lennox Mark Duckworth Mary Barnes (Chair) Rob Hansen Espen Berger Paul Kyzivat Mary : I thought we would go over some of issues and the things being discussed on the list. (shows active tickets) The first issue is the source selection case. Jonathan : I thought we discussed that in Andover. I thought the conclusions was it was a good use case but not anything we want in version 1. Mary : OK, great, I will go ahead and close that out. I don't see Roni. He has the RTCWEB use case. I don't think he is on right now. ? : Is it a Holiday in Israel? Mary : Maybe. I know Saturday was Passover. I will consult with Roni. Issue # 4 - there is not much we can do about that now. It has to be on hold for a while. Issue 5 is describing in room attributes. Mary : There was 9, the axis of capture. This is Stephan's. I will get back to him on this. Ticket 8 is distinguishing between multiple capture scenes. Espen : The classic case is where you have a lecture capture, with one camera at the speaker and one at the white board and one on the audience. Mark : That sounds like it would fit better using the purpose attribute. Espen : 4796 ? Mark : That sounds right. Jonathan : I thought this issue was about capture scenes. Mark : My basic question is, does anybody think that adding a human readable name as an attribute would help. I am thinking that the purpose attribute would be more easily useful. Espen : It is not only automatic, I want it to be in the message so I can understand - it is in addition. So, maybe it has two source. Rob : In the past we have talked about conferences with multiple capture scenes for different users - there, they would have the same purpose, so the purpose isn't enough. Paul : There have been cases where purpose is not enough. Having a human decipherable name is a fail-back. Mark : If it is a human readable string, would the source be a human ? Paul : That is not for us to decide. Marshall : Don't these sorts of things tend to turn into profiles over time? If you make this available, it will become something for the automated machinery to use. Paul : We talked about cases where there were 2 kinds of captures Mary : XCON does have a display text for available media. Paul : If the mapping to XCON is well understood, then maybe it is OK. Do we agree that each capture is a participant ? Mary : CLUE is built on SIP. XCON is built on SIPPING - if it is already there, we shouldn't be replicating it. The conference is built on blocks of attributes, each representing a participant. This is something to look at. I think it is reasonable to say we want something human readable - something capturable. Espen : I think it depends on the use cases. Mary : So it falls back to our use cases. Roni had comments on this too. I think we can agree to some sort of human readable text. So, that is the last open issue. The most recent ML discussion was around the mixed proposed. Paul : It seems we have been going in circles. The first thing to sort out is, what is the point of these attributes? Why are they there ? My take is that we are trying to provide enough information to map captures onto equipment at the receiver side, and these attributes will help with that. Jonathan : A lot of the complication is, we have a mixer. The consumer may be a middle box, which may not pass it along. Paul : If we can figure out the purpose, we can then figure out if we have the right information. We got into this confusing discussion about what it means to be composed. Maybe some captures from one camera can be composed. Espen : You want to cover use cases where the end user relies on a middle box, or the receiver receives something untouched from the sender. The first one I call composed, and the second original. So, a middle box needs to be able to express that it can send either original or composed scenes. Paul : This sounds like an attribute on the capture set. Espen : I think we need more concrete examples. Paul : I wonder if we need to identify some more challenging use cases. If all you have is that some are composed or some or not Espen : In this particular case, you don't mix. All are composed, or none. Paul : You can compose the not composed ones, but leave the composed ones alone. Espen : The base is, I think, a single composed attribute. Paul : Can we write down some of these cases ? Mark : It seems to me that these scenarios are more general than multiple streams for telepresence. The same issues apply to non-telepresence single stream units. Are we sure that CLUE is the best place for this ? Mary : I am not sure that we are. Espen : I can write down some of these use cases. I remember from IETF in Paris that there are people discussing related issues [in a number of different WG]. Paul : At the META level it's the same, but at the audio and video it is quite different. To me the fundamental problem in the scope of CLUE is, if you are the end point, and you have received an advertisement, with some scenes and captures, do you have sufficient information to select and map what you have onto what you have got. If the geometry does not match, then what ? Is there enough information to decide what to do? Marshall : And that is very telepresence specific. Even in typical videoconferencing you may not really care about what goes where in what size, as long as it fits. Espen : I think in other cases you may well care as well. Paul : So, what is the next step ? Mary : We can open a ticket and Espen said he would send something to the list. [Mary asked about the status of the Wenger transport draft - I said that I wasn't aware of any immediate plans to rev it.] Mary : We have had a discussion about the data model and different people had different views. To me, it is about what is to be carried. I know that all of this is If someone would like to volunteer and talk to Christer [Holmberg] on the data model and volunteer, that would be good. Allyn : Didn't Andy come out with a data model. Espen : That document would be a good starting point for what you should supply that isn't in SDP. Mary : That was not an IETF draft. Paul : It was his presentation. Mary : Right. I will let Christer know that that is available. I will forward this document to him. I think we will hold off other issues to next week. Call ended Tue Apr 10 10:56:21 EDT 2012 From ron.even.tlv@gmail.com Tue Apr 10 08:34:14 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D0711E80F6 for ; Tue, 10 Apr 2012 08:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3KwqM2go26r for ; Tue, 10 Apr 2012 08:34:13 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8B811E80D9 for ; Tue, 10 Apr 2012 08:34:13 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3562626wgb.13 for ; Tue, 10 Apr 2012 08:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=pBlBDA3qjpovRlfps912xJuPGpxvHbJofUUsLWxA6Ko=; b=xD3T4WOzVg1j8Lqh3JoQ/Dd3KbXYgGPS7sZ1vW3cl1Q3cpvjUBudivF8jSuNbn9yUv xjmU8WObJPBdlcU1WkYfbbGugPp2aHZiJTeEqAvzXIajhr+nhfbux9s4sYYLfNSQuQUg KdBApzuumwBjklLivaAqjHbi/zqt8psmjZ+r2rSv7ge35l2kvEGh6Bs5MXDQap55up4F 6i0BoEOSQZd/stRz2S1A8lpBR2cpMo0wwghf1WTpgc0+ib5XODpuzObtlqAXISohDl6j /iC+uioWWdoc+sPx8FsqykDKPKsiMgEi+P9q380glx5YWSIQroi94mRtprQeqKjpIGeH VeRg== Received: by 10.216.225.216 with SMTP id z66mr6570973wep.71.1334072052593; Tue, 10 Apr 2012 08:34:12 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id ff9sm38351184wib.2.2012.04.10.08.34.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 08:34:11 -0700 (PDT) From: "Roni Even" To: , References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> <083.0f61a255e64e6f1a288dafab8141842b@trac.tools.ietf.org> In-Reply-To: <083.0f61a255e64e6f1a288dafab8141842b@trac.tools.ietf.org> Date: Tue, 10 Apr 2012 18:32:48 +0300 Message-ID: <4f8452f3.6965b40a.256d.20ce@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0XHFZr0VcWTWuHQw6ZcuqUNLAiMwAEl9ZQ Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:34:14 -0000 Hi Mary, This is a procedural question I am wondering how the conclusion is tracked. I understand that closing = the issue should result update to the text in the framework. So where is = this conclusion appears as a summary by the WG chairs. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > clue issue tracker > Sent: Tuesday, April 10, 2012 4:18 PM > To: draft-ietf-clue-framework@tools.ietf.org; > mary.ietf.barnes@gmail.com; marshall.eubanks@gmail.com > Cc: clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data > structure >=20 > #7: Is composed attribute a boolean or data structure >=20 > Changes (by mary.ietf.barnes@=E2=80=A6): >=20 > * status: new =3D> closed > * resolution: =3D> fixed >=20 >=20 > Old description: >=20 > > Need to determine WG consensus as to whether the composed attribute > is > > a boolean (currently in the framework) or whether it should be a = data > > structure describing the composed image. > > (Note: this ticket is a result of closing Issue #2). >=20 > New description: >=20 > Need to determine WG consensus as to whether the composed attribute = is > a boolean (currently in the framework) or whether it should be a data > structure describing the composed image. > (Note: this ticket is a result of closing Issue #2). >=20 > Proposal to close ticket with conclusion that composed attribute is a > boolean on March 9th: > http://www.ietf.org/mail-archive/web/clue/current/msg01172.html >=20 > Confirmed at IETF-83 (chart 9): > http://www.ietf.org/proceedings/83/slides/slides-83-clue-2.pptx >=20 > -- >=20 > -- > = --------------------------------+-------------------------------------- > - > --------------------------------+--- > Reporter: mary.ietf.barnes@=E2=80=A6 | Owner: = draft-ietf-clue- > framework@=E2=80=A6 > Type: task | Status: closed > Priority: major | Milestone: > Component: framework | Version: > Severity: Active WG Document | Resolution: fixed > Keywords: | > = --------------------------------+-------------------------------------- > - > --------------------------------+--- >=20 > Ticket URL: > > clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Tue Apr 10 08:48:06 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D2511E8117 for ; Tue, 10 Apr 2012 08:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.671 X-Spam-Level: X-Spam-Status: No, score=-103.671 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do9n5CgcDGTl for ; Tue, 10 Apr 2012 08:48:05 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFB911E8116 for ; Tue, 10 Apr 2012 08:48:05 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3132155vcb.31 for ; Tue, 10 Apr 2012 08:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WWl6Guh2XdpDA+QWlFDslvv9SlLvX7d1CksAYrfwvgE=; b=e823Jv1qFIIAl21jRKvlOr4j46Ruk5/tzLIkjzjRHYeYjIkxFEMB3TaabuHY9t9MzE TXVBxI+fH/Dqt/qC8Uk0rsEkyujdpq2xQFk5qoV8bbJi3GG4l0bU4DcZdHZHnHmln7sw iqyUeDkihQpcvpspr4Z+pLzUxxqsYVmsN/5G1gIYk75AKqi0lKPSKNY9pEnJAbhR/yeZ TRndKboM1/oIyWnhWzVNAFjha1xFoXuFqRF68c8MaKyDhZIwnmoukOwPCjJkBds8ykmI xoLzBEuAFkhxGS5N9qPxjIhMgPphzzAy7HQercZTtl4GRhgsuM8ifYXqXUmCxMp9P5d1 bUDw== MIME-Version: 1.0 Received: by 10.52.73.132 with SMTP id l4mr4858124vdv.4.1334072884973; Tue, 10 Apr 2012 08:48:04 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Tue, 10 Apr 2012 08:48:04 -0700 (PDT) In-Reply-To: <4f8452f3.6965b40a.256d.20ce@mx.google.com> References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> <083.0f61a255e64e6f1a288dafab8141842b@trac.tools.ietf.org> <4f8452f3.6965b40a.256d.20ce@mx.google.com> Date: Tue, 10 Apr 2012 10:48:04 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=20cf3071c7e069cfb004bd550c84 Cc: clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:48:07 -0000 --20cf3071c7e069cfb004bd550c84 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I (as chair) updated the text in the issue tracker to reflect the closure - pointing to email thread and to the chart that Mark presented which proposed the following: =95Propose Ticket #7 be closed, keep =93composed=94 as a boolean attribute =95Add clarifying text for the attribute and for examples, that information like =93loudest panel stream plus PiPs=94 cannot be conveyed using these si= mple attributes Is this not sufficient and if not what do you propose? Are you asking that the change be done before we close the ticket? Mary. On Tue, Apr 10, 2012 at 10:32 AM, Roni Even wrote: > Hi Mary, > This is a procedural question > I am wondering how the conclusion is tracked. I understand that closing > the issue should result update to the text in the framework. So where is > this conclusion appears as a summary by the WG chairs. > > Roni > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > clue issue tracker > > Sent: Tuesday, April 10, 2012 4:18 PM > > To: draft-ietf-clue-framework@tools.ietf.org; > > mary.ietf.barnes@gmail.com; marshall.eubanks@gmail.com > > Cc: clue@ietf.org > > Subject: Re: [clue] #7: Is composed attribute a boolean or data > > structure > > > > #7: Is composed attribute a boolean or data structure > > > > Changes (by mary.ietf.barnes@=85): > > > > * status: new =3D> closed > > * resolution: =3D> fixed > > > > > > Old description: > > > > > Need to determine WG consensus as to whether the composed attribute > > is > > > a boolean (currently in the framework) or whether it should be a data > > > structure describing the composed image. > > > (Note: this ticket is a result of closing Issue #2). > > > > New description: > > > > Need to determine WG consensus as to whether the composed attribute is > > a boolean (currently in the framework) or whether it should be a data > > structure describing the composed image. > > (Note: this ticket is a result of closing Issue #2). > > > > Proposal to close ticket with conclusion that composed attribute is a > > boolean on March 9th: > > http://www.ietf.org/mail-archive/web/clue/current/msg01172.html > > > > Confirmed at IETF-83 (chart 9): > > http://www.ietf.org/proceedings/83/slides/slides-83-clue-2.pptx > > > > -- > > > > -- > > --------------------------------+-------------------------------------- > > - > > --------------------------------+--- > > Reporter: mary.ietf.barnes@=85 | Owner: draft-ietf-clue- > > framework@=85 > > Type: task | Status: closed > > Priority: major | Milestone: > > Component: framework | Version: > > Severity: Active WG Document | Resolution: fixed > > Keywords: | > > --------------------------------+-------------------------------------- > > - > > --------------------------------+--- > > > > Ticket URL: > > > > clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > --20cf3071c7e069cfb004bd550c84 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I (as chair) updated the text in the issue tracker to reflect the closure -= pointing to email thread and to the chart that Mark presented which propos= ed the following:
=95Propose Ticket #7 be closed, keep =93composed=94 as a boolean attrib= ute
=95Add clarifying text for the attribute and for examples, that information like =93loudest panel str= eam plus PiPs= =94 cannot be conveyed usin= g these simple attributes

Is this not sufficient and= if not what do you propose? =A0Are you asking that the change be done befo= re we close the ticket?=A0

Mary.=A0

On Tue, Apr 10, 2012 at 10:32 AM, Roni Even <ron.even.tlv@gmail.com> wr= ote:
Hi Mary,
This is a procedural question
I am wondering how the conclusion is tracked. I understand that closing the= issue should result update to the text in the framework. So where is this = conclusion appears as a summary by the WG chairs.

Roni

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> clue issue tracker
> Sent: Tuesday, April 10, 2012 4:18 PM
> To: draft-= ietf-clue-framework@tools.ietf.org;
> mary.ietf.barnes@gmail.c= om; marshall.eubanks@gmai= l.com
> Cc: clue@ietf.org
> Subject: Re: [clue] #7: Is com= posed attribute a boolean or data
> structure
>
> #7: Is composed attribute a boolean or data structure
>
> Changes (by mary.ietf.barnes@=85):
>
> =A0* status: =A0new =3D> closed
> =A0* resolution: =A0 =3D> fixed
>
>
> Old description:
>
> > Need to determine WG consensus as to whether the composed attribu= te
> is
> > a boolean (currently in the framework) or whether it should be a = data
> > structure describing the composed image.
> > (Note: this ticket is a result of closing Issue #2).
>
> New description:
>
> =A0Need to determine WG consensus as to whether the composed attribute= is
> a =A0boolean (currently in the framework) or whether it should be a da= ta
> structure describing the composed image.
> =A0(Note: this ticket is a result of closing Issue #2).
>
> =A0Proposal to close ticket with conclusion that composed attribute is= a
> boolean on March 9th:
> =A0http://www.ietf.org/mail-archive/web/clue/curren= t/msg01172.html
>
> =A0Confirmed at IETF-83 (chart 9):
> =A0http://www.ietf.org/proceedings/83/slides/slides= -83-clue-2.pptx
>
> --
>
> --
> --------------------------------+-------------------------------------= -
> -
> --------------------------------+---
> =A0Reporter: =A0mary.ietf.barnes@=85 =A0| =A0 =A0 = =A0 Owner: =A0draft-ietf-clue-
> framework@=85
> =A0 =A0 =A0Type: =A0task =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0Status: =A0closed
> =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
> Component: =A0framework =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
> =A0Severity: =A0Active WG Document =A0| =A0Resolution: =A0fixed
> =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> --------------------------------+-------------------------------------= -
> -
> --------------------------------+---
>
> Ticket URL:
> <http://trac.tools.ietf.org/wg/clue/trac/ticket/7#com= ment:4>
> clue <= http://tools.ietf.org/wg/clue/>
>
> ______________________________= _________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue


--20cf3071c7e069cfb004bd550c84-- From pkyzivat@alum.mit.edu Tue Apr 10 10:16:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984F111E80DF for ; Tue, 10 Apr 2012 10:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz284Z9fdG6O for ; Tue, 10 Apr 2012 10:16:18 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 520CE21F8661 for ; Tue, 10 Apr 2012 10:16:18 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta09.westchester.pa.mail.comcast.net with comcast id wBhg1i0061wpRvQ59HGHH7; Tue, 10 Apr 2012 17:16:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id wHGH1i01k07duvL3eHGHXE; Tue, 10 Apr 2012 17:16:17 +0000 Message-ID: <4F846AE0.4010700@alum.mit.edu> Date: Tue, 10 Apr 2012 13:16:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:16:19 -0000 This is follow on to the discussion of mixed/composed attributes. Restating what I said in the design team meeting today: The fundamental problem in the scope of CLUE is, if you are an endpoint, and you have received an advertisement, with some scenes and captures, do you have sufficient information to select and map the advertised scenes/captures onto the equipment you have? If you have sufficient equipment (displays, speakers) with compatible geometry to directly map all of the captures from one audio and one video capture scene entry from each capture scene then maybe all is good. In this case ISTM that the mixed/composed attributes aren't needed. If you don't have sufficient equipment to do that, then the job is harder, and more information is needed to figure out what to do. For instance: - If you don't have suitable displays, then perhaps you can select a video capture scene entry and locally compose or switch some of the captures in order to produce a set of captures that does map to the available displays. The area of capture of each capture could be helpful to doing this, and perhaps the composed attribute as well. - or rather than compose to fit your displays, you could switch. The area of capture and the composed/switched attributes can enter into the decision of which to switch on a single display and which to put on different displays. - handling video from multiple scenes probably presents some added issues. By definition there is no specified spatial relationship between the captures of different scenes. In some sense this may make it easier. - If you don't have sufficient speakers for all of the audio captures, then you have to decide to mix, switch, or drop some. The spatial information from the captures may help in deciding how to mix. Not evident that the mixed attribute helps with this - unless it is used to decide to switch rather than mix. Of course if you are mapping independent audio captures onto different speakers then they are being implicitly mixed. - If you don't have speakers with similar spatial relationship to those of the audio captures, then you must decide whether to do sub-optimal assignments or mix. Again not clear if the mixed attribute helps with this. - If you have audio from more than one scene, what should you do with it? Should you mix, even though you have no spatial relationships? Or should you switch based on active speaker? What would help you to decide? The problems are superficially different for MCUs. But perhaps only superficially. It seems to me that when the MCU decides how to map its inputs into its advertisement, it has some virtual room layouts in mind. So for each virtual room layout it is addressing the same issues as a real endpoint with that layout. But it does have the added problem of deciding how to describe what it is advertising - e.g. when to apply the mixed/composed attributes. Some interesting use cases for all of the above would be very helpful. Thanks, Paul From john@jlc.net Tue Apr 10 14:09:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B5D11E8103 for ; Tue, 10 Apr 2012 14:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.506 X-Spam-Level: X-Spam-Status: No, score=-106.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6gsgi5JTSsJ for ; Tue, 10 Apr 2012 14:09:22 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id EF11811E809D for ; Tue, 10 Apr 2012 14:09:21 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 05D6033C24; Tue, 10 Apr 2012 17:09:22 -0400 (EDT) Date: Tue, 10 Apr 2012 17:09:21 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20120410210921.GM13841@verdi> References: <4F846AE0.4010700@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F846AE0.4010700@alum.mit.edu> User-Agent: Mutt/1.4.1i Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:09:23 -0000 Paul Kyzivat wrote: > > The fundamental problem in the scope of CLUE is, if you are an > endpoint, and you have received an advertisement, with some scenes > and captures, do you have sufficient information to select and map > the advertised scenes/captures onto the equipment you have? Of course not! If we wanted that, we'd have to include for every composed scene what it's composed from, and for every mixed audio what it's mixed from. > If you have sufficient equipment (displays, speakers) with compatible > geometry to directly map all of the captures from one audio and one > video capture scene entry from each capture scene then maybe all is > good. In this case ISTM that the mixed/composed attributes aren't > needed. It's unlikely that the "typical" telepresence conference will have a separate screen for every possible video. Of course, the number of "capture scenes" _could_ be small enough to give each it's own video monitor -- but I don't think that's the general case we should design for. OTOH, with an appropriate "surround-sound" system, you can "place" an arbitrarily large number of audio streams, yet make them easy to distinguish. > If you don't have sufficient equipment to do that, then the job is > harder, and more information is needed to figure out what to do. Only marginally harder... > For instance: > > - If you don't have suitable displays, then perhaps you can select a > video capture scene entry and locally compose or switch some of the > captures in order to produce a set of captures that does map to the > available displays. The area of capture of each capture could be helpful > to doing this, and perhaps the composed attribute as well. One inevitable use case is filing your formal report from the airport. The person doing so will have lousy audio, vastly inadequate video, and typically inadequate bandwidth with excessive latency. S/he will need some middlebox to compose a "barely-adequate video" and mono audio. Then there's the use case of filing you formal report from your home office (when you're sick or somebody doesn't want to pay travel cost). You may well have surround-sound and two or three large monitors, 20 Mbps download with 40 msec RTT, and a decent-quality lavalier mike. You still probably want some middlebox to compose your basic video, but you can take individual streams as well to concentrate on particular people. Near the top end are the corporate telepresence rooms. They will want all streams, and are likely to have a human being mixing them. > - or rather than compose to fit your displays, you could switch... Folks _will_ do that -- I can't stop them. But I find it uninteresting. > - handling video from multiple scenes probably presents some added > issues. By definition there is no specified spatial relationship between > the captures of different scenes... Nonetheless, the participants will want to imagine such a relationship. > - If you don't have sufficient speakers for all of the audio captures, > then you have to decide to mix, switch, or drop some. There really isn't any such thing as "sufficient speakers", but surround-sound should be considered "sufficient". You can always mix to stereo or even mono: "you pays your money and you takes your choice". > The spatial information from the captures may help in deciding how to > mix. Absolutely! > Not evident that the mixed attribute helps with this It help you know when mixing is less likely to work well. > - unless it is used to decide to switch rather than mix. I'm not sure there is any such thing. "Mixing" frequently includes "riding gain" to reduce background noise. Binary switching is just a bad idea. > Of course if you are mapping independent audio captures onto different > speakers then they are being implicitly mixed. Not a useful way to think about it, IMHO. Human ears and brains can sort out individual sources if there are enough speakers, while mixing makes that harder. > - If you don't have speakers with similar spatial relationship to > those of the audio captures, then you must decide whether to do > sub-optimal assignments or mix. I suppose _some_ telepresence system will hide dozens of speakers in the telepresence room and try to do this -- to me it sounds like a dreadful idea, but it's quite possible the people will adapt. "Sub-optimal" really doesn't have a clear meaning here. Even speakers in the "wrong" left-to-right order while you can see the "correct" order on-screen won't confuse the listener as much as speaker assignments changing for no obvious reason. > Again not clear if the mixed attribute helps with this. As an extreme example, you could always render "mixed" in mono. > - If you have audio from more than one scene, what should you do with > it? Should you mix, even though you have no spatial relationships? IMHO, you should _invent_ a spatial relationship in that case. Even if each room invents a different spatial relationship, it will prove less confusing. > Or should you switch based on active speaker? Only if background-noise is a serious problem. > What would help you to decide? It becomes quickly obvious to the listener! > The problems are superficially different for MCUs. But perhaps only > superficially. It seems to me that when the MCU decides how to map its > inputs into its advertisement, it has some virtual room layouts in mind. I would expect so. > So for each virtual room layout it is addressing the same issues as a > real endpoint with that layout. But it does have the added problem of > deciding how to describe what it is advertising - e.g. when to apply > the mixed/composed attributes. Pretty much always, unless it's feeding an exact copy of what it receives. > Some interesting use cases for all of the above would be very helpful. Did the cases I listed help? -- John Leslie From ron.even.tlv@gmail.com Tue Apr 10 14:23:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B39E11E8103 for ; Tue, 10 Apr 2012 14:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6imhSEmzCgp for ; Tue, 10 Apr 2012 14:23:27 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 77DD411E809D for ; Tue, 10 Apr 2012 14:23:26 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so200803wib.13 for ; Tue, 10 Apr 2012 14:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=38XDrqP0FEnWEjXJL2WrJCIPPSO4P82lNRgO2/sh6hU=; b=k4UD+rxuWM8nZFRhL6zynvmMMM4AJ1yAktqoaqNH+Zbk5kGfC3swZDdTjFE/itqfAi f59IyjsRS3I572Nr5eVVM0H/w23n76sno9pNZwHyUN7KRt3qvwirdl2710JoIrTVX0ve 414+2e6ckUbrIXAx7VHo+qUSSOp0ee2xn4tZBO0icX9dYHXwAa0+ShpjWDiXEyYJ95+v 7051XT/s4EDQ4aHH10pVBJWwkpEN5KTd9M9vFWqSyf7AcgOkQSryHlh5RcS8gxg+RGY3 jDmp022ApHJQksoXmzDXp2Gw7/EZK0s6ojzEFgZbsYl0ogpbANIbDVHfktZzNtyf7o3U 6Vqw== Received: by 10.180.100.2 with SMTP id eu2mr10478352wib.1.1334093004588; Tue, 10 Apr 2012 14:23:24 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id ea6sm40299306wib.5.2012.04.10.14.23.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 14:23:23 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> <083.0f61a255e64e6f1a288dafab8141842b@trac.tools.ietf.org> <4f8452f3.6965b40a.256d.20ce@mx.google.com> In-Reply-To: Date: Wed, 11 Apr 2012 00:21:59 +0300 Message-ID: <4f84a4cb.8661b40a.377d.ffffb0bb@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01CD1779.1DA16310" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0XMVFkU4dZUu08QKylsbLYrIRCIwALifUQ Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:23:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0088_01CD1779.1DA16310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am OK with how you phrased it now. I did not see the second bullet as the outcome of closing this issue since the thread had it but not reflected as a WG consensus. I think that when closing an issue we should also be clear about what was the outcome as agreed by the WG. Roni From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Tuesday, April 10, 2012 6:48 PM To: Roni Even Cc: marshall.eubanks@gmail.com; clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure I (as chair) updated the text in the issue tracker to reflect the closure - pointing to email thread and to the chart that Mark presented which proposed the following: .Propose Ticket #7 be closed, keep "composed" as a boolean attribute .Add clarifying text for the attribute and for examples, that information like "loudest panel stream plus PiPs" cannot be conveyed using these simple attributes Is this not sufficient and if not what do you propose? Are you asking that the change be done before we close the ticket? Mary. On Tue, Apr 10, 2012 at 10:32 AM, Roni Even wrote: Hi Mary, This is a procedural question I am wondering how the conclusion is tracked. I understand that closing the issue should result update to the text in the framework. So where is this conclusion appears as a summary by the WG chairs. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > clue issue tracker > Sent: Tuesday, April 10, 2012 4:18 PM > To: draft-ietf-clue-framework@tools.ietf.org; > mary.ietf.barnes@gmail.com; marshall.eubanks@gmail.com > Cc: clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data > structure > > #7: Is composed attribute a boolean or data structure > > Changes (by mary.ietf.barnes@.): > > * status: new => closed > * resolution: => fixed > > > Old description: > > > Need to determine WG consensus as to whether the composed attribute > is > > a boolean (currently in the framework) or whether it should be a data > > structure describing the composed image. > > (Note: this ticket is a result of closing Issue #2). > > New description: > > Need to determine WG consensus as to whether the composed attribute is > a boolean (currently in the framework) or whether it should be a data > structure describing the composed image. > (Note: this ticket is a result of closing Issue #2). > > Proposal to close ticket with conclusion that composed attribute is a > boolean on March 9th: > http://www.ietf.org/mail-archive/web/clue/current/msg01172.html > > Confirmed at IETF-83 (chart 9): > http://www.ietf.org/proceedings/83/slides/slides-83-clue-2.pptx > > -- > > -- > --------------------------------+-------------------------------------- > - > --------------------------------+--- > Reporter: mary.ietf.barnes@. | Owner: draft-ietf-clue- > framework@. > Type: task | Status: closed > Priority: major | Milestone: > Component: framework | Version: > Severity: Active WG Document | Resolution: fixed > Keywords: | > --------------------------------+-------------------------------------- > - > --------------------------------+--- > > Ticket URL: > > clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_0088_01CD1779.1DA16310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am OK with how you phrased it now. I did not see the second bullet = as the outcome of closing this issue since the thread had it but not = reflected as a WG consensus. I think that when closing an issue we = should also be clear about what was the outcome as agreed by the = WG.

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: = Tuesday, April 10, 2012 6:48 PM
To: Roni Even
Cc: = marshall.eubanks@gmail.com; clue@ietf.org
Subject: Re: [clue] = #7: Is composed attribute a boolean or data = structure

 

I (as chair) = updated the text in the issue tracker to reflect the closure - pointing = to email thread and to the chart that Mark presented which proposed the = following:

•Propose Ticket = #7 be closed, keep “composed” as a boolean = attribute

•Add clarifying = text for the attribute and for examples, that information like = “loudest panel stream plus PiPs” cannot be conveyed using = these simple attributes

 

Is this not sufficient and if not what do you propose? =  Are you asking that the change be done before we close the = ticket? 

 

Mary. 

On Tue, Apr 10, 2012 at 10:32 AM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi Mary,
This is a = procedural question
I am wondering how the conclusion is tracked. I = understand that closing the issue should result update to the text in = the framework. So where is this conclusion appears as a summary by the = WG chairs.

Roni


> -----Original Message-----
> From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On = Behalf Of

> clue issue = tracker
> Sent: Tuesday, April 10, 2012 4:18 PM
> To: draft-ietf-clue-= framework@tools.ietf.org;
> mary.ietf.barnes@gmail.com= ; marshall.eubanks@gmail.com=
> Cc: clue@ietf.org

=

> Subject: Re: [clue] #7: Is composed = attribute a boolean or data
> structure
>
> #7: Is = composed attribute a boolean or data structure
>
> Changes = (by mary.ietf.barnes@…):
>
>  * status:  new = =3D> closed
>  * resolution:   =3D> = fixed
>
>
> Old description:
>
> > Need = to determine WG consensus as to whether the composed attribute
> = is
> > a boolean (currently in the framework) or whether it = should be a data
> > structure describing the composed = image.
> > (Note: this ticket is a result of closing Issue = #2).
>
> New description:
>
>  Need to = determine WG consensus as to whether the composed attribute is
> a =  boolean (currently in the framework) or whether it should be a = data
> structure describing the composed image.
> =  (Note: this ticket is a result of closing Issue = #2).
>
>  Proposal to close ticket with conclusion that = composed attribute is a
> boolean on March 9th:
>  http://www.ietf.org/mail-archive/web/clue/current/msg01= 172.html
>
>  Confirmed at IETF-83 (chart = 9):
>  http://www.ietf.org/proceedings/83/slides/slides-83-clu= e-2.pptx
>
> --
>
> --
> = --------------------------------+--------------------------------------> -

> = --------------------------------+---

>  Reporter:  mary.ietf.barnes@… =  |       Owner:  draft-ietf-clue-
> = framework@…

> =      Type:  task           =      |      Status:  closed
> =  Priority:  major             =   |   Milestone:
> Component:  framework   =         |     Version:
> =  Severity:  Active WG Document  |  Resolution: =  fixed
>  Keywords:           =            |
> = --------------------------------+--------------------------------------> -

> = --------------------------------+---

> = _______________________________________________
> clue mailing = list
> clue@ietf.org
> = https://www.ietf.org/mailman/listinfo/clue

 

------=_NextPart_000_0088_01CD1779.1DA16310-- From eckelcu@cisco.com Tue Apr 10 14:54:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F3511E80B5 for ; Tue, 10 Apr 2012 14:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGSeHj62P7Wy for ; Tue, 10 Apr 2012 14:54:14 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id EEE4811E812C for ; Tue, 10 Apr 2012 14:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=7462; q=dns/txt; s=iport; t=1334094853; x=1335304453; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=B3VrXzTz7eJzcyyxuIS2R8kK7B94K8XbUBEBENJ2AI8=; b=Nyehz4gczfI3RyVijr7rqscU6UZHNWkD/phDkALBaIQnS96FQiaqi/rT Q+4dzKQqvFbVp3Rw+aUc/8MrlbkPkt/xV2eVXtvoXxEjR0ddauzoSq/ns +RfnukeHD5LX7NUt7D5aRWYK2OQMXTgcCod+2a5v19Qiz3AkPTydZfk7B w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPyqhE+rRDoG/2dsb2JhbABFDrktgQeCCQEBAQMBAQEBDwEdCi4EAgQEAwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIGodnBAELmkWgMASPfmMEiFqbX4FpgjBX X-IronPort-AV: E=Sophos;i="4.75,401,1330905600"; d="scan'208";a="39931105" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 Apr 2012 21:54:10 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3ALsAKf026597; Tue, 10 Apr 2012 21:54:10 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 14:54:09 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2012 14:54:08 -0700 Message-ID: In-Reply-To: <20120410210921.GM13841@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Does framework provide sufficient info for receiver? Thread-Index: Ac0XXjfaI5R6JZVISoePWOl+c5OzqgABX/6w References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> From: "Charles Eckel (eckelcu)" To: "John Leslie" , "Paul Kyzivat" X-OriginalArrivalTime: 10 Apr 2012 21:54:09.0505 (UTC) FILETIME=[75422510:01CD1764] Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:54:16 -0000 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > John Leslie > Sent: Tuesday, April 10, 2012 2:09 PM > To: Paul Kyzivat > Cc: CLUE > Subject: Re: [clue] Does framework provide sufficient info for > receiver? >=20 > Paul Kyzivat wrote: > > > > The fundamental problem in the scope of CLUE is, if you are an > > endpoint, and you have received an advertisement, with some scenes > > and captures, do you have sufficient information to select and map > > the advertised scenes/captures onto the equipment you have? >=20 > Of course not! >=20 > If we wanted that, we'd have to include for every composed scene > what it's composed from, and for every mixed audio what it's mixed > from. Exactly, and that is what I was expecting to get out of framework provided by CLUE. This was the comment I made in Paris. If the CLUE WG has determined this is out of scope, then I will go elsewhere for this. Sorry I was not able to attend the design team meeting today. It seems this subject was discussed, and I see the update on the tracker, but I do not understand the outcome. Did the group decide it is out of scope, or that more discussion is needed? Cheers, Charles =20 > > If you have sufficient equipment (displays, speakers) with compatible > > geometry to directly map all of the captures from one audio and one > > video capture scene entry from each capture scene then maybe all is > > good. In this case ISTM that the mixed/composed attributes aren't > > needed. >=20 > It's unlikely that the "typical" telepresence conference will have > a separate screen for every possible video. >=20 > Of course, the number of "capture scenes" _could_ be small enough > to give each it's own video monitor -- but I don't think that's the > general case we should design for. >=20 > OTOH, with an appropriate "surround-sound" system, you can "place" > an arbitrarily large number of audio streams, yet make them easy to > distinguish. >=20 > > If you don't have sufficient equipment to do that, then the job is > > harder, and more information is needed to figure out what to do. >=20 > Only marginally harder... >=20 > > For instance: > > > > - If you don't have suitable displays, then perhaps you can select a > > video capture scene entry and locally compose or switch some of the > > captures in order to produce a set of captures that does map to the > > available displays. The area of capture of each capture could be > helpful > > to doing this, and perhaps the composed attribute as well. >=20 > One inevitable use case is filing your formal report from the > airport. > The person doing so will have lousy audio, vastly inadequate video, and > typically inadequate bandwidth with excessive latency. S/he will need > some middlebox to compose a "barely-adequate video" and mono audio. >=20 > Then there's the use case of filing you formal report from your home > office (when you're sick or somebody doesn't want to pay travel cost). > You may well have surround-sound and two or three large monitors, 20 > Mbps > download with 40 msec RTT, and a decent-quality lavalier mike. You > still > probably want some middlebox to compose your basic video, but you can > take individual streams as well to concentrate on particular people. >=20 > Near the top end are the corporate telepresence rooms. They will > want all streams, and are likely to have a human being mixing them. >=20 > > - or rather than compose to fit your displays, you could switch... >=20 > Folks _will_ do that -- I can't stop them. But I find it > uninteresting. >=20 > > - handling video from multiple scenes probably presents some added > > issues. By definition there is no specified spatial relationship > between > > the captures of different scenes... >=20 > Nonetheless, the participants will want to imagine such a > relationship. >=20 > > - If you don't have sufficient speakers for all of the audio > captures, > > then you have to decide to mix, switch, or drop some. >=20 > There really isn't any such thing as "sufficient speakers", but > surround-sound should be considered "sufficient". You can always mix to > stereo or even mono: "you pays your money and you takes your choice". >=20 > > The spatial information from the captures may help in deciding how to > > mix. >=20 > Absolutely! >=20 > > Not evident that the mixed attribute helps with this >=20 > It help you know when mixing is less likely to work well. >=20 > > - unless it is used to decide to switch rather than mix. >=20 > I'm not sure there is any such thing. "Mixing" frequently includes > "riding gain" to reduce background noise. Binary switching is just a > bad idea. >=20 > > Of course if you are mapping independent audio captures onto > different > > speakers then they are being implicitly mixed. >=20 > Not a useful way to think about it, IMHO. Human ears and brains can > sort out individual sources if there are enough speakers, while mixing > makes that harder. >=20 > > - If you don't have speakers with similar spatial relationship to > > those of the audio captures, then you must decide whether to do > > sub-optimal assignments or mix. >=20 > I suppose _some_ telepresence system will hide dozens of speakers > in the telepresence room and try to do this -- to me it sounds like a > dreadful idea, but it's quite possible the people will adapt. >=20 > "Sub-optimal" really doesn't have a clear meaning here. Even > speakers > in the "wrong" left-to-right order while you can see the "correct" > order > on-screen won't confuse the listener as much as speaker assignments > changing for no obvious reason. >=20 > > Again not clear if the mixed attribute helps with this. >=20 > As an extreme example, you could always render "mixed" in mono. >=20 > > - If you have audio from more than one scene, what should you do with > > it? Should you mix, even though you have no spatial relationships? >=20 > IMHO, you should _invent_ a spatial relationship in that case. Even > if each room invents a different spatial relationship, it will prove > less confusing. >=20 > > Or should you switch based on active speaker? >=20 > Only if background-noise is a serious problem. >=20 > > What would help you to decide? >=20 > It becomes quickly obvious to the listener! >=20 > > The problems are superficially different for MCUs. But perhaps only > > superficially. It seems to me that when the MCU decides how to map > its > > inputs into its advertisement, it has some virtual room layouts in > mind. >=20 > I would expect so. >=20 > > So for each virtual room layout it is addressing the same issues as a > > real endpoint with that layout. But it does have the added problem of > > deciding how to describe what it is advertising - e.g. when to apply > > the mixed/composed attributes. >=20 > Pretty much always, unless it's feeding an exact copy of what it > receives. >=20 > > Some interesting use cases for all of the above would be very > helpful. >=20 > Did the cases I listed help? >=20 > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Apr 11 08:05:44 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D580A11E815C for ; Wed, 11 Apr 2012 08:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLxRfCCjS1bY for ; Wed, 11 Apr 2012 08:05:43 -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 82F8311E815B for ; Wed, 11 Apr 2012 08:05:43 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta13.westchester.pa.mail.comcast.net with comcast id wexE1i0011uE5Es5Df5jpc; Wed, 11 Apr 2012 15:05:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id wf5j1i00X07duvL3cf5j3s; Wed, 11 Apr 2012 15:05:43 +0000 Message-ID: <4F859DC6.7000303@alum.mit.edu> Date: Wed, 11 Apr 2012 11:05:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: John Leslie References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> In-Reply-To: <20120410210921.GM13841@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:05:45 -0000 Hi John, Thanks for the comments. I've followed up inline. On 4/10/12 5:09 PM, John Leslie wrote: > Paul Kyzivat wrote: >> >> The fundamental problem in the scope of CLUE is, if you are an >> endpoint, and you have received an advertisement, with some scenes >> and captures, do you have sufficient information to select and map >> the advertised scenes/captures onto the equipment you have? > > Of course not! > > If we wanted that, we'd have to include for every composed scene > what it's composed from, and for every mixed audio what it's mixed > from. I think you must have misunderstood me. Otherwise I wouldn't expect you to answer "Of course not". AFAIK the whole point of CLUE is to provide the information to make this possible. My point in asking the question was so that we can identify what information we have overlooked that we need to include one way or another. Clearly there are some tradeoffs. More information might support *better* mappings. So one thing to decide is how good is good enough. >> If you have sufficient equipment (displays, speakers) with compatible >> geometry to directly map all of the captures from one audio and one >> video capture scene entry from each capture scene then maybe all is >> good. In this case ISTM that the mixed/composed attributes aren't >> needed. > > It's unlikely that the "typical" telepresence conference will have > a separate screen for every possible video. That isn't what I said. Consider what is perhaps a typical case, where the advertisement contains one scene with several alternative video and audio scene entries. Lets just consider the video. Then maybe there is one entry with three captures, and another with one (mixed/switched, whatever) capture. Then if you have three screens you can map all three captures in the first entry. If you have less than three screens then you can map the one capture from the 2nd entry onto one of your screens. But what if there was no entry with a single capture? If you had two screens, would you have enough info about the three captures in the first entry to make a reasonable mapping onto your two screens? What information would we need to include in the advertisement so that it would be possible to do this mapping well? > Of course, the number of "capture scenes" _could_ be small enough > to give each it's own video monitor -- but I don't think that's the > general case we should design for. IIUC an endpoint will typically only advertise one or two scenes. One would correspond to the cameras and mics in its room. The other, if present, would correspond to a "presentation" that doesn't fit into the coordinate space of the room. There are cases for more, but they get more obscure. So for a point-to-point clue call the recipient will only need to map one or two scenes. But when there is more than one it is more complex, requiring sharing of equipment. The situation is more complex for an MCU. It will have as input all the scenes offered by all the endpoints. It then has to decide what to offer out to the endpoints. It could just pass through all the scenes it receives from all the endpoints, leaving the mapping problem entirely to the endpoints. (I don't think that is what most people have in mind, though some might.) Or it could take on itself the job of mapping/mixing/switching all of those inputs and producing something more like what a typical endpoint would advertise - one or two scenes each with just a few captures. Or it could do both - advertise its own simplified composite scenes and also all those provided by the endpoints. That would allow the endpoints to either take the easy way out, or else do it all themselves in a way that suits them. Suppose it did this. Would the endpoints that want to take the easy way be able to figure out which scenes and captures to use? > OTOH, with an appropriate "surround-sound" system, you can "place" > an arbitrarily large number of audio streams, yet make them easy to > distinguish. > >> If you don't have sufficient equipment to do that, then the job is >> harder, and more information is needed to figure out what to do. > > Only marginally harder... > >> For instance: >> >> - If you don't have suitable displays, then perhaps you can select a >> video capture scene entry and locally compose or switch some of the >> captures in order to produce a set of captures that does map to the >> available displays. The area of capture of each capture could be helpful >> to doing this, and perhaps the composed attribute as well. > > One inevitable use case is filing your formal report from the airport. > The person doing so will have lousy audio, vastly inadequate video, and > typically inadequate bandwidth with excessive latency. S/he will need > some middlebox to compose a "barely-adequate video" and mono audio. This is indeed an interesting case - one we have explicitly put in scope. If an MCU is already in the call then perhaps we can hope that is one of the entries it makes available. If there isn't any MCU in the call, then the other endpoint might not advertise that option. Then what? Do we have a mechanism for that? > Then there's the use case of filing you formal report from your home > office (when you're sick or somebody doesn't want to pay travel cost). > You may well have surround-sound and two or three large monitors, 20 Mbps > download with 40 msec RTT, and a decent-quality lavalier mike. You still > probably want some middlebox to compose your basic video, but you can > take individual streams as well to concentrate on particular people. > > Near the top end are the corporate telepresence rooms. They will > want all streams, and are likely to have a human being mixing them. I don't understand your point "are likely to have a human being mixing them". Can you explain further? >> - or rather than compose to fit your displays, you could switch... > > Folks _will_ do that -- I can't stop them. But I find it uninteresting. ??? We have been talking about switching a lot. Are you saying that is uninteresting? If it makes sense for a middlebox to switch, doesn't it make equal sense for an endpoint to do so? >> - handling video from multiple scenes probably presents some added >> issues. By definition there is no specified spatial relationship between >> the captures of different scenes... > > Nonetheless, the participants will want to imagine such a relationship. ISTM that this needs further discussion. >> - If you don't have sufficient speakers for all of the audio captures, >> then you have to decide to mix, switch, or drop some. > > There really isn't any such thing as "sufficient speakers", but > surround-sound should be considered "sufficient". You can always mix to > stereo or even mono: "you pays your money and you takes your choice". Do we have enough information to do it "right" or "well"? Right now the coordinate info is all optional. Does it need to be mandatory in order to enable this? >> The spatial information from the captures may help in deciding how to >> mix. > > Absolutely! > >> Not evident that the mixed attribute helps with this > > It help you know when mixing is less likely to work well. > >> - unless it is used to decide to switch rather than mix. > > I'm not sure there is any such thing. "Mixing" frequently includes > "riding gain" to reduce background noise. Binary switching is just a > bad idea. I have no special understanding of this. I'm just asking probing questions in hopes that it will result in the right decisions being made and the right stuff specified. >> Of course if you are mapping independent audio captures onto different >> speakers then they are being implicitly mixed. > > Not a useful way to think about it, IMHO. Human ears and brains can > sort out individual sources if there are enough speakers, while mixing > makes that harder. I have had the impression that "simple" clue telepresence rooms would be hoping to do direct mapping of captures to devices. If the assumption is that this will be an unsatisfactory approach and all endpoints should be prepared to do something more complex then it would be helpful to write that down somewhere - e.g. in the framework. >> - If you don't have speakers with similar spatial relationship to >> those of the audio captures, then you must decide whether to do >> sub-optimal assignments or mix. > > I suppose _some_ telepresence system will hide dozens of speakers > in the telepresence room and try to do this -- to me it sounds like a > dreadful idea, but it's quite possible the people will adapt. > > "Sub-optimal" really doesn't have a clear meaning here. Even speakers > in the "wrong" left-to-right order while you can see the "correct" order > on-screen won't confuse the listener as much as speaker assignments > changing for no obvious reason. > >> Again not clear if the mixed attribute helps with this. > > As an extreme example, you could always render "mixed" in mono. > >> - If you have audio from more than one scene, what should you do with >> it? Should you mix, even though you have no spatial relationships? > > IMHO, you should _invent_ a spatial relationship in that case. Even > if each room invents a different spatial relationship, it will prove > less confusing. > >> Or should you switch based on active speaker? > > Only if background-noise is a serious problem. > >> What would help you to decide? > > It becomes quickly obvious to the listener! > >> The problems are superficially different for MCUs. But perhaps only >> superficially. It seems to me that when the MCU decides how to map its >> inputs into its advertisement, it has some virtual room layouts in mind. > > I would expect so. > >> So for each virtual room layout it is addressing the same issues as a >> real endpoint with that layout. But it does have the added problem of >> deciding how to describe what it is advertising - e.g. when to apply >> the mixed/composed attributes. > > Pretty much always, unless it's feeding an exact copy of what it > receives. Since I've seen people here describe cases when that isn't so, it would be helpful to have a more precise definition. >> Some interesting use cases for all of the above would be very helpful. > > Did the cases I listed help? I think they need to be worked out in much more detail: - what equipment (input and output) is in each endpoint, and where. - what is advertised and how the input equipment is mapped to the advertisement - how each endpoint maps the advertised captures to its output equipment together with how the info in the advertisement allowed it to determine that mapping. Thanks, Paul From mary.ietf.barnes@gmail.com Wed Apr 11 08:34:34 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A9C11E8074 for ; Wed, 11 Apr 2012 08:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.614 X-Spam-Level: X-Spam-Status: No, score=-103.614 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bREcLfQTuwKv for ; Wed, 11 Apr 2012 08:34:33 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF98411E8085 for ; Wed, 11 Apr 2012 08:34:32 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so824423vbb.31 for ; Wed, 11 Apr 2012 08:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hFomDcO8I3cwbXHezCxeNTJShzgjEOTgkSRZ1MhYXH0=; b=f6xTpcaEREUqL3bp+oVVSy5pS6On2yaHoEtYIQIDDJN9qeXjNBl72cp+8BbQw6Xok9 4dMZErChwVdeIlqHOQwYWT0Gbu8Go6no8m2BHmhWEdiW5mlmk1cjRM0qR3ZFg2OO8r2h 5sXzY7KPpsdsyvb+hHjpDP8928v7JUzdnLb2/RTmhNIWKJGflR3dV8iOmgVkjr1fucan Zmw56Bda7EqWV51AmUZ1lOcPf7L5QR2XxuZI1PDjDUdHK72EYxT/guSAdq4fJeqTM1IH 6LSQ1CzOAShaczuINdvjh9lUqSnyCq7J0mOPxLQ0hu5keq37RVmqa5oEpmIGcGcVXIEs uRhw== MIME-Version: 1.0 Received: by 10.220.58.197 with SMTP id i5mr7957209vch.38.1334158472417; Wed, 11 Apr 2012 08:34:32 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Wed, 11 Apr 2012 08:34:32 -0700 (PDT) In-Reply-To: <4f84a4cb.8661b40a.377d.ffffb0bb@mx.google.com> References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> <083.0f61a255e64e6f1a288dafab8141842b@trac.tools.ietf.org> <4f8452f3.6965b40a.256d.20ce@mx.google.com> <4f84a4cb.8661b40a.377d.ffffb0bb@mx.google.com> Date: Wed, 11 Apr 2012 10:34:32 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=0023544477cdd292f704bd68f984 Cc: clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:34:34 -0000 --0023544477cdd292f704bd68f984 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yeah, there's a balance between how much information you should regurgitate in the issue tracker and the risk of information getting out of sync. My preference (and what I stated early on) is that we just include links to relevant information since it's a necessity that the information be on the mailing list and/or in meeting materials and then we don't have to add a bunch of stuff to the issue tracker. To me the issue tracker is merely a convenience in keeping a list of ongoing issues so we don't lose track rather than being a repository of information. Mary. On Tue, Apr 10, 2012 at 4:21 PM, Roni Even wrote: > Hi,**** > > I am OK with how you phrased it now. I did not see the second bullet as > the outcome of closing this issue since the thread had it but not reflect= ed > as a WG consensus. I think that when closing an issue we should also be > clear about what was the outcome as agreed by the WG.**** > > Roni**** > > ** ** > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Tuesday, April 10, 2012 6:48 PM > *To:* Roni Even > *Cc:* marshall.eubanks@gmail.com; clue@ietf.org > > *Subject:* Re: [clue] #7: Is composed attribute a boolean or data > structure**** > > ** ** > > I (as chair) updated the text in the issue tracker to reflect the closure > - pointing to email thread and to the chart that Mark presented which > proposed the following:**** > > =95Propose Ticket #7 be closed, keep =93composed=94 as a boolean attribut= e**** > > =95Add clarifying text for the attribute and for examples, that informati= on > like =93loudest panel stream plus PiPs=94 cannot be conveyed using these = simple > attributes**** > > ** ** > > Is this not sufficient and if not what do you propose? Are you asking > that the change be done before we close the ticket? **** > > ** ** > > Mary. **** > > On Tue, Apr 10, 2012 at 10:32 AM, Roni Even > wrote:**** > > Hi Mary, > This is a procedural question > I am wondering how the conclusion is tracked. I understand that closing > the issue should result update to the text in the framework. So where is > this conclusion appears as a summary by the WG chairs. > > Roni**** > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of= * > *** > > > clue issue tracker > > Sent: Tuesday, April 10, 2012 4:18 PM > > To: draft-ietf-clue-framework@tools.ietf.org; > > mary.ietf.barnes@gmail.com; marshall.eubanks@gmail.com > > Cc: clue@ietf.org**** > > > Subject: Re: [clue] #7: Is composed attribute a boolean or data > > structure > > > > #7: Is composed attribute a boolean or data structure > > > > Changes (by mary.ietf.barnes@=85): > > > > * status: new =3D> closed > > * resolution: =3D> fixed > > > > > > Old description: > > > > > Need to determine WG consensus as to whether the composed attribute > > is > > > a boolean (currently in the framework) or whether it should be a data > > > structure describing the composed image. > > > (Note: this ticket is a result of closing Issue #2). > > > > New description: > > > > Need to determine WG consensus as to whether the composed attribute is > > a boolean (currently in the framework) or whether it should be a data > > structure describing the composed image. > > (Note: this ticket is a result of closing Issue #2). > > > > Proposal to close ticket with conclusion that composed attribute is a > > boolean on March 9th: > > http://www.ietf.org/mail-archive/web/clue/current/msg01172.html > > > > Confirmed at IETF-83 (chart 9): > > http://www.ietf.org/proceedings/83/slides/slides-83-clue-2.pptx > > > > -- > > > > -- > > --------------------------------+-------------------------------------- > > -**** > > > --------------------------------+---**** > > > Reporter: mary.ietf.barnes@=85 | Owner: draft-ietf-clue- > > framework@=85**** > > > Type: task | Status: closed > > Priority: major | Milestone: > > Component: framework | Version: > > Severity: Active WG Document | Resolution: fixed > > Keywords: | > > --------------------------------+-------------------------------------- > > -**** > > > --------------------------------+---**** > > > > > Ticket URL: > > > > clue > >**** > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --0023544477cdd292f704bd68f984 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yeah, there's a balance between how much information you should regurgi= tate in the issue tracker and the risk of information getting out of sync. = =A0My preference (and what I stated early on) is that we just include links= to relevant information since it's a necessity that the information be= on the mailing list and/or in meeting materials and then we don't have= to add a bunch of stuff to the issue tracker. =A0To me the issue tracker i= s merely a convenience in keeping a list of ongoing issues so we don't = lose track rather than being a repository of information.=A0

Mary. =A0

On Tue, Apr 10, = 2012 at 4:21 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi,

I am OK with how you phrased it now. I di= d not see the second bullet as the outcome of closing this issue since the = thread had it but not reflected as a WG consensus. I think that when closin= g an issue we should also be clear about what was the outcome as agreed by = the WG.

Roni=

=A0

From:= Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Tuesday, April 10, 2012 6:48 PM
To: Roni Even
= Cc: mar= shall.eubanks@gmail.com; clue@ietf.org


Subject: Re: [clue] #7: Is com= posed attribute a boolean or data structure

=A0

I (as chair) updated the text in the issue tracker t= o reflect the closure - pointing to email thread and to the chart that Mark= presented which proposed the following:

=95Propose Ticket #7 be closed, keep =93com= posed=94 as a boolean attribute

= =95Add clarifying text for the attribute and for examples, t= hat information like =93loudest panel stream plus PiPs=94 cannot be conveye= d using these simple attributes

=A0

Is this not sufficient and if not what do you propose? = =A0Are you asking that the change be done before we close the ticket?=A0=

=A0

Mary.=A0

On Tue, Apr 10, 2012 at 10:32 AM, Roni Even <ron.even.tlv@gmai= l.com> wrote:

Hi Mary,
This is a procedural question
I am wo= ndering how the conclusion is tracked. I understand that closing the issue = should result update to the text in the framework. So where is this conclus= ion appears as a summary by the WG chairs.

Roni


> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf Of

> clue issue tracker
> Sent: Tue= sday, April 10, 2012 4:18 PM
> To: draft-ietf-clue-framework@tools= .ietf.org;
> mary.i= etf.barnes@gmail.com; marshall.eubanks@gmail.com
> Cc: clue@ietf.org

> Subject: Re: [clue] #7: Is comp= osed attribute a boolean or data
> structure
>
> #7: Is c= omposed attribute a boolean or data structure
>
> Changes (by m= ary.ietf.barnes@=85):
>
> =A0* status: =A0new =3D> closed
> =A0* resolution: = =A0 =3D> fixed
>
>
> Old description:
>
> = > Need to determine WG consensus as to whether the composed attribute> is
> > a boolean (currently in the framework) or whether it should be a = data
> > structure describing the composed image.
> > (No= te: this ticket is a result of closing Issue #2).
>
> New descr= iption:
>
> =A0Need to determine WG consensus as to whether the composed a= ttribute is
> a =A0boolean (currently in the framework) or whether it= should be a data
> structure describing the composed image.
> = =A0(Note: this ticket is a result of closing Issue #2).
>
> =A0Proposal to close ticket with conclusion that composed attr= ibute is a
> boolean on March 9th:
> =A0http= ://www.ietf.org/mail-archive/web/clue/current/msg01172.html
>
> =A0Confirmed at IETF-83 (chart 9):
> =A0http://www.ietf.org/proceedings/83/slides/slides-83-clue-2.pptx
&= gt;
> --
>
> --
> --------------------------------+-------= -------------------------------
> -

> --------------------------------+---<= /p>

> =A0Reporter: =A0mary.ietf.barnes@=85 =A0| = =A0 =A0 =A0 Owner: =A0draft-ietf-clue-
> framework@=85<= /p>

> =A0 =A0 =A0Type: =A0task =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0closed
> =A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
= > Component: =A0framework =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
>= =A0Severity: =A0Active WG Document =A0| =A0Resolution: =A0fixed
> = =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> ---------= -----------------------+--------------------------------------
> -

> -----------------= ---------------+---

=

> ___________= ____________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

=A0

<= /div>

--0023544477cdd292f704bd68f984-- From espeberg@cisco.com Wed Apr 11 09:55:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0AA21F84D8 for ; Wed, 11 Apr 2012 09:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhDhfQac1TtU for ; Wed, 11 Apr 2012 09:55:20 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E2AC721F84D2 for ; Wed, 11 Apr 2012 09:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=15558; q=dns/txt; s=iport; t=1334163319; x=1335372919; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=j2UQQOIidxugEavFYa6175rx+zi4WlW1Pw1vpKzztI0=; b=dcrxLS3LaJMFQpCZhG4jBbTHph0FyYOReBPSKTKhaIIJN42u8m3nMMto FownTZ9ZCNUf43tdy+40LmZg51MFlq/gkS7iI4UvIa6ce0wKr+r00yD7r +EMdjUXSE2NLILMSdXStW4nLQbNwa7JaD6Shvs9ZJ8k9ODSAjGOvFbuMN A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFO2hU+Q/khN/2dsb2JhbAA5Cg65TYEHggkBAQEDAQEBAQ8BHQouBAIEBAMFBwQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEAQkJCBqHZwULnnGYPgSLIQSFPmMEpDmBaYIwOYFS X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="70605635" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 11 Apr 2012 16:55:17 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3BGtHuO030609; Wed, 11 Apr 2012 16:55:17 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 18:55:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Apr 2012 18:55:16 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> In-Reply-To: <4F859DC6.7000303@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Does framework provide sufficient info for receiver? Thread-Index: Ac0X9JWDDJwV+L/NRDufpoTzrPcK9wABfdhw References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> From: "Espen Berger (espeberg)" To: "Paul Kyzivat" , "John Leslie" X-OriginalArrivalTime: 11 Apr 2012 16:55:17.0610 (UTC) FILETIME=[DF6DDCA0:01CD1803] Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:55:22 -0000 During the CLUE design team meeting on webex yesterday we started to discuss various use cases and if they are in scope or not for the current work in CLUE.=20 As a part of my response to Pauls questions I summarized the use cases and grouped them into supported / not supported. I can dive into more detail about the use cases if people are interested? I would answer yes to the following use cases=20 * Telepresence point to point, where the reproduction will happen in a 2D-plane for audio and video. Currently CLUE support announcing capability of sending 1 - N capture (left to right) and a receiver can request 1 - M streams for rendering (left to tight), which is the basic for interoperability.=20 * Transcoded conferencing, where the MCU act like an endpoint and logically announces audio and video left to right and a receiver request 1 - M captures depending on how many screen and audio streams you prefer. Typically a single video stream pr. screen and one audio pr. screen (mono/stereo). Excluded is capabilities to select individual speakers, the MCU is free to optimize what to compose and send to a receiver. * Generic multi source, sending and receiving named sources where the user experience is controlled by an human being capable of reading sources names, or control software written explicit to operate on the named streams. The content attribute can be used to indicate a primary role, RFC4796 uses 'main' and 'alt'.=20 I would answer no, to the following use cases=20 * Switched conferencing, where we assume that endpoints do scalable video (either SVC or Simulcast), locally composited layout and audio mixing. Limited work has been done on how to use Scalable video and how to build mechanisms for complete composited layouts.=20 * Advanced audio reproduction, a group of audio scenarios mentioned by Jon Leslie and Johan Nielsen that requires more details during initial signalling and more dynamic information for transferring dynamic meta-information. =20 * Multi view, as described in the CLUE use case document.=20 (Other comments inline.) Cheers=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 11. april 2012 17:06 To: John Leslie Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? Hi John, Thanks for the comments. I've followed up inline. On 4/10/12 5:09 PM, John Leslie wrote: > Paul Kyzivat wrote: >> >> The fundamental problem in the scope of CLUE is, if you are an=20 >> endpoint, and you have received an advertisement, with some scenes=20 >> and captures, do you have sufficient information to select and map=20 >> the advertised scenes/captures onto the equipment you have? > > Of course not! > > If we wanted that, we'd have to include for every composed scene=20 > what it's composed from, and for every mixed audio what it's mixed=20 > from. I think you must have misunderstood me. Otherwise I wouldn't expect you to answer "Of course not". AFAIK the whole point of CLUE is to provide the information to make this possible. My point in asking the question was so that we can identify what information we have overlooked that we need to include one way or another. Clearly there are some tradeoffs. More information might support *better* mappings. So one thing to decide is how good is good enough. [Espen] Agree with Paul, we clearly can support in CLUE the use cases where a Telepresence room either offer a 1, 2 or 3 video captures, which can be rendered on 1, 2 or 3 screens.=20 >> If you have sufficient equipment (displays, speakers) with compatible >> geometry to directly map all of the captures from one audio and one=20 >> video capture scene entry from each capture scene then maybe all is=20 >> good. In this case ISTM that the mixed/composed attributes aren't=20 >> needed. > > It's unlikely that the "typical" telepresence conference will have > a separate screen for every possible video. That isn't what I said. Consider what is perhaps a typical case, where the advertisement contains one scene with several alternative video and audio scene entries. Lets just consider the video. Then maybe there is one entry with three captures, and another with one (mixed/switched, whatever) capture. Then if you have three screens you can map all three captures in the first entry. If you have less than three screens then you can map the one capture from the 2nd entry onto one of your screens. But what if there was no entry with a single capture? If you had two screens, would you have enough info about the three captures in the first entry to make a reasonable mapping onto your two screens? What information would we need to include in the advertisement so that it would be possible to do this mapping well? [Espen] How a vendor build a room or endpoint is transparent from the sender of media. As a sender you should not care if a room request 3 audio streams (left, center, right) and choose to mix and play out on a single speaker. We can argue that this is not the best experience, but still valid and typically done for PC-clients or other endpoints with a single speaker.=20 > Of course, the number of "capture scenes" _could_ be small enough=20 > to give each it's own video monitor -- but I don't think that's the=20 > general case we should design for. IIUC an endpoint will typically only advertise one or two scenes. One would correspond to the cameras and mics in its room. The other, if present, would correspond to a "presentation" that doesn't fit into the coordinate space of the room. There are cases for more, but they get more obscure. So for a point-to-point clue call the recipient will only need to map one or two scenes. But when there is more than one it is more complex, requiring sharing of equipment. The situation is more complex for an MCU. It will have as input all the scenes offered by all the endpoints. It then has to decide what to offer out to the endpoints. It could just pass through all the scenes it receives from all the endpoints, leaving the mapping problem entirely to the endpoints. (I don't think that is what most people have in mind, though some might.) Or it could take on itself the job of mapping/mixing/switching all of those inputs and producing something more like what a typical endpoint would advertise - one or two scenes each with just a few captures. Or it could do both - advertise its own simplified composite scenes and also all those provided by the endpoints. That would allow the endpoints to either take the easy way out, or else do it all themselves in a way that suits them. Suppose it did this. Would the endpoints that want to take the easy way be able to figure out which scenes and captures to use? [Espen] This sounds closer to a user experience discussions than a protocol discussion.=20 > OTOH, with an appropriate "surround-sound" system, you can "place" > an arbitrarily large number of audio streams, yet make them easy to=20 > distinguish. > >> If you don't have sufficient equipment to do that, then the job is=20 >> harder, and more information is needed to figure out what to do. > > Only marginally harder... > >> For instance: >> >> - If you don't have suitable displays, then perhaps you can select a=20 >> video capture scene entry and locally compose or switch some of the=20 >> captures in order to produce a set of captures that does map to the=20 >> available displays. The area of capture of each capture could be=20 >> helpful to doing this, and perhaps the composed attribute as well. > > One inevitable use case is filing your formal report from the airport. > The person doing so will have lousy audio, vastly inadequate video,=20 > and typically inadequate bandwidth with excessive latency. S/he will=20 > need some middlebox to compose a "barely-adequate video" and mono audio. This is indeed an interesting case - one we have explicitly put in scope. If an MCU is already in the call then perhaps we can hope that is one of the entries it makes available. If there isn't any MCU in the call, then the other endpoint might not advertise that option. Then what? Do we have a mechanism for that? [Espen] If an MCU detect low bandwidth or packet loss it can start using its normal recovery mechanisms. That could lower bitrate for audio and video (maybe by a SIP re-invite), change the CLUE offer to something that fits inside the available bandwidth. Getting good quality audio ande video is always a challenge, with or without clue.=20 > Then there's the use case of filing you formal report from your=20 > home office (when you're sick or somebody doesn't want to pay travel cost). > You may well have surround-sound and two or three large monitors, 20=20 > Mbps download with 40 msec RTT, and a decent-quality lavalier mike.=20 > You still probably want some middlebox to compose your basic video,=20 > but you can take individual streams as well to concentrate on particular people. > > Near the top end are the corporate telepresence rooms. They will=20 > want all streams, and are likely to have a human being mixing them. I don't understand your point "are likely to have a human being mixing them". Can you explain further? [Espen] I see this as mostly a request for focusing in on particular user. In a transcoded conference you can do that by looking into XCon, if you do switched conference the endpoint typically render the layout and can choose who to focus on. Mixing transcoded and switched conferencing I think makes it unnecessary complex for the initial use cases to cover.=20 >> - or rather than compose to fit your displays, you could switch... > > Folks _will_ do that -- I can't stop them. But I find it uninteresting. ??? We have been talking about switching a lot. Are you saying that is uninteresting? If it makes sense for a middlebox to switch, doesn't it make equal sense for an endpoint to do so? >> - handling video from multiple scenes probably presents some added=20 >> issues. By definition there is no specified spatial relationship=20 >> between the captures of different scenes... > > Nonetheless, the participants will want to imagine such a relationship. ISTM that this needs further discussion. >> - If you don't have sufficient speakers for all of the audio=20 >> captures, then you have to decide to mix, switch, or drop some. > > There really isn't any such thing as "sufficient speakers", but=20 > surround-sound should be considered "sufficient". You can always mix=20 > to stereo or even mono: "you pays your money and you takes your choice". Do we have enough information to do it "right" or "well"? Right now the coordinate info is all optional. Does it need to be mandatory in order to enable this? >> The spatial information from the captures may help in deciding how to >> mix. > > Absolutely! > >> Not evident that the mixed attribute helps with this > > It help you know when mixing is less likely to work well. > >> - unless it is used to decide to switch rather than mix. > > I'm not sure there is any such thing. "Mixing" frequently includes > "riding gain" to reduce background noise. Binary switching is just a=20 > bad idea. I have no special understanding of this. I'm just asking probing questions in hopes that it will result in the right decisions being made and the right stuff specified. >> Of course if you are mapping independent audio captures onto=20 >> different speakers then they are being implicitly mixed. > > Not a useful way to think about it, IMHO. Human ears and brains=20 > can sort out individual sources if there are enough speakers, while=20 > mixing makes that harder. I have had the impression that "simple" clue telepresence rooms would be hoping to do direct mapping of captures to devices. If the assumption is that this will be an unsatisfactory approach and all endpoints should be prepared to do something more complex then it would be helpful to write that down somewhere - e.g. in the framework. [Espen] Agree with Paul here, the basic scenario is well understood. A sends two logical audio captures and a receiver play them out with the same spatial relationship. As rule of thumb here could be that for basic interoperability between vendors you assume pairs of audio and video captures that can be easily rendered on matching pairs of screens and speaker. =20 >> - If you don't have speakers with similar spatial relationship to=20 >> those of the audio captures, then you must decide whether to do=20 >> sub-optimal assignments or mix. > > I suppose _some_ telepresence system will hide dozens of speakers=20 > in the telepresence room and try to do this -- to me it sounds like a=20 > dreadful idea, but it's quite possible the people will adapt. > > "Sub-optimal" really doesn't have a clear meaning here. Even=20 > speakers in the "wrong" left-to-right order while you can see the=20 > "correct" order on-screen won't confuse the listener as much as=20 > speaker assignments changing for no obvious reason. > >> Again not clear if the mixed attribute helps with this. > > As an extreme example, you could always render "mixed" in mono. > >> - If you have audio from more than one scene, what should you do with >> it? Should you mix, even though you have no spatial relationships? > > IMHO, you should _invent_ a spatial relationship in that case.=20 > Even if each room invents a different spatial relationship, it will=20 > prove less confusing. > >> Or should you switch based on active speaker? > > Only if background-noise is a serious problem. > >> What would help you to decide? > > It becomes quickly obvious to the listener! > >> The problems are superficially different for MCUs. But perhaps only=20 >> superficially. It seems to me that when the MCU decides how to map=20 >> its inputs into its advertisement, it has some virtual room layouts in mind. > > I would expect so. > >> So for each virtual room layout it is addressing the same issues as a >> real endpoint with that layout. But it does have the added problem of >> deciding how to describe what it is advertising - e.g. when to apply=20 >> the mixed/composed attributes. > > Pretty much always, unless it's feeding an exact copy of what it=20 > receives. Since I've seen people here describe cases when that isn't so, it would be helpful to have a more precise definition. >> Some interesting use cases for all of the above would be very helpful. > > Did the cases I listed help? I think they need to be worked out in much more detail: - what equipment (input and output) is in each endpoint, and where. - what is advertised and how the input equipment is mapped to the advertisement - how each endpoint maps the advertised captures to its output equipment together with how the info in the advertisement allowed it to determine that mapping. [Espen] Agree, being practical about what we will offer for actual endpoints are useful.=20 Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Wed Apr 11 10:45:27 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E849511E809B for ; Wed, 11 Apr 2012 10:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pmksidUoaTi for ; Wed, 11 Apr 2012 10:45:23 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BEB1911E80B3 for ; Wed, 11 Apr 2012 10:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=15505; q=dns/txt; s=iport; t=1334166323; x=1335375923; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=xTbdRUk7nOGXG7vxMvlSvtPhHe+jEjV1McGEntCvmxw=; b=Hf2eg1FVmI3UEOLa87nM19akYngm7lBtRzNRAlJQb/ueUnDVSH+ZlRNu TYycOVIg6qAtx6VN/P6e12dsISgXtCmdbAOFOP3sP/TItv/bPsZfGC0QL 8a6h558e4l56JntlLp7ZpoBp6Nub183NXtiijSRm7bBzyhxjyBa5Fqszf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAArDhU+rRDoJ/2dsb2JhbABEgkauFwGIcIEHggkBAQEDAQEBAQ8BCREDPgsFBwQCAQgOAwQBAQsGFwEGASAGHwkIAQEEARIIARmHXgMGBAELmn+WSw2JU4orf4U5YwSIWo4jiiiDFIFpgweBPA X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208,217";a="36952845" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 11 Apr 2012 17:45:17 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3BHjHSC028928; Wed, 11 Apr 2012 17:45:17 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 10:45:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD180A.DB68B6D1" Date: Wed, 11 Apr 2012 10:45:14 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0737FA9F@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4f84a4cb.8661b40a.377d.ffffb0bb@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] #7: Is composed attribute a boolean or data structure Thread-Index: Ac0XMVFkU4dZUu08QKylsbLYrIRCIwALifUQACrTDKA= References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> <083.0f61a255e64e6f1a288dafab8141842b@trac.tools.ietf.org> <4f8452f3.6965b40a.256d.20ce@mx.google.com> <4f84a4cb.8661b40a.377d.ffffb0bb@mx.google.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Mary Barnes" X-OriginalArrivalTime: 11 Apr 2012 17:45:17.0473 (UTC) FILETIME=[DB7CA110:01CD180A] Cc: clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:45:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD180A.DB68B6D1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is also how I interpreted the discussion- A =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, April 10, 2012 2:22 PM To: 'Mary Barnes' Cc: clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure =20 Hi, I am OK with how you phrased it now. I did not see the second bullet as the outcome of closing this issue since the thread had it but not reflected as a WG consensus. I think that when closing an issue we should also be clear about what was the outcome as agreed by the WG. Roni =20 From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Sent: Tuesday, April 10, 2012 6:48 PM To: Roni Even Cc: marshall.eubanks@gmail.com; clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure =20 I (as chair) updated the text in the issue tracker to reflect the closure - pointing to email thread and to the chart that Mark presented which proposed the following: *Propose Ticket #7 be closed, keep "composed" as a boolean attribute *Add clarifying text for the attribute and for examples, that information like "loudest panel stream plus PiPs" cannot be conveyed using these simple attributes =20 Is this not sufficient and if not what do you propose? Are you asking that the change be done before we close the ticket?=20 =20 Mary.=20 On Tue, Apr 10, 2012 at 10:32 AM, Roni Even wrote: Hi Mary, This is a procedural question I am wondering how the conclusion is tracked. I understand that closing the issue should result update to the text in the framework. So where is this conclusion appears as a summary by the WG chairs. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > clue issue tracker > Sent: Tuesday, April 10, 2012 4:18 PM > To: draft-ietf-clue-framework@tools.ietf.org; > mary.ietf.barnes@gmail.com; marshall.eubanks@gmail.com > Cc: clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data > structure > > #7: Is composed attribute a boolean or data structure > > Changes (by mary.ietf.barnes@...): > > * status: new =3D> closed > * resolution: =3D> fixed > > > Old description: > > > Need to determine WG consensus as to whether the composed attribute > is > > a boolean (currently in the framework) or whether it should be a data > > structure describing the composed image. > > (Note: this ticket is a result of closing Issue #2). > > New description: > > Need to determine WG consensus as to whether the composed attribute is > a boolean (currently in the framework) or whether it should be a data > structure describing the composed image. > (Note: this ticket is a result of closing Issue #2). > > Proposal to close ticket with conclusion that composed attribute is a > boolean on March 9th: > http://www.ietf.org/mail-archive/web/clue/current/msg01172.html > > Confirmed at IETF-83 (chart 9): > http://www.ietf.org/proceedings/83/slides/slides-83-clue-2.pptx > > -- > > -- > --------------------------------+-------------------------------------- > - > --------------------------------+--- > Reporter: mary.ietf.barnes@... | Owner: draft-ietf-clue- > framework@... > Type: task | Status: closed > Priority: major | Milestone: > Component: framework | Version: > Severity: Active WG Document | Resolution: fixed > Keywords: | > --------------------------------+-------------------------------------- > - > --------------------------------+--- > > Ticket URL: > > clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CD180A.DB68B6D1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is also how I interpreted the = discussion-

A

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Tuesday, April 10, 2012 2:22 PM
To: 'Mary Barnes'
Cc: clue@ietf.org
Subject: Re: [clue] #7: Is composed attribute a boolean or data structure

 

Hi,

I am OK with how you phrased it now. I did not see the = second bullet as the outcome of closing this issue since the thread had it but = not reflected as a WG consensus. I think that when closing an issue we = should also be clear about what was the outcome as agreed by the = WG.

Roni

 

From:= Mary = Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Tuesday, April 10, 2012 6:48 PM
To: Roni Even
Cc: marshall.eubanks@gmail.com; clue@ietf.org
Subject: Re: [clue] #7: Is composed attribute a boolean or data structure

 

I (as chair) updated the text in the issue tracker = to reflect the closure - pointing to email thread and to the chart that = Mark presented which proposed the following:

•Propose Ticket = #7 be closed, keep “composed” as a boolean = attribute

•Add clarifying = text for the attribute and for examples, that information like “loudest = panel stream plus PiPs” cannot be conveyed using these simple = attributes

 

Is this not sufficient and if not what do you = propose?  Are you asking that the change be done before we close the = ticket? 

 

Mary. 

On Tue, Apr 10, 2012 at 10:32 AM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi Mary,
This is a procedural question
I am wondering how the conclusion is tracked. I understand that closing = the issue should result update to the text in the framework. So where is = this conclusion appears as a summary by the WG chairs.

Roni


> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of

> clue issue tracker
> Sent: Tuesday, April 10, 2012 4:18 PM
> To: draft-ietf-clue-= framework@tools.ietf.org;
> mary.ietf.barnes@gmail.com= ; marshall.eubanks@gmail.com=
> Cc: clue@ietf.org

> Subject: Re: [clue] #7: Is composed attribute = a boolean or data
> structure
>
> #7: Is composed attribute a boolean or data structure
>
> Changes (by mary.ietf.barnes@…):
>
>  * status:  new =3D> closed
>  * resolution:   =3D> fixed
>
>
> Old description:
>
> > Need to determine WG consensus as to whether the composed = attribute
> is
> > a boolean (currently in the framework) or whether it should be = a data
> > structure describing the composed image.
> > (Note: this ticket is a result of closing Issue #2).
>
> New description:
>
>  Need to determine WG consensus as to whether the composed = attribute is
> a  boolean (currently in the framework) or whether it should = be a data
> structure describing the composed image.
>  (Note: this ticket is a result of closing Issue #2).
>
>  Proposal to close ticket with conclusion that composed = attribute is a
> boolean on March 9th:
>  http://www.ietf.org/mail-archive/web/clue/current/msg01= 172.html
>
>  Confirmed at IETF-83 (chart 9):
>  http://www.ietf.org/proceedings/83/slides/slides-83-clu= e-2.pptx
>
> --
>
> --
> = --------------------------------+-------------------------------------- > -

> = --------------------------------+---

>  Reporter:  mary.ietf.barnes@… =  |       Owner:  draft-ietf-clue-
> framework@…

>      Type:  task   =              |      Status:  closed
>  Priority:  major           =     |   Milestone:
> Component:  framework           | =     Version:
>  Severity:  Active WG Document  |  Resolution:  fixed
>  Keywords:               =        |
> = --------------------------------+-------------------------------------- > -

> = --------------------------------+---

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

 

------_=_NextPart_001_01CD180A.DB68B6D1-- From marshall.eubanks@gmail.com Thu Apr 12 08:50:46 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0505421F869A for ; Thu, 12 Apr 2012 08:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.607 X-Spam-Level: X-Spam-Status: No, score=-103.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph+S00wH7J+y for ; Thu, 12 Apr 2012 08:50:45 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 005C721F8698 for ; Thu, 12 Apr 2012 08:50:44 -0700 (PDT) Received: by lbok13 with SMTP id k13so1856039lbo.31 for ; Thu, 12 Apr 2012 08:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=cYHscMtlnsS7WCxqQdqwDxdQ6aCFW+oLP3QUe8O5mNA=; b=M92arKkik2QeaA7Nfsj+HZcLOccuLz5IBcEw8u0CxUkEuIpRx45F399shsfjT9XJGT v1jbrDcT4VR740xKYPwa7Hqphi8Z/tGw66Kf8pazfWdsHiDBFIdTDohyTSWT/Kj3/v+7 4hN52FC9eAZYVhOAFMoI5P118Wt6KKwzDJcN55X42jN4Bq9b0v7wUC5tvLlE4sxjssy9 gpQCjSV6s5H0clWu11m6CKCkx6tH7+N4evNkNPipHnSl0zJFWJ7MgyLPztcG7txPXp7K 71KlwcAHeZXvCOby2VOmFvwjCEigJVUQ1gjZCvidVy0UHJqWGWiNIk3NDn3fomB5Y+Sw QAng== MIME-Version: 1.0 Received: by 10.112.49.136 with SMTP id u8mr1398299lbn.2.1334245843814; Thu, 12 Apr 2012 08:50:43 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Thu, 12 Apr 2012 08:50:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 11:50:43 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] Fwd: [rtcweb] Dates for upcoming interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 15:50:46 -0000 Are we really going to have an interim in Stockholm ? Regards Marshall ---------- Forwarded message ---------- From: Ted Hardie Date: Thu, Apr 12, 2012 at 11:20 AM Subject: [rtcweb] Dates for upcoming interim To: rtcweb@ietf.org After discussion between the WEBRTC and RTCWEB chairs, consulting the doodle poll, and working through the potential for co-location with CLUE, we have decided to set the date for the RTCWEB interim at June 12 & 13th, to be hosted by Ericsson in Stockholm. =A0We understand that the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE wishes to co-locate their meeting, the 14th and 15th will be available. =A0This would not have been possible on the previous week, given the national holiday in Sweden on the Wednesday of that week. We very much appreciated the work Eric put into his analysis, and in general we will try to prefer hubs; in this particular case, however, a large fraction of the Western European participants are either based in Stockholm or must fly through it to reach one of the larger hubs. Given the availability of a host and this data, we decided to select Stockholm for this meeting. regards, Ted Hardie, for the chairs. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From marshall.eubanks@gmail.com Thu Apr 12 08:56:33 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB5021F869D for ; Thu, 12 Apr 2012 08:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.307 X-Spam-Level: X-Spam-Status: No, score=-103.307 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ve2VbsYSdIVW for ; Thu, 12 Apr 2012 08:56:33 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01521F86A2 for ; Thu, 12 Apr 2012 08:56:32 -0700 (PDT) Received: by lagj5 with SMTP id j5so1839007lag.31 for ; Thu, 12 Apr 2012 08:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=XqBzbhoAL+Obc+cUrScGl76K+70lHcWaMl0vGoIPnyE=; b=Q7bFlycHBDYQBAITMoOb038pW0pyPHvHPlnwe7XwUyyQzGrv+v+R374q55r7f+cxfV s8arSg/X3TDLA29S55PCm9SyUqSK65UunWTZdNc0zbo+T4dXuKuQNXR4MOU1WJYu/ZFP uWVuMe1ICJwcgh/bTTGqmxDc5Hn5ZtiKMscqJCdaHvavw3jBAMh8bMdoQ7HjE65b6r/j bliL0q1PwUKVwugOYsTCx8gGSqlJndXg2K499iTqX2hRhL7uL+a5iZ4mnq/G4bGDxi/g WgcF6a2udWY44wlcuLTBy13NefCsKlOhes1D7UG8FjbCf4yzMDyBX29QUla2xupKxYDC bxyg== MIME-Version: 1.0 Received: by 10.112.100.8 with SMTP id eu8mr1388216lbb.16.1334246191350; Thu, 12 Apr 2012 08:56:31 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Thu, 12 Apr 2012 08:56:31 -0700 (PDT) In-Reply-To: <4F869648.2020605@alvestrand.no> References: <4F869648.2020605@alvestrand.no> Date: Thu, 12 Apr 2012 11:56:31 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] Fwd: [rtcweb] Resolution negotiation - a contribution X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 15:56:33 -0000 I thought that CLUE might want to see this. I see these are pretty straightforward, and yet quite different from the way a telepresence session might work. Marshall ---------- Forwarded message ---------- From: Harald Alvestrand Date: Thu, Apr 12, 2012 at 4:46 AM Subject: [rtcweb] Resolution negotiation - a contribution To: "rtcweb@ietf.org" Hello folks, after the IETF, I've attempted to gather together information about resolution negotiation and what we might need to do there. I pulled together the paragraphs below - this may want to be incorporated in an I-D on "SDP usage in RTCWEB", or it may want to go somewhere else. Chairs' guidance is appreciated. At the moment, I have it in xml2rfc format, so it should be easy to do cut-and-paste on it, but don't want to push it as a separate I-D unless that's what the chairs desire. Note - there are some QUERY sections in there - I'm unsure what those should be resolved to. Comments? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harald 2. =A0Requirements =A0 The relevant requirement for video resolution negotiation from the =A0 RTCWEB use cases document =A0 [I-D.ietf-rtcweb-use-cases-and-requirements] is: =A0 o =A0F25 The browser SHOULD use encoding of streams suitable for the =A0 =A0 =A0current rendering (e.g. video display size) and SHOULD change =A0 =A0 =A0parameters if the rendering changes during the session. =A0 The resulting need is: =A0 o =A0To negotiate a maximum spatial resolution for all videos at call =A0 =A0 =A0setup time =A0 o =A0To negotiate a maximum temporal resolution ("frame rate") across =A0 =A0 =A0all videos at call setup time =A0 o =A0To indicate the desire of the recipient for a particular spatial =A0 =A0 =A0or temporal resolution on a particular video source =A0 o =A0To indicate the intent of the sender to send a video source in a =A0 =A0 =A0particular spatial or temporal resolution =A0 This document does not mention other requirements. 3. =A0SDP negotiation of video resolution =A0 An RTCWEB client MUST support negotiation of resolution using the =A0 "imageattr" attribute, as documented in [RFC6236]. =A0 An RTCWEB client MUST support a SAR value of 1.0 (square pixels), and =A0 MAY choose to support only the 1.0 value of the "sar" attribute. =A0 The interpretation of the negotiation is that any video stream in the =A0 m=3D line containing the a=3Dimageattr attribute will have a resolution =A0 within the bounds established by the negotiation. =A0 An RTCWEB client MUST support negotiation of the "a=3Dframerate" =A0 attribute, as specified in [RFC4566] section 6. =A0Note that this is an =A0 upper bound on framerate; there is no lower bound negotiated. =A0 These requirements are necessary and sufficient for establishing the =A0 maximum spatial and temporal resolution for all videos at call setup =A0 time. =A0These bounds MAY be renegotiated over the course of the call, =A0 but MUST NOT be renegotiated to render any currently transmitted =A0 video stream out of bounds; the sending video stream MUST first be =A0 changed to be of a resolution that fits within both the old and the =A0 new bounds, or halted. <> =A0 An RTCWEB client MUST support per-SSRC requests for video =A0 resolutions, as described in =A0 [I-D.lennox-mmusic-sdp-source-selection]. =A0This satisfies the =A0 requirement to indicate the desire of the recipient for a particular =A0 spatial or temporal resolution. =A0 We assume that the media sent from a sender to a receiver contains =A0 enough information inside the media format to tell what the =A0 resolution and framerate is. <> 4. =A0Non-SDP negotiation of video resolution =A0 An RTCWEB client MAY support the COP mechanism =A0 [I-D.westerlund-avtext-codec-operation-point] to negotiate the =A0 resolution of video within the limits established by the SDP =A0 negotiation without the need for additional SDP exchanges. 5. =A0Relation to WebRTC API constraint =A0 It is intended that the resolution negotiation be influenced by the =A0 constraints set by the application of either mandatory or optional =A0 constraints at the WebRTC API, as registered in the registry =A0 established by [I-D.burnett-rtcweb-constraints-registry]. =A0 The following relationships hold for all attributes that the =A0 implementation intends to satisfy (note that the constraints listed =A0 here have NOT been registered yet): =A0 video-min-height >=3D value of imageattr y=3D xyrange lower bound =A0 video-max-height <=3D value of imageattr y=3D xyrange upper bound =A0 video-min-framerate is not represented in SDP =A0 video-max-framerate <=3D value of a=3Dframerate attribute =A0 video-min-aspect-ratio <=3D value of imageattr "par=3D" prange lower =A0 bound =A0 video-max-aspect-ratio >=3D value of imageattr "par=3D" prange upper =A0 bound =A0 The implementation is free to increase "min" values or decrease "max" =A0 values (make requirements more restrictive) and add "step" in order =A0 to fit with its implementation restrictions. <>. =A0 Constraints specified at PeerConnection creation time are reflected =A0 as SDP-wide values. =A0Constraints specified when creating a =A0 MediaStream or attaching a MediaStream to a PeerConnection are =A0 reflected as ssrc-specific values. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From mary.ietf.barnes@gmail.com Thu Apr 12 09:07:09 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039A921F852C for ; Thu, 12 Apr 2012 09:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.613 X-Spam-Level: X-Spam-Status: No, score=-103.613 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhk-ceVTC5OO for ; Thu, 12 Apr 2012 09:07:08 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CCE5121F8512 for ; Thu, 12 Apr 2012 09:07:07 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1741137vbb.31 for ; Thu, 12 Apr 2012 09:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CFMMkbrmbQdtl9XYtyimQ39m4avR1PPbqsC3RPF60AE=; b=TrCbCwHWMCZze5SPV9WTqKlO8jVCEKunCGxY29uKOnTpy4CA/pYDdfWetp6tQaepFU 3ih93J297TW9tYzgoJ7QCWZ4cR9oJbAZHCap/SarKgj1tACGHKpjONlFUNRoCYpEpzuW BSYsxqf0/9wGUTNXjnJEypfhCWYAxhZkTupvgZFxLGccXd12glHsMYiasgUjWSb2f19S sUkCGncC1zr/h8ud2JA48QaCOl3viAe3uyNnxL6Q4nUDbf0oeaZcYWP4OKpGq8O8N1+I fRJofy/OvdOPRgWR4ezqBm9+HPSBf+IH2dS/u5556hQVw5HPDZYLmEIyi8AcRrveeKrk lOpA== MIME-Version: 1.0 Received: by 10.220.115.8 with SMTP id g8mr1605918vcq.8.1334246827367; Thu, 12 Apr 2012 09:07:07 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Thu, 12 Apr 2012 09:07:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 11:07:07 -0500 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=f46d04389129301b9104bd7d8c9e Cc: Cullen Jennings , rai-ads@tools.ietf.org, Ted Hardie , clue Subject: Re: [clue] Fwd: [rtcweb] Dates for upcoming interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:07:09 -0000 --f46d04389129301b9104bd7d8c9e Content-Type: text/plain; charset=ISO-8859-1 No, unfortunately, the RTCWEB folks made a decision that was based on who was available and they didn't count maybes, which would have put the total the highest for Thursday the 7th, which would have allowed CLUE to meet on the 5th and 6th, which is our 2nd optimal date. Since the 6th is our half-day meeting, folks that needed to be off on the 6th wouldn't miss as much and we could organize the agenda to maximize their participation. However, the RTCWEB folks made their decision without consulting with the CLUE WG chairs. Note, also that their choice results in not having one of the area directors at their meeting, which also doesn't make sense to me. Also, not having the CLUE and RTCWEB meetings co-located means that some folks will not be at the CLUE meeting and given the number of drafts that one of the individuals has that potentially apply to the CLUE solution, it's extremely unfortunate. It looks like June 7th and 8th are optimal for CLUE. The only problem with that choice is that the 6th is a Swedish holiday, so it is very unfortunate that some of the folks based in Sweden may find this problematic. We have a couple options: 1) We do another poll that includes the dates we originally skipped in trying to co-locate with RTCWEB. If the folks that are impacted by the need to travel on the 6th could let the chairs know then we can decide if we should run another (short/quick poll). We also need to do a poll for location, however, I would first like folks that are willing to host to let the chairs know, which leads to our 2nd option if the 6th really is a problem: 2) Meet in Stockholm as that does allow the folks in Sweden to avoid travel on the 6th, but we need a host and we need to see if the majority can travel there. Thanks, Mary. On Thu, Apr 12, 2012 at 10:50 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > Are we really going to have an interim in Stockholm ? > > Regards > Marshall > > ---------- Forwarded message ---------- > From: Ted Hardie > Date: Thu, Apr 12, 2012 at 11:20 AM > Subject: [rtcweb] Dates for upcoming interim > To: rtcweb@ietf.org > > > After discussion between the WEBRTC and RTCWEB chairs, consulting the > doodle poll, and working through the potential for co-location with > CLUE, we have decided to set the date for the RTCWEB interim at June > 12 & 13th, to be hosted by Ericsson in Stockholm. We understand that > the WEBRTC chairs will hold their meeting on June 11th. If CLUE > wishes to co-locate their meeting, the 14th and 15th will be > available. This would not have been possible on the previous week, > given the national holiday in Sweden on the Wednesday of that week. > > We very much appreciated the work Eric put into his analysis, and in > general we will try to prefer hubs; in this particular case, however, > a large fraction of the Western European participants are either based > in Stockholm or must fly through it to reach one of the larger hubs. > Given the availability of a host and this data, we decided to select > Stockholm for this meeting. > > regards, > > Ted Hardie, for the chairs. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --f46d04389129301b9104bd7d8c9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No, unfortunately, the RTCWEB folks made a decision that was based on who w= as available and they didn't count maybes, which would have put the tot= al the highest for Thursday the 7th, which would have allowed CLUE to meet = on the 5th and 6th, which is our 2nd optimal date. =A0Since the 6th is our = half-day meeting, folks that needed to be off on the 6th wouldn't miss = as much and we could organize the agenda to maximize their participation. = =A0However, the RTCWEB folks made their decision without consulting with th= e CLUE WG chairs. =A0 Note, also that their choice results in not having on= e of the area directors at their meeting, which also doesn't make sense= to me. =A0Also, not having the CLUE and RTCWEB meetings co-located means t= hat some folks will not be at the CLUE meeting and given the number of draf= ts that one of the individuals has that potentially apply to the CLUE solut= ion, it's extremely unfortunate.=A0

It looks like June 7th and 8th are optimal for CLUE. =A0The = only problem with that choice is that the 6th is a Swedish holiday, so it i= s very unfortunate that some of the folks based in Sweden may find this pro= blematic. We have a couple options:=A0
1) We do another poll that includes the dates we originally skipped in= trying to co-locate with RTCWEB. If the folks that are impacted by the nee= d to travel on the 6th could let the chairs know then we can decide if we s= hould run another (short/quick poll). =A0We also need to do a poll for loca= tion, however, I would first like folks that are willing to host to let the= chairs know, which leads to our 2nd option if the 6th really is a problem:=
2) Meet in Stockholm as that does allow the folks in Sweden to avoid t= ravel on the 6th, but we need a host and we need to see if the majority can= travel there.=A0

Thanks,
Mary.=A0
On Thu, Apr 12, 2012 at 10:50 AM, Marshall Euban= ks <mars= hall.eubanks@gmail.com> wrote:
Are we really going to have an interim in Stockholm ?

Regards
Marshall

---------- Forwarded message ----------
From: Ted Hardie <ted.ietf@gmail.c= om>
Date: Thu, Apr 12, 2012 at 11:20 AM
Subject: [rtcweb] Dates for upcoming interim
To: rtcweb@ietf.org


After discussion between the WEBRTC and RTCWEB chairs, consulting the
doodle poll, and working through the potential for co-location with
CLUE, we have decided to set the date for the RTCWEB interim at June
12 & 13th, to be hosted by Ericsson in Stockholm. =A0We understand that=
the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE
wishes to co-locate their meeting, the 14th and 15th will be
available. =A0This would not have been possible on the previous week,
given the national holiday in Sweden on the Wednesday of that week.

We very much appreciated the work Eric put into his analysis, and in
general we will try to prefer hubs; in this particular case, however,
a large fraction of the Western European participants are either based
in Stockholm or must fly through it to reach one of the larger hubs.
Given the availability of a host and this data, we decided to select
Stockholm for this meeting.

regards,

Ted Hardie, for the chairs.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--f46d04389129301b9104bd7d8c9e-- From mary.ietf.barnes@gmail.com Thu Apr 12 09:15:12 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D179E21F85D1 for ; Thu, 12 Apr 2012 09:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.613 X-Spam-Level: X-Spam-Status: No, score=-103.613 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QD50bDzsG15 for ; Thu, 12 Apr 2012 09:15:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13AF521F8512 for ; Thu, 12 Apr 2012 09:15:11 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1753299vcb.31 for ; Thu, 12 Apr 2012 09:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EjssgjovFnl6e+1sVpyHaITsOAZ7OZdPxmqnXszGJ0Y=; b=Ihhqg+t4kJ/C2lOCNlboJZIpSnQyti3NVVJ7w+vVaVjQ3JIfORr9pqoUxYLzOTVjFM n9wh5mBJ24s6AwyrgXQswsMTeohXnmY7rR25ougM8cB6+fcEjofYtN05zN3mMR5Zd7V2 dVEtHzh3aY6PeiM/nWGIxwXPx+ZextTSgUowQHg6J1pUFbAxMOveJOnZPbjqzYq3Lodm AsIBK6hpu2wkQWQ9S9bPdrsujbK8d4A8dCXUNA6rsJEX4Rb2ikQWcmRuWnUngU/jz+jH 47tbhJ1pTV8MQxtz+M42S7Qgrg/Ex0HyO6E/aBAnIz+o0eFPbiJLaXMBfLpw0SW0kf4q vaKg== MIME-Version: 1.0 Received: by 10.52.28.200 with SMTP id d8mr1274784vdh.38.1334247311592; Thu, 12 Apr 2012 09:15:11 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Thu, 12 Apr 2012 09:15:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 11:15:11 -0500 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=20cf3079bc9e0ccdad04bd7da9be Cc: clue Subject: Re: [clue] Fwd: [rtcweb] Dates for upcoming interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:15:12 -0000 --20cf3079bc9e0ccdad04bd7da9be Content-Type: text/plain; charset=ISO-8859-1 See my other response - not necessarily. Mary. On Thu, Apr 12, 2012 at 10:50 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > Are we really going to have an interim in Stockholm ? > > Regards > Marshall > > ---------- Forwarded message ---------- > From: Ted Hardie > Date: Thu, Apr 12, 2012 at 11:20 AM > Subject: [rtcweb] Dates for upcoming interim > To: rtcweb@ietf.org > > > After discussion between the WEBRTC and RTCWEB chairs, consulting the > doodle poll, and working through the potential for co-location with > CLUE, we have decided to set the date for the RTCWEB interim at June > 12 & 13th, to be hosted by Ericsson in Stockholm. We understand that > the WEBRTC chairs will hold their meeting on June 11th. If CLUE > wishes to co-locate their meeting, the 14th and 15th will be > available. This would not have been possible on the previous week, > given the national holiday in Sweden on the Wednesday of that week. > > We very much appreciated the work Eric put into his analysis, and in > general we will try to prefer hubs; in this particular case, however, > a large fraction of the Western European participants are either based > in Stockholm or must fly through it to reach one of the larger hubs. > Given the availability of a host and this data, we decided to select > Stockholm for this meeting. > > regards, > > Ted Hardie, for the chairs. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf3079bc9e0ccdad04bd7da9be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable See my other response - not necessarily.

Mary.=A0
On Thu, Apr 12, 2012 at 10:50 AM, Marshall Euba= nks <mar= shall.eubanks@gmail.com> wrote:
Are we really going to have an interim in St= ockholm ?

Regards
Marshall

---------- Forwarded message ----------
From: Ted Hardie <ted.ietf@gmail.c= om>
Date: Thu, Apr 12, 2012 at 11:20 AM
Subject: [rtcweb] Dates for upcoming interim
To: rtcweb@ietf.org


After discussion between the WEBRTC and RTCWEB chairs, consulting the
doodle poll, and working through the potential for co-location with
CLUE, we have decided to set the date for the RTCWEB interim at June
12 & 13th, to be hosted by Ericsson in Stockholm. =A0We understand that=
the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE
wishes to co-locate their meeting, the 14th and 15th will be
available. =A0This would not have been possible on the previous week,
given the national holiday in Sweden on the Wednesday of that week.

We very much appreciated the work Eric put into his analysis, and in
general we will try to prefer hubs; in this particular case, however,
a large fraction of the Western European participants are either based
in Stockholm or must fly through it to reach one of the larger hubs.
Given the availability of a host and this data, we decided to select
Stockholm for this meeting.

regards,

Ted Hardie, for the chairs.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf3079bc9e0ccdad04bd7da9be-- From mary.ietf.barnes@gmail.com Thu Apr 12 09:50:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DAB21F869E for ; Thu, 12 Apr 2012 09:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.612 X-Spam-Level: X-Spam-Status: No, score=-103.612 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGkATqkA2t9g for ; Thu, 12 Apr 2012 09:50:55 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6DD21F8604 for ; Thu, 12 Apr 2012 09:50:55 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1777828vbb.31 for ; Thu, 12 Apr 2012 09:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZKAOuQagNn6vcsAU0oaUfan0OGe0rSmOwkf/69Xi90w=; b=urfOtApT9IgHt8BP1V9PfzFVL+Xq5uynUy2r7HXBRd6VbSon1KBM8ENhgIt4TAvb/j d6Doo7w8z2YhjLOyCujp6cKE35LnE2st3sXQTOxDlAeMvlwYfP5b8ObN/na0vtkXRCC7 8brKIvHUGXzWEpzKIZeoHXUe4IN72AHIdnZcYfrAe2kXffj2+6/KzuR5zfod7s6fU069 CbGtSVMe7Q56hrJ35kU99EOz9VZyRWbhE18waVXPa9m6H90odswhaZcU8AsCxgVQawLM 3fFdJm6mzAtybjGc3+0m9Wkd3sCcqUtnnSMHj+i9n+wQeVqSBKVNcO34XZTWwDt4RCUZ as+A== MIME-Version: 1.0 Received: by 10.52.97.225 with SMTP id ed1mr1326495vdb.55.1334249454806; Thu, 12 Apr 2012 09:50:54 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Thu, 12 Apr 2012 09:50:54 -0700 (PDT) In-Reply-To: <1711327089.580861.1334249248560.JavaMail.doodle@worker1> References: <1711327089.580861.1334249248560.JavaMail.doodle@worker1> Date: Thu, 12 Apr 2012 11:50:54 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307ac895cba84304bd7e28e0 Subject: [clue] Fwd: Doodle: Link for poll "CLUE WG Interim Meeting Location" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:50:56 -0000 --20cf307ac895cba84304bd7e28e0 Content-Type: text/plain; charset=ISO-8859-1 Per the earlier email thread, June 7th & 8th is the best choice for the CLUE WG Interim meeting. Now, we need to choose the location. Note, that if we select Stockholm, that would give folks an opportunity to stay over and then attend the RTCWEB interim meeting the following week (and maybe give folks some time to work on some of the CLUE work items). http://www.doodle.com/wwrdycma9ymrdn3r Please respond to the poll no later than Thursday, April 19th, 2012 @ noon Pacific. Thanks, Mary CLUE WG co-chair --20cf307ac895cba84304bd7e28e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Per the earlier email thread, June 7th & 8th is= the best choice for the CLUE WG Interim meeting. Now, we need to choose th= e location. =A0Note, that if we select Stock= holm, that would give folks an opportunity to stay over and then attend the= RTCWEB interim meeting the following week (and maybe give folks some time = to work on some of the CLUE work items).

http:/= /www.doodle.com/wwrdycma9ymrdn3r

Please respond to the poll no later than Thursday, April 19th, 2012 @ n= oon Pacific.

Thanks,
Mary
CLUE WG co-chair



--20cf307ac895cba84304bd7e28e0-- From mary.ietf.barnes@gmail.com Thu Apr 12 10:58:34 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6F621F85B5 for ; Thu, 12 Apr 2012 10:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.611 X-Spam-Level: X-Spam-Status: No, score=-103.611 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgbk0TmrDKXz for ; Thu, 12 Apr 2012 10:58:33 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC0A21F857A for ; Thu, 12 Apr 2012 10:58:33 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1829882vbb.31 for ; Thu, 12 Apr 2012 10:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Df843myqBnQklXPTAlInlLjh0P8dVkRhKTuIx8FVRCA=; b=QD3ZG30tssGTqUSzakuGShnmp9W0cbPnU1wIqLh+ID/ATzYl6F4fJBolqZ3s/C+wt+ Htnk8RXUAsbAmAsVG5/5ZwP2YINo7jbh02cCUUdbnV/mlVvuizx13BI1j3A0hKAsjO4E 5KwY5ynj9E5O/VgNZbBPXXM0TB0SrXAv8vWScKIJfzlttb91/R6oaDhkSmM9HiNnOc82 6W+kHYK9sbxMRW40i504fUmYR/RvZ4u3PpmxmomyeoWWzlbVHfYdhlKdu4PDqgG+zkDp ocZZqhnA03/zbIbDVv1RZ9c4+MVbL4+Ybe3zjDv0xlO64V9P2DYOf7Tb88s5Slik+EdU 88PQ== MIME-Version: 1.0 Received: by 10.52.73.132 with SMTP id l4mr1427188vdv.4.1334253513019; Thu, 12 Apr 2012 10:58:33 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Thu, 12 Apr 2012 10:58:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 12:58:33 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf3071c7e0af110804bd7f1ad7 Subject: [clue] Fwd: [rtcweb] URGENT: Dates for upcoming interim ON HOLD X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 17:58:34 -0000 --20cf3071c7e0af110804bd7f1ad7 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, Please note that our dates may change to the 4th and 5th (or 5th and 6th if they follow my recommendation) so that we can optimize participation and save some folks two trips. Regards, Mary. ---------- Forwarded message ---------- From: Ted Hardie Date: Thu, Apr 12, 2012 at 12:42 PM Subject: [rtcweb] URGENT: Dates for upcoming interim ON HOLD To: rtcweb@ietf.org, Magnus Westerlund , Cullen Jennings Cc: rai-ads@tools.ietf.org, clue-chairs@tools.ietf.org Please hold off making travel plans based on this timing. Because neither RAI area director will be available during this timing, they have asked to consider shifting this timing to the previous week, June 7th and 8th. Until the chairs have had a chance to discuss this, please hold off on booking travel plans. My apologies for this scramble, Ted Hardie On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie wrote: > After discussion between the WEBRTC and RTCWEB chairs, consulting the > doodle poll, and working through the potential for co-location with > CLUE, we have decided to set the date for the RTCWEB interim at June > 12 & 13th, to be hosted by Ericsson in Stockholm. We understand that > the WEBRTC chairs will hold their meeting on June 11th. If CLUE > wishes to co-locate their meeting, the 14th and 15th will be > available. This would not have been possible on the previous week, > given the national holiday in Sweden on the Wednesday of that week. > > We very much appreciated the work Eric put into his analysis, and in > general we will try to prefer hubs; in this particular case, however, > a large fraction of the Western European participants are either based > in Stockholm or must fly through it to reach one of the larger hubs. > Given the availability of a host and this data, we decided to select > Stockholm for this meeting. > > regards, > > Ted Hardie, for the chairs. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --20cf3071c7e0af110804bd7f1ad7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

Please note that our dates may change to the 4= th and 5th (or 5th and 6th if they follow my recommendation) so that we can= optimize participation and save some folks two trips.

Regards,
Mary.=A0

--------= -- Forwarded message ----------
From: Ted = Hardie <ted.= ietf@gmail.com>
Date: Thu, Apr 12, 2012 at 12:42 PM
Subject: [rtcweb] URGENT: Dates for = upcoming interim ON HOLD
To: rtcweb@i= etf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, Cullen Jennings <fluffy@cisco.com>
Cc: rai-ads@tools.ietf.org, <= a href=3D"mailto:clue-chairs@tools.ietf.org">clue-chairs@tools.ietf.org=


Please hold off making travel plans based on this timing. =A0 B= ecause
neither RAI area director will be available during this timing, they
have asked to consider shifting this timing to the previous week, June
7th and 8th. =A0Until the chairs have had a chance to discuss this,
please hold off on booking travel plans.

My apologies for this scramble,

Ted Hardie

On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> After discussion between the WEBRTC and RTCWEB chairs, consulting the<= br> > doodle poll, and working through the potential for co-location with > CLUE, we have decided to set the date for the RTCWEB interim at June > 12 & 13th, to be hosted by Ericsson in Stockholm. =A0We understand= that
> the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE
> wishes to co-locate their meeting, the 14th and 15th will be
> available. =A0This would not have been possible on the previous week,<= br> > given the national holiday in Sweden on the Wednesday of that week. >
> We very much appreciated the work Eric put into his analysis, and in > general we will try to prefer hubs; in this particular case, however,<= br> > a large fraction of the Western European participants are either based=
> in Stockholm or must fly through it to reach one of the larger hubs. > Given the availability of a host and this data, we decided to select > Stockholm for this meeting.
>
> regards,
>
> Ted Hardie, for the chairs.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--20cf3071c7e0af110804bd7f1ad7-- From marshall.eubanks@gmail.com Thu Apr 12 11:00:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D5021F85EF for ; Thu, 12 Apr 2012 11:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teVnBALV1uOr for ; Thu, 12 Apr 2012 11:00:34 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 475E121F85D7 for ; Thu, 12 Apr 2012 11:00:34 -0700 (PDT) Received: by lagj5 with SMTP id j5so1941388lag.31 for ; Thu, 12 Apr 2012 11:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=R6KJxmhlkjexCPoTBY8P0gdxzHRjLXdlRtfjOQUrWJA=; b=sp5BMw/TKHLx3we+rpZSnzEu/PcN2ZLhUIkLFnVQjA9/ZkVgfOiVQEinElGM1VCjq4 A1XTlNV8kgdCpFniotVaa8W2xVUfpt3FeJC12A3MwGSOHduR3ttPeOxeKCcQQZT0wYjM LHvxwxaHWyGNdclVHw/vCM4iQoqihaupUuBSloMBCgDG+S4PFOKKeRj0JhKYCfTIRJkf UAkz3rAzHM4K4RrT7EGkUd9sn2JlJ6EnYRDUnbkI0fj1shiXxl92zhBG90NDThaIN0n4 EeO2vYt+j0DvU8KXcgTuf9rHjan+/WE4ey91CpX/MVbjDseEGUmg4tfwRPX4r3pP3XyL yC7w== MIME-Version: 1.0 Received: by 10.152.106.9 with SMTP id gq9mr3034738lab.14.1334253633156; Thu, 12 Apr 2012 11:00:33 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Thu, 12 Apr 2012 11:00:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 14:00:33 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] Fwd: [rtcweb] URGENT: Dates for upcoming interim ON HOLD X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:00:35 -0000 Well, well. ---------- Forwarded message ---------- From: Ted Hardie Date: Thu, Apr 12, 2012 at 1:42 PM Subject: [rtcweb] URGENT: Dates for upcoming interim ON HOLD To: rtcweb@ietf.org, Magnus Westerlund , Cullen Jennings Cc: rai-ads@tools.ietf.org, clue-chairs@tools.ietf.org Please hold off making travel plans based on this timing. =A0 Because neither RAI area director will be available during this timing, they have asked to consider shifting this timing to the previous week, June 7th and 8th. =A0Until the chairs have had a chance to discuss this, please hold off on booking travel plans. My apologies for this scramble, Ted Hardie On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie wrote: > After discussion between the WEBRTC and RTCWEB chairs, consulting the > doodle poll, and working through the potential for co-location with > CLUE, we have decided to set the date for the RTCWEB interim at June > 12 & 13th, to be hosted by Ericsson in Stockholm. =A0We understand that > the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE > wishes to co-locate their meeting, the 14th and 15th will be > available. =A0This would not have been possible on the previous week, > given the national holiday in Sweden on the Wednesday of that week. > > We very much appreciated the work Eric put into his analysis, and in > general we will try to prefer hubs; in this particular case, however, > a large fraction of the Western European participants are either based > in Stockholm or must fly through it to reach one of the larger hubs. > Given the availability of a host and this data, we decided to select > Stockholm for this meeting. > > regards, > > Ted Hardie, for the chairs. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From mary.ietf.barnes@gmail.com Thu Apr 12 11:01:40 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D621121F85D7 for ; Thu, 12 Apr 2012 11:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.611 X-Spam-Level: X-Spam-Status: No, score=-103.611 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB9yx6jdqVCJ for ; Thu, 12 Apr 2012 11:01:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C62A721F85BD for ; Thu, 12 Apr 2012 11:01:39 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1837511vcb.31 for ; Thu, 12 Apr 2012 11:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aZFxgrQD0B1wsEMj0A3Jj+6SBAoBYscG2PpLW1m2WCo=; b=qQlJg7NbsGqR7lUrARs/CG7e+gXhF2OCtIO1tu56b0qzWUs3kD8XS2HBMccJ9Awlp0 NhCPI2IpvK0ChkiLq8X9Ec6tPaRfMlhAhXEBt5HCjuf2mZDslqFhWElJRwcMcuiBvSaL uJ4P8CfNoAA9yRO5dTaKI+ml9HAANcSC1zlaFNaGfrnfK/eHeU6Pxq16+vu7V9kf0E5y Fe3GiJ4w+pHhJaCqqYptWwQih9yD67Iy7y1TVWX0f73IQ7XadA1eibMwSIFb4qfC5Sol QOr4hE0m2BHxd2Wrrd88zJ6ewSCnCGmKXwEsOoUn356SvsHzTfHl5l1WmEr/YF08OLPQ nn0w== MIME-Version: 1.0 Received: by 10.52.73.132 with SMTP id l4mr1431255vdv.4.1334253699252; Thu, 12 Apr 2012 11:01:39 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Thu, 12 Apr 2012 11:01:39 -0700 (PDT) In-Reply-To: References: <1711327089.580861.1334249248560.JavaMail.doodle@worker1> Date: Thu, 12 Apr 2012 13:01:39 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf3071c7e0c8c0b104bd7f259e Subject: Re: [clue] Doodle: Link for poll "CLUE WG Interim Meeting Location" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:01:41 -0000 --20cf3071c7e0c8c0b104bd7f259e Content-Type: text/plain; charset=ISO-8859-1 Per the email I just forwarded with regards to the dates for the RTCWEB meeting being on hold, our dates may change to the 4th/5th or 6th/7th. If we do that, we will meet in Stockholm. You can go ahead and make your selections, but please keep this in mind (i.e., if you can at all be flexible or have potential for going to Stockholm then select Yes or Maybe - if you absolutely, positively can't then select no). Thanks, Mary. On Thu, Apr 12, 2012 at 11:50 AM, Mary Barnes wrote: > Per the earlier email thread, June 7th & 8th is the best choice for the > CLUE WG Interim meeting. Now, we need to choose the location. Note, that > if we select Stockholm, that would give folks an opportunity to stay over > and then attend the RTCWEB interim meeting the following week (and maybe > give folks some time to work on some of the CLUE work items). > > http://www.doodle.com/wwrdycma9ymrdn3r > > Please respond to the poll no later than Thursday, April 19th, 2012 @ noon > Pacific. > > Thanks, > Mary > CLUE WG co-chair > > > > --20cf3071c7e0c8c0b104bd7f259e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Per the email I just forwarded with regards to the dates for the RTCWEB mee= ting being on hold, our dates may change to the 4th/5th or 6th/7th. =A0If w= e do that, we will meet in Stockholm. =A0You can go ahead and make your sel= ections, but please keep this in mind (i.e., if you can at all be flexible = or have potential for going to Stockholm then select Yes or Maybe - if you = absolutely, positively can't then select no).=A0

Thanks,
Mary.=A0

On Thu, Apr 12, 2012 at 11:50 AM, Mary Barnes <mary.ietf.barnes@gmail.com><= /span> wrote:
Per the earlier email thread, June 7th & 8t= h is the best choice for the CLUE WG Interim meeting. Now, we need to choos= e the location. =A0Note, that if we select Stockholm, that would give f= olks an opportunity to stay over and then attend the RTCWEB interim meeting= the following week (and maybe give folks some time to work on some of the = CLUE work items).

http:/= /www.doodle.com/wwrdycma9ymrdn3r

Please respond to the poll no later than Thursday, April 19th, 2012 @ n= oon Pacific.

Thanks,
Mary
CLUE WG co-chair




--20cf3071c7e0c8c0b104bd7f259e-- From pkyzivat@alum.mit.edu Thu Apr 12 13:36:34 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3DA21F8707 for ; Thu, 12 Apr 2012 13:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bfmLjER2r2f for ; Thu, 12 Apr 2012 13:36:33 -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 DB63B21F8703 for ; Thu, 12 Apr 2012 13:36:32 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id x8XF1i00317dt5G5D8cZXr; Thu, 12 Apr 2012 20:36:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id x8cY1i01707duvL3Z8cYCG; Thu, 12 Apr 2012 20:36:32 +0000 Message-ID: <4F873CCE.3020806@alum.mit.edu> Date: Thu, 12 Apr 2012 16:36:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Espen Berger (espeberg)" References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 20:36:34 -0000 Espen - comments inline. Thanks, Paul On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: > During the CLUE design team meeting on webex yesterday we started to > discuss various use cases and if they are in scope or not for the > current work in CLUE. > > As a part of my response to Pauls questions I summarized the use cases > and grouped them into supported / not supported. I can dive into more > detail about the use cases if people are interested? > > I would answer yes to the following use cases > * Telepresence point to point, where the reproduction will happen in a > 2D-plane for audio and video. Currently CLUE support announcing > capability of sending 1 - N capture (left to right) and a receiver can > request 1 - M streams for rendering (left to tight), which is the basic > for interoperability. In this case, suppose N > M. Who is responsible for deciding which M of the N streams will be used? AFAIK the recipient just picks the ones it wants. So then my question remains - does the recipient have sufficient info to select the "right" ones? (There isn't any guarantee that *any* N of the M streams will provide a reasonable rendering. This would be improved if we had a mechanism for the recipient to state "I can only handle N streams" and the sender was obligated to meet that constraint. I don't think we have said that. > * Transcoded conferencing, where the MCU act like an endpoint and > logically announces audio and video left to right and a receiver request > 1 - M captures depending on how many screen and audio streams you > prefer. Typically a single video stream pr. screen and one audio pr. > screen (mono/stereo). Excluded is capabilities to select individual > speakers, the MCU is free to optimize what to compose and send to a > receiver. This is logically equivalent to the prior case. > * Generic multi source, sending and receiving named sources where the > user experience is controlled by an human being capable of reading > sources names, or control software written explicit to operate on the > named streams. The content attribute can be used to indicate a primary > role, RFC4796 uses 'main' and 'alt'. Are you talking about the text names/labels we were discussing on the last call? If so, I agree that if the senders provide well conceived labels then a human can probably decide something reasonable. If the human is working only with "content" attributes, then its not so clear. Its quite possible that the recipient will find itself trying to choose between multiple streams with the same content type. (E.g. all 'main'.) > I would answer no, to the following use cases > * Switched conferencing, where we assume that endpoints do scalable > video (either SVC or Simulcast), locally composited layout and audio > mixing. Limited work has been done on how to use Scalable video and how > to build mechanisms for complete composited layouts. > * Advanced audio reproduction, a group of audio scenarios mentioned by > Jon Leslie and Johan Nielsen that requires more details during initial > signalling and more dynamic information for transferring dynamic > meta-information. > * Multi view, as described in the CLUE use case document. > > (Other comments inline.) > > Cheers > > -Espen > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 11. april 2012 17:06 > To: John Leslie > Cc: CLUE > Subject: Re: [clue] Does framework provide sufficient info for receiver? > > Hi John, > > Thanks for the comments. I've followed up inline. > > On 4/10/12 5:09 PM, John Leslie wrote: >> Paul Kyzivat wrote: >>> >>> The fundamental problem in the scope of CLUE is, if you are an >>> endpoint, and you have received an advertisement, with some scenes >>> and captures, do you have sufficient information to select and map >>> the advertised scenes/captures onto the equipment you have? >> >> Of course not! >> >> If we wanted that, we'd have to include for every composed scene >> what it's composed from, and for every mixed audio what it's mixed >> from. > > I think you must have misunderstood me. Otherwise I wouldn't expect you > to answer "Of course not". AFAIK the whole point of CLUE is to provide > the information to make this possible. > > My point in asking the question was so that we can identify what > information we have overlooked that we need to include one way or > another. > > Clearly there are some tradeoffs. More information might support > *better* mappings. So one thing to decide is how good is good enough. > [Espen] Agree with Paul, we clearly can support in CLUE the use cases > where a Telepresence room either offer a 1, 2 or 3 video captures, which > can be rendered on 1, 2 or 3 screens. I think its clear we can support cases where every advertisement that includes an entry for N (>1) captures also includes an entry with only one capture, and optionally entries containing other numbers of captures between 1 and N. But as I mention above, its not clear we have supported case where the minimal entry in the advertisement is for N>1 captures. >>> If you have sufficient equipment (displays, speakers) with compatible > >>> geometry to directly map all of the captures from one audio and one >>> video capture scene entry from each capture scene then maybe all is >>> good. In this case ISTM that the mixed/composed attributes aren't >>> needed. >> >> It's unlikely that the "typical" telepresence conference will have > >> a separate screen for every possible video. > > That isn't what I said. Consider what is perhaps a typical case, where > the advertisement contains one scene with several alternative video and > audio scene entries. Lets just consider the video. Then maybe there is > one entry with three captures, and another with one (mixed/switched, > whatever) capture. Then if you have three screens you can map all three > captures in the first entry. If you have less than three screens then > you can map the one capture from the 2nd entry onto one of your screens. > > But what if there was no entry with a single capture? If you had two > screens, would you have enough info about the three captures in the > first entry to make a reasonable mapping onto your two screens? What > information would we need to include in the advertisement so that it > would be possible to do this mapping well? > > [Espen] How a vendor build a room or endpoint is transparent from the > sender of media. As a sender you should not care if a room request 3 > audio streams (left, center, right) and choose to mix and play out on a > single speaker. We can argue that this is not the best experience, but > still valid and typically done for PC-clients or other endpoints with a > single speaker. Again, I think you are assuming the receiver can specify the max number of streams it can handle, and that the sender will then be obligated to select/construct a suitable set of streams. AFAIK we have not written down anything that calls for that. (If I am wrong, please let me know where this is specified.) We have the (largely hypothetical) recipient capabilities message, but its content hasn't been specified yet, and AFAIK there has been no statement that it is binding and the construction of the advertisement. >> Of course, the number of "capture scenes" _could_ be small enough >> to give each it's own video monitor -- but I don't think that's the >> general case we should design for. > > IIUC an endpoint will typically only advertise one or two scenes. One > would correspond to the cameras and mics in its room. The other, if > present, would correspond to a "presentation" that doesn't fit into the > coordinate space of the room. There are cases for more, but they get > more obscure. > > So for a point-to-point clue call the recipient will only need to map > one or two scenes. But when there is more than one it is more complex, > requiring sharing of equipment. > > The situation is more complex for an MCU. It will have as input all the > scenes offered by all the endpoints. It then has to decide what to offer > out to the endpoints. It could just pass through all the scenes it > receives from all the endpoints, leaving the mapping problem entirely to > the endpoints. (I don't think that is what most people have in mind, > though some might.) > > Or it could take on itself the job of mapping/mixing/switching all of > those inputs and producing something more like what a typical endpoint > would advertise - one or two scenes each with just a few captures. > > Or it could do both - advertise its own simplified composite scenes and > also all those provided by the endpoints. That would allow the endpoints > to either take the easy way out, or else do it all themselves in a way > that suits them. Suppose it did this. Would the endpoints that want to > take the easy way be able to figure out which scenes and captures to > use? > > [Espen] This sounds closer to a user experience discussions than a > protocol discussion. Perhaps it is. But the point of CLUE is to develop a protocol that enables an especially good user experience. While we shouldn't mandate the user experience, I think we are obligated to do due diligence that the protocol is sufficient to enable that user experience. >> OTOH, with an appropriate "surround-sound" system, you can "place" >> an arbitrarily large number of audio streams, yet make them easy to >> distinguish. >> >>> If you don't have sufficient equipment to do that, then the job is >>> harder, and more information is needed to figure out what to do. >> >> Only marginally harder... >> >>> For instance: >>> >>> - If you don't have suitable displays, then perhaps you can select a >>> video capture scene entry and locally compose or switch some of the >>> captures in order to produce a set of captures that does map to the >>> available displays. The area of capture of each capture could be >>> helpful to doing this, and perhaps the composed attribute as well. >> >> One inevitable use case is filing your formal report from the > airport. >> The person doing so will have lousy audio, vastly inadequate video, >> and typically inadequate bandwidth with excessive latency. S/he will >> need some middlebox to compose a "barely-adequate video" and mono > audio. > > This is indeed an interesting case - one we have explicitly put in > scope. If an MCU is already in the call then perhaps we can hope that is > one of the entries it makes available. > > If there isn't any MCU in the call, then the other endpoint might not > advertise that option. Then what? Do we have a mechanism for that? > [Espen] If an MCU detect low bandwidth or packet loss it can start using > its normal recovery mechanisms. That could lower bitrate for audio and > video (maybe by a SIP re-invite), change the CLUE offer to something > that fits inside the available bandwidth. Getting good quality audio > ande video is always a challenge, with or without clue. > >> Then there's the use case of filing you formal report from your >> home office (when you're sick or somebody doesn't want to pay travel > cost). >> You may well have surround-sound and two or three large monitors, 20 >> Mbps download with 40 msec RTT, and a decent-quality lavalier mike. >> You still probably want some middlebox to compose your basic video, >> but you can take individual streams as well to concentrate on > particular people. >> >> Near the top end are the corporate telepresence rooms. They will >> want all streams, and are likely to have a human being mixing them. > > I don't understand your point "are likely to have a human being mixing > them". Can you explain further? > [Espen] I see this as mostly a request for focusing in on particular > user. In a transcoded conference you can do that by looking into XCon, > if you do switched conference the endpoint typically render the layout > and can choose who to focus on. Mixing transcoded and switched > conferencing I think makes it unnecessary complex for the initial use > cases to cover. > >>> - or rather than compose to fit your displays, you could switch... >> >> Folks _will_ do that -- I can't stop them. But I find it > uninteresting. > > ??? We have been talking about switching a lot. Are you saying that is > uninteresting? > > If it makes sense for a middlebox to switch, doesn't it make equal sense > for an endpoint to do so? > >>> - handling video from multiple scenes probably presents some added >>> issues. By definition there is no specified spatial relationship >>> between the captures of different scenes... >> >> Nonetheless, the participants will want to imagine such a > relationship. > > ISTM that this needs further discussion. > >>> - If you don't have sufficient speakers for all of the audio >>> captures, then you have to decide to mix, switch, or drop some. >> >> There really isn't any such thing as "sufficient speakers", but >> surround-sound should be considered "sufficient". You can always mix >> to stereo or even mono: "you pays your money and you takes your > choice". > > Do we have enough information to do it "right" or "well"? > Right now the coordinate info is all optional. Does it need to be > mandatory in order to enable this? > >>> The spatial information from the captures may help in deciding how to > >>> mix. >> >> Absolutely! >> >>> Not evident that the mixed attribute helps with this >> >> It help you know when mixing is less likely to work well. >> >>> - unless it is used to decide to switch rather than mix. >> >> I'm not sure there is any such thing. "Mixing" frequently includes > >> "riding gain" to reduce background noise. Binary switching is just a >> bad idea. > > I have no special understanding of this. I'm just asking probing > questions in hopes that it will result in the right decisions being made > and the right stuff specified. > >>> Of course if you are mapping independent audio captures onto >>> different speakers then they are being implicitly mixed. >> >> Not a useful way to think about it, IMHO. Human ears and brains >> can sort out individual sources if there are enough speakers, while >> mixing makes that harder. > > I have had the impression that "simple" clue telepresence rooms would be > hoping to do direct mapping of captures to devices. If the assumption is > that this will be an unsatisfactory approach and all endpoints should be > prepared to do something more complex then it would be helpful to write > that down somewhere - e.g. in the framework. > > [Espen] Agree with Paul here, the basic scenario is well understood. A > sends two logical audio captures and a receiver play them out with the > same spatial relationship. As rule of thumb here could be that for basic > interoperability between vendors you assume pairs of audio and video > captures that can be easily rendered on matching pairs of screens and > speaker. > >>> - If you don't have speakers with similar spatial relationship to >>> those of the audio captures, then you must decide whether to do >>> sub-optimal assignments or mix. >> >> I suppose _some_ telepresence system will hide dozens of speakers >> in the telepresence room and try to do this -- to me it sounds like a >> dreadful idea, but it's quite possible the people will adapt. >> >> "Sub-optimal" really doesn't have a clear meaning here. Even >> speakers in the "wrong" left-to-right order while you can see the >> "correct" order on-screen won't confuse the listener as much as >> speaker assignments changing for no obvious reason. >> >>> Again not clear if the mixed attribute helps with this. >> >> As an extreme example, you could always render "mixed" in mono. >> >>> - If you have audio from more than one scene, what should you do with > >>> it? Should you mix, even though you have no spatial relationships? >> >> IMHO, you should _invent_ a spatial relationship in that case. >> Even if each room invents a different spatial relationship, it will >> prove less confusing. >> >>> Or should you switch based on active speaker? >> >> Only if background-noise is a serious problem. >> >>> What would help you to decide? >> >> It becomes quickly obvious to the listener! >> >>> The problems are superficially different for MCUs. But perhaps only >>> superficially. It seems to me that when the MCU decides how to map >>> its inputs into its advertisement, it has some virtual room layouts > in mind. >> >> I would expect so. >> >>> So for each virtual room layout it is addressing the same issues as a > >>> real endpoint with that layout. But it does have the added problem of > >>> deciding how to describe what it is advertising - e.g. when to apply >>> the mixed/composed attributes. >> >> Pretty much always, unless it's feeding an exact copy of what it >> receives. > > Since I've seen people here describe cases when that isn't so, it would > be helpful to have a more precise definition. > >>> Some interesting use cases for all of the above would be very > helpful. >> >> Did the cases I listed help? > > I think they need to be worked out in much more detail: > > - what equipment (input and output) is in each endpoint, and where. > - what is advertised and how the input equipment is mapped to > the advertisement > - how each endpoint maps the advertised captures to its output equipment > together with how the info in the advertisement allowed it to > determine that mapping. > > [Espen] Agree, being practical about what we will offer for actual > endpoints are useful. > > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From espeberg@cisco.com Fri Apr 13 04:45:02 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B1021F8611 for ; Fri, 13 Apr 2012 04:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBq42GmNGE6z for ; Fri, 13 Apr 2012 04:45:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E415421F8606 for ; Fri, 13 Apr 2012 04:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=1550; q=dns/txt; s=iport; t=1334317499; x=1335527099; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=WzjvrqalO63hFtIf2R7aZxKl4pryjAQX6Ty+rKW1MQY=; b=cuB95od9MTNUaUXpxHqaWyhI3Nn26NUxZ8JDpBy4zhDxVLTBwBgsFNeT IEh92r0c5pQyDdBbw+fAicM0A17nkoA5wgDYBQvbpTC/ChmRxJha7/Vah oa/OiYnj/fc881BZaiC2Ng4PKhnoUZg79cOfhrdoQyXu66zLU67vDEt+l M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHEQiE+Q/khM/2dsb2JhbABFDrcegQeCCQEBAQMBEgEdCj8FCwIBCA4UBhgGAVYBAQQbGodnBZlfoAaQdGMEpDmBaYIwOQ X-IronPort-AV: E=Sophos;i="4.75,415,1330905600"; d="scan'208";a="135062564" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2012 11:44:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3DBivTA005974; Fri, 13 Apr 2012 11:44:57 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Apr 2012 13:44:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2012 13:44:56 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E011976A2@XMB-AMS-214.cisco.com> In-Reply-To: <4F873CCE.3020806@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Does framework provide sufficient info for receiver? Thread-Index: Ac0Y6/inFyhPhIXXQDuHtsdD7OyYzAAeqW/g References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> From: "Espen Berger (espeberg)" To: "Paul Kyzivat" X-OriginalArrivalTime: 13 Apr 2012 11:44:57.0666 (UTC) FILETIME=[D9E76220:01CD196A] Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 11:45:02 -0000 > * Telepresence point to point, where the reproduction will happen in a > 2D-plane for audio and video. Currently CLUE support announcing=20 > capability of sending 1 - N capture (left to right) and a receiver can > request 1 - M streams for rendering (left to tight), which is the=20 > basic for interoperability. In this case, suppose N > M. Who is responsible for deciding which M of the N streams will be used? AFAIK the recipient just picks the ones it wants. So then my question remains - does the recipient have sufficient info to select the "right" ones? (There isn't any guarantee that *any* N of the M streams will provide a reasonable rendering. [Espen] A receiver requesting 2x streams to be rendered left, right, will rely on the media sender to give a decent experience. E.g. the most capable endpoint must translate its capabilities down to what lesser capable room can do.=20 This would be improved if we had a mechanism for the recipient to state "I can only handle N streams" and the sender was obligated to meet that constraint. I don't think we have said that. [Espen] I see this as an important use case for interoperability. Its fine for capable Telepresence room to do a advanced CLUE advertisement, as long as there is an easy and straightforward way to request two captures screens for left, right placed monitors.=20 We should have a use cases to express that we want to support endpoints that only support asking for 1 - N streams, rendered left to right.=20 Cheers=20 -Espen=20 From pkyzivat@alum.mit.edu Fri Apr 13 08:02:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C615D21F84BF for ; Fri, 13 Apr 2012 08:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f07aQT+-VYeJ for ; Fri, 13 Apr 2012 08:02:23 -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 C937021F847D for ; Fri, 13 Apr 2012 08:02:22 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id xT0D1i0080mv7h05DT2P98; Fri, 13 Apr 2012 15:02:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta11.westchester.pa.mail.comcast.net with comcast id xT2N1i00P07duvL3XT2N48; Fri, 13 Apr 2012 15:02:23 +0000 Message-ID: <4F883FFD.3060109@alum.mit.edu> Date: Fri, 13 Apr 2012 11:02:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Espen Berger (espeberg)" References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E011976A2@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E011976A2@XMB-AMS-214.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: [clue] Sender to comply with receiver limits on what it can receive (?) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 15:02:23 -0000 Changing the subject line. This is one specific point coming out of the thread on "Does framework provide sufficient info for receiver?" Paraphrasing, I think Espen is calling for a requirement that the sender construct an advertisement that is consistent with receiver capabilities. This seems to require the (still undefined) Capabilities message, and to make it binding. AFAIK we currently have no such requirement. Do others think we should? Thanks, Paul On 4/13/12 7:44 AM, Espen Berger (espeberg) wrote: >> * Telepresence point to point, where the reproduction will happen in a > >> 2D-plane for audio and video. Currently CLUE support announcing >> capability of sending 1 - N capture (left to right) and a receiver can > >> request 1 - M streams for rendering (left to tight), which is the >> basic for interoperability. > > In this case, suppose N> M. Who is responsible for deciding which M of > the N streams will be used? AFAIK the recipient just picks the ones it > wants. So then my question remains - does the recipient have sufficient > info to select the "right" ones? (There isn't any guarantee that *any* N > of the M streams will provide a reasonable rendering. > > [Espen] A receiver requesting 2x streams to be rendered left, right, > will rely on the media sender to give a decent experience. E.g. the most > capable endpoint must translate its capabilities down to what lesser > capable room can do. > > This would be improved if we had a mechanism for the recipient to state > "I can only handle N streams" and the sender was obligated to meet that > constraint. I don't think we have said that. > > [Espen] I see this as an important use case for interoperability. Its > fine for capable Telepresence room to do a advanced CLUE advertisement, > as long as there is an easy and straightforward way to request two > captures screens for left, right placed monitors. > > We should have a use cases to express that we want to support endpoints > that only support asking for 1 - N streams, rendered left to right. > > Cheers > > -Espen > > > From magnus.westerlund@ericsson.com Fri Apr 13 08:23:42 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9E921F8631 for ; Fri, 13 Apr 2012 08:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.196 X-Spam-Level: X-Spam-Status: No, score=-106.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz9mwitnRNIk for ; Fri, 13 Apr 2012 08:23:41 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDBC21F85F6 for ; Fri, 13 Apr 2012 08:23:41 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-26-4f8844fb752e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3F.1A.25560.BF4488F4; Fri, 13 Apr 2012 17:23:40 +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.213.0; Fri, 13 Apr 2012 17:23:35 +0200 Message-ID: <4F8844F6.1080104@ericsson.com> Date: Fri, 13 Apr 2012 17:23:34 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "rai-ads@tools.ietf.org" , Ted Hardie , clue Subject: Re: [clue] Fwd: [rtcweb] Dates for upcoming interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 15:23:42 -0000 Mary, CLUE WG On 2012-04-12 18:07, Mary Barnes wrote: > No, unfortunately, the RTCWEB folks made a decision that was based on > who was available and they didn't count maybes, which would have put the > total the highest for Thursday the 7th, which would have allowed CLUE to > meet on the 5th and 6th, which is our 2nd optimal date. Since the 6th > is our half-day meeting, folks that needed to be off on the 6th wouldn't > miss as much and we could organize the agenda to maximize their > participation. However, the RTCWEB folks made their decision without > consulting with the CLUE WG chairs. Note, also that their choice > results in not having one of the area directors at their meeting, which > also doesn't make sense to me. Also, not having the CLUE and RTCWEB > meetings co-located means that some folks will not be at the CLUE > meeting and given the number of drafts that one of the individuals has > that potentially apply to the CLUE solution, it's extremely unfortunate. I want to start with saying sorry this hasn't worked out as desired. My individual position but with the knowledge of what we RTCWEB chair has discussed. I have to say that there are several additional constraints. First of all RTCWEB are co-locating with the W3C WebRTC WG. As they want a full day and RTCWEB WG want 2 days we need three consecutive days. That isn't available the week of 4-7th of June. In addition there is a W3C official requirement on announcing events 8 weeks ahead of time. That we can meet by having RTCWEB meet 12-13 and WebRTC the 11th. We do however have to rank co-location with our sister organization higher than ensuring that CLUE WG worked out the best way. It is unfortunate with the AD, but the rest of the considerations do appear to weigh more heavily in my personal view. > It looks like June 7th and 8th are optimal for CLUE. The only problem > with that choice is that the 6th is a Swedish holiday, so it is very > unfortunate that some of the folks based in Sweden may find this > problematic. We have a couple options: > 1) We do another poll that includes the dates we originally skipped in > trying to co-locate with RTCWEB. If the folks that are impacted by the > need to travel on the 6th could let the chairs know then we can decide > if we should run another (short/quick poll). We also need to do a poll > for location, however, I would first like folks that are willing to host > to let the chairs know, which leads to our 2nd option if the 6th really > is a problem: > 2) Meet in Stockholm as that does allow the folks in Sweden to avoid > travel on the 6th, but we need a host and we need to see if the majority > can travel there. Ericsson is willing to host also the CLUE WG interim meeting in Stockholm. I think having CLUE meet in Stockholm on the 7th and 8th at least allows the individual that want to participate in both CLUE and RTCWEB/WEBRTC to avoid having to travel to two locations. Yes, it becomes a weekend away. But I know that I prefer a weekend in a foreign city to spend it on airplanes. 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 mary.ietf.barnes@gmail.com Fri Apr 13 09:50:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1051311E8088 for ; Fri, 13 Apr 2012 09:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.61 X-Spam-Level: X-Spam-Status: No, score=-103.61 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9p0bD-w4DOn for ; Fri, 13 Apr 2012 09:50:55 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1F2C11E8086 for ; Fri, 13 Apr 2012 09:50:54 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2611701vbb.31 for ; Fri, 13 Apr 2012 09:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b0QO+i81ihv8zP/0opuHlFyqTvk89QhCOr3kO8o+AMw=; b=bPG/Ulrge704+oyM8rgUGcee0IkrPUF6tHU0Ess+ehyEeDAasNa+HsLQhrf4vmfzG7 VBYi/AnAsjk2LeqK7FRUMVb3C2IbnYGKRFJibDaPMTfbdfYWp3f1eptkYRbE0ribNs1i /CIsoJMxBMp/i1hkuyRw7KDELnOK5V+KeV8JMWCHoBekxyPLFA/zuUvcPsXQ/RLC68Am LyMjxZYH10/Xx+lYrg2WO8kYaxfbFBBpVEJhnKhlMI7ytuDkcSnDKsMK647WhdNHVoW3 uAjraVT7JeF/TYq0ssbj3a1rNH65D/kQVkhmNP2S2L4xOnHiUr1rqMnLhTaSXVps2eix Bl0g== MIME-Version: 1.0 Received: by 10.220.38.200 with SMTP id c8mr1119788vce.28.1334335854280; Fri, 13 Apr 2012 09:50:54 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Fri, 13 Apr 2012 09:50:54 -0700 (PDT) In-Reply-To: <4F8844F6.1080104@ericsson.com> References: <4F8844F6.1080104@ericsson.com> Date: Fri, 13 Apr 2012 11:50:54 -0500 Message-ID: From: Mary Barnes To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec54ee6be9afed904bd9246c8 Cc: Cullen Jennings , "rai-ads@tools.ietf.org" , Ted Hardie , clue Subject: Re: [clue] Fwd: [rtcweb] Dates for upcoming interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:50:56 -0000 --bcaec54ee6be9afed904bd9246c8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks. I agree this should be workable. As a reminder to folks in the CLUE WG, please respond to the doodle with regards to the location: http://www.doodle.com/wwrdycma9ymrdn3r As I previously, noted please put a no for Stockholm if you absolutely/positively can't get there. I will note that I did an initial check of airfares and while I know that it's variable depending upon your locale, I can fly to Stockholm (for both meetings) for less than half what it would cost me to fly to Boston (for a CLUE meeting) and then on to Stockholm for the RTCWEB meeting. Thanks, Mary. On Fri, Apr 13, 2012 at 10:23 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Mary, CLUE WG > > On 2012-04-12 18:07, Mary Barnes wrote: > > No, unfortunately, the RTCWEB folks made a decision that was based on > > who was available and they didn't count maybes, which would have put th= e > > total the highest for Thursday the 7th, which would have allowed CLUE t= o > > meet on the 5th and 6th, which is our 2nd optimal date. Since the 6th > > is our half-day meeting, folks that needed to be off on the 6th wouldn'= t > > miss as much and we could organize the agenda to maximize their > > participation. However, the RTCWEB folks made their decision without > > consulting with the CLUE WG chairs. Note, also that their choice > > results in not having one of the area directors at their meeting, which > > also doesn't make sense to me. Also, not having the CLUE and RTCWEB > > meetings co-located means that some folks will not be at the CLUE > > meeting and given the number of drafts that one of the individuals has > > that potentially apply to the CLUE solution, it's extremely unfortunate= . > > I want to start with saying sorry this hasn't worked out as desired. > > My individual position but with the knowledge of what we RTCWEB chair > has discussed. I have to say that there are several additional > constraints. First of all RTCWEB are co-locating with the W3C WebRTC WG. > As they want a full day and RTCWEB WG want 2 days we need three > consecutive days. That isn't available the week of 4-7th of June. In > addition there is a W3C official requirement on announcing events 8 > weeks ahead of time. That we can meet by having RTCWEB meet 12-13 and > WebRTC the 11th. We do however have to rank co-location with our sister > organization higher than ensuring that CLUE WG worked out the best way. > > It is unfortunate with the AD, but the rest of the considerations do > appear to weigh more heavily in my personal view. > > > > It looks like June 7th and 8th are optimal for CLUE. The only problem > > with that choice is that the 6th is a Swedish holiday, so it is very > > unfortunate that some of the folks based in Sweden may find this > > problematic. We have a couple options: > > 1) We do another poll that includes the dates we originally skipped in > > trying to co-locate with RTCWEB. If the folks that are impacted by the > > need to travel on the 6th could let the chairs know then we can decide > > if we should run another (short/quick poll). We also need to do a poll > > for location, however, I would first like folks that are willing to hos= t > > to let the chairs know, which leads to our 2nd option if the 6th really > > is a problem: > > 2) Meet in Stockholm as that does allow the folks in Sweden to avoid > > travel on the 6th, but we need a host and we need to see if the majorit= y > > can travel there. > > Ericsson is willing to host also the CLUE WG interim meeting in Stockholm= . > > I think having CLUE meet in Stockholm on the 7th and 8th at least allows > the individual that want to participate in both CLUE and RTCWEB/WEBRTC > to avoid having to travel to two locations. Yes, it becomes a weekend > away. But I know that I prefer a weekend in a foreign city to spend it > on airplanes. > > 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 > ---------------------------------------------------------------------- > > --bcaec54ee6be9afed904bd9246c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks. =A0I agree this should be workable. =A0As a reminder to folks in th= e CLUE WG, please respond to the doodle with regards to the location:
<= a href=3D"http://www.doodle.com/wwrdycma9ymrdn3r">http://www.doodle.com/wwr= dycma9ymrdn3r

As I previously, noted please put a no for Stockholm if= you absolutely/positively can't get there. =A0I will note that I did a= n initial check of airfares and while I know that it's variable dependi= ng upon your locale, I can fly to Stockholm (for both meetings) for less th= an half what it would cost me to fly to Boston (for a CLUE meeting) and the= n on to Stockholm for the RTCWEB meeting.

Thanks,
Mary.=A0

On Fri, Apr 13, 2012 at 10:23 AM, Magnus Westerlund <ma= gnus.westerlund@ericsson.com> wrote:
Mary, CLUE WG

On 2012-04-12 18:07, Mary Barnes wrote:
> No, unfortunately, the RTCWEB folks made a decision that was based on<= br> > who was available and they didn't count maybes, which would have p= ut the
> total the highest for Thursday the 7th, which would have allowed CLUE = to
> meet on the 5th and 6th, which is our 2nd optimal date. =A0Since the 6= th
> is our half-day meeting, folks that needed to be off on the 6th wouldn= 't
> miss as much and we could organize the agenda to maximize their
> participation. =A0However, the RTCWEB folks made their decision withou= t
> consulting with the CLUE WG chairs. =A0 Note, also that their choice > results in not having one of the area directors at their meeting, whic= h
> also doesn't make sense to me. =A0Also, not having the CLUE and RT= CWEB
> meetings co-located means that some folks will not be at the CLUE
> meeting and given the number of drafts that one of the individuals has=
> that potentially apply to the CLUE solution, it's extremely unfort= unate.

I want to start with saying sorry this hasn't worked out as desir= ed.

My individual position but with the knowledge of what we RTCWEB chair
has discussed. I have to say that there are several additional
constraints. First of all RTCWEB are co-locating with the W3C WebRTC WG. As they want a full day and RTCWEB WG want 2 days we need three
consecutive days. That isn't available the week of 4-7th of June. In addition there is a W3C official requirement on announcing events 8
weeks ahead of time. That we can meet by having RTCWEB meet 12-13 and
WebRTC the 11th. We do however have to rank co-location with our sister
organization higher than ensuring that CLUE WG worked out the best way.

It is unfortunate with the AD, but the rest of the considerations do
appear to weigh more heavily in my personal view.


> It looks like June 7th and 8th are optimal for CLUE. =A0The only probl= em
> with that choice is that the 6th is a Swedish holiday, so it is very > unfortunate that some of the folks based in Sweden may find this
> problematic. We have a couple options:
> 1) We do another poll that includes the dates we originally skipped in=
> trying to co-locate with RTCWEB. If the folks that are impacted by the=
> need to travel on the 6th could let the chairs know then we can decide=
> if we should run another (short/quick poll). =A0We also need to do a p= oll
> for location, however, I would first like folks that are willing to ho= st
> to let the chairs know, which leads to our 2nd option if the 6th reall= y
> is a problem:
> 2) Meet in Stockholm as that does allow the folks in Sweden to avoid > travel on the 6th, but we need a host and we need to see if the majori= ty
> can travel there.

Ericsson is willing to host also the CLUE WG interim meeting in Stock= holm.

I think having CLUE meet in Stockholm on the 7th and 8th at least allows the individual that want to participate in both CLUE and RTCWEB/WEBRTC
to avoid having to travel to two locations. Yes, it becomes a weekend
away. But I know that I prefer a weekend in a foreign city to spend it
on airplanes.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287=
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--bcaec54ee6be9afed904bd9246c8-- From marshall.eubanks@gmail.com Fri Apr 13 10:03:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A8C11E8080 for ; Fri, 13 Apr 2012 10:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3xEOEIo-POn for ; Fri, 13 Apr 2012 10:03:23 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2066E21F8467 for ; Fri, 13 Apr 2012 10:03:22 -0700 (PDT) Received: by lagj5 with SMTP id j5so2766778lag.31 for ; Fri, 13 Apr 2012 10:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=anQQp9g/AnF7EhHnVVIG0a3UGDhWslNsL9pCDcQQa8k=; b=ikly4Jr221O4hCiahc5b8akG9KPVArYPM+FVH2J7BvBCFWWib+bPZ69SgmUSINEth8 387TbaD1zt3rjEbvdg5TYSa6e2kis5V2Ou06xG3n5EPfi63pmZm1dPI97JV1A7oV3fOU V6csHiIFxtr7gW/M9Wijg+Ney2MUlnpMZ/BMx8QjQ6C+Q0DT/FFtZGHG/B7AZhlEBBdM gt5o9zZO90rTJ0EqBEpKg4yADdwmAyH0kijvTdaypdmVTFf/9zbXF0vdg7woOH5qGni7 lfgHFaxsyMV4pHoGeYBYbzmDZaaG/NszP5XggP1Ky5kMdvUPMIjiZZCcHSsOlfDm+26E 5dkg== MIME-Version: 1.0 Received: by 10.152.132.166 with SMTP id ov6mr2297278lab.35.1334336602093; Fri, 13 Apr 2012 10:03:22 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Fri, 13 Apr 2012 10:03:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Apr 2012 13:03:22 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [clue] Fwd: Internet2 Introduces Video Services Participation for all Members X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:03:24 -0000 This is partially a FYI to the group, but also I wonder if we couldn't convince them to be beta testers for us in the future. Regards Marshall ---------- Forwarded message ---------- From: Ben Fineman Date: Fri, Apr 13, 2012 at 10:36 AM Subject: Internet2 Introduces Video Services Participation for all Members To: "megacon@lists.acs.ohio-state.edu List" Community collaboration is critical to the collective advancement of research and education. To better facilitate this goal, today I am excited to announce the inclusion of basic Video Services as yet another benefit of Internet2 membership. Along with the upcoming addition of Cisco TelePresence Exchange services to the interoperable Internet2 Video Services environment, this benefit will enable better real-time collaboration for researchers and educators through access to dependable, high quality video communications. All dues-paying Internet2 member institutions will be eligible to enroll as participants in our Video Services at no additional cost. This participation includes: =A0 =A0 =A0 =A0=95 A four screen Standard Virtual Room. Standard Virtual Ro= oms are interoperable with standards-based H.323, SIP, and TIP endpoints. These rooms leverage shared infrastructure and access during peak usage periods is not guaranteed. =A0 =A0 =A0 =A0=95 Up to ten direct endpoint registrations. These endpoints= can be H.323 today, or SIP including Cisco TelePresence coming in May. =A0 =A0 =A0 =A0=95 Unlimited endpoint registrations for members who aggrega= te endpoints through their own infrastructure. We will announce more details at the Internet2 Video Services Forum in Arlington, VA and begin accepting applications for participation in May. In the meantime, please find more information at http://commons.internet2.edu/, or email me with any questions. Regards, Ben /*----------------------- Benjamin J. Fineman Manager, Internet2 Video Services bfineman@internet2.edu (Email and XMPP) http://www.internet2.edu 734.352.4975=A0(desk) 734.417.0811=A0(mobile) -----------------------*/ From marshall.eubanks@gmail.com Fri Apr 13 11:14:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39A911E809B for ; Fri, 13 Apr 2012 11:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 572zq6budhM3 for ; Fri, 13 Apr 2012 11:14:25 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F85611E8093 for ; Fri, 13 Apr 2012 11:14:25 -0700 (PDT) Received: by lagj5 with SMTP id j5so2814561lag.31 for ; Fri, 13 Apr 2012 11:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Lmmp95/kIjcJ7bDvOTbCwYBS5msJvm5nfOQoTOEBDzg=; b=LCbj8ALukc4+js4B4oJgVpqp+pAJbMvVTpw2XK8pbvqEd0YA4VC2XiXWyoZad49WyN wi+jYax1zH6G8dnwckVXSpdO7m2IxEuLf7jfbemH83V+5fwzDogj0NKkFDhnarNbZkfk dH6ja458v8eiipt2ymNs1eeMXh7cetPp1EVk+axAxW4w0WTWAabsizbKZlGOZOdxDYSe bT/9B7p0hlm15VW1UhK6AL39AVT3KvR0vDXLIXc1XU/QEo1sPt9cmUjQ+pN4iyPnkNdM IBqSatJfEAwEEudBu52zrH2Sxwyd98OCvTPYO5W5lyqPOQ7iBmnpOSgZNximpCi7QBAJ q5WQ== MIME-Version: 1.0 Received: by 10.112.49.136 with SMTP id u8mr1245083lbn.2.1334340864122; Fri, 13 Apr 2012 11:14:24 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Fri, 13 Apr 2012 11:14:24 -0700 (PDT) Date: Fri, 13 Apr 2012 14:14:24 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] RTCWEB / CLUE Use Cases for Browser - Telepresence Interoperability X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:14:27 -0000 I am posting this to both CLUE and RTCWEB. I am not sure which (if either) WG would want to adopt it, but I think both should see it. If this gains traction, I will make sure both WG are kept abreast of developments. Regards Marshall RTCWEB / CLUE Use Cases for Browser - Telepresence Interoperability References : RTCWEB Use Cases and Requirements : http://www.ietf.org/id/draft-ietf-rtcweb-use-cases-and-requirements-07.txt CLUE : Use Cases for Telepresence Multi-streams http://www.ietf.org/id/draft-ietf-clue-telepresence-use-cases-02.txt What follows is a first-cut at use cases for interoperability between a browser based videoconferencing system and Telepresence videoconferencing. This is an attempt to describe what should be done, without specifying in detail how. I have seen all of the below in the field, with Cases 1-T, 1-R.c and 2-R.b being the most widely supported. These cases are similar to the 4.2.10 use case in ID.draft-ietf-rtcweb-use-cases-and-requirements, but of course in the telepresence scenario there is a set of CLUE semantics overlaid on the basic display of screens. In this scenario, the browser is more likely to require higher level protocol changes than the telepresence units but, of course, the telepresence units or middleware MUST be able to accommodate RTCWEB codec and signaling choices. Base scenario. There are one or more browser based videoconferencing systems and one or more telepresence systems (each with at least two cameras and two screens) participating in an immersive-telepresence videoconferencing session. This may or may not require middleware (a server or MCU) to accomplish, both use cases with and without middleware SHOULD be supported. The telepresence units themselves are assumed to use CLUE and underlying protocols to decide suitable bit rates, resolutions, etc., between themselves; intra-telepresence negotiations are not in scope for this text. In telepresence, "screen" and "stream" are used more or less interchangeably, and will be done so here. In the base scenario, there are thus at least 3 screens (streams); conferences with 9 or more streams are not unusual, and conferences with dozens or even hundreds of streams are a commercial reality. It is useful to divide use cases between Transmission (T, what the browser sends) and Reception (R, what it receives). Browser based units SHOULD be able to decide between transmission and reception use cases independently, depending on capabilities and user choices. Case 1 : The one screen use case. In Case 1, it is possible for a CLUE Telepresence session and a browser to interact without any knowledge of CLUE on the part of the browser (i.e., by a telepresence unit or middleware acting as a single point videoconferencing unit). Such "Clueless" conferencing sessions are not in scope for this text. Case 1-Transmission : The browser sends one screen at the screen characteristics of the participating telepresence units or, failing that, at the maximum resolution and bandwidth it is capable or authorized to do so. Likewise, audio SHOULD be sent at the bit rate and using the codec negotiated by the CLUE telepresence session. Case 1 audio SHOULD be sent in mono. The browser MUST be able to use CLUE to negotiate these characteristics (which may change with time), and SHOULD be able to provide whatever meta-data is required by CLUE (e.g., the user's name or location). The browser may be one complete screen in the remote telepresence units. If care is taken by the browser user and software (for example, by matching head size and camera angle compared to the standards of the participating telepresence units, together with sufficient audio and video quality and resolution), the browser image and sound may approach immersive telepresence on the remote ends. (It would be useful if the system provided feedback or even automated zoom in/out to help with this adjustment for remote immersion. I have seen this done manually, but this has not to my knowledge been discussed to date in CLUE.) In the case of lower quality browser transmitted video, the receiving telepresence units may chose to display such videos in a composited form, with multiple browser transmissions sharing one screen. (This is common with low quality video from multiple browser-based participants.) Case 1-Reception : The browser displays one screen for all of the remote telepresence units. The browser receives one screen at the screen characteristics of the participating telepresence units or, failing that, at the maximum resolution and bandwidth it is capable of. Likewise, it SHOULD be able to receive audio at the bit rate and using the codec negotiated by the CLUE telepresence session. The browser MUST be able to negotiate these characteristics (which may change with time) using CLUE. In all Case 1-R sub cases, the browser MAY also display "thumbnail" (i.e., substantially reduced) images of other screens. These thumbnails might be shown for all screens, or for recently active screens (e.g., the last speaker), or for some static choice (e.g., the conference chair). The browser SHOULD be able to signal its desire / need to receive such thumbnails. Sub Case 1-R a : Static. The browser displays one screen only, as selected by the user or by some other method. (A simultaneous translator, for example, may prefer only to see the screen attached to their assigned speaker, regardless of whether or not they are speaking.) Sub Case 1-R b : Switching. The browser displays the "active" stream, typically of the current speaker. The browser MUST be able to switch rapidly between resolutions and other stream configuration choices, say if the active screen switches between a telepresence unit and another browser's transmission. Sub Case 1-R c : Compositing. The browser displays one screen, consisting of a static compositing of all (or conceivably a selection) of the other screens. This MAY indicate the active speaker (say, by highlighting them) and MAY display composited metadata (such as the attendees in each sub-screen, or their location). (If this display is an NxM matrix of equal size sub-screens, this display type is frequently called "Hollywood Squares," but other choices are possible.) In general this will be a static screen assignment, which MAY change with time (e.g., as participants come and go from the conference). This compositing could be done by the browser, but in current practice will most likely be done by either a telepresence unit or by middleware. Case 2 : Multiple Screens. The browser sends and/or receives multiple screens at the maximum resolution and bandwidth it is capable or authorized to do so. (This case is NOT intended to cover "thumbnail" sub screens, which may be sent or received in this case as well.) Case 2-Transmission. The browser has access to multiple cameras and sends multiple images to remote participants. If care is taken by the browser user / software, the browser images may approach immersive telepresence on the remote ends. For this to happen in the multi-screen transmission case, the browser MUST be able to fully participate in CLUE protocol negotiations, identifying, for example, which screen is left, center and right in the case of a three camera transmission. In Case 2-T, the browser SHOULD send stereo or multi-channel audio and SHOULD format any such audio to match the transmitted screens, e.g., with the left audio corresponding to the left screen. Such audio choices, if made, MUST be indicated in the CLUE configuration setup. Case 2-Reception. The browser displays multiple screens based on the multiple screens available from other telepresence participants. Sub Case 2-R a : Switched compositing. In this use case typically one composited screen is shown, of some or all of the telepresence participants, together with one or more full-sized screens of the active participants (or, at times, of one static screen. Note that the composited screens may have higher sub-screen resolution than for thumbnails, or may have very different aspect ratios than is typical for thumbnails. For example, a three screen telepresence unit, with an individual screen aspect ratio of 16:9, may transmit a 48:9 aspect ratio composite of all its screens in the proper display order. Several such composites could be combined into a single 16:9 aspect ratio to make the composited screen in this use case. This use case includes multiple screens for selected speakers, for example a composited screen to the left, the conference moderator in larger resolution in the center, and (also in larger resolution) the current or previous speaker (should the moderator be currently speaking) on the right. In Case 2-R a, the browser SHOULD display screens and use stereo or multi-channel audio conforming to the CLUE configuration, with (in the above example), the conference moderator being assigned the center audio channel and the current or previous speaker the right audio channel. Sub Case 2-R b : Telepresence mimicry. The browser displays screens as if it were a telepresence unit involved in the telepresence session. The browser MUST be able to fully participate in the CLUE protocol, displaying, for example, left screens on the left and center screens on the center. In general, these screens will be displayed at the same aspect ratio, but with lower size / resolution, than in the full telepresence session. Experience shows that, for participants who are used to multi-screen telepresence, even lesser quality telepresence mimicry is very popular and RTCWEB / CLUE SHOULD support this full telepresence functionality. At the high end of browser capabilities, the full resolution and bit rates available could be used to approach a truly immersive telepresence at the browser receive side; this is likely to become more common in the future. In Case 2-R b, the browser SHOULD display screens and stereo or multi-channel audio conforming to the CLUE configuration, with, e.g., the left audio channel corresponding to the left screen, etc. From bfineman@internet2.edu Fri Apr 13 11:19:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201A921F85F0 for ; Fri, 13 Apr 2012 11:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6d3GZc23M-E for ; Fri, 13 Apr 2012 11:19:23 -0700 (PDT) Received: from int-proxy01.merit.edu (int-proxy01.merit.edu [207.75.116.230]) by ietfa.amsl.com (Postfix) with ESMTP id 3B55421F85D1 for ; Fri, 13 Apr 2012 11:19:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy01.merit.edu (Postfix) with ESMTP id A3D1610005D; Fri, 13 Apr 2012 14:19:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at int-proxy01.merit.edu Received: from int-proxy01.merit.edu ([127.0.0.1]) by localhost (int-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19AoeQ4k9h1z; Fri, 13 Apr 2012 14:19:19 -0400 (EDT) Received: from eduroam-wlan-63.internet2.edu (eduroam-wlan-63.internet2.edu [198.108.5.63]) by int-proxy01.merit.edu (Postfix) with ESMTPSA id 0AB8B100026; Fri, 13 Apr 2012 14:19:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_B7C5B955-B223-4B6D-A9D2-2C5ED9B96616" From: Ben Fineman In-Reply-To: Date: Fri, 13 Apr 2012 14:19:18 -0400 Message-Id: <28CD2660-1351-4CFB-BAE9-E6E518644CE2@internet2.edu> References: To: Marshall Eubanks X-Mailer: Apple Mail (2.1257) Cc: clue Subject: Re: [clue] Fwd: Internet2 Introduces Video Services Participation for all Members X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:19:24 -0000 --Apple-Mail=_B7C5B955-B223-4B6D-A9D2-2C5ED9B96616 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Marshall, I'm a lurker on this list, but I will say that a core part of = Internet2's mission in the video space is to promote interoperability = and standards. I will be pleased to do what I can to help with the = adoption of CLUE.=20 It's been some time since we had an Internet2 Member Meeting session on = telepresence interoperability as well - I would be interested in working = with folks to put together a session proposal for the Fall Internet2 = Member Meeting on CLUE if there is interest. Regards, Ben /*----------------------- Benjamin J. Fineman Manager, Internet2 Video Services bfineman@internet2.edu (Email and XMPP) http://www.internet2.edu 734.352.4975 (desk) 734.417.0811 (mobile) -----------------------*/ On Apr 13, 2012, at 1:03 PM, Marshall Eubanks wrote: > This is partially a FYI to the group, but also I wonder if we couldn't > convince them to be beta testers for us in the future. >=20 > Regards > Marshall >=20 >=20 > ---------- Forwarded message ---------- > From: Ben Fineman > Date: Fri, Apr 13, 2012 at 10:36 AM > Subject: Internet2 Introduces Video Services Participation for all = Members > To: "megacon@lists.acs.ohio-state.edu List" = >=20 >=20 > Community collaboration is critical to the collective advancement of > research and education. To better facilitate this goal, today I am > excited to announce the inclusion of basic Video Services as yet > another benefit of Internet2 membership. Along with the upcoming > addition of Cisco TelePresence Exchange services to the interoperable > Internet2 Video Services environment, this benefit will enable better > real-time collaboration for researchers and educators through access > to dependable, high quality video communications. >=20 > All dues-paying Internet2 member institutions will be eligible to > enroll as participants in our Video Services at no additional cost. > This participation includes: >=20 > =95 A four screen Standard Virtual Room. Standard Virtual Rooms > are interoperable with standards-based H.323, SIP, and TIP endpoints. > These rooms leverage shared infrastructure and access during peak > usage periods is not guaranteed. > =95 Up to ten direct endpoint registrations. These endpoints = can > be H.323 today, or SIP including Cisco TelePresence coming in May. > =95 Unlimited endpoint registrations for members who aggregate > endpoints through their own infrastructure. >=20 > We will announce more details at the Internet2 Video Services Forum in > Arlington, VA and begin accepting applications for participation in > May. In the meantime, please find more information at > http://commons.internet2.edu/, or email me with any questions. >=20 > Regards, > Ben >=20 > /*----------------------- > Benjamin J. Fineman > Manager, Internet2 Video Services >=20 > bfineman@internet2.edu (Email and XMPP) > http://www.internet2.edu >=20 > 734.352.4975 (desk) > 734.417.0811 (mobile) > -----------------------*/ > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --Apple-Mail=_B7C5B955-B223-4B6D-A9D2-2C5ED9B96616 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Marshall,

I'm a lurker on this list, but I will say = that a core part of Internet2's mission in the video space is to promote = interoperability and standards. I will be pleased to do what I can to = help with the adoption of CLUE. 

It's been = some time since we had an Internet2 Member Meeting session on = telepresence interoperability as well - I would be interested in working = with folks to put together a session proposal for the Fall Internet2 = Member Meeting on CLUE if there is = interest.

Regards,
Ben

/*-----------------------
Benjamin J. = Fineman
Manager, Internet2 Video Services

bfineman@internet2.edu (Email = and XMPP)
http://www.internet2.edu

734.= 352.4975 (desk)
734.417.0811 = (mobile)
-----------------------*/
=
=

On Apr 13, 2012, at 1:03 PM, Marshall Eubanks = wrote:

This is partially a FYI to the group, but also I = wonder if we couldn't
convince them to be beta testers for us in the = future.

Regards
Marshall


---------- Forwarded = message ----------
From: Ben Fineman <bfineman@internet2.edu>
D= ate: Fri, Apr 13, 2012 at 10:36 AM
Subject: Internet2 Introduces = Video Services Participation for all Members
To: "megacon@lists.acs.ohio-st= ate.edu List" <megacon@lists.acs.ohio-st= ate.edu>


Community collaboration is critical to the = collective advancement of
research and education. To better = facilitate this goal, today I am
excited to announce the inclusion of = basic Video Services as yet
another benefit of Internet2 membership. = Along with the upcoming
addition of Cisco TelePresence Exchange = services to the interoperable
Internet2 Video Services environment, = this benefit will enable better
real-time collaboration for = researchers and educators through access
to dependable, high quality = video communications.

All dues-paying Internet2 member = institutions will be eligible to
enroll as participants in our Video = Services at no additional cost.
This participation = includes:

       =95 A four screen Standard = Virtual Room. Standard Virtual Rooms
are interoperable with = standards-based H.323, SIP, and TIP endpoints.
These rooms leverage = shared infrastructure and access during peak
usage periods is not = guaranteed.
       =95 Up to ten direct endpoint = registrations. These endpoints can
be H.323 today, or SIP including = Cisco TelePresence coming in May.
       =95 = Unlimited endpoint registrations for members who aggregate
endpoints = through their own infrastructure.

We will announce more details = at the Internet2 Video Services Forum in
Arlington, VA and begin = accepting applications for participation in
May. In the meantime, = please find more information at
http://commons.internet2.edu/, = or email me with any = questions.

Regards,
Ben

/*-----------------------
Benj= amin J. Fineman
Manager, Internet2 Video Services

bfineman@internet2.edu (Email = and XMPP)
http://www.internet2.edu

734.= 352.4975 (desk)
734.417.0811 (mobile)
--------------------= ---*/
_______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

= --Apple-Mail=_B7C5B955-B223-4B6D-A9D2-2C5ED9B96616-- From pkyzivat@alum.mit.edu Fri Apr 13 11:33:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B157B21F8546 for ; Fri, 13 Apr 2012 11:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwYJIot1bbPC for ; Fri, 13 Apr 2012 11:33:49 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 6459021F8528 for ; Fri, 13 Apr 2012 11:33:49 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta15.westchester.pa.mail.comcast.net with comcast id xWZ21i0040EZKEL5FWZp9z; Fri, 13 Apr 2012 18:33:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta01.westchester.pa.mail.comcast.net with comcast id xWZp1i00607duvL3MWZp7w; Fri, 13 Apr 2012 18:33:49 +0000 Message-ID: <4F88718B.7050104@alum.mit.edu> Date: Fri, 13 Apr 2012 14:33:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] RTCWEB / CLUE Use Cases for Browser - Telepresence Interoperability X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:33:50 -0000 On 4/13/12 2:14 PM, Marshall Eubanks wrote: > I am posting this to both CLUE and RTCWEB. I am not sure which (if > either) WG would want to adopt it, but I think both should see it. If > this gains traction, I > will make sure both WG are kept abreast of developments. > > Regards > Marshall Marshall, Thanks for posting this. In Case 1 you say: 'Such "Clueless" conferencing sessions are not in scope for this text.' Yet you go on and detail it. What is your thinking here? Thanks, Paul > RTCWEB / CLUE Use Cases for Browser - Telepresence Interoperability > > References : > > RTCWEB Use Cases and Requirements : > http://www.ietf.org/id/draft-ietf-rtcweb-use-cases-and-requirements-07.txt > > CLUE : Use Cases for Telepresence Multi-streams > http://www.ietf.org/id/draft-ietf-clue-telepresence-use-cases-02.txt > > What follows is a first-cut at use cases for interoperability between > a browser based videoconferencing system and Telepresence > videoconferencing. This is an attempt to describe what should be done, > without specifying in detail how. I have seen all of the below in the > field, with Cases 1-T, 1-R.c and 2-R.b being the most widely > supported. These cases are similar to the 4.2.10 use case in > ID.draft-ietf-rtcweb-use-cases-and-requirements, but of course in the > telepresence scenario there is a set of CLUE semantics overlaid on the > basic display of screens. In this scenario, the browser is more likely > to require higher level protocol changes than the telepresence units > but, of course, the telepresence units or middleware MUST be able to > accommodate RTCWEB codec and signaling choices. > > Base scenario. There are one or more browser based videoconferencing > systems and one or more telepresence systems (each with at least two > cameras and two screens) participating in an immersive-telepresence > videoconferencing session. This may or may not require middleware (a > server or MCU) to accomplish, both use cases with and without > middleware SHOULD be supported. The telepresence units themselves are > assumed to use CLUE and underlying protocols to decide suitable bit > rates, resolutions, etc., between themselves; intra-telepresence > negotiations are not in scope for this text. In telepresence, "screen" > and "stream" are used more or less interchangeably, and will be done > so here. In the base scenario, there are thus at least 3 screens > (streams); conferences with 9 or more streams are not unusual, and > conferences with dozens or even hundreds of streams are a commercial > reality. > > It is useful to divide use cases between Transmission (T, what the > browser sends) and Reception (R, what it receives). Browser based > units SHOULD be able to decide between transmission and reception use > cases independently, depending on capabilities and user choices. > > Case 1 : The one screen use case. > > In Case 1, it is possible for a CLUE Telepresence session and a > browser to interact without any knowledge of CLUE on the part of the > browser (i.e., by a telepresence unit or middleware acting as a > single point videoconferencing unit). Such "Clueless" conferencing > sessions are not in scope for this text. > > Case 1-Transmission : The browser sends one screen at the screen > characteristics of the participating telepresence units or, failing > that, at the maximum resolution and bandwidth it is capable or > authorized to do so. Likewise, audio SHOULD be sent at the bit rate > and using the codec negotiated by the CLUE telepresence session. Case > 1 audio SHOULD be sent in mono. The browser MUST be able to use CLUE > to negotiate these characteristics (which may change with time), and > SHOULD be able to provide whatever meta-data is required by CLUE > (e.g., the user's name or location). > > The browser may be one complete screen in the remote telepresence > units. If care is taken by the browser user and software (for example, > by matching head size and camera angle compared to the standards of > the participating telepresence units, together with sufficient audio > and video quality and resolution), the browser image and sound may > approach immersive telepresence on the remote ends. (It would be > useful if the system provided feedback or even automated zoom in/out > to help with this adjustment for remote immersion. I have seen this > done manually, but this has not to my knowledge been discussed to date > in CLUE.) > > In the case of lower quality browser transmitted video, the receiving > telepresence units may chose to display such videos in a composited > form, with multiple browser transmissions sharing one screen. (This is > common with low quality video from multiple browser-based > participants.) > > Case 1-Reception : The browser displays one screen for all of the > remote telepresence units. The browser receives one screen at the > screen characteristics of the participating telepresence units or, > failing that, at the maximum resolution and bandwidth it is capable > of. Likewise, it SHOULD be able to receive audio at the bit rate and > using the codec negotiated by the CLUE telepresence session. The > browser MUST be able to negotiate these characteristics (which may > change with time) using CLUE. > > In all Case 1-R sub cases, the browser MAY also display "thumbnail" > (i.e., substantially reduced) images of other screens. These > thumbnails might be shown for all screens, or for recently active > screens (e.g., the last speaker), or for some static choice (e.g., the > conference chair). The browser SHOULD be able to signal its desire / > need to receive such thumbnails. > > Sub Case 1-R a : Static. The browser displays one screen only, as > selected by the user or by some other method. (A simultaneous > translator, for example, may prefer only to see the screen attached to > their assigned speaker, regardless of whether or not they are > speaking.) > > Sub Case 1-R b : Switching. The browser displays the "active" stream, > typically of the current speaker. The browser MUST be able to switch > rapidly between resolutions and other stream configuration choices, > say if the active screen switches between a telepresence unit and > another browser's transmission. > > Sub Case 1-R c : Compositing. The browser displays one screen, > consisting of a static compositing of all (or conceivably a selection) > of the other screens. This MAY indicate the active speaker (say, by > highlighting them) and MAY display composited metadata (such as the > attendees in each sub-screen, or their location). (If this display is > an NxM matrix of equal size sub-screens, this display type is > frequently called "Hollywood Squares," but other choices are > possible.) In general this will be a static screen assignment, which > MAY change with time (e.g., as participants come and go from the > conference). This compositing could be done by the browser, but in > current practice will most likely be done by either a telepresence > unit or by middleware. > > Case 2 : Multiple Screens. The browser sends and/or receives multiple > screens at the maximum resolution and bandwidth it is capable or > authorized to do so. (This case is NOT intended to cover "thumbnail" > sub screens, which may be sent or received in this case as well.) > > Case 2-Transmission. The browser has access to multiple cameras and > sends multiple images to remote participants. If care is taken by the > browser user / software, the browser images may approach immersive > telepresence on the remote ends. For this to happen in the > multi-screen transmission case, the browser MUST be able to fully > participate in CLUE protocol negotiations, identifying, for example, > which screen is left, center and right in the case of a three camera > transmission. > > In Case 2-T, the browser SHOULD send stereo or multi-channel audio and > SHOULD format any such audio to match the transmitted screens, e.g., > with the left audio corresponding to the left screen. Such audio > choices, if made, MUST be indicated in the CLUE configuration setup. > > Case 2-Reception. The browser displays multiple screens based on the > multiple screens available from other telepresence participants. > > Sub Case 2-R a : Switched compositing. In this use case typically one > composited screen is shown, of some or all of the telepresence > participants, together with one or more full-sized screens of the > active participants (or, at times, of one static screen. Note that the > composited screens may have higher sub-screen resolution than for > thumbnails, or may have very different aspect ratios than is typical > for thumbnails. For example, a three screen telepresence unit, with an > individual screen aspect ratio of 16:9, may transmit a 48:9 aspect > ratio composite of all its screens in the proper display order. > Several such composites could be combined into a single 16:9 aspect > ratio to make the composited screen in this use case. This use case > includes multiple screens for selected speakers, for example a > composited screen to the left, the conference moderator in larger > resolution in the center, and (also in larger resolution) the current > or previous speaker (should the moderator be currently speaking) on > the right. In Case 2-R a, the browser SHOULD display screens and use > stereo or multi-channel audio conforming to the CLUE configuration, > with (in the above example), the conference moderator being assigned > the center audio channel and the current or previous speaker the right > audio channel. > > Sub Case 2-R b : Telepresence mimicry. The browser displays screens as > if it were a telepresence unit involved in the telepresence session. > The browser MUST be able to fully participate in the CLUE protocol, > displaying, for example, left screens on the left and center screens > on the center. In general, these screens will be displayed at the same > aspect ratio, but with lower size / resolution, than in the full > telepresence session. Experience shows that, for participants who are > used to multi-screen telepresence, even lesser quality telepresence > mimicry is very popular and RTCWEB / CLUE SHOULD support this full > telepresence functionality. At the high end of browser capabilities, > the full resolution and bit rates available could be used to approach > a truly immersive telepresence at the browser receive side; this is > likely to become more common in the future. > > In Case 2-R b, the browser SHOULD display screens and stereo or > multi-channel audio conforming to the CLUE configuration, with, e.g., > the left audio channel corresponding to the left screen, etc. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From marshall.eubanks@gmail.com Fri Apr 13 12:06:33 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2852411E8075 for ; Fri, 13 Apr 2012 12:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vcq1fdh9bOIQ for ; Fri, 13 Apr 2012 12:06:32 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 80C4311E807F for ; Fri, 13 Apr 2012 12:06:31 -0700 (PDT) Received: by lagj5 with SMTP id j5so2849337lag.31 for ; Fri, 13 Apr 2012 12:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QKqc5cIY3MWBY13JvSE/WKIUG6v8PAzsTX6618oS5Vo=; b=G1uHfelQFP7Z73rUukIzGe3uWnvlYVJgjSeY64L+VnOemOktfqjjQtHJNVk8ZuTFhz 2C6hTuwvSlnWDwRtPwPsmJLSS99iMNbzAhqrr9KmPQhHETHMNu6VDnOZJeGEBcZe4gvz t2s7IqLVv1HUs+sgr8KEXyUdxphOWwid8VFunC9WyCM82Kk6dq1N7uGsMxrzLIEcEaRw wvuodktWCheidqCIYbgDsKSaN84X/yi04zyyHfwl7GDmx+XoQh+ZdkhqEQ5mq2CNCJGL Msq58KnKMZh602FokFC8ViiCC1wnfb1E1dc98BdHDf/Jy41oHO28PMpFfCWnlFDfPFot FiUQ== MIME-Version: 1.0 Received: by 10.112.30.102 with SMTP id r6mr1291241lbh.30.1334343990457; Fri, 13 Apr 2012 12:06:30 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Fri, 13 Apr 2012 12:06:30 -0700 (PDT) In-Reply-To: <4F88718B.7050104@alum.mit.edu> References: <4F88718B.7050104@alum.mit.edu> Date: Fri, 13 Apr 2012 15:06:30 -0400 Message-ID: From: Marshall Eubanks To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: clue@ietf.org Subject: Re: [clue] RTCWEB / CLUE Use Cases for Browser - Telepresence Interoperability X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:06:33 -0000 On Fri, Apr 13, 2012 at 2:33 PM, Paul Kyzivat wrote= : > On 4/13/12 2:14 PM, Marshall Eubanks wrote: >> >> I am posting this to both CLUE and RTCWEB. I am not sure which (if >> either) WG would want to adopt it, but I think both should see it. If >> this gains traction, I >> will make sure both WG are kept abreast of developments. >> >> Regards >> Marshall > > > Marshall, > > Thanks for posting this. In Case 1 you say: 'Such "Clueless" conferencing > sessions are not in scope for this text.' Yet you go on and detail it. Wh= at > is your thinking here? > No, I distinguish (or am trying to distinguish) between - clueless 1 screen sessions, where the clueless end has no idea of what's really going on and -CLUEfull 1 screen sessions, where the browser end does have an idea of what's going on and might, for example, display the name of the speaker and negotiate display options just like a regular telepresence unit. (Note, by the way, that there are one screen telepresence units on the market. I would argue that whatever they do with CLUE, ideally we would want a 1 screen CLUEfull browser to do.) - The use of thumbnails (really, a special case of multiple screens) is likely to be common in 1 screen CLUE and not present in normal videoconferencing. Also, a CLUEfull 1 screen session may have to switch rapidly, even between formats, and surely that is not part of the usual videoconferencing session. Now, we may decide that all of that can be negotiated elsewhere, using existing tools. If so, so be it, and let's get that documented in a draft. regards Marshall > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> RTCWEB / CLUE Use Cases for Browser - Telepresence Interoperability >> >> References : >> >> RTCWEB Use Cases and Requirements : >> http://www.ietf.org/id/draft-ietf-rtcweb-use-cases-and-requirements-07.t= xt >> >> CLUE : =A0Use Cases for Telepresence Multi-streams >> http://www.ietf.org/id/draft-ietf-clue-telepresence-use-cases-02.txt >> >> What follows is a first-cut at use cases for interoperability between >> a browser based videoconferencing system and Telepresence >> videoconferencing. This is an attempt to describe what should be done, >> without specifying in detail how. I have seen all of the below in the >> field, with Cases 1-T, 1-R.c and 2-R.b being the most widely >> supported. These cases are similar to the 4.2.10 use case in >> ID.draft-ietf-rtcweb-use-cases-and-requirements, but of course in the >> telepresence scenario there is a set of CLUE semantics overlaid on the >> basic display of screens. In this scenario, the browser is more likely >> to require higher level protocol changes than the telepresence units >> but, of course, the telepresence units or middleware MUST be able to >> accommodate RTCWEB codec and signaling choices. >> >> Base scenario. There are one or more browser based videoconferencing >> systems and one or more telepresence systems (each with at least two >> cameras and two screens) participating in an immersive-telepresence >> videoconferencing session. This may or may not require middleware (a >> server or MCU) to accomplish, both use cases with and without >> middleware SHOULD be supported. The telepresence units themselves are >> assumed to use CLUE and underlying protocols to decide suitable bit >> rates, resolutions, etc., between themselves; intra-telepresence >> negotiations are not in scope for this text. In telepresence, "screen" >> and "stream" are used more or less interchangeably, and will be done >> so here. In the base scenario, there are thus at least 3 screens >> (streams); conferences with 9 or more streams are not unusual, and >> conferences with dozens or even hundreds of streams are a commercial >> reality. >> >> It is useful to divide use cases between Transmission (T, what the >> browser sends) and Reception (R, what it receives). Browser based >> units SHOULD be able to decide between transmission and reception use >> cases independently, depending on capabilities and user choices. >> >> Case 1 : The one screen use case. >> >> In Case 1, it is possible for a CLUE Telepresence session and a >> browser to interact without any knowledge of CLUE on the part of the >> browser (i.e., by a telepresence unit or middleware =A0acting as a >> single point videoconferencing unit). Such "Clueless" conferencing >> sessions are not in scope for this text. >> >> Case 1-Transmission : The browser sends one screen at the screen >> characteristics of the participating telepresence units or, failing >> that, at the maximum resolution and bandwidth it is capable or >> authorized to do so. Likewise, audio SHOULD be sent at the bit rate >> and using the codec negotiated by the CLUE telepresence session. Case >> 1 audio SHOULD be sent in mono. The browser MUST be able to use CLUE >> to negotiate these characteristics (which may change with time), and >> SHOULD be able to provide whatever meta-data is required by CLUE >> (e.g., the user's name or location). >> >> The browser may be one complete screen in the remote telepresence >> units. If care is taken by the browser user and software (for example, >> by matching head size and camera angle compared to the standards of >> the participating telepresence units, together with sufficient audio >> and video quality and resolution), the browser image and sound may >> approach immersive telepresence on the remote ends. (It would be >> useful if the system provided feedback or even automated zoom in/out >> to help with this adjustment for remote immersion. I have seen this >> done manually, but this has not to my knowledge been discussed to date >> in CLUE.) >> >> In the case of lower quality browser transmitted video, the receiving >> telepresence units may chose to display such videos in a composited >> form, with multiple browser transmissions sharing one screen. (This is >> common with low quality video from multiple browser-based >> participants.) >> >> Case 1-Reception : The browser displays one screen for all of the >> remote telepresence units. The browser receives one screen at the >> screen characteristics of the participating telepresence units or, >> failing that, at the maximum resolution and bandwidth it is capable >> of. Likewise, it SHOULD be able to receive audio at the bit rate and >> using the codec negotiated by the CLUE telepresence session. The >> browser MUST be able to negotiate these characteristics (which may >> change with time) using CLUE. >> >> In all Case 1-R sub cases, the browser MAY also display "thumbnail" >> (i.e., substantially reduced) images of other screens. These >> thumbnails might be shown for all screens, or for recently active >> screens (e.g., the last speaker), or for some static choice (e.g., the >> conference chair). The browser SHOULD be able to signal its desire / >> need to receive such thumbnails. >> >> Sub Case 1-R a : =A0Static. The browser displays one screen only, as >> selected by the user or by some other method. (A simultaneous >> translator, for example, may prefer only to see the screen attached to >> their assigned speaker, regardless of whether or not they are >> speaking.) >> >> Sub Case 1-R b : Switching. The browser displays the "active" stream, >> typically of the current speaker. The browser MUST be able to switch >> rapidly between resolutions and other stream configuration choices, >> say if the active screen switches between a telepresence unit and >> another browser's transmission. >> >> Sub Case 1-R c : Compositing. The browser displays one screen, >> consisting of a static compositing of all (or conceivably a selection) >> of the other screens. This MAY indicate the active speaker (say, by >> highlighting them) and MAY display composited metadata (such as the >> attendees in each sub-screen, or their location). (If this display is >> an NxM matrix of equal size sub-screens, this display type is >> frequently called "Hollywood Squares," but other choices are >> possible.) In general this will be a static screen assignment, which >> MAY change with time (e.g., as participants come and go from the >> conference). This compositing could be done by the browser, but in >> current practice will most likely be done by either a telepresence >> unit or by middleware. >> >> Case 2 : Multiple Screens. =A0The browser sends and/or receives multiple >> screens at the maximum resolution and bandwidth it is capable or >> authorized to do so. (This case is NOT intended to cover "thumbnail" >> sub screens, which may be sent or received in this case as well.) >> >> Case 2-Transmission. The browser has access to multiple cameras and >> sends multiple images to remote participants. If care is taken by the >> browser user / software, the browser images may approach immersive >> telepresence on the remote ends. For this to happen in the >> multi-screen transmission case, the browser MUST be able to fully >> participate in CLUE protocol negotiations, identifying, for example, >> which screen is left, center and right in the case of a three camera >> transmission. >> >> In Case 2-T, the browser SHOULD send stereo or multi-channel audio and >> SHOULD format any such audio to match the transmitted screens, e.g., >> with the left audio corresponding to the left screen. Such audio >> choices, if made, MUST be indicated in the CLUE configuration setup. >> >> Case 2-Reception. The browser displays multiple screens based on the >> multiple screens available from other telepresence participants. >> >> Sub Case 2-R a : Switched compositing. In this use case typically one >> composited screen is shown, of some or all of the telepresence >> participants, together with one or more full-sized screens of the >> active participants (or, at times, of one static screen. Note that the >> composited screens may have higher sub-screen resolution than for >> thumbnails, or may have very different aspect ratios than is typical >> for thumbnails. For example, a three screen telepresence unit, with an >> individual screen aspect ratio of 16:9, may transmit a 48:9 aspect >> ratio composite of all its screens in the proper display order. >> Several such composites could be combined into a single 16:9 aspect >> ratio to make the composited screen in this use case. This use case >> includes multiple screens for selected speakers, for example a >> composited screen to the left, the conference moderator in larger >> resolution in the center, and (also in larger resolution) the current >> or previous speaker (should the moderator be currently speaking) on >> the right. In Case 2-R a, the browser SHOULD display screens and use >> stereo or multi-channel audio conforming to the CLUE configuration, >> with (in the above example), the conference moderator being assigned >> the center audio channel and the current or previous speaker the right >> audio channel. >> >> Sub Case 2-R b : Telepresence mimicry. The browser displays screens as >> if it were a telepresence unit involved in the telepresence session. >> The browser MUST be able to fully participate in the CLUE protocol, >> displaying, for example, left screens on the left and center screens >> on the center. In general, these screens will be displayed at the same >> aspect ratio, but with lower size / resolution, than in the full >> telepresence session. Experience shows that, for participants who are >> used to multi-screen telepresence, even lesser quality telepresence >> mimicry is very popular and RTCWEB / CLUE SHOULD support this full >> telepresence functionality. =A0At the high end of browser capabilities, >> the full resolution and bit rates available could =A0be used to approach >> a truly immersive telepresence at the browser receive side; this is >> likely to become more common in the future. >> >> In Case 2-R b, the browser SHOULD display screens and stereo or >> multi-channel audio conforming to the CLUE configuration, with, e.g., >> the left audio channel corresponding to the left screen, etc. >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From marshall.eubanks@gmail.com Fri Apr 13 13:14:06 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C7321F85DF for ; Fri, 13 Apr 2012 13:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5gkJmCjT5A9 for ; Fri, 13 Apr 2012 13:14:05 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAC3E21F85DD for ; Fri, 13 Apr 2012 13:14:04 -0700 (PDT) Received: by lagj5 with SMTP id j5so2889753lag.31 for ; Fri, 13 Apr 2012 13:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sX+2YuaG32lrl25Y5las5GsfuO8GDNyFRYX6fiBQL4Q=; b=b7BzktN4Xn54a14b5N4vHel1BDecVcSQMZ/Fct56lt1xYsvat6wpQIWaJ7dazsDBEz Dk7q25wILgOQs8JsDXj4gwACSI/f6OUaT8cnEBgWbGUuwrbJUpyH5fnJjeFyNFkh1so+ tIFOKV/SqEvR4TXkZViSdBexvgYTVGvSVHLRG4WQ9adwEJL1Y30dHx3vnAxlDLE2xg7v SRtW/1IaLyq7TLOoj7GV8BAPKK+UBYRNKVbQaZ79iTcIvrtX/vJ/oTPSKZian1yTzugL MW6D7EPtnycCUlkH9cTUOioW+6eJ5J1X8hG/0ymofH/IjZXD440V+aDlI/LBh3wkklcw YH5Q== MIME-Version: 1.0 Received: by 10.152.106.9 with SMTP id gq9mr2651608lab.14.1334348043800; Fri, 13 Apr 2012 13:14:03 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Fri, 13 Apr 2012 13:14:03 -0700 (PDT) In-Reply-To: <28CD2660-1351-4CFB-BAE9-E6E518644CE2@internet2.edu> References: <28CD2660-1351-4CFB-BAE9-E6E518644CE2@internet2.edu> Date: Fri, 13 Apr 2012 16:14:03 -0400 Message-ID: From: Marshall Eubanks To: Ben Fineman Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: clue Subject: Re: [clue] Fwd: Internet2 Introduces Video Services Participation for all Members X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:14:06 -0000 On Fri, Apr 13, 2012 at 2:19 PM, Ben Fineman wrote= : > Hi Marshall, > > I'm a lurker on this list, but I will say that a core part of Internet2's > mission in the video space is to promote interoperability and standards. = I > will be pleased to do what I can to help with the adoption of CLUE. > > It's been some time since we had an Internet2 Member Meeting session on > telepresence interoperability as well - I would be interested in working > with folks to put together a session proposal for the Fall Internet2 Memb= er > Meeting on CLUE if there is interest. Dear Ben; I would be glad to help with that. Regards Marshall > > Regards, > Ben > > /*----------------------- > Benjamin J. Fineman > Manager, Internet2 Video Services > > bfineman@internet2.edu (Email and XMPP) > http://www.internet2.edu > > 734.352.4975 (desk) > 734.417.0811 (mobile) > -----------------------*/ > > On Apr 13, 2012, at 1:03 PM, Marshall Eubanks wrote: > > This is partially a FYI to the group, but also I wonder if we couldn't > convince them to be beta testers for us in the future. > > Regards > Marshall > > > ---------- Forwarded message ---------- > From: Ben Fineman > Date: Fri, Apr 13, 2012 at 10:36 AM > Subject: Internet2 Introduces Video Services Participation for all Member= s > To: "megacon@lists.acs.ohio-state.edu List" > > > > Community collaboration is critical to the collective advancement of > research and education. To better facilitate this goal, today I am > excited to announce the inclusion of basic Video Services as yet > another benefit of Internet2 membership. Along with the upcoming > addition of Cisco TelePresence Exchange services to the interoperable > Internet2 Video Services environment, this benefit will enable better > real-time collaboration for researchers and educators through access > to dependable, high quality video communications. > > All dues-paying Internet2 member institutions will be eligible to > enroll as participants in our Video Services at no additional cost. > This participation includes: > > =A0 =A0 =A0 =A0=95 A four screen Standard Virtual Room. Standard Virtual = Rooms > are interoperable with standards-based H.323, SIP, and TIP endpoints. > These rooms leverage shared infrastructure and access during peak > usage periods is not guaranteed. > =A0 =A0 =A0 =A0=95 Up to ten direct endpoint registrations. These endpoin= ts can > be H.323 today, or SIP including Cisco TelePresence coming in May. > =A0 =A0 =A0 =A0=95 Unlimited endpoint registrations for members who aggre= gate > endpoints through their own infrastructure. > > We will announce more details at the Internet2 Video Services Forum in > Arlington, VA and begin accepting applications for participation in > May. In the meantime, please find more information at > http://commons.internet2.edu/, or email me with any questions. > > Regards, > Ben > > /*----------------------- > Benjamin J. Fineman > Manager, Internet2 Video Services > > bfineman@internet2.edu (Email and XMPP) > http://www.internet2.edu > > 734.352.4975=A0(desk) > 734.417.0811=A0(mobile) > -----------------------*/ > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From ron.even.tlv@gmail.com Fri Apr 13 14:41:03 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177D911E813F for ; Fri, 13 Apr 2012 14:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOy5ZLvzqtor for ; Fri, 13 Apr 2012 14:41:02 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8213911E813E for ; Fri, 13 Apr 2012 14:41:01 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2368558wgb.13 for ; Fri, 13 Apr 2012 14:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=fZ1Ax2KrVOLdbxKjccp4GvRuFJ2BzlGfUADtw2mYIgw=; b=GRkQKb/LJcskBq5M5OjnSP2zB+F37k1glIDdSCMHrwjQaVjHYGLTDH870kpm8yVxzw SULF7Br4O2/qLINgxJVUFjMGEOnTGrRd8PmMXS6Nlu/fkZGaBj8Gsc0hh2iXKCzpOWFS iiQHzg3Nt0YeauShL+5jIsz61jTRoM4kTjj5UXU/GNuzWh3vJznOeRu0fHU55ElKGhzd RXwOsAiOoRbjuiB2l85mOfauTbPHbsOc8mpPg1rgQCQFohrrPUG2NiIPtZbOLG8p7wyW Yu5fmr7GY9n00vqT7RJYSWgrY9kHqI5dQY+ewDVwJ+x9EBsSMEqKEWWPdOG67+ZeByz6 Casg== Received: by 10.180.92.71 with SMTP id ck7mr7998422wib.21.1334353260549; Fri, 13 Apr 2012 14:41:00 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id w10sm12351160wiy.3.2012.04.13.14.40.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Apr 2012 14:40:58 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'Magnus Westerlund'" References: <4F8844F6.1080104@ericsson.com> In-Reply-To: Date: Sat, 14 Apr 2012 00:39:28 +0300 Message-ID: <4f889d6a.4a54b40a.4734.ffffac7d@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016D_01CD19D7.0F639560" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0ZlZtNTlCA12XRSfiMbqURiquJdwAJ2/Ug Content-Language: en-us Cc: 'Cullen Jennings' , 'clue' , 'Ted Hardie' , rai-ads@tools.ietf.org Subject: Re: [clue] Fwd: [rtcweb] Dates for upcoming interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:41:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_016D_01CD19D7.0F639560 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Mary, I am now not sure what is the plan. Is there a final date for the RTCweb meeting, I did not see any message after Ted's about put the decision ON HOLD. =20 =20 I also think that if there is still a wish to co-locate the meetings it = will be better to ask again for the preferred dates so that we will not have = to stay for a weekend. If we need to have a weekend in the middle we can also look at separate locations since not all of the CLUE guys need to attend rtcweb I also think that the CLUE meeting can overlap the W3C meeting. =20 Thanks Roni=20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes Sent: Friday, April 13, 2012 7:51 PM To: Magnus Westerlund Cc: Cullen Jennings; rai-ads@tools.ietf.org; Ted Hardie; clue Subject: Re: [clue] Fwd: [rtcweb] Dates for upcoming interim =20 Thanks. I agree this should be workable. As a reminder to folks in the CLUE WG, please respond to the doodle with regards to the location: http://www.doodle.com/wwrdycma9ymrdn3r =20 As I previously, noted please put a no for Stockholm if you absolutely/positively can't get there. I will note that I did an = initial check of airfares and while I know that it's variable depending upon = your locale, I can fly to Stockholm (for both meetings) for less than half = what it would cost me to fly to Boston (for a CLUE meeting) and then on to Stockholm for the RTCWEB meeting. =20 Thanks, Mary.=20 On Fri, Apr 13, 2012 at 10:23 AM, Magnus Westerlund wrote: Mary, CLUE WG On 2012-04-12 18:07, Mary Barnes wrote: > No, unfortunately, the RTCWEB folks made a decision that was based on > who was available and they didn't count maybes, which would have put = the > total the highest for Thursday the 7th, which would have allowed CLUE = to > meet on the 5th and 6th, which is our 2nd optimal date. Since the 6th > is our half-day meeting, folks that needed to be off on the 6th = wouldn't > miss as much and we could organize the agenda to maximize their > participation. However, the RTCWEB folks made their decision without > consulting with the CLUE WG chairs. Note, also that their choice > results in not having one of the area directors at their meeting, = which > also doesn't make sense to me. Also, not having the CLUE and RTCWEB > meetings co-located means that some folks will not be at the CLUE > meeting and given the number of drafts that one of the individuals has > that potentially apply to the CLUE solution, it's extremely = unfortunate. I want to start with saying sorry this hasn't worked out as desired. My individual position but with the knowledge of what we RTCWEB chair has discussed. I have to say that there are several additional constraints. First of all RTCWEB are co-locating with the W3C WebRTC WG. As they want a full day and RTCWEB WG want 2 days we need three consecutive days. That isn't available the week of 4-7th of June. In addition there is a W3C official requirement on announcing events 8 weeks ahead of time. That we can meet by having RTCWEB meet 12-13 and WebRTC the 11th. We do however have to rank co-location with our sister organization higher than ensuring that CLUE WG worked out the best way. It is unfortunate with the AD, but the rest of the considerations do appear to weigh more heavily in my personal view. > It looks like June 7th and 8th are optimal for CLUE. The only problem > with that choice is that the 6th is a Swedish holiday, so it is very > unfortunate that some of the folks based in Sweden may find this > problematic. We have a couple options: > 1) We do another poll that includes the dates we originally skipped in > trying to co-locate with RTCWEB. If the folks that are impacted by the > need to travel on the 6th could let the chairs know then we can decide > if we should run another (short/quick poll). We also need to do a = poll > for location, however, I would first like folks that are willing to = host > to let the chairs know, which leads to our 2nd option if the 6th = really > is a problem: > 2) Meet in Stockholm as that does allow the folks in Sweden to avoid > travel on the 6th, but we need a host and we need to see if the = majority > can travel there. Ericsson is willing to host also the CLUE WG interim meeting in = Stockholm. I think having CLUE meet in Stockholm on the 7th and 8th at least allows the individual that want to participate in both CLUE and RTCWEB/WEBRTC to avoid having to travel to two locations. Yes, it becomes a weekend away. But I know that I prefer a weekend in a foreign city to spend it on airplanes. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 =20 F=E4r=F6gatan 6 | Mobile +46 73 0949079 =20 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- =20 ------=_NextPart_000_016D_01CD19D7.0F639560 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Mary,

I am now not sure what is the plan.

Is there a final date for the RTCweb meeting, I did not see any = message after Ted's about put the decision ON = HOLD.

 

 

I also think that if there is still a wish to co-locate the meetings = it will be better to ask again for the preferred dates so that we will = not have to stay for a weekend.

If we need to have a weekend in the middle we can also look at = separate locations since not all of the CLUE guys need to attend = rtcweb

I also think that the CLUE meeting can overlap the W3C = meeting.

 

Thanks

Roni

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: Friday, April 13, 2012 7:51 = PM
To: Magnus Westerlund
Cc: Cullen Jennings; = rai-ads@tools.ietf.org; Ted Hardie; clue
Subject: Re: [clue] = Fwd: [rtcweb] Dates for upcoming = interim

 

Thanks. =  I agree this should be workable.  As a reminder to folks in = the CLUE WG, please respond to the doodle with regards to the = location:

 

As I previously, noted please put a no for Stockholm = if you absolutely/positively can't get there.  I will note that I = did an initial check of airfares and while I know that it's variable = depending upon your locale, I can fly to Stockholm (for both meetings) = for less than half what it would cost me to fly to Boston (for a CLUE = meeting) and then on to Stockholm for the RTCWEB = meeting.

 

Thanks,

Mary. 

On Fri, Apr 13, 2012 at 10:23 AM, Magnus Westerlund = <magnus.westerlund@ericsson.com> = wrote:

Mary, CLUE = WG


On 2012-04-12 18:07, Mary Barnes = wrote:
> No, unfortunately, the RTCWEB folks made a decision that = was based on
> who was available and they didn't count maybes, = which would have put the
> total the highest for Thursday the 7th, = which would have allowed CLUE to
> meet on the 5th and 6th, which = is our 2nd optimal date.  Since the 6th
> is our half-day = meeting, folks that needed to be off on the 6th wouldn't
> miss as = much and we could organize the agenda to maximize their
> = participation.  However, the RTCWEB folks made their decision = without
> consulting with the CLUE WG chairs.   Note, also = that their choice
> results in not having one of the area = directors at their meeting, which
> also doesn't make sense to me. =  Also, not having the CLUE and RTCWEB
> meetings co-located = means that some folks will not be at the CLUE
> meeting and given = the number of drafts that one of the individuals has
> that = potentially apply to the CLUE solution, it's extremely = unfortunate.

I want to start = with saying sorry this hasn't worked out as desired.

My = individual position but with the knowledge of what we RTCWEB = chair
has discussed. I have to say that there are several = additional
constraints. First of all RTCWEB are co-locating with the = W3C WebRTC WG.
As they want a full day and RTCWEB WG want 2 days we = need three
consecutive days. That isn't available the week of 4-7th = of June. In
addition there is a W3C official requirement on = announcing events 8
weeks ahead of time. That we can meet by having = RTCWEB meet 12-13 and
WebRTC the 11th. We do however have to rank = co-location with our sister
organization higher than ensuring that = CLUE WG worked out the best way.

It is unfortunate with the AD, = but the rest of the considerations do
appear to weigh more heavily in = my personal view.



> It looks like June 7th and = 8th are optimal for CLUE.  The only problem
> with that = choice is that the 6th is a Swedish holiday, so it is very
> = unfortunate that some of the folks based in Sweden may find this
> = problematic. We have a couple options:
> 1) We do another poll = that includes the dates we originally skipped in
> trying to = co-locate with RTCWEB. If the folks that are impacted by the
> = need to travel on the 6th could let the chairs know then we can = decide
> if we should run another (short/quick poll).  We = also need to do a poll
> for location, however, I would first like = folks that are willing to host
> to let the chairs know, which = leads to our 2nd option if the 6th really
> is a problem:
> = 2) Meet in Stockholm as that does allow the folks in Sweden to = avoid
> travel on the 6th, but we need a host and we need to see = if the majority
> can travel there.

Ericsson is willing to = host also the CLUE WG interim meeting in Stockholm.

I think = having CLUE meet in Stockholm on the 7th and 8th at least allows
the = individual that want to participate in both CLUE and RTCWEB/WEBRTC
to = avoid having to travel to two locations. Yes, it becomes a = weekend
away. But I know that I prefer a weekend in a foreign city to = spend it
on airplanes.

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
-----------------= -----------------------------------------------------

 

------=_NextPart_000_016D_01CD19D7.0F639560-- From stephen.botzko@gmail.com Sat Apr 14 10:23:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A570121F84C4 for ; Sat, 14 Apr 2012 10:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfHrbT5QjqZq for ; Sat, 14 Apr 2012 10:23:04 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id EEA8421F84BD for ; Sat, 14 Apr 2012 10:23:03 -0700 (PDT) Received: by dady13 with SMTP id y13so7145070dad.27 for ; Sat, 14 Apr 2012 10:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vN/ACCkWh3i1jbNROcinDdp9mHocT6HsqlMhJyFCbNU=; b=HrUANSIXf7aHbbzMuU+nULmh6l+zjx3Qq3iZvi1ISHBnIsPSYjw6VnKmE2/m5uaj1/ VMqj2KV37xCFooSN0SgnVQUkWV9elrAqNtxKChbZmt63X6XVACej9YoYrCwcRwj8ZO7y vw9ZAhn1HlaIEBcQSt6xJtC+7nw2Au0J83uVCNr2QuEEekV/7zlXqmQcAv/dciqq+w3a 9IKcKl2dO0tNmYZOX+cDgyClO7qcDKW72gRdjWUMdoUcpeR1HHDtP7K7+pmBe5oP27MN uBTfJ61jBd5Yc39xEnhWP3I2JTcKxB/mlnEsYvjqU1WqeUjf7sxJFkAshQ/n0F1F/FCQ hDFA== MIME-Version: 1.0 Received: by 10.68.221.74 with SMTP id qc10mr14222175pbc.80.1334424183600; Sat, 14 Apr 2012 10:23:03 -0700 (PDT) Received: by 10.68.136.69 with HTTP; Sat, 14 Apr 2012 10:23:03 -0700 (PDT) In-Reply-To: <92DF9533227FC14F946C7321074B8C9E011976A2@XMB-AMS-214.cisco.com> References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E011976A2@XMB-AMS-214.cisco.com> Date: Sat, 14 Apr 2012 13:23:03 -0400 Message-ID: From: Stephen Botzko To: "Espen Berger (espeberg)" Content-Type: multipart/alternative; boundary=e89a8ff2432b71789b04bda6d7dd Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 17:23:04 -0000 --e89a8ff2432b71789b04bda6d7dd Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 13, 2012 at 7:44 AM, Espen Berger (espeberg) wrote: > > * Telepresence point to point, where the reproduction will happen in a > > > 2D-plane for audio and video. Currently CLUE support announcing > > capability of sending 1 - N capture (left to right) and a receiver can > > > request 1 - M streams for rendering (left to tight), which is the > > basic for interoperability. > > In this case, suppose N > M. Who is responsible for deciding which M of > the N streams will be used? AFAIK the recipient just picks the ones it > wants. So then my question remains - does the recipient have sufficient > info to select the "right" ones? (There isn't any guarantee that *any* N > of the M streams will provide a reasonable rendering. > > [Espen] A receiver requesting 2x streams to be rendered left, right, > will rely on the media sender to give a decent experience. E.g. the most > capable endpoint must translate its capabilities down to what lesser > capable room can do. > > This would be improved if we had a mechanism for the recipient to state > "I can only handle N streams" and the sender was obligated to meet that > constraint. I don't think we have said that. > > [Espen] I see this as an important use case for interoperability. Its > fine for capable Telepresence room to do a advanced CLUE advertisement, > as long as there is an easy and straightforward way to request two > captures screens for left, right placed monitors. > > We should have a use cases to express that we want to support endpoints > that only support asking for 1 - N streams, rendered left to right. > [sb] section 3.2 in the use case document covers the asymmetric case[/sb] > > Cheers > > -Espen > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --e89a8ff2432b71789b04bda6d7dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 13, 2012 at 7:44 AM, Espen B= erger (espeberg) <espeberg@cisco.com> wrote:
> * Telepresence point to point, where the reproductio= n will happen in a

> 2D-plane for audio and video. Currently CLUE support announcing
> capability of sending 1 - N capture (left to right) and a receiver can=

> request 1 - M streams for rendering (left to tight), which is the
> basic for interoperability.

In this case, suppose N > M. Who is responsible for deciding which M of<= br> the N streams will be used? AFAIK the recipient just picks the ones it
wants. So then my question remains - does the recipient have sufficient
info to select the "right" ones? (There isn't any guarantee t= hat *any* N
of the M streams will provide a reasonable rendering.

[Espen] A receiver requesting 2x streams to be rendered left, right,<= br> will rely on the media sender to give a decent experience. E.g. the most capable endpoint must translate its capabilities down to what lesser
capable room can do.

This would be improved if we had a mechanism for the recipient to state
"I can only handle N streams" and the sender was obligated to mee= t that
constraint. I don't think we have said that.

[Espen] I see this as an important use case for interoperability. Its=
fine for capable Telepresence room to do a advanced CLUE advertisement,
as long as there is an easy and straightforward way to request two
captures screens for left, right placed monitors.

We should have a use cases to express that we want to support endpoints
that only support asking for 1 - N streams, rendered left to right.=A0
<= /blockquote>
[sb] section 3.2 in the use case document covers the asymm= etric case[/sb]

Cheers

-Espen


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--e89a8ff2432b71789b04bda6d7dd-- From pkyzivat@alum.mit.edu Sat Apr 14 14:11:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177FE21F8593 for ; Sat, 14 Apr 2012 14:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmmDF+bvTBZu for ; Sat, 14 Apr 2012 14:11:18 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id D759221F858F for ; Sat, 14 Apr 2012 14:11:15 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA11.westchester.pa.mail.comcast.net with comcast id xx8G1i0010EZKEL5BxBGVR; Sat, 14 Apr 2012 21:11:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta01.westchester.pa.mail.comcast.net with comcast id xxBG1i00G07duvL3MxBG8r; Sat, 14 Apr 2012 21:11:16 +0000 Message-ID: <4F89E7F2.7090806@alum.mit.edu> Date: Sat, 14 Apr 2012 17:11:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Stephen Botzko References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E011976A2@XMB-AMS-214.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 21:11:19 -0000 Steven, The use case doc does cover this case, but it doesn't say much about how the recipient (with fewer screens) decides what to display. It doesn't even hint at what Espen was implying - that the recipient asked to sender to choose streams to meet the recipient's limitations. Thanks, Paul On 4/14/12 1:23 PM, Stephen Botzko wrote: > > > On Fri, Apr 13, 2012 at 7:44 AM, Espen Berger (espeberg) > > wrote: > > > * Telepresence point to point, where the reproduction will happen > in a > > > 2D-plane for audio and video. Currently CLUE support announcing > > capability of sending 1 - N capture (left to right) and a > receiver can > > > request 1 - M streams for rendering (left to tight), which is the > > basic for interoperability. > > In this case, suppose N > M. Who is responsible for deciding which M of > the N streams will be used? AFAIK the recipient just picks the ones it > wants. So then my question remains - does the recipient have sufficient > info to select the "right" ones? (There isn't any guarantee that *any* N > of the M streams will provide a reasonable rendering. > > [Espen] A receiver requesting 2x streams to be rendered left, right, > will rely on the media sender to give a decent experience. E.g. the most > capable endpoint must translate its capabilities down to what lesser > capable room can do. > > This would be improved if we had a mechanism for the recipient to state > "I can only handle N streams" and the sender was obligated to meet that > constraint. I don't think we have said that. > > [Espen] I see this as an important use case for interoperability. Its > fine for capable Telepresence room to do a advanced CLUE advertisement, > as long as there is an easy and straightforward way to request two > captures screens for left, right placed monitors. > > We should have a use cases to express that we want to support endpoints > that only support asking for 1 - N streams, rendered left to right. > > [sb] section 3.2 in the use case document covers the asymmetric case[/sb] > > > Cheers > > -Espen > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From ron.even.tlv@gmail.com Sun Apr 15 03:28:32 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A30321F8527 for ; Sun, 15 Apr 2012 03:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_05=-1.11, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S71NbhJOMkf5 for ; Sun, 15 Apr 2012 03:28:30 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 651B621F85E4 for ; Sun, 15 Apr 2012 03:28:30 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2974539wgb.13 for ; Sun, 15 Apr 2012 03:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=c8XjAivMlKImjpF5iQ3Yb3a14zgCZG8eLjJ2dfV2kHs=; b=mwVYHyQZmeEpravPYiXX57Qq1r4ZCYQ3MmR6yHOjBoztNwUhZW1XG4aUiiX5op2WNY 01HrnXfeqSEvyXKPm/PMJSWwQFH0OggzoefkKBop0DaeBSubo6hLR52NT5xEQqhSYk/z JL9yCkEFkswO5JsiUL8T4AXdw9z/VagIDJwKQsMmmbgKdsAfxCcZqSYia60ae1baeR/T QOSsyw9W4F/K7l9XmZN7AF86kedLpEm4H2Afo4fkmOv2JhBhWh1Tppq1jAmEkxXlKNpg fKnlOlFPN545QxypStCJ9mAFmUt2nlawXMyjEd5KPyW0/5OnlwzH3xYqficBMf/LhMY7 f+BA== Received: by 10.216.132.222 with SMTP id o72mr4294612wei.95.1334485709542; Sun, 15 Apr 2012 03:28:29 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id ca3sm11008727wib.6.2012.04.15.03.28.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Apr 2012 03:28:27 -0700 (PDT) From: "Roni Even" To: "'Marshall Eubanks'" , "'Mary Barnes'" References: In-Reply-To: Date: Sun, 15 Apr 2012 13:26:56 +0300 Message-ID: <4f8aa2cb.035bb40a.126f.3288@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0XLsElC4dhLgUFQ+WBbyNBbaZJbwDwSqsA Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Agenda: CLUE WG Design Team X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 10:28:32 -0000 Hi, Sorry for not attending the meeting, we had our Holiday and I missed the call. As for the notes. I have no problem with source selection not in version 1. My view is that this is a nice to have feature but currently in multipoint I think most solutions use stimulus based approach using a web interface or some menus based on DTMF or some H.224 based signaling since they cannot count on source selection support as part of the endpoint application. On multiple capture scenes, my comment was about the point to point use case. Is there a case where there may be more than one capture scene in an advertisement. If there is such a case we will need to be able to describe it at the capture scene level using some attribute that will carry the semantics of the scene. If not, we should say in the text that there will be just one. This is for completeness of the model. On the transport work, I think that the transport drat provide the options but we are not sure yet which one is the way to go forward. We may need to discuss it in the interim meeting with the discussion on the data model. Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Marshall Eubanks > Sent: Tuesday, April 10, 2012 6:30 PM > To: Mary Barnes > Cc: CLUE > Subject: Re: [clue] Agenda: CLUE WG Design Team > > (Fairly) raw notes from today's call. > > Regards > Marshall > > On Tue, Apr 10, 2012 at 10:04 AM, Mary Barnes > wrote: > > > > > > Agenda: > > 1) Review list of open action items. > > 2) Discuss current open items and decide if we need an issue opened > in > > the tracker or whether these aren't real issues: > > - mixed/composed > > - simultaneous sets > > 3) Way forward for signaling solution(s) and data model. > > > > Thanks, > > Mary. > > > > > >>> > >>> > >>> ---------- Forwarded message ---------- > >>> From: *Clue Working Group* >>> > > >>> Date: Mon, Apr 9, 2012 at 3:37 PM > >>> Subject: Meeting invitation: CLUE WG Design Team > >>> To: mary.ietf.barnes@gmail.com > >>> > >>> > >>> > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > CLUE Design Team > > Tue Apr 10 10:03:01 EDT 2012 > > Marshall Eubanks > Allyn Romanow > Brian Baldino > John Leslie > Jonathan Lennox > Mark Duckworth > Mary Barnes (Chair) > Rob Hansen > Espen Berger > Paul Kyzivat > > Mary : I thought we would go over some of issues and the things being > discussed on the list. > > (shows active tickets) > > The first issue is the source selection case. > > Jonathan : I thought we discussed that in Andover. I thought the > conclusions was it was a good use case but not anything we want in > version 1. > > Mary : OK, great, I will go ahead and close that out. > > I don't see Roni. He has the RTCWEB use case. I don't think he is on > right now. > > ? : Is it a Holiday in Israel? > > Mary : Maybe. I know Saturday was Passover. I will consult with Roni. > > Issue # 4 - there is not much we can do about that now. It has to be on > hold for a while. > > Issue 5 is describing in room attributes. > > > > Mary : There was 9, the axis of capture. > > > > This is Stephan's. I will get back to him on this. > > Ticket 8 is distinguishing between multiple capture scenes. > > Espen : The classic case is where you have a lecture capture, with one > camera at the speaker and one at the white board and one on the > audience. > > Mark : That sounds like it would fit better using the purpose > attribute. > > Espen : 4796 ? > > Mark : That sounds right. > > Jonathan : I thought this issue was about capture scenes. > > Mark : My basic question is, does anybody think that adding a human > readable name as an attribute would help. I am thinking that the > purpose attribute would be more easily useful. > > Espen : It is not only automatic, I want it to be in the message so I > can understand - it is in addition. So, maybe it has two source. > > Rob : In the past we have talked about conferences with multiple > capture scenes for different users - there, they would have the same > purpose, so the purpose isn't enough. > > Paul : There have been cases where purpose is not enough. Having a > human decipherable name is a fail-back. > > Mark : If it is a human readable string, would the source be a human ? > > Paul : That is not for us to decide. > > Marshall : Don't these sorts of things tend to turn into profiles over > time? If you make this available, it will become something for the > automated machinery to use. > > Paul : We talked about cases where there were 2 kinds of captures > > Mary : XCON does have a display text for available media. > > Paul : If the mapping to XCON is well understood, then maybe it is OK. > > Do we agree that each capture is a participant ? > > Mary : CLUE is built on SIP. XCON is built on SIPPING - if it is > already there, we shouldn't be replicating it. > > The conference is built on blocks of attributes, each representing a > participant. This is something to look at. > > I think it is reasonable to say we want something human readable - > something capturable. > > Espen : I think it depends on the use cases. > > Mary : So it falls back to our use cases. Roni had comments on this > too. > > I think we can agree to some sort of human readable text. > > So, that is the last open issue. > > The most recent ML discussion was around the mixed proposed. > > Paul : It seems we have been going in circles. The first thing to sort > out is, what is the point of these attributes? Why are they there ? > > My take is that we are trying to provide enough information to map > captures onto equipment at the receiver side, and these attributes will > help with that. > > Jonathan : A lot of the complication is, we have a mixer. > > The consumer may be a middle box, which may not pass it along. > > Paul : If we can figure out the purpose, we can then figure out if we > have the right information. > > We got into this confusing discussion about what it means to be > composed. Maybe some captures from one camera can be composed. > > Espen : You want to cover use cases where the end user relies on a > middle box, or the receiver receives something untouched from the > sender. > > The first one I call composed, and the second original. > > So, a middle box needs to be able to express that it can send either > original or composed scenes. > > Paul : This sounds like an attribute on the capture set. > > Espen : I think we need more concrete examples. > > Paul : I wonder if we need to identify some more challenging use cases. > > If all you have is that some are composed or some or not > > Espen : In this particular case, you don't mix. All are composed, or > none. > > Paul : You can compose the not composed ones, but leave the composed > ones alone. > > Espen : The base is, I think, a single composed attribute. > > Paul : Can we write down some of these cases ? > > Mark : It seems to me that these scenarios are more general than > multiple streams for telepresence. The same issues apply to non- > telepresence single stream units. > > Are we sure that CLUE is the best place for this ? > > Mary : I am not sure that we are. > > Espen : I can write down some of these use cases. > > I remember from IETF in Paris that there are people discussing related > issues [in a number of different WG]. > > Paul : At the META level it's the same, but at the audio and video it > is quite different. > > To me the fundamental problem in the scope of CLUE is, if you are the > end point, and you have received an advertisement, with some scenes and > captures, do you have sufficient information to select and map what you > have onto what you have got. If the geometry does not match, then what > ? Is there enough information to decide what to do? > > Marshall : And that is very telepresence specific. Even in typical > videoconferencing you may not really care about what goes where in what > size, as long as it fits. > > Espen : I think in other cases you may well care as well. > > Paul : So, what is the next step ? > > Mary : We can open a ticket and Espen said he would send something to > the list. > > [Mary asked about the status of the Wenger transport draft - I said > that I wasn't aware of any immediate plans to rev it.] > > Mary : We have had a discussion about the data model and different > people had different views. To me, it is about what is to be carried. > I know that all of this is > > If someone would like to volunteer and talk to Christer [Holmberg] on > the data model and volunteer, that would be good. > > Allyn : Didn't Andy come out with a data model. > > Espen : That document would be a good starting point for what you > should supply that isn't in SDP. > > Mary : That was not an IETF draft. > > Paul : It was his presentation. > > Mary : Right. > > I will let Christer know that that is available. I will forward this > document to him. > > I think we will hold off other issues to next week. > > Call ended > Tue Apr 10 10:56:21 EDT 2012 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From espeberg@cisco.com Sun Apr 15 04:01:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FAE21F8755 for ; Sun, 15 Apr 2012 04:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-XErlgNx3Ru for ; Sun, 15 Apr 2012 04:01:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4056021F8754 for ; Sun, 15 Apr 2012 04:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=2861; q=dns/txt; s=iport; t=1334487709; x=1335697309; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=PXqLGCdnvmN0jWYTqquVW9aTqiL8mFY5SjIAweXrFIo=; b=D2NkwGWoq6nNeC/pOFTTO5bFsMwkyKNxL5SZrGIgfYZNC86ASlx3bkut 1i6lQOgi831854f+mgxp0FXpY4hWwH82okbqs6zYnDC8sIyIFvkVfGUKE RNCGBWtMdLW+UzEeid6NLFYSl1mfmHZl1k4DJ/iG9DsdBsp652Uoqi1NF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFCpik+Q/khL/2dsb2JhbABDDrUJgQeCCQEBAQMBEgEKEwo/BQcEAgEIDgMEAQEBCgYXAQYBRQkIAQEEEwgah2cFnhCXB5BmYwSkOYFpgjA5 X-IronPort-AV: E=Sophos;i="4.75,424,1330905600"; d="scan'208";a="135191254" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2012 11:01:48 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3FB1mdC031656; Sun, 15 Apr 2012 11:01:48 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 15 Apr 2012 13:01:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Apr 2012 13:01:47 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E011977CB@XMB-AMS-214.cisco.com> In-Reply-To: <4F883FFD.3060109@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sender to comply with receiver limits on what it can receive (?) Thread-Index: Ac0Zhnw2wesJKE7dQ0u5sTYmjkvq+wBbtzUg References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E011976A2@XMB-AMS-214.cisco.com> <4F883FFD.3060109@alum.mit.edu> From: "Espen Berger (espeberg)" To: "Paul Kyzivat" X-OriginalArrivalTime: 15 Apr 2012 11:01:48.0138 (UTC) FILETIME=[274044A0:01CD1AF7] Cc: CLUE Subject: Re: [clue] Sender to comply with receiver limits on what it can receive (?) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 11:01:50 -0000 I was not thinking about adding the capability message back in.=20 My comment was to make sure that a receiver of a CLUE advertisement message can understand what the media consumers preferred configurations are for a two screen endpoint. It cannot be only up to the two screen endpoint to choose correctly between alternatives, the sender can send some useful hints to make it easier to choose between alternatives. -Espen=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 13. april 2012 17:02 To: Espen Berger (espeberg) Cc: John Leslie; CLUE Subject: Sender to comply with receiver limits on what it can receive (?) Changing the subject line. This is one specific point coming out of the thread on "Does framework provide sufficient info for receiver?" Paraphrasing, I think Espen is calling for a requirement that the sender construct an advertisement that is consistent with receiver capabilities. This seems to require the (still undefined) Capabilities message, and to make it binding. AFAIK we currently have no such requirement. Do others think we should? Thanks, Paul On 4/13/12 7:44 AM, Espen Berger (espeberg) wrote: >> * Telepresence point to point, where the reproduction will happen in=20 >> a > >> 2D-plane for audio and video. Currently CLUE support announcing=20 >> capability of sending 1 - N capture (left to right) and a receiver=20 >> can > >> request 1 - M streams for rendering (left to tight), which is the=20 >> basic for interoperability. > > In this case, suppose N> M. Who is responsible for deciding which M=20 > of the N streams will be used? AFAIK the recipient just picks the ones > it wants. So then my question remains - does the recipient have=20 > sufficient info to select the "right" ones? (There isn't any guarantee > that *any* N of the M streams will provide a reasonable rendering. > > [Espen] A receiver requesting 2x streams to be rendered left, right,=20 > will rely on the media sender to give a decent experience. E.g. the=20 > most capable endpoint must translate its capabilities down to what=20 > lesser capable room can do. > > This would be improved if we had a mechanism for the recipient to=20 > state "I can only handle N streams" and the sender was obligated to=20 > meet that constraint. I don't think we have said that. > > [Espen] I see this as an important use case for interoperability. Its=20 > fine for capable Telepresence room to do a advanced CLUE=20 > advertisement, as long as there is an easy and straightforward way to=20 > request two captures screens for left, right placed monitors. > > We should have a use cases to express that we want to support=20 > endpoints that only support asking for 1 - N streams, rendered left to right. > > Cheers > > -Espen > > > From stephen.botzko@gmail.com Sun Apr 15 04:22:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF5821F8731 for ; Sun, 15 Apr 2012 04:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.436 X-Spam-Level: X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeyptFNykctM for ; Sun, 15 Apr 2012 04:22:44 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 435E221F8724 for ; Sun, 15 Apr 2012 04:22:44 -0700 (PDT) Received: by dady13 with SMTP id y13so7865215dad.27 for ; Sun, 15 Apr 2012 04:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=teYC6YXCRYmPKIlqj8Q8KY4IO68el+YDrLNr7V7MOeI=; b=V3hff8HgrMY8N5XH3nKbM3juKVbla/+k/C+sqARNAC7UkQ60LeKfkCWGNml7kLu0DY PXViiWTqg9qKES6p6PCoQfq0b8YzZ96N5C704aCw8Zzff0gkJc+r3WIA9qit1wQi4j4U GJzZvYgNdiMxKOObZt8AMByBltPeZZoxGG0KiE8HVfonSNvroGoWFAPkg4JPZuIBZ2aK tLiCsleYMcNmaPRAxBl6CTFxZTrqmUmyCbxmMbUF+SSAkuJH2HTCZe+r7HuBhFtvgwXk Ze2oBJQZ3fxQM3KE1JXSibxiEK6ihc8SuRZtSR7l+KygvR+dtNKOBy7WcuH/kJusUlZE Q6Qw== MIME-Version: 1.0 Received: by 10.68.134.133 with SMTP id pk5mr19611904pbb.17.1334488964033; Sun, 15 Apr 2012 04:22:44 -0700 (PDT) Received: by 10.68.136.69 with HTTP; Sun, 15 Apr 2012 04:22:44 -0700 (PDT) In-Reply-To: <92DF9533227FC14F946C7321074B8C9E011977CB@XMB-AMS-214.cisco.com> References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E011976A2@XMB-AMS-214.cisco.com> <4F883FFD.3060109@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E011977CB@XMB-AMS-214.cisco.com> Date: Sun, 15 Apr 2012 07:22:44 -0400 Message-ID: From: Stephen Botzko To: "Espen Berger (espeberg)" Content-Type: multipart/alternative; boundary=047d7b11190ba86d8304bdb5ec31 Cc: CLUE Subject: Re: [clue] Sender to comply with receiver limits on what it can receive (?) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 11:22:45 -0000 --047d7b11190ba86d8304bdb5ec31 Content-Type: text/plain; charset=ISO-8859-1 In my view, a nice sender would advertise exactly one 2-capture entry, and send the captures it thinks are most useful. Stephen On Sun, Apr 15, 2012 at 7:01 AM, Espen Berger (espeberg) wrote: > I was not thinking about adding the capability message back in. > > My comment was to make sure that a receiver of a CLUE advertisement > message can understand what the media consumers preferred configurations > are for a two screen endpoint. It cannot be only up to the two screen > endpoint to choose correctly between alternatives, the sender can send > some useful hints to make it easier to choose between alternatives. > > -Espen > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 13. april 2012 17:02 > To: Espen Berger (espeberg) > Cc: John Leslie; CLUE > Subject: Sender to comply with receiver limits on what it can receive > (?) > > Changing the subject line. This is one specific point coming out of the > thread on "Does framework provide sufficient info for receiver?" > > Paraphrasing, I think Espen is calling for a requirement that the sender > construct an advertisement that is consistent with receiver > capabilities. This seems to require the (still undefined) Capabilities > message, and to make it binding. > > AFAIK we currently have no such requirement. > Do others think we should? > > Thanks, > Paul > > On 4/13/12 7:44 AM, Espen Berger (espeberg) wrote: > >> * Telepresence point to point, where the reproduction will happen in > >> a > > > >> 2D-plane for audio and video. Currently CLUE support announcing > >> capability of sending 1 - N capture (left to right) and a receiver > >> can > > > >> request 1 - M streams for rendering (left to tight), which is the > >> basic for interoperability. > > > > In this case, suppose N> M. Who is responsible for deciding which M > > of the N streams will be used? AFAIK the recipient just picks the ones > > > it wants. So then my question remains - does the recipient have > > sufficient info to select the "right" ones? (There isn't any guarantee > > > that *any* N of the M streams will provide a reasonable rendering. > > > > [Espen] A receiver requesting 2x streams to be rendered left, right, > > will rely on the media sender to give a decent experience. E.g. the > > most capable endpoint must translate its capabilities down to what > > lesser capable room can do. > > > > This would be improved if we had a mechanism for the recipient to > > state "I can only handle N streams" and the sender was obligated to > > meet that constraint. I don't think we have said that. > > > > [Espen] I see this as an important use case for interoperability. Its > > fine for capable Telepresence room to do a advanced CLUE > > advertisement, as long as there is an easy and straightforward way to > > request two captures screens for left, right placed monitors. > > > > We should have a use cases to express that we want to support > > endpoints that only support asking for 1 - N streams, rendered left to > right. > > > > Cheers > > > > -Espen > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --047d7b11190ba86d8304bdb5ec31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In my view, a nice sender would advertise exactly one 2-capture entry, and = send the captures it thinks are most useful.

Stephen

On Sun, Apr 15, 2012 at 7:01 AM, Espen Berger (espeberg)= <espeberg@cisco= .com> wrote:
I was not thinking about adding the capabili= ty message back in.

My comment was to make sure that a receiver of a CLUE advertisement
message can understand what the media consumers preferred configurations are for a two screen endpoint. It cannot be only up to the two screen
endpoint to choose correctly between alternatives, the sender can send
some useful hints to make it easier to choose between alternatives.

-Espen

-----Original Message-----
From: Paul Kyzivat [mailto:pkyziva= t@alum.mit.edu]
Sent: 13. april 2012 17:02
To: Espen Berger (espeberg)
Cc: John Leslie; CLUE
Subject: Sender to comply with receiver limits on what it can receive
(?)

Changing the subject line. Th= is is one specific point coming out of the
thread on "Does framework provide sufficient info for receiver?"<= br>
Paraphrasing, I think Espen is calling for a requirement that the sender construct an advertisement that is consistent with receiver
capabilities. This seems to require the (still undefined) Capabilities
message, and to make it binding.

AFAIK we currently have no such requirement.
Do others think we should?

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

On 4/13/12 7:44 AM, Espen Berger (espeberg) wrote:
>> * Telepresence point to point, where the reproduction will happen = in
>> a
>
>> 2D-plane for audio and video. Currently CLUE support announcing >> capability of sending 1 - N capture (left to right) and a receiver=
>> can
>
>> request 1 - M streams for rendering (left to tight), which is the<= br> >> basic for interoperability.
>
> In this case, suppose N> =A0M. Who is responsible for deciding whic= h M
> of the N streams will be used? AFAIK the recipient just picks the ones=

> it wants. So then my question remains - does the recipient have
> sufficient info to select the "right" ones? (There isn't= any guarantee

> that *any* N of the M streams will provide a reasonable rendering.
>
> [Espen] A receiver requesting 2x streams to be rendered left, right, > will rely on the media sender to give a decent experience. E.g. the > most capable endpoint must translate its capabilities down to what
> lesser capable room can do.
>
> This would be improved if we had a mechanism for the recipient to
> state "I can only handle N streams" and the sender was oblig= ated to
> meet that constraint. I don't think we have said that.
>
> [Espen] I see this as an important use case for interoperability. Its<= br> > fine for capable Telepresence room to do a advanced CLUE
> advertisement, as long as there is an easy and straightforward way to<= br> > request two captures screens for left, right placed monitors.
>
> We should have a use cases to express that we want to support
> endpoints that only support asking for 1 - N streams, rendered left to=
right.
>
> Cheers
>
> -Espen
>
>
>

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--047d7b11190ba86d8304bdb5ec31-- From ron.even.tlv@gmail.com Sun Apr 15 08:21:41 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F8B21F87BE for ; Sun, 15 Apr 2012 08:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.759 X-Spam-Level: X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra43NB-8cK4P for ; Sun, 15 Apr 2012 08:21:39 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC7A521F879E for ; Sun, 15 Apr 2012 08:21:38 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so6744170wib.13 for ; Sun, 15 Apr 2012 08:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=gnlVH+P2eT8u6iksDrqMLy3+f2V568/4dFZT066eab8=; b=n8timu2no28q9miOA+61QndIghVdAaBMVg7ThHzXujsfn+e4O2vgWaLmmTsXFrUJvv 48J6nuUCfjrB0hcxM5oHQ7pe9m1AAc9IJtI4HkBJ0KvbVTlWZy0n79yrEO6lOtblb9Pz eVxo4Qc8Q8nmsaNtjJDuYbqVOq/r+k2A+ODaLFGAgicJB+e3+112+3dTPcE4zC7SxTsG hGVYakFvO1Esni8ho+0pwjqiuxzNkqQVHmfgZHr1OW2abb6jsldfN6gEOM7uDBSrOD1W q7LptNhGKY6QlIIOpP/KUOuQeIuzHQdS3v9ukV+hnJKukq1dGxkGEC7CTxKD62CfRC7z 4YrA== Received: by 10.180.100.2 with SMTP id eu2mr11362209wib.1.1334503297898; Sun, 15 Apr 2012 08:21:37 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id e6sm12829996wix.8.2012.04.15.08.21.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Apr 2012 08:21:36 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'Espen Berger \(espeberg\)'" References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> In-Reply-To: <4F873CCE.3020806@alum.mit.edu> Date: Sun, 15 Apr 2012 18:20:05 +0300 Message-ID: <4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0Y6/f0dqdrC6/bTYS0AHS4deGudQCLkFDw Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 15:21:41 -0000 Hi Paul, I think that there is enough information that will allow a receiver to select N out of M streams. The receiver will know the semantics of the streams (people or presentation) and the spatial information of the room and the different streams. My view is that this is enough for the general telepresence point to point use case. As for multipoint use case, this is why I think it is important to know if the advertisement is based on site switch or segment switch which will provide the extra information needed for the selection (spatial information provides the internal relation between the capture) and I think that the audio level will help with knowing who are the active speakers in this case Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Thursday, April 12, 2012 11:37 PM > To: Espen Berger (espeberg) > Cc: CLUE > Subject: Re: [clue] Does framework provide sufficient info for > receiver? > > Espen - comments inline. > > Thanks, > Paul > > On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: > > During the CLUE design team meeting on webex yesterday we started to > > discuss various use cases and if they are in scope or not for the > > current work in CLUE. > > > > As a part of my response to Pauls questions I summarized the use > cases > > and grouped them into supported / not supported. I can dive into more > > detail about the use cases if people are interested? > > > > I would answer yes to the following use cases > > * Telepresence point to point, where the reproduction will happen in > a > > 2D-plane for audio and video. Currently CLUE support announcing > > capability of sending 1 - N capture (left to right) and a receiver > can > > request 1 - M streams for rendering (left to tight), which is the > > basic for interoperability. > > In this case, suppose N > M. Who is responsible for deciding which M of > the N streams will be used? AFAIK the recipient just picks the ones it > wants. So then my question remains - does the recipient have sufficient > info to select the "right" ones? (There isn't any guarantee that *any* > N of the M streams will provide a reasonable rendering. > > This would be improved if we had a mechanism for the recipient to state > "I can only handle N streams" and the sender was obligated to meet that > constraint. I don't think we have said that. > > > * Transcoded conferencing, where the MCU act like an endpoint and > > logically announces audio and video left to right and a receiver > > request > > 1 - M captures depending on how many screen and audio streams you > > prefer. Typically a single video stream pr. screen and one audio pr. > > screen (mono/stereo). Excluded is capabilities to select individual > > speakers, the MCU is free to optimize what to compose and send to a > > receiver. > > This is logically equivalent to the prior case. > > > * Generic multi source, sending and receiving named sources where the > > user experience is controlled by an human being capable of reading > > sources names, or control software written explicit to operate on the > > named streams. The content attribute can be used to indicate a > primary > > role, RFC4796 uses 'main' and 'alt'. > > Are you talking about the text names/labels we were discussing on the > last call? > > If so, I agree that if the senders provide well conceived labels then a > human can probably decide something reasonable. > > If the human is working only with "content" attributes, then its not so > clear. Its quite possible that the recipient will find itself trying to > choose between multiple streams with the same content type. (E.g. all > 'main'.) > > > I would answer no, to the following use cases > > * Switched conferencing, where we assume that endpoints do scalable > > video (either SVC or Simulcast), locally composited layout and audio > > mixing. Limited work has been done on how to use Scalable video and > > how to build mechanisms for complete composited layouts. > > * Advanced audio reproduction, a group of audio scenarios mentioned > by > > Jon Leslie and Johan Nielsen that requires more details during > initial > > signalling and more dynamic information for transferring dynamic > > meta-information. > > * Multi view, as described in the CLUE use case document. > > > > (Other comments inline.) > > > > Cheers > > > > -Espen > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Paul Kyzivat > > Sent: 11. april 2012 17:06 > > To: John Leslie > > Cc: CLUE > > Subject: Re: [clue] Does framework provide sufficient info for > receiver? > > > > Hi John, > > > > Thanks for the comments. I've followed up inline. > > > > On 4/10/12 5:09 PM, John Leslie wrote: > >> Paul Kyzivat wrote: > >>> > >>> The fundamental problem in the scope of CLUE is, if you are an > >>> endpoint, and you have received an advertisement, with some scenes > >>> and captures, do you have sufficient information to select and map > >>> the advertised scenes/captures onto the equipment you have? > >> > >> Of course not! > >> > >> If we wanted that, we'd have to include for every composed > scene > >> what it's composed from, and for every mixed audio what it's mixed > >> from. > > > > I think you must have misunderstood me. Otherwise I wouldn't expect > > you to answer "Of course not". AFAIK the whole point of CLUE is to > > provide the information to make this possible. > > > > My point in asking the question was so that we can identify what > > information we have overlooked that we need to include one way or > > another. > > > > Clearly there are some tradeoffs. More information might support > > *better* mappings. So one thing to decide is how good is good enough. > > [Espen] Agree with Paul, we clearly can support in CLUE the use cases > > where a Telepresence room either offer a 1, 2 or 3 video captures, > > which can be rendered on 1, 2 or 3 screens. > > I think its clear we can support cases where every advertisement that > includes an entry for N (>1) captures also includes an entry with only > one capture, and optionally entries containing other numbers of > captures between 1 and N. > > But as I mention above, its not clear we have supported case where the > minimal entry in the advertisement is for N>1 captures. > > >>> If you have sufficient equipment (displays, speakers) with > >>> compatible > > > >>> geometry to directly map all of the captures from one audio and one > >>> video capture scene entry from each capture scene then maybe all is > >>> good. In this case ISTM that the mixed/composed attributes aren't > >>> needed. > >> > >> It's unlikely that the "typical" telepresence conference will > >> have > > > >> a separate screen for every possible video. > > > > That isn't what I said. Consider what is perhaps a typical case, > where > > the advertisement contains one scene with several alternative video > > and audio scene entries. Lets just consider the video. Then maybe > > there is one entry with three captures, and another with one > > (mixed/switched, > > whatever) capture. Then if you have three screens you can map all > > three captures in the first entry. If you have less than three > screens > > then you can map the one capture from the 2nd entry onto one of your > screens. > > > > But what if there was no entry with a single capture? If you had two > > screens, would you have enough info about the three captures in the > > first entry to make a reasonable mapping onto your two screens? What > > information would we need to include in the advertisement so that it > > would be possible to do this mapping well? > > > > [Espen] How a vendor build a room or endpoint is transparent from the > > sender of media. As a sender you should not care if a room request 3 > > audio streams (left, center, right) and choose to mix and play out on > > a single speaker. We can argue that this is not the best experience, > > but still valid and typically done for PC-clients or other endpoints > > with a single speaker. > > Again, I think you are assuming the receiver can specify the max number > of streams it can handle, and that the sender will then be obligated to > select/construct a suitable set of streams. AFAIK we have not written > down anything that calls for that. (If I am wrong, please let me know > where this is specified.) > > We have the (largely hypothetical) recipient capabilities message, but > its content hasn't been specified yet, and AFAIK there has been no > statement that it is binding and the construction of the advertisement. > > >> Of course, the number of "capture scenes" _could_ be small > >> enough to give each it's own video monitor -- but I don't think > >> that's the general case we should design for. > > > > IIUC an endpoint will typically only advertise one or two scenes. One > > would correspond to the cameras and mics in its room. The other, if > > present, would correspond to a "presentation" that doesn't fit into > > the coordinate space of the room. There are cases for more, but they > > get more obscure. > > > > So for a point-to-point clue call the recipient will only need to map > > one or two scenes. But when there is more than one it is more > complex, > > requiring sharing of equipment. > > > > The situation is more complex for an MCU. It will have as input all > > the scenes offered by all the endpoints. It then has to decide what > to > > offer out to the endpoints. It could just pass through all the scenes > > it receives from all the endpoints, leaving the mapping problem > > entirely to the endpoints. (I don't think that is what most people > > have in mind, though some might.) > > > > Or it could take on itself the job of mapping/mixing/switching all of > > those inputs and producing something more like what a typical > endpoint > > would advertise - one or two scenes each with just a few captures. > > > > Or it could do both - advertise its own simplified composite scenes > > and also all those provided by the endpoints. That would allow the > > endpoints to either take the easy way out, or else do it all > > themselves in a way that suits them. Suppose it did this. Would the > > endpoints that want to take the easy way be able to figure out which > > scenes and captures to use? > > > > [Espen] This sounds closer to a user experience discussions than a > > protocol discussion. > > Perhaps it is. But the point of CLUE is to develop a protocol that > enables an especially good user experience. While we shouldn't mandate > the user experience, I think we are obligated to do due diligence that > the protocol is sufficient to enable that user experience. > > >> OTOH, with an appropriate "surround-sound" system, you can > "place" > >> an arbitrarily large number of audio streams, yet make them easy to > >> distinguish. > >> > >>> If you don't have sufficient equipment to do that, then the job is > >>> harder, and more information is needed to figure out what to do. > >> > >> Only marginally harder... > >> > >>> For instance: > >>> > >>> - If you don't have suitable displays, then perhaps you can select > a > >>> video capture scene entry and locally compose or switch some of the > >>> captures in order to produce a set of captures that does map to the > >>> available displays. The area of capture of each capture could be > >>> helpful to doing this, and perhaps the composed attribute as well. > >> > >> One inevitable use case is filing your formal report from the > > airport. > >> The person doing so will have lousy audio, vastly inadequate video, > >> and typically inadequate bandwidth with excessive latency. S/he will > >> need some middlebox to compose a "barely-adequate video" and mono > > audio. > > > > This is indeed an interesting case - one we have explicitly put in > > scope. If an MCU is already in the call then perhaps we can hope that > > is one of the entries it makes available. > > > > If there isn't any MCU in the call, then the other endpoint might not > > advertise that option. Then what? Do we have a mechanism for that? > > [Espen] If an MCU detect low bandwidth or packet loss it can start > > using its normal recovery mechanisms. That could lower bitrate for > > audio and video (maybe by a SIP re-invite), change the CLUE offer to > > something that fits inside the available bandwidth. Getting good > > quality audio ande video is always a challenge, with or without clue. > > > >> Then there's the use case of filing you formal report from your > >> home office (when you're sick or somebody doesn't want to pay travel > > cost). > >> You may well have surround-sound and two or three large monitors, 20 > >> Mbps download with 40 msec RTT, and a decent-quality lavalier mike. > >> You still probably want some middlebox to compose your basic video, > >> but you can take individual streams as well to concentrate on > > particular people. > >> > >> Near the top end are the corporate telepresence rooms. They > will > >> want all streams, and are likely to have a human being mixing them. > > > > I don't understand your point "are likely to have a human being > mixing > > them". Can you explain further? > > [Espen] I see this as mostly a request for focusing in on particular > > user. In a transcoded conference you can do that by looking into > XCon, > > if you do switched conference the endpoint typically render the > layout > > and can choose who to focus on. Mixing transcoded and switched > > conferencing I think makes it unnecessary complex for the initial use > > cases to cover. > > > >>> - or rather than compose to fit your displays, you could switch... > >> > >> Folks _will_ do that -- I can't stop them. But I find it > > uninteresting. > > > > ??? We have been talking about switching a lot. Are you saying that > is > > uninteresting? > > > > If it makes sense for a middlebox to switch, doesn't it make equal > > sense for an endpoint to do so? > > > >>> - handling video from multiple scenes probably presents some added > >>> issues. By definition there is no specified spatial relationship > >>> between the captures of different scenes... > >> > >> Nonetheless, the participants will want to imagine such a > > relationship. > > > > ISTM that this needs further discussion. > > > >>> - If you don't have sufficient speakers for all of the audio > >>> captures, then you have to decide to mix, switch, or drop some. > >> > >> There really isn't any such thing as "sufficient speakers", but > >> surround-sound should be considered "sufficient". You can always mix > >> to stereo or even mono: "you pays your money and you takes your > > choice". > > > > Do we have enough information to do it "right" or "well"? > > Right now the coordinate info is all optional. Does it need to be > > mandatory in order to enable this? > > > >>> The spatial information from the captures may help in deciding how > >>> to > > > >>> mix. > >> > >> Absolutely! > >> > >>> Not evident that the mixed attribute helps with this > >> > >> It help you know when mixing is less likely to work well. > >> > >>> - unless it is used to decide to switch rather than mix. > >> > >> I'm not sure there is any such thing. "Mixing" frequently > >> includes > > > >> "riding gain" to reduce background noise. Binary switching is just a > >> bad idea. > > > > I have no special understanding of this. I'm just asking probing > > questions in hopes that it will result in the right decisions being > > made and the right stuff specified. > > > >>> Of course if you are mapping independent audio captures onto > >>> different speakers then they are being implicitly mixed. > >> > >> Not a useful way to think about it, IMHO. Human ears and brains > >> can sort out individual sources if there are enough speakers, while > >> mixing makes that harder. > > > > I have had the impression that "simple" clue telepresence rooms would > > be hoping to do direct mapping of captures to devices. If the > > assumption is that this will be an unsatisfactory approach and all > > endpoints should be prepared to do something more complex then it > > would be helpful to write that down somewhere - e.g. in the > framework. > > > > [Espen] Agree with Paul here, the basic scenario is well understood. > A > > sends two logical audio captures and a receiver play them out with > the > > same spatial relationship. As rule of thumb here could be that for > > basic interoperability between vendors you assume pairs of audio and > > video captures that can be easily rendered on matching pairs of > > screens and speaker. > > > >>> - If you don't have speakers with similar spatial relationship to > >>> those of the audio captures, then you must decide whether to do > >>> sub-optimal assignments or mix. > >> > >> I suppose _some_ telepresence system will hide dozens of > >> speakers in the telepresence room and try to do this -- to me it > >> sounds like a dreadful idea, but it's quite possible the people will > adapt. > >> > >> "Sub-optimal" really doesn't have a clear meaning here. Even > >> speakers in the "wrong" left-to-right order while you can see the > >> "correct" order on-screen won't confuse the listener as much as > >> speaker assignments changing for no obvious reason. > >> > >>> Again not clear if the mixed attribute helps with this. > >> > >> As an extreme example, you could always render "mixed" in mono. > >> > >>> - If you have audio from more than one scene, what should you do > >>> with > > > >>> it? Should you mix, even though you have no spatial relationships? > >> > >> IMHO, you should _invent_ a spatial relationship in that case. > >> Even if each room invents a different spatial relationship, it will > >> prove less confusing. > >> > >>> Or should you switch based on active speaker? > >> > >> Only if background-noise is a serious problem. > >> > >>> What would help you to decide? > >> > >> It becomes quickly obvious to the listener! > >> > >>> The problems are superficially different for MCUs. But perhaps only > >>> superficially. It seems to me that when the MCU decides how to map > >>> its inputs into its advertisement, it has some virtual room layouts > > in mind. > >> > >> I would expect so. > >> > >>> So for each virtual room layout it is addressing the same issues as > >>> a > > > >>> real endpoint with that layout. But it does have the added problem > >>> of > > > >>> deciding how to describe what it is advertising - e.g. when to > apply > >>> the mixed/composed attributes. > >> > >> Pretty much always, unless it's feeding an exact copy of what > it > >> receives. > > > > Since I've seen people here describe cases when that isn't so, it > > would be helpful to have a more precise definition. > > > >>> Some interesting use cases for all of the above would be very > > helpful. > >> > >> Did the cases I listed help? > > > > I think they need to be worked out in much more detail: > > > > - what equipment (input and output) is in each endpoint, and where. > > - what is advertised and how the input equipment is mapped to > > the advertisement > > - how each endpoint maps the advertised captures to its output > equipment > > together with how the info in the advertisement allowed it to > > determine that mapping. > > > > [Espen] Agree, being practical about what we will offer for actual > > endpoints are useful. > > > > > > Thanks, > > Paul > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Sun Apr 15 11:14:49 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D641921F883F for ; Sun, 15 Apr 2012 11:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCuvVNl1R0C1 for ; Sun, 15 Apr 2012 11:14:49 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 08F8521F883E for ; Sun, 15 Apr 2012 11:14:49 -0700 (PDT) Received: by dady13 with SMTP id y13so8212183dad.27 for ; Sun, 15 Apr 2012 11:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ayaqgjUEIceaxt4XO/E9JXLiidtwB7IAF4y6oCD/wGQ=; b=idNBxseJNwTTBTJ4irfgvVWFdKZ3XtY2atg7FDBkukZ4EbKiFXscKMBkFRePr8Bgd7 uVo8bjrPc+wymD8MrxNzzCAI1EyP21f43Nra+62cqqDY5LeDpizmBrCa2B+hK2kiVbVY DhBW4w6iBK1csrxk073yCQptVi42xTAISzYGWq91huzZWwOdYKs9lvxXsSNa6esypfsu EBfO/olreGzYPBPISVrvi4iVPpHrMP/8t/uNVWOhaW4zS6S29cH/r459eRsEVYC95vl0 T6N+Les/QPSllvSU+ud3pwRpF/x6TCzU9UKd4sLPzCwGPTNWjMdCcIHtM6bQXd3L4a+n c0dg== MIME-Version: 1.0 Received: by 10.68.134.133 with SMTP id pk5mr22091684pbb.17.1334513688683; Sun, 15 Apr 2012 11:14:48 -0700 (PDT) Received: by 10.68.136.69 with HTTP; Sun, 15 Apr 2012 11:14:48 -0700 (PDT) In-Reply-To: <4F89E7F2.7090806@alum.mit.edu> References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E011976A2@XMB-AMS-214.cisco.com> <4F89E7F2.7090806@alum.mit.edu> Date: Sun, 15 Apr 2012 14:14:48 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b11190b5ca35e04bdbbae99 Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 18:14:50 -0000 --047d7b11190b5ca35e04bdbbae99 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 14, 2012 at 5:11 PM, Paul Kyzivat wrote: > Steven, > > The use case doc does cover this case, but it doesn't say much about how > the recipient (with fewer screens) decides what to display. > > It doesn't even hint at what Espen was implying - that the recipient asked > to sender to choose streams to meet the recipient's limitations. > > Thanks, > Paul > > [sb] What it says (in part) is 1. The 1 screen system might simply show only 1 of the 3 camera images, since the receiving side has only 1 screen. Two people are seen at full size, but 4 people are not seen at all. The choice of which 1 of the 3 streams to display could be fixed, or could be selected by the users. It could also be made automatically based on who is speaking in the 3 screen room, such that the people in the 1 screen room always see the person who is speaking. If the automatic selection is done at the sender, the transmission of streams that are not displayed could be suppressed, which would avoid wasting bandwidth. This is a solution-free description of course, and perhaps more possibilities could be outlined. Though I think it covers the basic ground. Answering the original question "Does the recipient have sufficient info to select the 'right' ones?" requires knowledge of the recipient's intent and tacit assumptions on what is being advertised. I think grounding this discussion in tangible use cases (specific advertisements with specific receiver limitations) would be more fruitful than trying to begin by discussing it in the abstract. If those specifics are not covered in the use cases, we should probably add them.[\sb] > > On 4/14/12 1:23 PM, Stephen Botzko wrote: > >> >> >> On Fri, Apr 13, 2012 at 7:44 AM, Espen Berger (espeberg) >> > wrote: >> >> > * Telepresence point to point, where the reproduction will happen >> in a >> >> > 2D-plane for audio and video. Currently CLUE support announcing >> > capability of sending 1 - N capture (left to right) and a >> receiver can >> >> > request 1 - M streams for rendering (left to tight), which is the >> > basic for interoperability. >> >> In this case, suppose N > M. Who is responsible for deciding which M of >> the N streams will be used? AFAIK the recipient just picks the ones it >> wants. So then my question remains - does the recipient have sufficient >> info to select the "right" ones? (There isn't any guarantee that *any* >> N >> of the M streams will provide a reasonable rendering. >> >> [Espen] A receiver requesting 2x streams to be rendered left, right, >> will rely on the media sender to give a decent experience. E.g. the >> most >> capable endpoint must translate its capabilities down to what lesser >> capable room can do. >> >> This would be improved if we had a mechanism for the recipient to state >> "I can only handle N streams" and the sender was obligated to meet that >> constraint. I don't think we have said that. >> >> [Espen] I see this as an important use case for interoperability. Its >> fine for capable Telepresence room to do a advanced CLUE advertisement, >> as long as there is an easy and straightforward way to request two >> captures screens for left, right placed monitors. >> >> We should have a use cases to express that we want to support endpoints >> that only support asking for 1 - N streams, rendered left to right. >> >> [sb] section 3.2 in the use case document covers the asymmetric case[/sb] >> >> >> Cheers >> >> -Espen >> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> > --047d7b11190b5ca35e04bdbbae99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Apr 14, 2012 at 5:11 PM, Paul Ky= zivat <pkyziv= at@alum.mit.edu> wrote:
Steven,

The use case doc does cover this case, but it doesn't say much about ho= w the recipient (with fewer screens) decides what to display.=A0

It doesn't even hint at what Espen was implying - that the recipient as= ked to sender to choose streams to meet the recipient's limitations.
=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

[sb] What= it says (in part) is

   1.  The 1 screen system might simply s=
how only 1 of the 3 camera
       images, since the receiving side has only 1 screen.  Two people
       are seen at full size, but 4 people are not seen at all.  The
       choice of which 1 of the 3 streams to display could be fixed, or
       could be selected by the users.  It could also be made
       automatically based on who is speaking in the 3 screen room, such
       that the people in the 1 screen room always see the person who is
       speaking.  If the automatic selection is done at the sender, the
       transmission of streams that are not displayed could be
       suppressed, which would avoid wasting bandwidth.

This is a = solution-free description of course, and perhaps more possibilities could b= e outlined.=A0=A0 Though I think it covers the basic ground.

Answeri= ng the original question "Does the recipient have sufficient info to s= elect the 'right' ones?" requires knowledge of the recipient&#= 39;s intent and tacit assumptions on what is being advertised.=A0 I think g= rounding this discussion in tangible use cases (specific advertisements wit= h specific receiver limitations) would be more fruitful than trying to begi= n by discussing it in the abstract. If those specifics are not covered in t= he use cases, we should probably add them.[\sb]
=A0


=A0

On 4/14/12 1:23 PM, Stephen Botzko wrote:


On Fri, Apr 13, 2012 at 7:44 AM, Espen Berger (espeberg)
<espeberg@cisco.= com <mailto:= espeberg@cisco.com>> wrote:

=A0 =A0 > * Telepresence point to point, where the reproduction will ha= ppen
=A0 =A0in a

=A0 =A0 > 2D-plane for audio and video. Currently CLUE support announci= ng
=A0 =A0 > capability of sending 1 - N capture (left to right) and a
=A0 =A0receiver can

=A0 =A0 > request 1 - M streams for rendering (left to tight), which is= the
=A0 =A0 > basic for interoperability.

=A0 =A0In this case, suppose N > M. Who is responsible for deciding whi= ch M of
=A0 =A0the N streams will be used? AFAIK the recipient just picks the ones= it
=A0 =A0wants. So then my question remains - does the recipient have suffic= ient
=A0 =A0info to select the "right" ones? (There isn't any gua= rantee that *any* N
=A0 =A0of the M streams will provide a reasonable rendering.

=A0 =A0[Espen] A receiver requesting 2x streams to be rendered left, right= ,
=A0 =A0will rely on the media sender to give a decent experience. E.g. the= most
=A0 =A0capable endpoint must translate its capabilities down to what lesse= r
=A0 =A0capable room can do.

=A0 =A0This would be improved if we had a mechanism for the recipient to s= tate
=A0 =A0"I can only handle N streams" and the sender was obligate= d to meet that
=A0 =A0constraint. I don't think we have said that.

=A0 =A0[Espen] I see this as an important use case for interoperability. I= ts
=A0 =A0fine for capable Telepresence room to do a advanced CLUE advertisem= ent,
=A0 =A0as long as there is an easy and straightforward way to request two<= br> =A0 =A0captures screens for left, right placed monitors.

=A0 =A0We should have a use cases to express that we want to support endpo= ints
=A0 =A0that only support asking for 1 - N streams, rendered left to right.=

[sb] section 3.2 in the use case document covers the asymmetric case[/sb]

=A0 =A0Cheers

=A0 =A0-Espen


=A0 =A0_______________________________________________
=A0 =A0clue mailing list
=A0 =A0clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0https://www.ietf.org/mailman/listinfo/clue




--047d7b11190b5ca35e04bdbbae99-- From pkyzivat@alum.mit.edu Mon Apr 16 06:56:12 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C579C21F8760 for ; Mon, 16 Apr 2012 06:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHbkM+m1X4nH for ; Mon, 16 Apr 2012 06:56:12 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id B530521F85B6 for ; Mon, 16 Apr 2012 06:56:11 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id yc0P1i00527AodY5AdwC06; Mon, 16 Apr 2012 13:56:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id ydwB1i02907duvL3fdwBsA; Mon, 16 Apr 2012 13:56:12 +0000 Message-ID: <4F8C24FA.90205@alum.mit.edu> Date: Mon, 16 Apr 2012 09:56:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Espen Berger (espeberg)" References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E011976A2@XMB-AMS-214.cisco.com> <4F883FFD.3060109@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E011977CB@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E011977CB@XMB-AMS-214.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Sender to comply with receiver limits on what it can receive (?) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 13:56:13 -0000 On 4/15/12 7:01 AM, Espen Berger (espeberg) wrote: > I was not thinking about adding the capability message back in. Hmm. AFAIK we didn't take it out. We just haven't worked on it much. > My comment was to make sure that a receiver of a CLUE advertisement > message can understand what the media consumers preferred configurations > are for a two screen endpoint. It cannot be only up to the two screen > endpoint to choose correctly between alternatives, the sender can send > some useful hints to make it easier to choose between alternatives. Suppose the sender's preferred configuration is a 3-screen room plus a separate display for presentations. Is it expected to create capture scene entries for not only that, but for all interesting lesser configurations, so that a recipient need only choose a single entry? This might mean the sender has to construct entries for all of: - 4 screens (one for presentation) - 3 screens - 2 screens - 1 screen Alternatively, the recipient will need enough information to figure out what to do when none of the capture scene entries map well to the available equipment. Note that this is more complex if there is more than one scene in the advertisement. E.g. the "natural" way to advertise this might be as one 'main' scene and one 'presentation' scene, because the physical relationship of the presentation screens to the other scenes is irrelevant. But that means that the recipient must choose one capture scene entry from each scene, and those must map independently to local screens. If the recipient has four screens this is easy. But if the recipient has fewer than four screens, then it is a problem, since it then becomes hard to share one screen for captures from two capture scene entries. I have a gut feeling that something is not quite right here - it just doesn't hang together smoothly. But I'm not certain precisely what is wrong. Thanks, Paul > -Espen > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 13. april 2012 17:02 > To: Espen Berger (espeberg) > Cc: John Leslie; CLUE > Subject: Sender to comply with receiver limits on what it can receive > (?) > > Changing the subject line. This is one specific point coming out of the > thread on "Does framework provide sufficient info for receiver?" > > Paraphrasing, I think Espen is calling for a requirement that the sender > construct an advertisement that is consistent with receiver > capabilities. This seems to require the (still undefined) Capabilities > message, and to make it binding. > > AFAIK we currently have no such requirement. > Do others think we should? > > Thanks, > Paul > > On 4/13/12 7:44 AM, Espen Berger (espeberg) wrote: >>> * Telepresence point to point, where the reproduction will happen in >>> a >> >>> 2D-plane for audio and video. Currently CLUE support announcing >>> capability of sending 1 - N capture (left to right) and a receiver >>> can >> >>> request 1 - M streams for rendering (left to tight), which is the >>> basic for interoperability. >> >> In this case, suppose N> M. Who is responsible for deciding which M >> of the N streams will be used? AFAIK the recipient just picks the ones > >> it wants. So then my question remains - does the recipient have >> sufficient info to select the "right" ones? (There isn't any guarantee > >> that *any* N of the M streams will provide a reasonable rendering. >> >> [Espen] A receiver requesting 2x streams to be rendered left, right, >> will rely on the media sender to give a decent experience. E.g. the >> most capable endpoint must translate its capabilities down to what >> lesser capable room can do. >> >> This would be improved if we had a mechanism for the recipient to >> state "I can only handle N streams" and the sender was obligated to >> meet that constraint. I don't think we have said that. >> >> [Espen] I see this as an important use case for interoperability. Its >> fine for capable Telepresence room to do a advanced CLUE >> advertisement, as long as there is an easy and straightforward way to >> request two captures screens for left, right placed monitors. >> >> We should have a use cases to express that we want to support >> endpoints that only support asking for 1 - N streams, rendered left to > right. >> >> Cheers >> >> -Espen >> >> >> > > From pkyzivat@alum.mit.edu Mon Apr 16 07:11:49 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30D821F8722 for ; Mon, 16 Apr 2012 07:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8uoPrTKz6eI for ; Mon, 16 Apr 2012 07:11:48 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8A32321F8710 for ; Mon, 16 Apr 2012 07:11:48 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta12.westchester.pa.mail.comcast.net with comcast id ydtz1i00A1uE5Es5CeBpYo; Mon, 16 Apr 2012 14:11:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id yeBo1i00R07duvL3ceBpiH; Mon, 16 Apr 2012 14:11:49 +0000 Message-ID: <4F8C28A3.8030209@alum.mit.edu> Date: Mon, 16 Apr 2012 10:11:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Stephen Botzko References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E011976A2@XMB-AMS-214.cisco.com> <4F89E7F2.7090806@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 14:11:49 -0000 Please see reply inline. On 4/15/12 2:14 PM, Stephen Botzko wrote: > > > On Sat, Apr 14, 2012 at 5:11 PM, Paul Kyzivat > wrote: > > Steven, > > The use case doc does cover this case, but it doesn't say much about > how the recipient (with fewer screens) decides what to display. > > > It doesn't even hint at what Espen was implying - that the recipient > asked to sender to choose streams to meet the recipient's limitations. > > Thanks, > Paul > > [sb] What it says (in part) is > > 1. The 1 screen system might simply show only 1 of the 3 camera > images, since the receiving side has only 1 screen. Two people > are seen at full size, but 4 people are not seen at all. The > choice of which 1 of the 3 streams to display could be fixed, or > could be selected by the users. It could also be made > automatically based on who is speaking in the 3 screen room, such > that the people in the 1 screen room always see the person who is > speaking. If the automatic selection is done at the sender, the > transmission of streams that are not displayed could be > suppressed, which would avoid wasting bandwidth. > > > This is a solution-free description of course, and perhaps more > possibilities could be outlined. Though I think it covers the basic > ground. Of course there are a number of ways to cope with insufficient hw to display everything. Of those, some (more than one) are plausible, and some others would probably be judged stupid by any rational person. > Answering the original question "Does the recipient have sufficient info > to select the 'right' ones?" requires knowledge of the recipient's > intent and tacit assumptions on what is being advertised. I think > grounding this discussion in tangible use cases (specific advertisements > with specific receiver limitations) would be more fruitful than trying > to begin by discussing it in the abstract. If those specifics are not > covered in the use cases, we should probably add them.[\sb] I agree. I already suggested that this be investigated via use cases. The existing use cases can be a useful starting point, but they will need to be elaborated with futher assumptions about what rendering hw is available and perhaps something about preferences of the recipient. My point in raising the issue is that so far, when just exploring some of these cases in my head, it seems like there probably isn't sufficient information. But I am not the expert here, and I may well be making unreasonable assumptions. I think at least some others (Espen and Roni) think there *is* sufficient info. Note that I got to this question from the discussions of mixed/composed, because I wasn't seeing common agreement on how these would be used to help with this kind of decision. But my question here is more general, since there is a considerable amount of data defined that might affect this decision. Thanks, Paul > On 4/14/12 1:23 PM, Stephen Botzko wrote: > > > > On Fri, Apr 13, 2012 at 7:44 AM, Espen Berger (espeberg) > > >> wrote: > > > * Telepresence point to point, where the reproduction will happen > in a > > > 2D-plane for audio and video. Currently CLUE support announcing > > capability of sending 1 - N capture (left to right) and a > receiver can > > > request 1 - M streams for rendering (left to tight), which is the > > basic for interoperability. > > In this case, suppose N > M. Who is responsible for deciding > which M of > the N streams will be used? AFAIK the recipient just picks > the ones it > wants. So then my question remains - does the recipient have > sufficient > info to select the "right" ones? (There isn't any guarantee > that *any* N > of the M streams will provide a reasonable rendering. > > [Espen] A receiver requesting 2x streams to be rendered > left, right, > will rely on the media sender to give a decent experience. > E.g. the most > capable endpoint must translate its capabilities down to > what lesser > capable room can do. > > This would be improved if we had a mechanism for the > recipient to state > "I can only handle N streams" and the sender was obligated to > meet that > constraint. I don't think we have said that. > > [Espen] I see this as an important use case for > interoperability. Its > fine for capable Telepresence room to do a advanced CLUE > advertisement, > as long as there is an easy and straightforward way to > request two > captures screens for left, right placed monitors. > > We should have a use cases to express that we want to > support endpoints > that only support asking for 1 - N streams, rendered left to > right. > > [sb] section 3.2 in the use case document covers the asymmetric > case[/sb] > > > Cheers > > -Espen > > > _________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/__listinfo/clue > > > > > From pkyzivat@alum.mit.edu Mon Apr 16 07:34:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB15221F8752 for ; Mon, 16 Apr 2012 07:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joEIONuXVHp9 for ; Mon, 16 Apr 2012 07:34:57 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 9889E21F874A for ; Mon, 16 Apr 2012 07:34:56 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta14.westchester.pa.mail.comcast.net with comcast id ydoP1i0041uE5Es5EeaxKb; Mon, 16 Apr 2012 14:34:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id yeaw1i01D07duvL3ceawLr; Mon, 16 Apr 2012 14:34:57 +0000 Message-ID: <4F8C2E0F.4070005@alum.mit.edu> Date: Mon, 16 Apr 2012 10:34:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Roni Even References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> In-Reply-To: <4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'CLUE' Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 14:34:59 -0000 Hi Roni, On 4/15/12 11:20 AM, Roni Even wrote: > Hi Paul, > I think that there is enough information that will allow a receiver to > select N out of M streams. > The receiver will know the semantics of the streams (people or presentation) > and the spatial information of the room and the different streams. > My view is that this is enough for the general telepresence point to point > use case. I think I agree for the case where there is a single scene advertised, and all the captures represent single cameras. But as soon as you add in mixed or switched captures it becomes far less clear. For instance, suppose the sender does something to combine some of its captures so that it can advertise a capture scene entry that requires fewer displays. E.g. suppose it has three main captures of participants and one presentation capture. And suppose in addition to advertising all of those as one entry, it also advertises another entry for a three-screen room, consisting of one capture for the presentation, one for the current speaker, and one for the prior speaker. So that is one fixed and two switched captures. If the recipient need to map this to two displays, how does it decide what to do? The obvious thing would be to omit the capture for the prior speaker. But how would it know which one that is. > As for multipoint use case, this is why I think it is important to know if > the advertisement is based on site switch or segment switch which will > provide the extra information needed for the selection (spatial information > provides the internal relation between the capture) and I think that the > audio level will help with knowing who are the active speakers in this case I think there are too many unknowns in the above to discuss it with clarity. We need some use cases. Thanks, Paul > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Thursday, April 12, 2012 11:37 PM >> To: Espen Berger (espeberg) >> Cc: CLUE >> Subject: Re: [clue] Does framework provide sufficient info for >> receiver? >> >> Espen - comments inline. >> >> Thanks, >> Paul >> >> On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: >>> During the CLUE design team meeting on webex yesterday we started to >>> discuss various use cases and if they are in scope or not for the >>> current work in CLUE. >>> >>> As a part of my response to Pauls questions I summarized the use >> cases >>> and grouped them into supported / not supported. I can dive into more >>> detail about the use cases if people are interested? >>> >>> I would answer yes to the following use cases >>> * Telepresence point to point, where the reproduction will happen in >> a >>> 2D-plane for audio and video. Currently CLUE support announcing >>> capability of sending 1 - N capture (left to right) and a receiver >> can >>> request 1 - M streams for rendering (left to tight), which is the >>> basic for interoperability. >> >> In this case, suppose N> M. Who is responsible for deciding which M of >> the N streams will be used? AFAIK the recipient just picks the ones it >> wants. So then my question remains - does the recipient have sufficient >> info to select the "right" ones? (There isn't any guarantee that *any* >> N of the M streams will provide a reasonable rendering. >> >> This would be improved if we had a mechanism for the recipient to state >> "I can only handle N streams" and the sender was obligated to meet that >> constraint. I don't think we have said that. >> >>> * Transcoded conferencing, where the MCU act like an endpoint and >>> logically announces audio and video left to right and a receiver >>> request >>> 1 - M captures depending on how many screen and audio streams you >>> prefer. Typically a single video stream pr. screen and one audio pr. >>> screen (mono/stereo). Excluded is capabilities to select individual >>> speakers, the MCU is free to optimize what to compose and send to a >>> receiver. >> >> This is logically equivalent to the prior case. >> >>> * Generic multi source, sending and receiving named sources where the >>> user experience is controlled by an human being capable of reading >>> sources names, or control software written explicit to operate on the >>> named streams. The content attribute can be used to indicate a >> primary >>> role, RFC4796 uses 'main' and 'alt'. >> >> Are you talking about the text names/labels we were discussing on the >> last call? >> >> If so, I agree that if the senders provide well conceived labels then a >> human can probably decide something reasonable. >> >> If the human is working only with "content" attributes, then its not so >> clear. Its quite possible that the recipient will find itself trying to >> choose between multiple streams with the same content type. (E.g. all >> 'main'.) >> >>> I would answer no, to the following use cases >>> * Switched conferencing, where we assume that endpoints do scalable >>> video (either SVC or Simulcast), locally composited layout and audio >>> mixing. Limited work has been done on how to use Scalable video and >>> how to build mechanisms for complete composited layouts. >>> * Advanced audio reproduction, a group of audio scenarios mentioned >> by >>> Jon Leslie and Johan Nielsen that requires more details during >> initial >>> signalling and more dynamic information for transferring dynamic >>> meta-information. >>> * Multi view, as described in the CLUE use case document. >>> >>> (Other comments inline.) >>> >>> Cheers >>> >>> -Espen >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: 11. april 2012 17:06 >>> To: John Leslie >>> Cc: CLUE >>> Subject: Re: [clue] Does framework provide sufficient info for >> receiver? >>> >>> Hi John, >>> >>> Thanks for the comments. I've followed up inline. >>> >>> On 4/10/12 5:09 PM, John Leslie wrote: >>>> Paul Kyzivat wrote: >>>>> >>>>> The fundamental problem in the scope of CLUE is, if you are an >>>>> endpoint, and you have received an advertisement, with some scenes >>>>> and captures, do you have sufficient information to select and map >>>>> the advertised scenes/captures onto the equipment you have? >>>> >>>> Of course not! >>>> >>>> If we wanted that, we'd have to include for every composed >> scene >>>> what it's composed from, and for every mixed audio what it's mixed >>>> from. >>> >>> I think you must have misunderstood me. Otherwise I wouldn't expect >>> you to answer "Of course not". AFAIK the whole point of CLUE is to >>> provide the information to make this possible. >>> >>> My point in asking the question was so that we can identify what >>> information we have overlooked that we need to include one way or >>> another. >>> >>> Clearly there are some tradeoffs. More information might support >>> *better* mappings. So one thing to decide is how good is good enough. >>> [Espen] Agree with Paul, we clearly can support in CLUE the use cases >>> where a Telepresence room either offer a 1, 2 or 3 video captures, >>> which can be rendered on 1, 2 or 3 screens. >> >> I think its clear we can support cases where every advertisement that >> includes an entry for N (>1) captures also includes an entry with only >> one capture, and optionally entries containing other numbers of >> captures between 1 and N. >> >> But as I mention above, its not clear we have supported case where the >> minimal entry in the advertisement is for N>1 captures. >> >>>>> If you have sufficient equipment (displays, speakers) with >>>>> compatible >>> >>>>> geometry to directly map all of the captures from one audio and one >>>>> video capture scene entry from each capture scene then maybe all is >>>>> good. In this case ISTM that the mixed/composed attributes aren't >>>>> needed. >>>> >>>> It's unlikely that the "typical" telepresence conference will >>>> have >>> >>>> a separate screen for every possible video. >>> >>> That isn't what I said. Consider what is perhaps a typical case, >> where >>> the advertisement contains one scene with several alternative video >>> and audio scene entries. Lets just consider the video. Then maybe >>> there is one entry with three captures, and another with one >>> (mixed/switched, >>> whatever) capture. Then if you have three screens you can map all >>> three captures in the first entry. If you have less than three >> screens >>> then you can map the one capture from the 2nd entry onto one of your >> screens. >>> >>> But what if there was no entry with a single capture? If you had two >>> screens, would you have enough info about the three captures in the >>> first entry to make a reasonable mapping onto your two screens? What >>> information would we need to include in the advertisement so that it >>> would be possible to do this mapping well? >>> >>> [Espen] How a vendor build a room or endpoint is transparent from the >>> sender of media. As a sender you should not care if a room request 3 >>> audio streams (left, center, right) and choose to mix and play out on >>> a single speaker. We can argue that this is not the best experience, >>> but still valid and typically done for PC-clients or other endpoints >>> with a single speaker. >> >> Again, I think you are assuming the receiver can specify the max number >> of streams it can handle, and that the sender will then be obligated to >> select/construct a suitable set of streams. AFAIK we have not written >> down anything that calls for that. (If I am wrong, please let me know >> where this is specified.) >> >> We have the (largely hypothetical) recipient capabilities message, but >> its content hasn't been specified yet, and AFAIK there has been no >> statement that it is binding and the construction of the advertisement. >> >>>> Of course, the number of "capture scenes" _could_ be small >>>> enough to give each it's own video monitor -- but I don't think >>>> that's the general case we should design for. >>> >>> IIUC an endpoint will typically only advertise one or two scenes. One >>> would correspond to the cameras and mics in its room. The other, if >>> present, would correspond to a "presentation" that doesn't fit into >>> the coordinate space of the room. There are cases for more, but they >>> get more obscure. >>> >>> So for a point-to-point clue call the recipient will only need to map >>> one or two scenes. But when there is more than one it is more >> complex, >>> requiring sharing of equipment. >>> >>> The situation is more complex for an MCU. It will have as input all >>> the scenes offered by all the endpoints. It then has to decide what >> to >>> offer out to the endpoints. It could just pass through all the scenes >>> it receives from all the endpoints, leaving the mapping problem >>> entirely to the endpoints. (I don't think that is what most people >>> have in mind, though some might.) >>> >>> Or it could take on itself the job of mapping/mixing/switching all of >>> those inputs and producing something more like what a typical >> endpoint >>> would advertise - one or two scenes each with just a few captures. >>> >>> Or it could do both - advertise its own simplified composite scenes >>> and also all those provided by the endpoints. That would allow the >>> endpoints to either take the easy way out, or else do it all >>> themselves in a way that suits them. Suppose it did this. Would the >>> endpoints that want to take the easy way be able to figure out which >>> scenes and captures to use? >>> >>> [Espen] This sounds closer to a user experience discussions than a >>> protocol discussion. >> >> Perhaps it is. But the point of CLUE is to develop a protocol that >> enables an especially good user experience. While we shouldn't mandate >> the user experience, I think we are obligated to do due diligence that >> the protocol is sufficient to enable that user experience. >> >>>> OTOH, with an appropriate "surround-sound" system, you can >> "place" >>>> an arbitrarily large number of audio streams, yet make them easy to >>>> distinguish. >>>> >>>>> If you don't have sufficient equipment to do that, then the job is >>>>> harder, and more information is needed to figure out what to do. >>>> >>>> Only marginally harder... >>>> >>>>> For instance: >>>>> >>>>> - If you don't have suitable displays, then perhaps you can select >> a >>>>> video capture scene entry and locally compose or switch some of the >>>>> captures in order to produce a set of captures that does map to the >>>>> available displays. The area of capture of each capture could be >>>>> helpful to doing this, and perhaps the composed attribute as well. >>>> >>>> One inevitable use case is filing your formal report from the >>> airport. >>>> The person doing so will have lousy audio, vastly inadequate video, >>>> and typically inadequate bandwidth with excessive latency. S/he will >>>> need some middlebox to compose a "barely-adequate video" and mono >>> audio. >>> >>> This is indeed an interesting case - one we have explicitly put in >>> scope. If an MCU is already in the call then perhaps we can hope that >>> is one of the entries it makes available. >>> >>> If there isn't any MCU in the call, then the other endpoint might not >>> advertise that option. Then what? Do we have a mechanism for that? >>> [Espen] If an MCU detect low bandwidth or packet loss it can start >>> using its normal recovery mechanisms. That could lower bitrate for >>> audio and video (maybe by a SIP re-invite), change the CLUE offer to >>> something that fits inside the available bandwidth. Getting good >>> quality audio ande video is always a challenge, with or without clue. >>> >>>> Then there's the use case of filing you formal report from your >>>> home office (when you're sick or somebody doesn't want to pay travel >>> cost). >>>> You may well have surround-sound and two or three large monitors, 20 >>>> Mbps download with 40 msec RTT, and a decent-quality lavalier mike. >>>> You still probably want some middlebox to compose your basic video, >>>> but you can take individual streams as well to concentrate on >>> particular people. >>>> >>>> Near the top end are the corporate telepresence rooms. They >> will >>>> want all streams, and are likely to have a human being mixing them. >>> >>> I don't understand your point "are likely to have a human being >> mixing >>> them". Can you explain further? >>> [Espen] I see this as mostly a request for focusing in on particular >>> user. In a transcoded conference you can do that by looking into >> XCon, >>> if you do switched conference the endpoint typically render the >> layout >>> and can choose who to focus on. Mixing transcoded and switched >>> conferencing I think makes it unnecessary complex for the initial use >>> cases to cover. >>> >>>>> - or rather than compose to fit your displays, you could switch... >>>> >>>> Folks _will_ do that -- I can't stop them. But I find it >>> uninteresting. >>> >>> ??? We have been talking about switching a lot. Are you saying that >> is >>> uninteresting? >>> >>> If it makes sense for a middlebox to switch, doesn't it make equal >>> sense for an endpoint to do so? >>> >>>>> - handling video from multiple scenes probably presents some added >>>>> issues. By definition there is no specified spatial relationship >>>>> between the captures of different scenes... >>>> >>>> Nonetheless, the participants will want to imagine such a >>> relationship. >>> >>> ISTM that this needs further discussion. >>> >>>>> - If you don't have sufficient speakers for all of the audio >>>>> captures, then you have to decide to mix, switch, or drop some. >>>> >>>> There really isn't any such thing as "sufficient speakers", but >>>> surround-sound should be considered "sufficient". You can always mix >>>> to stereo or even mono: "you pays your money and you takes your >>> choice". >>> >>> Do we have enough information to do it "right" or "well"? >>> Right now the coordinate info is all optional. Does it need to be >>> mandatory in order to enable this? >>> >>>>> The spatial information from the captures may help in deciding how >>>>> to >>> >>>>> mix. >>>> >>>> Absolutely! >>>> >>>>> Not evident that the mixed attribute helps with this >>>> >>>> It help you know when mixing is less likely to work well. >>>> >>>>> - unless it is used to decide to switch rather than mix. >>>> >>>> I'm not sure there is any such thing. "Mixing" frequently >>>> includes >>> >>>> "riding gain" to reduce background noise. Binary switching is just a >>>> bad idea. >>> >>> I have no special understanding of this. I'm just asking probing >>> questions in hopes that it will result in the right decisions being >>> made and the right stuff specified. >>> >>>>> Of course if you are mapping independent audio captures onto >>>>> different speakers then they are being implicitly mixed. >>>> >>>> Not a useful way to think about it, IMHO. Human ears and brains >>>> can sort out individual sources if there are enough speakers, while >>>> mixing makes that harder. >>> >>> I have had the impression that "simple" clue telepresence rooms would >>> be hoping to do direct mapping of captures to devices. If the >>> assumption is that this will be an unsatisfactory approach and all >>> endpoints should be prepared to do something more complex then it >>> would be helpful to write that down somewhere - e.g. in the >> framework. >>> >>> [Espen] Agree with Paul here, the basic scenario is well understood. >> A >>> sends two logical audio captures and a receiver play them out with >> the >>> same spatial relationship. As rule of thumb here could be that for >>> basic interoperability between vendors you assume pairs of audio and >>> video captures that can be easily rendered on matching pairs of >>> screens and speaker. >>> >>>>> - If you don't have speakers with similar spatial relationship to >>>>> those of the audio captures, then you must decide whether to do >>>>> sub-optimal assignments or mix. >>>> >>>> I suppose _some_ telepresence system will hide dozens of >>>> speakers in the telepresence room and try to do this -- to me it >>>> sounds like a dreadful idea, but it's quite possible the people will >> adapt. >>>> >>>> "Sub-optimal" really doesn't have a clear meaning here. Even >>>> speakers in the "wrong" left-to-right order while you can see the >>>> "correct" order on-screen won't confuse the listener as much as >>>> speaker assignments changing for no obvious reason. >>>> >>>>> Again not clear if the mixed attribute helps with this. >>>> >>>> As an extreme example, you could always render "mixed" in mono. >>>> >>>>> - If you have audio from more than one scene, what should you do >>>>> with >>> >>>>> it? Should you mix, even though you have no spatial relationships? >>>> >>>> IMHO, you should _invent_ a spatial relationship in that case. >>>> Even if each room invents a different spatial relationship, it will >>>> prove less confusing. >>>> >>>>> Or should you switch based on active speaker? >>>> >>>> Only if background-noise is a serious problem. >>>> >>>>> What would help you to decide? >>>> >>>> It becomes quickly obvious to the listener! >>>> >>>>> The problems are superficially different for MCUs. But perhaps only >>>>> superficially. It seems to me that when the MCU decides how to map >>>>> its inputs into its advertisement, it has some virtual room layouts >>> in mind. >>>> >>>> I would expect so. >>>> >>>>> So for each virtual room layout it is addressing the same issues as >>>>> a >>> >>>>> real endpoint with that layout. But it does have the added problem >>>>> of >>> >>>>> deciding how to describe what it is advertising - e.g. when to >> apply >>>>> the mixed/composed attributes. >>>> >>>> Pretty much always, unless it's feeding an exact copy of what >> it >>>> receives. >>> >>> Since I've seen people here describe cases when that isn't so, it >>> would be helpful to have a more precise definition. >>> >>>>> Some interesting use cases for all of the above would be very >>> helpful. >>>> >>>> Did the cases I listed help? >>> >>> I think they need to be worked out in much more detail: >>> >>> - what equipment (input and output) is in each endpoint, and where. >>> - what is advertised and how the input equipment is mapped to >>> the advertisement >>> - how each endpoint maps the advertised captures to its output >> equipment >>> together with how the info in the advertisement allowed it to >>> determine that mapping. >>> >>> [Espen] Agree, being practical about what we will offer for actual >>> endpoints are useful. >>> >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From marshall.eubanks@gmail.com Mon Apr 16 07:56:13 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495FA11E808D for ; Mon, 16 Apr 2012 07:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRK0yEpZsYun for ; Mon, 16 Apr 2012 07:56:12 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD50B11E808F for ; Mon, 16 Apr 2012 07:56:11 -0700 (PDT) Received: by lagj5 with SMTP id j5so4305408lag.31 for ; Mon, 16 Apr 2012 07:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=C3KYvWGQ5shCrgU+wBUp/6ca5O3+nLEMCU4m0/qtL8c=; b=SZNy2myUggZ7p/qFqLL+lk2372/BYhKcnoAdYr8eA2Kl8ZycMBNr1T1lbc7QV/yamj /4rHT1+gZQ0e0iRwuqt1EkvX2x5DNbn+Ngyl7DP36p99jV3AW67/8xSBVSjXMNImeolA wsbB9+3LzBCM0NuiOwETl5pPlVg3nU8H+NYa6niPy2WJ6nqFQ2WfcFEugOjDfjoC8uhl 0dJpkJMWPFljYkP0h6uC1PVVTX566aCKHnFh/1+gvPmJP6I601EdztuNtTEVTXvZHmtl UDzajVEttI5JvUxLQ6uKmTW8BsqZdAerYwHmRg0Pg8UOf0FMtl3D6sm+d1LiQBRc8ndq 0jTQ== MIME-Version: 1.0 Received: by 10.152.132.166 with SMTP id ov6mr11578776lab.35.1334588170720; Mon, 16 Apr 2012 07:56:10 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Mon, 16 Apr 2012 07:56:10 -0700 (PDT) In-Reply-To: <4F8BDA2B.3040204@ericsson.com> References: <4F732531.2030208@ericsson.com> <4F8BDA2B.3040204@ericsson.com> Date: Mon, 16 Apr 2012 10:56:10 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] Fwd: [rtcweb] Consensus call regarding media security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 14:56:13 -0000 I thought that CLUE people might be interested in this. Encryption has not (to my knowledge) been seriously discussed in CLUE. It is not mentioned in the Requirements, Framework or Use Cases documents. Now, RTCWEB has just made it mandatory (against some opposition, but the consensus call is below). Of course, RTCWEB is not the videoconferencing industry, and we clearly cannot mandate encryption (as the videoconferencing industry has not). However Some might say that encryption is at a layer below CLUE, but I actually think that is wrong and that we are going to have to deal with it some. CLUE will include metadata (such as, potentially, the participants names) and configuration options that users will expect to have encrypted. I would actually regard it as a security breach to say, transport will be encrypted, but all of the host of CLUE data will carried in the clear. Worse, I think it is a reality that this means that encrypted RTCWEB session will be run with unencrypted CLUE telepresence sessions, and we need to think about the implications of that. I also think we are going to have to think more than we have (or, at least, than I have) about the general security implications of the CLUE data, how to best authenticate CLUE exchanges, and how to ensure that CLUE traffic is protected. Questions I see arising from this include - should CLUE traffic be protected by https / SSL ? Is that a MAY, a SHOULD or a MUST ? - what are the security information of the information shared by CLUE ? Does some of it (e.g., user names) require more protection than other pieces. - If a session is encrypted, is the CLUE information also required to be encrypted ? Does that use the same security infrastructure, or a separate one? For example, if there is encryption through a shared secret distributed through a PKI or by some other means, does CLUE share that secret? If the CLUE exchange goes on _before_ the PKI exchange, using some other PKI or SSL, does it change once the shared secret has been distributed? I know that all of this might not be required for RTCWEB, but we might as well start thinking about it anyway. Regards Marshall ---------- Forwarded message ---------- From: Magnus Westerlund Date: Mon, Apr 16, 2012 at 4:36 AM Subject: Re: [rtcweb] Consensus call regarding media security To: rtcweb@ietf.org, EKR WG, EKR The deadline for this call of consensus has ended. I note that there has been discussion of a number of details and additional views on the actual consensus statement made. Some supporting the consensus from the meeting room and some opposing it. In the end I determine that the two consensus statements are confirmed: =A0The first was that there was overwhelming consensus that all RTP =A0packets SHALL be protected by SRTP. =A0Secondly that no one objected against making DTLS-SRTP a mandatory to =A0implement and the default keying mechanism. Additional mechanisms are =A0not precluded. >From the discussion in the thread I would note the following: 1) Null cipher for encryption is strongly desired but an actual proposal is needed for how to express this. 2) Details of the SRTP and DTLS-SRTP usage in this WG needs to be defined. This is for continued discussion. I hope our editor of the security architecture can make a proposal to the WG to consider. 3) The discussion of additional keying mechanisms such as Security Descriptions and Encrypted Key Transport will continue. Cheers Magnus On 2012-03-28 16:50, Magnus Westerlund wrote: > WG, > > In todays RTCWEB WG meeting there was discussion around media security > mechanism. In this meeting there was some clear consensus in the > meeting which we would like to confirm on the list. > > The first was that there was overwhelming consensus that all RTP > packets SHALL be protected by SRTP. > > Secondly that no one objected against making DTLS-SRTP a mandatory to > implement and the default keying mechanism. Additional mechanisms are > not precluded. > > WG participants may state their position regarding these consensus calls > until 12th of April when the chairs will declare the final consensus. If > you where present in the meeting room and comment on this, please > indicate that. > > Best Regards > > Magnus Westerlund > For the WG chairs > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From ron.even.tlv@gmail.com Mon Apr 16 09:28:34 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4562511E8091 for ; Mon, 16 Apr 2012 09:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSvXC8EtRlSz for ; Mon, 16 Apr 2012 09:28:32 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CED5611E80A5 for ; Mon, 16 Apr 2012 09:28:31 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so7503476wib.13 for ; Mon, 16 Apr 2012 09:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=SlERlyfOw6LJbiBowMVyf5ICnd5UBGSMydyKUZcD/jo=; b=FQ9HF4MTFTzUy9+LbNwUyKq5s95Ii3tKddL66+x3QrK4VW3EZeuN6qCzL/6XhJG0ns kJz8zHaqDKBNKkrK89MBifffRviO5iG34zF0arU9r9fGUlqyzmN5b3Y8+3oxR38+lSaK +/4XqXWDfZzeLnypX0pn5mu8+G7g3D5R2ENDyrWqnyZaF0JDEUN1YHd2F0Npg3574O2C 6HeHfSK3tyTrQi/Hg5D2eD1J1EUOOoo70LO9M8aWL5WQ9zRhFAAtJoEbZ+Ir6DXLZTKb VtvNerqvrhTuX20xmouEtLbdvtIj4PZZbRfhKvOcQ6kMyrZ6+ZURj9ViIHX/YS28/MqR dIKw== Received: by 10.180.97.4 with SMTP id dw4mr8753000wib.18.1334593710905; Mon, 16 Apr 2012 09:28:30 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id n20sm33174982wiw.5.2012.04.16.09.28.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 09:28:29 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> In-Reply-To: <4F8C2E0F.4070005@alum.mit.edu> Date: Mon, 16 Apr 2012 19:26:56 +0300 Message-ID: <4f8c48ad.f44cb40a.72e3.60f0@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0b3hhrWdEsAflvQB6TGsdJgQ+oMgADsOIg Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:28:34 -0000 Hi Paul, Inline Roni > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Monday, April 16, 2012 5:35 PM > To: Roni Even > Cc: 'Espen Berger (espeberg)'; 'CLUE' > Subject: Re: [clue] Does framework provide sufficient info for > receiver? > > Hi Roni, > > On 4/15/12 11:20 AM, Roni Even wrote: > > Hi Paul, > > I think that there is enough information that will allow a receiver > to > > select N out of M streams. > > The receiver will know the semantics of the streams (people or > > presentation) and the spatial information of the room and the > different streams. > > My view is that this is enough for the general telepresence point to > > point use case. > > I think I agree for the case where there is a single scene advertised, > and all the captures represent single cameras. > > But as soon as you add in mixed or switched captures it becomes far > less clear. > > For instance, suppose the sender does something to combine some of its > captures so that it can advertise a capture scene entry that requires > fewer displays. E.g. suppose it has three main captures of participants > and one presentation capture. And suppose in addition to advertising > all of those as one entry, it also advertises another entry for a > three-screen room, consisting of one capture for the presentation, one > for the current speaker, and one for the prior speaker. So that is one > fixed and two switched captures. If the recipient need to map this to > two displays, how does it decide what to do? The obvious thing would be > to omit the capture for the prior speaker. But how would it know which > one that is. This is an interesting case but I am not sure it will happen. My view from current application is that for this case there will be one switch capture advertised and the content in the stream will be decided by the sending entity (MCU) to be the current speaker or previous speaker depending on the receiver. BTW: If a consumer wants to create such application it can start by getting the active speaker and afterwards continue to receive the active speaker and request the stream where the previous speaker is based on the spatial information from the three main captures. > > > As for multipoint use case, this is why I think it is important to > > know if the advertisement is based on site switch or segment switch > > which will provide the extra information needed for the selection > > (spatial information provides the internal relation between the > > capture) and I think that the audio level will help with knowing who > > are the active speakers in this case > > I think there are too many unknowns in the above to discuss it with > clarity. We need some use cases. > > Thanks, > Paul > > > Roni > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Thursday, April 12, 2012 11:37 PM > >> To: Espen Berger (espeberg) > >> Cc: CLUE > >> Subject: Re: [clue] Does framework provide sufficient info for > >> receiver? > >> > >> Espen - comments inline. > >> > >> Thanks, > >> Paul > >> > >> On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: > >>> During the CLUE design team meeting on webex yesterday we started > to > >>> discuss various use cases and if they are in scope or not for the > >>> current work in CLUE. > >>> > >>> As a part of my response to Pauls questions I summarized the use > >> cases > >>> and grouped them into supported / not supported. I can dive into > >>> more detail about the use cases if people are interested? > >>> > >>> I would answer yes to the following use cases > >>> * Telepresence point to point, where the reproduction will happen > in > >> a > >>> 2D-plane for audio and video. Currently CLUE support announcing > >>> capability of sending 1 - N capture (left to right) and a receiver > >> can > >>> request 1 - M streams for rendering (left to tight), which is the > >>> basic for interoperability. > >> > >> In this case, suppose N> M. Who is responsible for deciding which M > >> of the N streams will be used? AFAIK the recipient just picks the > >> ones it wants. So then my question remains - does the recipient have > >> sufficient info to select the "right" ones? (There isn't any > >> guarantee that *any* N of the M streams will provide a reasonable > rendering. > >> > >> This would be improved if we had a mechanism for the recipient to > >> state "I can only handle N streams" and the sender was obligated to > >> meet that constraint. I don't think we have said that. > >> > >>> * Transcoded conferencing, where the MCU act like an endpoint and > >>> logically announces audio and video left to right and a receiver > >>> request > >>> 1 - M captures depending on how many screen and audio streams you > >>> prefer. Typically a single video stream pr. screen and one audio > pr. > >>> screen (mono/stereo). Excluded is capabilities to select individual > >>> speakers, the MCU is free to optimize what to compose and send to a > >>> receiver. > >> > >> This is logically equivalent to the prior case. > >> > >>> * Generic multi source, sending and receiving named sources where > >>> the user experience is controlled by an human being capable of > >>> reading sources names, or control software written explicit to > >>> operate on the named streams. The content attribute can be used to > >>> indicate a > >> primary > >>> role, RFC4796 uses 'main' and 'alt'. > >> > >> Are you talking about the text names/labels we were discussing on > the > >> last call? > >> > >> If so, I agree that if the senders provide well conceived labels > then > >> a human can probably decide something reasonable. > >> > >> If the human is working only with "content" attributes, then its not > >> so clear. Its quite possible that the recipient will find itself > >> trying to choose between multiple streams with the same content > type. > >> (E.g. all > >> 'main'.) > >> > >>> I would answer no, to the following use cases > >>> * Switched conferencing, where we assume that endpoints do scalable > >>> video (either SVC or Simulcast), locally composited layout and > audio > >>> mixing. Limited work has been done on how to use Scalable video and > >>> how to build mechanisms for complete composited layouts. > >>> * Advanced audio reproduction, a group of audio scenarios mentioned > >> by > >>> Jon Leslie and Johan Nielsen that requires more details during > >> initial > >>> signalling and more dynamic information for transferring dynamic > >>> meta-information. > >>> * Multi view, as described in the CLUE use case document. > >>> > >>> (Other comments inline.) > >>> > >>> Cheers > >>> > >>> -Espen > >>> > >>> -----Original Message----- > >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >>> Of Paul Kyzivat > >>> Sent: 11. april 2012 17:06 > >>> To: John Leslie > >>> Cc: CLUE > >>> Subject: Re: [clue] Does framework provide sufficient info for > >> receiver? > >>> > >>> Hi John, > >>> > >>> Thanks for the comments. I've followed up inline. > >>> > >>> On 4/10/12 5:09 PM, John Leslie wrote: > >>>> Paul Kyzivat wrote: > >>>>> > >>>>> The fundamental problem in the scope of CLUE is, if you are an > >>>>> endpoint, and you have received an advertisement, with some > scenes > >>>>> and captures, do you have sufficient information to select and > map > >>>>> the advertised scenes/captures onto the equipment you have? > >>>> > >>>> Of course not! > >>>> > >>>> If we wanted that, we'd have to include for every composed > >> scene > >>>> what it's composed from, and for every mixed audio what it's mixed > >>>> from. > >>> > >>> I think you must have misunderstood me. Otherwise I wouldn't expect > >>> you to answer "Of course not". AFAIK the whole point of CLUE is to > >>> provide the information to make this possible. > >>> > >>> My point in asking the question was so that we can identify what > >>> information we have overlooked that we need to include one way or > >>> another. > >>> > >>> Clearly there are some tradeoffs. More information might support > >>> *better* mappings. So one thing to decide is how good is good > enough. > >>> [Espen] Agree with Paul, we clearly can support in CLUE the use > >>> cases where a Telepresence room either offer a 1, 2 or 3 video > >>> captures, which can be rendered on 1, 2 or 3 screens. > >> > >> I think its clear we can support cases where every advertisement > that > >> includes an entry for N (>1) captures also includes an entry with > >> only one capture, and optionally entries containing other numbers of > >> captures between 1 and N. > >> > >> But as I mention above, its not clear we have supported case where > >> the minimal entry in the advertisement is for N>1 captures. > >> > >>>>> If you have sufficient equipment (displays, speakers) with > >>>>> compatible > >>> > >>>>> geometry to directly map all of the captures from one audio and > >>>>> one video capture scene entry from each capture scene then maybe > >>>>> all is good. In this case ISTM that the mixed/composed attributes > >>>>> aren't needed. > >>>> > >>>> It's unlikely that the "typical" telepresence conference > will > >>>> have > >>> > >>>> a separate screen for every possible video. > >>> > >>> That isn't what I said. Consider what is perhaps a typical case, > >> where > >>> the advertisement contains one scene with several alternative video > >>> and audio scene entries. Lets just consider the video. Then maybe > >>> there is one entry with three captures, and another with one > >>> (mixed/switched, > >>> whatever) capture. Then if you have three screens you can map all > >>> three captures in the first entry. If you have less than three > >> screens > >>> then you can map the one capture from the 2nd entry onto one of > your > >> screens. > >>> > >>> But what if there was no entry with a single capture? If you had > two > >>> screens, would you have enough info about the three captures in the > >>> first entry to make a reasonable mapping onto your two screens? > What > >>> information would we need to include in the advertisement so that > it > >>> would be possible to do this mapping well? > >>> > >>> [Espen] How a vendor build a room or endpoint is transparent from > >>> the sender of media. As a sender you should not care if a room > >>> request 3 audio streams (left, center, right) and choose to mix and > >>> play out on a single speaker. We can argue that this is not the > best > >>> experience, but still valid and typically done for PC-clients or > >>> other endpoints with a single speaker. > >> > >> Again, I think you are assuming the receiver can specify the max > >> number of streams it can handle, and that the sender will then be > >> obligated to select/construct a suitable set of streams. AFAIK we > >> have not written down anything that calls for that. (If I am wrong, > >> please let me know where this is specified.) > >> > >> We have the (largely hypothetical) recipient capabilities message, > >> but its content hasn't been specified yet, and AFAIK there has been > >> no statement that it is binding and the construction of the > advertisement. > >> > >>>> Of course, the number of "capture scenes" _could_ be small > >>>> enough to give each it's own video monitor -- but I don't think > >>>> that's the general case we should design for. > >>> > >>> IIUC an endpoint will typically only advertise one or two scenes. > >>> One would correspond to the cameras and mics in its room. The > other, > >>> if present, would correspond to a "presentation" that doesn't fit > >>> into the coordinate space of the room. There are cases for more, > but > >>> they get more obscure. > >>> > >>> So for a point-to-point clue call the recipient will only need to > >>> map one or two scenes. But when there is more than one it is more > >> complex, > >>> requiring sharing of equipment. > >>> > >>> The situation is more complex for an MCU. It will have as input all > >>> the scenes offered by all the endpoints. It then has to decide what > >> to > >>> offer out to the endpoints. It could just pass through all the > >>> scenes it receives from all the endpoints, leaving the mapping > >>> problem entirely to the endpoints. (I don't think that is what most > >>> people have in mind, though some might.) > >>> > >>> Or it could take on itself the job of mapping/mixing/switching all > >>> of those inputs and producing something more like what a typical > >> endpoint > >>> would advertise - one or two scenes each with just a few captures. > >>> > >>> Or it could do both - advertise its own simplified composite scenes > >>> and also all those provided by the endpoints. That would allow the > >>> endpoints to either take the easy way out, or else do it all > >>> themselves in a way that suits them. Suppose it did this. Would the > >>> endpoints that want to take the easy way be able to figure out > which > >>> scenes and captures to use? > >>> > >>> [Espen] This sounds closer to a user experience discussions than a > >>> protocol discussion. > >> > >> Perhaps it is. But the point of CLUE is to develop a protocol that > >> enables an especially good user experience. While we shouldn't > >> mandate the user experience, I think we are obligated to do due > >> diligence that the protocol is sufficient to enable that user > experience. > >> > >>>> OTOH, with an appropriate "surround-sound" system, you can > >> "place" > >>>> an arbitrarily large number of audio streams, yet make them easy > to > >>>> distinguish. > >>>> > >>>>> If you don't have sufficient equipment to do that, then the job > is > >>>>> harder, and more information is needed to figure out what to do. > >>>> > >>>> Only marginally harder... > >>>> > >>>>> For instance: > >>>>> > >>>>> - If you don't have suitable displays, then perhaps you can > select > >> a > >>>>> video capture scene entry and locally compose or switch some of > >>>>> the captures in order to produce a set of captures that does map > >>>>> to the available displays. The area of capture of each capture > >>>>> could be helpful to doing this, and perhaps the composed > attribute as well. > >>>> > >>>> One inevitable use case is filing your formal report from > the > >>> airport. > >>>> The person doing so will have lousy audio, vastly inadequate > video, > >>>> and typically inadequate bandwidth with excessive latency. S/he > >>>> will need some middlebox to compose a "barely-adequate video" and > >>>> mono > >>> audio. > >>> > >>> This is indeed an interesting case - one we have explicitly put in > >>> scope. If an MCU is already in the call then perhaps we can hope > >>> that is one of the entries it makes available. > >>> > >>> If there isn't any MCU in the call, then the other endpoint might > >>> not advertise that option. Then what? Do we have a mechanism for > that? > >>> [Espen] If an MCU detect low bandwidth or packet loss it can start > >>> using its normal recovery mechanisms. That could lower bitrate for > >>> audio and video (maybe by a SIP re-invite), change the CLUE offer > to > >>> something that fits inside the available bandwidth. Getting good > >>> quality audio ande video is always a challenge, with or without > clue. > >>> > >>>> Then there's the use case of filing you formal report from > >>>> your home office (when you're sick or somebody doesn't want to pay > >>>> travel > >>> cost). > >>>> You may well have surround-sound and two or three large monitors, > >>>> 20 Mbps download with 40 msec RTT, and a decent-quality lavalier > mike. > >>>> You still probably want some middlebox to compose your basic > video, > >>>> but you can take individual streams as well to concentrate on > >>> particular people. > >>>> > >>>> Near the top end are the corporate telepresence rooms. They > >> will > >>>> want all streams, and are likely to have a human being mixing > them. > >>> > >>> I don't understand your point "are likely to have a human being > >> mixing > >>> them". Can you explain further? > >>> [Espen] I see this as mostly a request for focusing in on > particular > >>> user. In a transcoded conference you can do that by looking into > >> XCon, > >>> if you do switched conference the endpoint typically render the > >> layout > >>> and can choose who to focus on. Mixing transcoded and switched > >>> conferencing I think makes it unnecessary complex for the initial > >>> use cases to cover. > >>> > >>>>> - or rather than compose to fit your displays, you could > switch... > >>>> > >>>> Folks _will_ do that -- I can't stop them. But I find it > >>> uninteresting. > >>> > >>> ??? We have been talking about switching a lot. Are you saying that > >> is > >>> uninteresting? > >>> > >>> If it makes sense for a middlebox to switch, doesn't it make equal > >>> sense for an endpoint to do so? > >>> > >>>>> - handling video from multiple scenes probably presents some > added > >>>>> issues. By definition there is no specified spatial relationship > >>>>> between the captures of different scenes... > >>>> > >>>> Nonetheless, the participants will want to imagine such a > >>> relationship. > >>> > >>> ISTM that this needs further discussion. > >>> > >>>>> - If you don't have sufficient speakers for all of the audio > >>>>> captures, then you have to decide to mix, switch, or drop some. > >>>> > >>>> There really isn't any such thing as "sufficient speakers", > >>>> but surround-sound should be considered "sufficient". You can > >>>> always mix to stereo or even mono: "you pays your money and you > >>>> takes your > >>> choice". > >>> > >>> Do we have enough information to do it "right" or "well"? > >>> Right now the coordinate info is all optional. Does it need to be > >>> mandatory in order to enable this? > >>> > >>>>> The spatial information from the captures may help in deciding > how > >>>>> to > >>> > >>>>> mix. > >>>> > >>>> Absolutely! > >>>> > >>>>> Not evident that the mixed attribute helps with this > >>>> > >>>> It help you know when mixing is less likely to work well. > >>>> > >>>>> - unless it is used to decide to switch rather than mix. > >>>> > >>>> I'm not sure there is any such thing. "Mixing" frequently > >>>> includes > >>> > >>>> "riding gain" to reduce background noise. Binary switching is just > >>>> a bad idea. > >>> > >>> I have no special understanding of this. I'm just asking probing > >>> questions in hopes that it will result in the right decisions being > >>> made and the right stuff specified. > >>> > >>>>> Of course if you are mapping independent audio captures onto > >>>>> different speakers then they are being implicitly mixed. > >>>> > >>>> Not a useful way to think about it, IMHO. Human ears and > >>>> brains can sort out individual sources if there are enough > >>>> speakers, while mixing makes that harder. > >>> > >>> I have had the impression that "simple" clue telepresence rooms > >>> would be hoping to do direct mapping of captures to devices. If the > >>> assumption is that this will be an unsatisfactory approach and all > >>> endpoints should be prepared to do something more complex then it > >>> would be helpful to write that down somewhere - e.g. in the > >> framework. > >>> > >>> [Espen] Agree with Paul here, the basic scenario is well > understood. > >> A > >>> sends two logical audio captures and a receiver play them out with > >> the > >>> same spatial relationship. As rule of thumb here could be that for > >>> basic interoperability between vendors you assume pairs of audio > and > >>> video captures that can be easily rendered on matching pairs of > >>> screens and speaker. > >>> > >>>>> - If you don't have speakers with similar spatial relationship to > >>>>> those of the audio captures, then you must decide whether to do > >>>>> sub-optimal assignments or mix. > >>>> > >>>> I suppose _some_ telepresence system will hide dozens of > >>>> speakers in the telepresence room and try to do this -- to me it > >>>> sounds like a dreadful idea, but it's quite possible the people > >>>> will > >> adapt. > >>>> > >>>> "Sub-optimal" really doesn't have a clear meaning here. Even > >>>> speakers in the "wrong" left-to-right order while you can see the > >>>> "correct" order on-screen won't confuse the listener as much as > >>>> speaker assignments changing for no obvious reason. > >>>> > >>>>> Again not clear if the mixed attribute helps with this. > >>>> > >>>> As an extreme example, you could always render "mixed" in > mono. > >>>> > >>>>> - If you have audio from more than one scene, what should you do > >>>>> with > >>> > >>>>> it? Should you mix, even though you have no spatial > relationships? > >>>> > >>>> IMHO, you should _invent_ a spatial relationship in that > case. > >>>> Even if each room invents a different spatial relationship, it > will > >>>> prove less confusing. > >>>> > >>>>> Or should you switch based on active speaker? > >>>> > >>>> Only if background-noise is a serious problem. > >>>> > >>>>> What would help you to decide? > >>>> > >>>> It becomes quickly obvious to the listener! > >>>> > >>>>> The problems are superficially different for MCUs. But perhaps > >>>>> only superficially. It seems to me that when the MCU decides how > >>>>> to map its inputs into its advertisement, it has some virtual > room > >>>>> layouts > >>> in mind. > >>>> > >>>> I would expect so. > >>>> > >>>>> So for each virtual room layout it is addressing the same issues > >>>>> as a > >>> > >>>>> real endpoint with that layout. But it does have the added > problem > >>>>> of > >>> > >>>>> deciding how to describe what it is advertising - e.g. when to > >> apply > >>>>> the mixed/composed attributes. > >>>> > >>>> Pretty much always, unless it's feeding an exact copy of > what > >> it > >>>> receives. > >>> > >>> Since I've seen people here describe cases when that isn't so, it > >>> would be helpful to have a more precise definition. > >>> > >>>>> Some interesting use cases for all of the above would be very > >>> helpful. > >>>> > >>>> Did the cases I listed help? > >>> > >>> I think they need to be worked out in much more detail: > >>> > >>> - what equipment (input and output) is in each endpoint, and where. > >>> - what is advertised and how the input equipment is mapped to > >>> the advertisement > >>> - how each endpoint maps the advertised captures to its output > >> equipment > >>> together with how the info in the advertisement allowed it to > >>> determine that mapping. > >>> > >>> [Espen] Agree, being practical about what we will offer for actual > >>> endpoints are useful. > >>> > >>> > >>> Thanks, > >>> Paul > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > From ron.even.tlv@gmail.com Mon Apr 16 09:35:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A42B11E80AC for ; Mon, 16 Apr 2012 09:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HST-uA+TlkG7 for ; Mon, 16 Apr 2012 09:35:22 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB6811E8091 for ; Mon, 16 Apr 2012 09:35:21 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3710590wgb.13 for ; Mon, 16 Apr 2012 09:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=ko8lXodIJ2g+2n02An0h9yTgoj3NzbcByzYT09wu2Bo=; b=s6ZRjuxM55JK5FLekV5drFkYLIKiu1LXhOAWQyPW8+JnMF5j/rkAY1ESxvC3acvANF xofbFhvub0eR61tUI3Bsj2UeBLvulw/hWoPWs3LKanamvbfXrlaWxYcd2qbNDmjMxdGB QOicwXHDXblpFZGZm75fnQntZpjUUKrM7thHGyKQhcWc64ys/Anxtt2SMTZa1k8ynagX 4e/trXFkXBWYALr41BIuYievSjAMqgMGKR2eBST9YydMmEt/bMRIbZFGFGmL/FPGls3s ZhjPFcyqhTAukJkKtfRNEh/0QEnpdrYCdhJdbxrGflAmG9ktvCkWnFhaU/H5EsAaaIIw pqGQ== Received: by 10.216.139.194 with SMTP id c44mr7323804wej.112.1334594121149; Mon, 16 Apr 2012 09:35:21 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id ff9sm20660103wib.2.2012.04.16.09.35.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 09:35:19 -0700 (PDT) From: "Roni Even" To: "'Marshall Eubanks'" , "'clue'" References: <4F732531.2030208@ericsson.com> <4F8BDA2B.3040204@ericsson.com> In-Reply-To: Date: Mon, 16 Apr 2012 19:33:48 +0300 Message-ID: <4f8c4a47.6965b40a.6f3e.61a7@mx.google.com> 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: Ac0b4RgghMekkod5SdaVX3w3/5Xf5AADKtMQ Content-Language: en-us Subject: Re: [clue] Fwd: [rtcweb] Consensus call regarding media security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:35:23 -0000 Hi Marshall, I think that RTCweb discussed the media security and I believe that = video conferencing systems support SRTP. The question will be the keying = mechanism and currently I think that most support SDES (there was work done in = IMTC to recommend the security profile and the outcome was SDES) and later may support DTLS-SRTP.=20 Another issue will be the usage of ICE and I think it will be good for = us to look at the proposed profile in RTCweb. As for the CLUE signaling I think it should be secure, I am sure that it will not go through IESG without security.=20 Roni=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Marshall Eubanks > Sent: Monday, April 16, 2012 5:56 PM > To: clue > Subject: [clue] Fwd: [rtcweb] Consensus call regarding media security >=20 > I thought that CLUE people might be interested in this. >=20 > Encryption has not (to my knowledge) been seriously discussed in CLUE. > It is not mentioned > in the Requirements, Framework or Use Cases documents. >=20 > Now, RTCWEB has just made it mandatory (against some opposition, but > the consensus call is below). Of course, RTCWEB is not the > videoconferencing industry, and we clearly cannot mandate encryption > (as the videoconferencing industry has not). However >=20 > Some might say that encryption is at a layer below CLUE, but I = actually > think that is wrong and that we are going to have to deal with it = some. > CLUE will include metadata (such as, potentially, the participants > names) and configuration options that users will expect to have > encrypted. I would actually regard it as a security breach to say, > transport will be encrypted, but all of the host of CLUE data will > carried in the clear. >=20 > Worse, I think it is a reality that this means that encrypted RTCWEB > session will be run with unencrypted CLUE telepresence sessions, and = we > need to think about the implications of that. I also think we are > going to have to think more than we have (or, at least, than I have) > about the general security implications of the CLUE data, how to best > authenticate CLUE exchanges, and how to ensure that CLUE traffic is > protected. Questions I see arising from this include >=20 > - should CLUE traffic be protected by https / SSL ? Is that a MAY, a > SHOULD or a MUST ? > - what are the security information of the information shared by CLUE = ? > Does some of it (e.g., user names) require more protection than other > pieces. > - If a session is encrypted, is the CLUE information also required to > be encrypted ? Does that use the same security infrastructure, or a > separate one? For example, if there is encryption through a shared > secret distributed through a PKI or by some other means, does CLUE > share that secret? If the CLUE exchange goes on _before_ the PKI > exchange, using some other PKI or SSL, does it change once the shared > secret has been distributed? >=20 > I know that all of this might not be required for RTCWEB, but we might > as well start thinking about it anyway. >=20 > Regards > Marshall >=20 >=20 > ---------- Forwarded message ---------- > From: Magnus Westerlund > Date: Mon, Apr 16, 2012 at 4:36 AM > Subject: Re: [rtcweb] Consensus call regarding media security > To: rtcweb@ietf.org, EKR >=20 >=20 > WG, EKR >=20 > The deadline for this call of consensus has ended. I note that there > has been discussion of a number of details and additional views on the > actual consensus statement made. Some supporting the consensus from = the > meeting room and some opposing it. In the end I determine that the two > consensus statements are confirmed: >=20 > =A0The first was that there was overwhelming consensus that all RTP > =A0packets SHALL be protected by SRTP. >=20 > =A0Secondly that no one objected against making DTLS-SRTP a mandatory = to > =A0implement and the default keying mechanism. Additional mechanisms = are > =A0not precluded. >=20 > From the discussion in the thread I would note the following: >=20 > 1) Null cipher for encryption is strongly desired but an actual > proposal is needed for how to express this. >=20 > 2) Details of the SRTP and DTLS-SRTP usage in this WG needs to be > defined. This is for continued discussion. I hope our editor of the > security architecture can make a proposal to the WG to consider. >=20 > 3) The discussion of additional keying mechanisms such as Security > Descriptions and Encrypted Key Transport will continue. >=20 > Cheers >=20 > Magnus >=20 > On 2012-03-28 16:50, Magnus Westerlund wrote: > > WG, > > > > In todays RTCWEB WG meeting there was discussion around media > security > > mechanism. In this meeting there was some clear consensus in the > > meeting which we would like to confirm on the list. > > > > The first was that there was overwhelming consensus that all RTP > > packets SHALL be protected by SRTP. > > > > Secondly that no one objected against making DTLS-SRTP a mandatory = to > > implement and the default keying mechanism. Additional mechanisms = are > > not precluded. > > > > WG participants may state their position regarding these consensus > > calls until 12th of April when the chairs will declare the final > > consensus. If you where present in the meeting room and comment on > > this, please indicate that. > > > > Best Regards > > > > Magnus Westerlund > > For the WG chairs > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 = F=E4r=F6gatan 6 > =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From john@jlc.net Mon Apr 16 09:55:12 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E305721F86DB for ; Mon, 16 Apr 2012 09:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.774 X-Spam-Level: X-Spam-Status: No, score=-105.774 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGsyv-P730D8 for ; Mon, 16 Apr 2012 09:55:12 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E59BF21F86E4 for ; Mon, 16 Apr 2012 09:55:11 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9DD0233C22; Mon, 16 Apr 2012 12:55:11 -0400 (EDT) Date: Mon, 16 Apr 2012 12:55:11 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20120416165511.GD33066@verdi> References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8C2E0F.4070005@alum.mit.edu> User-Agent: Mutt/1.4.1i Cc: 'CLUE' Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:55:13 -0000 Paul Kyzivat wrote: > > For instance, suppose the sender does something to combine some of its > captures so that it can advertise a capture scene entry that requires > fewer displays. E.g. suppose it has three main captures of participants > and one presentation capture. And suppose in addition to advertising all > of those as one entry, it also advertises another entry for a > three-screen room, consisting of one capture for the presentation, one > for the current speaker, and one for the prior speaker. Disclaimer: I am a sound guy -- but that doesn't mean I don't pay attention to what video guys do... Current-speaker and previous-speaker are certainly useful; but when dealing with them, you actually need to know _which_ cameras are available as switched sources. (I don't especially want to re-open a question which has appeared to be settled, but I _really_ don't understand why we settled on omitting a list of sources among which we switch...) To some degree, I suppose this can be inferred; but for real conferences, some potential speakers are in one room while others are in a different room, quite likely under the management of only partly compatible software. Thus, in the ideal, we'd be able to have a screen for current speaker regardless of which room s/he is in. Previous-speaker is largely useful to allow differing decisions on _when_ to switch. In watching professionally-staged conferences panels, you'll notice that there is a delay in switching when someone else starts speaking. It _looks_ as if the camera-man is slow on the uptake, but that isn't true. The person responsible for video mixing makes the decision on when to switch, not the cameraman. And s/he integrates into the decision how likely the need to switch back may be... Thus, previous-speaker is most useful when you can use it to second- guess the switching algorithm. (In any case, audio-switching is entirely different.) > So that is one fixed and two switched captures. If the recipient needs > to map this to two displays, how does it decide what to do? I'm not sure the question makes sense. How many displays are free will change during any real conference. Often, the best solution is to leave a display empty rather than change too often. But let me take a whack at it anyway... When there is a presentation display, you almost need to have a user-activated switch to say when the presentation display is needed versus when participant display is needed. When enough displays are available, you want the speaker, the presentation, and something to gauge attendee reactions. When you're one-down on displays, some folks will want to concentrate on attendee reactions and others on the presentation materials. > The obvious thing would be to omit the capture for the prior speaker. > But how would it know which one that is. Good question!!! I had naively assumed that switching policy would be included in any advertisement of a switched source. > On 4/15/12 11:20 AM, Roni Even wrote: > >> As for multipoint use case, this is why I think it is important to >> know if the advertisement is based on site switch or segment switch >> which will provide the extra information needed for the selection >> (spatial information provides the internal relation between the >> capture) and I think that the audio level will help with knowing who >> are the active speakers in this case (As is too often the case, Roni loses me on what difference he draws between site-switched and segment-switched...) On "audio-level" I'm quite clear -- audio level should _never_ be used to second-guess a video-switching algorithm. The correlation is often very poor. As a first approximation, audio level should be considered orthogonal to any video characteristic. Automatic switching _will_ use audio-level as an input (often the primary input); but the switching-decision will be biased by things quite unrelated to audio-level, or related to essentially-invisible characteristics of audio-level history. The switching decisions themselves need to be carried in-stream: audio levels won't significantly help you reproduce them. > I think there are too many unknowns in the above to discuss it with > clarity. We need some use cases. Agreed. (But I don't want to propose any in this email.) -- John Leslie From marshall.eubanks@gmail.com Mon Apr 16 14:19:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5EC11E8091 for ; Mon, 16 Apr 2012 14:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE2ObDYmsggM for ; Mon, 16 Apr 2012 14:19:21 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7478A21F858D for ; Mon, 16 Apr 2012 14:19:21 -0700 (PDT) Received: by lagj5 with SMTP id j5so4615805lag.31 for ; Mon, 16 Apr 2012 14:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=BSCPtNhCysg2adTpgOwCmdOFO+4g3dXHYfe/CTTYN/Y=; b=0MKRzBPSvw4h9cqJ/51CiE5JC/2ZsC/Iv0HutE0lpFSxeaknLmBvhQhHddBfSFsRNA z1s+5qtYVVry1Gt48Zo6lnUoGrBB8DOi/Y0/LtkO7mTOvvMwMRabjb2nAGcCg4gKHZAU fbrAcZWw4Tyy8WqHHTCcqlBE2D0dMmL5E9bWFy8fQTYgf09iGDOQ8Msv/QTxbOu+XNCh X0xW35wiEgqI0YE/ItSrLNrZd9pMT/FzteUO31IHQgsr5duW+SbN4p9DKpuYRGc2rss2 HtkqeDLfWy86rGryr/cK0Z6Fu22eaFHdpaAemI30SjaJerM9a0I1vzKWO9Pp1KPY17T7 hPHg== MIME-Version: 1.0 Received: by 10.112.100.8 with SMTP id eu8mr6098137lbb.16.1334611160435; Mon, 16 Apr 2012 14:19:20 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Mon, 16 Apr 2012 14:19:20 -0700 (PDT) In-Reply-To: <69E0EC88-CB36-4C9C-B149-1682DEBCA6EC@cisco.com> References: <93CA273D-6111-4B2E-816F-B94EACEA0A95@cisco.com> <69E0EC88-CB36-4C9C-B149-1682DEBCA6EC@cisco.com> Date: Mon, 16 Apr 2012 17:19:20 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] Fwd: [rtcweb] Update of future interim meeting locations X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 21:19:22 -0000 More FYI ---------- Forwarded message ---------- From: Cullen Jennings Date: Mon, Apr 16, 2012 at 5:18 PM Subject: Re: [rtcweb] Update of future interim meeting locations To: Mary Barnes Cc: rtcweb@ietf.org Mary, I think you are correct that the dates being considered are Clue - June 7 and 8 WebRTC - June 11 RTCWeb - June 12 and 13 Sorry for confusion. On Apr 16, 2012, at 3:04 PM, Mary Barnes wrote: > Just one clarification - I thought the W3C WebRTC group planned to meet o= n June 11th and then the IETF RTCWEB WG on June 12-13? > > The CLUE WG meeting still plans to meet on June 7-8. > > Regards, > Mary. > > On Mon, Apr 16, 2012 at 2:45 PM, Cullen Jennings wrote= : > > The CLUE and WebRTC groups are making plans based on WebRTC meeting June = 12 and 13 in Stockholm. The chairs believe that picking a different time or= locations at this point will not be beneficial so we plan to try and confi= rm that date. > > I'd like to try and answer the question about locations of RTCWeb interim= meetings after the ones currently planned. > > First of all, the chairs would are going to declare that there is WG cons= ensus for a 1:1:1 meeting rotation between west coast of north america, eur= ope, and east coast of north america and plan to run approximately equal nu= mber of meetings in these locations. =A0In counting the number of past meet= ings in a given region, we will include all the face to face RTCWeb and Web= RTC meetings as this work is closely joined and a large number of the parti= cipants travel to both sets of meetings. The face to face meetings that hap= pen at the main IETF or W3C meetings are included in this count. Collocated= meetings will be counted just once as they only require one set of travel = to that location. > > Cullen =A0 > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From mary.ietf.barnes@gmail.com Mon Apr 16 14:36:05 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7D211E808A for ; Mon, 16 Apr 2012 14:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.61 X-Spam-Level: X-Spam-Status: No, score=-103.61 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id He5tWyzxfVid for ; Mon, 16 Apr 2012 14:36:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5A911E807F for ; Mon, 16 Apr 2012 14:36:03 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so4398398vcb.31 for ; Mon, 16 Apr 2012 14:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=GxbeHsVGrUyviiwuWXhmaiTtPKBJZF5pxDm5mUOaPz8=; b=OBIkreBEQ39jtDWV5TMGeLzIcYj6fCZo+7a1fXuZrQgxXD/XVJwF4oXrgpF+uvjIKZ OdFpY70JaQZko2ea8eU8xo5/sPzFU/SZ7M+VSNPHAv3S67mrIOfP6tpGBaOHy4nCO2Fl 1iyp5e/2HXODBQ1FEHfi9AU57MJ9nDVd6hq58tS7HNqW/IooBEb3PYgPPHC5v9bn4Uno CyhW8zdbH1v9eFOcxoRPYyUjCXxsDETg3WR+s2T+8aL3wvvpqbwq/YBCss/4AWeIpzP6 l5+Y56Xwe3v8kcUORQTTb2FiTzjPYV5780GtlrnEbouiinMa/nYL1nIOwj6f+3NpKO4B CZYA== MIME-Version: 1.0 Received: by 10.52.28.200 with SMTP id d8mr5512510vdh.38.1334612162559; Mon, 16 Apr 2012 14:36:02 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Mon, 16 Apr 2012 14:36:02 -0700 (PDT) Date: Mon, 16 Apr 2012 16:36:02 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf3079bc9edcbd9c04bdd29b63 Subject: [clue] Interim meeting (was Fwd: [rtcweb] Update of future interim meeting locations X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 21:36:05 -0000 --20cf3079bc9edcbd9c04bdd29b63 Content-Type: text/plain; charset=ISO-8859-1 So, at this point, we have not had everyone that said they could attend the CLUE meeting on June 7th/8th reply to the doodle on Location: http://www.doodle.com/wwrdycma9ymrdn3r We announced that the poll would close on Thursday, April 19th @ @ noon Pacific. As it is, it is extremely close between Boston and Stockholm. However, there are 3 good reasons to select Stockholm: 1) We've met twice in Boston 2) Logistics and costs for those attending both are significantly better (lower cost than attending the meetings at separate locations and not having to spend the weekend on airplanes) 3) Both groups can benefit from the cross pollination. There are definite overlaps in problems to be solved - Marshall has pointed out just a few in recent days. Regards, Mary. On Mon, Apr 16, 2012 at 4:19 PM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > More FYI > > > ---------- Forwarded message ---------- > From: Cullen Jennings > Date: Mon, Apr 16, 2012 at 5:18 PM > Subject: Re: [rtcweb] Update of future interim meeting locations > To: Mary Barnes > Cc: rtcweb@ietf.org > > > > Mary, I think you are correct that the dates being considered are > > Clue - June 7 and 8 > > WebRTC - June 11 > > RTCWeb - June 12 and 13 > > Sorry for confusion. > > On Apr 16, 2012, at 3:04 PM, Mary Barnes wrote: > > > Just one clarification - I thought the W3C WebRTC group planned to meet > on June 11th and then the IETF RTCWEB WG on June 12-13? > > > > The CLUE WG meeting still plans to meet on June 7-8. > > > > Regards, > > Mary. > > > > On Mon, Apr 16, 2012 at 2:45 PM, Cullen Jennings > wrote: > > > > The CLUE and WebRTC groups are making plans based on WebRTC meeting June > 12 and 13 in Stockholm. The chairs believe that picking a different time or > locations at this point will not be beneficial so we plan to try and > confirm that date. > > > > I'd like to try and answer the question about locations of RTCWeb > interim meetings after the ones currently planned. > > > > First of all, the chairs would are going to declare that there is WG > consensus for a 1:1:1 meeting rotation between west coast of north america, > europe, and east coast of north america and plan to run approximately equal > number of meetings in these locations. In counting the number of past > meetings in a given region, we will include all the face to face RTCWeb and > WebRTC meetings as this work is closely joined and a large number of the > participants travel to both sets of meetings. The face to face meetings > that happen at the main IETF or W3C meetings are included in this count. > Collocated meetings will be counted just once as they only require one set > of travel to that location. > > > > Cullen > > > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf3079bc9edcbd9c04bdd29b63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So, at this point, we have not had everyone that said they could attend the= CLUE meeting on June 7th/8th reply to the doodle on Location:
We announced that the poll would close on Thursday, April 19th @=A0@ noon Pacific.

As it is, it is extremely close between Boston and Stockholm. =A0H= owever, there are 3 good reasons to select Stockholm:
1) We've met twice in Boston
2) Logistics and costs for = those attending both are significantly better (lower cost than attending th= e meetings at separate locations and not having to spend the weekend on air= planes)
3) Both groups can benefit from the cross pollination. =A0There are de= finite overlaps in problems to be solved - Marshall has pointed out just a = few in recent days.=A0

Regards,
Mary.=A0=

On Mon, Apr 16, 2012 at 4:19 PM, Marsha= ll Eubanks <marshall.eubanks@gmail.com> wrote:
More FYI


---------- Forwarded message ----------
From: Cullen Jennings <fluffy@cisco.= com>
Date: Mon, Apr 16, 2012 at 5:18 PM
Subject: Re: [rtcweb] Update of future interim meeting locations
To: Mary Barnes <mary.ietf= .barnes@gmail.com>
Cc: rtcweb@ietf.org



Mary, I think you are correct that the dates being considered are

Clue - June 7 and 8

WebRTC - June 11

RTCWeb - June 12 and 13

Sorry for confusion.

On Apr 16, 2012, at 3:04 PM, Mary Barnes wrote:

> Just one clarification - I thought the W3C WebRTC group planned to mee= t on June 11th and then the IETF RTCWEB WG on June 12-13?
>
> The CLUE WG meeting still plans to meet on June 7-8.
>
> Regards,
> Mary.
>
> On Mon, Apr 16, 2012 at 2:45 PM, Cullen Jennings <fluffy@cisco.com> wrote:
>
> The CLUE and WebRTC groups are making plans based on WebRTC meeting Ju= ne 12 and 13 in Stockholm. The chairs believe that picking a different time= or locations at this point will not be beneficial so we plan to try and co= nfirm that date.
>
> I'd like to try and answer the question about locations of RTCWeb = interim meetings after the ones currently planned.
>
> First of all, the chairs would are going to declare that there is WG c= onsensus for a 1:1:1 meeting rotation between west coast of north america, = europe, and east coast of north america and plan to run approximately equal= number of meetings in these locations. =A0In counting the number of past m= eetings in a given region, we will include all the face to face RTCWeb and = WebRTC meetings as this work is closely joined and a large number of the pa= rticipants travel to both sets of meetings. The face to face meetings that = happen at the main IETF or W3C meetings are included in this count. Colloca= ted meetings will be counted just once as they only require one set of trav= el to that location.
>
> Cullen =A0<RTCWeb co-chair>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf3079bc9edcbd9c04bdd29b63-- From marshall.eubanks@gmail.com Mon Apr 16 14:43:08 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF76821F85D9 for ; Mon, 16 Apr 2012 14:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s35U3HDqv7B8 for ; Mon, 16 Apr 2012 14:43:08 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B29C221F858E for ; Mon, 16 Apr 2012 14:43:07 -0700 (PDT) Received: by lagj5 with SMTP id j5so4629543lag.31 for ; Mon, 16 Apr 2012 14:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xo17SHNeE/iQy7PmHpyoCbhsZnNby28BFOqzfBLCSKQ=; b=QtYmaEIU043cUnhjAmYzVb2CiPqoRS25k3T95e4UJjgBRWAmf+IittpTvGb6cEhCFX CTgRJTMWRL9MTNgNYXyNp5QLijnEB8eGHpvfLGlMRvPsKGWlJl20yDnGhefj6d9e4Xhc z+A3VViT4ZS7IwaTvWgOparzX2/9MJ2odyRT4VRVWF/VXTjHQp+dJ7HQWr4zssGDmIMn z+O69llNxHIn6WkuQuaNXyZ5u1Vrih/OYftIRZsla9wjHU2RKf+uR8J+77JJx9sbhKs/ CaRnvGe4EdByXIoZytTTa1p411NN14c3YsQU0VyeKhGzwkI3IZo50qTgd4LJ/mQxsZAz qYUw== MIME-Version: 1.0 Received: by 10.112.44.106 with SMTP id d10mr1146638lbm.30.1334612586528; Mon, 16 Apr 2012 14:43:06 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Mon, 16 Apr 2012 14:43:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Apr 2012 17:43:06 -0400 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Interim meeting (was Fwd: [rtcweb] Update of future interim meeting locations X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 21:43:08 -0000 On Mon, Apr 16, 2012 at 5:36 PM, Mary Barnes w= rote: > So, at this point, we have not had everyone that said they could attend t= he > CLUE meeting on June 7th/8th reply to the doodle on Location: > http://www.doodle.com/wwrdycma9ymrdn3r > We announced that the poll would close on Thursday, April 19th @=A0@ noon > Pacific. > > As it is, it is extremely close between Boston and Stockholm. =A0However, > there are 3 good reasons to select Stockholm: > 1) We've met twice in Boston > 2) Logistics and costs for those attending both are significantly better > (lower cost than attending the meetings at separate locations and not hav= ing > to spend the weekend on airplanes) > 3) Both groups can benefit from the cross pollination. =A0There are defin= ite > overlaps in problems to be solved - Marshall has pointed out just a few i= n > recent days. > I must admit that the notion of spending a week+ * in Stockholm to attend interims leaves me very cold. *If we start on the 7th us US attendees have to get there on the 6th which means we leave on the 5th. The return would be no earlier than the 14th. That's 8 days in Sweden and 9 days on travel. I like Sweden, but... Regards Marshall > Regards, > Mary. > > On Mon, Apr 16, 2012 at 4:19 PM, Marshall Eubanks > wrote: >> >> More FYI >> >> >> ---------- Forwarded message ---------- >> From: Cullen Jennings >> Date: Mon, Apr 16, 2012 at 5:18 PM >> Subject: Re: [rtcweb] Update of future interim meeting locations >> To: Mary Barnes >> Cc: rtcweb@ietf.org >> >> >> >> Mary, I think you are correct that the dates being considered are >> >> Clue - June 7 and 8 >> >> WebRTC - June 11 >> >> RTCWeb - June 12 and 13 >> >> Sorry for confusion. >> >> On Apr 16, 2012, at 3:04 PM, Mary Barnes wrote: >> >> > Just one clarification - I thought the W3C WebRTC group planned to mee= t >> > on June 11th and then the IETF RTCWEB WG on June 12-13? >> > >> > The CLUE WG meeting still plans to meet on June 7-8. >> > >> > Regards, >> > Mary. >> > >> > On Mon, Apr 16, 2012 at 2:45 PM, Cullen Jennings >> > wrote: >> > >> > The CLUE and WebRTC groups are making plans based on WebRTC meeting Ju= ne >> > 12 and 13 in Stockholm. The chairs believe that picking a different ti= me or >> > locations at this point will not be beneficial so we plan to try and c= onfirm >> > that date. >> > >> > I'd like to try and answer the question about locations of RTCWeb >> > interim meetings after the ones currently planned. >> > >> > First of all, the chairs would are going to declare that there is WG >> > consensus for a 1:1:1 meeting rotation between west coast of north ame= rica, >> > europe, and east coast of north america and plan to run approximately = equal >> > number of meetings in these locations. =A0In counting the number of pa= st >> > meetings in a given region, we will include all the face to face RTCWe= b and >> > WebRTC meetings as this work is closely joined and a large number of t= he >> > participants travel to both sets of meetings. The face to face meeting= s that >> > happen at the main IETF or W3C meetings are included in this count. >> > Collocated meetings will be counted just once as they only require one= set >> > of travel to that location. >> > >> > Cullen =A0 >> > >> > >> > >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> > >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From mary.ietf.barnes@gmail.com Mon Apr 16 14:58:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0CD21F8622 for ; Mon, 16 Apr 2012 14:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.609 X-Spam-Level: X-Spam-Status: No, score=-103.609 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPMN+2Qpg0Ub for ; Mon, 16 Apr 2012 14:58:15 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76D2321F8621 for ; Mon, 16 Apr 2012 14:58:15 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4384383vbb.31 for ; Mon, 16 Apr 2012 14:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EceYKHTuFh8foHk0ugMAAMYI7ccuGnOTDRcJvV4eo7s=; b=geyIpKQOB6qTtijty7Csw6uaZxlCM0Zsdl4RSNwS0JRdQxp4DYRPlOOWTZ91QVhlRz OmJ5C6DA+cLBJ28tUsjSE2GeM+KqEmUr9sfiucWXfljdXYokYmY43LlJqmek4wRwFunB XoKDLTTfeURjbddrpr8On+nxAwihMV63Adt/GFg3gNPnmWVXzf2lKxaWrW0mwbCX4JfW t5VbZwcoI1rxm2FIF/fn6X2kItpaud/f5D1kNTLxSGZvyfJCwZRSYx+iQfZ4PDY9zuKE rU9D/Ym2LmY+MJjO3AxdbLX7YrTbxIDPitbKm5oBpQjQNvlm+bjSTzO9u4CtvHFP665e 13Ig== MIME-Version: 1.0 Received: by 10.52.97.225 with SMTP id ed1mr5564005vdb.55.1334613494985; Mon, 16 Apr 2012 14:58:14 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Mon, 16 Apr 2012 14:58:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Apr 2012 16:58:14 -0500 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=20cf307ac89547f51504bdd2ebb9 Cc: CLUE Subject: Re: [clue] Interim meeting (was Fwd: [rtcweb] Update of future interim meeting locations X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 21:58:17 -0000 --20cf307ac89547f51504bdd2ebb9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 16, 2012 at 4:43 PM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > On Mon, Apr 16, 2012 at 5:36 PM, Mary Barnes > wrote: > > So, at this point, we have not had everyone that said they could attend > the > > CLUE meeting on June 7th/8th reply to the doodle on Location: > > http://www.doodle.com/wwrdycma9ymrdn3r > > We announced that the poll would close on Thursday, April 19th @ @ noon > > Pacific. > > > > As it is, it is extremely close between Boston and Stockholm. However, > > there are 3 good reasons to select Stockholm: > > 1) We've met twice in Boston > > 2) Logistics and costs for those attending both are significantly better > > (lower cost than attending the meetings at separate locations and not > having > > to spend the weekend on airplanes) > > 3) Both groups can benefit from the cross pollination. There are > definite > > overlaps in problems to be solved - Marshall has pointed out just a few > in > > recent days. > > > > I must admit that the notion of spending a week+ * in Stockholm to > attend interims leaves me very cold. > > *If we start on the 7th us US attendees have to get there on the 6th > which means we leave on the 5th. The return would be no earlier than > the 14th. That's 8 days in Sweden and 9 days on travel. I like Sweden, > but... > > Regards > Marshall > [MB] Well, if you break it into two separate meetings that still eats up the same amount of time with two more days spent on an airplane. For me to go to CLUE in Boston and then onto the other meeting in Stockholm, I would leave for CLUE on the 6th and then return home from CLUE very late on the 8th and then leave for Stockholm on the 9th and then return from Stockholm on the 14th. It would cost about $1000 more for me to fly to Stockholm from Boston rather than just going back to DFW. I would much prefer to spend my weekend in a nice city than on an airplane. The previous interim meetings (before IETF-83) were about 2 weeks apart and RTCWEB and WebRTC met for just two days combined, but CLUE was also scheduled for two full days, so I had to stayover after than meeting and fly out the next morning. So, it was still the same number of days (8) for me being away from home, including Valentine's day and my birthday. Mary. [/MB] > > > Regards, > > Mary. > > > > On Mon, Apr 16, 2012 at 4:19 PM, Marshall Eubanks > > wrote: > >> > >> More FYI > >> > >> > >> ---------- Forwarded message ---------- > >> From: Cullen Jennings > >> Date: Mon, Apr 16, 2012 at 5:18 PM > >> Subject: Re: [rtcweb] Update of future interim meeting locations > >> To: Mary Barnes > >> Cc: rtcweb@ietf.org > >> > >> > >> > >> Mary, I think you are correct that the dates being considered are > >> > >> Clue - June 7 and 8 > >> > >> WebRTC - June 11 > >> > >> RTCWeb - June 12 and 13 > >> > >> Sorry for confusion. > >> > >> On Apr 16, 2012, at 3:04 PM, Mary Barnes wrote: > >> > >> > Just one clarification - I thought the W3C WebRTC group planned to > meet > >> > on June 11th and then the IETF RTCWEB WG on June 12-13? > >> > > >> > The CLUE WG meeting still plans to meet on June 7-8. > >> > > >> > Regards, > >> > Mary. > >> > > >> > On Mon, Apr 16, 2012 at 2:45 PM, Cullen Jennings > >> > wrote: > >> > > >> > The CLUE and WebRTC groups are making plans based on WebRTC meeting > June > >> > 12 and 13 in Stockholm. The chairs believe that picking a different > time or > >> > locations at this point will not be beneficial so we plan to try and > confirm > >> > that date. > >> > > >> > I'd like to try and answer the question about locations of RTCWeb > >> > interim meetings after the ones currently planned. > >> > > >> > First of all, the chairs would are going to declare that there is WG > >> > consensus for a 1:1:1 meeting rotation between west coast of north > america, > >> > europe, and east coast of north america and plan to run approximately > equal > >> > number of meetings in these locations. In counting the number of past > >> > meetings in a given region, we will include all the face to face > RTCWeb and > >> > WebRTC meetings as this work is closely joined and a large number of > the > >> > participants travel to both sets of meetings. The face to face > meetings that > >> > happen at the main IETF or W3C meetings are included in this count. > >> > Collocated meetings will be counted just once as they only require > one set > >> > of travel to that location. > >> > > >> > Cullen > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > rtcweb mailing list > >> > rtcweb@ietf.org > >> > https://www.ietf.org/mailman/listinfo/rtcweb > >> > > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > > --20cf307ac89547f51504bdd2ebb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 16, 2012 at 4:43 PM, Marshal= l Eubanks <marshall.eubanks@gmail.com> wrote:
On Mon, Apr 16, 2012 at 5:36 PM, Mary Barnes <mary.ietf.barnes@gmail.com> w= rote:
> So, at this point, we have not had everyone that said they could atten= d the
> CLUE meeting on June 7th/8th reply to the doodle on Location:
> h= ttp://www.doodle.com/wwrdycma9ymrdn3r
> We announced that the poll would close on Thursday, April 19th @=A0@ n= oon
> Pacific.
>
> As it is, it is extremely close between Boston and Stockholm. =A0Howev= er,
> there are 3 good reasons to select Stockholm:
> 1) We've met twice in Boston
> 2) Logistics and costs for those attending both are significantly bett= er
> (lower cost than attending the meetings at separate locations and not = having
> to spend the weekend on airplanes)
> 3) Both groups can benefit from the cross pollination. =A0There are de= finite
> overlaps in problems to be solved - Marshall has pointed out just a fe= w in
> recent days.
>

I must admit that the notion of spending a week+ * in Stockholm to attend interims leaves me very cold.

*If we start on the 7th us US attendees have to get there on the 6th
which means we leave on the 5th. The return would be no earlier than
the 14th. That's 8 days in Sweden and 9 days on travel. I like Sweden,<= br> but...

Regards
Marshall
[MB] Well, if you break it into two separate meetings that = still eats up the same amount of time with two more days spent on an airpla= ne. =A0For me to go to CLUE in Boston and then onto the other meeting in St= ockholm, I would leave for CLUE on the 6th and then return home from CLUE v= ery late on the 8th and then leave for Stockholm on the 9th and then return= from Stockholm on the 14th. =A0It would cost about $1000 more for me to fl= y to Stockholm from Boston rather than just going back to DFW. =A0 I would = much prefer to spend my weekend in a nice city than on an airplane. =A0

The previous interim meetings (before IETF-83) were abo= ut 2 weeks apart and RTCWEB and WebRTC met for just two days combined, but = CLUE was also scheduled for two full days, so I had to stayover after than = meeting and fly out the next morning. So, it was still the same number of d= ays (8) for me being away from home, including Valentine's day and my b= irthday.=A0

Mary.=A0
[/MB]
=A0

> Regards,
> Mary.
>
> On Mon, Apr 16, 2012 at 4:19 PM, Marshall Eubanks
> <marshall.eubanks@gma= il.com> wrote:
>>
>> More FYI
>>
>>
>> ---------- Forwarded message ----------
>> From: Cullen Jennings <fluf= fy@cisco.com>
>> Date: Mon, Apr 16, 2012 at 5:18 PM
>> Subject: Re: [rtcweb] Update of future interim meeting locations >> To: Mary Barnes <= mary.ietf.barnes@gmail.com>
>> Cc: rtcweb@ietf.org
>>
>>
>>
>> Mary, I think you are correct that the dates being considered are<= br> >>
>> Clue - June 7 and 8
>>
>> WebRTC - June 11
>>
>> RTCWeb - June 12 and 13
>>
>> Sorry for confusion.
>>
>> On Apr 16, 2012, at 3:04 PM, Mary Barnes wrote:
>>
>> > Just one clarification - I thought the W3C WebRTC group plann= ed to meet
>> > on June 11th and then the IETF RTCWEB WG on June 12-13?
>> >
>> > The CLUE WG meeting still plans to meet on June 7-8.
>> >
>> > Regards,
>> > Mary.
>> >
>> > On Mon, Apr 16, 2012 at 2:45 PM, Cullen Jennings <fluffy@cisco.com>
>> > wrote:
>> >
>> > The CLUE and WebRTC groups are making plans based on WebRTC m= eeting June
>> > 12 and 13 in Stockholm. The chairs believe that picking a dif= ferent time or
>> > locations at this point will not be beneficial so we plan to = try and confirm
>> > that date.
>> >
>> > I'd like to try and answer the question about locations o= f RTCWeb
>> > interim meetings after the ones currently planned.
>> >
>> > First of all, the chairs would are going to declare that ther= e is WG
>> > consensus for a 1:1:1 meeting rotation between west coast of = north america,
>> > europe, and east coast of north america and plan to run appro= ximately equal
>> > number of meetings in these locations. =A0In counting the num= ber of past
>> > meetings in a given region, we will include all the face to f= ace RTCWeb and
>> > WebRTC meetings as this work is closely joined and a large nu= mber of the
>> > participants travel to both sets of meetings. The face to fac= e meetings that
>> > happen at the main IETF or W3C meetings are included in this = count.
>> > Collocated meetings will be counted just once as they only re= quire one set
>> > of travel to that location.
>> >
>> > Cullen =A0<RTCWeb co-chair>
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>
>

--20cf307ac89547f51504bdd2ebb9-- From espeberg@cisco.com Mon Apr 16 15:16:34 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6CE11E80E5 for ; Mon, 16 Apr 2012 15:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRoGG3EKoUT6 for ; Mon, 16 Apr 2012 15:16:34 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5575C11E80D1 for ; Mon, 16 Apr 2012 15:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=5713; q=dns/txt; s=iport; t=1334614593; x=1335824193; h=from:message-id:content-transfer-encoding:to:cc:subject: mime-version:date; bh=Y/NeBS2YdUCt56P1xpniRawbWpQj4hzT8ePNUpKAo10=; b=knnOOmCkVjRIYsrK042Np3PnacU68pN32Pu/lhfKVEkB+3NrbNh81IHy o004ycWw4DAMLIGWzQpkTQfTj7y/fCMntz7zVUCjsVjhwdnr4ZWkbNeJn X6Wncl4oohAS1UNcgdQSaqd1NhKA45LSsNSjl2lIsF/XJtz1HCQ90XxT5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8IAFyZjE+Q/khN/2dsb2JhbABEhWaENqhkAoEHggkBAQEDAQEBAQ8BEEYBBAsFDQEIEQMBAgECAgwYAgIDIAYoCQEEARIih14DBgULmViNEIh1DYlTgS+JCIV6gRgElW2LOIMUgWmCaQ X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="71011827" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 16 Apr 2012 22:16:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3GMGWPg009478; Mon, 16 Apr 2012 22:16:32 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Apr 2012 00:16:32 +0200 Received: from 72.163.62.205 ([72.163.62.205]) by XMB-AMS-214.cisco.com ([144.254.75.25]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 Apr 2012 22:16:31 +0000 From: "Espen Berger (espeberg)" Message-ID: <134801cd1c1e$93ba9d82$cd3ea348@cisco.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: , "Marshall Eubanks" X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [clue] Interim meeting (was Fwd: [rtcweb] Update of future interim meeting locations Thread-Index: Ac0cHpO6OHMdjRvvTEGOdNUgKkthrw== Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2012 22:16:32.0411 (UTC) FILETIME=[942BD6B0:01CD1C1E] Date: 17 Apr 2012 00:16:32 +0200 Cc: CLUE Subject: Re: [clue] Interim meeting (was Fwd: [rtcweb] Update of future interim meeting locations X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 22:16:35 -0000 Stockholm in june is a great experience :) =0A= =0A= -Espen=0A= =0A= ----- Reply message -----=0A= Fra: "Mary Barnes" =0A= Til: "Marshall Eubanks" =0A= Kopi: "CLUE" =0A= Emne: [clue] Interim meeting (was Fwd: [rtcweb] Update of future interim = meeting locations=0A= Dato: man., apr. 16, 2012 23:58=0A= =0A= =0A= =0A= On Mon, Apr 16, 2012 at 4:43 PM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > On Mon, Apr 16, 2012 at 5:36 PM, Mary Barnes = > wrote: > > So, at this point, we have not had everyone that said they could = attend > the > > CLUE meeting on June 7th/8th reply to the doodle on Location: > > http://www.doodle.com/wwrdycma9ymrdn3r > > We announced that the poll would close on Thursday, April 19th @ @ = noon > > Pacific. > > > > As it is, it is extremely close between Boston and Stockholm. = However, > > there are 3 good reasons to select Stockholm: > > 1) We've met twice in Boston > > 2) Logistics and costs for those attending both are significantly = better > > (lower cost than attending the meetings at separate locations and = not > having > > to spend the weekend on airplanes) > > 3) Both groups can benefit from the cross pollination. There are > definite > > overlaps in problems to be solved - Marshall has pointed out just a = few > in > > recent days. > > > > I must admit that the notion of spending a week+ * in Stockholm to > attend interims leaves me very cold. > > *If we start on the 7th us US attendees have to get there on the 6th > which means we leave on the 5th. The return would be no earlier than > the 14th. That's 8 days in Sweden and 9 days on travel. I like Sweden, > but... > > Regards > Marshall > [MB] Well, if you break it into two separate meetings that still eats up the same amount of time with two more days spent on an airplane. For me = to go to CLUE in Boston and then onto the other meeting in Stockholm, I = would leave for CLUE on the 6th and then return home from CLUE very late on = the 8th and then leave for Stockholm on the 9th and then return from = Stockholm on the 14th. It would cost about $1000 more for me to fly to Stockholm from Boston rather than just going back to DFW. I would much prefer to spend my weekend in a nice city than on an airplane. The previous interim meetings (before IETF-83) were about 2 weeks apart = and RTCWEB and WebRTC met for just two days combined, but CLUE was also scheduled for two full days, so I had to stayover after than meeting and fly out the next morning. So, it was still the same number of days (8) = for me being away from home, including Valentine's day and my birthday. Mary. [/MB] > > > Regards, > > Mary. > > > > On Mon, Apr 16, 2012 at 4:19 PM, Marshall Eubanks > > wrote: > >> > >> More FYI > >> > >> > >> ---------- Forwarded message ---------- > >> From: Cullen Jennings > >> Date: Mon, Apr 16, 2012 at 5:18 PM > >> Subject: Re: [rtcweb] Update of future interim meeting locations > >> To: Mary Barnes > >> Cc: rtcweb@ietf.org > >> > >> > >> > >> Mary, I think you are correct that the dates being considered are > >> > >> Clue - June 7 and 8 > >> > >> WebRTC - June 11 > >> > >> RTCWeb - June 12 and 13 > >> > >> Sorry for confusion. > >> > >> On Apr 16, 2012, at 3:04 PM, Mary Barnes wrote: > >> > >> > Just one clarification - I thought the W3C WebRTC group planned = to > meet > >> > on June 11th and then the IETF RTCWEB WG on June 12-13? > >> > > >> > The CLUE WG meeting still plans to meet on June 7-8. > >> > > >> > Regards, > >> > Mary. > >> > > >> > On Mon, Apr 16, 2012 at 2:45 PM, Cullen Jennings = > >> > wrote: > >> > > >> > The CLUE and WebRTC groups are making plans based on WebRTC = meeting > June > >> > 12 and 13 in Stockholm. The chairs believe that picking a = different > time or > >> > locations at this point will not be beneficial so we plan to try = and > confirm > >> > that date. > >> > > >> > I'd like to try and answer the question about locations of RTCWeb > >> > interim meetings after the ones currently planned. > >> > > >> > First of all, the chairs would are going to declare that there is = WG > >> > consensus for a 1:1:1 meeting rotation between west coast of = north > america, > >> > europe, and east coast of north america and plan to run = approximately > equal > >> > number of meetings in these locations. In counting the number of = past > >> > meetings in a given region, we will include all the face to face > RTCWeb and > >> > WebRTC meetings as this work is closely joined and a large number = of > the > >> > participants travel to both sets of meetings. The face to face > meetings that > >> > happen at the main IETF or W3C meetings are included in this = count. > >> > Collocated meetings will be counted just once as they only = require > one set > >> > of travel to that location. > >> > > >> > Cullen > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > rtcweb mailing list > >> > rtcweb@ietf.org > >> > https://www.ietf.org/mailman/listinfo/rtcweb > >> > > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > > From bbaldino@cisco.com Mon Apr 16 16:19:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE9B21F853C for ; Mon, 16 Apr 2012 16:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B3wXQyIMkZs for ; Mon, 16 Apr 2012 16:19:24 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A2F4A21F8539 for ; Mon, 16 Apr 2012 16:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=24388; q=dns/txt; s=iport; t=1334618364; x=1335827964; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=FYt1yFF0fdA/hJub2maNK81a0bzV48LTpUKHz7rLcHg=; b=MfgjJqHvWOAK9BX3cke+5bJHyLGR/4kHSJxDe8bgdywQusyVcCeC6wS5 8nSAUBGDDua/jFVxhBZzy9TAkDJOv0V/WkX2GlRDieJkYG62zGHyIY9dM E2B1uaPKM8mpZJ2N2C3UgFaP6yAhxRCrYNEoWuH1XADA0Ko8erRC+hY+I Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAN+njE+rRDoG/2dsb2JhbAA6Cg6ydIEHggkBAQEDAQEBAQ8BBxYKLgQCBAQDBQcEAgEIDgMEAQEBCgYXAQYBJh8JCAEBBAEJCQgah2cEAQuZVZ9rBIsuBIU0YwSIWoktkjKBaYIwV4E0 X-IronPort-AV: E=Sophos;i="4.75,430,1330905600"; d="scan'208";a="40738017" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 16 Apr 2012 23:19:24 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3GNJNCS002736; Mon, 16 Apr 2012 23:19:24 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 16:19:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Apr 2012 16:19:22 -0700 Message-ID: In-Reply-To: <4F8C2E0F.4070005@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Does framework provide sufficient info for receiver? Thread-Index: Ac0b3h33jHHCHBWnRma9BZYX5Y4QRgARLyAw References: <4F846AE0.4010700@alum.mit.edu><20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com><4F873CCE.3020806@alum.mit.edu><4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> From: "Brian Baldino (bbaldino)" To: "Paul Kyzivat" , "Roni Even" X-OriginalArrivalTime: 16 Apr 2012 23:19:22.0853 (UTC) FILETIME=[5B87A150:01CD1C27] Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 23:19:26 -0000 Hey Paul, with regards to this bit: "For instance, suppose the sender does something to combine some of its captures so that it can advertise a capture scene entry that requires fewer displays. E.g. suppose it has three main captures of participants and one presentation capture. And suppose in addition to advertising all of those as one entry, it also advertises another entry for a three-screen room, consisting of one capture for the presentation, one for the current speaker, and one for the prior speaker. So that is one fixed and two switched captures. If the recipient need to map this to two displays, how does it decide what to do? The obvious thing would be to omit the capture for the prior speaker. But how would it know which one that is." My understanding was more that the provider would advertise all valid views with a capture entry for each, not require (or rely on) an endpoint to be able to "find" a valid view which is a subset of one that was actually advertised; therefore relieving the consumer of that responsibility. So in this case, the provider would advertise entries that contained: 1) Just the active speaker=20 2) The active speaker and previous active speaker 3) The active speaker, previous active speaker and presentation (Maybe even a 4th that contained the active speaker and presentation) The idea being that the provider is smart enough to know/advertise its valid views rather than rely on the consumer to figure them out. =20 Even with this there are still situations where no advertised view is ideal for the consumer, maybe this is the situation you're referring to? I'd hoped that the consumer could get away with choosing the "next best fit" using information already in the advertisement (how many captures an entry consists of, switched vs. non-switched, area of capture info, etc.) -Brian =20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, April 16, 2012 7:35 AM To: Roni Even Cc: 'CLUE' Subject: Re: [clue] Does framework provide sufficient info for receiver? Hi Roni, On 4/15/12 11:20 AM, Roni Even wrote: > Hi Paul, > I think that there is enough information that will allow a receiver to > select N out of M streams. > The receiver will know the semantics of the streams (people or=20 > presentation) and the spatial information of the room and the different streams. > My view is that this is enough for the general telepresence point to=20 > point use case. I think I agree for the case where there is a single scene advertised, and all the captures represent single cameras. But as soon as you add in mixed or switched captures it becomes far less clear. For instance, suppose the sender does something to combine some of its captures so that it can advertise a capture scene entry that requires fewer displays. E.g. suppose it has three main captures of participants and one presentation capture. And suppose in addition to advertising all of those as one entry, it also advertises another entry for a three-screen room, consisting of one capture for the presentation, one for the current speaker, and one for the prior speaker. So that is one fixed and two switched captures. If the recipient need to map this to two displays, how does it decide what to do? The obvious thing would be to omit the capture for the prior speaker. But how would it know which one that is. > As for multipoint use case, this is why I think it is important to=20 > know if the advertisement is based on site switch or segment switch=20 > which will provide the extra information needed for the selection=20 > (spatial information provides the internal relation between the=20 > capture) and I think that the audio level will help with knowing who=20 > are the active speakers in this case I think there are too many unknowns in the above to discuss it with clarity. We need some use cases. Thanks, Paul > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 >> Of Paul Kyzivat >> Sent: Thursday, April 12, 2012 11:37 PM >> To: Espen Berger (espeberg) >> Cc: CLUE >> Subject: Re: [clue] Does framework provide sufficient info for=20 >> receiver? >> >> Espen - comments inline. >> >> Thanks, >> Paul >> >> On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: >>> During the CLUE design team meeting on webex yesterday we started to >>> discuss various use cases and if they are in scope or not for the=20 >>> current work in CLUE. >>> >>> As a part of my response to Pauls questions I summarized the use >> cases >>> and grouped them into supported / not supported. I can dive into=20 >>> more detail about the use cases if people are interested? >>> >>> I would answer yes to the following use cases >>> * Telepresence point to point, where the reproduction will happen in >> a >>> 2D-plane for audio and video. Currently CLUE support announcing=20 >>> capability of sending 1 - N capture (left to right) and a receiver >> can >>> request 1 - M streams for rendering (left to tight), which is the=20 >>> basic for interoperability. >> >> In this case, suppose N> M. Who is responsible for deciding which M=20 >> of the N streams will be used? AFAIK the recipient just picks the=20 >> ones it wants. So then my question remains - does the recipient have=20 >> sufficient info to select the "right" ones? (There isn't any=20 >> guarantee that *any* N of the M streams will provide a reasonable rendering. >> >> This would be improved if we had a mechanism for the recipient to=20 >> state "I can only handle N streams" and the sender was obligated to=20 >> meet that constraint. I don't think we have said that. >> >>> * Transcoded conferencing, where the MCU act like an endpoint and=20 >>> logically announces audio and video left to right and a receiver=20 >>> request >>> 1 - M captures depending on how many screen and audio streams you=20 >>> prefer. Typically a single video stream pr. screen and one audio pr. >>> screen (mono/stereo). Excluded is capabilities to select individual=20 >>> speakers, the MCU is free to optimize what to compose and send to a=20 >>> receiver. >> >> This is logically equivalent to the prior case. >> >>> * Generic multi source, sending and receiving named sources where=20 >>> the user experience is controlled by an human being capable of=20 >>> reading sources names, or control software written explicit to=20 >>> operate on the named streams. The content attribute can be used to=20 >>> indicate a >> primary >>> role, RFC4796 uses 'main' and 'alt'. >> >> Are you talking about the text names/labels we were discussing on the >> last call? >> >> If so, I agree that if the senders provide well conceived labels then >> a human can probably decide something reasonable. >> >> If the human is working only with "content" attributes, then its not=20 >> so clear. Its quite possible that the recipient will find itself=20 >> trying to choose between multiple streams with the same content type. >> (E.g. all >> 'main'.) >> >>> I would answer no, to the following use cases >>> * Switched conferencing, where we assume that endpoints do scalable=20 >>> video (either SVC or Simulcast), locally composited layout and audio >>> mixing. Limited work has been done on how to use Scalable video and=20 >>> how to build mechanisms for complete composited layouts. >>> * Advanced audio reproduction, a group of audio scenarios mentioned >> by >>> Jon Leslie and Johan Nielsen that requires more details during >> initial >>> signalling and more dynamic information for transferring dynamic=20 >>> meta-information. >>> * Multi view, as described in the CLUE use case document. >>> >>> (Other comments inline.) >>> >>> Cheers >>> >>> -Espen >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: 11. april 2012 17:06 >>> To: John Leslie >>> Cc: CLUE >>> Subject: Re: [clue] Does framework provide sufficient info for >> receiver? >>> >>> Hi John, >>> >>> Thanks for the comments. I've followed up inline. >>> >>> On 4/10/12 5:09 PM, John Leslie wrote: >>>> Paul Kyzivat wrote: >>>>> >>>>> The fundamental problem in the scope of CLUE is, if you are an=20 >>>>> endpoint, and you have received an advertisement, with some scenes >>>>> and captures, do you have sufficient information to select and map >>>>> the advertised scenes/captures onto the equipment you have? >>>> >>>> Of course not! >>>> >>>> If we wanted that, we'd have to include for every composed >> scene >>>> what it's composed from, and for every mixed audio what it's mixed=20 >>>> from. >>> >>> I think you must have misunderstood me. Otherwise I wouldn't expect=20 >>> you to answer "Of course not". AFAIK the whole point of CLUE is to=20 >>> provide the information to make this possible. >>> >>> My point in asking the question was so that we can identify what=20 >>> information we have overlooked that we need to include one way or=20 >>> another. >>> >>> Clearly there are some tradeoffs. More information might support >>> *better* mappings. So one thing to decide is how good is good enough. >>> [Espen] Agree with Paul, we clearly can support in CLUE the use=20 >>> cases where a Telepresence room either offer a 1, 2 or 3 video=20 >>> captures, which can be rendered on 1, 2 or 3 screens. >> >> I think its clear we can support cases where every advertisement that >> includes an entry for N (>1) captures also includes an entry with=20 >> only one capture, and optionally entries containing other numbers of=20 >> captures between 1 and N. >> >> But as I mention above, its not clear we have supported case where=20 >> the minimal entry in the advertisement is for N>1 captures. >> >>>>> If you have sufficient equipment (displays, speakers) with=20 >>>>> compatible >>> >>>>> geometry to directly map all of the captures from one audio and=20 >>>>> one video capture scene entry from each capture scene then maybe=20 >>>>> all is good. In this case ISTM that the mixed/composed attributes=20 >>>>> aren't needed. >>>> >>>> It's unlikely that the "typical" telepresence conference will >>>> have >>> >>>> a separate screen for every possible video. >>> >>> That isn't what I said. Consider what is perhaps a typical case, >> where >>> the advertisement contains one scene with several alternative video=20 >>> and audio scene entries. Lets just consider the video. Then maybe=20 >>> there is one entry with three captures, and another with one=20 >>> (mixed/switched, >>> whatever) capture. Then if you have three screens you can map all=20 >>> three captures in the first entry. If you have less than three >> screens >>> then you can map the one capture from the 2nd entry onto one of your >> screens. >>> >>> But what if there was no entry with a single capture? If you had two >>> screens, would you have enough info about the three captures in the=20 >>> first entry to make a reasonable mapping onto your two screens? What >>> information would we need to include in the advertisement so that it >>> would be possible to do this mapping well? >>> >>> [Espen] How a vendor build a room or endpoint is transparent from=20 >>> the sender of media. As a sender you should not care if a room=20 >>> request 3 audio streams (left, center, right) and choose to mix and=20 >>> play out on a single speaker. We can argue that this is not the best >>> experience, but still valid and typically done for PC-clients or=20 >>> other endpoints with a single speaker. >> >> Again, I think you are assuming the receiver can specify the max=20 >> number of streams it can handle, and that the sender will then be=20 >> obligated to select/construct a suitable set of streams. AFAIK we=20 >> have not written down anything that calls for that. (If I am wrong,=20 >> please let me know where this is specified.) >> >> We have the (largely hypothetical) recipient capabilities message,=20 >> but its content hasn't been specified yet, and AFAIK there has been=20 >> no statement that it is binding and the construction of the advertisement. >> >>>> Of course, the number of "capture scenes" _could_ be small=20 >>>> enough to give each it's own video monitor -- but I don't think=20 >>>> that's the general case we should design for. >>> >>> IIUC an endpoint will typically only advertise one or two scenes.=20 >>> One would correspond to the cameras and mics in its room. The other, >>> if present, would correspond to a "presentation" that doesn't fit=20 >>> into the coordinate space of the room. There are cases for more, but >>> they get more obscure. >>> >>> So for a point-to-point clue call the recipient will only need to=20 >>> map one or two scenes. But when there is more than one it is more >> complex, >>> requiring sharing of equipment. >>> >>> The situation is more complex for an MCU. It will have as input all=20 >>> the scenes offered by all the endpoints. It then has to decide what >> to >>> offer out to the endpoints. It could just pass through all the=20 >>> scenes it receives from all the endpoints, leaving the mapping=20 >>> problem entirely to the endpoints. (I don't think that is what most=20 >>> people have in mind, though some might.) >>> >>> Or it could take on itself the job of mapping/mixing/switching all=20 >>> of those inputs and producing something more like what a typical >> endpoint >>> would advertise - one or two scenes each with just a few captures. >>> >>> Or it could do both - advertise its own simplified composite scenes=20 >>> and also all those provided by the endpoints. That would allow the=20 >>> endpoints to either take the easy way out, or else do it all=20 >>> themselves in a way that suits them. Suppose it did this. Would the=20 >>> endpoints that want to take the easy way be able to figure out which >>> scenes and captures to use? >>> >>> [Espen] This sounds closer to a user experience discussions than a=20 >>> protocol discussion. >> >> Perhaps it is. But the point of CLUE is to develop a protocol that=20 >> enables an especially good user experience. While we shouldn't=20 >> mandate the user experience, I think we are obligated to do due=20 >> diligence that the protocol is sufficient to enable that user experience. >> >>>> OTOH, with an appropriate "surround-sound" system, you can >> "place" >>>> an arbitrarily large number of audio streams, yet make them easy to >>>> distinguish. >>>> >>>>> If you don't have sufficient equipment to do that, then the job is >>>>> harder, and more information is needed to figure out what to do. >>>> >>>> Only marginally harder... >>>> >>>>> For instance: >>>>> >>>>> - If you don't have suitable displays, then perhaps you can select >> a >>>>> video capture scene entry and locally compose or switch some of=20 >>>>> the captures in order to produce a set of captures that does map=20 >>>>> to the available displays. The area of capture of each capture=20 >>>>> could be helpful to doing this, and perhaps the composed attribute as well. >>>> >>>> One inevitable use case is filing your formal report from the >>> airport. >>>> The person doing so will have lousy audio, vastly inadequate video, >>>> and typically inadequate bandwidth with excessive latency. S/he=20 >>>> will need some middlebox to compose a "barely-adequate video" and=20 >>>> mono >>> audio. >>> >>> This is indeed an interesting case - one we have explicitly put in=20 >>> scope. If an MCU is already in the call then perhaps we can hope=20 >>> that is one of the entries it makes available. >>> >>> If there isn't any MCU in the call, then the other endpoint might=20 >>> not advertise that option. Then what? Do we have a mechanism for that? >>> [Espen] If an MCU detect low bandwidth or packet loss it can start=20 >>> using its normal recovery mechanisms. That could lower bitrate for=20 >>> audio and video (maybe by a SIP re-invite), change the CLUE offer to >>> something that fits inside the available bandwidth. Getting good=20 >>> quality audio ande video is always a challenge, with or without clue. >>> >>>> Then there's the use case of filing you formal report from=20 >>>> your home office (when you're sick or somebody doesn't want to pay=20 >>>> travel >>> cost). >>>> You may well have surround-sound and two or three large monitors,=20 >>>> 20 Mbps download with 40 msec RTT, and a decent-quality lavalier mike. >>>> You still probably want some middlebox to compose your basic video, >>>> but you can take individual streams as well to concentrate on >>> particular people. >>>> >>>> Near the top end are the corporate telepresence rooms. They >> will >>>> want all streams, and are likely to have a human being mixing them. >>> >>> I don't understand your point "are likely to have a human being >> mixing >>> them". Can you explain further? >>> [Espen] I see this as mostly a request for focusing in on particular >>> user. In a transcoded conference you can do that by looking into >> XCon, >>> if you do switched conference the endpoint typically render the >> layout >>> and can choose who to focus on. Mixing transcoded and switched=20 >>> conferencing I think makes it unnecessary complex for the initial=20 >>> use cases to cover. >>> >>>>> - or rather than compose to fit your displays, you could switch... >>>> >>>> Folks _will_ do that -- I can't stop them. But I find it >>> uninteresting. >>> >>> ??? We have been talking about switching a lot. Are you saying that >> is >>> uninteresting? >>> >>> If it makes sense for a middlebox to switch, doesn't it make equal=20 >>> sense for an endpoint to do so? >>> >>>>> - handling video from multiple scenes probably presents some added >>>>> issues. By definition there is no specified spatial relationship=20 >>>>> between the captures of different scenes... >>>> >>>> Nonetheless, the participants will want to imagine such a >>> relationship. >>> >>> ISTM that this needs further discussion. >>> >>>>> - If you don't have sufficient speakers for all of the audio=20 >>>>> captures, then you have to decide to mix, switch, or drop some. >>>> >>>> There really isn't any such thing as "sufficient speakers",=20 >>>> but surround-sound should be considered "sufficient". You can=20 >>>> always mix to stereo or even mono: "you pays your money and you=20 >>>> takes your >>> choice". >>> >>> Do we have enough information to do it "right" or "well"? >>> Right now the coordinate info is all optional. Does it need to be=20 >>> mandatory in order to enable this? >>> >>>>> The spatial information from the captures may help in deciding how >>>>> to >>> >>>>> mix. >>>> >>>> Absolutely! >>>> >>>>> Not evident that the mixed attribute helps with this >>>> >>>> It help you know when mixing is less likely to work well. >>>> >>>>> - unless it is used to decide to switch rather than mix. >>>> >>>> I'm not sure there is any such thing. "Mixing" frequently=20 >>>> includes >>> >>>> "riding gain" to reduce background noise. Binary switching is just=20 >>>> a bad idea. >>> >>> I have no special understanding of this. I'm just asking probing=20 >>> questions in hopes that it will result in the right decisions being=20 >>> made and the right stuff specified. >>> >>>>> Of course if you are mapping independent audio captures onto=20 >>>>> different speakers then they are being implicitly mixed. >>>> >>>> Not a useful way to think about it, IMHO. Human ears and=20 >>>> brains can sort out individual sources if there are enough=20 >>>> speakers, while mixing makes that harder. >>> >>> I have had the impression that "simple" clue telepresence rooms=20 >>> would be hoping to do direct mapping of captures to devices. If the=20 >>> assumption is that this will be an unsatisfactory approach and all=20 >>> endpoints should be prepared to do something more complex then it=20 >>> would be helpful to write that down somewhere - e.g. in the >> framework. >>> >>> [Espen] Agree with Paul here, the basic scenario is well understood. >> A >>> sends two logical audio captures and a receiver play them out with >> the >>> same spatial relationship. As rule of thumb here could be that for=20 >>> basic interoperability between vendors you assume pairs of audio and >>> video captures that can be easily rendered on matching pairs of=20 >>> screens and speaker. >>> >>>>> - If you don't have speakers with similar spatial relationship to=20 >>>>> those of the audio captures, then you must decide whether to do=20 >>>>> sub-optimal assignments or mix. >>>> >>>> I suppose _some_ telepresence system will hide dozens of=20 >>>> speakers in the telepresence room and try to do this -- to me it=20 >>>> sounds like a dreadful idea, but it's quite possible the people=20 >>>> will >> adapt. >>>> >>>> "Sub-optimal" really doesn't have a clear meaning here. Even=20 >>>> speakers in the "wrong" left-to-right order while you can see the=20 >>>> "correct" order on-screen won't confuse the listener as much as=20 >>>> speaker assignments changing for no obvious reason. >>>> >>>>> Again not clear if the mixed attribute helps with this. >>>> >>>> As an extreme example, you could always render "mixed" in mono. >>>> >>>>> - If you have audio from more than one scene, what should you do=20 >>>>> with >>> >>>>> it? Should you mix, even though you have no spatial relationships? >>>> >>>> IMHO, you should _invent_ a spatial relationship in that case. >>>> Even if each room invents a different spatial relationship, it will >>>> prove less confusing. >>>> >>>>> Or should you switch based on active speaker? >>>> >>>> Only if background-noise is a serious problem. >>>> >>>>> What would help you to decide? >>>> >>>> It becomes quickly obvious to the listener! >>>> >>>>> The problems are superficially different for MCUs. But perhaps=20 >>>>> only superficially. It seems to me that when the MCU decides how=20 >>>>> to map its inputs into its advertisement, it has some virtual room >>>>> layouts >>> in mind. >>>> >>>> I would expect so. >>>> >>>>> So for each virtual room layout it is addressing the same issues=20 >>>>> as a >>> >>>>> real endpoint with that layout. But it does have the added problem >>>>> of >>> >>>>> deciding how to describe what it is advertising - e.g. when to >> apply >>>>> the mixed/composed attributes. >>>> >>>> Pretty much always, unless it's feeding an exact copy of what >> it >>>> receives. >>> >>> Since I've seen people here describe cases when that isn't so, it=20 >>> would be helpful to have a more precise definition. >>> >>>>> Some interesting use cases for all of the above would be very >>> helpful. >>>> >>>> Did the cases I listed help? >>> >>> I think they need to be worked out in much more detail: >>> >>> - what equipment (input and output) is in each endpoint, and where. >>> - what is advertised and how the input equipment is mapped to >>> the advertisement >>> - how each endpoint maps the advertised captures to its output >> equipment >>> together with how the info in the advertisement allowed it to >>> determine that mapping. >>> >>> [Espen] Agree, being practical about what we will offer for actual=20 >>> endpoints are useful. >>> >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Apr 16 16:34:27 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A3111E80EC for ; Mon, 16 Apr 2012 16:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XjSAwcbFw-T for ; Mon, 16 Apr 2012 16:34:25 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 051CE11E80E4 for ; Mon, 16 Apr 2012 16:34:24 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id yicT1i00G1swQuc53naRXE; Mon, 16 Apr 2012 23:34:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id ynaQ1i00g07duvL3bnaRT8; Mon, 16 Apr 2012 23:34:25 +0000 Message-ID: <4F8CAC7F.7040405@alum.mit.edu> Date: Mon, 16 Apr 2012 19:34:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Brian Baldino (bbaldino)" References: <4F846AE0.4010700@alum.mit.edu><20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com><4F873CCE.3020806@alum.mit.edu><4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 23:34:27 -0000 On 4/16/12 7:19 PM, Brian Baldino (bbaldino) wrote: > Hey Paul, with regards to this bit: > > "For instance, suppose the sender does something to combine some of its > captures so that it can advertise a capture scene entry that requires > fewer displays. E.g. suppose it has three main captures of participants > and one presentation capture. And suppose in addition to advertising all > of those as one entry, it also advertises another entry for a > three-screen room, consisting of one capture for the presentation, one > for the current speaker, and one for the prior speaker. So that is one > fixed and two switched captures. If the recipient need to map this to > two displays, how does it decide what to do? The obvious thing would be > to omit the capture for the prior speaker. But how would it know which > one that is." > > My understanding was more that the provider would advertise all valid > views with a capture entry for each, not require (or rely on) an > endpoint to be able to "find" a valid view which is a subset of one that > was actually advertised; therefore relieving the consumer of that > responsibility. So in this case, the provider would advertise entries > that contained: > 1) Just the active speaker > 2) The active speaker and previous active speaker > 3) The active speaker, previous active speaker and presentation > (Maybe even a 4th that contained the active speaker and presentation) > > The idea being that the provider is smart enough to know/advertise its > valid views rather than rely on the consumer to figure them out. > > Even with this there are still situations where no advertised view is > ideal for the consumer, maybe this is the situation you're referring to? > I'd hoped that the consumer could get away with choosing the "next best > fit" using information already in the advertisement (how many captures > an entry consists of, switched vs. non-switched, area of capture info, > etc.) What you describe certainly seems possible, within limits. As you add more "raw" captures, the number of possibilities goes up combinatorially. I would think there would be a temptation to just offer the entries you think will be popular. (E.g. the ones supported by room configurations you sell, and perhaps not those sold by competitors.) If this is the solution, then perhaps we should have guidelines for the sorts of advertisements that should be offered. As I mentioned somewhere, this gets harder when there is more than one scene in the advertisement, because the advertiser has no way to indicate how to balance the entries in different captures. Perhaps that means that a separate scene should not be used for presentations, even though there is no natural coordinate relationship between the presentation and the captures of participants. I'm just trying to see if we have common expectations in the group, that those expectations are consistent with the requirements and use cases, and that the support for those expectations is documented. Thanks, Paul > -Brian > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Monday, April 16, 2012 7:35 AM > To: Roni Even > Cc: 'CLUE' > Subject: Re: [clue] Does framework provide sufficient info for receiver? > > Hi Roni, > > On 4/15/12 11:20 AM, Roni Even wrote: >> Hi Paul, >> I think that there is enough information that will allow a receiver to > >> select N out of M streams. >> The receiver will know the semantics of the streams (people or >> presentation) and the spatial information of the room and the > different streams. >> My view is that this is enough for the general telepresence point to >> point use case. > > I think I agree for the case where there is a single scene advertised, > and all the captures represent single cameras. > > But as soon as you add in mixed or switched captures it becomes far less > clear. > > For instance, suppose the sender does something to combine some of its > captures so that it can advertise a capture scene entry that requires > fewer displays. E.g. suppose it has three main captures of participants > and one presentation capture. And suppose in addition to advertising all > of those as one entry, it also advertises another entry for a > three-screen room, consisting of one capture for the presentation, one > for the current speaker, and one for the prior speaker. So that is one > fixed and two switched captures. If the recipient need to map this to > two displays, how does it decide what to do? The obvious thing would be > to omit the capture for the prior speaker. But how would it know which > one that is. > >> As for multipoint use case, this is why I think it is important to >> know if the advertisement is based on site switch or segment switch >> which will provide the extra information needed for the selection >> (spatial information provides the internal relation between the >> capture) and I think that the audio level will help with knowing who >> are the active speakers in this case > > I think there are too many unknowns in the above to discuss it with > clarity. We need some use cases. > > Thanks, > Paul > >> Roni >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Thursday, April 12, 2012 11:37 PM >>> To: Espen Berger (espeberg) >>> Cc: CLUE >>> Subject: Re: [clue] Does framework provide sufficient info for >>> receiver? >>> >>> Espen - comments inline. >>> >>> Thanks, >>> Paul >>> >>> On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: >>>> During the CLUE design team meeting on webex yesterday we started to > >>>> discuss various use cases and if they are in scope or not for the >>>> current work in CLUE. >>>> >>>> As a part of my response to Pauls questions I summarized the use >>> cases >>>> and grouped them into supported / not supported. I can dive into >>>> more detail about the use cases if people are interested? >>>> >>>> I would answer yes to the following use cases >>>> * Telepresence point to point, where the reproduction will happen in >>> a >>>> 2D-plane for audio and video. Currently CLUE support announcing >>>> capability of sending 1 - N capture (left to right) and a receiver >>> can >>>> request 1 - M streams for rendering (left to tight), which is the >>>> basic for interoperability. >>> >>> In this case, suppose N> M. Who is responsible for deciding which M >>> of the N streams will be used? AFAIK the recipient just picks the >>> ones it wants. So then my question remains - does the recipient have >>> sufficient info to select the "right" ones? (There isn't any >>> guarantee that *any* N of the M streams will provide a reasonable > rendering. >>> >>> This would be improved if we had a mechanism for the recipient to >>> state "I can only handle N streams" and the sender was obligated to >>> meet that constraint. I don't think we have said that. >>> >>>> * Transcoded conferencing, where the MCU act like an endpoint and >>>> logically announces audio and video left to right and a receiver >>>> request >>>> 1 - M captures depending on how many screen and audio streams you >>>> prefer. Typically a single video stream pr. screen and one audio pr. >>>> screen (mono/stereo). Excluded is capabilities to select individual >>>> speakers, the MCU is free to optimize what to compose and send to a >>>> receiver. >>> >>> This is logically equivalent to the prior case. >>> >>>> * Generic multi source, sending and receiving named sources where >>>> the user experience is controlled by an human being capable of >>>> reading sources names, or control software written explicit to >>>> operate on the named streams. The content attribute can be used to >>>> indicate a >>> primary >>>> role, RFC4796 uses 'main' and 'alt'. >>> >>> Are you talking about the text names/labels we were discussing on the > >>> last call? >>> >>> If so, I agree that if the senders provide well conceived labels then > >>> a human can probably decide something reasonable. >>> >>> If the human is working only with "content" attributes, then its not >>> so clear. Its quite possible that the recipient will find itself >>> trying to choose between multiple streams with the same content type. > >>> (E.g. all >>> 'main'.) >>> >>>> I would answer no, to the following use cases >>>> * Switched conferencing, where we assume that endpoints do scalable >>>> video (either SVC or Simulcast), locally composited layout and audio > >>>> mixing. Limited work has been done on how to use Scalable video and >>>> how to build mechanisms for complete composited layouts. >>>> * Advanced audio reproduction, a group of audio scenarios mentioned >>> by >>>> Jon Leslie and Johan Nielsen that requires more details during >>> initial >>>> signalling and more dynamic information for transferring dynamic >>>> meta-information. >>>> * Multi view, as described in the CLUE use case document. >>>> >>>> (Other comments inline.) >>>> >>>> Cheers >>>> >>>> -Espen >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >>>> Of Paul Kyzivat >>>> Sent: 11. april 2012 17:06 >>>> To: John Leslie >>>> Cc: CLUE >>>> Subject: Re: [clue] Does framework provide sufficient info for >>> receiver? >>>> >>>> Hi John, >>>> >>>> Thanks for the comments. I've followed up inline. >>>> >>>> On 4/10/12 5:09 PM, John Leslie wrote: >>>>> Paul Kyzivat wrote: >>>>>> >>>>>> The fundamental problem in the scope of CLUE is, if you are an >>>>>> endpoint, and you have received an advertisement, with some scenes > >>>>>> and captures, do you have sufficient information to select and map > >>>>>> the advertised scenes/captures onto the equipment you have? >>>>> >>>>> Of course not! >>>>> >>>>> If we wanted that, we'd have to include for every composed >>> scene >>>>> what it's composed from, and for every mixed audio what it's mixed >>>>> from. >>>> >>>> I think you must have misunderstood me. Otherwise I wouldn't expect >>>> you to answer "Of course not". AFAIK the whole point of CLUE is to >>>> provide the information to make this possible. >>>> >>>> My point in asking the question was so that we can identify what >>>> information we have overlooked that we need to include one way or >>>> another. >>>> >>>> Clearly there are some tradeoffs. More information might support >>>> *better* mappings. So one thing to decide is how good is good > enough. >>>> [Espen] Agree with Paul, we clearly can support in CLUE the use >>>> cases where a Telepresence room either offer a 1, 2 or 3 video >>>> captures, which can be rendered on 1, 2 or 3 screens. >>> >>> I think its clear we can support cases where every advertisement that > >>> includes an entry for N (>1) captures also includes an entry with >>> only one capture, and optionally entries containing other numbers of >>> captures between 1 and N. >>> >>> But as I mention above, its not clear we have supported case where >>> the minimal entry in the advertisement is for N>1 captures. >>> >>>>>> If you have sufficient equipment (displays, speakers) with >>>>>> compatible >>>> >>>>>> geometry to directly map all of the captures from one audio and >>>>>> one video capture scene entry from each capture scene then maybe >>>>>> all is good. In this case ISTM that the mixed/composed attributes >>>>>> aren't needed. >>>>> >>>>> It's unlikely that the "typical" telepresence conference will > >>>>> have >>>> >>>>> a separate screen for every possible video. >>>> >>>> That isn't what I said. Consider what is perhaps a typical case, >>> where >>>> the advertisement contains one scene with several alternative video >>>> and audio scene entries. Lets just consider the video. Then maybe >>>> there is one entry with three captures, and another with one >>>> (mixed/switched, >>>> whatever) capture. Then if you have three screens you can map all >>>> three captures in the first entry. If you have less than three >>> screens >>>> then you can map the one capture from the 2nd entry onto one of your >>> screens. >>>> >>>> But what if there was no entry with a single capture? If you had two > >>>> screens, would you have enough info about the three captures in the >>>> first entry to make a reasonable mapping onto your two screens? What > >>>> information would we need to include in the advertisement so that it > >>>> would be possible to do this mapping well? >>>> >>>> [Espen] How a vendor build a room or endpoint is transparent from >>>> the sender of media. As a sender you should not care if a room >>>> request 3 audio streams (left, center, right) and choose to mix and >>>> play out on a single speaker. We can argue that this is not the best > >>>> experience, but still valid and typically done for PC-clients or >>>> other endpoints with a single speaker. >>> >>> Again, I think you are assuming the receiver can specify the max >>> number of streams it can handle, and that the sender will then be >>> obligated to select/construct a suitable set of streams. AFAIK we >>> have not written down anything that calls for that. (If I am wrong, >>> please let me know where this is specified.) >>> >>> We have the (largely hypothetical) recipient capabilities message, >>> but its content hasn't been specified yet, and AFAIK there has been >>> no statement that it is binding and the construction of the > advertisement. >>> >>>>> Of course, the number of "capture scenes" _could_ be small >>>>> enough to give each it's own video monitor -- but I don't think >>>>> that's the general case we should design for. >>>> >>>> IIUC an endpoint will typically only advertise one or two scenes. >>>> One would correspond to the cameras and mics in its room. The other, > >>>> if present, would correspond to a "presentation" that doesn't fit >>>> into the coordinate space of the room. There are cases for more, but > >>>> they get more obscure. >>>> >>>> So for a point-to-point clue call the recipient will only need to >>>> map one or two scenes. But when there is more than one it is more >>> complex, >>>> requiring sharing of equipment. >>>> >>>> The situation is more complex for an MCU. It will have as input all >>>> the scenes offered by all the endpoints. It then has to decide what >>> to >>>> offer out to the endpoints. It could just pass through all the >>>> scenes it receives from all the endpoints, leaving the mapping >>>> problem entirely to the endpoints. (I don't think that is what most >>>> people have in mind, though some might.) >>>> >>>> Or it could take on itself the job of mapping/mixing/switching all >>>> of those inputs and producing something more like what a typical >>> endpoint >>>> would advertise - one or two scenes each with just a few captures. >>>> >>>> Or it could do both - advertise its own simplified composite scenes >>>> and also all those provided by the endpoints. That would allow the >>>> endpoints to either take the easy way out, or else do it all >>>> themselves in a way that suits them. Suppose it did this. Would the >>>> endpoints that want to take the easy way be able to figure out which > >>>> scenes and captures to use? >>>> >>>> [Espen] This sounds closer to a user experience discussions than a >>>> protocol discussion. >>> >>> Perhaps it is. But the point of CLUE is to develop a protocol that >>> enables an especially good user experience. While we shouldn't >>> mandate the user experience, I think we are obligated to do due >>> diligence that the protocol is sufficient to enable that user > experience. >>> >>>>> OTOH, with an appropriate "surround-sound" system, you can >>> "place" >>>>> an arbitrarily large number of audio streams, yet make them easy to > >>>>> distinguish. >>>>> >>>>>> If you don't have sufficient equipment to do that, then the job is > >>>>>> harder, and more information is needed to figure out what to do. >>>>> >>>>> Only marginally harder... >>>>> >>>>>> For instance: >>>>>> >>>>>> - If you don't have suitable displays, then perhaps you can select >>> a >>>>>> video capture scene entry and locally compose or switch some of >>>>>> the captures in order to produce a set of captures that does map >>>>>> to the available displays. The area of capture of each capture >>>>>> could be helpful to doing this, and perhaps the composed attribute > as well. >>>>> >>>>> One inevitable use case is filing your formal report from the >>>> airport. >>>>> The person doing so will have lousy audio, vastly inadequate video, > >>>>> and typically inadequate bandwidth with excessive latency. S/he >>>>> will need some middlebox to compose a "barely-adequate video" and >>>>> mono >>>> audio. >>>> >>>> This is indeed an interesting case - one we have explicitly put in >>>> scope. If an MCU is already in the call then perhaps we can hope >>>> that is one of the entries it makes available. >>>> >>>> If there isn't any MCU in the call, then the other endpoint might >>>> not advertise that option. Then what? Do we have a mechanism for > that? >>>> [Espen] If an MCU detect low bandwidth or packet loss it can start >>>> using its normal recovery mechanisms. That could lower bitrate for >>>> audio and video (maybe by a SIP re-invite), change the CLUE offer to > >>>> something that fits inside the available bandwidth. Getting good >>>> quality audio ande video is always a challenge, with or without > clue. >>>> >>>>> Then there's the use case of filing you formal report from >>>>> your home office (when you're sick or somebody doesn't want to pay >>>>> travel >>>> cost). >>>>> You may well have surround-sound and two or three large monitors, >>>>> 20 Mbps download with 40 msec RTT, and a decent-quality lavalier > mike. >>>>> You still probably want some middlebox to compose your basic video, > >>>>> but you can take individual streams as well to concentrate on >>>> particular people. >>>>> >>>>> Near the top end are the corporate telepresence rooms. They >>> will >>>>> want all streams, and are likely to have a human being mixing them. >>>> >>>> I don't understand your point "are likely to have a human being >>> mixing >>>> them". Can you explain further? >>>> [Espen] I see this as mostly a request for focusing in on particular > >>>> user. In a transcoded conference you can do that by looking into >>> XCon, >>>> if you do switched conference the endpoint typically render the >>> layout >>>> and can choose who to focus on. Mixing transcoded and switched >>>> conferencing I think makes it unnecessary complex for the initial >>>> use cases to cover. >>>> >>>>>> - or rather than compose to fit your displays, you could switch... >>>>> >>>>> Folks _will_ do that -- I can't stop them. But I find it >>>> uninteresting. >>>> >>>> ??? We have been talking about switching a lot. Are you saying that >>> is >>>> uninteresting? >>>> >>>> If it makes sense for a middlebox to switch, doesn't it make equal >>>> sense for an endpoint to do so? >>>> >>>>>> - handling video from multiple scenes probably presents some added > >>>>>> issues. By definition there is no specified spatial relationship >>>>>> between the captures of different scenes... >>>>> >>>>> Nonetheless, the participants will want to imagine such a >>>> relationship. >>>> >>>> ISTM that this needs further discussion. >>>> >>>>>> - If you don't have sufficient speakers for all of the audio >>>>>> captures, then you have to decide to mix, switch, or drop some. >>>>> >>>>> There really isn't any such thing as "sufficient speakers", >>>>> but surround-sound should be considered "sufficient". You can >>>>> always mix to stereo or even mono: "you pays your money and you >>>>> takes your >>>> choice". >>>> >>>> Do we have enough information to do it "right" or "well"? >>>> Right now the coordinate info is all optional. Does it need to be >>>> mandatory in order to enable this? >>>> >>>>>> The spatial information from the captures may help in deciding how > >>>>>> to >>>> >>>>>> mix. >>>>> >>>>> Absolutely! >>>>> >>>>>> Not evident that the mixed attribute helps with this >>>>> >>>>> It help you know when mixing is less likely to work well. >>>>> >>>>>> - unless it is used to decide to switch rather than mix. >>>>> >>>>> I'm not sure there is any such thing. "Mixing" frequently >>>>> includes >>>> >>>>> "riding gain" to reduce background noise. Binary switching is just >>>>> a bad idea. >>>> >>>> I have no special understanding of this. I'm just asking probing >>>> questions in hopes that it will result in the right decisions being >>>> made and the right stuff specified. >>>> >>>>>> Of course if you are mapping independent audio captures onto >>>>>> different speakers then they are being implicitly mixed. >>>>> >>>>> Not a useful way to think about it, IMHO. Human ears and >>>>> brains can sort out individual sources if there are enough >>>>> speakers, while mixing makes that harder. >>>> >>>> I have had the impression that "simple" clue telepresence rooms >>>> would be hoping to do direct mapping of captures to devices. If the >>>> assumption is that this will be an unsatisfactory approach and all >>>> endpoints should be prepared to do something more complex then it >>>> would be helpful to write that down somewhere - e.g. in the >>> framework. >>>> >>>> [Espen] Agree with Paul here, the basic scenario is well understood. >>> A >>>> sends two logical audio captures and a receiver play them out with >>> the >>>> same spatial relationship. As rule of thumb here could be that for >>>> basic interoperability between vendors you assume pairs of audio and > >>>> video captures that can be easily rendered on matching pairs of >>>> screens and speaker. >>>> >>>>>> - If you don't have speakers with similar spatial relationship to >>>>>> those of the audio captures, then you must decide whether to do >>>>>> sub-optimal assignments or mix. >>>>> >>>>> I suppose _some_ telepresence system will hide dozens of >>>>> speakers in the telepresence room and try to do this -- to me it >>>>> sounds like a dreadful idea, but it's quite possible the people >>>>> will >>> adapt. >>>>> >>>>> "Sub-optimal" really doesn't have a clear meaning here. Even >>>>> speakers in the "wrong" left-to-right order while you can see the >>>>> "correct" order on-screen won't confuse the listener as much as >>>>> speaker assignments changing for no obvious reason. >>>>> >>>>>> Again not clear if the mixed attribute helps with this. >>>>> >>>>> As an extreme example, you could always render "mixed" in > mono. >>>>> >>>>>> - If you have audio from more than one scene, what should you do >>>>>> with >>>> >>>>>> it? Should you mix, even though you have no spatial relationships? >>>>> >>>>> IMHO, you should _invent_ a spatial relationship in that > case. >>>>> Even if each room invents a different spatial relationship, it will > >>>>> prove less confusing. >>>>> >>>>>> Or should you switch based on active speaker? >>>>> >>>>> Only if background-noise is a serious problem. >>>>> >>>>>> What would help you to decide? >>>>> >>>>> It becomes quickly obvious to the listener! >>>>> >>>>>> The problems are superficially different for MCUs. But perhaps >>>>>> only superficially. It seems to me that when the MCU decides how >>>>>> to map its inputs into its advertisement, it has some virtual room > >>>>>> layouts >>>> in mind. >>>>> >>>>> I would expect so. >>>>> >>>>>> So for each virtual room layout it is addressing the same issues >>>>>> as a >>>> >>>>>> real endpoint with that layout. But it does have the added problem > >>>>>> of >>>> >>>>>> deciding how to describe what it is advertising - e.g. when to >>> apply >>>>>> the mixed/composed attributes. >>>>> >>>>> Pretty much always, unless it's feeding an exact copy of what >>> it >>>>> receives. >>>> >>>> Since I've seen people here describe cases when that isn't so, it >>>> would be helpful to have a more precise definition. >>>> >>>>>> Some interesting use cases for all of the above would be very >>>> helpful. >>>>> >>>>> Did the cases I listed help? >>>> >>>> I think they need to be worked out in much more detail: >>>> >>>> - what equipment (input and output) is in each endpoint, and where. >>>> - what is advertised and how the input equipment is mapped to >>>> the advertisement >>>> - how each endpoint maps the advertised captures to its output >>> equipment >>>> together with how the info in the advertisement allowed it to >>>> determine that mapping. >>>> >>>> [Espen] Agree, being practical about what we will offer for actual >>>> endpoints are useful. >>>> >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From bbaldino@cisco.com Mon Apr 16 17:47:30 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407D011E80F0 for ; Mon, 16 Apr 2012 17:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xlEpfpRPHw2 for ; Mon, 16 Apr 2012 17:47:28 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id AF74A11E80EE for ; Mon, 16 Apr 2012 17:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=5961; q=dns/txt; s=iport; t=1334623648; x=1335833248; h=mime-version:subject:date:message-id:from:to:cc; bh=b47D9U6OlNZ88F6mSbNM9JdhjbsamVzm6C51YiU5EeQ=; b=AP1YTOG0lhTgNILR/pWmDVYH95ZERUN0dUxbbokOLVn7kMOH5KmmHYJb TfwWsmsemxD/JipZmfdGS4roQDg9Inm+15vizIf8XaHzqdDrEg8Y+n+Dh RzBNk9KpQLWN5kupgbJ00o7h3cWp8G3OrIwtpKz/47htY7hnQrwDB7yGf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPy8jE+rRDoI/2dsb2JhbABEgkavA4EHggsBBBIBCREDNwkJEgEqBhgHVwEEGxqHawGZbp98jiWCQWMEiFqbX4Fpgwc X-IronPort-AV: E=Sophos;i="4.75,432,1330905600"; d="scan'208,217";a="40747297" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 17 Apr 2012 00:47:28 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3H0lSxh010168; Tue, 17 Apr 2012 00:47:28 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 17:47:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1C33.A9B32597" Date: Mon, 16 Apr 2012 17:47:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Timing discussion Thread-Index: Ac0cM6fc0quJFEvKRCqlv/pyaD+dpQ== From: "Brian Baldino (bbaldino)" To: X-OriginalArrivalTime: 17 Apr 2012 00:47:28.0573 (UTC) FILETIME=[AA107ED0:01CD1C33] Subject: [clue] Timing discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 00:47:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1C33.A9B32597 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hey all, At the last meeting Mary brought up the topic of 'how quickly do things need to happen' (and therefor where should certain information be carried) came up. I've got some text below that is hopefully a good start to that discussion; I'm sure there are types of data that I missed but hopefully this will work to get things going. =20 -Brian =20 Timings: I've categorized these into three levels: =20 Media plane (typically relatively fast) Media control plane (typically relatively medium) Signaling plane (typically relatively slow) =20 The speeds above are just rough categorizations and only describe the planes in terms of 'relative' speeds as the actual speeds are based on all sorts of factors (i.e. even media plane can be 'slow' if it's going over a satellite link). =20 Listed below are some events and the 'lowest acceptable' time as listed above. Obviously it is ideal for everything to happen as quickly as possible, but, I think what we're really after is what we would be willing to deal with in the worst case. I don't have a lot of scenarios, these were some things I was able to come up with, but hopefully this 'system' will be useful to categorize things that come up moving forward. =20 Image repair (IDR, etc.) - Media control plane Layout change - Signaling plane Bitrate, etc. renegotiation - Signaling plane Switching change (i.e. active speaker) - Media plane Roster list - Signaling plane ------_=_NextPart_001_01CD1C33.A9B32597 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hey = all,

At the last meeting = Mary brought up the topic of ‘how quickly do things need to = happen’ (and therefor where should certain information be carried) = came up.  I’ve got some text below that is hopefully a good = start to that discussion; I’m sure there are types of data that I = missed but hopefully this will work to get things = going.

 

-Brian

 

Timings:
I’ve = categorized these into three levels:
 
Media plane (typically = relatively fast)
Media control plane (typically relatively = medium)
Signaling plane (typically relatively slow)
 
The = speeds above are just rough categorizations and only describe the planes = in terms of ‘relative’ speeds as the actual speeds are based = on all sorts of factors (i.e. even media plane can be ‘slow’ = if it’s going over a satellite link).
 
Listed below = are some events and the ‘lowest acceptable’ time as listed = above.  Obviously it is ideal for everything to happen as quickly = as possible, but, I think what we’re really after is what we would = be willing to deal with in the worst case.  I don’t have a = lot of scenarios, these were some things I was able to come up with, but = hopefully this ‘system’ will be useful to categorize things = that come up moving forward.
 
Image repair (IDR, etc.) = – Media control plane
Layout change – Signaling = plane
Bitrate, etc. renegotiation – Signaling = plane
Switching change (i.e. active speaker) – Media = plane
Roster list – Signaling plane

------_=_NextPart_001_01CD1C33.A9B32597-- From christer.holmberg@ericsson.com Tue Apr 17 03:09:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D351421F8622 for ; Tue, 17 Apr 2012 03:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qzt8gyxUikPT for ; Tue, 17 Apr 2012 03:09:31 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A301D21F85F0 for ; Tue, 17 Apr 2012 03:09:30 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-95-4f8d415920a6 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 26.F1.25560.9514D8F4; Tue, 17 Apr 2012 12:09:29 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 17 Apr 2012 12:09:28 +0200 From: Christer Holmberg To: "Brian Baldino (bbaldino)" , "clue@ietf.org" Date: Tue, 17 Apr 2012 12:09:28 +0200 Thread-Topic: Timing discussion Thread-Index: Ac0cM6fc0quJFEvKRCqlv/pyaD+dpQATjS2A Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42DF5531@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C42DF5531ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Timing discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 10:09:35 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C42DF5531ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The idea of the draft that I will start working on was to define different = criteria for information that needs to be transmitted. Timing is of course = one of the most important criteria. I assume that time critical information in most (all?) cases will have to b= e sent over the media plane, but I don't think we should have a default ass= umption that we will automatically send stuff over the signaling plane just= because it's not time critical. Another criteria is whether intermediaries need to have access to the infor= mation, which may have impact on how it's sent. Regards, Christer From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Bri= an Baldino (bbaldino) Sent: 17. huhtikuuta 2012 3:47 To: clue@ietf.org Subject: [clue] Timing discussion Hey all, At the last meeting Mary brought up the topic of 'how quickly do things nee= d to happen' (and therefor where should certain information be carried) cam= e up. I've got some text below that is hopefully a good start to that disc= ussion; I'm sure there are types of data that I missed but hopefully this w= ill work to get things going. -Brian Timings: I've categorized these into three levels: Media plane (typically relatively fast) Media control plane (typically relatively medium) Signaling plane (typically relatively slow) The speeds above are just rough categorizations and only describe the plane= s in terms of 'relative' speeds as the actual speeds are based on all sorts= of factors (i.e. even media plane can be 'slow' if it's going over a satel= lite link). Listed below are some events and the 'lowest acceptable' time as listed abo= ve. Obviously it is ideal for everything to happen as quickly as possible,= but, I think what we're really after is what we would be willing to deal w= ith in the worst case. I don't have a lot of scenarios, these were some th= ings I was able to come up with, but hopefully this 'system' will be useful= to categorize things that come up moving forward. Image repair (IDR, etc.) - Media control plane Layout change - Signaling plane Bitrate, etc. renegotiation - Signaling plane Switching change (i.e. active speaker) - Media plane Roster list - Signaling plane --_000_7F2072F1E0DE894DA4B517B93C6A05852C42DF5531ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The idea of the draft that I will start working on was t= o define different criteria for information that needs to be transmitted. T= iming is of course one of the most important criteria.

 

I assume that time = critical information in most (all?) cases will have to be sent over the med= ia plane, but I don’t think we should have a default assumption that = we will automatically send stuff over the signaling plane just because it&#= 8217;s not time critical.

 

Another criteria is whether intermediaries need = to have access to the information, which may have impact on how it’s = sent.

 

Regards,

 

Christer

 

<= span style=3D'color:#1F497D'> 

 

=

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.or= g] On Behalf Of Brian Baldino (bbaldino)
Sent: 17. huhtiku= uta 2012 3:47
To: clue@ietf.org
Subject: [clue] Timing = discussion

 = ;

Hey all,

At the last meeting Mary= brought up the topic of ‘how quickly do things need to happen’= (and therefor where should certain information be carried) came up.  = I’ve got some text below that is hopefully a good start to that discu= ssion; I’m sure there are types of data that I missed but hopefully t= his will work to get things going.

 

-Brian

 

Timings:
I’ve categorized these into three levels:<= br> 
Media plane (typically relatively fast)
Media control plane= (typically relatively medium)
Signaling plane (typically relatively slo= w)
 
The speeds above are just rough categorizations and only de= scribe the planes in terms of ‘relative’ speeds as the actual s= peeds are based on all sorts of factors (i.e. even media plane can be ̵= 6;slow’ if it’s going over a satellite link).
 
List= ed below are some events and the ‘lowest acceptable’ time as li= sted above.  Obviously it is ideal for everything to happen as quickly= as possible, but, I think what we’re really after is what we would b= e willing to deal with in the worst case.  I don’t have a lot of= scenarios, these were some things I was able to come up with, but hopefull= y this ‘system’ will be useful to categorize things that come u= p moving forward.
 
Image repair (IDR, etc.) – Media contr= ol plane
Layout change – Signaling plane
Bitrate, etc. renegoti= ation – Signaling plane
Switching change (i.e. active speaker) = 211; Media plane
Roster list – Signaling plane

= --_000_7F2072F1E0DE894DA4B517B93C6A05852C42DF5531ESESSCMS0356e_-- From pkyzivat@alum.mit.edu Tue Apr 17 06:24:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D732A21F84F8 for ; Tue, 17 Apr 2012 06:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljIYzK-zgDio for ; Tue, 17 Apr 2012 06:24:21 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id D66E821F857D for ; Tue, 17 Apr 2012 06:24:20 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id z1Eg1i0071swQuc5F1QL4d; Tue, 17 Apr 2012 13:24:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id z1QL1i01807duvL3b1QMtY; Tue, 17 Apr 2012 13:24:21 +0000 Message-ID: <4F8D6F03.1040508@alum.mit.edu> Date: Tue, 17 Apr 2012 09:24:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Timing discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:24:25 -0000 Brian, I'm having trouble making sense of what you are proposing without some numbers attached. For instance its hard for me to distinguish between what needs to be in the media control plane and what could be in the signaling plane without any estimates of the timing of either, or of the required timing. Otherwise I think it simply becomes an exercise of "X seems like signaling so it should go in the signaling plane, Y seems like media so it should go in the media plane, ...". Is it possible to put some numeric time ranges on these things? Thanks, Paul On 4/16/12 8:47 PM, Brian Baldino (bbaldino) wrote: > Hey all, > > At the last meeting Mary brought up the topic of ‘how quickly do things > need to happen’ (and therefor where should certain information be > carried) came up. I’ve got some text below that is hopefully a good > start to that discussion; I’m sure there are types of data that I missed > but hopefully this will work to get things going. > > -Brian > > ** > > *Timings*: > I’ve categorized these into three levels: > > Media plane (typically relatively fast) > Media control plane (typically relatively medium) > Signaling plane (typically relatively slow) > > The speeds above are just rough categorizations and only describe the > planes in terms of ‘relative’ speeds as the actual speeds are based on > all sorts of factors (i.e. even media plane can be ‘slow’ if it’s going > over a satellite link). > > Listed below are some events and the ‘lowest acceptable’ time as listed > above. Obviously it is ideal for everything to happen as quickly as > possible, but, I think what we’re really after is what we would be > willing to deal with in the worst case. I don’t have a lot of scenarios, > these were some things I was able to come up with, but hopefully this > ‘system’ will be useful to categorize things that come up moving forward. > > Image repair (IDR, etc.) – Media control plane > Layout change – Signaling plane > Bitrate, etc. renegotiation – Signaling plane > Switching change (i.e. active speaker) – Media plane > Roster list – Signaling plane > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Apr 17 06:31:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A803E21F863C for ; Tue, 17 Apr 2012 06:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOCiQyOgQnL7 for ; Tue, 17 Apr 2012 06:31:25 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9287221F8638 for ; Tue, 17 Apr 2012 06:31:25 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta10.westchester.pa.mail.comcast.net with comcast id z1WZ1i0040QuhwU5A1XSL3; Tue, 17 Apr 2012 13:31:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta02.westchester.pa.mail.comcast.net with comcast id z1XR1i00b07duvL3N1XRp7; Tue, 17 Apr 2012 13:31:26 +0000 Message-ID: <4F8D70AC.5050008@alum.mit.edu> Date: Tue, 17 Apr 2012 09:31:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852C42DF5531@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42DF5531@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Timing discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:31:29 -0000 On 4/17/12 6:09 AM, Christer Holmberg wrote: > Hi, > > The idea of the draft that I will start working on was to define > different criteria for information that needs to be transmitted. Timing > is of course one of the most important criteria. > > I assume that time critical information in most (all?) cases will have > to be sent over the media plane, but I don’t think we should have a > default assumption that we will automatically send stuff over the > signaling plane just because it’s not time critical. As I just replied to Brian, ISTM that it would be helpful to put some numbers to the information - expected size, frequency, acceptable latency. Also implications of data loss if sent over an unreliable channel. Of course all of these numbers will have to be ranges. > Another criteria is whether intermediaries need to have access to the > information, which may have impact on how it’s sent. Yeah, I suppose so. Thanks, Paul > Regards, > > Christer > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Brian Baldino (bbaldino) > *Sent:* 17. huhtikuuta 2012 3:47 > *To:* clue@ietf.org > *Subject:* [clue] Timing discussion > > Hey all, > > At the last meeting Mary brought up the topic of ‘how quickly do things > need to happen’ (and therefor where should certain information be > carried) came up. I’ve got some text below that is hopefully a good > start to that discussion; I’m sure there are types of data that I missed > but hopefully this will work to get things going. > > -Brian > > ** > > *Timings*: > I’ve categorized these into three levels: > > Media plane (typically relatively fast) > Media control plane (typically relatively medium) > Signaling plane (typically relatively slow) > > The speeds above are just rough categorizations and only describe the > planes in terms of ‘relative’ speeds as the actual speeds are based on > all sorts of factors (i.e. even media plane can be ‘slow’ if it’s going > over a satellite link). > > Listed below are some events and the ‘lowest acceptable’ time as listed > above. Obviously it is ideal for everything to happen as quickly as > possible, but, I think what we’re really after is what we would be > willing to deal with in the worst case. I don’t have a lot of scenarios, > these were some things I was able to come up with, but hopefully this > ‘system’ will be useful to categorize things that come up moving forward. > > Image repair (IDR, etc.) – Media control plane > Layout change – Signaling plane > Bitrate, etc. renegotiation – Signaling plane > Switching change (i.e. active speaker) – Media plane > Roster list – Signaling plane > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From marshall.eubanks@gmail.com Tue Apr 17 06:47:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583D821F85C2 for ; Tue, 17 Apr 2012 06:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pci29SSTJPC3 for ; Tue, 17 Apr 2012 06:47:31 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC02821F852E for ; Tue, 17 Apr 2012 06:47:30 -0700 (PDT) Received: by lbgc1 with SMTP id c1so325987lbg.31 for ; Tue, 17 Apr 2012 06:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hIT2QxeiXuPIEeVAQdlwUiXJp/A2zPyxxcnqrA8y/m0=; b=oEIzIddSfn2qM5FVuptNoHTqIZC1WRGVj4JFIMjJ7UIR5W+ARKMYh09U3WmnW50z0o CstYSuZaJoIEOyXQQPqKQKAS/kcWU43MH7wJFuPCCjhP//7uC7LkQCdlgZO7300ZrBpG Sf3vIj1IJevybfwJflTfG/zt3xDK/s9NxNqkNX8csGGrkjnQ1uV1lmPeOv0WvU/8uZF3 xZGCuPiZ3Ljrj9FOtBtzntGL2xvnKxieuSqNSOeTkgnGye6jV2AXzx2HQXsZPX7utCiD THY0ILYVWcm/aNyx6c1Z844I8I5zECV0dOcgc5cAyIhZIAhrUAnC/CwuPb1rJ6637b/P twgQ== MIME-Version: 1.0 Received: by 10.112.49.136 with SMTP id u8mr7396370lbn.2.1334670449600; Tue, 17 Apr 2012 06:47:29 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Tue, 17 Apr 2012 06:47:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Apr 2012 09:47:29 -0400 Message-ID: From: Marshall Eubanks To: "Brian Baldino (bbaldino)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: clue@ietf.org Subject: Re: [clue] Timing discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:47:35 -0000 On Mon, Apr 16, 2012 at 8:47 PM, Brian Baldino (bbaldino) wrote: > Hey all, > > At the last meeting Mary brought up the topic of =91how quickly do things= need > to happen=92 (and therefor where should certain information be carried) c= ame > up.=A0 I=92ve got some text below that is hopefully a good start to that > discussion; I=92m sure there are types of data that I missed but hopefull= y > this will work to get things going. > > > > -Brian > > > > Timings: > I=92ve categorized these into three levels: > > Media plane (typically relatively fast) > Media control plane (typically relatively medium) > Signaling plane (typically relatively slow) > > The speeds above are just rough categorizations and only describe the pla= nes > in terms of =91relative=92 speeds as the actual speeds are based on all s= orts of > factors (i.e. even media plane can be =91slow=92 if it=92s going over a s= atellite > link). First off, is CLUE really going to set up 3 communications mechanisms ? I hope not. Second, can we not describe any non-SIP based control channel as being in the "media plane?" I would prefer "CLUE control channel." My reasoning here is that there may be "media plane" communications that occur at a layer below CLUE (e.g., RTCP). Unless we are literally planning to use that media plane, I don't think we should call what we are doing media plane. Third, timings. I think that there are 3 time scales of interest. These are (roughly, and from a video-centric perspective) - 30 msec. This is a video frame. Nothing of significance I think can happen faster, and some things, such as video switching, ideally would only take one frame. When I think of "media plane" this is the time scale I am thinking of. This can only be achieved with one-way communication, as most RTT will be > 30 msec. - 200 msec. This was always viewed as the ideal IPTV channel change time (and a lot of work was done on IGMP to try and get there). This also happens to be a rough upper bound on non-noticeable RTTs, and so is a rough limit on how fast you can do things if those things require some sort of RT handshake / authorization / acknowledgement. I think that it would be good to do many CLUE config changes in this time range - experience is that users will tolerate 200 msec of interruption or dead time, if something major changes. - many seconds. Setting up a conference, changing basic conference parameters, etc., can take many seconds. Rebooting equipment can take many seconds. Things that require, .e.g., noticing that a heartbeat is gone, or that there is a failure to respond to a message, will also typically take this sort of time. Experience is that a many seconds delay may be OK at the start of a conference, or in case of a major failure, but shouldn't happen very often if at all inside a functioning conference. My opinion is that we will not do things on the 30 msec time frame, that we should set up a CLUE signaling channel, and aim for 200 msec type performance (when the RTT will support it), and that timing then becomes a discussion of what is priority, and what is not. draft-wenger-clue-transport-02 says At this point in time, there is no proposal on the table that suggests that we can avoid a CLUE control channel. I still think that is valid. Regards Marshall > > Listed below are some events and the =91lowest acceptable=92 time as list= ed > above. =A0Obviously it is ideal for everything to happen as quickly as > possible, but, I think what we=92re really after is what we would be will= ing > to deal with in the worst case. =A0I don=92t have a lot of scenarios, the= se were > some things I was able to come up with, but hopefully this =91system=92 w= ill be > useful to categorize things that come up moving forward. > > Image repair (IDR, etc.) =96 Media control plane > Layout change =96 Signaling plane > Bitrate, etc. renegotiation =96 Signaling plane > Switching change (i.e. active speaker) =96 Media plane > Roster list =96 Signaling plane > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From ron.even.tlv@gmail.com Tue Apr 17 07:23:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67F111E8080 for ; Tue, 17 Apr 2012 07:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvf2t7rK8Jg5 for ; Tue, 17 Apr 2012 07:23:12 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id EC7FC21F84EE for ; Tue, 17 Apr 2012 07:23:11 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so538401wib.13 for ; Tue, 17 Apr 2012 07:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=lmiLmNemuyGYM0Skcr3/4gGWJxOilohT9b+fGzuSLWI=; b=mWurdeog/u/4Yk1S4/5WfF+pqhEQaxNGL4m2XaAdK6pl72jgL1m9IR/cWRDnU35ATA KImMMLk2oqdRJ0igfhjkSkascOjPKR6lihje0ZrtLr4PX8A05EGG2dsc42sPGRXNivWz TPFARoXAv6/0VNCNT9s3uARjhO5owJ3DiL1HBz5b3lgCpOeRhduzGLFJO9DFrfnawHFY bTQFuaGVoO+TVWeyAF3kCvcZy19rB0jppJqp56f33HNMsj8BwbY94g8a/H8gQcN3V5a9 1x+CFF9WQtvNSIF1mkzeBXw/2UZjApnnAs1KIfpIUa+2Fg9cGssyMWZFkq68yFB45dFl EnCQ== Received: by 10.180.95.37 with SMTP id dh5mr7667478wib.8.1334672589137; Tue, 17 Apr 2012 07:23:09 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id fl2sm43850869wib.2.2012.04.17.07.23.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 07:23:07 -0700 (PDT) From: "Roni Even" To: "'Brian Baldino \(bbaldino\)'" , "'Paul Kyzivat'" References: <4F846AE0.4010700@alum.mit.edu><20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com><4F873CCE.3020806@alum.mit.edu><4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> In-Reply-To: Date: Tue, 17 Apr 2012 17:21:33 +0300 Message-ID: <4f8d7ccb.2266b40a.1ceb.fffffc00@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0b3h33jHHCHBWnRma9BZYX5Y4QRgARLyAwACCIeOA= Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:23:16 -0000 Hi, My view is that in this case the provider can advertise the three fixed captures and one with switched which may be the active speaker. We will need a way to let the consumer know who is the current speaker enabling him to choose the switched active speaker stream and one of the fixed streams which may be the previous speaker. Roni > -----Original Message----- > From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] > Sent: Tuesday, April 17, 2012 2:19 AM > To: Paul Kyzivat; Roni Even > Cc: CLUE > Subject: RE: [clue] Does framework provide sufficient info for > receiver? > > Hey Paul, with regards to this bit: > > "For instance, suppose the sender does something to combine some of its > captures so that it can advertise a capture scene entry that requires > fewer displays. E.g. suppose it has three main captures of participants > and one presentation capture. And suppose in addition to advertising > all of those as one entry, it also advertises another entry for a > three-screen room, consisting of one capture for the presentation, one > for the current speaker, and one for the prior speaker. So that is one > fixed and two switched captures. If the recipient need to map this to > two displays, how does it decide what to do? The obvious thing would be > to omit the capture for the prior speaker. But how would it know which > one that is." > > My understanding was more that the provider would advertise all valid > views with a capture entry for each, not require (or rely on) an > endpoint to be able to "find" a valid view which is a subset of one > that was actually advertised; therefore relieving the consumer of that > responsibility. So in this case, the provider would advertise entries > that contained: > 1) Just the active speaker > 2) The active speaker and previous active speaker > 3) The active speaker, previous active speaker and presentation (Maybe > even a 4th that contained the active speaker and presentation) > > The idea being that the provider is smart enough to know/advertise its > valid views rather than rely on the consumer to figure them out. > > Even with this there are still situations where no advertised view is > ideal for the consumer, maybe this is the situation you're referring > to? > I'd hoped that the consumer could get away with choosing the "next best > fit" using information already in the advertisement (how many captures > an entry consists of, switched vs. non-switched, area of capture info, > etc.) > > -Brian > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Monday, April 16, 2012 7:35 AM > To: Roni Even > Cc: 'CLUE' > Subject: Re: [clue] Does framework provide sufficient info for > receiver? > > Hi Roni, > > On 4/15/12 11:20 AM, Roni Even wrote: > > Hi Paul, > > I think that there is enough information that will allow a receiver > to > > > select N out of M streams. > > The receiver will know the semantics of the streams (people or > > presentation) and the spatial information of the room and the > different streams. > > My view is that this is enough for the general telepresence point to > > point use case. > > I think I agree for the case where there is a single scene advertised, > and all the captures represent single cameras. > > But as soon as you add in mixed or switched captures it becomes far > less clear. > > For instance, suppose the sender does something to combine some of its > captures so that it can advertise a capture scene entry that requires > fewer displays. E.g. suppose it has three main captures of participants > and one presentation capture. And suppose in addition to advertising > all of those as one entry, it also advertises another entry for a > three-screen room, consisting of one capture for the presentation, one > for the current speaker, and one for the prior speaker. So that is one > fixed and two switched captures. If the recipient need to map this to > two displays, how does it decide what to do? The obvious thing would be > to omit the capture for the prior speaker. But how would it know which > one that is. > > > As for multipoint use case, this is why I think it is important to > > know if the advertisement is based on site switch or segment switch > > which will provide the extra information needed for the selection > > (spatial information provides the internal relation between the > > capture) and I think that the audio level will help with knowing who > > are the active speakers in this case > > I think there are too many unknowns in the above to discuss it with > clarity. We need some use cases. > > Thanks, > Paul > > > Roni > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Thursday, April 12, 2012 11:37 PM > >> To: Espen Berger (espeberg) > >> Cc: CLUE > >> Subject: Re: [clue] Does framework provide sufficient info for > >> receiver? > >> > >> Espen - comments inline. > >> > >> Thanks, > >> Paul > >> > >> On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: > >>> During the CLUE design team meeting on webex yesterday we started > to > > >>> discuss various use cases and if they are in scope or not for the > >>> current work in CLUE. > >>> > >>> As a part of my response to Pauls questions I summarized the use > >> cases > >>> and grouped them into supported / not supported. I can dive into > >>> more detail about the use cases if people are interested? > >>> > >>> I would answer yes to the following use cases > >>> * Telepresence point to point, where the reproduction will happen > in > >> a > >>> 2D-plane for audio and video. Currently CLUE support announcing > >>> capability of sending 1 - N capture (left to right) and a receiver > >> can > >>> request 1 - M streams for rendering (left to tight), which is the > >>> basic for interoperability. > >> > >> In this case, suppose N> M. Who is responsible for deciding which M > >> of the N streams will be used? AFAIK the recipient just picks the > >> ones it wants. So then my question remains - does the recipient have > >> sufficient info to select the "right" ones? (There isn't any > >> guarantee that *any* N of the M streams will provide a reasonable > rendering. > >> > >> This would be improved if we had a mechanism for the recipient to > >> state "I can only handle N streams" and the sender was obligated to > >> meet that constraint. I don't think we have said that. > >> > >>> * Transcoded conferencing, where the MCU act like an endpoint and > >>> logically announces audio and video left to right and a receiver > >>> request > >>> 1 - M captures depending on how many screen and audio streams you > >>> prefer. Typically a single video stream pr. screen and one audio > pr. > >>> screen (mono/stereo). Excluded is capabilities to select individual > >>> speakers, the MCU is free to optimize what to compose and send to a > >>> receiver. > >> > >> This is logically equivalent to the prior case. > >> > >>> * Generic multi source, sending and receiving named sources where > >>> the user experience is controlled by an human being capable of > >>> reading sources names, or control software written explicit to > >>> operate on the named streams. The content attribute can be used to > >>> indicate a > >> primary > >>> role, RFC4796 uses 'main' and 'alt'. > >> > >> Are you talking about the text names/labels we were discussing on > the > > >> last call? > >> > >> If so, I agree that if the senders provide well conceived labels > then > > >> a human can probably decide something reasonable. > >> > >> If the human is working only with "content" attributes, then its not > >> so clear. Its quite possible that the recipient will find itself > >> trying to choose between multiple streams with the same content > type. > > >> (E.g. all > >> 'main'.) > >> > >>> I would answer no, to the following use cases > >>> * Switched conferencing, where we assume that endpoints do scalable > >>> video (either SVC or Simulcast), locally composited layout and > audio > > >>> mixing. Limited work has been done on how to use Scalable video and > >>> how to build mechanisms for complete composited layouts. > >>> * Advanced audio reproduction, a group of audio scenarios mentioned > >> by > >>> Jon Leslie and Johan Nielsen that requires more details during > >> initial > >>> signalling and more dynamic information for transferring dynamic > >>> meta-information. > >>> * Multi view, as described in the CLUE use case document. > >>> > >>> (Other comments inline.) > >>> > >>> Cheers > >>> > >>> -Espen > >>> > >>> -----Original Message----- > >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > >>> Of Paul Kyzivat > >>> Sent: 11. april 2012 17:06 > >>> To: John Leslie > >>> Cc: CLUE > >>> Subject: Re: [clue] Does framework provide sufficient info for > >> receiver? > >>> > >>> Hi John, > >>> > >>> Thanks for the comments. I've followed up inline. > >>> > >>> On 4/10/12 5:09 PM, John Leslie wrote: > >>>> Paul Kyzivat wrote: > >>>>> > >>>>> The fundamental problem in the scope of CLUE is, if you are an > >>>>> endpoint, and you have received an advertisement, with some > scenes > > >>>>> and captures, do you have sufficient information to select and > map > > >>>>> the advertised scenes/captures onto the equipment you have? > >>>> > >>>> Of course not! > >>>> > >>>> If we wanted that, we'd have to include for every composed > >> scene > >>>> what it's composed from, and for every mixed audio what it's mixed > >>>> from. > >>> > >>> I think you must have misunderstood me. Otherwise I wouldn't expect > >>> you to answer "Of course not". AFAIK the whole point of CLUE is to > >>> provide the information to make this possible. > >>> > >>> My point in asking the question was so that we can identify what > >>> information we have overlooked that we need to include one way or > >>> another. > >>> > >>> Clearly there are some tradeoffs. More information might support > >>> *better* mappings. So one thing to decide is how good is good > enough. > >>> [Espen] Agree with Paul, we clearly can support in CLUE the use > >>> cases where a Telepresence room either offer a 1, 2 or 3 video > >>> captures, which can be rendered on 1, 2 or 3 screens. > >> > >> I think its clear we can support cases where every advertisement > that > > >> includes an entry for N (>1) captures also includes an entry with > >> only one capture, and optionally entries containing other numbers of > >> captures between 1 and N. > >> > >> But as I mention above, its not clear we have supported case where > >> the minimal entry in the advertisement is for N>1 captures. > >> > >>>>> If you have sufficient equipment (displays, speakers) with > >>>>> compatible > >>> > >>>>> geometry to directly map all of the captures from one audio and > >>>>> one video capture scene entry from each capture scene then maybe > >>>>> all is good. In this case ISTM that the mixed/composed attributes > >>>>> aren't needed. > >>>> > >>>> It's unlikely that the "typical" telepresence conference > will > > >>>> have > >>> > >>>> a separate screen for every possible video. > >>> > >>> That isn't what I said. Consider what is perhaps a typical case, > >> where > >>> the advertisement contains one scene with several alternative video > >>> and audio scene entries. Lets just consider the video. Then maybe > >>> there is one entry with three captures, and another with one > >>> (mixed/switched, > >>> whatever) capture. Then if you have three screens you can map all > >>> three captures in the first entry. If you have less than three > >> screens > >>> then you can map the one capture from the 2nd entry onto one of > your > >> screens. > >>> > >>> But what if there was no entry with a single capture? If you had > two > > >>> screens, would you have enough info about the three captures in the > >>> first entry to make a reasonable mapping onto your two screens? > What > > >>> information would we need to include in the advertisement so that > it > > >>> would be possible to do this mapping well? > >>> > >>> [Espen] How a vendor build a room or endpoint is transparent from > >>> the sender of media. As a sender you should not care if a room > >>> request 3 audio streams (left, center, right) and choose to mix and > >>> play out on a single speaker. We can argue that this is not the > best > > >>> experience, but still valid and typically done for PC-clients or > >>> other endpoints with a single speaker. > >> > >> Again, I think you are assuming the receiver can specify the max > >> number of streams it can handle, and that the sender will then be > >> obligated to select/construct a suitable set of streams. AFAIK we > >> have not written down anything that calls for that. (If I am wrong, > >> please let me know where this is specified.) > >> > >> We have the (largely hypothetical) recipient capabilities message, > >> but its content hasn't been specified yet, and AFAIK there has been > >> no statement that it is binding and the construction of the > advertisement. > >> > >>>> Of course, the number of "capture scenes" _could_ be small > >>>> enough to give each it's own video monitor -- but I don't think > >>>> that's the general case we should design for. > >>> > >>> IIUC an endpoint will typically only advertise one or two scenes. > >>> One would correspond to the cameras and mics in its room. The > other, > > >>> if present, would correspond to a "presentation" that doesn't fit > >>> into the coordinate space of the room. There are cases for more, > but > > >>> they get more obscure. > >>> > >>> So for a point-to-point clue call the recipient will only need to > >>> map one or two scenes. But when there is more than one it is more > >> complex, > >>> requiring sharing of equipment. > >>> > >>> The situation is more complex for an MCU. It will have as input all > >>> the scenes offered by all the endpoints. It then has to decide what > >> to > >>> offer out to the endpoints. It could just pass through all the > >>> scenes it receives from all the endpoints, leaving the mapping > >>> problem entirely to the endpoints. (I don't think that is what most > >>> people have in mind, though some might.) > >>> > >>> Or it could take on itself the job of mapping/mixing/switching all > >>> of those inputs and producing something more like what a typical > >> endpoint > >>> would advertise - one or two scenes each with just a few captures. > >>> > >>> Or it could do both - advertise its own simplified composite scenes > >>> and also all those provided by the endpoints. That would allow the > >>> endpoints to either take the easy way out, or else do it all > >>> themselves in a way that suits them. Suppose it did this. Would the > >>> endpoints that want to take the easy way be able to figure out > which > > >>> scenes and captures to use? > >>> > >>> [Espen] This sounds closer to a user experience discussions than a > >>> protocol discussion. > >> > >> Perhaps it is. But the point of CLUE is to develop a protocol that > >> enables an especially good user experience. While we shouldn't > >> mandate the user experience, I think we are obligated to do due > >> diligence that the protocol is sufficient to enable that user > experience. > >> > >>>> OTOH, with an appropriate "surround-sound" system, you can > >> "place" > >>>> an arbitrarily large number of audio streams, yet make them easy > to > > >>>> distinguish. > >>>> > >>>>> If you don't have sufficient equipment to do that, then the job > is > > >>>>> harder, and more information is needed to figure out what to do. > >>>> > >>>> Only marginally harder... > >>>> > >>>>> For instance: > >>>>> > >>>>> - If you don't have suitable displays, then perhaps you can > select > >> a > >>>>> video capture scene entry and locally compose or switch some of > >>>>> the captures in order to produce a set of captures that does map > >>>>> to the available displays. The area of capture of each capture > >>>>> could be helpful to doing this, and perhaps the composed > attribute > as well. > >>>> > >>>> One inevitable use case is filing your formal report from > the > >>> airport. > >>>> The person doing so will have lousy audio, vastly inadequate > video, > > >>>> and typically inadequate bandwidth with excessive latency. S/he > >>>> will need some middlebox to compose a "barely-adequate video" and > >>>> mono > >>> audio. > >>> > >>> This is indeed an interesting case - one we have explicitly put in > >>> scope. If an MCU is already in the call then perhaps we can hope > >>> that is one of the entries it makes available. > >>> > >>> If there isn't any MCU in the call, then the other endpoint might > >>> not advertise that option. Then what? Do we have a mechanism for > that? > >>> [Espen] If an MCU detect low bandwidth or packet loss it can start > >>> using its normal recovery mechanisms. That could lower bitrate for > >>> audio and video (maybe by a SIP re-invite), change the CLUE offer > to > > >>> something that fits inside the available bandwidth. Getting good > >>> quality audio ande video is always a challenge, with or without > clue. > >>> > >>>> Then there's the use case of filing you formal report from > >>>> your home office (when you're sick or somebody doesn't want to pay > >>>> travel > >>> cost). > >>>> You may well have surround-sound and two or three large monitors, > >>>> 20 Mbps download with 40 msec RTT, and a decent-quality lavalier > mike. > >>>> You still probably want some middlebox to compose your basic > video, > > >>>> but you can take individual streams as well to concentrate on > >>> particular people. > >>>> > >>>> Near the top end are the corporate telepresence rooms. They > >> will > >>>> want all streams, and are likely to have a human being mixing > them. > >>> > >>> I don't understand your point "are likely to have a human being > >> mixing > >>> them". Can you explain further? > >>> [Espen] I see this as mostly a request for focusing in on > particular > > >>> user. In a transcoded conference you can do that by looking into > >> XCon, > >>> if you do switched conference the endpoint typically render the > >> layout > >>> and can choose who to focus on. Mixing transcoded and switched > >>> conferencing I think makes it unnecessary complex for the initial > >>> use cases to cover. > >>> > >>>>> - or rather than compose to fit your displays, you could > switch... > >>>> > >>>> Folks _will_ do that -- I can't stop them. But I find it > >>> uninteresting. > >>> > >>> ??? We have been talking about switching a lot. Are you saying that > >> is > >>> uninteresting? > >>> > >>> If it makes sense for a middlebox to switch, doesn't it make equal > >>> sense for an endpoint to do so? > >>> > >>>>> - handling video from multiple scenes probably presents some > added > > >>>>> issues. By definition there is no specified spatial relationship > >>>>> between the captures of different scenes... > >>>> > >>>> Nonetheless, the participants will want to imagine such a > >>> relationship. > >>> > >>> ISTM that this needs further discussion. > >>> > >>>>> - If you don't have sufficient speakers for all of the audio > >>>>> captures, then you have to decide to mix, switch, or drop some. > >>>> > >>>> There really isn't any such thing as "sufficient speakers", > >>>> but surround-sound should be considered "sufficient". You can > >>>> always mix to stereo or even mono: "you pays your money and you > >>>> takes your > >>> choice". > >>> > >>> Do we have enough information to do it "right" or "well"? > >>> Right now the coordinate info is all optional. Does it need to be > >>> mandatory in order to enable this? > >>> > >>>>> The spatial information from the captures may help in deciding > how > > >>>>> to > >>> > >>>>> mix. > >>>> > >>>> Absolutely! > >>>> > >>>>> Not evident that the mixed attribute helps with this > >>>> > >>>> It help you know when mixing is less likely to work well. > >>>> > >>>>> - unless it is used to decide to switch rather than mix. > >>>> > >>>> I'm not sure there is any such thing. "Mixing" frequently > >>>> includes > >>> > >>>> "riding gain" to reduce background noise. Binary switching is just > >>>> a bad idea. > >>> > >>> I have no special understanding of this. I'm just asking probing > >>> questions in hopes that it will result in the right decisions being > >>> made and the right stuff specified. > >>> > >>>>> Of course if you are mapping independent audio captures onto > >>>>> different speakers then they are being implicitly mixed. > >>>> > >>>> Not a useful way to think about it, IMHO. Human ears and > >>>> brains can sort out individual sources if there are enough > >>>> speakers, while mixing makes that harder. > >>> > >>> I have had the impression that "simple" clue telepresence rooms > >>> would be hoping to do direct mapping of captures to devices. If the > >>> assumption is that this will be an unsatisfactory approach and all > >>> endpoints should be prepared to do something more complex then it > >>> would be helpful to write that down somewhere - e.g. in the > >> framework. > >>> > >>> [Espen] Agree with Paul here, the basic scenario is well > understood. > >> A > >>> sends two logical audio captures and a receiver play them out with > >> the > >>> same spatial relationship. As rule of thumb here could be that for > >>> basic interoperability between vendors you assume pairs of audio > and > > >>> video captures that can be easily rendered on matching pairs of > >>> screens and speaker. > >>> > >>>>> - If you don't have speakers with similar spatial relationship to > >>>>> those of the audio captures, then you must decide whether to do > >>>>> sub-optimal assignments or mix. > >>>> > >>>> I suppose _some_ telepresence system will hide dozens of > >>>> speakers in the telepresence room and try to do this -- to me it > >>>> sounds like a dreadful idea, but it's quite possible the people > >>>> will > >> adapt. > >>>> > >>>> "Sub-optimal" really doesn't have a clear meaning here. Even > >>>> speakers in the "wrong" left-to-right order while you can see the > >>>> "correct" order on-screen won't confuse the listener as much as > >>>> speaker assignments changing for no obvious reason. > >>>> > >>>>> Again not clear if the mixed attribute helps with this. > >>>> > >>>> As an extreme example, you could always render "mixed" in > mono. > >>>> > >>>>> - If you have audio from more than one scene, what should you do > >>>>> with > >>> > >>>>> it? Should you mix, even though you have no spatial > relationships? > >>>> > >>>> IMHO, you should _invent_ a spatial relationship in that > case. > >>>> Even if each room invents a different spatial relationship, it > will > > >>>> prove less confusing. > >>>> > >>>>> Or should you switch based on active speaker? > >>>> > >>>> Only if background-noise is a serious problem. > >>>> > >>>>> What would help you to decide? > >>>> > >>>> It becomes quickly obvious to the listener! > >>>> > >>>>> The problems are superficially different for MCUs. But perhaps > >>>>> only superficially. It seems to me that when the MCU decides how > >>>>> to map its inputs into its advertisement, it has some virtual > room > > >>>>> layouts > >>> in mind. > >>>> > >>>> I would expect so. > >>>> > >>>>> So for each virtual room layout it is addressing the same issues > >>>>> as a > >>> > >>>>> real endpoint with that layout. But it does have the added > problem > > >>>>> of > >>> > >>>>> deciding how to describe what it is advertising - e.g. when to > >> apply > >>>>> the mixed/composed attributes. > >>>> > >>>> Pretty much always, unless it's feeding an exact copy of > what > >> it > >>>> receives. > >>> > >>> Since I've seen people here describe cases when that isn't so, it > >>> would be helpful to have a more precise definition. > >>> > >>>>> Some interesting use cases for all of the above would be very > >>> helpful. > >>>> > >>>> Did the cases I listed help? > >>> > >>> I think they need to be worked out in much more detail: > >>> > >>> - what equipment (input and output) is in each endpoint, and where. > >>> - what is advertised and how the input equipment is mapped to > >>> the advertisement > >>> - how each endpoint maps the advertised captures to its output > >> equipment > >>> together with how the info in the advertisement allowed it to > >>> determine that mapping. > >>> > >>> [Espen] Agree, being practical about what we will offer for actual > >>> endpoints are useful. > >>> > >>> > >>> Thanks, > >>> Paul > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From john@jlc.net Tue Apr 17 08:05:30 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4FB11E80B2 for ; Tue, 17 Apr 2012 08:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.833 X-Spam-Level: X-Spam-Status: No, score=-105.833 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MIbIY9e1-2b for ; Tue, 17 Apr 2012 08:05:29 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 01EA611E8080 for ; Tue, 17 Apr 2012 08:05:29 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6C6BE33C20; Tue, 17 Apr 2012 11:05:28 -0400 (EDT) Date: Tue, 17 Apr 2012 11:05:28 -0400 From: John Leslie To: Mary Barnes Message-ID: <20120417150528.GA33008@verdi> References: <205835231.1334003836566.JavaMail.nobody@jva2wl001.webex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: CLUE Subject: [clue] CLUE WG Design Team -- April 17 notes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 15:05:30 -0000 John Leslie, Paul Kyzivat, Brian Baldino, Jonathan, Mark Duckworth, Marshall Eubanks, Rob Hansen, Spencer 1004 Paul: Don't know whether there's convergence on the Interim date Spencer: acting as if the RTCweb date is nailed Marshall: Mary was trying to get them to move... Paul: don't know if Mary intended to meet today Spencer: I'll try to find her on jabber Paul: Christer is starting work on a data model Spencer: Mary will join shortly 1012 Mary joined "Tax Day" discussion Paul: timing questions maybe... Paul put up email from Marshall re timing Mary: better not to try to shoehorn to another group's definitions Marshall: a few hundred milliseconds is typically acceptable (seconds are not); RTT likely to be hundreds of milliseconds. Rob: agree with the numbers... implications of switching Marshall: what about showing name of the speaker Rob: not at frame level -- only things vital to rendering belong at frame level -- things you can't fix later Marshall: are we going to have to set up our own "clue" channel? Rob: we concluded we won't do "everything" in SDP Marshall: separate logical from transport Rob: several RTTs, Jonathan: small number of seconds Marshall: will CLUE have border controllers Jonathan: satellite uplink? Mary: Christen working on data model -- how fast things change, requirements... do we agree on three time-scales of interest? (general agreement) Paul: Marshall proposed mechanisms for three time-frames, whether data fits is a separable question, maybe doesn't fit in any bucket -- we may send several-second stuff in a CLUE 200-msec channel because of its size Marshall: is there a possibility we might have gigabyte-size messages? (do we need a background priority Jonathan?: roster for huge conferences could be large 1032 Paul: question whether we have enough data to drive recipient decision Jonathan: perhaps I haven't thought about it as much as Paul Paul: between abstract and concrete -- think it would help to sort out use cases in more details, equipment used Marshall: three images on two screens, e.g. Paul: answers I'm hearing, pick an entry which fits your configuration; we could e.g. require a one-screen redering be sent Mark: are you talking about issue #8? Paul: talking about two different problem... in one scene, there may not be any rows that match your need... if you need to throw something out, e.g. two screens available for three-screen offering Mark: what do you think might be able to solve that? Rob: three-screen system could offer switched version on two screens, or receiver could do the switching Paul: wasn't clear during mixed/switched discussion that recipient has enough inforation... if you send both a composed and a switched, do I have the information to choose... if I knew one was previous speaker... Marshall: to me, I wouldn't flip current-speaker/previous-speaker on-screen Paul: provider might offer both a switched-current-speaker and a switched-previous-speaker, I could choose Rob: algorithm could offer current-loudest-speaker and current-N... sender sends the one you ask for... you can subscribe to part of a capture set Paul: might have one entry with three capture, another with two... I could take all the capture in that entry Rob: my understanding is you can ask for individual captures in an entry Mark: receiver may be incapable of receiving all, you can ask for just one or two Paul: in effect, captures in an entry will map to mlines? ... when I select particular captures from particular capture scenes ... I have to pick which I want to receive ... the advertisement specified what they are, such as left-middle-right Rob: in the switched case, you could ask for "up-to-two"... Paul: I think this is what's too fuzzy... do I know what I'm choosing Rob: algorithm might be anything, e.g. three loudest Marshall: sounds like a middleware issue, does the middleware have the info? does it relay it back to the sender? Paul: could make it easier by pushing back on provider -- it should provide sets for any number of screens up to its maximum Rob: examples that do one-screen and three-screen, but not two Marshall: we could assumed they were in order of importance Paul: from cameras raw, you have good coordinates, if switched, not... coordinates not meaningful for presentation... if coordinate system different, needs to be in different scene Marshal: do we have a mechanism to say "must show this screen" Jonathan: what is the or-else? drop the call? Paul: could define a priority Marshall: should we allow priorities to be set Jonathan: but who sets the priorities?... I've tried to avoid defining things where it's not clear how they're set Marshall: example IETF WG meeting... maybe we need to write down use cases 1059 Mary: we have use-cases, but they're often insufficiently detailed, we don't have any how-to-use these use-cases documents Marshall: perhaps start with use-cases that are "special"... bottom-up Paul: think we can start with use-cases we have, and elaborate on them... equipment at each end, e.g. Mary: somebody need to take an action-item to elaborate one use-case Paul: I will do that 1102 adjourn -- John Leslie From pkyzivat@alum.mit.edu Tue Apr 17 11:45:00 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB0111E80A1 for ; Tue, 17 Apr 2012 11:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJVklElodaof for ; Tue, 17 Apr 2012 11:44:56 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8211E80A0 for ; Tue, 17 Apr 2012 11:44:55 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id z6RU1i0040vyq2s516kwPF; Tue, 17 Apr 2012 18:44:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta05.westchester.pa.mail.comcast.net with comcast id z6kv1i00z07duvL3R6kvbi; Tue, 17 Apr 2012 18:44:55 +0000 Message-ID: <4F8DBA26.8010705@alum.mit.edu> Date: Tue, 17 Apr 2012 14:44:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Roni Even References: <4F846AE0.4010700@alum.mit.edu><20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com><4F873CCE.3020806@alum.mit.edu><4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> <4f8d7ccb.2266b40a.1ceb.fffffc00@mx.google.com> In-Reply-To: <4f8d7ccb.2266b40a.1ceb.fffffc00@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'CLUE' Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 18:45:00 -0000 Hi Roni, On 4/17/12 10:21 AM, Roni Even wrote: > Hi, > My view is that in this case the provider can advertise the three fixed > captures and one with switched which may be the active speaker. Do you mean one capture scene entry containing all four of these captures? Or do you mean one capture scene entry with the three fixed captures, and another one containing just the switched capture? > We will need > a way to let the consumer know who is the current speaker enabling him to > choose the switched active speaker stream and one of the fixed streams which > may be the previous speaker. So in that case the consumer would receive all four captures, and render the switched capture plus dynamically select one of the others to render? If so, how is that any easier than simply receiving the three fixed captures and making its own decision about which two to render based on tracking speakers? That would have the benefit of requiring one less stream to be received. But it would still require receiving more streams than if it could select two offered by the provider that provide a good experience for a two screen system. Thanks, Paul > Roni > >> -----Original Message----- >> From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] >> Sent: Tuesday, April 17, 2012 2:19 AM >> To: Paul Kyzivat; Roni Even >> Cc: CLUE >> Subject: RE: [clue] Does framework provide sufficient info for >> receiver? >> >> Hey Paul, with regards to this bit: >> >> "For instance, suppose the sender does something to combine some of its >> captures so that it can advertise a capture scene entry that requires >> fewer displays. E.g. suppose it has three main captures of participants >> and one presentation capture. And suppose in addition to advertising >> all of those as one entry, it also advertises another entry for a >> three-screen room, consisting of one capture for the presentation, one >> for the current speaker, and one for the prior speaker. So that is one >> fixed and two switched captures. If the recipient need to map this to >> two displays, how does it decide what to do? The obvious thing would be >> to omit the capture for the prior speaker. But how would it know which >> one that is." >> >> My understanding was more that the provider would advertise all valid >> views with a capture entry for each, not require (or rely on) an >> endpoint to be able to "find" a valid view which is a subset of one >> that was actually advertised; therefore relieving the consumer of that >> responsibility. So in this case, the provider would advertise entries >> that contained: >> 1) Just the active speaker >> 2) The active speaker and previous active speaker >> 3) The active speaker, previous active speaker and presentation (Maybe >> even a 4th that contained the active speaker and presentation) >> >> The idea being that the provider is smart enough to know/advertise its >> valid views rather than rely on the consumer to figure them out. >> >> Even with this there are still situations where no advertised view is >> ideal for the consumer, maybe this is the situation you're referring >> to? >> I'd hoped that the consumer could get away with choosing the "next best >> fit" using information already in the advertisement (how many captures >> an entry consists of, switched vs. non-switched, area of capture info, >> etc.) >> >> -Brian >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Monday, April 16, 2012 7:35 AM >> To: Roni Even >> Cc: 'CLUE' >> Subject: Re: [clue] Does framework provide sufficient info for >> receiver? >> >> Hi Roni, >> >> On 4/15/12 11:20 AM, Roni Even wrote: >>> Hi Paul, >>> I think that there is enough information that will allow a receiver >> to >> >>> select N out of M streams. >>> The receiver will know the semantics of the streams (people or >>> presentation) and the spatial information of the room and the >> different streams. >>> My view is that this is enough for the general telepresence point to >>> point use case. >> >> I think I agree for the case where there is a single scene advertised, >> and all the captures represent single cameras. >> >> But as soon as you add in mixed or switched captures it becomes far >> less clear. >> >> For instance, suppose the sender does something to combine some of its >> captures so that it can advertise a capture scene entry that requires >> fewer displays. E.g. suppose it has three main captures of participants >> and one presentation capture. And suppose in addition to advertising >> all of those as one entry, it also advertises another entry for a >> three-screen room, consisting of one capture for the presentation, one >> for the current speaker, and one for the prior speaker. So that is one >> fixed and two switched captures. If the recipient need to map this to >> two displays, how does it decide what to do? The obvious thing would be >> to omit the capture for the prior speaker. But how would it know which >> one that is. >> >>> As for multipoint use case, this is why I think it is important to >>> know if the advertisement is based on site switch or segment switch >>> which will provide the extra information needed for the selection >>> (spatial information provides the internal relation between the >>> capture) and I think that the audio level will help with knowing who >>> are the active speakers in this case >> >> I think there are too many unknowns in the above to discuss it with >> clarity. We need some use cases. >> >> Thanks, >> Paul >> >>> Roni >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat >>>> Sent: Thursday, April 12, 2012 11:37 PM >>>> To: Espen Berger (espeberg) >>>> Cc: CLUE >>>> Subject: Re: [clue] Does framework provide sufficient info for >>>> receiver? >>>> >>>> Espen - comments inline. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: >>>>> During the CLUE design team meeting on webex yesterday we started >> to >> >>>>> discuss various use cases and if they are in scope or not for the >>>>> current work in CLUE. >>>>> >>>>> As a part of my response to Pauls questions I summarized the use >>>> cases >>>>> and grouped them into supported / not supported. I can dive into >>>>> more detail about the use cases if people are interested? >>>>> >>>>> I would answer yes to the following use cases >>>>> * Telepresence point to point, where the reproduction will happen >> in >>>> a >>>>> 2D-plane for audio and video. Currently CLUE support announcing >>>>> capability of sending 1 - N capture (left to right) and a receiver >>>> can >>>>> request 1 - M streams for rendering (left to tight), which is the >>>>> basic for interoperability. >>>> >>>> In this case, suppose N> M. Who is responsible for deciding which M >>>> of the N streams will be used? AFAIK the recipient just picks the >>>> ones it wants. So then my question remains - does the recipient have >>>> sufficient info to select the "right" ones? (There isn't any >>>> guarantee that *any* N of the M streams will provide a reasonable >> rendering. >>>> >>>> This would be improved if we had a mechanism for the recipient to >>>> state "I can only handle N streams" and the sender was obligated to >>>> meet that constraint. I don't think we have said that. >>>> >>>>> * Transcoded conferencing, where the MCU act like an endpoint and >>>>> logically announces audio and video left to right and a receiver >>>>> request >>>>> 1 - M captures depending on how many screen and audio streams you >>>>> prefer. Typically a single video stream pr. screen and one audio >> pr. >>>>> screen (mono/stereo). Excluded is capabilities to select individual >>>>> speakers, the MCU is free to optimize what to compose and send to a >>>>> receiver. >>>> >>>> This is logically equivalent to the prior case. >>>> >>>>> * Generic multi source, sending and receiving named sources where >>>>> the user experience is controlled by an human being capable of >>>>> reading sources names, or control software written explicit to >>>>> operate on the named streams. The content attribute can be used to >>>>> indicate a >>>> primary >>>>> role, RFC4796 uses 'main' and 'alt'. >>>> >>>> Are you talking about the text names/labels we were discussing on >> the >> >>>> last call? >>>> >>>> If so, I agree that if the senders provide well conceived labels >> then >> >>>> a human can probably decide something reasonable. >>>> >>>> If the human is working only with "content" attributes, then its not >>>> so clear. Its quite possible that the recipient will find itself >>>> trying to choose between multiple streams with the same content >> type. >> >>>> (E.g. all >>>> 'main'.) >>>> >>>>> I would answer no, to the following use cases >>>>> * Switched conferencing, where we assume that endpoints do scalable >>>>> video (either SVC or Simulcast), locally composited layout and >> audio >> >>>>> mixing. Limited work has been done on how to use Scalable video and >>>>> how to build mechanisms for complete composited layouts. >>>>> * Advanced audio reproduction, a group of audio scenarios mentioned >>>> by >>>>> Jon Leslie and Johan Nielsen that requires more details during >>>> initial >>>>> signalling and more dynamic information for transferring dynamic >>>>> meta-information. >>>>> * Multi view, as described in the CLUE use case document. >>>>> >>>>> (Other comments inline.) >>>>> >>>>> Cheers >>>>> >>>>> -Espen >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >> >>>>> Of Paul Kyzivat >>>>> Sent: 11. april 2012 17:06 >>>>> To: John Leslie >>>>> Cc: CLUE >>>>> Subject: Re: [clue] Does framework provide sufficient info for >>>> receiver? >>>>> >>>>> Hi John, >>>>> >>>>> Thanks for the comments. I've followed up inline. >>>>> >>>>> On 4/10/12 5:09 PM, John Leslie wrote: >>>>>> Paul Kyzivat wrote: >>>>>>> >>>>>>> The fundamental problem in the scope of CLUE is, if you are an >>>>>>> endpoint, and you have received an advertisement, with some >> scenes >> >>>>>>> and captures, do you have sufficient information to select and >> map >> >>>>>>> the advertised scenes/captures onto the equipment you have? >>>>>> >>>>>> Of course not! >>>>>> >>>>>> If we wanted that, we'd have to include for every composed >>>> scene >>>>>> what it's composed from, and for every mixed audio what it's mixed >>>>>> from. >>>>> >>>>> I think you must have misunderstood me. Otherwise I wouldn't expect >>>>> you to answer "Of course not". AFAIK the whole point of CLUE is to >>>>> provide the information to make this possible. >>>>> >>>>> My point in asking the question was so that we can identify what >>>>> information we have overlooked that we need to include one way or >>>>> another. >>>>> >>>>> Clearly there are some tradeoffs. More information might support >>>>> *better* mappings. So one thing to decide is how good is good >> enough. >>>>> [Espen] Agree with Paul, we clearly can support in CLUE the use >>>>> cases where a Telepresence room either offer a 1, 2 or 3 video >>>>> captures, which can be rendered on 1, 2 or 3 screens. >>>> >>>> I think its clear we can support cases where every advertisement >> that >> >>>> includes an entry for N (>1) captures also includes an entry with >>>> only one capture, and optionally entries containing other numbers of >>>> captures between 1 and N. >>>> >>>> But as I mention above, its not clear we have supported case where >>>> the minimal entry in the advertisement is for N>1 captures. >>>> >>>>>>> If you have sufficient equipment (displays, speakers) with >>>>>>> compatible >>>>> >>>>>>> geometry to directly map all of the captures from one audio and >>>>>>> one video capture scene entry from each capture scene then maybe >>>>>>> all is good. In this case ISTM that the mixed/composed attributes >>>>>>> aren't needed. >>>>>> >>>>>> It's unlikely that the "typical" telepresence conference >> will >> >>>>>> have >>>>> >>>>>> a separate screen for every possible video. >>>>> >>>>> That isn't what I said. Consider what is perhaps a typical case, >>>> where >>>>> the advertisement contains one scene with several alternative video >>>>> and audio scene entries. Lets just consider the video. Then maybe >>>>> there is one entry with three captures, and another with one >>>>> (mixed/switched, >>>>> whatever) capture. Then if you have three screens you can map all >>>>> three captures in the first entry. If you have less than three >>>> screens >>>>> then you can map the one capture from the 2nd entry onto one of >> your >>>> screens. >>>>> >>>>> But what if there was no entry with a single capture? If you had >> two >> >>>>> screens, would you have enough info about the three captures in the >>>>> first entry to make a reasonable mapping onto your two screens? >> What >> >>>>> information would we need to include in the advertisement so that >> it >> >>>>> would be possible to do this mapping well? >>>>> >>>>> [Espen] How a vendor build a room or endpoint is transparent from >>>>> the sender of media. As a sender you should not care if a room >>>>> request 3 audio streams (left, center, right) and choose to mix and >>>>> play out on a single speaker. We can argue that this is not the >> best >> >>>>> experience, but still valid and typically done for PC-clients or >>>>> other endpoints with a single speaker. >>>> >>>> Again, I think you are assuming the receiver can specify the max >>>> number of streams it can handle, and that the sender will then be >>>> obligated to select/construct a suitable set of streams. AFAIK we >>>> have not written down anything that calls for that. (If I am wrong, >>>> please let me know where this is specified.) >>>> >>>> We have the (largely hypothetical) recipient capabilities message, >>>> but its content hasn't been specified yet, and AFAIK there has been >>>> no statement that it is binding and the construction of the >> advertisement. >>>> >>>>>> Of course, the number of "capture scenes" _could_ be small >>>>>> enough to give each it's own video monitor -- but I don't think >>>>>> that's the general case we should design for. >>>>> >>>>> IIUC an endpoint will typically only advertise one or two scenes. >>>>> One would correspond to the cameras and mics in its room. The >> other, >> >>>>> if present, would correspond to a "presentation" that doesn't fit >>>>> into the coordinate space of the room. There are cases for more, >> but >> >>>>> they get more obscure. >>>>> >>>>> So for a point-to-point clue call the recipient will only need to >>>>> map one or two scenes. But when there is more than one it is more >>>> complex, >>>>> requiring sharing of equipment. >>>>> >>>>> The situation is more complex for an MCU. It will have as input all >>>>> the scenes offered by all the endpoints. It then has to decide what >>>> to >>>>> offer out to the endpoints. It could just pass through all the >>>>> scenes it receives from all the endpoints, leaving the mapping >>>>> problem entirely to the endpoints. (I don't think that is what most >>>>> people have in mind, though some might.) >>>>> >>>>> Or it could take on itself the job of mapping/mixing/switching all >>>>> of those inputs and producing something more like what a typical >>>> endpoint >>>>> would advertise - one or two scenes each with just a few captures. >>>>> >>>>> Or it could do both - advertise its own simplified composite scenes >>>>> and also all those provided by the endpoints. That would allow the >>>>> endpoints to either take the easy way out, or else do it all >>>>> themselves in a way that suits them. Suppose it did this. Would the >>>>> endpoints that want to take the easy way be able to figure out >> which >> >>>>> scenes and captures to use? >>>>> >>>>> [Espen] This sounds closer to a user experience discussions than a >>>>> protocol discussion. >>>> >>>> Perhaps it is. But the point of CLUE is to develop a protocol that >>>> enables an especially good user experience. While we shouldn't >>>> mandate the user experience, I think we are obligated to do due >>>> diligence that the protocol is sufficient to enable that user >> experience. >>>> >>>>>> OTOH, with an appropriate "surround-sound" system, you can >>>> "place" >>>>>> an arbitrarily large number of audio streams, yet make them easy >> to >> >>>>>> distinguish. >>>>>> >>>>>>> If you don't have sufficient equipment to do that, then the job >> is >> >>>>>>> harder, and more information is needed to figure out what to do. >>>>>> >>>>>> Only marginally harder... >>>>>> >>>>>>> For instance: >>>>>>> >>>>>>> - If you don't have suitable displays, then perhaps you can >> select >>>> a >>>>>>> video capture scene entry and locally compose or switch some of >>>>>>> the captures in order to produce a set of captures that does map >>>>>>> to the available displays. The area of capture of each capture >>>>>>> could be helpful to doing this, and perhaps the composed >> attribute >> as well. >>>>>> >>>>>> One inevitable use case is filing your formal report from >> the >>>>> airport. >>>>>> The person doing so will have lousy audio, vastly inadequate >> video, >> >>>>>> and typically inadequate bandwidth with excessive latency. S/he >>>>>> will need some middlebox to compose a "barely-adequate video" and >>>>>> mono >>>>> audio. >>>>> >>>>> This is indeed an interesting case - one we have explicitly put in >>>>> scope. If an MCU is already in the call then perhaps we can hope >>>>> that is one of the entries it makes available. >>>>> >>>>> If there isn't any MCU in the call, then the other endpoint might >>>>> not advertise that option. Then what? Do we have a mechanism for >> that? >>>>> [Espen] If an MCU detect low bandwidth or packet loss it can start >>>>> using its normal recovery mechanisms. That could lower bitrate for >>>>> audio and video (maybe by a SIP re-invite), change the CLUE offer >> to >> >>>>> something that fits inside the available bandwidth. Getting good >>>>> quality audio ande video is always a challenge, with or without >> clue. >>>>> >>>>>> Then there's the use case of filing you formal report from >>>>>> your home office (when you're sick or somebody doesn't want to pay >>>>>> travel >>>>> cost). >>>>>> You may well have surround-sound and two or three large monitors, >>>>>> 20 Mbps download with 40 msec RTT, and a decent-quality lavalier >> mike. >>>>>> You still probably want some middlebox to compose your basic >> video, >> >>>>>> but you can take individual streams as well to concentrate on >>>>> particular people. >>>>>> >>>>>> Near the top end are the corporate telepresence rooms. They >>>> will >>>>>> want all streams, and are likely to have a human being mixing >> them. >>>>> >>>>> I don't understand your point "are likely to have a human being >>>> mixing >>>>> them". Can you explain further? >>>>> [Espen] I see this as mostly a request for focusing in on >> particular >> >>>>> user. In a transcoded conference you can do that by looking into >>>> XCon, >>>>> if you do switched conference the endpoint typically render the >>>> layout >>>>> and can choose who to focus on. Mixing transcoded and switched >>>>> conferencing I think makes it unnecessary complex for the initial >>>>> use cases to cover. >>>>> >>>>>>> - or rather than compose to fit your displays, you could >> switch... >>>>>> >>>>>> Folks _will_ do that -- I can't stop them. But I find it >>>>> uninteresting. >>>>> >>>>> ??? We have been talking about switching a lot. Are you saying that >>>> is >>>>> uninteresting? >>>>> >>>>> If it makes sense for a middlebox to switch, doesn't it make equal >>>>> sense for an endpoint to do so? >>>>> >>>>>>> - handling video from multiple scenes probably presents some >> added >> >>>>>>> issues. By definition there is no specified spatial relationship >>>>>>> between the captures of different scenes... >>>>>> >>>>>> Nonetheless, the participants will want to imagine such a >>>>> relationship. >>>>> >>>>> ISTM that this needs further discussion. >>>>> >>>>>>> - If you don't have sufficient speakers for all of the audio >>>>>>> captures, then you have to decide to mix, switch, or drop some. >>>>>> >>>>>> There really isn't any such thing as "sufficient speakers", >>>>>> but surround-sound should be considered "sufficient". You can >>>>>> always mix to stereo or even mono: "you pays your money and you >>>>>> takes your >>>>> choice". >>>>> >>>>> Do we have enough information to do it "right" or "well"? >>>>> Right now the coordinate info is all optional. Does it need to be >>>>> mandatory in order to enable this? >>>>> >>>>>>> The spatial information from the captures may help in deciding >> how >> >>>>>>> to >>>>> >>>>>>> mix. >>>>>> >>>>>> Absolutely! >>>>>> >>>>>>> Not evident that the mixed attribute helps with this >>>>>> >>>>>> It help you know when mixing is less likely to work well. >>>>>> >>>>>>> - unless it is used to decide to switch rather than mix. >>>>>> >>>>>> I'm not sure there is any such thing. "Mixing" frequently >>>>>> includes >>>>> >>>>>> "riding gain" to reduce background noise. Binary switching is just >>>>>> a bad idea. >>>>> >>>>> I have no special understanding of this. I'm just asking probing >>>>> questions in hopes that it will result in the right decisions being >>>>> made and the right stuff specified. >>>>> >>>>>>> Of course if you are mapping independent audio captures onto >>>>>>> different speakers then they are being implicitly mixed. >>>>>> >>>>>> Not a useful way to think about it, IMHO. Human ears and >>>>>> brains can sort out individual sources if there are enough >>>>>> speakers, while mixing makes that harder. >>>>> >>>>> I have had the impression that "simple" clue telepresence rooms >>>>> would be hoping to do direct mapping of captures to devices. If the >>>>> assumption is that this will be an unsatisfactory approach and all >>>>> endpoints should be prepared to do something more complex then it >>>>> would be helpful to write that down somewhere - e.g. in the >>>> framework. >>>>> >>>>> [Espen] Agree with Paul here, the basic scenario is well >> understood. >>>> A >>>>> sends two logical audio captures and a receiver play them out with >>>> the >>>>> same spatial relationship. As rule of thumb here could be that for >>>>> basic interoperability between vendors you assume pairs of audio >> and >> >>>>> video captures that can be easily rendered on matching pairs of >>>>> screens and speaker. >>>>> >>>>>>> - If you don't have speakers with similar spatial relationship to >>>>>>> those of the audio captures, then you must decide whether to do >>>>>>> sub-optimal assignments or mix. >>>>>> >>>>>> I suppose _some_ telepresence system will hide dozens of >>>>>> speakers in the telepresence room and try to do this -- to me it >>>>>> sounds like a dreadful idea, but it's quite possible the people >>>>>> will >>>> adapt. >>>>>> >>>>>> "Sub-optimal" really doesn't have a clear meaning here. Even >>>>>> speakers in the "wrong" left-to-right order while you can see the >>>>>> "correct" order on-screen won't confuse the listener as much as >>>>>> speaker assignments changing for no obvious reason. >>>>>> >>>>>>> Again not clear if the mixed attribute helps with this. >>>>>> >>>>>> As an extreme example, you could always render "mixed" in >> mono. >>>>>> >>>>>>> - If you have audio from more than one scene, what should you do >>>>>>> with >>>>> >>>>>>> it? Should you mix, even though you have no spatial >> relationships? >>>>>> >>>>>> IMHO, you should _invent_ a spatial relationship in that >> case. >>>>>> Even if each room invents a different spatial relationship, it >> will >> >>>>>> prove less confusing. >>>>>> >>>>>>> Or should you switch based on active speaker? >>>>>> >>>>>> Only if background-noise is a serious problem. >>>>>> >>>>>>> What would help you to decide? >>>>>> >>>>>> It becomes quickly obvious to the listener! >>>>>> >>>>>>> The problems are superficially different for MCUs. But perhaps >>>>>>> only superficially. It seems to me that when the MCU decides how >>>>>>> to map its inputs into its advertisement, it has some virtual >> room >> >>>>>>> layouts >>>>> in mind. >>>>>> >>>>>> I would expect so. >>>>>> >>>>>>> So for each virtual room layout it is addressing the same issues >>>>>>> as a >>>>> >>>>>>> real endpoint with that layout. But it does have the added >> problem >> >>>>>>> of >>>>> >>>>>>> deciding how to describe what it is advertising - e.g. when to >>>> apply >>>>>>> the mixed/composed attributes. >>>>>> >>>>>> Pretty much always, unless it's feeding an exact copy of >> what >>>> it >>>>>> receives. >>>>> >>>>> Since I've seen people here describe cases when that isn't so, it >>>>> would be helpful to have a more precise definition. >>>>> >>>>>>> Some interesting use cases for all of the above would be very >>>>> helpful. >>>>>> >>>>>> Did the cases I listed help? >>>>> >>>>> I think they need to be worked out in much more detail: >>>>> >>>>> - what equipment (input and output) is in each endpoint, and where. >>>>> - what is advertised and how the input equipment is mapped to >>>>> the advertisement >>>>> - how each endpoint maps the advertised captures to its output >>>> equipment >>>>> together with how the info in the advertisement allowed it to >>>>> determine that mapping. >>>>> >>>>> [Espen] Agree, being practical about what we will offer for actual >>>>> endpoints are useful. >>>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From mary.ietf.barnes@gmail.com Tue Apr 17 11:54:54 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B900A11E80B0 for ; Tue, 17 Apr 2012 11:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.609 X-Spam-Level: X-Spam-Status: No, score=-103.609 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04aBRGX3ZGY7 for ; Tue, 17 Apr 2012 11:54:50 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3C411E80A0 for ; Tue, 17 Apr 2012 11:54:50 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5134575vbb.31 for ; Tue, 17 Apr 2012 11:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ozFNx2Qv4GQmpNCdgBK9LDsYsheql3R00AN1cwwyb1A=; b=V3LdfSD5ZLSAHT59oarmS5/k2CU2J1Ag21+vtzaWt7pao7gdvlydP5ePDM7KsnfE6f 64WwbpYflyx8rEnMs4Y1RW4clYHKiMRgacPqCCGUA3LSfpbP2pJuj4U/Mn4YGh8MF7D7 9BjluRp8dBPaG3v13z+f6E+Rf1NSnsF8onwGiKWnfqmmIAlRDE0/FL1Wl64Xzt4YJkJR t0brReVmRMnXSB+ROiTA1zxwpl9eQQGZbDOi3NxEYEPbqbEQ63ofZ5GWwf37ls27nMA/ +Ii667KvstOL9AKyCg2kfM+IWbdRrwkjs5TlHOAsq2LO+xLluDHM4xRjuwZ4AHmkUdUi pjig== MIME-Version: 1.0 Received: by 10.220.58.197 with SMTP id i5mr8709743vch.38.1334688890111; Tue, 17 Apr 2012 11:54:50 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Tue, 17 Apr 2012 11:54:50 -0700 (PDT) Date: Tue, 17 Apr 2012 13:54:50 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=0023544477cd2e45fa04bde47935 Subject: [clue] Updated Design Team wiki X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 18:54:54 -0000 --0023544477cd2e45fa04bde47935 Content-Type: text/plain; charset=ISO-8859-1 Hi all, We have uploaded all the meetings minutes thus far to the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team Note, that the Webex logistics are available there, as well, so you might find it handy to bookmark that page. Regards, Mary CLUE WG co-chair --0023544477cd2e45fa04bde47935 Content-Type: text/html; charset=ISO-8859-1 Hi all,

We have uploaded all the meetings minutes thus far to the CLUE WG wiki:

Note, that the Webex logistics are available there, as well, so you might find it handy to bookmark that page.

Regards,
Mary
CLUE WG co-chair
--0023544477cd2e45fa04bde47935-- From marshall.eubanks@gmail.com Tue Apr 17 12:43:08 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1583221F8455 for ; Tue, 17 Apr 2012 12:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS4lGKv1h96e for ; Tue, 17 Apr 2012 12:43:03 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8F321F8459 for ; Tue, 17 Apr 2012 12:43:02 -0700 (PDT) Received: by lagj5 with SMTP id j5so5519661lag.31 for ; Tue, 17 Apr 2012 12:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zMljz2lxKUJjjbmZ7GGALJD0n24r/ujFnvSEnuZQjwE=; b=TrNPaLMzCOpMAjgqfpXFmCvUbXP/4wpGbaJ/A/lGYRsK5k7ro9SVyyk1nERrsMss1N S9vNIkFP8J6qOy8rkReV6KPFnyP/MSrmsuEC6v4vSQkM3YiOTJgEUkEGucEiEIuLEkv4 PY8DnuyG0Nxi4nEP/asPmOMonbgjKvDXqMP2a88JvxW6EBsEqtgnlpCg72w1GkM4ekJT sLbB6iHVjYKnASjWnl38rfnW/23UkoQCtqP02LHLzZqkJSInuZa+XrV7mX5jGnLLb4pS aZMCf5py6bIsS2sbmHCuVgKNJriPc6fvqYpfKaY4xs5lMuXmgC2Uj5baYGPQJEAazSxZ Q9XA== MIME-Version: 1.0 Received: by 10.112.100.8 with SMTP id eu8mr7935649lbb.16.1334691781949; Tue, 17 Apr 2012 12:43:01 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Tue, 17 Apr 2012 12:43:01 -0700 (PDT) In-Reply-To: <4F8CAC7F.7040405@alum.mit.edu> References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> <4F8CAC7F.7040405@alum.mit.edu> Date: Tue, 17 Apr 2012 15:43:01 -0400 Message-ID: From: Marshall Eubanks To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:43:08 -0000 Thinking about our discussion today, I do NOT think that we can just push this entirely on the sender, and just say "I want N screens, please send the appropriate set." I see two general problems : - as screens are composited information much be carried along, and the compositor will inevitably be making its own decisions about what to carry, in what form, etc. - some such decisions and serving must come from middleware (i.e., MCU or servers in the network). How will they know what to do without getting information from upstream? And, if they get it, why can't such information go directly to receivers at the edge ? Regards Marshall On Mon, Apr 16, 2012 at 7:34 PM, Paul Kyzivat wrote= : > On 4/16/12 7:19 PM, Brian Baldino (bbaldino) wrote: >> >> Hey Paul, with regards to this bit: >> >> "For instance, suppose the sender does something to combine some of its >> captures so that it can advertise a capture scene entry that requires >> fewer displays. E.g. suppose it has three main captures of participants >> and one presentation capture. And suppose in addition to advertising all >> of those as one entry, it also advertises another entry for a >> three-screen room, consisting of one capture for the presentation, one >> for the current speaker, and one for the prior speaker. So that is one >> fixed and two switched captures. If the recipient need to map this to >> two displays, how does it decide what to do? The obvious thing would be >> to omit the capture for the prior speaker. But how would it know which >> one that is." >> >> My understanding was more that the provider would advertise all valid >> views with a capture entry for each, not require (or rely on) an >> endpoint to be able to "find" a valid view which is a subset of one that >> was actually advertised; therefore relieving the consumer of that >> responsibility. =A0So in this case, the provider would advertise entries >> that contained: >> 1) Just the active speaker >> 2) The active speaker and previous active speaker >> 3) The active speaker, previous active speaker and presentation >> (Maybe even a 4th that contained the active speaker and presentation) >> >> The idea being that the provider is smart enough to know/advertise its >> valid views rather than rely on the consumer to figure them out. >> >> Even with this there are still situations where no advertised view is >> ideal for the consumer, maybe this is the situation you're referring to? >> I'd hoped that the consumer could get away with choosing the "next best >> fit" using information already in the advertisement (how many captures >> an entry consists of, switched vs. non-switched, area of capture info, >> etc.) > > > What you describe certainly seems possible, within limits. > As you add more "raw" captures, the number of possibilities goes up > combinatorially. I would think there would be a temptation to just offer = the > entries you think will be popular. (E.g. the ones supported by room > configurations you sell, and perhaps not those sold by competitors.) > > If this is the solution, then perhaps we should have guidelines for the > sorts of advertisements that should be offered. > > As I mentioned somewhere, this gets harder when there is more than one sc= ene > in the advertisement, because the advertiser has no way to indicate how t= o > balance the entries in different captures. Perhaps that means that a > separate scene should not be used for presentations, even though there is= no > natural coordinate relationship between the presentation and the captures= of > participants. > > I'm just trying to see if we have common expectations in the group, that > those expectations are consistent with the requirements and use cases, an= d > that the support for those expectations is documented. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > >> -Brian >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Monday, April 16, 2012 7:35 AM >> To: Roni Even >> Cc: 'CLUE' >> Subject: Re: [clue] Does framework provide sufficient info for receiver? >> >> Hi Roni, >> >> On 4/15/12 11:20 AM, Roni Even wrote: >>> >>> Hi Paul, >>> I think that there is enough information that will allow a receiver to >> >> >>> select N out of M streams. >>> The receiver will know the semantics of the streams (people or >>> presentation) and the spatial information of the room and the >> >> different streams. >>> >>> My view is that this is enough for the general telepresence point to >>> point use case. >> >> >> I think I agree for the case where there is a single scene advertised, >> and all the captures represent single cameras. >> >> But as soon as you add in mixed or switched captures it becomes far less >> clear. >> >> For instance, suppose the sender does something to combine some of its >> captures so that it can advertise a capture scene entry that requires >> fewer displays. E.g. suppose it has three main captures of participants >> and one presentation capture. And suppose in addition to advertising all >> of those as one entry, it also advertises another entry for a >> three-screen room, consisting of one capture for the presentation, one >> for the current speaker, and one for the prior speaker. So that is one >> fixed and two switched captures. If the recipient need to map this to >> two displays, how does it decide what to do? The obvious thing would be >> to omit the capture for the prior speaker. But how would it know which >> one that is. >> >>> As for multipoint use case, this is why I think it is important to >>> know if the advertisement is based on site switch or segment switch >>> which will provide the extra information needed for the selection >>> (spatial information provides the internal relation between the >>> capture) and I think that the audio level will help with knowing who >>> are the active speakers in this case >> >> >> I think there are too many unknowns in the above to discuss it with >> clarity. We need some use cases. >> >> =A0 =A0 =A0 =A0Thanks, >> =A0 =A0 =A0 =A0Paul >> >>> Roni >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat >>>> Sent: Thursday, April 12, 2012 11:37 PM >>>> To: Espen Berger (espeberg) >>>> Cc: CLUE >>>> Subject: Re: [clue] Does framework provide sufficient info for >>>> receiver? >>>> >>>> Espen - comments inline. >>>> >>>> =A0 =A0 =A0 =A0Thanks, >>>> =A0 =A0 =A0 =A0Paul >>>> >>>> On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: >>>>> >>>>> During the CLUE design team meeting on webex yesterday we started to >> >> >>>>> discuss various use cases and if they are in scope or not for the >>>>> current work in CLUE. >>>>> >>>>> As a part of my response to Pauls questions I summarized the use >>>> >>>> cases >>>>> >>>>> and grouped them into supported / not supported. I can dive into >>>>> more detail about the use cases if people are interested? >>>>> >>>>> I would answer yes to the following use cases >>>>> * Telepresence point to point, where the reproduction will happen in >>>> >>>> a >>>>> >>>>> 2D-plane for audio and video. Currently CLUE support announcing >>>>> capability of sending 1 - N capture (left to right) and a receiver >>>> >>>> can >>>>> >>>>> request 1 - M streams for rendering (left to tight), which is the >>>>> basic for interoperability. >>>> >>>> >>>> In this case, suppose N> =A0 M. Who is responsible for deciding which = M >>>> of the N streams will be used? AFAIK the recipient just picks the >>>> ones it wants. So then my question remains - does the recipient have >>>> sufficient info to select the "right" ones? (There isn't any >>>> guarantee that *any* N of the M streams will provide a reasonable >> >> rendering. >>>> >>>> >>>> This would be improved if we had a mechanism for the recipient to >>>> state "I can only handle N streams" and the sender was obligated to >>>> meet that constraint. I don't think we have said that. >>>> >>>>> * Transcoded conferencing, where the MCU act like an endpoint and >>>>> logically announces audio and video left to right and a receiver >>>>> request >>>>> 1 - M captures depending on how many screen and audio streams you >>>>> prefer. Typically a single video stream pr. screen and one audio pr. >>>>> screen (mono/stereo). Excluded is capabilities to select individual >>>>> speakers, the MCU is free to optimize what to compose and send to a >>>>> receiver. >>>> >>>> >>>> This is logically equivalent to the prior case. >>>> >>>>> * Generic multi source, sending and receiving named sources where >>>>> the user experience is controlled by an human being capable of >>>>> reading sources names, or control software written explicit to >>>>> operate on the named streams. The content attribute can be used to >>>>> indicate a >>>> >>>> primary >>>>> >>>>> role, RFC4796 uses 'main' and 'alt'. >>>> >>>> >>>> Are you talking about the text names/labels we were discussing on the >> >> >>>> last call? >>>> >>>> If so, I agree that if the senders provide well conceived labels then >> >> >>>> a human can probably decide something reasonable. >>>> >>>> If the human is working only with "content" attributes, then its not >>>> so clear. Its quite possible that the recipient will find itself >>>> trying to choose between multiple streams with the same content type. >> >> >>>> (E.g. all >>>> 'main'.) >>>> >>>>> I would answer no, to the following use cases >>>>> * Switched conferencing, where we assume that endpoints do scalable >>>>> video (either SVC or Simulcast), locally composited layout and audio >> >> >>>>> mixing. Limited work has been done on how to use Scalable video and >>>>> how to build mechanisms for complete composited layouts. >>>>> * Advanced audio reproduction, a group of audio scenarios mentioned >>>> >>>> by >>>>> >>>>> Jon Leslie and Johan Nielsen that requires more details during >>>> >>>> initial >>>>> >>>>> signalling and more dynamic information for transferring dynamic >>>>> meta-information. >>>>> * Multi view, as described in the CLUE use case document. >>>>> >>>>> (Other comments inline.) >>>>> >>>>> Cheers >>>>> >>>>> -Espen >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> >> >>>>> Of Paul Kyzivat >>>>> Sent: 11. april 2012 17:06 >>>>> To: John Leslie >>>>> Cc: CLUE >>>>> Subject: Re: [clue] Does framework provide sufficient info for >>>> >>>> receiver? >>>>> >>>>> >>>>> Hi John, >>>>> >>>>> Thanks for the comments. I've followed up inline. >>>>> >>>>> On 4/10/12 5:09 PM, John Leslie wrote: >>>>>> >>>>>> Paul Kyzivat =A0 =A0 wrote: >>>>>>> >>>>>>> >>>>>>> The fundamental problem in the scope of CLUE is, if you are an >>>>>>> endpoint, and you have received an advertisement, with some scenes >> >> >>>>>>> and captures, do you have sufficient information to select and map >> >> >>>>>>> the advertised scenes/captures onto the equipment you have? >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 Of course not! >>>>>> >>>>>> =A0 =A0 =A0 If we wanted that, we'd have to include for every compos= ed >>>> >>>> scene >>>>>> >>>>>> what it's composed from, and for every mixed audio what it's mixed >>>>>> from. >>>>> >>>>> >>>>> I think you must have misunderstood me. Otherwise I wouldn't expect >>>>> you to answer "Of course not". AFAIK the whole point of CLUE is to >>>>> provide the information to make this possible. >>>>> >>>>> My point in asking the question was so that we can identify what >>>>> information we have overlooked that we need to include one way or >>>>> another. >>>>> >>>>> Clearly there are some tradeoffs. More information might support >>>>> *better* mappings. So one thing to decide is how good is good >> >> enough. >>>>> >>>>> [Espen] Agree with Paul, we clearly can support in CLUE the use >>>>> cases where a Telepresence room either offer a 1, 2 or 3 video >>>>> captures, which can be rendered on 1, 2 or 3 screens. >>>> >>>> >>>> I think its clear we can support cases where every advertisement that >> >> >>>> includes an entry for N (>1) captures also includes an entry with >>>> only one capture, and optionally entries containing other numbers of >>>> captures between 1 and N. >>>> >>>> But as I mention above, its not clear we have supported case where >>>> the minimal entry in the advertisement is for N>1 captures. >>>> >>>>>>> If you have sufficient equipment (displays, speakers) with >>>>>>> compatible >>>>> >>>>> >>>>>>> geometry to directly map all of the captures from one audio and >>>>>>> one video capture scene entry from each capture scene then maybe >>>>>>> all is good. In this case ISTM that the mixed/composed attributes >>>>>>> aren't needed. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 It's unlikely that the "typical" telepresence conference= will >> >> >>>>>> have >>>>> >>>>> >>>>>> a separate screen for every possible video. >>>>> >>>>> >>>>> That isn't what I said. Consider what is perhaps a typical case, >>>> >>>> where >>>>> >>>>> the advertisement contains one scene with several alternative video >>>>> and audio scene entries. Lets just consider the video. Then maybe >>>>> there is one entry with three captures, and another with one >>>>> (mixed/switched, >>>>> whatever) capture. Then if you have three screens you can map all >>>>> three captures in the first entry. If you have less than three >>>> >>>> screens >>>>> >>>>> then you can map the one capture from the 2nd entry onto one of your >>>> >>>> screens. >>>>> >>>>> >>>>> But what if there was no entry with a single capture? If you had two >> >> >>>>> screens, would you have enough info about the three captures in the >>>>> first entry to make a reasonable mapping onto your two screens? What >> >> >>>>> information would we need to include in the advertisement so that it >> >> >>>>> would be possible to do this mapping well? >>>>> >>>>> [Espen] How a vendor build a room or endpoint is transparent from >>>>> the sender of media. As a sender you should not care if a room >>>>> request 3 audio streams (left, center, right) and choose to mix and >>>>> play out on a single speaker. We can argue that this is not the best >> >> >>>>> experience, but still valid and typically done for PC-clients or >>>>> other endpoints with a single speaker. >>>> >>>> >>>> Again, I think you are assuming the receiver can specify the max >>>> number of streams it can handle, and that the sender will then be >>>> obligated to select/construct a suitable set of streams. AFAIK we >>>> have not written down anything that calls for that. (If I am wrong, >>>> please let me know where this is specified.) >>>> >>>> We have the (largely hypothetical) recipient capabilities message, >>>> but its content hasn't been specified yet, and AFAIK there has been >>>> no statement that it is binding and the construction of the >> >> advertisement. >>>> >>>> >>>>>> =A0 =A0 =A0 Of course, the number of "capture scenes" _could_ be sma= ll >>>>>> enough to give each it's own video monitor -- but I don't think >>>>>> that's the general case we should design for. >>>>> >>>>> >>>>> IIUC an endpoint will typically only advertise one or two scenes. >>>>> One would correspond to the cameras and mics in its room. The other, >> >> >>>>> if present, would correspond to a "presentation" that doesn't fit >>>>> into the coordinate space of the room. There are cases for more, but >> >> >>>>> they get more obscure. >>>>> >>>>> So for a point-to-point clue call the recipient will only need to >>>>> map one or two scenes. But when there is more than one it is more >>>> >>>> complex, >>>>> >>>>> requiring sharing of equipment. >>>>> >>>>> The situation is more complex for an MCU. It will have as input all >>>>> the scenes offered by all the endpoints. It then has to decide what >>>> >>>> to >>>>> >>>>> offer out to the endpoints. It could just pass through all the >>>>> scenes it receives from all the endpoints, leaving the mapping >>>>> problem entirely to the endpoints. (I don't think that is what most >>>>> people have in mind, though some might.) >>>>> >>>>> Or it could take on itself the job of mapping/mixing/switching all >>>>> of those inputs and producing something more like what a typical >>>> >>>> endpoint >>>>> >>>>> would advertise - one or two scenes each with just a few captures. >>>>> >>>>> Or it could do both - advertise its own simplified composite scenes >>>>> and also all those provided by the endpoints. That would allow the >>>>> endpoints to either take the easy way out, or else do it all >>>>> themselves in a way that suits them. Suppose it did this. Would the >>>>> endpoints that want to take the easy way be able to figure out which >> >> >>>>> scenes and captures to use? >>>>> >>>>> [Espen] This sounds closer to a user experience discussions than a >>>>> protocol discussion. >>>> >>>> >>>> Perhaps it is. But the point of CLUE is to develop a protocol that >>>> enables an especially good user experience. While we shouldn't >>>> mandate the user experience, I think we are obligated to do due >>>> diligence that the protocol is sufficient to enable that user >> >> experience. >>>> >>>> >>>>>> =A0 =A0 =A0 OTOH, with an appropriate "surround-sound" system, you c= an >>>> >>>> "place" >>>>>> >>>>>> an arbitrarily large number of audio streams, yet make them easy to >> >> >>>>>> distinguish. >>>>>> >>>>>>> If you don't have sufficient equipment to do that, then the job is >> >> >>>>>>> harder, and more information is needed to figure out what to do. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 Only marginally harder... >>>>>> >>>>>>> For instance: >>>>>>> >>>>>>> - If you don't have suitable displays, then perhaps you can select >>>> >>>> a >>>>>>> >>>>>>> video capture scene entry and locally compose or switch some of >>>>>>> the captures in order to produce a set of captures that does map >>>>>>> to the available displays. The area of capture of each capture >>>>>>> could be helpful to doing this, and perhaps the composed attribute >> >> as well. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 One inevitable use case is filing your formal report fro= m the >>>>> >>>>> airport. >>>>>> >>>>>> The person doing so will have lousy audio, vastly inadequate video, >> >> >>>>>> and typically inadequate bandwidth with excessive latency. S/he >>>>>> will need some middlebox to compose a "barely-adequate video" and >>>>>> mono >>>>> >>>>> audio. >>>>> >>>>> This is indeed an interesting case - one we have explicitly put in >>>>> scope. If an MCU is already in the call then perhaps we can hope >>>>> that is one of the entries it makes available. >>>>> >>>>> If there isn't any MCU in the call, then the other endpoint might >>>>> not advertise that option. Then what? Do we have a mechanism for >> >> that? >>>>> >>>>> [Espen] If an MCU detect low bandwidth or packet loss it can start >>>>> using its normal recovery mechanisms. That could lower bitrate for >>>>> audio and video (maybe by a SIP re-invite), change the CLUE offer to >> >> >>>>> something that fits inside the available bandwidth. Getting good >>>>> quality audio ande video is always a challenge, with or without >> >> clue. >>>>> >>>>> >>>>>> =A0 =A0 =A0 Then there's the use case of filing you formal report fr= om >>>>>> your home office (when you're sick or somebody doesn't want to pay >>>>>> travel >>>>> >>>>> cost). >>>>>> >>>>>> You may well have surround-sound and two or three large monitors, >>>>>> 20 Mbps download with 40 msec RTT, and a decent-quality lavalier >> >> mike. >>>>>> >>>>>> You still probably want some middlebox to compose your basic video, >> >> >>>>>> but you can take individual streams as well to concentrate on >>>>> >>>>> particular people. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 Near the top end are the corporate telepresence rooms. T= hey >>>> >>>> will >>>>>> >>>>>> want all streams, and are likely to have a human being mixing them. >>>>> >>>>> >>>>> I don't understand your point "are likely to have a human being >>>> >>>> mixing >>>>> >>>>> them". Can you explain further? >>>>> [Espen] I see this as mostly a request for focusing in on particular >> >> >>>>> user. In a transcoded conference you can do that by looking into >>>> >>>> XCon, >>>>> >>>>> if you do switched conference the endpoint typically render the >>>> >>>> layout >>>>> >>>>> and can choose who to focus on. =A0Mixing transcoded and switched >>>>> conferencing I think makes it unnecessary complex for the initial >>>>> use cases to cover. >>>>> >>>>>>> - or rather than compose to fit your displays, you could switch... >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 Folks _will_ do that -- I can't stop them. But I find it >>>>> >>>>> uninteresting. >>>>> >>>>> ??? We have been talking about switching a lot. Are you saying that >>>> >>>> is >>>>> >>>>> uninteresting? >>>>> >>>>> If it makes sense for a middlebox to switch, doesn't it make equal >>>>> sense for an endpoint to do so? >>>>> >>>>>>> - handling video from multiple scenes probably presents some added >> >> >>>>>>> issues. By definition there is no specified spatial relationship >>>>>>> between the captures of different scenes... >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 Nonetheless, the participants will want to imagine such = a >>>>> >>>>> relationship. >>>>> >>>>> ISTM that this needs further discussion. >>>>> >>>>>>> - If you don't have sufficient speakers for all of the audio >>>>>>> captures, then you have to decide to mix, switch, or drop some. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 There really isn't any such thing as "sufficient speaker= s", >>>>>> but surround-sound should be considered "sufficient". You can >>>>>> always mix to stereo or even mono: "you pays your money and you >>>>>> takes your >>>>> >>>>> choice". >>>>> >>>>> Do we have enough information to do it "right" or "well"? >>>>> Right now the coordinate info is all optional. Does it need to be >>>>> mandatory in order to enable this? >>>>> >>>>>>> The spatial information from the captures may help in deciding how >> >> >>>>>>> to >>>>> >>>>> >>>>>>> mix. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 Absolutely! >>>>>> >>>>>>> Not evident that the mixed attribute helps with this >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 It help you know when mixing is less likely to work well= . >>>>>> >>>>>>> - unless it is used to decide to switch rather than mix. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 I'm not sure there is any such thing. "Mixing" frequentl= y >>>>>> includes >>>>> >>>>> >>>>>> "riding gain" to reduce background noise. Binary switching is just >>>>>> a bad idea. >>>>> >>>>> >>>>> I have no special understanding of this. I'm just asking probing >>>>> questions in hopes that it will result in the right decisions being >>>>> made and the right stuff specified. >>>>> >>>>>>> Of course if you are mapping independent audio captures onto >>>>>>> different speakers then they are being implicitly mixed. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 Not a useful way to think about it, IMHO. Human ears and >>>>>> brains can sort out individual sources if there are enough >>>>>> speakers, while mixing makes that harder. >>>>> >>>>> >>>>> I have had the impression that "simple" clue telepresence rooms >>>>> would be hoping to do direct mapping of captures to devices. If the >>>>> assumption is that this will be an unsatisfactory approach and all >>>>> endpoints should be prepared to do something more complex then it >>>>> would be helpful to write that down somewhere - e.g. in the >>>> >>>> framework. >>>>> >>>>> >>>>> [Espen] Agree with Paul here, the basic scenario is well understood. >>>> >>>> A >>>>> >>>>> sends two logical audio captures and a receiver play them out with >>>> >>>> the >>>>> >>>>> same spatial relationship. As rule of thumb here could be that for >>>>> basic interoperability between vendors you assume pairs of audio and >> >> >>>>> video captures that can be easily rendered on matching pairs of >>>>> screens and speaker. >>>>> >>>>>>> - If you don't have speakers with similar spatial relationship to >>>>>>> those of the audio captures, then you must decide whether to do >>>>>>> sub-optimal assignments or mix. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 I suppose _some_ telepresence system will hide dozens of >>>>>> speakers in the telepresence room and try to do this -- to me it >>>>>> sounds like a dreadful idea, but it's quite possible the people >>>>>> will >>>> >>>> adapt. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 "Sub-optimal" really doesn't have a clear meaning here. = Even >>>>>> speakers in the "wrong" left-to-right order while you can see the >>>>>> "correct" order on-screen won't confuse the listener as much as >>>>>> speaker assignments changing for no obvious reason. >>>>>> >>>>>>> Again not clear if the mixed attribute helps with this. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 As an extreme example, you could always render "mixed" i= n >> >> mono. >>>>>> >>>>>> >>>>>>> - If you have audio from more than one scene, what should you do >>>>>>> with >>>>> >>>>> >>>>>>> it? Should you mix, even though you have no spatial relationships? >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 IMHO, you should _invent_ a spatial relationship in that >> >> case. >>>>>> >>>>>> Even if each room invents a different spatial relationship, it will >> >> >>>>>> prove less confusing. >>>>>> >>>>>>> Or should you switch based on active speaker? >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 Only if background-noise is a serious problem. >>>>>> >>>>>>> What would help you to decide? >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 It becomes quickly obvious to the listener! >>>>>> >>>>>>> The problems are superficially different for MCUs. But perhaps >>>>>>> only superficially. It seems to me that when the MCU decides how >>>>>>> to map its inputs into its advertisement, it has some virtual room >> >> >>>>>>> layouts >>>>> >>>>> in mind. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 I would expect so. >>>>>> >>>>>>> So for each virtual room layout it is addressing the same issues >>>>>>> as a >>>>> >>>>> >>>>>>> real endpoint with that layout. But it does have the added problem >> >> >>>>>>> of >>>>> >>>>> >>>>>>> deciding how to describe what it is advertising - e.g. when to >>>> >>>> apply >>>>>>> >>>>>>> the mixed/composed attributes. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 Pretty much always, unless it's feeding an exact copy of= what >>>> >>>> it >>>>>> >>>>>> receives. >>>>> >>>>> >>>>> Since I've seen people here describe cases when that isn't so, it >>>>> would be helpful to have a more precise definition. >>>>> >>>>>>> Some interesting use cases for all of the above would be very >>>>> >>>>> helpful. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 Did the cases I listed help? >>>>> >>>>> >>>>> I think they need to be worked out in much more detail: >>>>> >>>>> - what equipment (input and output) is in each endpoint, and where. >>>>> - what is advertised and how the input equipment is mapped to >>>>> =A0 =A0 =A0the advertisement >>>>> - how each endpoint maps the advertised captures to its output >>>> >>>> equipment >>>>> >>>>> =A0 =A0 =A0together with how the info in the advertisement allowed it= to >>>>> =A0 =A0 =A0determine that mapping. >>>>> >>>>> [Espen] Agree, being practical about what we will offer for actual >>>>> endpoints are useful. >>>>> >>>>> >>>>> =A0 =A0 =A0 =A0Thanks, >>>>> =A0 =A0 =A0 =A0Paul >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From john@jlc.net Tue Apr 17 13:17:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5CF11E80CB for ; Tue, 17 Apr 2012 13:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.884 X-Spam-Level: X-Spam-Status: No, score=-105.884 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ilmp5qxSYFsQ for ; Tue, 17 Apr 2012 13:17:15 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0153F11E80BA for ; Tue, 17 Apr 2012 13:17:14 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C07EE33C21; Tue, 17 Apr 2012 16:17:14 -0400 (EDT) Date: Tue, 17 Apr 2012 16:17:14 -0400 From: John Leslie To: Marshall Eubanks Message-ID: <20120417201714.GB99904@verdi> References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> <4F8CAC7F.7040405@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: CLUE Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:17:16 -0000 Marshall Eubanks wrote: > > Thinking about our discussion today, I do NOT think that we can just > push this entirely on the sender, and just say "I want N screens, > please send the appropriate set." I quite agree. We're trying to write a standard for interoperability; and it's simply not reasonable to expect full trust between competitors on how screen real-estate is allocated. > I see two general problems : > > - as screens are composited information much be carried along, and the > compositor will inevitably be making its own decisions about what to > carry, in what form, etc. Yes, and we can't standardize all those details. > - some such decisions and serving must come from middleware (i.e., MCU > or servers in the network). How will they know what to do without > getting information from upstream? And, if they get it, why can't > such information go directly to receivers at the edge ? Clearly, middleware will be involved for some setups. Were I writing middleware, I'd want to know my best source of video for every potential speaker (whether or not any audio matches); and to apply my own algorithms for "current speaker" (as distinct from "loudest audio". In principle, such information _could_ go to receivers at the edge, but I expect there to be bandwidth and latency issues lasting many years into the future. My point is that vendors _should_ want to give a "familiar" experience to their customers, and it will at least subtly differ from the experience other vendors offer. -- John Leslie From pkyzivat@alum.mit.edu Tue Apr 17 13:36:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E559911E80CC for ; Tue, 17 Apr 2012 13:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOHIjCCt1m7d for ; Tue, 17 Apr 2012 13:36:58 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 4100211E80C7 for ; Tue, 17 Apr 2012 13:36:58 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id z8761i0061ZXKqc598cyU9; Tue, 17 Apr 2012 20:36:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id z8cy1i00k07duvL3h8cy1v; Tue, 17 Apr 2012 20:36:58 +0000 Message-ID: <4F8DD467.4060402@alum.mit.edu> Date: Tue, 17 Apr 2012 16:36:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> <4F8CAC7F.7040405@alum.mit.edu> <20120417201714.GB99904@verdi> In-Reply-To: <20120417201714.GB99904@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:36:59 -0000 On 4/17/12 4:17 PM, John Leslie wrote: > My point is that vendors _should_ want to give a "familiar" experience > to their customers, and it will at least subtly differ from the experience > other vendors offer. How should I read the above when systems from two different vendors are interoperating? I can see this in two ways: - the receiving system will endeavor to adapt the advertised information from the provider to produce the kind of experience the receiving system prefers. - the providing system may want to do what it can to cause the receiving system to give the experience the providing system prefers. Absent some counteracting force systems will probably try to do both, though they are in some sense conflicting goals. Presumably the receiving system could come closest to providing its familiar experience to its customers if the providing system makes available all the raw captures and sufficient information to understand what they are. But that assumes the receiving system has sufficient bandwidth and processing capacity. As soon as the sending system starts processing the captures, especially if it then fails to make all the raw captures available, it is putting its imprint on the receiving system's user experience. Maybe it would make sense to distinguish here between behavior of endpoints and MCUs. We may expect an MCU to have a stronger influence on endpoint user experience than we do in a point to point session. Thanks, Paul From ron.even.tlv@gmail.com Tue Apr 17 14:25:05 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11B011E80C5 for ; Tue, 17 Apr 2012 14:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3o86A14-ikv8 for ; Tue, 17 Apr 2012 14:24:58 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E089611E80B2 for ; Tue, 17 Apr 2012 14:24:57 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4373wib.13 for ; Tue, 17 Apr 2012 14:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=CunZMEmgssXoIyrw+KpoYfUGaEzL/icNq16IOoFn5NM=; b=z9zsLibPvn7RoHmrEcWHINRRxPfQddhklA1sogdCWWKLW8pYxdJPoVh/uy44jAfFRs iNh78zHkINhp/t5zCHnnup4BCk6EfiNQ/smnP9/kEWLG55fSIE1sDvefJQONHTkrWI1Z 50RANQS2cwKcPzh43Xsfj+XcB30vMLMRbWXyUkxvg1it7obKunUvWJXfK++7yD+Tqw/Q EmTBLD321gN+HsPCE32NutdMARTS0bt5A2FbXZBLu77LdcRHA/wCH2NbapHLfBrM0Lm/ Bt24WC4XLpqEM1kgeeChpOMKpeEQVktwOpFd3xBwu+Ux4xeFNA0vH0dL3F1YKc4wNXyQ 93rg== Received: by 10.180.101.8 with SMTP id fc8mr84719wib.12.1334697896985; Tue, 17 Apr 2012 14:24:56 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id n20sm47461428wiw.5.2012.04.17.14.24.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 14:24:55 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <4F846AE0.4010700@alum.mit.edu><20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com><4F873CCE.3020806@alum.mit.edu><4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> <4f8d7ccb.2266b40a.1ceb.fffffc00@mx.google.com> <4F8DBA26.8010705@alum.mit.edu> In-Reply-To: <4F8DBA26.8010705@alum.mit.edu> Date: Wed, 18 Apr 2012 00:23:21 +0300 Message-ID: <4f8ddfa7.f44cb40a.72e3.7f2a@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0cyi5W/DP2s8saRAaY3g5x3vZfnwAFVe0Q Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 21:25:05 -0000 Paul, This is one capture scene entry since they can be provided simultaneously. The consumer can ask for a subset of the entry and not all four captures. It can ask first for the switched and any one of the fixed and when the active speaker changes it can ask for a different fixed capture from the 3 fixed captures. I also think that there is nothing that will prevent the receiver to ask for the three fixed and display 2 of them except we do not have a way to say which ones are the most active speaker. This is why the switched one is needed Roni > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, April 17, 2012 9:45 PM > To: Roni Even > Cc: 'Brian Baldino (bbaldino)'; 'CLUE' > Subject: Re: [clue] Does framework provide sufficient info for > receiver? > > Hi Roni, > > On 4/17/12 10:21 AM, Roni Even wrote: > > Hi, > > My view is that in this case the provider can advertise the three > > fixed captures and one with switched which may be the active speaker. > > Do you mean one capture scene entry containing all four of these > captures? Or do you mean one capture scene entry with the three fixed > captures, and another one containing just the switched capture? > > > We will need > > a way to let the consumer know who is the current speaker enabling > him > > to choose the switched active speaker stream and one of the fixed > > streams which may be the previous speaker. > > So in that case the consumer would receive all four captures, and > render the switched capture plus dynamically select one of the others > to render? > > If so, how is that any easier than simply receiving the three fixed > captures and making its own decision about which two to render based on > tracking speakers? That would have the benefit of requiring one less > stream to be received. But it would still require receiving more > streams than if it could select two offered by the provider that > provide a good experience for a two screen system. > > Thanks, > Paul > > > Roni > > > >> -----Original Message----- > >> From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] > >> Sent: Tuesday, April 17, 2012 2:19 AM > >> To: Paul Kyzivat; Roni Even > >> Cc: CLUE > >> Subject: RE: [clue] Does framework provide sufficient info for > >> receiver? > >> > >> Hey Paul, with regards to this bit: > >> > >> "For instance, suppose the sender does something to combine some of > >> its captures so that it can advertise a capture scene entry that > >> requires fewer displays. E.g. suppose it has three main captures of > >> participants and one presentation capture. And suppose in addition > to > >> advertising all of those as one entry, it also advertises another > >> entry for a three-screen room, consisting of one capture for the > >> presentation, one for the current speaker, and one for the prior > >> speaker. So that is one fixed and two switched captures. If the > >> recipient need to map this to two displays, how does it decide what > >> to do? The obvious thing would be to omit the capture for the prior > >> speaker. But how would it know which one that is." > >> > >> My understanding was more that the provider would advertise all > valid > >> views with a capture entry for each, not require (or rely on) an > >> endpoint to be able to "find" a valid view which is a subset of one > >> that was actually advertised; therefore relieving the consumer of > >> that responsibility. So in this case, the provider would advertise > >> entries that contained: > >> 1) Just the active speaker > >> 2) The active speaker and previous active speaker > >> 3) The active speaker, previous active speaker and presentation > >> (Maybe even a 4th that contained the active speaker and > presentation) > >> > >> The idea being that the provider is smart enough to know/advertise > >> its valid views rather than rely on the consumer to figure them out. > >> > >> Even with this there are still situations where no advertised view > is > >> ideal for the consumer, maybe this is the situation you're referring > >> to? > >> I'd hoped that the consumer could get away with choosing the "next > >> best fit" using information already in the advertisement (how many > >> captures an entry consists of, switched vs. non-switched, area of > >> capture info, > >> etc.) > >> > >> -Brian > >> > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Monday, April 16, 2012 7:35 AM > >> To: Roni Even > >> Cc: 'CLUE' > >> Subject: Re: [clue] Does framework provide sufficient info for > >> receiver? > >> > >> Hi Roni, > >> > >> On 4/15/12 11:20 AM, Roni Even wrote: > >>> Hi Paul, > >>> I think that there is enough information that will allow a receiver > >> to > >> > >>> select N out of M streams. > >>> The receiver will know the semantics of the streams (people or > >>> presentation) and the spatial information of the room and the > >> different streams. > >>> My view is that this is enough for the general telepresence point > to > >>> point use case. > >> > >> I think I agree for the case where there is a single scene > >> advertised, and all the captures represent single cameras. > >> > >> But as soon as you add in mixed or switched captures it becomes far > >> less clear. > >> > >> For instance, suppose the sender does something to combine some of > >> its captures so that it can advertise a capture scene entry that > >> requires fewer displays. E.g. suppose it has three main captures of > >> participants and one presentation capture. And suppose in addition > to > >> advertising all of those as one entry, it also advertises another > >> entry for a three-screen room, consisting of one capture for the > >> presentation, one for the current speaker, and one for the prior > >> speaker. So that is one fixed and two switched captures. If the > >> recipient need to map this to two displays, how does it decide what > >> to do? The obvious thing would be to omit the capture for the prior > >> speaker. But how would it know which one that is. > >> > >>> As for multipoint use case, this is why I think it is important to > >>> know if the advertisement is based on site switch or segment switch > >>> which will provide the extra information needed for the selection > >>> (spatial information provides the internal relation between the > >>> capture) and I think that the audio level will help with knowing > who > >>> are the active speakers in this case > >> > >> I think there are too many unknowns in the above to discuss it with > >> clarity. We need some use cases. > >> > >> Thanks, > >> Paul > >> > >>> Roni > >>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Thursday, April 12, 2012 11:37 PM > >>>> To: Espen Berger (espeberg) > >>>> Cc: CLUE > >>>> Subject: Re: [clue] Does framework provide sufficient info for > >>>> receiver? > >>>> > >>>> Espen - comments inline. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: > >>>>> During the CLUE design team meeting on webex yesterday we started > >> to > >> > >>>>> discuss various use cases and if they are in scope or not for the > >>>>> current work in CLUE. > >>>>> > >>>>> As a part of my response to Pauls questions I summarized the use > >>>> cases > >>>>> and grouped them into supported / not supported. I can dive into > >>>>> more detail about the use cases if people are interested? > >>>>> > >>>>> I would answer yes to the following use cases > >>>>> * Telepresence point to point, where the reproduction will happen > >> in > >>>> a > >>>>> 2D-plane for audio and video. Currently CLUE support announcing > >>>>> capability of sending 1 - N capture (left to right) and a > receiver > >>>> can > >>>>> request 1 - M streams for rendering (left to tight), which is the > >>>>> basic for interoperability. > >>>> > >>>> In this case, suppose N> M. Who is responsible for deciding > which M > >>>> of the N streams will be used? AFAIK the recipient just picks the > >>>> ones it wants. So then my question remains - does the recipient > >>>> have sufficient info to select the "right" ones? (There isn't any > >>>> guarantee that *any* N of the M streams will provide a reasonable > >> rendering. > >>>> > >>>> This would be improved if we had a mechanism for the recipient to > >>>> state "I can only handle N streams" and the sender was obligated > to > >>>> meet that constraint. I don't think we have said that. > >>>> > >>>>> * Transcoded conferencing, where the MCU act like an endpoint and > >>>>> logically announces audio and video left to right and a receiver > >>>>> request > >>>>> 1 - M captures depending on how many screen and audio streams you > >>>>> prefer. Typically a single video stream pr. screen and one audio > >> pr. > >>>>> screen (mono/stereo). Excluded is capabilities to select > >>>>> individual speakers, the MCU is free to optimize what to compose > >>>>> and send to a receiver. > >>>> > >>>> This is logically equivalent to the prior case. > >>>> > >>>>> * Generic multi source, sending and receiving named sources where > >>>>> the user experience is controlled by an human being capable of > >>>>> reading sources names, or control software written explicit to > >>>>> operate on the named streams. The content attribute can be used > to > >>>>> indicate a > >>>> primary > >>>>> role, RFC4796 uses 'main' and 'alt'. > >>>> > >>>> Are you talking about the text names/labels we were discussing on > >> the > >> > >>>> last call? > >>>> > >>>> If so, I agree that if the senders provide well conceived labels > >> then > >> > >>>> a human can probably decide something reasonable. > >>>> > >>>> If the human is working only with "content" attributes, then its > >>>> not so clear. Its quite possible that the recipient will find > >>>> itself trying to choose between multiple streams with the same > >>>> content > >> type. > >> > >>>> (E.g. all > >>>> 'main'.) > >>>> > >>>>> I would answer no, to the following use cases > >>>>> * Switched conferencing, where we assume that endpoints do > >>>>> scalable video (either SVC or Simulcast), locally composited > >>>>> layout and > >> audio > >> > >>>>> mixing. Limited work has been done on how to use Scalable video > >>>>> and how to build mechanisms for complete composited layouts. > >>>>> * Advanced audio reproduction, a group of audio scenarios > >>>>> mentioned > >>>> by > >>>>> Jon Leslie and Johan Nielsen that requires more details during > >>>> initial > >>>>> signalling and more dynamic information for transferring dynamic > >>>>> meta-information. > >>>>> * Multi view, as described in the CLUE use case document. > >>>>> > >>>>> (Other comments inline.) > >>>>> > >>>>> Cheers > >>>>> > >>>>> -Espen > >>>>> > >>>>> -----Original Message----- > >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> Behalf > >> > >>>>> Of Paul Kyzivat > >>>>> Sent: 11. april 2012 17:06 > >>>>> To: John Leslie > >>>>> Cc: CLUE > >>>>> Subject: Re: [clue] Does framework provide sufficient info for > >>>> receiver? > >>>>> > >>>>> Hi John, > >>>>> > >>>>> Thanks for the comments. I've followed up inline. > >>>>> > >>>>> On 4/10/12 5:09 PM, John Leslie wrote: > >>>>>> Paul Kyzivat wrote: > >>>>>>> > >>>>>>> The fundamental problem in the scope of CLUE is, if you are an > >>>>>>> endpoint, and you have received an advertisement, with some > >> scenes > >> > >>>>>>> and captures, do you have sufficient information to select and > >> map > >> > >>>>>>> the advertised scenes/captures onto the equipment you have? > >>>>>> > >>>>>> Of course not! > >>>>>> > >>>>>> If we wanted that, we'd have to include for every > composed > >>>> scene > >>>>>> what it's composed from, and for every mixed audio what it's > >>>>>> mixed from. > >>>>> > >>>>> I think you must have misunderstood me. Otherwise I wouldn't > >>>>> expect you to answer "Of course not". AFAIK the whole point of > >>>>> CLUE is to provide the information to make this possible. > >>>>> > >>>>> My point in asking the question was so that we can identify what > >>>>> information we have overlooked that we need to include one way or > >>>>> another. > >>>>> > >>>>> Clearly there are some tradeoffs. More information might support > >>>>> *better* mappings. So one thing to decide is how good is good > >> enough. > >>>>> [Espen] Agree with Paul, we clearly can support in CLUE the use > >>>>> cases where a Telepresence room either offer a 1, 2 or 3 video > >>>>> captures, which can be rendered on 1, 2 or 3 screens. > >>>> > >>>> I think its clear we can support cases where every advertisement > >> that > >> > >>>> includes an entry for N (>1) captures also includes an entry with > >>>> only one capture, and optionally entries containing other numbers > >>>> of captures between 1 and N. > >>>> > >>>> But as I mention above, its not clear we have supported case where > >>>> the minimal entry in the advertisement is for N>1 captures. > >>>> > >>>>>>> If you have sufficient equipment (displays, speakers) with > >>>>>>> compatible > >>>>> > >>>>>>> geometry to directly map all of the captures from one audio and > >>>>>>> one video capture scene entry from each capture scene then > maybe > >>>>>>> all is good. In this case ISTM that the mixed/composed > >>>>>>> attributes aren't needed. > >>>>>> > >>>>>> It's unlikely that the "typical" telepresence conference > >> will > >> > >>>>>> have > >>>>> > >>>>>> a separate screen for every possible video. > >>>>> > >>>>> That isn't what I said. Consider what is perhaps a typical case, > >>>> where > >>>>> the advertisement contains one scene with several alternative > >>>>> video and audio scene entries. Lets just consider the video. Then > >>>>> maybe there is one entry with three captures, and another with > one > >>>>> (mixed/switched, > >>>>> whatever) capture. Then if you have three screens you can map all > >>>>> three captures in the first entry. If you have less than three > >>>> screens > >>>>> then you can map the one capture from the 2nd entry onto one of > >> your > >>>> screens. > >>>>> > >>>>> But what if there was no entry with a single capture? If you had > >> two > >> > >>>>> screens, would you have enough info about the three captures in > >>>>> the first entry to make a reasonable mapping onto your two > screens? > >> What > >> > >>>>> information would we need to include in the advertisement so that > >> it > >> > >>>>> would be possible to do this mapping well? > >>>>> > >>>>> [Espen] How a vendor build a room or endpoint is transparent from > >>>>> the sender of media. As a sender you should not care if a room > >>>>> request 3 audio streams (left, center, right) and choose to mix > >>>>> and play out on a single speaker. We can argue that this is not > >>>>> the > >> best > >> > >>>>> experience, but still valid and typically done for PC-clients or > >>>>> other endpoints with a single speaker. > >>>> > >>>> Again, I think you are assuming the receiver can specify the max > >>>> number of streams it can handle, and that the sender will then be > >>>> obligated to select/construct a suitable set of streams. AFAIK we > >>>> have not written down anything that calls for that. (If I am > wrong, > >>>> please let me know where this is specified.) > >>>> > >>>> We have the (largely hypothetical) recipient capabilities message, > >>>> but its content hasn't been specified yet, and AFAIK there has > been > >>>> no statement that it is binding and the construction of the > >> advertisement. > >>>> > >>>>>> Of course, the number of "capture scenes" _could_ be > small > >>>>>> enough to give each it's own video monitor -- but I don't think > >>>>>> that's the general case we should design for. > >>>>> > >>>>> IIUC an endpoint will typically only advertise one or two scenes. > >>>>> One would correspond to the cameras and mics in its room. The > >> other, > >> > >>>>> if present, would correspond to a "presentation" that doesn't fit > >>>>> into the coordinate space of the room. There are cases for more, > >> but > >> > >>>>> they get more obscure. > >>>>> > >>>>> So for a point-to-point clue call the recipient will only need to > >>>>> map one or two scenes. But when there is more than one it is more > >>>> complex, > >>>>> requiring sharing of equipment. > >>>>> > >>>>> The situation is more complex for an MCU. It will have as input > >>>>> all the scenes offered by all the endpoints. It then has to > decide > >>>>> what > >>>> to > >>>>> offer out to the endpoints. It could just pass through all the > >>>>> scenes it receives from all the endpoints, leaving the mapping > >>>>> problem entirely to the endpoints. (I don't think that is what > >>>>> most people have in mind, though some might.) > >>>>> > >>>>> Or it could take on itself the job of mapping/mixing/switching > all > >>>>> of those inputs and producing something more like what a typical > >>>> endpoint > >>>>> would advertise - one or two scenes each with just a few > captures. > >>>>> > >>>>> Or it could do both - advertise its own simplified composite > >>>>> scenes and also all those provided by the endpoints. That would > >>>>> allow the endpoints to either take the easy way out, or else do > it > >>>>> all themselves in a way that suits them. Suppose it did this. > >>>>> Would the endpoints that want to take the easy way be able to > >>>>> figure out > >> which > >> > >>>>> scenes and captures to use? > >>>>> > >>>>> [Espen] This sounds closer to a user experience discussions than > a > >>>>> protocol discussion. > >>>> > >>>> Perhaps it is. But the point of CLUE is to develop a protocol that > >>>> enables an especially good user experience. While we shouldn't > >>>> mandate the user experience, I think we are obligated to do due > >>>> diligence that the protocol is sufficient to enable that user > >> experience. > >>>> > >>>>>> OTOH, with an appropriate "surround-sound" system, you > can > >>>> "place" > >>>>>> an arbitrarily large number of audio streams, yet make them easy > >> to > >> > >>>>>> distinguish. > >>>>>> > >>>>>>> If you don't have sufficient equipment to do that, then the job > >> is > >> > >>>>>>> harder, and more information is needed to figure out what to > do. > >>>>>> > >>>>>> Only marginally harder... > >>>>>> > >>>>>>> For instance: > >>>>>>> > >>>>>>> - If you don't have suitable displays, then perhaps you can > >> select > >>>> a > >>>>>>> video capture scene entry and locally compose or switch some of > >>>>>>> the captures in order to produce a set of captures that does > map > >>>>>>> to the available displays. The area of capture of each capture > >>>>>>> could be helpful to doing this, and perhaps the composed > >> attribute > >> as well. > >>>>>> > >>>>>> One inevitable use case is filing your formal report from > >> the > >>>>> airport. > >>>>>> The person doing so will have lousy audio, vastly inadequate > >> video, > >> > >>>>>> and typically inadequate bandwidth with excessive latency. S/he > >>>>>> will need some middlebox to compose a "barely-adequate video" > and > >>>>>> mono > >>>>> audio. > >>>>> > >>>>> This is indeed an interesting case - one we have explicitly put > in > >>>>> scope. If an MCU is already in the call then perhaps we can hope > >>>>> that is one of the entries it makes available. > >>>>> > >>>>> If there isn't any MCU in the call, then the other endpoint might > >>>>> not advertise that option. Then what? Do we have a mechanism for > >> that? > >>>>> [Espen] If an MCU detect low bandwidth or packet loss it can > start > >>>>> using its normal recovery mechanisms. That could lower bitrate > for > >>>>> audio and video (maybe by a SIP re-invite), change the CLUE offer > >> to > >> > >>>>> something that fits inside the available bandwidth. Getting good > >>>>> quality audio ande video is always a challenge, with or without > >> clue. > >>>>> > >>>>>> Then there's the use case of filing you formal report > from > >>>>>> your home office (when you're sick or somebody doesn't want to > >>>>>> pay travel > >>>>> cost). > >>>>>> You may well have surround-sound and two or three large > monitors, > >>>>>> 20 Mbps download with 40 msec RTT, and a decent-quality lavalier > >> mike. > >>>>>> You still probably want some middlebox to compose your basic > >> video, > >> > >>>>>> but you can take individual streams as well to concentrate on > >>>>> particular people. > >>>>>> > >>>>>> Near the top end are the corporate telepresence rooms. > >>>>>> They > >>>> will > >>>>>> want all streams, and are likely to have a human being mixing > >> them. > >>>>> > >>>>> I don't understand your point "are likely to have a human being > >>>> mixing > >>>>> them". Can you explain further? > >>>>> [Espen] I see this as mostly a request for focusing in on > >> particular > >> > >>>>> user. In a transcoded conference you can do that by looking into > >>>> XCon, > >>>>> if you do switched conference the endpoint typically render the > >>>> layout > >>>>> and can choose who to focus on. Mixing transcoded and switched > >>>>> conferencing I think makes it unnecessary complex for the initial > >>>>> use cases to cover. > >>>>> > >>>>>>> - or rather than compose to fit your displays, you could > >> switch... > >>>>>> > >>>>>> Folks _will_ do that -- I can't stop them. But I find it > >>>>> uninteresting. > >>>>> > >>>>> ??? We have been talking about switching a lot. Are you saying > >>>>> that > >>>> is > >>>>> uninteresting? > >>>>> > >>>>> If it makes sense for a middlebox to switch, doesn't it make > equal > >>>>> sense for an endpoint to do so? > >>>>> > >>>>>>> - handling video from multiple scenes probably presents some > >> added > >> > >>>>>>> issues. By definition there is no specified spatial > relationship > >>>>>>> between the captures of different scenes... > >>>>>> > >>>>>> Nonetheless, the participants will want to imagine such a > >>>>> relationship. > >>>>> > >>>>> ISTM that this needs further discussion. > >>>>> > >>>>>>> - If you don't have sufficient speakers for all of the audio > >>>>>>> captures, then you have to decide to mix, switch, or drop some. > >>>>>> > >>>>>> There really isn't any such thing as "sufficient > >>>>>> speakers", but surround-sound should be considered "sufficient". > >>>>>> You can always mix to stereo or even mono: "you pays your money > >>>>>> and you takes your > >>>>> choice". > >>>>> > >>>>> Do we have enough information to do it "right" or "well"? > >>>>> Right now the coordinate info is all optional. Does it need to be > >>>>> mandatory in order to enable this? > >>>>> > >>>>>>> The spatial information from the captures may help in deciding > >> how > >> > >>>>>>> to > >>>>> > >>>>>>> mix. > >>>>>> > >>>>>> Absolutely! > >>>>>> > >>>>>>> Not evident that the mixed attribute helps with this > >>>>>> > >>>>>> It help you know when mixing is less likely to work well. > >>>>>> > >>>>>>> - unless it is used to decide to switch rather than mix. > >>>>>> > >>>>>> I'm not sure there is any such thing. "Mixing" frequently > >>>>>> includes > >>>>> > >>>>>> "riding gain" to reduce background noise. Binary switching is > >>>>>> just a bad idea. > >>>>> > >>>>> I have no special understanding of this. I'm just asking probing > >>>>> questions in hopes that it will result in the right decisions > >>>>> being made and the right stuff specified. > >>>>> > >>>>>>> Of course if you are mapping independent audio captures onto > >>>>>>> different speakers then they are being implicitly mixed. > >>>>>> > >>>>>> Not a useful way to think about it, IMHO. Human ears and > >>>>>> brains can sort out individual sources if there are enough > >>>>>> speakers, while mixing makes that harder. > >>>>> > >>>>> I have had the impression that "simple" clue telepresence rooms > >>>>> would be hoping to do direct mapping of captures to devices. If > >>>>> the assumption is that this will be an unsatisfactory approach > and > >>>>> all endpoints should be prepared to do something more complex > then > >>>>> it would be helpful to write that down somewhere - e.g. in the > >>>> framework. > >>>>> > >>>>> [Espen] Agree with Paul here, the basic scenario is well > >> understood. > >>>> A > >>>>> sends two logical audio captures and a receiver play them out > with > >>>> the > >>>>> same spatial relationship. As rule of thumb here could be that > for > >>>>> basic interoperability between vendors you assume pairs of audio > >> and > >> > >>>>> video captures that can be easily rendered on matching pairs of > >>>>> screens and speaker. > >>>>> > >>>>>>> - If you don't have speakers with similar spatial relationship > >>>>>>> to those of the audio captures, then you must decide whether to > >>>>>>> do sub-optimal assignments or mix. > >>>>>> > >>>>>> I suppose _some_ telepresence system will hide dozens of > >>>>>> speakers in the telepresence room and try to do this -- to me it > >>>>>> sounds like a dreadful idea, but it's quite possible the people > >>>>>> will > >>>> adapt. > >>>>>> > >>>>>> "Sub-optimal" really doesn't have a clear meaning here. > >>>>>> Even speakers in the "wrong" left-to-right order while you can > >>>>>> see the "correct" order on-screen won't confuse the listener as > >>>>>> much as speaker assignments changing for no obvious reason. > >>>>>> > >>>>>>> Again not clear if the mixed attribute helps with this. > >>>>>> > >>>>>> As an extreme example, you could always render "mixed" in > >> mono. > >>>>>> > >>>>>>> - If you have audio from more than one scene, what should you > do > >>>>>>> with > >>>>> > >>>>>>> it? Should you mix, even though you have no spatial > >> relationships? > >>>>>> > >>>>>> IMHO, you should _invent_ a spatial relationship in that > >> case. > >>>>>> Even if each room invents a different spatial relationship, it > >> will > >> > >>>>>> prove less confusing. > >>>>>> > >>>>>>> Or should you switch based on active speaker? > >>>>>> > >>>>>> Only if background-noise is a serious problem. > >>>>>> > >>>>>>> What would help you to decide? > >>>>>> > >>>>>> It becomes quickly obvious to the listener! > >>>>>> > >>>>>>> The problems are superficially different for MCUs. But perhaps > >>>>>>> only superficially. It seems to me that when the MCU decides > how > >>>>>>> to map its inputs into its advertisement, it has some virtual > >> room > >> > >>>>>>> layouts > >>>>> in mind. > >>>>>> > >>>>>> I would expect so. > >>>>>> > >>>>>>> So for each virtual room layout it is addressing the same > issues > >>>>>>> as a > >>>>> > >>>>>>> real endpoint with that layout. But it does have the added > >> problem > >> > >>>>>>> of > >>>>> > >>>>>>> deciding how to describe what it is advertising - e.g. when to > >>>> apply > >>>>>>> the mixed/composed attributes. > >>>>>> > >>>>>> Pretty much always, unless it's feeding an exact copy of > >> what > >>>> it > >>>>>> receives. > >>>>> > >>>>> Since I've seen people here describe cases when that isn't so, it > >>>>> would be helpful to have a more precise definition. > >>>>> > >>>>>>> Some interesting use cases for all of the above would be very > >>>>> helpful. > >>>>>> > >>>>>> Did the cases I listed help? > >>>>> > >>>>> I think they need to be worked out in much more detail: > >>>>> > >>>>> - what equipment (input and output) is in each endpoint, and > where. > >>>>> - what is advertised and how the input equipment is mapped to > >>>>> the advertisement > >>>>> - how each endpoint maps the advertised captures to its output > >>>> equipment > >>>>> together with how the info in the advertisement allowed it > to > >>>>> determine that mapping. > >>>>> > >>>>> [Espen] Agree, being practical about what we will offer for > actual > >>>>> endpoints are useful. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > From pkyzivat@alum.mit.edu Tue Apr 17 14:38:14 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA56411E80B1 for ; Tue, 17 Apr 2012 14:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBEfL-5vZemU for ; Tue, 17 Apr 2012 14:38:09 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 115F311E8089 for ; Tue, 17 Apr 2012 14:38:08 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id z84x1i0041c6gX8559e37T; Tue, 17 Apr 2012 21:38:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id z9e31i00b07duvL3j9e35G; Tue, 17 Apr 2012 21:38:03 +0000 Message-ID: <4F8DE2B9.2070607@alum.mit.edu> Date: Tue, 17 Apr 2012 17:38:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Roni Even References: <4F846AE0.4010700@alum.mit.edu><20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com><4F873CCE.3020806@alum.mit.edu><4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> <4f8d7ccb.2266b40a.1ceb.fffffc00@mx.google.com> <4F8DBA26.8010705@alum.mit.edu> <4f8ddfa7.f44cb40a.72e3.7f2a@mx.google.com> In-Reply-To: <4f8ddfa7.f44cb40a.72e3.7f2a@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'CLUE' Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 21:38:14 -0000 Hi Roni, On 4/17/12 5:23 PM, Roni Even wrote: > Paul, > This is one capture scene entry since they can be provided simultaneously. As I understand, its possible to get things from multiple entries simultaneously. (But whether its possible or not depends on the simultaneous set entries.) Being in a single entry should mean that all the captures in the entry together represent the scene. I *think* putting all the fixed captures *and* a switched capture that switches among those fixed ones would be valid, though it does involve some redundancy. (I'd be interested to hear if others think this is appropriate.) > The consumer can ask for a subset of the entry and not all four captures. It > can ask first for the switched and any one of the fixed and when the active > speaker changes it can ask for a different fixed capture from the 3 fixed > captures. While I see how that would be possible, having to send a new select request on the clue channel every time there is a speaker switch might be unacceptable. Even worse if that also required an o/a exchange. (But maybe it won't require that.) > I also think that there is nothing that will prevent the receiver to ask for > the three fixed and display 2 of them except we do not have a way to say > which ones are the most active speaker. This is why the switched one is > needed We need sufficient information to determine active speaker. Is getting a switched capture, where the switching criterion is active speaker, the only way to do that? Thanks, Paul > Roni > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, April 17, 2012 9:45 PM >> To: Roni Even >> Cc: 'Brian Baldino (bbaldino)'; 'CLUE' >> Subject: Re: [clue] Does framework provide sufficient info for >> receiver? >> >> Hi Roni, >> >> On 4/17/12 10:21 AM, Roni Even wrote: >>> Hi, >>> My view is that in this case the provider can advertise the three >>> fixed captures and one with switched which may be the active speaker. >> >> Do you mean one capture scene entry containing all four of these >> captures? Or do you mean one capture scene entry with the three fixed >> captures, and another one containing just the switched capture? >> >>> We will need >>> a way to let the consumer know who is the current speaker enabling >> him >>> to choose the switched active speaker stream and one of the fixed >>> streams which may be the previous speaker. >> >> So in that case the consumer would receive all four captures, and >> render the switched capture plus dynamically select one of the others >> to render? >> >> If so, how is that any easier than simply receiving the three fixed >> captures and making its own decision about which two to render based on >> tracking speakers? That would have the benefit of requiring one less >> stream to be received. But it would still require receiving more >> streams than if it could select two offered by the provider that >> provide a good experience for a two screen system. >> >> Thanks, >> Paul >> >>> Roni >>> >>>> -----Original Message----- >>>> From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] >>>> Sent: Tuesday, April 17, 2012 2:19 AM >>>> To: Paul Kyzivat; Roni Even >>>> Cc: CLUE >>>> Subject: RE: [clue] Does framework provide sufficient info for >>>> receiver? >>>> >>>> Hey Paul, with regards to this bit: >>>> >>>> "For instance, suppose the sender does something to combine some of >>>> its captures so that it can advertise a capture scene entry that >>>> requires fewer displays. E.g. suppose it has three main captures of >>>> participants and one presentation capture. And suppose in addition >> to >>>> advertising all of those as one entry, it also advertises another >>>> entry for a three-screen room, consisting of one capture for the >>>> presentation, one for the current speaker, and one for the prior >>>> speaker. So that is one fixed and two switched captures. If the >>>> recipient need to map this to two displays, how does it decide what >>>> to do? The obvious thing would be to omit the capture for the prior >>>> speaker. But how would it know which one that is." >>>> >>>> My understanding was more that the provider would advertise all >> valid >>>> views with a capture entry for each, not require (or rely on) an >>>> endpoint to be able to "find" a valid view which is a subset of one >>>> that was actually advertised; therefore relieving the consumer of >>>> that responsibility. So in this case, the provider would advertise >>>> entries that contained: >>>> 1) Just the active speaker >>>> 2) The active speaker and previous active speaker >>>> 3) The active speaker, previous active speaker and presentation >>>> (Maybe even a 4th that contained the active speaker and >> presentation) >>>> >>>> The idea being that the provider is smart enough to know/advertise >>>> its valid views rather than rely on the consumer to figure them out. >>>> >>>> Even with this there are still situations where no advertised view >> is >>>> ideal for the consumer, maybe this is the situation you're referring >>>> to? >>>> I'd hoped that the consumer could get away with choosing the "next >>>> best fit" using information already in the advertisement (how many >>>> captures an entry consists of, switched vs. non-switched, area of >>>> capture info, >>>> etc.) >>>> >>>> -Brian >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat >>>> Sent: Monday, April 16, 2012 7:35 AM >>>> To: Roni Even >>>> Cc: 'CLUE' >>>> Subject: Re: [clue] Does framework provide sufficient info for >>>> receiver? >>>> >>>> Hi Roni, >>>> >>>> On 4/15/12 11:20 AM, Roni Even wrote: >>>>> Hi Paul, >>>>> I think that there is enough information that will allow a receiver >>>> to >>>> >>>>> select N out of M streams. >>>>> The receiver will know the semantics of the streams (people or >>>>> presentation) and the spatial information of the room and the >>>> different streams. >>>>> My view is that this is enough for the general telepresence point >> to >>>>> point use case. >>>> >>>> I think I agree for the case where there is a single scene >>>> advertised, and all the captures represent single cameras. >>>> >>>> But as soon as you add in mixed or switched captures it becomes far >>>> less clear. >>>> >>>> For instance, suppose the sender does something to combine some of >>>> its captures so that it can advertise a capture scene entry that >>>> requires fewer displays. E.g. suppose it has three main captures of >>>> participants and one presentation capture. And suppose in addition >> to >>>> advertising all of those as one entry, it also advertises another >>>> entry for a three-screen room, consisting of one capture for the >>>> presentation, one for the current speaker, and one for the prior >>>> speaker. So that is one fixed and two switched captures. If the >>>> recipient need to map this to two displays, how does it decide what >>>> to do? The obvious thing would be to omit the capture for the prior >>>> speaker. But how would it know which one that is. >>>> >>>>> As for multipoint use case, this is why I think it is important to >>>>> know if the advertisement is based on site switch or segment switch >>>>> which will provide the extra information needed for the selection >>>>> (spatial information provides the internal relation between the >>>>> capture) and I think that the audio level will help with knowing >> who >>>>> are the active speakers in this case >>>> >>>> I think there are too many unknowns in the above to discuss it with >>>> clarity. We need some use cases. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>> Behalf Of Paul Kyzivat >>>>>> Sent: Thursday, April 12, 2012 11:37 PM >>>>>> To: Espen Berger (espeberg) >>>>>> Cc: CLUE >>>>>> Subject: Re: [clue] Does framework provide sufficient info for >>>>>> receiver? >>>>>> >>>>>> Espen - comments inline. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: >>>>>>> During the CLUE design team meeting on webex yesterday we started >>>> to >>>> >>>>>>> discuss various use cases and if they are in scope or not for the >>>>>>> current work in CLUE. >>>>>>> >>>>>>> As a part of my response to Pauls questions I summarized the use >>>>>> cases >>>>>>> and grouped them into supported / not supported. I can dive into >>>>>>> more detail about the use cases if people are interested? >>>>>>> >>>>>>> I would answer yes to the following use cases >>>>>>> * Telepresence point to point, where the reproduction will happen >>>> in >>>>>> a >>>>>>> 2D-plane for audio and video. Currently CLUE support announcing >>>>>>> capability of sending 1 - N capture (left to right) and a >> receiver >>>>>> can >>>>>>> request 1 - M streams for rendering (left to tight), which is the >>>>>>> basic for interoperability. >>>>>> >>>>>> In this case, suppose N> M. Who is responsible for deciding >> which M >>>>>> of the N streams will be used? AFAIK the recipient just picks the >>>>>> ones it wants. So then my question remains - does the recipient >>>>>> have sufficient info to select the "right" ones? (There isn't any >>>>>> guarantee that *any* N of the M streams will provide a reasonable >>>> rendering. >>>>>> >>>>>> This would be improved if we had a mechanism for the recipient to >>>>>> state "I can only handle N streams" and the sender was obligated >> to >>>>>> meet that constraint. I don't think we have said that. >>>>>> >>>>>>> * Transcoded conferencing, where the MCU act like an endpoint and >>>>>>> logically announces audio and video left to right and a receiver >>>>>>> request >>>>>>> 1 - M captures depending on how many screen and audio streams you >>>>>>> prefer. Typically a single video stream pr. screen and one audio >>>> pr. >>>>>>> screen (mono/stereo). Excluded is capabilities to select >>>>>>> individual speakers, the MCU is free to optimize what to compose >>>>>>> and send to a receiver. >>>>>> >>>>>> This is logically equivalent to the prior case. >>>>>> >>>>>>> * Generic multi source, sending and receiving named sources where >>>>>>> the user experience is controlled by an human being capable of >>>>>>> reading sources names, or control software written explicit to >>>>>>> operate on the named streams. The content attribute can be used >> to >>>>>>> indicate a >>>>>> primary >>>>>>> role, RFC4796 uses 'main' and 'alt'. >>>>>> >>>>>> Are you talking about the text names/labels we were discussing on >>>> the >>>> >>>>>> last call? >>>>>> >>>>>> If so, I agree that if the senders provide well conceived labels >>>> then >>>> >>>>>> a human can probably decide something reasonable. >>>>>> >>>>>> If the human is working only with "content" attributes, then its >>>>>> not so clear. Its quite possible that the recipient will find >>>>>> itself trying to choose between multiple streams with the same >>>>>> content >>>> type. >>>> >>>>>> (E.g. all >>>>>> 'main'.) >>>>>> >>>>>>> I would answer no, to the following use cases >>>>>>> * Switched conferencing, where we assume that endpoints do >>>>>>> scalable video (either SVC or Simulcast), locally composited >>>>>>> layout and >>>> audio >>>> >>>>>>> mixing. Limited work has been done on how to use Scalable video >>>>>>> and how to build mechanisms for complete composited layouts. >>>>>>> * Advanced audio reproduction, a group of audio scenarios >>>>>>> mentioned >>>>>> by >>>>>>> Jon Leslie and Johan Nielsen that requires more details during >>>>>> initial >>>>>>> signalling and more dynamic information for transferring dynamic >>>>>>> meta-information. >>>>>>> * Multi view, as described in the CLUE use case document. >>>>>>> >>>>>>> (Other comments inline.) >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> -Espen >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf >>>> >>>>>>> Of Paul Kyzivat >>>>>>> Sent: 11. april 2012 17:06 >>>>>>> To: John Leslie >>>>>>> Cc: CLUE >>>>>>> Subject: Re: [clue] Does framework provide sufficient info for >>>>>> receiver? >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> Thanks for the comments. I've followed up inline. >>>>>>> >>>>>>> On 4/10/12 5:09 PM, John Leslie wrote: >>>>>>>> Paul Kyzivat wrote: >>>>>>>>> >>>>>>>>> The fundamental problem in the scope of CLUE is, if you are an >>>>>>>>> endpoint, and you have received an advertisement, with some >>>> scenes >>>> >>>>>>>>> and captures, do you have sufficient information to select and >>>> map >>>> >>>>>>>>> the advertised scenes/captures onto the equipment you have? >>>>>>>> >>>>>>>> Of course not! >>>>>>>> >>>>>>>> If we wanted that, we'd have to include for every >> composed >>>>>> scene >>>>>>>> what it's composed from, and for every mixed audio what it's >>>>>>>> mixed from. >>>>>>> >>>>>>> I think you must have misunderstood me. Otherwise I wouldn't >>>>>>> expect you to answer "Of course not". AFAIK the whole point of >>>>>>> CLUE is to provide the information to make this possible. >>>>>>> >>>>>>> My point in asking the question was so that we can identify what >>>>>>> information we have overlooked that we need to include one way or >>>>>>> another. >>>>>>> >>>>>>> Clearly there are some tradeoffs. More information might support >>>>>>> *better* mappings. So one thing to decide is how good is good >>>> enough. >>>>>>> [Espen] Agree with Paul, we clearly can support in CLUE the use >>>>>>> cases where a Telepresence room either offer a 1, 2 or 3 video >>>>>>> captures, which can be rendered on 1, 2 or 3 screens. >>>>>> >>>>>> I think its clear we can support cases where every advertisement >>>> that >>>> >>>>>> includes an entry for N (>1) captures also includes an entry with >>>>>> only one capture, and optionally entries containing other numbers >>>>>> of captures between 1 and N. >>>>>> >>>>>> But as I mention above, its not clear we have supported case where >>>>>> the minimal entry in the advertisement is for N>1 captures. >>>>>> >>>>>>>>> If you have sufficient equipment (displays, speakers) with >>>>>>>>> compatible >>>>>>> >>>>>>>>> geometry to directly map all of the captures from one audio and >>>>>>>>> one video capture scene entry from each capture scene then >> maybe >>>>>>>>> all is good. In this case ISTM that the mixed/composed >>>>>>>>> attributes aren't needed. >>>>>>>> >>>>>>>> It's unlikely that the "typical" telepresence conference >>>> will >>>> >>>>>>>> have >>>>>>> >>>>>>>> a separate screen for every possible video. >>>>>>> >>>>>>> That isn't what I said. Consider what is perhaps a typical case, >>>>>> where >>>>>>> the advertisement contains one scene with several alternative >>>>>>> video and audio scene entries. Lets just consider the video. Then >>>>>>> maybe there is one entry with three captures, and another with >> one >>>>>>> (mixed/switched, >>>>>>> whatever) capture. Then if you have three screens you can map all >>>>>>> three captures in the first entry. If you have less than three >>>>>> screens >>>>>>> then you can map the one capture from the 2nd entry onto one of >>>> your >>>>>> screens. >>>>>>> >>>>>>> But what if there was no entry with a single capture? If you had >>>> two >>>> >>>>>>> screens, would you have enough info about the three captures in >>>>>>> the first entry to make a reasonable mapping onto your two >> screens? >>>> What >>>> >>>>>>> information would we need to include in the advertisement so that >>>> it >>>> >>>>>>> would be possible to do this mapping well? >>>>>>> >>>>>>> [Espen] How a vendor build a room or endpoint is transparent from >>>>>>> the sender of media. As a sender you should not care if a room >>>>>>> request 3 audio streams (left, center, right) and choose to mix >>>>>>> and play out on a single speaker. We can argue that this is not >>>>>>> the >>>> best >>>> >>>>>>> experience, but still valid and typically done for PC-clients or >>>>>>> other endpoints with a single speaker. >>>>>> >>>>>> Again, I think you are assuming the receiver can specify the max >>>>>> number of streams it can handle, and that the sender will then be >>>>>> obligated to select/construct a suitable set of streams. AFAIK we >>>>>> have not written down anything that calls for that. (If I am >> wrong, >>>>>> please let me know where this is specified.) >>>>>> >>>>>> We have the (largely hypothetical) recipient capabilities message, >>>>>> but its content hasn't been specified yet, and AFAIK there has >> been >>>>>> no statement that it is binding and the construction of the >>>> advertisement. >>>>>> >>>>>>>> Of course, the number of "capture scenes" _could_ be >> small >>>>>>>> enough to give each it's own video monitor -- but I don't think >>>>>>>> that's the general case we should design for. >>>>>>> >>>>>>> IIUC an endpoint will typically only advertise one or two scenes. >>>>>>> One would correspond to the cameras and mics in its room. The >>>> other, >>>> >>>>>>> if present, would correspond to a "presentation" that doesn't fit >>>>>>> into the coordinate space of the room. There are cases for more, >>>> but >>>> >>>>>>> they get more obscure. >>>>>>> >>>>>>> So for a point-to-point clue call the recipient will only need to >>>>>>> map one or two scenes. But when there is more than one it is more >>>>>> complex, >>>>>>> requiring sharing of equipment. >>>>>>> >>>>>>> The situation is more complex for an MCU. It will have as input >>>>>>> all the scenes offered by all the endpoints. It then has to >> decide >>>>>>> what >>>>>> to >>>>>>> offer out to the endpoints. It could just pass through all the >>>>>>> scenes it receives from all the endpoints, leaving the mapping >>>>>>> problem entirely to the endpoints. (I don't think that is what >>>>>>> most people have in mind, though some might.) >>>>>>> >>>>>>> Or it could take on itself the job of mapping/mixing/switching >> all >>>>>>> of those inputs and producing something more like what a typical >>>>>> endpoint >>>>>>> would advertise - one or two scenes each with just a few >> captures. >>>>>>> >>>>>>> Or it could do both - advertise its own simplified composite >>>>>>> scenes and also all those provided by the endpoints. That would >>>>>>> allow the endpoints to either take the easy way out, or else do >> it >>>>>>> all themselves in a way that suits them. Suppose it did this. >>>>>>> Would the endpoints that want to take the easy way be able to >>>>>>> figure out >>>> which >>>> >>>>>>> scenes and captures to use? >>>>>>> >>>>>>> [Espen] This sounds closer to a user experience discussions than >> a >>>>>>> protocol discussion. >>>>>> >>>>>> Perhaps it is. But the point of CLUE is to develop a protocol that >>>>>> enables an especially good user experience. While we shouldn't >>>>>> mandate the user experience, I think we are obligated to do due >>>>>> diligence that the protocol is sufficient to enable that user >>>> experience. >>>>>> >>>>>>>> OTOH, with an appropriate "surround-sound" system, you >> can >>>>>> "place" >>>>>>>> an arbitrarily large number of audio streams, yet make them easy >>>> to >>>> >>>>>>>> distinguish. >>>>>>>> >>>>>>>>> If you don't have sufficient equipment to do that, then the job >>>> is >>>> >>>>>>>>> harder, and more information is needed to figure out what to >> do. >>>>>>>> >>>>>>>> Only marginally harder... >>>>>>>> >>>>>>>>> For instance: >>>>>>>>> >>>>>>>>> - If you don't have suitable displays, then perhaps you can >>>> select >>>>>> a >>>>>>>>> video capture scene entry and locally compose or switch some of >>>>>>>>> the captures in order to produce a set of captures that does >> map >>>>>>>>> to the available displays. The area of capture of each capture >>>>>>>>> could be helpful to doing this, and perhaps the composed >>>> attribute >>>> as well. >>>>>>>> >>>>>>>> One inevitable use case is filing your formal report from >>>> the >>>>>>> airport. >>>>>>>> The person doing so will have lousy audio, vastly inadequate >>>> video, >>>> >>>>>>>> and typically inadequate bandwidth with excessive latency. S/he >>>>>>>> will need some middlebox to compose a "barely-adequate video" >> and >>>>>>>> mono >>>>>>> audio. >>>>>>> >>>>>>> This is indeed an interesting case - one we have explicitly put >> in >>>>>>> scope. If an MCU is already in the call then perhaps we can hope >>>>>>> that is one of the entries it makes available. >>>>>>> >>>>>>> If there isn't any MCU in the call, then the other endpoint might >>>>>>> not advertise that option. Then what? Do we have a mechanism for >>>> that? >>>>>>> [Espen] If an MCU detect low bandwidth or packet loss it can >> start >>>>>>> using its normal recovery mechanisms. That could lower bitrate >> for >>>>>>> audio and video (maybe by a SIP re-invite), change the CLUE offer >>>> to >>>> >>>>>>> something that fits inside the available bandwidth. Getting good >>>>>>> quality audio ande video is always a challenge, with or without >>>> clue. >>>>>>> >>>>>>>> Then there's the use case of filing you formal report >> from >>>>>>>> your home office (when you're sick or somebody doesn't want to >>>>>>>> pay travel >>>>>>> cost). >>>>>>>> You may well have surround-sound and two or three large >> monitors, >>>>>>>> 20 Mbps download with 40 msec RTT, and a decent-quality lavalier >>>> mike. >>>>>>>> You still probably want some middlebox to compose your basic >>>> video, >>>> >>>>>>>> but you can take individual streams as well to concentrate on >>>>>>> particular people. >>>>>>>> >>>>>>>> Near the top end are the corporate telepresence rooms. >>>>>>>> They >>>>>> will >>>>>>>> want all streams, and are likely to have a human being mixing >>>> them. >>>>>>> >>>>>>> I don't understand your point "are likely to have a human being >>>>>> mixing >>>>>>> them". Can you explain further? >>>>>>> [Espen] I see this as mostly a request for focusing in on >>>> particular >>>> >>>>>>> user. In a transcoded conference you can do that by looking into >>>>>> XCon, >>>>>>> if you do switched conference the endpoint typically render the >>>>>> layout >>>>>>> and can choose who to focus on. Mixing transcoded and switched >>>>>>> conferencing I think makes it unnecessary complex for the initial >>>>>>> use cases to cover. >>>>>>> >>>>>>>>> - or rather than compose to fit your displays, you could >>>> switch... >>>>>>>> >>>>>>>> Folks _will_ do that -- I can't stop them. But I find it >>>>>>> uninteresting. >>>>>>> >>>>>>> ??? We have been talking about switching a lot. Are you saying >>>>>>> that >>>>>> is >>>>>>> uninteresting? >>>>>>> >>>>>>> If it makes sense for a middlebox to switch, doesn't it make >> equal >>>>>>> sense for an endpoint to do so? >>>>>>> >>>>>>>>> - handling video from multiple scenes probably presents some >>>> added >>>> >>>>>>>>> issues. By definition there is no specified spatial >> relationship >>>>>>>>> between the captures of different scenes... >>>>>>>> >>>>>>>> Nonetheless, the participants will want to imagine such a >>>>>>> relationship. >>>>>>> >>>>>>> ISTM that this needs further discussion. >>>>>>> >>>>>>>>> - If you don't have sufficient speakers for all of the audio >>>>>>>>> captures, then you have to decide to mix, switch, or drop some. >>>>>>>> >>>>>>>> There really isn't any such thing as "sufficient >>>>>>>> speakers", but surround-sound should be considered "sufficient". >>>>>>>> You can always mix to stereo or even mono: "you pays your money >>>>>>>> and you takes your >>>>>>> choice". >>>>>>> >>>>>>> Do we have enough information to do it "right" or "well"? >>>>>>> Right now the coordinate info is all optional. Does it need to be >>>>>>> mandatory in order to enable this? >>>>>>> >>>>>>>>> The spatial information from the captures may help in deciding >>>> how >>>> >>>>>>>>> to >>>>>>> >>>>>>>>> mix. >>>>>>>> >>>>>>>> Absolutely! >>>>>>>> >>>>>>>>> Not evident that the mixed attribute helps with this >>>>>>>> >>>>>>>> It help you know when mixing is less likely to work well. >>>>>>>> >>>>>>>>> - unless it is used to decide to switch rather than mix. >>>>>>>> >>>>>>>> I'm not sure there is any such thing. "Mixing" frequently >>>>>>>> includes >>>>>>> >>>>>>>> "riding gain" to reduce background noise. Binary switching is >>>>>>>> just a bad idea. >>>>>>> >>>>>>> I have no special understanding of this. I'm just asking probing >>>>>>> questions in hopes that it will result in the right decisions >>>>>>> being made and the right stuff specified. >>>>>>> >>>>>>>>> Of course if you are mapping independent audio captures onto >>>>>>>>> different speakers then they are being implicitly mixed. >>>>>>>> >>>>>>>> Not a useful way to think about it, IMHO. Human ears and >>>>>>>> brains can sort out individual sources if there are enough >>>>>>>> speakers, while mixing makes that harder. >>>>>>> >>>>>>> I have had the impression that "simple" clue telepresence rooms >>>>>>> would be hoping to do direct mapping of captures to devices. If >>>>>>> the assumption is that this will be an unsatisfactory approach >> and >>>>>>> all endpoints should be prepared to do something more complex >> then >>>>>>> it would be helpful to write that down somewhere - e.g. in the >>>>>> framework. >>>>>>> >>>>>>> [Espen] Agree with Paul here, the basic scenario is well >>>> understood. >>>>>> A >>>>>>> sends two logical audio captures and a receiver play them out >> with >>>>>> the >>>>>>> same spatial relationship. As rule of thumb here could be that >> for >>>>>>> basic interoperability between vendors you assume pairs of audio >>>> and >>>> >>>>>>> video captures that can be easily rendered on matching pairs of >>>>>>> screens and speaker. >>>>>>> >>>>>>>>> - If you don't have speakers with similar spatial relationship >>>>>>>>> to those of the audio captures, then you must decide whether to >>>>>>>>> do sub-optimal assignments or mix. >>>>>>>> >>>>>>>> I suppose _some_ telepresence system will hide dozens of >>>>>>>> speakers in the telepresence room and try to do this -- to me it >>>>>>>> sounds like a dreadful idea, but it's quite possible the people >>>>>>>> will >>>>>> adapt. >>>>>>>> >>>>>>>> "Sub-optimal" really doesn't have a clear meaning here. >>>>>>>> Even speakers in the "wrong" left-to-right order while you can >>>>>>>> see the "correct" order on-screen won't confuse the listener as >>>>>>>> much as speaker assignments changing for no obvious reason. >>>>>>>> >>>>>>>>> Again not clear if the mixed attribute helps with this. >>>>>>>> >>>>>>>> As an extreme example, you could always render "mixed" in >>>> mono. >>>>>>>> >>>>>>>>> - If you have audio from more than one scene, what should you >> do >>>>>>>>> with >>>>>>> >>>>>>>>> it? Should you mix, even though you have no spatial >>>> relationships? >>>>>>>> >>>>>>>> IMHO, you should _invent_ a spatial relationship in that >>>> case. >>>>>>>> Even if each room invents a different spatial relationship, it >>>> will >>>> >>>>>>>> prove less confusing. >>>>>>>> >>>>>>>>> Or should you switch based on active speaker? >>>>>>>> >>>>>>>> Only if background-noise is a serious problem. >>>>>>>> >>>>>>>>> What would help you to decide? >>>>>>>> >>>>>>>> It becomes quickly obvious to the listener! >>>>>>>> >>>>>>>>> The problems are superficially different for MCUs. But perhaps >>>>>>>>> only superficially. It seems to me that when the MCU decides >> how >>>>>>>>> to map its inputs into its advertisement, it has some virtual >>>> room >>>> >>>>>>>>> layouts >>>>>>> in mind. >>>>>>>> >>>>>>>> I would expect so. >>>>>>>> >>>>>>>>> So for each virtual room layout it is addressing the same >> issues >>>>>>>>> as a >>>>>>> >>>>>>>>> real endpoint with that layout. But it does have the added >>>> problem >>>> >>>>>>>>> of >>>>>>> >>>>>>>>> deciding how to describe what it is advertising - e.g. when to >>>>>> apply >>>>>>>>> the mixed/composed attributes. >>>>>>>> >>>>>>>> Pretty much always, unless it's feeding an exact copy of >>>> what >>>>>> it >>>>>>>> receives. >>>>>>> >>>>>>> Since I've seen people here describe cases when that isn't so, it >>>>>>> would be helpful to have a more precise definition. >>>>>>> >>>>>>>>> Some interesting use cases for all of the above would be very >>>>>>> helpful. >>>>>>>> >>>>>>>> Did the cases I listed help? >>>>>>> >>>>>>> I think they need to be worked out in much more detail: >>>>>>> >>>>>>> - what equipment (input and output) is in each endpoint, and >> where. >>>>>>> - what is advertised and how the input equipment is mapped to >>>>>>> the advertisement >>>>>>> - how each endpoint maps the advertised captures to its output >>>>>> equipment >>>>>>> together with how the info in the advertisement allowed it >> to >>>>>>> determine that mapping. >>>>>>> >>>>>>> [Espen] Agree, being practical about what we will offer for >> actual >>>>>>> endpoints are useful. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> > > From ron.even.tlv@gmail.com Tue Apr 17 14:55:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DFD11E8089 for ; Tue, 17 Apr 2012 14:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2j-0BbbgLaU for ; Tue, 17 Apr 2012 14:55:31 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E215611E8086 for ; Tue, 17 Apr 2012 14:55:30 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4648239wgb.13 for ; Tue, 17 Apr 2012 14:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=EMCc64rKCU/hd92mIaN5oNGCzGhArd/9rD/My8fM8ko=; b=h1P4aCsf/aTkow+iNlkr2/FMLlH7gdDWdoeinzGcg7ornVPyhbThVxq2b40TMIQxOB lktYoYdGN73wGvl+6oCzVn2qstbKS/taGzQoFKmG/IL8OX03G+ZVBjZLj5sl8N8XHcz6 YqA3W+UR0pwCmJKUwsPxJ+P7xTmCKiPovvQNQoyt1rqcJ8gtvlN+uHZmKkH7J+9lFQuv cOes/kOvfMqnEQ7EyVWyDue4GJUs+2epxaysMhHK2F71wC9sMm9GlEzBZp8Lyg3MuKG+ TljIHHMoDuQr59Dmq2DJj+U3snD5AdZVj0w9hHzybL/NtfsRjHTh4HLAWMx2FoxLdO4S WvNw== Received: by 10.216.132.8 with SMTP id n8mr10031356wei.36.1334699730094; Tue, 17 Apr 2012 14:55:30 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id o2sm47747019wiv.11.2012.04.17.14.55.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 14:55:28 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <4F846AE0.4010700@alum.mit.edu> <20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> <4F8CAC7F.7040405@alum.mit.edu> <20120417201714.GB99904@verdi> <4F8DD467.4060402@alum.mit.edu> In-Reply-To: <4F8DD467.4060402@alum.mit.edu> Date: Wed, 18 Apr 2012 00:53:55 +0300 Message-ID: <4f8de6d0.e249b40a.17fd.ffff8a0d@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0c2d1OD7hACoPoTXiAGDF60O1e/QACawxQ Content-Language: en-us Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 21:55:35 -0000 Hi Paul, I fully agree that there is a difference between centralized conferences with MCUs and point to point case. My experience with MCUs is that they wish to provide the best experience to all participants (they may have better support for the endpoints from the same vendor). Since the MCUs cannot be sure what functionality will be supported by the end points that they will meet in the field (I am talking here about the solution design phase) they have some out of band mechanism that allows the use of the endpoint to interact with the MCU conferencing application in order to control the conference including the views that the participants will see. Therefore I do not see much value in having a protocol for that and I had similar feedback to XCON work of which I only see the event package as an important block. As for point to point I think that the current information is sufficient. The sender will provide the capture set entries but if it provides the simultaneous sets that consumer can ask for the capture he wants regardless of the capture set entries which reflect the provider preference. Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, April 17, 2012 11:37 PM > To: clue@ietf.org > Subject: Re: [clue] Does framework provide sufficient info for > receiver? > > On 4/17/12 4:17 PM, John Leslie wrote: > > > My point is that vendors _should_ want to give a "familiar" > > experience to their customers, and it will at least subtly differ > from > > the experience other vendors offer. > > How should I read the above when systems from two different vendors are > interoperating? I can see this in two ways: > > - the receiving system will endeavor to adapt the advertised > information from the provider to produce the kind of experience the > receiving system prefers. > > - the providing system may want to do what it can to cause the > receiving system to give the experience the providing system prefers. > > Absent some counteracting force systems will probably try to do both, > though they are in some sense conflicting goals. > > Presumably the receiving system could come closest to providing its > familiar experience to its customers if the providing system makes > available all the raw captures and sufficient information to understand > what they are. But that assumes the receiving system has sufficient > bandwidth and processing capacity. > > As soon as the sending system starts processing the captures, > especially if it then fails to make all the raw captures available, it > is putting its imprint on the receiving system's user experience. > > Maybe it would make sense to distinguish here between behavior of > endpoints and MCUs. We may expect an MCU to have a stronger influence > on endpoint user experience than we do in a point to point session. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Tue Apr 17 15:01:30 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049AF11E80DE for ; Tue, 17 Apr 2012 15:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoa9gJFFTU2C for ; Tue, 17 Apr 2012 15:01:25 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8CF11E80B1 for ; Tue, 17 Apr 2012 15:01:25 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so13756wib.13 for ; Tue, 17 Apr 2012 15:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=XrnbTpKhIvljfQM6fFYkf0HXVyLVw7N6WuABzrcGIO0=; b=AQFaGEnMPZXjxiKIPOqrM7VU4aEY7mBIKjrzVizMg8Af9Kdaapw81zA2tUZcFs+i2H MOtEMgHozQVNJadOVek9eJhdjV4zbOPJ8HGKKtl8ZBJfu2IktIHyRpqcBQ72fd6t2Y6L EGDhSel2Jx1y0mBz0xf0W/gEaqYqK3gmdGYbQScbBbYecB4485sEzh6iuguM8nl8GpJJ TUbrKOk5ixwUUrjHZNcmB2xvKclgA3IGESbebxvAUOHqnkKPIfGnca2fJW6T2CM4hg1V e+C6dncUA9HRDOOEdC3ecWsUaQVive5KHwObC3DmKtpSJkVbzHLcVmogailxa6MAOszT 7MQQ== Received: by 10.180.86.132 with SMTP id p4mr258116wiz.15.1334700084445; Tue, 17 Apr 2012 15:01:24 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id fl2sm47798258wib.2.2012.04.17.15.01.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 15:01:23 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <4F846AE0.4010700@alum.mit.edu><20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com><4F873CCE.3020806@alum.mit.edu><4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> <4f8d7ccb.2266b40a.1ceb.fffffc00@mx.google.com> <4F8DBA26.8010705@alum.mit.edu> <4f8ddfa7.f44cb40a.72e3.7f2a@mx.google.com> <4F8DE2B9.2070607@alum.mit.edu> In-Reply-To: <4F8DE2B9.2070607@alum.mit.edu> Date: Wed, 18 Apr 2012 00:59:49 +0300 Message-ID: <4f8de833.2266b40a.1ceb.ffff9215@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0c4l4RcVRb3EnFTjGuFrl/nCVkgAAAk83g Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 22:01:30 -0000 Paul, Inline Roni > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Wednesday, April 18, 2012 12:38 AM > To: Roni Even > Cc: 'Brian Baldino (bbaldino)'; 'CLUE' > Subject: Re: [clue] Does framework provide sufficient info for > receiver? > > Hi Roni, > > On 4/17/12 5:23 PM, Roni Even wrote: > > Paul, > > This is one capture scene entry since they can be provided > simultaneously. > > As I understand, its possible to get things from multiple entries > simultaneously. (But whether its possible or not depends on the > simultaneous set entries.) > > Being in a single entry should mean that all the captures in the entry > together represent the scene. I *think* putting all the fixed captures > *and* a switched capture that switches among those fixed ones would be > valid, though it does involve some redundancy. (I'd be interested to > hear if others think this is appropriate.) There is such example in the framework document for a simultaneous set that includes redundant information. Note that the consumer can create his own preferred views based on the capture set entries and simultenous sets. The capture set entries represent the provider preference. > > > The consumer can ask for a subset of the entry and not all four > > captures. It can ask first for the switched and any one of the fixed > > and when the active speaker changes it can ask for a different fixed > > capture from the 3 fixed captures. > > While I see how that would be possible, having to send a new select > request on the clue channel every time there is a speaker switch might > be unacceptable. Even worse if that also required an o/a exchange. (But > maybe it won't require that.) > > > I also think that there is nothing that will prevent the receiver to > > ask for the three fixed and display 2 of them except we do not have a > > way to say which ones are the most active speaker. This is why the > > switched one is needed I do not think this is an issue since switching decision is a slow process in order to prevent frequent switches when not needed. Note that switching may require new video synchronization point. > > We need sufficient information to determine active speaker. > Is getting a switched capture, where the switching criterion is active > speaker, the only way to do that? Currently I think this is the case as long as we get one audio stream for the three video captures. > > Thanks, > Paul > > > Roni > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Tuesday, April 17, 2012 9:45 PM > >> To: Roni Even > >> Cc: 'Brian Baldino (bbaldino)'; 'CLUE' > >> Subject: Re: [clue] Does framework provide sufficient info for > >> receiver? > >> > >> Hi Roni, > >> > >> On 4/17/12 10:21 AM, Roni Even wrote: > >>> Hi, > >>> My view is that in this case the provider can advertise the three > >>> fixed captures and one with switched which may be the active > speaker. > >> > >> Do you mean one capture scene entry containing all four of these > >> captures? Or do you mean one capture scene entry with the three > fixed > >> captures, and another one containing just the switched capture? > >> > >>> We will need > >>> a way to let the consumer know who is the current speaker enabling > >> him > >>> to choose the switched active speaker stream and one of the fixed > >>> streams which may be the previous speaker. > >> > >> So in that case the consumer would receive all four captures, and > >> render the switched capture plus dynamically select one of the > others > >> to render? > >> > >> If so, how is that any easier than simply receiving the three fixed > >> captures and making its own decision about which two to render based > >> on tracking speakers? That would have the benefit of requiring one > >> less stream to be received. But it would still require receiving > more > >> streams than if it could select two offered by the provider that > >> provide a good experience for a two screen system. > >> > >> Thanks, > >> Paul > >> > >>> Roni > >>> > >>>> -----Original Message----- > >>>> From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] > >>>> Sent: Tuesday, April 17, 2012 2:19 AM > >>>> To: Paul Kyzivat; Roni Even > >>>> Cc: CLUE > >>>> Subject: RE: [clue] Does framework provide sufficient info for > >>>> receiver? > >>>> > >>>> Hey Paul, with regards to this bit: > >>>> > >>>> "For instance, suppose the sender does something to combine some > of > >>>> its captures so that it can advertise a capture scene entry that > >>>> requires fewer displays. E.g. suppose it has three main captures > of > >>>> participants and one presentation capture. And suppose in addition > >> to > >>>> advertising all of those as one entry, it also advertises another > >>>> entry for a three-screen room, consisting of one capture for the > >>>> presentation, one for the current speaker, and one for the prior > >>>> speaker. So that is one fixed and two switched captures. If the > >>>> recipient need to map this to two displays, how does it decide > what > >>>> to do? The obvious thing would be to omit the capture for the > prior > >>>> speaker. But how would it know which one that is." > >>>> > >>>> My understanding was more that the provider would advertise all > >> valid > >>>> views with a capture entry for each, not require (or rely on) an > >>>> endpoint to be able to "find" a valid view which is a subset of > one > >>>> that was actually advertised; therefore relieving the consumer of > >>>> that responsibility. So in this case, the provider would > advertise > >>>> entries that contained: > >>>> 1) Just the active speaker > >>>> 2) The active speaker and previous active speaker > >>>> 3) The active speaker, previous active speaker and presentation > >>>> (Maybe even a 4th that contained the active speaker and > >> presentation) > >>>> > >>>> The idea being that the provider is smart enough to know/advertise > >>>> its valid views rather than rely on the consumer to figure them > out. > >>>> > >>>> Even with this there are still situations where no advertised view > >> is > >>>> ideal for the consumer, maybe this is the situation you're > >>>> referring to? > >>>> I'd hoped that the consumer could get away with choosing the "next > >>>> best fit" using information already in the advertisement (how many > >>>> captures an entry consists of, switched vs. non-switched, area of > >>>> capture info, > >>>> etc.) > >>>> > >>>> -Brian > >>>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Monday, April 16, 2012 7:35 AM > >>>> To: Roni Even > >>>> Cc: 'CLUE' > >>>> Subject: Re: [clue] Does framework provide sufficient info for > >>>> receiver? > >>>> > >>>> Hi Roni, > >>>> > >>>> On 4/15/12 11:20 AM, Roni Even wrote: > >>>>> Hi Paul, > >>>>> I think that there is enough information that will allow a > >>>>> receiver > >>>> to > >>>> > >>>>> select N out of M streams. > >>>>> The receiver will know the semantics of the streams (people or > >>>>> presentation) and the spatial information of the room and the > >>>> different streams. > >>>>> My view is that this is enough for the general telepresence point > >> to > >>>>> point use case. > >>>> > >>>> I think I agree for the case where there is a single scene > >>>> advertised, and all the captures represent single cameras. > >>>> > >>>> But as soon as you add in mixed or switched captures it becomes > far > >>>> less clear. > >>>> > >>>> For instance, suppose the sender does something to combine some of > >>>> its captures so that it can advertise a capture scene entry that > >>>> requires fewer displays. E.g. suppose it has three main captures > of > >>>> participants and one presentation capture. And suppose in addition > >> to > >>>> advertising all of those as one entry, it also advertises another > >>>> entry for a three-screen room, consisting of one capture for the > >>>> presentation, one for the current speaker, and one for the prior > >>>> speaker. So that is one fixed and two switched captures. If the > >>>> recipient need to map this to two displays, how does it decide > what > >>>> to do? The obvious thing would be to omit the capture for the > prior > >>>> speaker. But how would it know which one that is. > >>>> > >>>>> As for multipoint use case, this is why I think it is important > to > >>>>> know if the advertisement is based on site switch or segment > >>>>> switch which will provide the extra information needed for the > >>>>> selection (spatial information provides the internal relation > >>>>> between the > >>>>> capture) and I think that the audio level will help with knowing > >> who > >>>>> are the active speakers in this case > >>>> > >>>> I think there are too many unknowns in the above to discuss it > with > >>>> clarity. We need some use cases. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Roni > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>>>> Behalf Of Paul Kyzivat > >>>>>> Sent: Thursday, April 12, 2012 11:37 PM > >>>>>> To: Espen Berger (espeberg) > >>>>>> Cc: CLUE > >>>>>> Subject: Re: [clue] Does framework provide sufficient info for > >>>>>> receiver? > >>>>>> > >>>>>> Espen - comments inline. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>>> On 4/11/12 12:55 PM, Espen Berger (espeberg) wrote: > >>>>>>> During the CLUE design team meeting on webex yesterday we > >>>>>>> started > >>>> to > >>>> > >>>>>>> discuss various use cases and if they are in scope or not for > >>>>>>> the current work in CLUE. > >>>>>>> > >>>>>>> As a part of my response to Pauls questions I summarized the > use > >>>>>> cases > >>>>>>> and grouped them into supported / not supported. I can dive > into > >>>>>>> more detail about the use cases if people are interested? > >>>>>>> > >>>>>>> I would answer yes to the following use cases > >>>>>>> * Telepresence point to point, where the reproduction will > >>>>>>> happen > >>>> in > >>>>>> a > >>>>>>> 2D-plane for audio and video. Currently CLUE support announcing > >>>>>>> capability of sending 1 - N capture (left to right) and a > >> receiver > >>>>>> can > >>>>>>> request 1 - M streams for rendering (left to tight), which is > >>>>>>> the basic for interoperability. > >>>>>> > >>>>>> In this case, suppose N> M. Who is responsible for deciding > >> which M > >>>>>> of the N streams will be used? AFAIK the recipient just picks > the > >>>>>> ones it wants. So then my question remains - does the recipient > >>>>>> have sufficient info to select the "right" ones? (There isn't > any > >>>>>> guarantee that *any* N of the M streams will provide a > reasonable > >>>> rendering. > >>>>>> > >>>>>> This would be improved if we had a mechanism for the recipient > to > >>>>>> state "I can only handle N streams" and the sender was obligated > >> to > >>>>>> meet that constraint. I don't think we have said that. > >>>>>> > >>>>>>> * Transcoded conferencing, where the MCU act like an endpoint > >>>>>>> and logically announces audio and video left to right and a > >>>>>>> receiver request > >>>>>>> 1 - M captures depending on how many screen and audio streams > >>>>>>> you prefer. Typically a single video stream pr. screen and one > >>>>>>> audio > >>>> pr. > >>>>>>> screen (mono/stereo). Excluded is capabilities to select > >>>>>>> individual speakers, the MCU is free to optimize what to > compose > >>>>>>> and send to a receiver. > >>>>>> > >>>>>> This is logically equivalent to the prior case. > >>>>>> > >>>>>>> * Generic multi source, sending and receiving named sources > >>>>>>> where the user experience is controlled by an human being > >>>>>>> capable of reading sources names, or control software written > >>>>>>> explicit to operate on the named streams. The content attribute > >>>>>>> can be used > >> to > >>>>>>> indicate a > >>>>>> primary > >>>>>>> role, RFC4796 uses 'main' and 'alt'. > >>>>>> > >>>>>> Are you talking about the text names/labels we were discussing > on > >>>> the > >>>> > >>>>>> last call? > >>>>>> > >>>>>> If so, I agree that if the senders provide well conceived labels > >>>> then > >>>> > >>>>>> a human can probably decide something reasonable. > >>>>>> > >>>>>> If the human is working only with "content" attributes, then its > >>>>>> not so clear. Its quite possible that the recipient will find > >>>>>> itself trying to choose between multiple streams with the same > >>>>>> content > >>>> type. > >>>> > >>>>>> (E.g. all > >>>>>> 'main'.) > >>>>>> > >>>>>>> I would answer no, to the following use cases > >>>>>>> * Switched conferencing, where we assume that endpoints do > >>>>>>> scalable video (either SVC or Simulcast), locally composited > >>>>>>> layout and > >>>> audio > >>>> > >>>>>>> mixing. Limited work has been done on how to use Scalable video > >>>>>>> and how to build mechanisms for complete composited layouts. > >>>>>>> * Advanced audio reproduction, a group of audio scenarios > >>>>>>> mentioned > >>>>>> by > >>>>>>> Jon Leslie and Johan Nielsen that requires more details during > >>>>>> initial > >>>>>>> signalling and more dynamic information for transferring > dynamic > >>>>>>> meta-information. > >>>>>>> * Multi view, as described in the CLUE use case document. > >>>>>>> > >>>>>>> (Other comments inline.) > >>>>>>> > >>>>>>> Cheers > >>>>>>> > >>>>>>> -Espen > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>> Behalf > >>>> > >>>>>>> Of Paul Kyzivat > >>>>>>> Sent: 11. april 2012 17:06 > >>>>>>> To: John Leslie > >>>>>>> Cc: CLUE > >>>>>>> Subject: Re: [clue] Does framework provide sufficient info for > >>>>>> receiver? > >>>>>>> > >>>>>>> Hi John, > >>>>>>> > >>>>>>> Thanks for the comments. I've followed up inline. > >>>>>>> > >>>>>>> On 4/10/12 5:09 PM, John Leslie wrote: > >>>>>>>> Paul Kyzivat wrote: > >>>>>>>>> > >>>>>>>>> The fundamental problem in the scope of CLUE is, if you are > an > >>>>>>>>> endpoint, and you have received an advertisement, with some > >>>> scenes > >>>> > >>>>>>>>> and captures, do you have sufficient information to select > and > >>>> map > >>>> > >>>>>>>>> the advertised scenes/captures onto the equipment you have? > >>>>>>>> > >>>>>>>> Of course not! > >>>>>>>> > >>>>>>>> If we wanted that, we'd have to include for every > >> composed > >>>>>> scene > >>>>>>>> what it's composed from, and for every mixed audio what it's > >>>>>>>> mixed from. > >>>>>>> > >>>>>>> I think you must have misunderstood me. Otherwise I wouldn't > >>>>>>> expect you to answer "Of course not". AFAIK the whole point of > >>>>>>> CLUE is to provide the information to make this possible. > >>>>>>> > >>>>>>> My point in asking the question was so that we can identify > what > >>>>>>> information we have overlooked that we need to include one way > >>>>>>> or another. > >>>>>>> > >>>>>>> Clearly there are some tradeoffs. More information might > support > >>>>>>> *better* mappings. So one thing to decide is how good is good > >>>> enough. > >>>>>>> [Espen] Agree with Paul, we clearly can support in CLUE the use > >>>>>>> cases where a Telepresence room either offer a 1, 2 or 3 video > >>>>>>> captures, which can be rendered on 1, 2 or 3 screens. > >>>>>> > >>>>>> I think its clear we can support cases where every advertisement > >>>> that > >>>> > >>>>>> includes an entry for N (>1) captures also includes an entry > with > >>>>>> only one capture, and optionally entries containing other > numbers > >>>>>> of captures between 1 and N. > >>>>>> > >>>>>> But as I mention above, its not clear we have supported case > >>>>>> where the minimal entry in the advertisement is for N>1 > captures. > >>>>>> > >>>>>>>>> If you have sufficient equipment (displays, speakers) with > >>>>>>>>> compatible > >>>>>>> > >>>>>>>>> geometry to directly map all of the captures from one audio > >>>>>>>>> and one video capture scene entry from each capture scene > then > >> maybe > >>>>>>>>> all is good. In this case ISTM that the mixed/composed > >>>>>>>>> attributes aren't needed. > >>>>>>>> > >>>>>>>> It's unlikely that the "typical" telepresence > >>>>>>>> conference > >>>> will > >>>> > >>>>>>>> have > >>>>>>> > >>>>>>>> a separate screen for every possible video. > >>>>>>> > >>>>>>> That isn't what I said. Consider what is perhaps a typical > case, > >>>>>> where > >>>>>>> the advertisement contains one scene with several alternative > >>>>>>> video and audio scene entries. Lets just consider the video. > >>>>>>> Then maybe there is one entry with three captures, and another > >>>>>>> with > >> one > >>>>>>> (mixed/switched, > >>>>>>> whatever) capture. Then if you have three screens you can map > >>>>>>> all three captures in the first entry. If you have less than > >>>>>>> three > >>>>>> screens > >>>>>>> then you can map the one capture from the 2nd entry onto one of > >>>> your > >>>>>> screens. > >>>>>>> > >>>>>>> But what if there was no entry with a single capture? If you > had > >>>> two > >>>> > >>>>>>> screens, would you have enough info about the three captures in > >>>>>>> the first entry to make a reasonable mapping onto your two > >> screens? > >>>> What > >>>> > >>>>>>> information would we need to include in the advertisement so > >>>>>>> that > >>>> it > >>>> > >>>>>>> would be possible to do this mapping well? > >>>>>>> > >>>>>>> [Espen] How a vendor build a room or endpoint is transparent > >>>>>>> from the sender of media. As a sender you should not care if a > >>>>>>> room request 3 audio streams (left, center, right) and choose > to > >>>>>>> mix and play out on a single speaker. We can argue that this is > >>>>>>> not the > >>>> best > >>>> > >>>>>>> experience, but still valid and typically done for PC-clients > or > >>>>>>> other endpoints with a single speaker. > >>>>>> > >>>>>> Again, I think you are assuming the receiver can specify the max > >>>>>> number of streams it can handle, and that the sender will then > be > >>>>>> obligated to select/construct a suitable set of streams. AFAIK > we > >>>>>> have not written down anything that calls for that. (If I am > >> wrong, > >>>>>> please let me know where this is specified.) > >>>>>> > >>>>>> We have the (largely hypothetical) recipient capabilities > >>>>>> message, but its content hasn't been specified yet, and AFAIK > >>>>>> there has > >> been > >>>>>> no statement that it is binding and the construction of the > >>>> advertisement. > >>>>>> > >>>>>>>> Of course, the number of "capture scenes" _could_ be > >> small > >>>>>>>> enough to give each it's own video monitor -- but I don't > think > >>>>>>>> that's the general case we should design for. > >>>>>>> > >>>>>>> IIUC an endpoint will typically only advertise one or two > scenes. > >>>>>>> One would correspond to the cameras and mics in its room. The > >>>> other, > >>>> > >>>>>>> if present, would correspond to a "presentation" that doesn't > >>>>>>> fit into the coordinate space of the room. There are cases for > >>>>>>> more, > >>>> but > >>>> > >>>>>>> they get more obscure. > >>>>>>> > >>>>>>> So for a point-to-point clue call the recipient will only need > >>>>>>> to map one or two scenes. But when there is more than one it is > >>>>>>> more > >>>>>> complex, > >>>>>>> requiring sharing of equipment. > >>>>>>> > >>>>>>> The situation is more complex for an MCU. It will have as input > >>>>>>> all the scenes offered by all the endpoints. It then has to > >> decide > >>>>>>> what > >>>>>> to > >>>>>>> offer out to the endpoints. It could just pass through all the > >>>>>>> scenes it receives from all the endpoints, leaving the mapping > >>>>>>> problem entirely to the endpoints. (I don't think that is what > >>>>>>> most people have in mind, though some might.) > >>>>>>> > >>>>>>> Or it could take on itself the job of mapping/mixing/switching > >> all > >>>>>>> of those inputs and producing something more like what a > typical > >>>>>> endpoint > >>>>>>> would advertise - one or two scenes each with just a few > >> captures. > >>>>>>> > >>>>>>> Or it could do both - advertise its own simplified composite > >>>>>>> scenes and also all those provided by the endpoints. That would > >>>>>>> allow the endpoints to either take the easy way out, or else do > >> it > >>>>>>> all themselves in a way that suits them. Suppose it did this. > >>>>>>> Would the endpoints that want to take the easy way be able to > >>>>>>> figure out > >>>> which > >>>> > >>>>>>> scenes and captures to use? > >>>>>>> > >>>>>>> [Espen] This sounds closer to a user experience discussions > than > >> a > >>>>>>> protocol discussion. > >>>>>> > >>>>>> Perhaps it is. But the point of CLUE is to develop a protocol > >>>>>> that enables an especially good user experience. While we > >>>>>> shouldn't mandate the user experience, I think we are obligated > >>>>>> to do due diligence that the protocol is sufficient to enable > >>>>>> that user > >>>> experience. > >>>>>> > >>>>>>>> OTOH, with an appropriate "surround-sound" system, you > >> can > >>>>>> "place" > >>>>>>>> an arbitrarily large number of audio streams, yet make them > >>>>>>>> easy > >>>> to > >>>> > >>>>>>>> distinguish. > >>>>>>>> > >>>>>>>>> If you don't have sufficient equipment to do that, then the > >>>>>>>>> job > >>>> is > >>>> > >>>>>>>>> harder, and more information is needed to figure out what to > >> do. > >>>>>>>> > >>>>>>>> Only marginally harder... > >>>>>>>> > >>>>>>>>> For instance: > >>>>>>>>> > >>>>>>>>> - If you don't have suitable displays, then perhaps you can > >>>> select > >>>>>> a > >>>>>>>>> video capture scene entry and locally compose or switch some > >>>>>>>>> of the captures in order to produce a set of captures that > >>>>>>>>> does > >> map > >>>>>>>>> to the available displays. The area of capture of each > capture > >>>>>>>>> could be helpful to doing this, and perhaps the composed > >>>> attribute > >>>> as well. > >>>>>>>> > >>>>>>>> One inevitable use case is filing your formal report > >>>>>>>> from > >>>> the > >>>>>>> airport. > >>>>>>>> The person doing so will have lousy audio, vastly inadequate > >>>> video, > >>>> > >>>>>>>> and typically inadequate bandwidth with excessive latency. > S/he > >>>>>>>> will need some middlebox to compose a "barely-adequate video" > >> and > >>>>>>>> mono > >>>>>>> audio. > >>>>>>> > >>>>>>> This is indeed an interesting case - one we have explicitly put > >> in > >>>>>>> scope. If an MCU is already in the call then perhaps we can > hope > >>>>>>> that is one of the entries it makes available. > >>>>>>> > >>>>>>> If there isn't any MCU in the call, then the other endpoint > >>>>>>> might not advertise that option. Then what? Do we have a > >>>>>>> mechanism for > >>>> that? > >>>>>>> [Espen] If an MCU detect low bandwidth or packet loss it can > >> start > >>>>>>> using its normal recovery mechanisms. That could lower bitrate > >> for > >>>>>>> audio and video (maybe by a SIP re-invite), change the CLUE > >>>>>>> offer > >>>> to > >>>> > >>>>>>> something that fits inside the available bandwidth. Getting > good > >>>>>>> quality audio ande video is always a challenge, with or without > >>>> clue. > >>>>>>> > >>>>>>>> Then there's the use case of filing you formal report > >> from > >>>>>>>> your home office (when you're sick or somebody doesn't want to > >>>>>>>> pay travel > >>>>>>> cost). > >>>>>>>> You may well have surround-sound and two or three large > >> monitors, > >>>>>>>> 20 Mbps download with 40 msec RTT, and a decent-quality > >>>>>>>> lavalier > >>>> mike. > >>>>>>>> You still probably want some middlebox to compose your basic > >>>> video, > >>>> > >>>>>>>> but you can take individual streams as well to concentrate on > >>>>>>> particular people. > >>>>>>>> > >>>>>>>> Near the top end are the corporate telepresence rooms. > >>>>>>>> They > >>>>>> will > >>>>>>>> want all streams, and are likely to have a human being mixing > >>>> them. > >>>>>>> > >>>>>>> I don't understand your point "are likely to have a human being > >>>>>> mixing > >>>>>>> them". Can you explain further? > >>>>>>> [Espen] I see this as mostly a request for focusing in on > >>>> particular > >>>> > >>>>>>> user. In a transcoded conference you can do that by looking > into > >>>>>> XCon, > >>>>>>> if you do switched conference the endpoint typically render the > >>>>>> layout > >>>>>>> and can choose who to focus on. Mixing transcoded and switched > >>>>>>> conferencing I think makes it unnecessary complex for the > >>>>>>> initial use cases to cover. > >>>>>>> > >>>>>>>>> - or rather than compose to fit your displays, you could > >>>> switch... > >>>>>>>> > >>>>>>>> Folks _will_ do that -- I can't stop them. But I find > >>>>>>>> it > >>>>>>> uninteresting. > >>>>>>> > >>>>>>> ??? We have been talking about switching a lot. Are you saying > >>>>>>> that > >>>>>> is > >>>>>>> uninteresting? > >>>>>>> > >>>>>>> If it makes sense for a middlebox to switch, doesn't it make > >> equal > >>>>>>> sense for an endpoint to do so? > >>>>>>> > >>>>>>>>> - handling video from multiple scenes probably presents some > >>>> added > >>>> > >>>>>>>>> issues. By definition there is no specified spatial > >> relationship > >>>>>>>>> between the captures of different scenes... > >>>>>>>> > >>>>>>>> Nonetheless, the participants will want to imagine > such > >>>>>>>> a > >>>>>>> relationship. > >>>>>>> > >>>>>>> ISTM that this needs further discussion. > >>>>>>> > >>>>>>>>> - If you don't have sufficient speakers for all of the audio > >>>>>>>>> captures, then you have to decide to mix, switch, or drop > some. > >>>>>>>> > >>>>>>>> There really isn't any such thing as "sufficient > >>>>>>>> speakers", but surround-sound should be considered > "sufficient". > >>>>>>>> You can always mix to stereo or even mono: "you pays your > money > >>>>>>>> and you takes your > >>>>>>> choice". > >>>>>>> > >>>>>>> Do we have enough information to do it "right" or "well"? > >>>>>>> Right now the coordinate info is all optional. Does it need to > >>>>>>> be mandatory in order to enable this? > >>>>>>> > >>>>>>>>> The spatial information from the captures may help in > deciding > >>>> how > >>>> > >>>>>>>>> to > >>>>>>> > >>>>>>>>> mix. > >>>>>>>> > >>>>>>>> Absolutely! > >>>>>>>> > >>>>>>>>> Not evident that the mixed attribute helps with this > >>>>>>>> > >>>>>>>> It help you know when mixing is less likely to work > well. > >>>>>>>> > >>>>>>>>> - unless it is used to decide to switch rather than mix. > >>>>>>>> > >>>>>>>> I'm not sure there is any such thing. "Mixing" > >>>>>>>> frequently includes > >>>>>>> > >>>>>>>> "riding gain" to reduce background noise. Binary switching is > >>>>>>>> just a bad idea. > >>>>>>> > >>>>>>> I have no special understanding of this. I'm just asking > probing > >>>>>>> questions in hopes that it will result in the right decisions > >>>>>>> being made and the right stuff specified. > >>>>>>> > >>>>>>>>> Of course if you are mapping independent audio captures onto > >>>>>>>>> different speakers then they are being implicitly mixed. > >>>>>>>> > >>>>>>>> Not a useful way to think about it, IMHO. Human ears > >>>>>>>> and brains can sort out individual sources if there are enough > >>>>>>>> speakers, while mixing makes that harder. > >>>>>>> > >>>>>>> I have had the impression that "simple" clue telepresence rooms > >>>>>>> would be hoping to do direct mapping of captures to devices. If > >>>>>>> the assumption is that this will be an unsatisfactory approach > >> and > >>>>>>> all endpoints should be prepared to do something more complex > >> then > >>>>>>> it would be helpful to write that down somewhere - e.g. in the > >>>>>> framework. > >>>>>>> > >>>>>>> [Espen] Agree with Paul here, the basic scenario is well > >>>> understood. > >>>>>> A > >>>>>>> sends two logical audio captures and a receiver play them out > >> with > >>>>>> the > >>>>>>> same spatial relationship. As rule of thumb here could be that > >> for > >>>>>>> basic interoperability between vendors you assume pairs of > audio > >>>> and > >>>> > >>>>>>> video captures that can be easily rendered on matching pairs of > >>>>>>> screens and speaker. > >>>>>>> > >>>>>>>>> - If you don't have speakers with similar spatial > relationship > >>>>>>>>> to those of the audio captures, then you must decide whether > >>>>>>>>> to do sub-optimal assignments or mix. > >>>>>>>> > >>>>>>>> I suppose _some_ telepresence system will hide dozens > >>>>>>>> of speakers in the telepresence room and try to do this -- to > >>>>>>>> me it sounds like a dreadful idea, but it's quite possible the > >>>>>>>> people will > >>>>>> adapt. > >>>>>>>> > >>>>>>>> "Sub-optimal" really doesn't have a clear meaning > here. > >>>>>>>> Even speakers in the "wrong" left-to-right order while you can > >>>>>>>> see the "correct" order on-screen won't confuse the listener > as > >>>>>>>> much as speaker assignments changing for no obvious reason. > >>>>>>>> > >>>>>>>>> Again not clear if the mixed attribute helps with this. > >>>>>>>> > >>>>>>>> As an extreme example, you could always render "mixed" > >>>>>>>> in > >>>> mono. > >>>>>>>> > >>>>>>>>> - If you have audio from more than one scene, what should you > >> do > >>>>>>>>> with > >>>>>>> > >>>>>>>>> it? Should you mix, even though you have no spatial > >>>> relationships? > >>>>>>>> > >>>>>>>> IMHO, you should _invent_ a spatial relationship in > >>>>>>>> that > >>>> case. > >>>>>>>> Even if each room invents a different spatial relationship, it > >>>> will > >>>> > >>>>>>>> prove less confusing. > >>>>>>>> > >>>>>>>>> Or should you switch based on active speaker? > >>>>>>>> > >>>>>>>> Only if background-noise is a serious problem. > >>>>>>>> > >>>>>>>>> What would help you to decide? > >>>>>>>> > >>>>>>>> It becomes quickly obvious to the listener! > >>>>>>>> > >>>>>>>>> The problems are superficially different for MCUs. But > perhaps > >>>>>>>>> only superficially. It seems to me that when the MCU decides > >> how > >>>>>>>>> to map its inputs into its advertisement, it has some virtual > >>>> room > >>>> > >>>>>>>>> layouts > >>>>>>> in mind. > >>>>>>>> > >>>>>>>> I would expect so. > >>>>>>>> > >>>>>>>>> So for each virtual room layout it is addressing the same > >> issues > >>>>>>>>> as a > >>>>>>> > >>>>>>>>> real endpoint with that layout. But it does have the added > >>>> problem > >>>> > >>>>>>>>> of > >>>>>>> > >>>>>>>>> deciding how to describe what it is advertising - e.g. when > to > >>>>>> apply > >>>>>>>>> the mixed/composed attributes. > >>>>>>>> > >>>>>>>> Pretty much always, unless it's feeding an exact copy > >>>>>>>> of > >>>> what > >>>>>> it > >>>>>>>> receives. > >>>>>>> > >>>>>>> Since I've seen people here describe cases when that isn't so, > >>>>>>> it would be helpful to have a more precise definition. > >>>>>>> > >>>>>>>>> Some interesting use cases for all of the above would be very > >>>>>>> helpful. > >>>>>>>> > >>>>>>>> Did the cases I listed help? > >>>>>>> > >>>>>>> I think they need to be worked out in much more detail: > >>>>>>> > >>>>>>> - what equipment (input and output) is in each endpoint, and > >> where. > >>>>>>> - what is advertised and how the input equipment is mapped to > >>>>>>> the advertisement > >>>>>>> - how each endpoint maps the advertised captures to its output > >>>>>> equipment > >>>>>>> together with how the info in the advertisement allowed > >>>>>>> it > >> to > >>>>>>> determine that mapping. > >>>>>>> > >>>>>>> [Espen] Agree, being practical about what we will offer for > >> actual > >>>>>>> endpoints are useful. > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> _______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >>> > > > > From marshall.eubanks@gmail.com Thu Apr 19 04:35:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A34B21F85ED for ; Thu, 19 Apr 2012 04:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts1C5Y8n2CAG for ; Thu, 19 Apr 2012 04:35:06 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF28421F85E4 for ; Thu, 19 Apr 2012 04:35:05 -0700 (PDT) Received: by lbgc1 with SMTP id c1so2134668lbg.31 for ; Thu, 19 Apr 2012 04:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=2OObyPq/EJjXoSB5eR6QRUatXD/hQktEWaNKHtXzbWM=; b=npjiUVCpL+rxNyBLtiVduZm5vsNXjyKrVh5jHizGlio3qynoxUGvRkergPG+X1LqSf kM4btTrU9dgNsH7dVNcPwNM1GO8zgnxNU3hwffoBEhyHaAPQLxB9LrHxGFbnv9mpg3pJ r08FNAcR7PWdpVEbKEx8I1RSixz4I8cIloe8Uo1jprATWi78eE64KbGu5kLc3E9OZ8qX BNaLh6yCA9r4wvyp2j1rgHk9Uwu3ZOboL9HPJ0tQsQCHO0I4ppZmwbYUwYx28YS1suYT ljhF5pey6/9DEdZQr2bCugftWJkGIIgFlFBfB4eGtUdgSN+22GVM2swYfwli2Y9miHN5 4dxg== MIME-Version: 1.0 Received: by 10.152.132.166 with SMTP id ov6mr1786337lab.35.1334835304885; Thu, 19 Apr 2012 04:35:04 -0700 (PDT) Received: by 10.112.46.4 with HTTP; Thu, 19 Apr 2012 04:35:04 -0700 (PDT) In-Reply-To: <4F8FD87C.2070907@ericsson.com> References: <4F8FD87C.2070907@ericsson.com> Date: Thu, 19 Apr 2012 07:35:04 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] Fwd: [rtcweb] URGENT: Dates for upcoming interim ON HOLD X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 11:35:10 -0000 FYI ---------- Forwarded message ---------- From: Magnus Westerlund Date: Thu, Apr 19, 2012 at 5:18 AM Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD To: Ted Hardie Cc: Cullen Jennings , "rai-ads@tools.ietf.org" , "rtcweb@ietf.org" , "clue-chairs@tools.ietf.org" RTCWEB WG, The dates for the upcoming interim is off the hold. I can confirm AD approval, and that we will hold an Face to Face interim meeting on the 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for each of those days. As a Host I can't confirm the location within Stockholm yet. We are aiming on either a location in Kista or in the central part of town. There are some hotels out in Kista, but even if we end up in Kista staying in central Stockholm allows for a short (17 min) subway ride from T-centralen plus a no more than 10 min walk to the Kista venue. Making it a very viable option to book a hotel room in the area around T-centralen or on Kungsholmen with easy access to the blue-line subway. Cheers Magnus Westerlund On 2012-04-12 19:42, Ted Hardie wrote: > Please hold off making travel plans based on this timing. =A0 Because > neither RAI area director will be available during this timing, they > have asked to consider shifting this timing to the previous week, June > 7th and 8th. =A0Until the chairs have had a chance to discuss this, > please hold off on booking travel plans. > > My apologies for this scramble, > > Ted Hardie > > On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie wrote: >> After discussion between the WEBRTC and RTCWEB chairs, consulting the >> doodle poll, and working through the potential for co-location with >> CLUE, we have decided to set the date for the RTCWEB interim at June >> 12 & 13th, to be hosted by Ericsson in Stockholm. =A0We understand that >> the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE >> wishes to co-locate their meeting, the 14th and 15th will be >> available. =A0This would not have been possible on the previous week, >> given the national holiday in Sweden on the Wednesday of that week. >> >> We very much appreciated the work Eric put into his analysis, and in >> general we will try to prefer hubs; in this particular case, however, >> a large fraction of the Western European participants are either based >> in Stockholm or must fly through it to reach one of the larger hubs. >> Given the availability of a host and this data, we decided to select >> Stockholm for this meeting. >> >> regards, >> >> Ted Hardie, for the chairs. > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From espeberg@cisco.com Thu Apr 19 09:31:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB48821F868A for ; Thu, 19 Apr 2012 09:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heb2VvSEn0Rb for ; Thu, 19 Apr 2012 09:31:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 31D6721F867C for ; Thu, 19 Apr 2012 09:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=4310; q=dns/txt; s=iport; t=1334853090; x=1336062690; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=iJrte+iDOLfjHCFZTFlPwIvFtmx0LiHe6sVD/1YIkQI=; b=hovptB/7ESo8jH/LJHSTAJPWMi7pX+MEBVYzhQecyC+9tmGVSopeSQbE cmrhUvbCiD4+4WKoz3uwVUF7IZVGcx0iDcy3bYCI5A8y9m28gKD1Iiqqw UvWzGr9Mzy2LDk6kghot+SeoxILVn0+ScmsrhYqdcWR+6ZX57YTKCJtTd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAO08kE+Q/khR/2dsb2JhbABDDrE2gQeCCQEBAQMBAQEBDwEdCi4GEAcEAgEIDgMEAQEBCgYXAQYBJh8JCAEBBAESCBMHh2gFC5pkoB4EkARjBKRBgWmCMDk X-IronPort-AV: E=Sophos;i="4.75,447,1330905600"; d="scan'208";a="135682592" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 19 Apr 2012 16:31:29 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3JGVTMc014306; Thu, 19 Apr 2012 16:31:29 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Apr 2012 18:31:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Apr 2012 18:31:27 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E011980F4@XMB-AMS-214.cisco.com> In-Reply-To: <4f8de6d0.e249b40a.17fd.ffff8a0d@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Does framework provide sufficient info for receiver? Thread-Index: Ac0c2d1OD7hACoPoTXiAGDF60O1e/QACawxQAFk38zA= References: <4F846AE0.4010700@alum.mit.edu><20120410210921.GM13841@verdi> <4F859DC6.7000303@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9E0119741A@XMB-AMS-214.cisco.com> <4F873CCE.3020806@alum.mit.edu> <4f8ae780.e64eb40a.3477.ffffa7e5@mx.google.com> <4F8C2E0F.4070005@alum.mit.edu> <4F8CAC7F.7040405@alum.mit.edu> <20120417201714.GB99904@verdi><4F8DD467.4060402@alum.mit.edu> <4f8de6d0.e249b40a.17fd.ffff8a0d@mx.google.com> From: "Espen Berger (espeberg)" To: "Roni Even" , "Paul Kyzivat" , X-OriginalArrivalTime: 19 Apr 2012 16:31:29.0001 (UTC) FILETIME=[DF376D90:01CD1E49] Subject: Re: [clue] Does framework provide sufficient info for receiver? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 16:31:36 -0000 By doing complete CLUE capability negotiation examples for the typical use cases and typical behaviour I think we are better prepared to discuss what is supported in the CLUE framework, what is eventually unclear and what we would define as CLUE extensions. I also think it's useful to look at the last requirement, "REQMT-16: The solution MUST include extensibility mechanisms". This indicate that CLUE does not to support all use cases for everyone, but rather make a good set of core feature with interoperability in mind for the important use cases. Implementers are free to extend the core protocol and we should provide hooks to allow extension to be made in a interoperable way.=20 Cheers=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 17. april 2012 23:54 To: 'Paul Kyzivat'; clue@ietf.org Subject: Re: [clue] Does framework provide sufficient info for receiver? Hi Paul, I fully agree that there is a difference between centralized conferences with MCUs and point to point case. My experience with MCUs is that they wish to provide the best experience to all participants (they may have better support for the endpoints from the same vendor). Since the MCUs cannot be sure what functionality will be supported by the end points that they will meet in the field (I am talking here about the solution design phase) they have some out of band mechanism that allows the use of the endpoint to interact with the MCU conferencing application in order to control the conference including the views that the participants will see. Therefore I do not see much value in having a protocol for that and I had similar feedback to XCON work of which I only see the event package as an important block. As for point to point I think that the current information is sufficient. The sender will provide the capture set entries but if it provides the simultaneous sets that consumer can ask for the capture he wants regardless of the capture set entries which reflect the provider preference. Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: Tuesday, April 17, 2012 11:37 PM > To: clue@ietf.org > Subject: Re: [clue] Does framework provide sufficient info for=20 > receiver? >=20 > On 4/17/12 4:17 PM, John Leslie wrote: >=20 > > My point is that vendors _should_ want to give a "familiar" > > experience to their customers, and it will at least subtly differ > from > > the experience other vendors offer. >=20 > How should I read the above when systems from two different vendors=20 > are interoperating? I can see this in two ways: >=20 > - the receiving system will endeavor to adapt the advertised=20 > information from the provider to produce the kind of experience the=20 > receiving system prefers. >=20 > - the providing system may want to do what it can to cause the=20 > receiving system to give the experience the providing system prefers. >=20 > Absent some counteracting force systems will probably try to do both,=20 > though they are in some sense conflicting goals. >=20 > Presumably the receiving system could come closest to providing its=20 > familiar experience to its customers if the providing system makes=20 > available all the raw captures and sufficient information to=20 > understand what they are. But that assumes the receiving system has=20 > sufficient bandwidth and processing capacity. >=20 > As soon as the sending system starts processing the captures,=20 > especially if it then fails to make all the raw captures available, it > is putting its imprint on the receiving system's user experience. >=20 > Maybe it would make sense to distinguish here between behavior of=20 > endpoints and MCUs. We may expect an MCU to have a stronger influence=20 > on endpoint user experience than we do in a point to point session. >=20 > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Thu Apr 19 10:46:12 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAC921F86DB for ; Thu, 19 Apr 2012 10:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.608 X-Spam-Level: X-Spam-Status: No, score=-103.608 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hm-FyvYcQrzC for ; Thu, 19 Apr 2012 10:46:11 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB0821F845E for ; Thu, 19 Apr 2012 10:46:11 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6831371vbb.31 for ; Thu, 19 Apr 2012 10:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8nCzfJ4pjIoHqV3ynUP8r3WHuyiz0lyP9E7Phm+xkUQ=; b=zMoEkLtRRYHJDhz59kEgiHTu7M+SYI2r3cYJWH2Egr8pDTmnP3KR0P11/Y7GoM999l eSXoHZAmvzlovxDnLCxx24LYsxzhKZaDzKRykGWhEcN0v+exKIs+2uo3rPVmFKuUPxi7 zsqzvIa713mqItWOgSkwBtLi1g8XgivaslrjtJycsFmHY+DNu378C5BeVx4nW3MraRQn GmQF/lUZcushWVaLCsU97Yc8BnRU5d4FG+OBNmR1EQKlGMh29tkFsYifKquKSieimb76 XJAfy8mlIrSCx5hWy61/bxntism3z9Rb6jX4i+5P+784/5Dz7I9zXHqO+ZBt8SJQ5yHI bmcw== MIME-Version: 1.0 Received: by 10.52.72.169 with SMTP id e9mr1333900vdv.21.1334857570867; Thu, 19 Apr 2012 10:46:10 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Thu, 19 Apr 2012 10:46:10 -0700 (PDT) In-Reply-To: References: <4F8FD87C.2070907@ericsson.com> Date: Thu, 19 Apr 2012 12:46:10 -0500 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=20cf3071d0a2565b4304be0bbf30 Cc: clue Subject: Re: [clue] Fwd: [rtcweb] URGENT: Dates for upcoming interim ON HOLD X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 17:46:12 -0000 --20cf3071d0a2565b4304be0bbf30 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As I've highlighted in previous emails, we have a doodle for location selection for the CLUE meeting: http://www.doodle.com/wwrdycma9ymrdn3r This poll closes at noon Pacific today - i.e., in 1.5 hours. So, we will make the decision for the location at the end of today. Note that our date has been set for June 7-8 based on our original poll: http://doodle.com/nm3pp69znr3286cy Please note, that there are significantly fewer people that have responded to the location doodle poll than people that indicated they could attend the meeting on the 7th-8th, per the poll for meeting dates. So we'll assume whomever doesn't respond to the location poll is okay with any of the locations. Folks that want to attend both meetings are strongly encouraged to indicate their preference for Stockholm unless you want to spend the weekend traveling from Boston or San Jose. Thanks, Mary. On Thu, Apr 19, 2012 at 6:35 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > FYI > > > ---------- Forwarded message ---------- > From: Magnus Westerlund > Date: Thu, Apr 19, 2012 at 5:18 AM > Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD > To: Ted Hardie > Cc: Cullen Jennings , "rai-ads@tools.ietf.org" > , "rtcweb@ietf.org" , > "clue-chairs@tools.ietf.org" > > > RTCWEB WG, > > The dates for the upcoming interim is off the hold. I can confirm AD > approval, and that we will hold an Face to Face interim meeting on the > 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a > meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for > each of those days. > > As a Host I can't confirm the location within Stockholm yet. We are > aiming on either a location in Kista or in the central part of town. > There are some hotels out in Kista, but even if we end up in Kista > staying in central Stockholm allows for a short (17 min) subway ride > from T-centralen plus a no more than 10 min walk to the Kista venue. > Making it a very viable option to book a hotel room in the area around > T-centralen or on Kungsholmen with easy access to the blue-line subway. > > Cheers > > Magnus Westerlund > > > > > On 2012-04-12 19:42, Ted Hardie wrote: > > Please hold off making travel plans based on this timing. Because > > neither RAI area director will be available during this timing, they > > have asked to consider shifting this timing to the previous week, June > > 7th and 8th. Until the chairs have had a chance to discuss this, > > please hold off on booking travel plans. > > > > My apologies for this scramble, > > > > Ted Hardie > > > > On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie wrote: > >> After discussion between the WEBRTC and RTCWEB chairs, consulting the > >> doodle poll, and working through the potential for co-location with > >> CLUE, we have decided to set the date for the RTCWEB interim at June > >> 12 & 13th, to be hosted by Ericsson in Stockholm. We understand that > >> the WEBRTC chairs will hold their meeting on June 11th. If CLUE > >> wishes to co-locate their meeting, the 14th and 15th will be > >> available. This would not have been possible on the previous week, > >> given the national holiday in Sweden on the Wednesday of that week. > >> > >> We very much appreciated the work Eric put into his analysis, and in > >> general we will try to prefer hubs; in this particular case, however, > >> a large fraction of the Western European participants are either based > >> in Stockholm or must fly through it to reach one of the larger hubs. > >> Given the availability of a host and this data, we decided to select > >> Stockholm for this meeting. > >> > >> regards, > >> > >> Ted Hardie, for the chairs. > > > > > -- > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf3071d0a2565b4304be0bbf30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As I've highlighted in previous emails, we have a doodle for location s= election for the CLUE meeting:=A0
This= poll closes at noon Pacific today - i.e., in 1.5 hours. =A0So, we will mak= e the decision for the location at the end of today.

Note that our date has been set for June 7-8 based on o= ur original poll: =A0=A0http= ://doodle.com/nm3pp69znr3286cy

Please note, th= at there are significantly fewer people that have responded to the location= doodle poll than people that indicated they could attend the meeting on th= e 7th-8th, per the poll for meeting dates. =A0So we'll assume whomever = doesn't respond to the location poll is okay with any of the locations.= =A0Folks that want to attend both meetings are strongly encouraged to indi= cate their preference for Stockholm unless you want to spend the weekend tr= aveling from Boston or San Jose.=A0

Thanks,
Mary.=A0

On Thu, Apr 19, 2012 at 6:35 AM, Marshall Eubanks &= lt;marshall.eubanks@gmail.com= > wrote:
FYI


---------- Forwarded message ----------
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Thu, Apr 19, 2012 at 5:18 AM
Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD
To: Ted Hardie <ted.ietf@gmail.com= >
Cc: Cullen Jennings <fluffy@cisco.co= m>, "rai-ads@tools.ie= tf.org"
<rai-ads@tools.ietf.org>= ;, "rtcweb@ietf.org" <<= a href=3D"mailto:rtcweb@ietf.org">rtcweb@ietf.org>,
"clue-chairs@tools.ietf.= org" <clue-chairs= @tools.ietf.org>


RTCWEB WG,

The dates for the upcoming interim is off the hold. I can confirm AD
approval, and that we will hold an Face to Face interim meeting on the
12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a
meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for
each of those days.

As a Host I can't confirm the location within Stockholm yet. We are
aiming on either a location in Kista or in the central part of town.
There are some hotels out in Kista, but even if we end up in Kista
staying in central Stockholm allows for a short (17 min) subway ride
from T-centralen plus a no more than 10 min walk to the Kista venue.
Making it a very viable option to book a hotel room in the area around
T-centralen or on Kungsholmen with easy access to the blue-line subway.

Cheers

Magnus Westerlund




On 2012-04-12 19:42, Ted Hardie wrote:
> Please hold off making travel plans based on this timing. =A0 Because<= br> > neither RAI area director will be available during this timing, they > have asked to consider shifting this timing to the previous week, June=
> 7th and 8th. =A0Until the chairs have had a chance to discuss this, > please hold off on booking travel plans.
>
> My apologies for this scramble,
>
> Ted Hardie
>
> On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>> After discussion between the WEBRTC and RTCWEB chairs, consulting = the
>> doodle poll, and working through the potential for co-location wit= h
>> CLUE, we have decided to set the date for the RTCWEB interim at Ju= ne
>> 12 & 13th, to be hosted by Ericsson in Stockholm. =A0We unders= tand that
>> the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE=
>> wishes to co-locate their meeting, the 14th and 15th will be
>> available. =A0This would not have been possible on the previous we= ek,
>> given the national holiday in Sweden on the Wednesday of that week= .
>>
>> We very much appreciated the work Eric put into his analysis, and = in
>> general we will try to prefer hubs; in this particular case, howev= er,
>> a large fraction of the Western European participants are either b= ased
>> in Stockholm or must fly through it to reach one of the larger hub= s.
>> Given the availability of a host and this data, we decided to sele= ct
>> Stockholm for this meeting.
>>
>> regards,
>>
>> Ted Hardie, for the chairs.
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
_______________________= ________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf3071d0a2565b4304be0bbf30-- From mary.ietf.barnes@gmail.com Thu Apr 19 10:53:44 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E2221F86CE for ; Thu, 19 Apr 2012 10:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.775 X-Spam-Level: X-Spam-Status: No, score=-102.775 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7UiUAY4Ehgx for ; Thu, 19 Apr 2012 10:53:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE7E21F867B for ; Thu, 19 Apr 2012 10:53:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6837271vbb.31 for ; Thu, 19 Apr 2012 10:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gc7c0qQw38kaCH1IoU71laHiyIBlkD7tTHPALT0ohe0=; b=LwSlv0ujYeRPfS3kduVkVI06RYOxvRtzHNEfiVidu37tKWp8Cgnr/BikovTYLHFz3U x/shd4z/m4Hf9XENfeFxfhJhXGlXXLmaEINqQecrmH/k0WIi2YDvyjFqGqE9JkXtlQnG ccwdaMnw0/K9e/VWMs3nWmmLzAY1GSNpeoxvm+O5QhxR0yLAkl8ezYUgjklMrvHV85IU l753YnVZqM0RHUpmd+ZJfethEnNmYLn3NSGg7xWGbFJqf35IjKOVrHy6aoMg0EWZnTYQ W3O6CWwjNH/CgqkaiEuB5Md4xhMFd2ab5X8WOwTNRqy8HsYwN5+4O3RpXBZiOvVL4ILH cv8A== MIME-Version: 1.0 Received: by 10.220.58.197 with SMTP id i5mr1631058vch.38.1334858022960; Thu, 19 Apr 2012 10:53:42 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Thu, 19 Apr 2012 10:53:42 -0700 (PDT) Date: Thu, 19 Apr 2012 12:53:42 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=0023544477cd48bfb104be0bda72 Subject: [clue] Attending W3C meeting (was Fwd: [rtcweb] Confirmation of F2F Interim meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 17:53:44 -0000 --0023544477cd48bfb104be0bda72 Content-Type: text/plain; charset=ISO-8859-1 For CLUE folks that would be interested to also attend the W3C meeting on June 11th. You may request permission to attend if your company is not a W3C member per Harald's response below. You might ask why this meeting is important - we have discussed in the past that some of the CLUE information may need to be transported over the API for WebRTC clients to interface with a CLUE enabled endpoint. It also is very helpful to understand what W3C is doing to understand some of the context in the RTCWEB WG. Regards, Mary. ---------- Forwarded message ---------- From: Harald Alvestrand Date: Thu, Apr 19, 2012 at 10:00 AM Subject: Re: [rtcweb] Confirmation of F2F Interim meeting To: "Kevin P. Fleming" Cc: rtcweb@ietf.org On 04/19/2012 04:20 PM, Kevin P. Fleming wrote: > On 04/19/2012 04:21 AM, Magnus Westerlund wrote: > >> RTCWEB WG, >> >> The dates for the upcoming interim is off the hold. I can confirm AD >> approval, and that we will hold an Face to Face interim meeting on the >> 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a >> meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for >> each of those days. >> > > Is the W3C meeting 'open attendance' like the IETF meeting will be, or > does it require membership or sponsorship? > The WG chairs can welcome people into the meeting as "observers with speaking privilleges". All we want as formality is that you send us a note beforehand asking to be an observer. We will accept the request. Harald ______________________________**_________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/**listinfo/rtcweb --0023544477cd48bfb104be0bda72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For CLUE folks that would be interested to also attend the W3C meeting on J= une 11th. You may request permission to attend if your company is not a W3C= member per Harald's response below.=A0

You might as= k why this meeting is important - we have discussed in the past that some o= f the CLUE information may need to be transported over the API for WebRTC c= lients to interface with a CLUE enabled endpoint. =A0It also is very helpfu= l to understand what W3C is doing to understand some of the context in the = RTCWEB WG.=A0

Regards,
Mary.=A0

---------- Forwarded message ----------
From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, Apr 19, 2012 at 10:00 AM
Subject: Re: [rtcweb] Confirmation o= f F2F Interim meeting
To: "Kevin P. Fleming" <kpfleming@digium.com>
Cc: rtcweb@ietf.org


On 04/19/2012 04:20 PM, Kevin P. Fleming wrote:
On 04/19/2012 04:21 AM, Magnus Westerlund wrote:
RTCWEB WG,

The dates for the upcoming interim is off the hold. I can confirm AD
approval, and that we will hold an Face to Face interim meeting on the
12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a
meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for
each of those days.

Is the W3C meeting 'open attendance' like the IETF meeting will be,= or does it require membership or sponsorship?
The WG chairs can welcome people into the meeting as "observers with s= peaking privilleges".
All we want as formality is that you send us a note beforehand asking to be= an observer.
We will accept the request.<= br>
=A0 =A0 =A0 =A0 =A0 =A0 Harald



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

--0023544477cd48bfb104be0bda72-- From mary.ietf.barnes@gmail.com Thu Apr 19 10:57:44 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FBF21F86AD for ; Thu, 19 Apr 2012 10:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuvUZX74LsNV for ; Thu, 19 Apr 2012 10:57:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1793321F867B for ; Thu, 19 Apr 2012 10:57:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6840147vbb.31 for ; Thu, 19 Apr 2012 10:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5UGQxCBwS3/iRKKrW4mkYaZP8xARNdB8nSpkpXxCYiI=; b=VuRlSuQXWd26UoDmf9T2sTv1yzembdUKezRN0GoCt5YkAr2bnkUas18wx4je/TW7Ok /QKFK+Sm8VJ0W7u+iRfVy+TnP+WcUB/mNe7bUUoJrxaKdxVIB+EXpsrilZQDdw8XCt8G kf5svZcvY6NcF9+4QSd9MeDWBw8ZUPZ5Q3/EnF9POY3otjkCjAkknpdB5BJgNfLgMa1r dvxRXXjDXnhaxskOvBimdPYTUcK7pMWwogBr+oQnf5o/QMzijHgdyHN4CwUeRWDBrsXS QZBaTArNeQIalN0O44mMNxBCo04sjtDVyNYi56A5fHu3SvmlAvOZ6QTH9eH1snHSl5Ch WTbQ== MIME-Version: 1.0 Received: by 10.52.97.225 with SMTP id ed1mr1331382vdb.55.1334858262515; Thu, 19 Apr 2012 10:57:42 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Thu, 19 Apr 2012 10:57:42 -0700 (PDT) Date: Thu, 19 Apr 2012 12:57:42 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307ac895900ea004be0be822 Subject: [clue] CLUE WG interim meeting location X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 17:57:44 -0000 --20cf307ac895900ea004be0be822 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Note, I'm resending with a different Subject to ensure folks read it (even if you don't care about RTCWEB) ---------- Forwarded message ---------- From: Mary Barnes Date: Thu, Apr 19, 2012 at 12:46 PM Subject: Re: [clue] Fwd: [rtcweb] URGENT: Dates for upcoming interim ON HOL= D To: Marshall Eubanks Cc: clue As I've highlighted in previous emails, we have a doodle for location selection for the CLUE meeting: http://www.doodle.com/wwrdycma9ymrdn3r This poll closes at noon Pacific today - i.e., in 1.5 hours. So, we will make the decision for the location at the end of today. Note that our date has been set for June 7-8 based on our original poll: http://doodle.com/nm3pp69znr3286cy Please note, that there are significantly fewer people that have responded to the location doodle poll than people that indicated they could attend the meeting on the 7th-8th, per the poll for meeting dates. So we'll assume whomever doesn't respond to the location poll is okay with any of the locations. Folks that want to attend both meetings are strongly encouraged to indicate their preference for Stockholm unless you want to spend the weekend traveling from Boston or San Jose. Thanks, Mary. On Thu, Apr 19, 2012 at 6:35 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > FYI > > > ---------- Forwarded message ---------- > From: Magnus Westerlund > Date: Thu, Apr 19, 2012 at 5:18 AM > Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD > To: Ted Hardie > Cc: Cullen Jennings , "rai-ads@tools.ietf.org" > , "rtcweb@ietf.org" , > "clue-chairs@tools.ietf.org" > > > RTCWEB WG, > > The dates for the upcoming interim is off the hold. I can confirm AD > approval, and that we will hold an Face to Face interim meeting on the > 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a > meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for > each of those days. > > As a Host I can't confirm the location within Stockholm yet. We are > aiming on either a location in Kista or in the central part of town. > There are some hotels out in Kista, but even if we end up in Kista > staying in central Stockholm allows for a short (17 min) subway ride > from T-centralen plus a no more than 10 min walk to the Kista venue. > Making it a very viable option to book a hotel room in the area around > T-centralen or on Kungsholmen with easy access to the blue-line subway. > > Cheers > > Magnus Westerlund > > > > > On 2012-04-12 19:42, Ted Hardie wrote: > > Please hold off making travel plans based on this timing. Because > > neither RAI area director will be available during this timing, they > > have asked to consider shifting this timing to the previous week, June > > 7th and 8th. Until the chairs have had a chance to discuss this, > > please hold off on booking travel plans. > > > > My apologies for this scramble, > > > > Ted Hardie > > > > On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie wrote: > >> After discussion between the WEBRTC and RTCWEB chairs, consulting the > >> doodle poll, and working through the potential for co-location with > >> CLUE, we have decided to set the date for the RTCWEB interim at June > >> 12 & 13th, to be hosted by Ericsson in Stockholm. We understand that > >> the WEBRTC chairs will hold their meeting on June 11th. If CLUE > >> wishes to co-locate their meeting, the 14th and 15th will be > >> available. This would not have been possible on the previous week, > >> given the national holiday in Sweden on the Wednesday of that week. > >> > >> We very much appreciated the work Eric put into his analysis, and in > >> general we will try to prefer hubs; in this particular case, however, > >> a large fraction of the Western European participants are either based > >> in Stockholm or must fly through it to reach one of the larger hubs. > >> Given the availability of a host and this data, we decided to select > >> Stockholm for this meeting. > >> > >> regards, > >> > >> Ted Hardie, for the chairs. > > > > > -- > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307ac895900ea004be0be822 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Note, I'm resending with a different Subject to ensure folks read it (e= ven if you don't care about RTCWEB)

-= --------- Forwarded message ----------
From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Thu, Apr 19, 2012 at 12:46 PM
Subject: Re: [clue] Fwd: [rtcweb] UR= GENT: Dates for upcoming interim ON HOLD
To: Marshall Eubanks <marshall.eubanks@gmail.com><= br> Cc: clue <clue@ietf.org>

=
As I've highlighted in previous emails, we have a doodle for locati= on selection for the CLUE meeting:=A0
This poll closes at noon Pacific today - i.e., in 1.5 hours. =A0So, we= will make the decision for the location at the end of today.

Note that our date has been set for June 7-8 based on o= ur original poll: =A0=A0http://doodle.com/nm3pp69znr3286cy

Please note, that there are significantly fewer people that have responded = to the location doodle poll than people that indicated they could attend th= e meeting on the 7th-8th, per the poll for meeting dates. =A0So we'll a= ssume whomever doesn't respond to the location poll is okay with any of= the locations. =A0Folks that want to attend both meetings are strongly enc= ouraged to indicate their preference for Stockholm unless you want to spend= the weekend traveling from Boston or San Jose.=A0

Thanks,
Mary.=A0

On Thu, Apr 19, 2012 at 6:35 AM, Marshall Euba= nks <marshall.eubanks@gmail.com> wrote:
FYI


---------- Forwarded message ----------
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Thu, Apr 19, 2012 at 5:18 AM
Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD
To: Ted Hardie <= ted.ietf@gmail.com>
Cc: Cullen Jennings <fluffy@cisco.com>, "rai-ads@tools.ietf.org"
<rai-ads@too= ls.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>,
"clue-= chairs@tools.ietf.org" <clue-chairs@tools.ietf.org>


RTCWEB WG,

The dates for the upcoming interim is off the hold. I can confirm AD
approval, and that we will hold an Face to Face interim meeting on the
12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a
meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for
each of those days.

As a Host I can't confirm the location within Stockholm yet. We are
aiming on either a location in Kista or in the central part of town.
There are some hotels out in Kista, but even if we end up in Kista
staying in central Stockholm allows for a short (17 min) subway ride
from T-centralen plus a no more than 10 min walk to the Kista venue.
Making it a very viable option to book a hotel room in the area around
T-centralen or on Kungsholmen with easy access to the blue-line subway.

Cheers

Magnus Westerlund




On 2012-04-12 19:42, Ted Hardie wrote:
> Please hold off making travel plans based on this timing. =A0 Because<= br> > neither RAI area director will be available during this timing, they > have asked to consider shifting this timing to the previous week, June=
> 7th and 8th. =A0Until the chairs have had a chance to discuss this, > please hold off on booking travel plans.
>
> My apologies for this scramble,
>
> Ted Hardie
>
> On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>> After discussion between the WEBRTC and RTCWEB chairs, consulting = the
>> doodle poll, and working through the potential for co-location wit= h
>> CLUE, we have decided to set the date for the RTCWEB interim at Ju= ne
>> 12 & 13th, to be hosted by Ericsson in Stockholm. =A0We unders= tand that
>> the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE=
>> wishes to co-locate their meeting, the 14th and 15th will be
>> available. =A0This would not have been possible on the previous we= ek,
>> given the national holiday in Sweden on the Wednesday of that week= .
>>
>> We very much appreciated the work Eric put into his analysis, and = in
>> general we will try to prefer hubs; in this particular case, howev= er,
>> a large fraction of the Western European participants are either b= ased
>> in Stockholm or must fly through it to reach one of the larger hub= s.
>> Given the availability of a host and this data, we decided to sele= ct
>> Stockholm for this meeting.
>>
>> regards,
>>
>> Ted Hardie, for the chairs.
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287=
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--20cf307ac895900ea004be0be822-- From ron.even.tlv@gmail.com Thu Apr 19 13:25:05 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AEE21F8642 for ; Thu, 19 Apr 2012 13:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SVdPQiaBnPn for ; Thu, 19 Apr 2012 13:25:03 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 69FD221F8639 for ; Thu, 19 Apr 2012 13:25:03 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so6089499wgb.13 for ; Thu, 19 Apr 2012 13:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=8t7M+LmadeOY3Zqtpcf4JzNkStrmtzk/sOYOmjJmagE=; b=Wp6ivxDRPflE1opnuAuMfdXOt6BTySRvJeZ1AceAXdGaQVQ7hjojfh9rnK5E6N4VcA Hio5rIekGuowxgHkbRNTrfeP3wjcyOuWljPFi+U6Qk8+uIrspinFe41Pdw2aVgEcsv7S BZpArRVNHaGoj0ZzUwvUzOkuYzBd9uT//pVZNv/6WkoZbcfG9JCqLALTml6N9q7O4kfq S/xCMZc+qvCp6ztxvpKDOi5Q7htfRpVeVxdWL4EULhuTBwiJaQglRMHxv5QwZ2axLw5u wWD9LdmRj/nuYODTFPzOd7lLwji7B68aWrGkFK1zlmkMUm7b+Dstikd93LaOdaEVPmh0 +J5g== Received: by 10.216.135.106 with SMTP id t84mr2214067wei.74.1334867102367; Thu, 19 Apr 2012 13:25:02 -0700 (PDT) Received: from windows8d787f9 (bzq-109-65-204-117.red.bezeqint.net. [109.65.204.117]) by mx.google.com with ESMTPS id n8sm193588wix.10.2012.04.19.13.24.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 13:25:00 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Thu, 19 Apr 2012 23:23:24 +0300 Message-ID: <4f90749c.0850b40a.1745.066e@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01CD1E83.6C543760" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0eVe2L3lHlLgvtSESvEkEH5XRrXgAFBvBQ Content-Language: en-us Subject: Re: [clue] CLUE WG interim meeting location X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 20:25:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B5_01CD1E83.6C543760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mary, I noticed that Magnus as a host do not have a location yet for the = RTCweb meeting. Is he also looking for a location for CLUE. =20 Roni Even =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes Sent: Thursday, April 19, 2012 8:58 PM To: CLUE Subject: [clue] CLUE WG interim meeting location =20 Note, I'm resending with a different Subject to ensure folks read it = (even if you don't care about RTCWEB) ---------- Forwarded message ---------- From: Mary Barnes Date: Thu, Apr 19, 2012 at 12:46 PM Subject: Re: [clue] Fwd: [rtcweb] URGENT: Dates for upcoming interim ON = HOLD To: Marshall Eubanks Cc: clue As I've highlighted in previous emails, we have a doodle for location selection for the CLUE meeting:=20 http://www.doodle.com/wwrdycma9ymrdn3r This poll closes at noon Pacific today - i.e., in 1.5 hours. So, we = will make the decision for the location at the end of today. =20 Note that our date has been set for June 7-8 based on our original poll: http://doodle.com/nm3pp69znr3286cy =20 Please note, that there are significantly fewer people that have = responded to the location doodle poll than people that indicated they could attend = the meeting on the 7th-8th, per the poll for meeting dates. So we'll assume whomever doesn't respond to the location poll is okay with any of the locations. Folks that want to attend both meetings are strongly = encouraged to indicate their preference for Stockholm unless you want to spend the weekend traveling from Boston or San Jose.=20 =20 Thanks, Mary.=20 =20 On Thu, Apr 19, 2012 at 6:35 AM, Marshall Eubanks wrote: FYI ---------- Forwarded message ---------- From: Magnus Westerlund Date: Thu, Apr 19, 2012 at 5:18 AM Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD To: Ted Hardie Cc: Cullen Jennings , "rai-ads@tools.ietf.org" , "rtcweb@ietf.org" , "clue-chairs@tools.ietf.org" RTCWEB WG, The dates for the upcoming interim is off the hold. I can confirm AD approval, and that we will hold an Face to Face interim meeting on the 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for each of those days. As a Host I can't confirm the location within Stockholm yet. We are aiming on either a location in Kista or in the central part of town. There are some hotels out in Kista, but even if we end up in Kista staying in central Stockholm allows for a short (17 min) subway ride from T-centralen plus a no more than 10 min walk to the Kista venue. Making it a very viable option to book a hotel room in the area around T-centralen or on Kungsholmen with easy access to the blue-line subway. Cheers Magnus Westerlund On 2012-04-12 19:42, Ted Hardie wrote: > Please hold off making travel plans based on this timing. Because > neither RAI area director will be available during this timing, they > have asked to consider shifting this timing to the previous week, June > 7th and 8th. Until the chairs have had a chance to discuss this, > please hold off on booking travel plans. > > My apologies for this scramble, > > Ted Hardie > > On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie = wrote: >> After discussion between the WEBRTC and RTCWEB chairs, consulting the >> doodle poll, and working through the potential for co-location with >> CLUE, we have decided to set the date for the RTCWEB interim at June >> 12 & 13th, to be hosted by Ericsson in Stockholm. We understand that >> the WEBRTC chairs will hold their meeting on June 11th. If CLUE >> wishes to co-locate their meeting, the 14th and 15th will be >> available. This would not have been possible on the previous week, >> given the national holiday in Sweden on the Wednesday of that week. >> >> We very much appreciated the work Eric put into his analysis, and in >> general we will try to prefer hubs; in this particular case, however, >> a large fraction of the Western European participants are either = based >> in Stockholm or must fly through it to reach one of the larger hubs. >> Given the availability of a host and this data, we decided to select >> Stockholm for this meeting. >> >> regards, >> >> Ted Hardie, for the chairs. > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 =20 F=E4r=F6gatan 6 | Mobile +46 73 0949079 =20 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 =20 ------=_NextPart_000_00B5_01CD1E83.6C543760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mary,

I noticed that Magnus as a host do not have a location yet for the = RTCweb meeting. Is he also looking for a location for = CLUE.

 

Roni Even

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: Thursday, April 19, 2012 8:58 = PM
To: CLUE
Subject: [clue] CLUE WG interim meeting = location

 

Note, I'm resending with a different = Subject to ensure folks read it (even if you don't care about = RTCWEB)

---------- Forwarded = message ----------
From: Mary Barnes <mary.ietf.barnes@gmail.com= >
Date: Thu, Apr 19, 2012 at 12:46 PM
Subject: Re: [clue] Fwd: = [rtcweb] URGENT: Dates for upcoming interim ON HOLD
To: Marshall = Eubanks <marshall.eubanks@gmail.com= >
Cc: clue <clue@ietf.org>


As I've = highlighted in previous emails, we have a doodle for location selection = for the CLUE meeting: 

This poll closes at noon Pacific today = - i.e., in 1.5 hours.  So, we will make the decision for the = location at the end of today.

 

Note that our date has been set for June 7-8 based on = our original poll:   http://doodle.com/nm3pp69znr3286cy

 

Please note, that there are significantly fewer people = that have responded to the location doodle poll than people that = indicated they could attend the meeting on the 7th-8th, per the poll for = meeting dates.  So we'll assume whomever doesn't respond to the = location poll is okay with any of the locations.  Folks that want = to attend both meetings are strongly encouraged to indicate their = preference for Stockholm unless you want to spend the weekend traveling = from Boston or San Jose. 

 

Thanks,

Mary. 

 

On Thu, Apr 19, 2012 at 6:35 AM, Marshall Eubanks = <marshall.eubanks@gmail.com> = wrote:

FYI



---------- Forwarded message = ----------
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Thu, = Apr 19, 2012 at 5:18 AM
Subject: Re: [rtcweb] URGENT: Dates for = upcoming interim ON HOLD
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Cullen Jennings = <fluffy@cisco.com>, "rai-ads@tools.ietf.org"
<rai-ads@tools.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>,
"clue-chairs@tools.ietf.org" <clue-chairs@tools.ietf.org>


RTCWEB = WG,

The dates for the upcoming interim is off the hold. I can = confirm AD
approval, and that we will hold an Face to Face interim = meeting on the
12th and 13th of June in Stockholm. The W3C WebRTC WG = will hold a
meeting in Stockholm on the 11th of June. Assume meeting = 9.00-18.00 for
each of those days.

As a Host I can't confirm = the location within Stockholm yet. We are
aiming on either a location = in Kista or in the central part of town.
There are some hotels out in = Kista, but even if we end up in Kista
staying in central Stockholm = allows for a short (17 min) subway ride
from T-centralen plus a no = more than 10 min walk to the Kista venue.
Making it a very viable = option to book a hotel room in the area around
T-centralen or on = Kungsholmen with easy access to the blue-line = subway.

Cheers

Magnus Westerlund




On = 2012-04-12 19:42, Ted Hardie wrote:
> Please hold off making = travel plans based on this timing.   Because
> neither RAI = area director will be available during this timing, they
> have = asked to consider shifting this timing to the previous week, = June
> 7th and 8th.  Until the chairs have had a chance to = discuss this,
> please hold off on booking travel = plans.
>
> My apologies for this scramble,
>
> = Ted Hardie
>
> On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie = <ted.ietf@gmail.com> wrote:
>> After = discussion between the WEBRTC and RTCWEB chairs, consulting = the
>> doodle poll, and working through the potential for = co-location with
>> CLUE, we have decided to set the date for = the RTCWEB interim at June
>> 12 & 13th, to be hosted by = Ericsson in Stockholm.  We understand that
>> the WEBRTC = chairs will hold their meeting on June 11th.  If CLUE
>> = wishes to co-locate their meeting, the 14th and 15th will be
>> = available.  This would not have been possible on the previous = week,
>> given the national holiday in Sweden on the Wednesday = of that week.
>>
>> We very much appreciated the work = Eric put into his analysis, and in
>> general we will try to = prefer hubs; in this particular case, however,
>> a large = fraction of the Western European participants are either = based
>> in Stockholm or must fly through it to reach one of = the larger hubs.
>> Given the availability of a host and this = data, we decided to select
>> Stockholm for this = meeting.
>>
>> regards,
>>
>> Ted = Hardie, for the chairs.
>


--

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
-----------------= -----------------------------------------------------

____________= ___________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

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

 

 

------=_NextPart_000_00B5_01CD1E83.6C543760-- From mary.ietf.barnes@gmail.com Thu Apr 19 16:32:59 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868D421E8013 for ; Thu, 19 Apr 2012 16:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.15 X-Spam-Level: X-Spam-Status: No, score=-103.15 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRCcqimcTVrL for ; Thu, 19 Apr 2012 16:32:58 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14E0E11E8073 for ; Thu, 19 Apr 2012 16:32:58 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2515625vcb.31 for ; Thu, 19 Apr 2012 16:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HI+K4MrbyR6qxBinP5v5I4dwQlurFD+i/iS3n8y+ykk=; b=ALhblRTG5iiAnjszD18zQ8NR17D6C18dVRTs4tAXjuv/UShhr13ap/YsykMEmyKBgP eKFqHpSa//MVJUaPpcRXNYtAE0Qh/v4Df3HpqaRn0cxpO1JEBbwGwZfxIlqKRJFn8Qbl 0W/F/KFgLEzorMA7A7ZizLKw5gq5WxgNoY06UwDNKs79iB7einUiklbcjVnJcG/WS4kj QBAoLqg7EwyLoQ3qr18MTTbHXB1EtvqnqkzXmOERDVaW1nvpfyi1DBy6iKWp0o526CZ6 JKNOgFb0bhdjNKvAD/E7SDnEBnS1U2kze5Ppu63XvnYlEPhaV3hdHETPLrHRrm2974Ts +VRQ== MIME-Version: 1.0 Received: by 10.52.28.200 with SMTP id d8mr1914140vdh.38.1334878377547; Thu, 19 Apr 2012 16:32:57 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Thu, 19 Apr 2012 16:32:57 -0700 (PDT) Date: Thu, 19 Apr 2012 18:32:57 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf3079bc9e83187904be1097d0 Subject: [clue] CLUE WG interim meeting to be held in Stockholm, Feb. 7-8, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 23:32:59 -0000 --20cf3079bc9e83187904be1097d0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, The doodle indicates that a majority support having the meeting in Stockholm. The exact location is TBD. We'll provide details as soon as we confirm a meeting space. If you did not reply to the original doodle with regards to the date and plan to attend the meeting please fill out the doodle for June 7th ASAP or indicate Stockholm in the location doodle. We need to have a fairly firm number for the number of attendees as we work out the remaining logistics. Thanks to everyone for their patience as we worked to coordinate this meeting with RTCWEB. Mary. On Thu, Apr 19, 2012 at 12:57 PM, Mary Barnes w= rote: > Note, I'm resending with a different Subject to ensure folks read it (eve= n > if you don't care about RTCWEB) > > ---------- Forwarded message ---------- > From: Mary Barnes > Date: Thu, Apr 19, 2012 at 12:46 PM > Subject: Re: [clue] Fwd: [rtcweb] URGENT: Dates for upcoming interim ON > HOLD > To: Marshall Eubanks > Cc: clue > > > As I've highlighted in previous emails, we have a doodle for location > selection for the CLUE meeting: > http://www.doodle.com/wwrdycma9ymrdn3r > This poll closes at noon Pacific today - i.e., in 1.5 hours. So, we will > make the decision for the location at the end of today. > > Note that our date has been set for June 7-8 based on our original poll: > http://doodle.com/nm3pp69znr3286cy > > Please note, that there are significantly fewer people that have responde= d > to the location doodle poll than people that indicated they could attend > the meeting on the 7th-8th, per the poll for meeting dates. So we'll > assume whomever doesn't respond to the location poll is okay with any of > the locations. Folks that want to attend both meetings are strongly > encouraged to indicate their preference for Stockholm unless you want to > spend the weekend traveling from Boston or San Jose. > > Thanks, > Mary. > > > On Thu, Apr 19, 2012 at 6:35 AM, Marshall Eubanks < > marshall.eubanks@gmail.com> wrote: > >> FYI >> >> >> ---------- Forwarded message ---------- >> From: Magnus Westerlund >> Date: Thu, Apr 19, 2012 at 5:18 AM >> Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD >> To: Ted Hardie >> Cc: Cullen Jennings , "rai-ads@tools.ietf.org" >> , "rtcweb@ietf.org" , >> "clue-chairs@tools.ietf.org" >> >> >> RTCWEB WG, >> >> The dates for the upcoming interim is off the hold. I can confirm AD >> approval, and that we will hold an Face to Face interim meeting on the >> 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a >> meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for >> each of those days. >> >> As a Host I can't confirm the location within Stockholm yet. We are >> aiming on either a location in Kista or in the central part of town. >> There are some hotels out in Kista, but even if we end up in Kista >> staying in central Stockholm allows for a short (17 min) subway ride >> from T-centralen plus a no more than 10 min walk to the Kista venue. >> Making it a very viable option to book a hotel room in the area around >> T-centralen or on Kungsholmen with easy access to the blue-line subway. >> >> Cheers >> >> Magnus Westerlund >> >> >> >> >> On 2012-04-12 19:42, Ted Hardie wrote: >> > Please hold off making travel plans based on this timing. Because >> > neither RAI area director will be available during this timing, they >> > have asked to consider shifting this timing to the previous week, June >> > 7th and 8th. Until the chairs have had a chance to discuss this, >> > please hold off on booking travel plans. >> > >> > My apologies for this scramble, >> > >> > Ted Hardie >> > >> > On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie wrote= : >> >> After discussion between the WEBRTC and RTCWEB chairs, consulting the >> >> doodle poll, and working through the potential for co-location with >> >> CLUE, we have decided to set the date for the RTCWEB interim at June >> >> 12 & 13th, to be hosted by Ericsson in Stockholm. We understand that >> >> the WEBRTC chairs will hold their meeting on June 11th. If CLUE >> >> wishes to co-locate their meeting, the 14th and 15th will be >> >> available. This would not have been possible on the previous week, >> >> given the national holiday in Sweden on the Wednesday of that week. >> >> >> >> We very much appreciated the work Eric put into his analysis, and in >> >> general we will try to prefer hubs; in this particular case, however, >> >> a large fraction of the Western European participants are either base= d >> >> in Stockholm or must fly through it to reach one of the larger hubs. >> >> Given the availability of a host and this data, we decided to select >> >> Stockholm for this meeting. >> >> >> >> regards, >> >> >> >> Ted Hardie, for the chairs. >> > >> >> >> -- >> >> 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 >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > > --20cf3079bc9e83187904be1097d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

The doodle indicates that a majority support hav= ing the meeting in Stockholm. =A0The exact location is TBD. =A0We'll pr= ovide details as soon as we confirm a meeting space.

If you did not reply to the original doodle with regards to the date and pl= an to attend the meeting please fill out the doodle for June 7th ASAP or in= dicate Stockholm in the location doodle. =A0We need to have a fairly firm n= umber for the number of attendees as we work out the remaining logistics.

Thanks to everyone for their patience as we worked to c= oordinate this meeting with RTCWEB.

Mary.

<= div class=3D"gmail_quote">On Thu, Apr 19, 2012 at 12:57 PM, Mary Barnes <mary.ietf.= barnes@gmail.com> wrote:
Note, I'm resending with a different Sub= ject to ensure folks read it (even if you don't care about RTCWEB)
<= br>
---------- Forwarded message ----------
From:= Mary Barnes <mary.ietf.barnes@= gmail.com>
Date: Thu, Apr 19, 2012 at 12:46 PM
Subject: Re: [clue] Fwd: [rtcweb] UR= GENT: Dates for upcoming interim ON HOLD
To: Marshall Eubanks <marshall.eubanks@= gmail.com>
Cc: clue <clue@ietf.o= rg>


As I've highlighted in previous emails, we have a= doodle for location selection for the CLUE meeting:=A0
This poll closes at noon Pacific today - i.e., in 1.5 hours. =A0So, we= will make the decision for the location at the end of today.

Note that our date has been set for June 7-8 based on o= ur original poll: =A0=A0http://doodle.com/nm3pp69znr3286cy

Please note, that there are significantly fewer people that have responded = to the location doodle poll than people that indicated they could attend th= e meeting on the 7th-8th, per the poll for meeting dates. =A0So we'll a= ssume whomever doesn't respond to the location poll is okay with any of= the locations. =A0Folks that want to attend both meetings are strongly enc= ouraged to indicate their preference for Stockholm unless you want to spend= the weekend traveling from Boston or San Jose.=A0

Thanks,
Mary.=A0


On Thu, Apr 19, 2012 at 6:35 AM, Marshall Eubanks <marshall.eubanks@gmail.com> wrote:
FYI


---------- Forwarded message ----------
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Thu, Apr 19, 2012 at 5:18 AM
Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD
To: Ted Hardie <= ted.ietf@gmail.com>
Cc: Cullen Jennings <fluffy@cisco.com>, "rai-ads@tools.ietf.org"
<rai-ads@too= ls.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>,
"clue-= chairs@tools.ietf.org" <clue-chairs@tools.ietf.org>


RTCWEB WG,

The dates for the upcoming interim is off the hold. I can confirm AD
approval, and that we will hold an Face to Face interim meeting on the
12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a
meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for
each of those days.

As a Host I can't confirm the location within Stockholm yet. We are
aiming on either a location in Kista or in the central part of town.
There are some hotels out in Kista, but even if we end up in Kista
staying in central Stockholm allows for a short (17 min) subway ride
from T-centralen plus a no more than 10 min walk to the Kista venue.
Making it a very viable option to book a hotel room in the area around
T-centralen or on Kungsholmen with easy access to the blue-line subway.

Cheers

Magnus Westerlund




On 2012-04-12 19:42, Ted Hardie wrote:
> Please hold off making travel plans based on this timing. =A0 Because<= br> > neither RAI area director will be available during this timing, they > have asked to consider shifting this timing to the previous week, June=
> 7th and 8th. =A0Until the chairs have had a chance to discuss this, > please hold off on booking travel plans.
>
> My apologies for this scramble,
>
> Ted Hardie
>
> On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>> After discussion between the WEBRTC and RTCWEB chairs, consulting = the
>> doodle poll, and working through the potential for co-location wit= h
>> CLUE, we have decided to set the date for the RTCWEB interim at Ju= ne
>> 12 & 13th, to be hosted by Ericsson in Stockholm. =A0We unders= tand that
>> the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE=
>> wishes to co-locate their meeting, the 14th and 15th will be
>> available. =A0This would not have been possible on the previous we= ek,
>> given the national holiday in Sweden on the Wednesday of that week= .
>>
>> We very much appreciated the work Eric put into his analysis, and = in
>> general we will try to prefer hubs; in this particular case, howev= er,
>> a large fraction of the Western European participants are either b= ased
>> in Stockholm or must fly through it to reach one of the larger hub= s.
>> Given the availability of a host and this data, we decided to sele= ct
>> Stockholm for this meeting.
>>
>> regards,
>>
>> Ted Hardie, for the chairs.
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287=
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue



--20cf3079bc9e83187904be1097d0-- From mary.ietf.barnes@gmail.com Mon Apr 23 06:59:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC0E21F85E1 for ; Mon, 23 Apr 2012 06:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.139 X-Spam-Level: X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKts4nTmJ3sz for ; Mon, 23 Apr 2012 06:59:14 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B50D121F862B for ; Mon, 23 Apr 2012 06:59:14 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4954426vcb.31 for ; Mon, 23 Apr 2012 06:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=r0osis0PbDCcSeWxpcABkQhAwgnIpF3DSxUwmQAAlDA=; b=X4s2SDfwXRZAnr++U/eUFEptNwsY56rYGN1/NmmFC4laaWfiD1jQAoPTIR6o3tARfe i+4ujlnEZ9rw5oOxTHR/gPJ0LL5TAaglLXREvR9h47rnTsAyA6HlGPB6xTj53sAweLUw HcomK2QDemswV44Ni5rD+u8BsN8l+825V5rlx99ZMdoKGB/uqu2aUfG7gLZHXzWnOOj3 r/RtOnN5WpGUoPRpJeqDxLCkD5/8awl+MsnOqapUxJb3lDaSk9YHw5JKFyp/f4kcbjvb lQoQfJreqqNMs8yTCPWPXlSKusdIs/L8puTo61HOcQ6xmw8ziKBGcGWHEKuxI8l/Pb0A zKnQ== MIME-Version: 1.0 Received: by 10.220.115.82 with SMTP id h18mr16016709vcq.18.1335189554102; Mon, 23 Apr 2012 06:59:14 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Mon, 23 Apr 2012 06:59:14 -0700 (PDT) Date: Mon, 23 Apr 2012 08:59:14 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d043c7c7814826704be590b39 Subject: Re: [clue] CLUE WG interim meeting to be held in Stockholm, June 7-8, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 13:59:17 -0000 --f46d043c7c7814826704be590b39 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Resending with updated date in the subject. On Thu, Apr 19, 2012 at 6:32 PM, Mary Barnes wr= ote: > Hi all, > > The doodle indicates that a majority support having the meeting in > Stockholm. The exact location is TBD. We'll provide details as soon as = we > confirm a meeting space. > > If you did not reply to the original doodle with regards to the date and > plan to attend the meeting please fill out the doodle for June 7th ASAP o= r > indicate Stockholm in the location doodle. We need to have a fairly firm > number for the number of attendees as we work out the remaining logistics= . > > Thanks to everyone for their patience as we worked to coordinate this > meeting with RTCWEB. > > Mary. > > On Thu, Apr 19, 2012 at 12:57 PM, Mary Barnes wrote: > >> Note, I'm resending with a different Subject to ensure folks read it >> (even if you don't care about RTCWEB) >> >> ---------- Forwarded message ---------- >> From: Mary Barnes >> Date: Thu, Apr 19, 2012 at 12:46 PM >> Subject: Re: [clue] Fwd: [rtcweb] URGENT: Dates for upcoming interim ON >> HOLD >> To: Marshall Eubanks >> Cc: clue >> >> >> As I've highlighted in previous emails, we have a doodle for location >> selection for the CLUE meeting: >> http://www.doodle.com/wwrdycma9ymrdn3r >> This poll closes at noon Pacific today - i.e., in 1.5 hours. So, we wil= l >> make the decision for the location at the end of today. >> >> Note that our date has been set for June 7-8 based on our original poll: >> http://doodle.com/nm3pp69znr3286cy >> >> Please note, that there are significantly fewer people that have >> responded to the location doodle poll than people that indicated they co= uld >> attend the meeting on the 7th-8th, per the poll for meeting dates. So >> we'll assume whomever doesn't respond to the location poll is okay with = any >> of the locations. Folks that want to attend both meetings are strongly >> encouraged to indicate their preference for Stockholm unless you want to >> spend the weekend traveling from Boston or San Jose. >> >> Thanks, >> Mary. >> >> >> On Thu, Apr 19, 2012 at 6:35 AM, Marshall Eubanks < >> marshall.eubanks@gmail.com> wrote: >> >>> FYI >>> >>> >>> ---------- Forwarded message ---------- >>> From: Magnus Westerlund >>> Date: Thu, Apr 19, 2012 at 5:18 AM >>> Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD >>> To: Ted Hardie >>> Cc: Cullen Jennings , "rai-ads@tools.ietf.org" >>> , "rtcweb@ietf.org" , >>> "clue-chairs@tools.ietf.org" >>> >>> >>> RTCWEB WG, >>> >>> The dates for the upcoming interim is off the hold. I can confirm AD >>> approval, and that we will hold an Face to Face interim meeting on the >>> 12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a >>> meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for >>> each of those days. >>> >>> As a Host I can't confirm the location within Stockholm yet. We are >>> aiming on either a location in Kista or in the central part of town. >>> There are some hotels out in Kista, but even if we end up in Kista >>> staying in central Stockholm allows for a short (17 min) subway ride >>> from T-centralen plus a no more than 10 min walk to the Kista venue. >>> Making it a very viable option to book a hotel room in the area around >>> T-centralen or on Kungsholmen with easy access to the blue-line subway. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> >>> >>> >>> On 2012-04-12 19:42, Ted Hardie wrote: >>> > Please hold off making travel plans based on this timing. Because >>> > neither RAI area director will be available during this timing, they >>> > have asked to consider shifting this timing to the previous week, Jun= e >>> > 7th and 8th. Until the chairs have had a chance to discuss this, >>> > please hold off on booking travel plans. >>> > >>> > My apologies for this scramble, >>> > >>> > Ted Hardie >>> > >>> > On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie >>> wrote: >>> >> After discussion between the WEBRTC and RTCWEB chairs, consulting th= e >>> >> doodle poll, and working through the potential for co-location with >>> >> CLUE, we have decided to set the date for the RTCWEB interim at June >>> >> 12 & 13th, to be hosted by Ericsson in Stockholm. We understand tha= t >>> >> the WEBRTC chairs will hold their meeting on June 11th. If CLUE >>> >> wishes to co-locate their meeting, the 14th and 15th will be >>> >> available. This would not have been possible on the previous week, >>> >> given the national holiday in Sweden on the Wednesday of that week. >>> >> >>> >> We very much appreciated the work Eric put into his analysis, and in >>> >> general we will try to prefer hubs; in this particular case, however= , >>> >> a large fraction of the Western European participants are either bas= ed >>> >> in Stockholm or must fly through it to reach one of the larger hubs. >>> >> Given the availability of a host and this data, we decided to select >>> >> Stockholm for this meeting. >>> >> >>> >> regards, >>> >> >>> >> Ted Hardie, for the chairs. >>> > >>> >>> >>> -- >>> >>> 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 >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> >> > --f46d043c7c7814826704be590b39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Resending with updated date in the subject.

On Thu, Apr 19, 2012 at 6:32 PM, Mary Barnes <mary.ietf.barnes@gmail.com>= wrote:
Hi all,

The doodle indica= tes that a majority support having the meeting in Stockholm. =A0The exact l= ocation is TBD. =A0We'll provide details as soon as we confirm a meetin= g space.

If you did not reply to the original doodle with regards to the date and pl= an to attend the meeting please fill out the doodle for June 7th ASAP or in= dicate Stockholm in the location doodle. =A0We need to have a fairly firm n= umber for the number of attendees as we work out the remaining logistics.

Thanks to everyone for their patience as we worked to c= oordinate this meeting with RTCWEB.

Mary.

<= div class=3D"gmail_quote">On Thu, Apr 19, 2012 at 12:57 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Note, I'm resending with a different Sub= ject to ensure folks read it (even if you don't care about RTCWEB)

---------- Forwarded message ----------
From:= Mary Barnes <mary.ietf.barnes@= gmail.com>
Date: Thu, Apr 19, 2012 at 12:46 PM
Subject: Re: [clue] Fwd: [rtcweb] UR= GENT: Dates for upcoming interim ON HOLD
To: Marshall Eubanks <marshall.eubanks@= gmail.com>
Cc: clue <clue@ietf.o= rg>


As I've highlighted in previous emails, we have a= doodle for location selection for the CLUE meeting:=A0
This poll closes at noon Pacific today - i.e., in 1.5 hours. =A0So, we= will make the decision for the location at the end of today.

Note that our date has been set for June 7-8 based on o= ur original poll: =A0=A0http://doodle.com/nm3pp69znr3286cy

Please note, that there are significantly fewer people that have responded = to the location doodle poll than people that indicated they could attend th= e meeting on the 7th-8th, per the poll for meeting dates. =A0So we'll a= ssume whomever doesn't respond to the location poll is okay with any of= the locations. =A0Folks that want to attend both meetings are strongly enc= ouraged to indicate their preference for Stockholm unless you want to spend= the weekend traveling from Boston or San Jose.=A0

Thanks,
Mary.=A0


On Thu, Apr 19, 2012 at 6:35 AM, Marshall Eubanks <marshall.eubanks@gmail.com> wrote:
FYI


---------- Forwarded message ----------
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Thu, Apr 19, 2012 at 5:18 AM
Subject: Re: [rtcweb] URGENT: Dates for upcoming interim ON HOLD
To: Ted Hardie <= ted.ietf@gmail.com>
Cc: Cullen Jennings <fluffy@cisco.com>, "rai-ads@tools.ietf.org"
<rai-ads@too= ls.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>,
"clue-= chairs@tools.ietf.org" <clue-chairs@tools.ietf.org>


RTCWEB WG,

The dates for the upcoming interim is off the hold. I can confirm AD
approval, and that we will hold an Face to Face interim meeting on the
12th and 13th of June in Stockholm. The W3C WebRTC WG will hold a
meeting in Stockholm on the 11th of June. Assume meeting 9.00-18.00 for
each of those days.

As a Host I can't confirm the location within Stockholm yet. We are
aiming on either a location in Kista or in the central part of town.
There are some hotels out in Kista, but even if we end up in Kista
staying in central Stockholm allows for a short (17 min) subway ride
from T-centralen plus a no more than 10 min walk to the Kista venue.
Making it a very viable option to book a hotel room in the area around
T-centralen or on Kungsholmen with easy access to the blue-line subway.

Cheers

Magnus Westerlund




On 2012-04-12 19:42, Ted Hardie wrote:
> Please hold off making travel plans based on this timing. =A0 Because<= br> > neither RAI area director will be available during this timing, they > have asked to consider shifting this timing to the previous week, June=
> 7th and 8th. =A0Until the chairs have had a chance to discuss this, > please hold off on booking travel plans.
>
> My apologies for this scramble,
>
> Ted Hardie
>
> On Thu, Apr 12, 2012 at 8:20 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>> After discussion between the WEBRTC and RTCWEB chairs, consulting = the
>> doodle poll, and working through the potential for co-location wit= h
>> CLUE, we have decided to set the date for the RTCWEB interim at Ju= ne
>> 12 & 13th, to be hosted by Ericsson in Stockholm. =A0We unders= tand that
>> the WEBRTC chairs will hold their meeting on June 11th. =A0If CLUE=
>> wishes to co-locate their meeting, the 14th and 15th will be
>> available. =A0This would not have been possible on the previous we= ek,
>> given the national holiday in Sweden on the Wednesday of that week= .
>>
>> We very much appreciated the work Eric put into his analysis, and = in
>> general we will try to prefer hubs; in this particular case, howev= er,
>> a large fraction of the Western European participants are either b= ased
>> in Stockholm or must fly through it to reach one of the larger hub= s.
>> Given the availability of a host and this data, we decided to sele= ct
>> Stockholm for this meeting.
>>
>> regards,
>>
>> Ted Hardie, for the chairs.
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287=
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue




--f46d043c7c7814826704be590b39-- From pkyzivat@alum.mit.edu Mon Apr 23 12:48:44 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D6321F8474 for ; Mon, 23 Apr 2012 12:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNHyPWrt0BBi for ; Mon, 23 Apr 2012 12:48:43 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB5821F845C for ; Mon, 23 Apr 2012 12:48:43 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id 1Uu91j0051ZXKqc55Xokp0; Mon, 23 Apr 2012 19:48:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id 1Xoj1j00707duvL3hXojZp; Mon, 23 Apr 2012 19:48:43 +0000 Message-ID: <4F95B21A.2000900@alum.mit.edu> Date: Mon, 23 Apr 2012 15:48:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] No design team meeting tomorrow Tues Apr 24 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:48:44 -0000 Mary and I think there hasn't been enough happen since the last meeting to support a meeting tomorrow. So we'll leave people to spend the time more productively. (I still own a more detailed use case to support discussing how recipient can figure out what captures to use. I'll try to get it out soon.) Thanks, Paul From pkyzivat@alum.mit.edu Thu Apr 26 09:57:20 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0921E80DA for ; Thu, 26 Apr 2012 09:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPEwcIj8isam for ; Thu, 26 Apr 2012 09:57:19 -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 C59CE21E801E for ; Thu, 26 Apr 2012 09:57:16 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id 2fPl1j0051wpRvQ5DgxHJH; Thu, 26 Apr 2012 16:57:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id 2gxF1j00a07duvL3egxF0a; Thu, 26 Apr 2012 16:57:15 +0000 Message-ID: <4F997E6B.7070501@alum.mit.edu> Date: Thu, 26 Apr 2012 12:57:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:57:20 -0000 I am working on my use cases for the question about how to select which captures to display. But I have a gap in my understanding, and would like to get input from those of you with more experience in a diversity of telepresence systems. My only live experience with telepresence systems is with the Cisco ones. I'm not aware of it having any explicit support for presentations, though that might just be my lack of understanding. So I'd like to hear what *is* supported, or is *intended* to be supported. I presume that for the most part presentations these days originate in a computer and are fed into the telepresence system, much like they are in webex - either by preloading documents to the conference controller and then interacting with it from a computer to have them displayed, or by "sharing an application" dynamically from a computer. I understand that in a system like webex, which is not a telepresence system. But what does that mean when married to a telepresence system? Some ways I can imagine this working: - visitors to a telepresence room bring their own computers. Each seat has a video connector that the visitor can connect to and originate a presentation stream. When active, these become additional captures from the room. But for others in the same room to see, these would then have to be treated as incoming captures (from where) and displayed on some display in the room. - visitors to a telepresence room bring their own computers. Each such computer connects to an MCU as if it were an independent endpoint/room. The computer then offers up whatever it wants to share as a capture. The room itself also connects to the MCU, with its cameras as captures. The MCU sorts this all out, handles floor control, and decides what to advertise. So it can include presentations from user's computers as well as captures from the rooms. The local room can then display one or more presentations on its diplays. Or, the user's computer could also serve as a display for presentations so that the room's displays could be reserved for showing participants in other rooms. - the telepresence room could have a personal display and controller at each seat. This could provide the user with a controller to request the floor, to review preloaded documents and request their display, etc. (Its a bit like the first one above.) There seems to be a big difference if the presentation is seen as coming from a room that has the typical telepresence layout, or if it is seen coming from a separate endpoint coupled to the computer generating it, and whether the presentation is displayed on equipment that is part of the room, or by a separate endpoint. I'd like feedback if any of the above makes sense, and whether there are other ways of looking at this I haven't imagined. Thanks, Paul From stephen.botzko@gmail.com Thu Apr 26 11:33:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9912D21E814F for ; Thu, 26 Apr 2012 11:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMkJSjCMWzMZ for ; Thu, 26 Apr 2012 11:33:49 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id ACC2021E8150 for ; Thu, 26 Apr 2012 11:33:49 -0700 (PDT) Received: by dady13 with SMTP id y13so2976417dad.27 for ; Thu, 26 Apr 2012 11:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZoJafEHrj2O2jVOfCsuwLg2CAls8d0DqQk7OxOzMlXc=; b=VdKoXw8fn6TrKc+C1J2Q3WpGjv3lWqEsmxFvhpcnTuW9RKTwcLAbXeaIvWL2cr+ERq lUDhcwZI+Db7scc/D8a6W7XE+HrOwua1tsT9AGoEHPeKmojU+9LdFqSSciqxfIyGIH9r crLSsu7rsmA1EmSQr1gl8PP7P+l4Dtp9kUdGPdqjuX9myBWZPkwwLHvMBfDpv2hqiUGU kIsC5J5rnEioNY16AY7smAgpY/qvqE1tGNCzPcsoi4b2bTxpMhLiNQYifhbilaDZ07aV 5RUxJwCd9mKNuX13ZNzfQALGa+CbJ5ESMSnb/gZcRwaW6A6MfBoxTADGqAQBWVSfh5mO WUdg== MIME-Version: 1.0 Received: by 10.68.212.227 with SMTP id nn3mr15593742pbc.122.1335465228543; Thu, 26 Apr 2012 11:33:48 -0700 (PDT) Received: by 10.68.136.69 with HTTP; Thu, 26 Apr 2012 11:33:48 -0700 (PDT) In-Reply-To: <4F997E6B.7070501@alum.mit.edu> References: <4F997E6B.7070501@alum.mit.edu> Date: Thu, 26 Apr 2012 14:33:48 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8ff1c0de8ea80b04be993a73 Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:33:50 -0000 --e89a8ff1c0de8ea80b04be993a73 Content-Type: text/plain; charset=ISO-8859-1 Most traditional videoconferencing systems support H.239 (with H.323), using a functionally equivalent method in SIP. The presentation video is assigned a role (e.g., slides), and the ability to send is token-controlled with BFCP. All endpoints in the conference receive the presentation. If there is a legacy device (which doesn't support presentations) on the far end, the sender usually chooses to send the presentation instead of the participant video. Computers can be connected using HDMI/Displayport/DVI/VGA directly to the video conferencing endpoint. Alternatively, there may be a PC application that screen-scrapes the display and sends it to the endpoint for distribution. These same options are used in telepresence systems. On the receiving side, there are several options. Sometimes the content is displayed on a separate monitor or projector. Sometimes the content is composed along with participants, and placed on a single display. In telepresence systems, there are frequently content monitors at each seat, all of which will display the presentation. Application sharing was common back in the 90's (using the T.120 protocol), but fell out of favor for a variety of reasons. Stephen Botzko On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat wrote: > I am working on my use cases for the question about how to select which > captures to display. But I have a gap in my understanding, and would like > to get input from those of you with more experience in a diversity of > telepresence systems. > > My only live experience with telepresence systems is with the Cisco ones. > I'm not aware of it having any explicit support for presentations, though > that might just be my lack of understanding. > > So I'd like to hear what *is* supported, or is *intended* to be supported. > > I presume that for the most part presentations these days originate in a > computer and are fed into the telepresence system, much like they are in > webex - either by preloading documents to the conference controller and > then interacting with it from a computer to have them displayed, or by > "sharing an application" dynamically from a computer. I understand that in > a system like webex, which is not a telepresence system. But what does that > mean when married to a telepresence system? > > Some ways I can imagine this working: > > - visitors to a telepresence room bring their own computers. > Each seat has a video connector that the visitor can connect to > and originate a presentation stream. When active, these become > additional captures from the room. But for others in the same > room to see, these would then have to be treated as incoming > captures (from where) and displayed on some display in the room. > > - visitors to a telepresence room bring their own computers. > Each such computer connects to an MCU as if it were an independent > endpoint/room. The computer then offers up whatever it wants to > share as a capture. The room itself also connects to the MCU, > with its cameras as captures. The MCU sorts this all out, handles > floor control, and decides what to advertise. So it can include > presentations from user's computers as well as captures from the > rooms. The local room can then display one or more presentations > on its diplays. Or, the user's computer could also serve as a > display for presentations so that the room's displays could be > reserved for showing participants in other rooms. > > - the telepresence room could have a personal display and controller > at each seat. This could provide the user with a controller to > request the floor, to review preloaded documents and request their > display, etc. (Its a bit like the first one above.) > > There seems to be a big difference if the presentation is seen as coming > from a room that has the typical telepresence layout, or if it is seen > coming from a separate endpoint coupled to the computer generating it, and > whether the presentation is displayed on equipment that is part of the > room, or by a separate endpoint. > > I'd like feedback if any of the above makes sense, and whether there are > other ways of looking at this I haven't imagined. > > Thanks, > Paul > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --e89a8ff1c0de8ea80b04be993a73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Most traditional videoconferencing systems suppo= rt H.239 (with H.323), using a functionally equivalent method=A0 in SIP.=A0= The presentation video is assigned a role (e.g., slides), and the ability = to send is token-controlled with BFCP.=A0 All endpoints in the conference r= eceive the presentation.=A0 If there is a legacy device (which doesn't = support presentations) on the far end, the sender usually chooses to send t= he presentation instead of the participant video.

Computers can be connected using HDMI/Displayport/DVI/VGA directly to t= he video conferencing endpoint.=A0 Alternatively, there may be a PC applica= tion that screen-scrapes the display and sends it to the endpoint for distr= ibution. These same options are used in telepresence systems.

On the receiving side, there are several options.=A0 Sometimes the cont= ent is displayed on a separate monitor or projector.=A0 Sometimes the conte= nt is composed along with participants, and placed on a single display.=A0 = In telepresence systems, there are frequently content monitors at each seat= , all of which will display the presentation.

Application sharing was common back in the 90's (using the T.120 pr= otocol), but fell out of favor for a variety of reasons.

Stephen Bot= zko



On Thu, Apr 26, 2012 at 12:57= PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
I am working on my use cases for the questio= n about how to select which captures to display. But I have a gap in my und= erstanding, and would like to get input from those of you with more experie= nce in a diversity of telepresence systems.

My only live experience with telepresence systems is with the Cisco ones. I= 'm not aware of it having any explicit support for presentations, thoug= h that might just be my lack of understanding.

So I'd like to hear what *is* supported, or is *intended* to be support= ed.

I presume that for the most part presentations these days originate in a co= mputer and are fed into the telepresence system, much like they are in webe= x - either by preloading documents to the conference controller and then in= teracting with it from a computer to have them displayed, or by "shari= ng an application" dynamically from a computer. I understand that in a= system like webex, which is not a telepresence system. But what does that = mean when married to a telepresence system?

Some ways I can imagine this working:

- visitors to a telepresence room bring their own computers.
=A0Each seat has a video connector that the visitor can connect to
=A0and originate a presentation stream. When active, these become
=A0additional captures from the room. But for others in the same
=A0room to see, these would then have to be treated as incoming
=A0captures (from where) and displayed on some display in the room.

- visitors to a telepresence room bring their own computers.
=A0Each such computer connects to an MCU as if it were an independent
=A0endpoint/room. The computer then offers up whatever it wants to
=A0share as a capture. The room itself also connects to the MCU,
=A0with its cameras as captures. The MCU sorts this all out, handles
=A0floor control, and decides what to advertise. So it can include
=A0presentations from user's computers as well as captures from the =A0rooms. The local room can then display one or more presentations
=A0on its diplays. Or, the user's computer could also serve as a
=A0display for presentations so that the room's displays could be
=A0reserved for showing participants in other rooms.

- the telepresence room could have a personal display and controller
=A0at each seat. This could provide the user with a controller to
=A0request the floor, to review preloaded documents and request their
=A0display, etc. (Its a bit like the first one above.)

There seems to be a big difference if the presentation is seen as coming fr= om a room that has the typical telepresence layout, or if it is seen coming= from a separate endpoint coupled to the computer generating it, and whethe= r the presentation is displayed on equipment that is part of the room, or b= y a separate endpoint.

I'd like feedback if any of the above makes sense, and whether there ar= e other ways of looking at this I haven't imagined.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--e89a8ff1c0de8ea80b04be993a73-- From Mark.Duckworth@polycom.com Fri Apr 27 13:53:46 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6334C21F86EB for ; Fri, 27 Apr 2012 13:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq-naCLOwcW5 for ; Fri, 27 Apr 2012 13:53:45 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B9FDE21F86E8 for ; Fri, 27 Apr 2012 13:53:45 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 27 Apr 2012 13:53:44 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , CLUE Date: Fri, 27 Apr 2012 13:53:43 -0700 Thread-Topic: [clue] ways of managing presentations in telepresence sessions Thread-Index: Ac0jzbn+99gc7htPSZikFD5HwLInXQA6XXyQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FD3F6A35@CRPMBOXPRD01.polycom.com> References: <4F997E6B.7070501@alum.mit.edu> In-Reply-To: <4F997E6B.7070501@alum.mit.edu> 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 Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 20:53:46 -0000 Hi Paul, I agree with Steve's response, but want to add something else, see below. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Thursday, April 26, 2012 12:57 PM > To: CLUE > Subject: [clue] ways of managing presentations in telepresence sessions >=20 > I am working on my use cases for the question about how to select which > captures to display. But I have a gap in my understanding, and would like= to > get input from those of you with more experience in a diversity of > telepresence systems. >=20 > My only live experience with telepresence systems is with the Cisco ones. > I'm not aware of it having any explicit support for presentations, though= that > might just be my lack of understanding. >=20 > So I'd like to hear what *is* supported, or is *intended* to be supported= . >=20 > I presume that for the most part presentations these days originate in a > computer and are fed into the telepresence system, much like they are in > webex - either by preloading documents to the conference controller and > then interacting with it from a computer to have them displayed, or by > "sharing an application" dynamically from a computer. I understand that i= n a > system like webex, which is not a telepresence system. But what does that > mean when married to a telepresence system? >=20 > Some ways I can imagine this working: >=20 > - visitors to a telepresence room bring their own computers. > Each seat has a video connector that the visitor can connect to > and originate a presentation stream. When active, these become > additional captures from the room. But for others in the same > room to see, these would then have to be treated as incoming > captures (from where) and displayed on some display in the room. >=20 > - visitors to a telepresence room bring their own computers. > Each such computer connects to an MCU as if it were an independent > endpoint/room. The computer then offers up whatever it wants to > share as a capture. The room itself also connects to the MCU, > with its cameras as captures. The MCU sorts this all out, handles > floor control, and decides what to advertise. So it can include > presentations from user's computers as well as captures from the > rooms. The local room can then display one or more presentations > on its diplays. Or, the user's computer could also serve as a > display for presentations so that the room's displays could be > reserved for showing participants in other rooms. [Duckworth, Mark] Yes, a computer could make a separate connection (separat= e SIP call) to the MCU, but I don't see how the MCU can "sort this all out"= as if it knows something about the computer being used by the same people = in the same telepresence room that is also connected to the MCU. The "tele= presence room endpoint" and the "computer endpoint" would be totally indepe= ndent, and the MCU would treat them independently. Is that what you mean? > - the telepresence room could have a personal display and controller > at each seat. This could provide the user with a controller to > request the floor, to review preloaded documents and request their > display, etc. (Its a bit like the first one above.) >=20 > There seems to be a big difference if the presentation is seen as coming = from > a room that has the typical telepresence layout, or if it is seen coming = from a > separate endpoint coupled to the computer generating it, and whether the > presentation is displayed on equipment that is part of the room, or by a > separate endpoint. >=20 > I'd like feedback if any of the above makes sense, and whether there are > other ways of looking at this I haven't imagined. >=20 > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Fri Apr 27 14:11:00 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B3521E8015 for ; Fri, 27 Apr 2012 14:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+CcHMRblVMN for ; Fri, 27 Apr 2012 14:10:59 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1521E8011 for ; Fri, 27 Apr 2012 14:10:59 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta06.westchester.pa.mail.comcast.net with comcast id 397p1j00A1ap0As569B0pX; Fri, 27 Apr 2012 21:11:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id 39B11j00k07duvL3i9B2mL; Fri, 27 Apr 2012 21:11:02 +0000 Message-ID: <4F9B0B62.5090100@alum.mit.edu> Date: Fri, 27 Apr 2012 17:10:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Duckworth, Mark" References: <4F997E6B.7070501@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FD3F6A35@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FD3F6A35@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 21:11:00 -0000 On 4/27/12 4:53 PM, Duckworth, Mark wrote: >> - visitors to a telepresence room bring their own computers. >> Each such computer connects to an MCU as if it were an independent >> endpoint/room. The computer then offers up whatever it wants to >> share as a capture. The room itself also connects to the MCU, >> with its cameras as captures. The MCU sorts this all out, handles >> floor control, and decides what to advertise. So it can include >> presentations from user's computers as well as captures from the >> rooms. The local room can then display one or more presentations >> on its diplays. Or, the user's computer could also serve as a >> display for presentations so that the room's displays could be >> reserved for showing participants in other rooms. > > [Duckworth, Mark] Yes, a computer could make a separate connection (separate SIP call) to the MCU, but I don't see how the MCU can "sort this all out" as if it knows something about the computer being used by the same people in the same telepresence room that is also connected to the MCU. The "telepresence room endpoint" and the "computer endpoint" would be totally independent, and the MCU would treat them independently. Is that what you mean? I wasn't imagining that the MCU could figure out, on its own, that the computer was in the same room as another telepresence endpoint. But what it can work out is that it has another source of captures - in this case perhaps just a single capture marked as a presentation. If there are a lot of presentations coming in to the MCU this way then there may be a need for floor control. But if there is only one at a time, maybe not. Presumably that computer, with a UI being controlled by the user, can make its own decisions about what it wants to receive from the MCU. If the room is providing interesting displays of everything interesting, then maybe it won't receive anything. It would be more "interesting" if the computers of individual users also used a camera to send a capture containing an image of the user. Then it would indeed get complicated to sort out - captures from the room cameras plus captures from the cameras of computers belonging to individual users. I wasn't contemplating discussing that right now. Thanks, Paul From pkyzivat@alum.mit.edu Fri Apr 27 14:20:03 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4DA21F85B4 for ; Fri, 27 Apr 2012 14:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DocNEq+Vm0ZO for ; Fri, 27 Apr 2012 14:20:02 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 5F40921F85B6 for ; Fri, 27 Apr 2012 14:20:02 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id 39841j0011ZXKqc599L3v1; Fri, 27 Apr 2012 21:20:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id 39L11j00j07duvL3h9L1s5; Fri, 27 Apr 2012 21:20:01 +0000 Message-ID: <4F9B0D81.4040608@alum.mit.edu> Date: Fri, 27 Apr 2012 17:20:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Stephen Botzko References: <4F997E6B.7070501@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 21:20:03 -0000 On 4/26/12 2:33 PM, Stephen Botzko wrote: > Most traditional videoconferencing systems support H.239 (with H.323), > using a functionally equivalent method in SIP. The presentation video > is assigned a role (e.g., slides), and the ability to send is > token-controlled with BFCP. All endpoints in the conference receive the > presentation. If there is a legacy device (which doesn't support > presentations) on the far end, the sender usually chooses to send the > presentation instead of the participant video. > > Computers can be connected using HDMI/Displayport/DVI/VGA directly to > the video conferencing endpoint. Alternatively, there may be a PC > application that screen-scrapes the display and sends it to the endpoint > for distribution. These same options are used in telepresence systems. > > On the receiving side, there are several options. Sometimes the content > is displayed on a separate monitor or projector. Sometimes the content > is composed along with participants, and placed on a single display. In > telepresence systems, there are frequently content monitors at each > seat, all of which will display the presentation. > > Application sharing was common back in the 90's (using the T.120 > protocol), but fell out of favor for a variety of reasons. What is it that webex uses for application sharing? AFAIK that is not falling out of favor. I would much rather use webex application sharing than be forced to plug a video connector into my computer. Of course that is still somewhat cumbersome, but presumably it will be improved over time. Its the UI for driving it that is cumbersome, not the output. A key difference is that if the computer output is via video cable into the local room controller, then that is probably responsible for displaying it locally on a display in the room as well as sending it to the remote end. If the users connect their computers directly to the MCU, then the capture will come to the room just like anything else from the MCU. Thanks, Paul > Stephen Botzko > > > > On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat > wrote: > > I am working on my use cases for the question about how to select > which captures to display. But I have a gap in my understanding, and > would like to get input from those of you with more experience in a > diversity of telepresence systems. > > My only live experience with telepresence systems is with the Cisco > ones. I'm not aware of it having any explicit support for > presentations, though that might just be my lack of understanding. > > So I'd like to hear what *is* supported, or is *intended* to be > supported. > > I presume that for the most part presentations these days originate > in a computer and are fed into the telepresence system, much like > they are in webex - either by preloading documents to the conference > controller and then interacting with it from a computer to have them > displayed, or by "sharing an application" dynamically from a > computer. I understand that in a system like webex, which is not a > telepresence system. But what does that mean when married to a > telepresence system? > > Some ways I can imagine this working: > > - visitors to a telepresence room bring their own computers. > Each seat has a video connector that the visitor can connect to > and originate a presentation stream. When active, these become > additional captures from the room. But for others in the same > room to see, these would then have to be treated as incoming > captures (from where) and displayed on some display in the room. > > - visitors to a telepresence room bring their own computers. > Each such computer connects to an MCU as if it were an independent > endpoint/room. The computer then offers up whatever it wants to > share as a capture. The room itself also connects to the MCU, > with its cameras as captures. The MCU sorts this all out, handles > floor control, and decides what to advertise. So it can include > presentations from user's computers as well as captures from the > rooms. The local room can then display one or more presentations > on its diplays. Or, the user's computer could also serve as a > display for presentations so that the room's displays could be > reserved for showing participants in other rooms. > > - the telepresence room could have a personal display and controller > at each seat. This could provide the user with a controller to > request the floor, to review preloaded documents and request their > display, etc. (Its a bit like the first one above.) > > There seems to be a big difference if the presentation is seen as > coming from a room that has the typical telepresence layout, or if > it is seen coming from a separate endpoint coupled to the computer > generating it, and whether the presentation is displayed on > equipment that is part of the room, or by a separate endpoint. > > I'd like feedback if any of the above makes sense, and whether there > are other ways of looking at this I haven't imagined. > > Thanks, > Paul > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > From marshall.eubanks@gmail.com Fri Apr 27 14:30:39 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1922E11E8087 for ; Fri, 27 Apr 2012 14:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.606 X-Spam-Level: X-Spam-Status: No, score=-103.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJt5aHJetP8z for ; Fri, 27 Apr 2012 14:30:38 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6C1511E8089 for ; Fri, 27 Apr 2012 14:30:37 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so901121lbb.31 for ; Fri, 27 Apr 2012 14:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YE97qAopMKhX7y9oYwGf5yrW7daCfgC01LLLHEv7H/M=; b=hJvIx+nAWdbAcxM3GLnqsP8BZZls/LFpN4bOsPNJMvynpRT/vNmPs84mRYY1jSPzB/ om9whSC9MsQ0i7vdV2iOFMZyiynH8g01395n0Wu7RLzWWPjcMn2hfOKYlsijvTcra/jt 89bicPFJNVucOZNNUEcsdfvOpVU0Q0lWz+lGgfGpoNVjZQkWmCgGjBApJa6HUka1k9pw wZ3Hjl/gjNAXc3GxrBFirtIiFWXW1+bjE994ga6ovTaPO8O2QYim/Dv9uYhw4AMDoLeh dHKIjM98K2u0/IBIiUXIORsXZ33tZ/CNNkZNMy00DiLq5RGHVHvLKZH0mHKlnNuiQyKe Uw1g== MIME-Version: 1.0 Received: by 10.112.23.100 with SMTP id l4mr5904959lbf.100.1335562236730; Fri, 27 Apr 2012 14:30:36 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Fri, 27 Apr 2012 14:30:36 -0700 (PDT) In-Reply-To: <4F9B0D81.4040608@alum.mit.edu> References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> Date: Fri, 27 Apr 2012 17:30:36 -0400 Message-ID: From: Marshall Eubanks To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 21:30:39 -0000 On Fri, Apr 27, 2012 at 5:20 PM, Paul Kyzivat wrote= : > On 4/26/12 2:33 PM, Stephen Botzko wrote: >> >> Most traditional videoconferencing systems support H.239 (with H.323), >> using a functionally equivalent method =A0in SIP. =A0The presentation vi= deo >> is assigned a role (e.g., slides), and the ability to send is >> token-controlled with BFCP. =A0All endpoints in the conference receive t= he >> presentation. =A0If there is a legacy device (which doesn't support >> presentations) on the far end, the sender usually chooses to send the >> presentation instead of the participant video. >> >> Computers can be connected using HDMI/Displayport/DVI/VGA directly to >> the video conferencing endpoint. =A0Alternatively, there may be a PC >> application that screen-scrapes the display and sends it to the endpoint >> for distribution. These same options are used in telepresence systems. >> >> On the receiving side, there are several options. =A0Sometimes the conte= nt >> is displayed on a separate monitor or projector. =A0Sometimes the conten= t >> is composed along with participants, and placed on a single display. =A0= In >> telepresence systems, there are frequently content monitors at each >> seat, all of which will display the presentation. >> >> Application sharing was common back in the 90's (using the T.120 >> protocol), but fell out of favor for a variety of reasons. > > > What is it that webex uses for application sharing? AFAIK that is not > falling out of favor. I would much rather use webex application sharing t= han > be forced to plug a video connector into my computer. > > Of course that is still somewhat cumbersome, but presumably it will be > improved over time. Its the UI for driving it that is cumbersome, not the > output. > Since this is true, and since it is very hard to change such behavior, this raises the question : Is there a CLUE role for metadata exchange with applications such as Webex? Or, are we going to be condemned to running separate asynchronous conferences for data and telepresence ? I am not sure of the answer, but I did want to raise the question. Regards Marshall > A key difference is that if the computer output is via video cable into t= he > local room controller, then that is probably responsible for displaying i= t > locally on a display in the room as well as sending it to the remote end.= If > the users connect their computers directly to the MCU, then the capture w= ill > come to the room just like anything else from the MCU. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> Stephen Botzko >> >> >> >> On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat > > wrote: >> >> =A0 =A0I am working on my use cases for the question about how to select >> =A0 =A0which captures to display. But I have a gap in my understanding, = and >> =A0 =A0would like to get input from those of you with more experience in= a >> =A0 =A0diversity of telepresence systems. >> >> =A0 =A0My only live experience with telepresence systems is with the Cis= co >> =A0 =A0ones. I'm not aware of it having any explicit support for >> =A0 =A0presentations, though that might just be my lack of understanding= . >> >> =A0 =A0So I'd like to hear what *is* supported, or is *intended* to be >> =A0 =A0supported. >> >> =A0 =A0I presume that for the most part presentations these days origina= te >> =A0 =A0in a computer and are fed into the telepresence system, much like >> =A0 =A0they are in webex - either by preloading documents to the confere= nce >> =A0 =A0controller and then interacting with it from a computer to have t= hem >> =A0 =A0displayed, or by "sharing an application" dynamically from a >> =A0 =A0computer. I understand that in a system like webex, which is not = a >> =A0 =A0telepresence system. But what does that mean when married to a >> =A0 =A0telepresence system? >> >> =A0 =A0Some ways I can imagine this working: >> >> =A0 =A0- visitors to a telepresence room bring their own computers. >> =A0 =A0 =A0Each seat has a video connector that the visitor can connect = to >> =A0 =A0 =A0and originate a presentation stream. When active, these becom= e >> =A0 =A0 =A0additional captures from the room. But for others in the same >> =A0 =A0 =A0room to see, these would then have to be treated as incoming >> =A0 =A0 =A0captures (from where) and displayed on some display in the ro= om. >> >> =A0 =A0- visitors to a telepresence room bring their own computers. >> =A0 =A0 =A0Each such computer connects to an MCU as if it were an indepe= ndent >> =A0 =A0 =A0endpoint/room. The computer then offers up whatever it wants = to >> =A0 =A0 =A0share as a capture. The room itself also connects to the MCU, >> =A0 =A0 =A0with its cameras as captures. The MCU sorts this all out, han= dles >> =A0 =A0 =A0floor control, and decides what to advertise. So it can inclu= de >> =A0 =A0 =A0presentations from user's computers as well as captures from = the >> =A0 =A0 =A0rooms. The local room can then display one or more presentati= ons >> =A0 =A0 =A0on its diplays. Or, the user's computer could also serve as a >> =A0 =A0 =A0display for presentations so that the room's displays could b= e >> =A0 =A0 =A0reserved for showing participants in other rooms. >> >> =A0 =A0- the telepresence room could have a personal display and control= ler >> =A0 =A0 =A0at each seat. This could provide the user with a controller t= o >> =A0 =A0 =A0request the floor, to review preloaded documents and request = their >> =A0 =A0 =A0display, etc. (Its a bit like the first one above.) >> >> =A0 =A0There seems to be a big difference if the presentation is seen as >> =A0 =A0coming from a room that has the typical telepresence layout, or i= f >> =A0 =A0it is seen coming from a separate endpoint coupled to the compute= r >> =A0 =A0generating it, and whether the presentation is displayed on >> =A0 =A0equipment that is part of the room, or by a separate endpoint. >> >> =A0 =A0I'd like feedback if any of the above makes sense, and whether th= ere >> =A0 =A0are other ways of looking at this I haven't imagined. >> >> =A0 =A0 =A0 =A0 =A0 =A0Thanks, >> =A0 =A0 =A0 =A0 =A0 =A0Paul >> =A0 =A0_________________________________________________ >> =A0 =A0clue mailing list >> =A0 =A0clue@ietf.org >> =A0 =A0https://www.ietf.org/mailman/__listinfo/clue >> =A0 =A0 >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Sat Apr 28 01:07:08 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929D221F86E3 for ; Sat, 28 Apr 2012 01:07:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClPoDIu++09a for ; Sat, 28 Apr 2012 01:07:07 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C93921F85E5 for ; Sat, 28 Apr 2012 01:07:07 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so1030133wib.13 for ; Sat, 28 Apr 2012 01:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=WDhehFk5mSZ0CxqDKy9Uf15yZcnInTv+fI4eZS360mQ=; b=hhVPdGEsNoTvTTUfTkDGIf/kacFYSq9VNELlYL0aSgtCLx7eclBRRrktNPFiaUQrXU 0yINJEzz4CPMH17hD6VXpqCvqzfG3Nz4jRwJtzY+gHaugvuclTfxVw3w24KFevIl8TbO V0266A/eUyZ7x6bCpTASBB3PABSnGId3gBwTEuhkTZJqea3/i7PfajCqWC6Zbvv7tHpt AmXFjOT6KZG9EmZ0JxQFFwqzzIxWg05tNuNOiP/Y5OYZVh2tIKIO3jGT3Rk84faurxQr y0dubS3sI6QoUTuVepkv5akvCjL/H8mzofaSpVHr6rGhyIPfGf8EL76Tlzx0j5scB1Zu 2+vA== Received: by 10.216.135.141 with SMTP id u13mr2176351wei.79.1335600425568; Sat, 28 Apr 2012 01:07:05 -0700 (PDT) Received: from windows8d787f9 ([109.67.230.123]) by mx.google.com with ESMTPS id ff2sm17069628wib.9.2012.04.28.01.07.02 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 Apr 2012 01:07:03 -0700 (PDT) From: "Roni Even" To: "'Marshall Eubanks'" , "'Paul Kyzivat'" References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> In-Reply-To: Date: Sat, 28 Apr 2012 11:05:17 +0300 Message-ID: <4f9ba527.6265b40a.7cae.0d9d@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0kvP9XAZ4OdPaUSkSuhg0T7yEAPgAVgRjQ Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 08:07:08 -0000 Hi, Steve in his response mentioned that the there is a data collaboration standard which is T.120 that was used in the past but is not used today. = The presentation stream is not for collaboration but just presentation and = works well in TP rooms equipped with monitors for the presentation stream. As for application sharing like WebEx or Meetecho all these solution are stimulus based and there is no standard for these solutions. Most of the video conferencing providers have such solution with some integration to = the video conference. I do not think that Clue should work on this integration since there is = no standard application sharing to integrate with. There was a proposal to work on application sharing in MMUSIC and AVT = couple of years ago (I think Jonathan had a draft with Henning) based on RTP = level. There was also a later draft http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 but = none of this progressed. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Marshall Eubanks > Sent: Saturday, April 28, 2012 12:31 AM > To: Paul Kyzivat > Cc: CLUE > Subject: Re: [clue] ways of managing presentations in telepresence > sessions >=20 > On Fri, Apr 27, 2012 at 5:20 PM, Paul Kyzivat > wrote: > > On 4/26/12 2:33 PM, Stephen Botzko wrote: > >> > >> Most traditional videoconferencing systems support H.239 (with > >> H.323), using a functionally equivalent method =A0in SIP. =A0The > >> presentation video is assigned a role (e.g., slides), and the > ability > >> to send is token-controlled with BFCP. =A0All endpoints in the > >> conference receive the presentation. =A0If there is a legacy device > >> (which doesn't support > >> presentations) on the far end, the sender usually chooses to send > the > >> presentation instead of the participant video. > >> > >> Computers can be connected using HDMI/Displayport/DVI/VGA directly > to > >> the video conferencing endpoint. =A0Alternatively, there may be a = PC > >> application that screen-scrapes the display and sends it to the > >> endpoint for distribution. These same options are used in > telepresence systems. > >> > >> On the receiving side, there are several options. =A0Sometimes the > >> content is displayed on a separate monitor or projector. = =A0Sometimes > >> the content is composed along with participants, and placed on a > >> single display. =A0In telepresence systems, there are frequently > >> content monitors at each seat, all of which will display the > presentation. > >> > >> Application sharing was common back in the 90's (using the T.120 > >> protocol), but fell out of favor for a variety of reasons. > > > > > > What is it that webex uses for application sharing? AFAIK that is = not > > falling out of favor. I would much rather use webex application > > sharing than be forced to plug a video connector into my computer. > > > > Of course that is still somewhat cumbersome, but presumably it will > be > > improved over time. Its the UI for driving it that is cumbersome, = not > > the output. > > >=20 > Since this is true, and since it is very hard to change such behavior, > this raises the question : >=20 > Is there a CLUE role for metadata exchange with applications such as > Webex? Or, are we going to be condemned to running separate > asynchronous conferences for data and telepresence ? >=20 > I am not sure of the answer, but I did want to raise the question. >=20 > Regards > Marshall >=20 >=20 > > A key difference is that if the computer output is via video cable > > into the local room controller, then that is probably responsible = for > > displaying it locally on a display in the room as well as sending it > > to the remote end. If the users connect their computers directly to > > the MCU, then the capture will come to the room just like anything > else from the MCU. > > > > =A0 =A0 =A0 =A0Thanks, > > =A0 =A0 =A0 =A0Paul > > > >> Stephen Botzko > >> > >> > >> > >> On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat > >> > wrote: > >> > >> =A0 =A0I am working on my use cases for the question about how to = select > >> =A0 =A0which captures to display. But I have a gap in my = understanding, > >> and > >> =A0 =A0would like to get input from those of you with more = experience in > >> a > >> =A0 =A0diversity of telepresence systems. > >> > >> =A0 =A0My only live experience with telepresence systems is with = the > >> Cisco > >> =A0 =A0ones. I'm not aware of it having any explicit support for > >> =A0 =A0presentations, though that might just be my lack of > understanding. > >> > >> =A0 =A0So I'd like to hear what *is* supported, or is *intended* to = be > >> =A0 =A0supported. > >> > >> =A0 =A0I presume that for the most part presentations these days > >> originate > >> =A0 =A0in a computer and are fed into the telepresence system, much = like > >> =A0 =A0they are in webex - either by preloading documents to the > >> conference > >> =A0 =A0controller and then interacting with it from a computer to = have > >> them > >> =A0 =A0displayed, or by "sharing an application" dynamically from a > >> =A0 =A0computer. I understand that in a system like webex, which is = not > a > >> =A0 =A0telepresence system. But what does that mean when married to = a > >> =A0 =A0telepresence system? > >> > >> =A0 =A0Some ways I can imagine this working: > >> > >> =A0 =A0- visitors to a telepresence room bring their own computers. > >> =A0 =A0 =A0Each seat has a video connector that the visitor can = connect to > >> =A0 =A0 =A0and originate a presentation stream. When active, these = become > >> =A0 =A0 =A0additional captures from the room. But for others in the = same > >> =A0 =A0 =A0room to see, these would then have to be treated as = incoming > >> =A0 =A0 =A0captures (from where) and displayed on some display in = the > room. > >> > >> =A0 =A0- visitors to a telepresence room bring their own computers. > >> =A0 =A0 =A0Each such computer connects to an MCU as if it were an > >> independent > >> =A0 =A0 =A0endpoint/room. The computer then offers up whatever it = wants to > >> =A0 =A0 =A0share as a capture. The room itself also connects to the = MCU, > >> =A0 =A0 =A0with its cameras as captures. The MCU sorts this all = out, > >> handles > >> =A0 =A0 =A0floor control, and decides what to advertise. So it can = include > >> =A0 =A0 =A0presentations from user's computers as well as captures = from > the > >> =A0 =A0 =A0rooms. The local room can then display one or more > presentations > >> =A0 =A0 =A0on its diplays. Or, the user's computer could also serve = as a > >> =A0 =A0 =A0display for presentations so that the room's displays = could be > >> =A0 =A0 =A0reserved for showing participants in other rooms. > >> > >> =A0 =A0- the telepresence room could have a personal display and > >> controller > >> =A0 =A0 =A0at each seat. This could provide the user with a = controller to > >> =A0 =A0 =A0request the floor, to review preloaded documents and = request > >> their > >> =A0 =A0 =A0display, etc. (Its a bit like the first one above.) > >> > >> =A0 =A0There seems to be a big difference if the presentation is = seen as > >> =A0 =A0coming from a room that has the typical telepresence layout, = or > if > >> =A0 =A0it is seen coming from a separate endpoint coupled to the > computer > >> =A0 =A0generating it, and whether the presentation is displayed on > >> =A0 =A0equipment that is part of the room, or by a separate = endpoint. > >> > >> =A0 =A0I'd like feedback if any of the above makes sense, and = whether > >> there > >> =A0 =A0are other ways of looking at this I haven't imagined. > >> > >> =A0 =A0 =A0 =A0 =A0 =A0Thanks, > >> =A0 =A0 =A0 =A0 =A0 =A0Paul > >> =A0 =A0_________________________________________________ > >> =A0 =A0clue mailing list > >> =A0 =A0clue@ietf.org > >> =A0 =A0https://www.ietf.org/mailman/__listinfo/clue > >> =A0 =A0 > >> > >> > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From br@brianrosen.net Sat Apr 28 06:16:51 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAA621F86C9 for ; Sat, 28 Apr 2012 06:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.75 X-Spam-Level: X-Spam-Status: No, score=-102.75 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAjXO+XErf8e for ; Sat, 28 Apr 2012 06:16:49 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.253]) by ietfa.amsl.com (Postfix) with ESMTP id CEBDA21F86C5 for ; Sat, 28 Apr 2012 06:16:48 -0700 (PDT) X-ASG-Debug-ID: 1335619007-0491e52ee989ac0001-dOUo1C Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id vUQdwEWXxzNFpexK; Sat, 28 Apr 2012 06:16:47 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[156.154.4.11]) by wwh1.winweblinux.com with esmtpa (Exim 4.69) (envelope-from ) id 1SO7W3-001Wxl-3k; Sat, 28 Apr 2012 06:16:47 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [clue] ways of managing presentations in telepresence sessions Content-Type: text/plain; charset=windows-1252 From: Brian Rosen In-Reply-To: <4F9B0D81.4040608@alum.mit.edu> Date: Sat, 28 Apr 2012 09:16:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1335619007 X-Barracuda-URL: http://64.34.111.253:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.95403 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 13:16:51 -0000 Most of the commercial web share systems download a piece of java that = grabs the screen update commands. I agree that using these services is interesting, but passing control = would be nice and aligning rosters would be nice and =85 That means some reasonable protocol that webex et. al. could use to do = that. I def wouldn't want to try to do what webex does some other way in an = MCU. Brian On Apr 27, 2012, at 5:20 PM, Paul Kyzivat wrote: > On 4/26/12 2:33 PM, Stephen Botzko wrote: >> Most traditional videoconferencing systems support H.239 (with = H.323), >> using a functionally equivalent method in SIP. The presentation = video >> is assigned a role (e.g., slides), and the ability to send is >> token-controlled with BFCP. All endpoints in the conference receive = the >> presentation. If there is a legacy device (which doesn't support >> presentations) on the far end, the sender usually chooses to send the >> presentation instead of the participant video. >>=20 >> Computers can be connected using HDMI/Displayport/DVI/VGA directly to >> the video conferencing endpoint. Alternatively, there may be a PC >> application that screen-scrapes the display and sends it to the = endpoint >> for distribution. These same options are used in telepresence = systems. >>=20 >> On the receiving side, there are several options. Sometimes the = content >> is displayed on a separate monitor or projector. Sometimes the = content >> is composed along with participants, and placed on a single display. = In >> telepresence systems, there are frequently content monitors at each >> seat, all of which will display the presentation. >>=20 >> Application sharing was common back in the 90's (using the T.120 >> protocol), but fell out of favor for a variety of reasons. >=20 > What is it that webex uses for application sharing? AFAIK that is not = falling out of favor. I would much rather use webex application sharing = than be forced to plug a video connector into my computer. >=20 > Of course that is still somewhat cumbersome, but presumably it will be = improved over time. Its the UI for driving it that is cumbersome, not = the output. >=20 > A key difference is that if the computer output is via video cable = into the local room controller, then that is probably responsible for = displaying it locally on a display in the room as well as sending it to = the remote end. If the users connect their computers directly to the = MCU, then the capture will come to the room just like anything else from = the MCU. >=20 > Thanks, > Paul >=20 >> Stephen Botzko >>=20 >>=20 >>=20 >> On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat > > wrote: >>=20 >> I am working on my use cases for the question about how to select >> which captures to display. But I have a gap in my understanding, and >> would like to get input from those of you with more experience in a >> diversity of telepresence systems. >>=20 >> My only live experience with telepresence systems is with the Cisco >> ones. I'm not aware of it having any explicit support for >> presentations, though that might just be my lack of understanding. >>=20 >> So I'd like to hear what *is* supported, or is *intended* to be >> supported. >>=20 >> I presume that for the most part presentations these days originate >> in a computer and are fed into the telepresence system, much like >> they are in webex - either by preloading documents to the conference >> controller and then interacting with it from a computer to have them >> displayed, or by "sharing an application" dynamically from a >> computer. I understand that in a system like webex, which is not a >> telepresence system. But what does that mean when married to a >> telepresence system? >>=20 >> Some ways I can imagine this working: >>=20 >> - visitors to a telepresence room bring their own computers. >> Each seat has a video connector that the visitor can connect to >> and originate a presentation stream. When active, these become >> additional captures from the room. But for others in the same >> room to see, these would then have to be treated as incoming >> captures (from where) and displayed on some display in the room. >>=20 >> - visitors to a telepresence room bring their own computers. >> Each such computer connects to an MCU as if it were an independent >> endpoint/room. The computer then offers up whatever it wants to >> share as a capture. The room itself also connects to the MCU, >> with its cameras as captures. The MCU sorts this all out, handles >> floor control, and decides what to advertise. So it can include >> presentations from user's computers as well as captures from the >> rooms. The local room can then display one or more presentations >> on its diplays. Or, the user's computer could also serve as a >> display for presentations so that the room's displays could be >> reserved for showing participants in other rooms. >>=20 >> - the telepresence room could have a personal display and controller >> at each seat. This could provide the user with a controller to >> request the floor, to review preloaded documents and request their >> display, etc. (Its a bit like the first one above.) >>=20 >> There seems to be a big difference if the presentation is seen as >> coming from a room that has the typical telepresence layout, or if >> it is seen coming from a separate endpoint coupled to the computer >> generating it, and whether the presentation is displayed on >> equipment that is part of the room, or by a separate endpoint. >>=20 >> I'd like feedback if any of the above makes sense, and whether there >> are other ways of looking at this I haven't imagined. >>=20 >> Thanks, >> Paul >> _________________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/__listinfo/clue >> >>=20 >>=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Sat Apr 28 10:18:40 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EEB21F8645 for ; Sat, 28 Apr 2012 10:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRbluSScIKtk for ; Sat, 28 Apr 2012 10:18:39 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 988F121F8644 for ; Sat, 28 Apr 2012 10:18:39 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so2173132pbb.31 for ; Sat, 28 Apr 2012 10:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o3ZXsqGxDjMwgWi9hMUUwEUHKzO3QbsUloYmQ6Ph7nw=; b=k5/jqyTlH5Qe67MVxfwvlC6I637Ede2QNXk9ZE/1d9BgwpjXyk3SPvArPtPR3Yo3sP finYw14NVMK7bVxzi3h97nPlwDuVOPL+64CA8HMxlbtIFtnGlQO4WryQe2QRVqDICB8c zPGecLqnoNNBMorI/glD4NvmWQVHoFfOhLDGy7gzvGeQKDJt4/yfGBYGNw5S2jB/q5hi hBke7AIFnny7r6HuRVh8zDjqkxJsuxCNKrNUYe3f6YDX38oqcpeBrp9RtZ2mY8LCyS+e Wuf1OKJBrHAnoyqsSV6vuxj7RNw+i3Y4CctSrPrZKiRV+cXUqgHuXCVpEnq/IZ4RSV/g 2VCg== MIME-Version: 1.0 Received: by 10.68.189.41 with SMTP id gf9mr18795711pbc.17.1335633519412; Sat, 28 Apr 2012 10:18:39 -0700 (PDT) Received: by 10.68.136.69 with HTTP; Sat, 28 Apr 2012 10:18:39 -0700 (PDT) In-Reply-To: <4F9B0D81.4040608@alum.mit.edu> References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> Date: Sat, 28 Apr 2012 13:18:39 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8ff1c70679875604bec069f8 Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 17:18:40 -0000 --e89a8ff1c70679875604bec069f8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 27, 2012 at 5:20 PM, Paul Kyzivat wrote: > On 4/26/12 2:33 PM, Stephen Botzko wrote: > >> Most traditional videoconferencing systems support H.239 (with H.323), >> using a functionally equivalent method in SIP. The presentation video >> is assigned a role (e.g., slides), and the ability to send is >> token-controlled with BFCP. All endpoints in the conference receive the >> presentation. If there is a legacy device (which doesn't support >> presentations) on the far end, the sender usually chooses to send the >> presentation instead of the participant video. >> >> Computers can be connected using HDMI/Displayport/DVI/VGA directly to >> the video conferencing endpoint. Alternatively, there may be a PC >> application that screen-scrapes the display and sends it to the endpoint >> for distribution. These same options are used in telepresence systems. >> >> On the receiving side, there are several options. Sometimes the content >> is displayed on a separate monitor or projector. Sometimes the content >> is composed along with participants, and placed on a single display. In >> telepresence systems, there are frequently content monitors at each >> seat, all of which will display the presentation. >> >> Application sharing was common back in the 90's (using the T.120 >> protocol), but fell out of favor for a variety of reasons. >> > > What is it that webex uses for application sharing? AFAIK that is not > falling out of favor. I would much rather use webex application sharing > than be forced to plug a video connector into my computer. > [sb] As I mentioned above, the existing solutions usually include a screen-scrape application, so you don't have to use a video cable. This is essentially the same as using Webex for presenting (but not remote control). Also, even though Webex allows remote control, in my experience that feature is not used as much as simple presenting. I am not saying it has no value, just that the most common case I see is a simple presentation. Supporting the video cable still has value, especially if you have guest presenter who does not have access to your local network. Most of those presenters are expecting to use a projector, so they have the cables with them. My answer on application sharing falling "out of favor" related specifically to vendor support for standards-based application sharing (T.120 in particular) - which I thought was responsive to your original question. Perhaps I misunderstood it. Anyway there were several reasons [and perhaps various viewpoints] on why T.120 was dropped, though I think it is probably not a useful discussion for this list. I know of no other standards-based protocol for application sharing. BTW, it is relatively common for web screen sharing to co-exist with the videoconferencing presentation methods. For instance, you can have a stand-alone webex conference, with someone sharing their laptop screen for the video participants.[/sb] > > Of course that is still somewhat cumbersome, but presumably it will be > improved over time. Its the UI for driving it that is cumbersome, not the > output. > > A key difference is that if the computer output is via video cable into > the local room controller, then that is probably responsible for displaying > it locally on a display in the room as well as sending it to the remote > end. If the users connect their computers directly to the MCU, then the > capture will come to the room just like anything else from the MCU. > [sb]The standard model for videoconferencing presentations is a token-controlled transmission. If you don't have the token, you are receiving. The local equipment is always responsible for display. Looping the presentation back through the MCU back to the originating site wastes bandwidth. I don't know if web conferencing solutions do this differently or not. I've always assumed that when I grab the webex "ball" I stop receiving desktop images. Certainly there is no reason for the server to send them back to me.[/sb] > > Thanks, > Paul > > Stephen Botzko >> >> >> >> On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat > **> wrote: >> >> I am working on my use cases for the question about how to select >> which captures to display. But I have a gap in my understanding, and >> would like to get input from those of you with more experience in a >> diversity of telepresence systems. >> >> My only live experience with telepresence systems is with the Cisco >> ones. I'm not aware of it having any explicit support for >> presentations, though that might just be my lack of understanding. >> >> So I'd like to hear what *is* supported, or is *intended* to be >> supported. >> >> I presume that for the most part presentations these days originate >> in a computer and are fed into the telepresence system, much like >> they are in webex - either by preloading documents to the conference >> controller and then interacting with it from a computer to have them >> displayed, or by "sharing an application" dynamically from a >> computer. I understand that in a system like webex, which is not a >> telepresence system. But what does that mean when married to a >> telepresence system? >> >> Some ways I can imagine this working: >> >> - visitors to a telepresence room bring their own computers. >> Each seat has a video connector that the visitor can connect to >> and originate a presentation stream. When active, these become >> additional captures from the room. But for others in the same >> room to see, these would then have to be treated as incoming >> captures (from where) and displayed on some display in the room. >> >> - visitors to a telepresence room bring their own computers. >> Each such computer connects to an MCU as if it were an independent >> endpoint/room. The computer then offers up whatever it wants to >> share as a capture. The room itself also connects to the MCU, >> with its cameras as captures. The MCU sorts this all out, handles >> floor control, and decides what to advertise. So it can include >> presentations from user's computers as well as captures from the >> rooms. The local room can then display one or more presentations >> on its diplays. Or, the user's computer could also serve as a >> display for presentations so that the room's displays could be >> reserved for showing participants in other rooms. >> >> - the telepresence room could have a personal display and controller >> at each seat. This could provide the user with a controller to >> request the floor, to review preloaded documents and request their >> display, etc. (Its a bit like the first one above.) >> >> There seems to be a big difference if the presentation is seen as >> coming from a room that has the typical telepresence layout, or if >> it is seen coming from a separate endpoint coupled to the computer >> generating it, and whether the presentation is displayed on >> equipment that is part of the room, or by a separate endpoint. >> >> I'd like feedback if any of the above makes sense, and whether there >> are other ways of looking at this I haven't imagined. >> >> Thanks, >> Paul >> ______________________________**___________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/clue >> >> > >> >> >> > --e89a8ff1c70679875604bec069f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 27, 2012 at 5:20 PM, Paul Ky= zivat <pkyzivat@alum.mit.edu> wrote:
On 4/26/12 2:33 PM, Stephen Botzko wrote:
Most traditional videoconferencing systems support H.239 (with H.323),
using a functionally equivalent method =A0in SIP. =A0The presentation video=
is assigned a role (e.g., slides), and the ability to send is
token-controlled with BFCP. =A0All endpoints in the conference receive the<= br> presentation. =A0If there is a legacy device (which doesn't support
presentations) on the far end, the sender usually chooses to send the
presentation instead of the participant video.

Computers can be connected using HDMI/Displayport/DVI/VGA directly to
the video conferencing endpoint. =A0Alternatively, there may be a PC
application that screen-scrapes the display and sends it to the endpoint for distribution. These same options are used in telepresence systems.

On the receiving side, there are several options. =A0Sometimes the content<= br> is displayed on a separate monitor or projector. =A0Sometimes the content is composed along with participants, and placed on a single display. =A0In<= br> telepresence systems, there are frequently content monitors at each
seat, all of which will display the presentation.

Application sharing was common back in the 90's (using the T.120
protocol), but fell out of favor for a variety of reasons.

What is it that webex uses for application sharing? AFAIK that is not falli= ng out of favor. I would much rather use webex application sharing than be = forced to plug a video connector into my computer.

[sb] As I mentioned above, the existing solutions usually include a scr= een-scrape application, so you don't have to use a video cable. This is= essentially the same as using Webex for presenting (but not remote control= ). Also, even though Webex allows remote control, in my experience that fea= ture is not used as much as simple presenting.=A0 I am not saying it has no= value, just that the most common case I see is a simple presentation.

Supporting the video cable still has value, especially if you have gues= t presenter who does not have access to your local network.=A0 Most of thos= e presenters are expecting to use a projector, so they have the cables with= them.=A0

My answer on application sharing falling "out of favor" relat= ed specifically to vendor support for standards-based application sharing (= T.120 in particular) - which I thought was responsive to your original ques= tion.=A0 Perhaps I misunderstood it.=A0 Anyway there were several reasons [= and perhaps various viewpoints] on why T.120 was dropped, though I think it= is probably not a useful discussion for this list.=A0 I know of no other s= tandards-based protocol for application sharing.

BTW, it is relatively common for web screen sharing to co-exist with th= e videoconferencing presentation methods.=A0 For instance, you can have a s= tand-alone webex conference, with someone sharing their laptop screen for t= he video participants.[/sb]

Of course that is still somewhat cumbersome, but presumably it will be impr= oved over time. Its the UI for driving it that is cumbersome, not the outpu= t.

A key difference is that if the computer output is via video cable into the= local room controller, then that is probably responsible for displaying it= locally on a display in the room as well as sending it to the remote end. = If the users connect their computers directly to the MCU, then the capture = will come to the room just like anything else from the MCU.
[sb]The standard model for videoconferencing presentation= s is a token-controlled transmission.=A0 If you don't have the token, y= ou are receiving. The local equipment is always responsible for display.=A0= Looping the presentation back through the MCU back to the originating site= wastes bandwidth.

I don't know if web conferencing solutions do this differently or n= ot.=A0 I've always assumed that when I grab the webex "ball" = I stop receiving desktop images.=A0 Certainly there is no reason for the se= rver to send them back to me.[/sb]

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

Stephen Botzko



On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
=
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0I am working on my use cases for the question about how to select =A0 =A0which captures to display. But I have a gap in my understanding, an= d
=A0 =A0would like to get input from those of you with more experience in a=
=A0 =A0diversity of telepresence systems.

=A0 =A0My only live experience with telepresence systems is with the Cisco=
=A0 =A0ones. I'm not aware of it having any explicit support for
=A0 =A0presentations, though that might just be my lack of understanding.<= br>
=A0 =A0So I'd like to hear what *is* supported, or is *intended* to be=
=A0 =A0supported.

=A0 =A0I presume that for the most part presentations these days originate=
=A0 =A0in a computer and are fed into the telepresence system, much like =A0 =A0they are in webex - either by preloading documents to the conferenc= e
=A0 =A0controller and then interacting with it from a computer to have the= m
=A0 =A0displayed, or by "sharing an application" dynamically fro= m a
=A0 =A0computer. I understand that in a system like webex, which is not a<= br> =A0 =A0telepresence system. But what does that mean when married to a
=A0 =A0telepresence system?

=A0 =A0Some ways I can imagine this working:

=A0 =A0- visitors to a telepresence room bring their own computers.
=A0 =A0 =A0Each seat has a video connector that the visitor can connect to=
=A0 =A0 =A0and originate a presentation stream. When active, these become<= br> =A0 =A0 =A0additional captures from the room. But for others in the same =A0 =A0 =A0room to see, these would then have to be treated as incoming =A0 =A0 =A0captures (from where) and displayed on some display in the room= .

=A0 =A0- visitors to a telepresence room bring their own computers.
=A0 =A0 =A0Each such computer connects to an MCU as if it were an independ= ent
=A0 =A0 =A0endpoint/room. The computer then offers up whatever it wants to=
=A0 =A0 =A0share as a capture. The room itself also connects to the MCU, =A0 =A0 =A0with its cameras as captures. The MCU sorts this all out, handl= es
=A0 =A0 =A0floor control, and decides what to advertise. So it can include=
=A0 =A0 =A0presentations from user's computers as well as captures fro= m the
=A0 =A0 =A0rooms. The local room can then display one or more presentation= s
=A0 =A0 =A0on its diplays. Or, the user's computer could also serve as= a
=A0 =A0 =A0display for presentations so that the room's displays could= be
=A0 =A0 =A0reserved for showing participants in other rooms.

=A0 =A0- the telepresence room could have a personal display and controlle= r
=A0 =A0 =A0at each seat. This could provide the user with a controller to<= br> =A0 =A0 =A0request the floor, to review preloaded documents and request th= eir
=A0 =A0 =A0display, etc. (Its a bit like the first one above.)

=A0 =A0There seems to be a big difference if the presentation is seen as =A0 =A0coming from a room that has the typical telepresence layout, or if<= br> =A0 =A0it is seen coming from a separate endpoint coupled to the computer<= br> =A0 =A0generating it, and whether the presentation is displayed on
=A0 =A0equipment that is part of the room, or by a separate endpoint.

=A0 =A0I'd like feedback if any of the above makes sense, and whether = there
=A0 =A0are other ways of looking at this I haven't imagined.

=A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0Paul
=A0 =A0_________________________________________________
=A0 =A0clue mailing list
=A0 =A0clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0https://www.ietf.org/mailman/__listinfo/clue
=A0 =A0<https://www.ietf.org/mailman/listinfo/clue>




--e89a8ff1c70679875604bec069f8-- From pkyzivat@alum.mit.edu Mon Apr 30 09:15:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FDB21F8744 for ; Mon, 30 Apr 2012 09:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pbh4mB9xeq8c for ; Mon, 30 Apr 2012 09:15:23 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6A59721F8743 for ; Mon, 30 Apr 2012 09:15:23 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta08.westchester.pa.mail.comcast.net with comcast id 4Caf1j0061wpRvQ58GFPUD; Mon, 30 Apr 2012 16:15:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id 4GFP1j00E07duvL3eGFPNi; Mon, 30 Apr 2012 16:15:23 +0000 Message-ID: <4F9EBA9C.8040208@alum.mit.edu> Date: Mon, 30 Apr 2012 12:15:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Roni Even References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4f9ba527.6265b40a.7cae.0d9d@mx.google.com> In-Reply-To: <4f9ba527.6265b40a.7cae.0d9d@mx.google.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: 'CLUE' Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:15:24 -0000 My thought was not about the application sharing mechanism details. What I was thinking is that the shared application would in some way be mapped to a presentation capture. The point that seems to matter the most is how this appears in the telepresence session topology. The share might show up as a capture from the room where the person doing the sharing resides. This implies that there is a connection between the computer doing the sharing to the controller for the room. And then the room controller will be deciding how to advertise it. E.g. it could display it on a screen in its own room and advertise it in the room scene with the position of that screen. Or the room controller could advertise the share as a presentation capture in a separate scene. Or the share might show up as a capture from a separate endpoint corresponding to the computer doing the sharing. Because this means there are at least three endpoints involved, it will require an MCU. And then the MCU will need to figure out what to advertise in order to make that capture available to all the rooms. ISTM that either of these approaches could be made to work. But if the computer doing the sharing is connecting over the web then it seems much more natural to me that it would be to a common point for the session, rather than to the room controller. I don't know how much of this it makes sense to address as part of CLUE, but I don't think we can ignore it entirely. Thanks, Paul On 4/28/12 4:05 AM, Roni Even wrote: > Hi, > Steve in his response mentioned that the there is a data collaboration > standard which is T.120 that was used in the past but is not used today. The > presentation stream is not for collaboration but just presentation and works > well in TP rooms equipped with monitors for the presentation stream. > > As for application sharing like WebEx or Meetecho all these solution are > stimulus based and there is no standard for these solutions. Most of the > video conferencing providers have such solution with some integration to the > video conference. > I do not think that Clue should work on this integration since there is no > standard application sharing to integrate with. > There was a proposal to work on application sharing in MMUSIC and AVT couple > of years ago (I think Jonathan had a draft with Henning) based on RTP level. > There was also a later draft > http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 but none > of this progressed. > > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Marshall Eubanks >> Sent: Saturday, April 28, 2012 12:31 AM >> To: Paul Kyzivat >> Cc: CLUE >> Subject: Re: [clue] ways of managing presentations in telepresence >> sessions >> >> On Fri, Apr 27, 2012 at 5:20 PM, Paul Kyzivat >> wrote: >>> On 4/26/12 2:33 PM, Stephen Botzko wrote: >>>> >>>> Most traditional videoconferencing systems support H.239 (with >>>> H.323), using a functionally equivalent method in SIP. The >>>> presentation video is assigned a role (e.g., slides), and the >> ability >>>> to send is token-controlled with BFCP. All endpoints in the >>>> conference receive the presentation. If there is a legacy device >>>> (which doesn't support >>>> presentations) on the far end, the sender usually chooses to send >> the >>>> presentation instead of the participant video. >>>> >>>> Computers can be connected using HDMI/Displayport/DVI/VGA directly >> to >>>> the video conferencing endpoint. Alternatively, there may be a PC >>>> application that screen-scrapes the display and sends it to the >>>> endpoint for distribution. These same options are used in >> telepresence systems. >>>> >>>> On the receiving side, there are several options. Sometimes the >>>> content is displayed on a separate monitor or projector. Sometimes >>>> the content is composed along with participants, and placed on a >>>> single display. In telepresence systems, there are frequently >>>> content monitors at each seat, all of which will display the >> presentation. >>>> >>>> Application sharing was common back in the 90's (using the T.120 >>>> protocol), but fell out of favor for a variety of reasons. >>> >>> >>> What is it that webex uses for application sharing? AFAIK that is not >>> falling out of favor. I would much rather use webex application >>> sharing than be forced to plug a video connector into my computer. >>> >>> Of course that is still somewhat cumbersome, but presumably it will >> be >>> improved over time. Its the UI for driving it that is cumbersome, not >>> the output. >>> >> >> Since this is true, and since it is very hard to change such behavior, >> this raises the question : >> >> Is there a CLUE role for metadata exchange with applications such as >> Webex? Or, are we going to be condemned to running separate >> asynchronous conferences for data and telepresence ? >> >> I am not sure of the answer, but I did want to raise the question. >> >> Regards >> Marshall >> >> >>> A key difference is that if the computer output is via video cable >>> into the local room controller, then that is probably responsible for >>> displaying it locally on a display in the room as well as sending it >>> to the remote end. If the users connect their computers directly to >>> the MCU, then the capture will come to the room just like anything >> else from the MCU. >>> >>> Thanks, >>> Paul >>> >>>> Stephen Botzko >>>> >>>> >>>> >>>> On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat >> >>> > wrote: >>>> >>>> I am working on my use cases for the question about how to select >>>> which captures to display. But I have a gap in my understanding, >>>> and >>>> would like to get input from those of you with more experience in >>>> a >>>> diversity of telepresence systems. >>>> >>>> My only live experience with telepresence systems is with the >>>> Cisco >>>> ones. I'm not aware of it having any explicit support for >>>> presentations, though that might just be my lack of >> understanding. >>>> >>>> So I'd like to hear what *is* supported, or is *intended* to be >>>> supported. >>>> >>>> I presume that for the most part presentations these days >>>> originate >>>> in a computer and are fed into the telepresence system, much like >>>> they are in webex - either by preloading documents to the >>>> conference >>>> controller and then interacting with it from a computer to have >>>> them >>>> displayed, or by "sharing an application" dynamically from a >>>> computer. I understand that in a system like webex, which is not >> a >>>> telepresence system. But what does that mean when married to a >>>> telepresence system? >>>> >>>> Some ways I can imagine this working: >>>> >>>> - visitors to a telepresence room bring their own computers. >>>> Each seat has a video connector that the visitor can connect to >>>> and originate a presentation stream. When active, these become >>>> additional captures from the room. But for others in the same >>>> room to see, these would then have to be treated as incoming >>>> captures (from where) and displayed on some display in the >> room. >>>> >>>> - visitors to a telepresence room bring their own computers. >>>> Each such computer connects to an MCU as if it were an >>>> independent >>>> endpoint/room. The computer then offers up whatever it wants to >>>> share as a capture. The room itself also connects to the MCU, >>>> with its cameras as captures. The MCU sorts this all out, >>>> handles >>>> floor control, and decides what to advertise. So it can include >>>> presentations from user's computers as well as captures from >> the >>>> rooms. The local room can then display one or more >> presentations >>>> on its diplays. Or, the user's computer could also serve as a >>>> display for presentations so that the room's displays could be >>>> reserved for showing participants in other rooms. >>>> >>>> - the telepresence room could have a personal display and >>>> controller >>>> at each seat. This could provide the user with a controller to >>>> request the floor, to review preloaded documents and request >>>> their >>>> display, etc. (Its a bit like the first one above.) >>>> >>>> There seems to be a big difference if the presentation is seen as >>>> coming from a room that has the typical telepresence layout, or >> if >>>> it is seen coming from a separate endpoint coupled to the >> computer >>>> generating it, and whether the presentation is displayed on >>>> equipment that is part of the room, or by a separate endpoint. >>>> >>>> I'd like feedback if any of the above makes sense, and whether >>>> there >>>> are other ways of looking at this I haven't imagined. >>>> >>>> Thanks, >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From pkyzivat@alum.mit.edu Mon Apr 30 09:44:39 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC6921F8809 for ; Mon, 30 Apr 2012 09:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNJLxJ3f5alN for ; Mon, 30 Apr 2012 09:44:28 -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 095AF21F87EE for ; Mon, 30 Apr 2012 09:44:23 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta13.westchester.pa.mail.comcast.net with comcast id 4GiG1j00C1uE5Es5DGkQXf; Mon, 30 Apr 2012 16:44:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id 4GkP1j02A07duvL3cGkQ3y; Mon, 30 Apr 2012 16:44:24 +0000 Message-ID: <4F9EC169.30601@alum.mit.edu> Date: Mon, 30 Apr 2012 12:44:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Brian Rosen References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:44:39 -0000 On 4/28/12 9:16 AM, Brian Rosen wrote: > Most of the commercial web share systems download a piece of java that grabs the screen update commands. > > I agree that using these services is interesting, but passing control would be nice and aligning rosters would be nice and … > > That means some reasonable protocol that webex et. al. could use to do that. > > I def wouldn't want to try to do what webex does some other way in an MCU. As I just said in another reply, its not clear to me exactly how much we need to address in CLUE, but I think its more than none. I certainly think we need to leave things relatively open for innovation in user interfaces and implementation techniques. I can see how an evolved webex server could connect to a CLUE MCU. But that would be a bit of a hack, since one would then have to configure a webex session and a CLUE conference separately. Or there could be a hybrid MCU that supports both CLUE and webex. And RTCWEB will presumably lead to other options for a computer to do its own sharing by creating a video stream from an application window and sending it off to a CLUE MCU. And presumably there are many other possibilities. Thanks, Paul > Brian > > On Apr 27, 2012, at 5:20 PM, Paul Kyzivat wrote: > >> On 4/26/12 2:33 PM, Stephen Botzko wrote: >>> Most traditional videoconferencing systems support H.239 (with H.323), >>> using a functionally equivalent method in SIP. The presentation video >>> is assigned a role (e.g., slides), and the ability to send is >>> token-controlled with BFCP. All endpoints in the conference receive the >>> presentation. If there is a legacy device (which doesn't support >>> presentations) on the far end, the sender usually chooses to send the >>> presentation instead of the participant video. >>> >>> Computers can be connected using HDMI/Displayport/DVI/VGA directly to >>> the video conferencing endpoint. Alternatively, there may be a PC >>> application that screen-scrapes the display and sends it to the endpoint >>> for distribution. These same options are used in telepresence systems. >>> >>> On the receiving side, there are several options. Sometimes the content >>> is displayed on a separate monitor or projector. Sometimes the content >>> is composed along with participants, and placed on a single display. In >>> telepresence systems, there are frequently content monitors at each >>> seat, all of which will display the presentation. >>> >>> Application sharing was common back in the 90's (using the T.120 >>> protocol), but fell out of favor for a variety of reasons. >> >> What is it that webex uses for application sharing? AFAIK that is not falling out of favor. I would much rather use webex application sharing than be forced to plug a video connector into my computer. >> >> Of course that is still somewhat cumbersome, but presumably it will be improved over time. Its the UI for driving it that is cumbersome, not the output. >> >> A key difference is that if the computer output is via video cable into the local room controller, then that is probably responsible for displaying it locally on a display in the room as well as sending it to the remote end. If the users connect their computers directly to the MCU, then the capture will come to the room just like anything else from the MCU. >> >> Thanks, >> Paul >> >>> Stephen Botzko >>> >>> >>> >>> On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat>> > wrote: >>> >>> I am working on my use cases for the question about how to select >>> which captures to display. But I have a gap in my understanding, and >>> would like to get input from those of you with more experience in a >>> diversity of telepresence systems. >>> >>> My only live experience with telepresence systems is with the Cisco >>> ones. I'm not aware of it having any explicit support for >>> presentations, though that might just be my lack of understanding. >>> >>> So I'd like to hear what *is* supported, or is *intended* to be >>> supported. >>> >>> I presume that for the most part presentations these days originate >>> in a computer and are fed into the telepresence system, much like >>> they are in webex - either by preloading documents to the conference >>> controller and then interacting with it from a computer to have them >>> displayed, or by "sharing an application" dynamically from a >>> computer. I understand that in a system like webex, which is not a >>> telepresence system. But what does that mean when married to a >>> telepresence system? >>> >>> Some ways I can imagine this working: >>> >>> - visitors to a telepresence room bring their own computers. >>> Each seat has a video connector that the visitor can connect to >>> and originate a presentation stream. When active, these become >>> additional captures from the room. But for others in the same >>> room to see, these would then have to be treated as incoming >>> captures (from where) and displayed on some display in the room. >>> >>> - visitors to a telepresence room bring their own computers. >>> Each such computer connects to an MCU as if it were an independent >>> endpoint/room. The computer then offers up whatever it wants to >>> share as a capture. The room itself also connects to the MCU, >>> with its cameras as captures. The MCU sorts this all out, handles >>> floor control, and decides what to advertise. So it can include >>> presentations from user's computers as well as captures from the >>> rooms. The local room can then display one or more presentations >>> on its diplays. Or, the user's computer could also serve as a >>> display for presentations so that the room's displays could be >>> reserved for showing participants in other rooms. >>> >>> - the telepresence room could have a personal display and controller >>> at each seat. This could provide the user with a controller to >>> request the floor, to review preloaded documents and request their >>> display, etc. (Its a bit like the first one above.) >>> >>> There seems to be a big difference if the presentation is seen as >>> coming from a room that has the typical telepresence layout, or if >>> it is seen coming from a separate endpoint coupled to the computer >>> generating it, and whether the presentation is displayed on >>> equipment that is part of the room, or by a separate endpoint. >>> >>> I'd like feedback if any of the above makes sense, and whether there >>> are other ways of looking at this I haven't imagined. >>> >>> Thanks, >>> Paul >>> _________________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/__listinfo/clue >>> >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From pkyzivat@alum.mit.edu Mon Apr 30 09:56:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336EF21F8528 for ; Mon, 30 Apr 2012 09:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG0BCPGIUkoc for ; Mon, 30 Apr 2012 09:56:56 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 02AB021F87A2 for ; Mon, 30 Apr 2012 09:56:53 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta06.westchester.pa.mail.comcast.net with comcast id 4GiG1j00A0ldTLk56Gws4B; Mon, 30 Apr 2012 16:56:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta04.westchester.pa.mail.comcast.net with comcast id 4Gws1j01B07duvL3QGws4V; Mon, 30 Apr 2012 16:56:52 +0000 Message-ID: <4F9EC454.3060605@alum.mit.edu> Date: Mon, 30 Apr 2012 12:56:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Stephen Botzko References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:56:58 -0000 On 4/28/12 1:18 PM, Stephen Botzko wrote: > [sb] As I mentioned above, the existing solutions usually include a > screen-scrape application, so you don't have to use a video cable. This > is essentially the same as using Webex for presenting (but not remote > control). How are these solutions connected? Does the captured application data go to the local room controller, or to an MCU in the middle of the TP session? Or something else? > Also, even though Webex allows remote control, in my > experience that feature is not used as much as simple presenting. I am > not saying it has no value, just that the most common case I see is a > simple presentation. That is my experience as well. I wasn't thinking about the multi-user-control aspect. > Supporting the video cable still has value, especially if you have guest > presenter who does not have access to your local network. Most of those > presenters are expecting to use a projector, so they have the cables > with them. Surely. In this case, I presume the cable connects to the local room controller. If there are multiple cable connectors (e.g. one at each seat) do they show up as multiple presentation streams? Or is there some sort of switch and floor control? If so, how does one manage the floor control? > My answer on application sharing falling "out of favor" related > specifically to vendor support for standards-based application sharing > (T.120 in particular) - which I thought was responsive to your original > question. Perhaps I misunderstood it. Anyway there were several > reasons [and perhaps various viewpoints] on why T.120 was dropped, > though I think it is probably not a useful discussion for this list. I > know of no other standards-based protocol for application sharing. I wasn't assuming there was, other than a pure video (and maybe audio) stream interface. There are other fora for that sort of thing, but its my impression that this is largely a world of proprietary and defacto standards. > BTW, it is relatively common for web screen sharing to co-exist with the > videoconferencing presentation methods. For instance, you can have a > stand-alone webex conference, with someone sharing their laptop screen > for the video participants.[/sb] I have done this. But it was cumbersome. IIRC, getting the sharing to be visible in the room I was in required using a video cable in addition to using webex sharing. > Of course that is still somewhat cumbersome, but presumably it will > be improved over time. Its the UI for driving it that is cumbersome, > not the output. > > A key difference is that if the computer output is via video cable > into the local room controller, then that is probably responsible > for displaying it locally on a display in the room as well as > sending it to the remote end. If the users connect their computers > directly to the MCU, then the capture will come to the room just > like anything else from the MCU. > > [sb]The standard model for videoconferencing presentations is a > token-controlled transmission. If you don't have the token, you are > receiving. The local equipment is always responsible for display. > Looping the presentation back through the MCU back to the originating > site wastes bandwidth. > > I don't know if web conferencing solutions do this differently or not. > I've always assumed that when I grab the webex "ball" I stop receiving > desktop images. Certainly there is no reason for the server to send > them back to me.[/sb] Thanks, Paul From marshall.eubanks@gmail.com Mon Apr 30 10:49:33 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1057921F8880 for ; Mon, 30 Apr 2012 10:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.629 X-Spam-Level: X-Spam-Status: No, score=-103.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsdAvArGz2bU for ; Mon, 30 Apr 2012 10:49:32 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5EF421F887B for ; Mon, 30 Apr 2012 10:49:31 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so2260500lbb.31 for ; Mon, 30 Apr 2012 10:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5clt6DJpZZpa4/Tau+uyUTz82JVSVA/0Bke1bN66Y8U=; b=RLaugn5fucklS0oTVrx+quZl6rnoRtbBnQvK0swa4IP9lZoQO7hjqJwKXenqLWnBvQ ehZ8x5QBToEpDh9iEG7ey16lNWwFDED8EdCfqA0rEDmBeGl/+UbPUgQ7WQk3U6RSM4t0 Acgn6VJXKWhgOX1XZa/3a0Meq70JeVn9JcrqVXH+Pcg/MdyL1/prm+S2YzQehGsiOuvl FIqoasr8x+vgttN+GQQVtWd+gasI7sHT5Rk5EwgLcVtalSLVFUMPzb7gmOiKD4YS5Fx7 CFDfuQgHd5tCxE3fuKIVCtzMIH6Me7Ta2JKTbJxpzemPOTgHUgEeIOU+7PMkCtSB3EVz 76yw== MIME-Version: 1.0 Received: by 10.112.23.100 with SMTP id l4mr10111524lbf.100.1335808170544; Mon, 30 Apr 2012 10:49:30 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Mon, 30 Apr 2012 10:49:30 -0700 (PDT) In-Reply-To: <4F9EC454.3060605@alum.mit.edu> References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> Date: Mon, 30 Apr 2012 13:49:30 -0400 Message-ID: From: Marshall Eubanks To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 17:49:33 -0000 Here is a potential use case : There is a telepresence session and an associated webex-like computer sharing session. At some time, person X has the floor on the computer sharing session (i.e., they are the presenter). I want to see person X on screen. (Or, maybe, I am the chair, and I want every telepresence participant to see person X on their screen.) I want to see X even if he or she is not talking for a bit, so just doing voice switching is not enough. After a while, person Y starts displaying viewgraphs from their computer (i.e., they are now the presenter). I want the presenter screen to switch to showing person Y. Right now, all of this would be manual and very cumbersome to do, and yet I think it is an option people would want. Is publishing an XML scheme for describing this enough ? Could the telepresence system join the computer sharing session? Or can the computer sharing session join the telepresence as a participant, albeit a non-media producing or consuming participant? Regards Marshall On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat wrot= e: > On 4/28/12 1:18 PM, Stephen Botzko wrote: > >> [sb] As I mentioned above, the existing solutions usually include a >> screen-scrape application, so you don't have to use a video cable. This >> is essentially the same as using Webex for presenting (but not remote >> control). > > > How are these solutions connected? Does the captured application data go = to > the local room controller, or to an MCU in the middle of the TP session? = Or > something else? > > >> Also, even though Webex allows remote control, in my >> experience that feature is not used as much as simple presenting. =A0I a= m >> not saying it has no value, just that the most common case I see is a >> simple presentation. > > > That is my experience as well. I wasn't thinking about the > multi-user-control aspect. > > >> Supporting the video cable still has value, especially if you have guest >> presenter who does not have access to your local network. =A0Most of tho= se >> presenters are expecting to use a projector, so they have the cables >> with them. > > > Surely. In this case, I presume the cable connects to the local room > controller. If there are multiple cable connectors (e.g. one at each seat= ) > do they show up as multiple presentation streams? Or is there some sort o= f > switch and floor control? If so, how does one manage the floor control? > > >> My answer on application sharing falling "out of favor" related >> specifically to vendor support for standards-based application sharing >> (T.120 in particular) - which I thought was responsive to your original >> question. =A0Perhaps I misunderstood it. =A0Anyway there were several >> reasons [and perhaps various viewpoints] on why T.120 was dropped, >> though I think it is probably not a useful discussion for this list. =A0= I >> know of no other standards-based protocol for application sharing. > > > I wasn't assuming there was, other than a pure video (and maybe audio) > stream interface. There are other fora for that sort of thing, but its my > impression that this is largely a world of proprietary and defacto > standards. > > >> BTW, it is relatively common for web screen sharing to co-exist with the >> videoconferencing presentation methods. =A0For instance, you can have a >> stand-alone webex conference, with someone sharing their laptop screen >> for the video participants.[/sb] > > > I have done this. But it was cumbersome. IIRC, getting the sharing to be > visible in the room I was in required using a video cable in addition to > using webex sharing. > > >> =A0 =A0Of course that is still somewhat cumbersome, but presumably it wi= ll >> =A0 =A0be improved over time. Its the UI for driving it that is cumberso= me, >> =A0 =A0not the output. >> >> =A0 =A0A key difference is that if the computer output is via video cabl= e >> =A0 =A0into the local room controller, then that is probably responsible >> =A0 =A0for displaying it locally on a display in the room as well as >> =A0 =A0sending it to the remote end. If the users connect their computer= s >> =A0 =A0directly to the MCU, then the capture will come to the room just >> =A0 =A0like anything else from the MCU. >> >> [sb]The standard model for videoconferencing presentations is a >> token-controlled transmission. =A0If you don't have the token, you are >> receiving. The local equipment is always responsible for display. >> Looping the presentation back through the MCU back to the originating >> site wastes bandwidth. >> >> I don't know if web conferencing solutions do this differently or not. >> I've always assumed that when I grab the webex "ball" I stop receiving >> desktop images. =A0Certainly there is no reason for the server to send >> them back to me.[/sb] > > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Apr 30 11:19:51 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B1221F88BF for ; Mon, 30 Apr 2012 11:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP2WswQdLPek for ; Mon, 30 Apr 2012 11:19:50 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id A380221F88B8 for ; Mon, 30 Apr 2012 11:19:50 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta09.westchester.pa.mail.comcast.net with comcast id 4BLi1j00227AodY59JKqW1; Mon, 30 Apr 2012 18:19:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id 4JKq1j00Y07duvL3fJKq6H; Mon, 30 Apr 2012 18:19:50 +0000 Message-ID: <4F9ED7C5.70709@alum.mit.edu> Date: Mon, 30 Apr 2012 14:19:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Marshall Eubanks References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 18:19:51 -0000 Thanks Marshall - this is a good use case. I'm inserting questions inline. On 4/30/12 1:49 PM, Marshall Eubanks wrote: > Here is a potential use case : > > There is a telepresence session and an associated webex-like computer > sharing session. > > At some time, person X has the floor on the computer sharing session > (i.e., they are the presenter). > > I want to see person X on screen. (Or, maybe, I am the chair, and I > want every telepresence participant to see > person X on their screen.) I want to see X even if he or she is not > talking for a bit, so just doing voice switching is not enough. Are you talking about the *computer* screen? Or one of the screens in the TP room? And are you just talking about displaying the presenter, or the presentation as well? I think its reasonable to expect that some but not all of the participants in the room(s) will have a computer connected into the webex-like session. Those that don't will still want to see the presentation. I can see how the people with computers could use those as supplemental displays, so that they could see more captures than are available in the room as a whole. Presumably they wouldn't bother to locally display a capture that is already being displayed on a room screen. Thanks, Paul > After a while, person Y starts displaying viewgraphs from their > computer (i.e., they are now the presenter). > > I want the presenter screen to switch to showing person Y. > > Right now, all of this would be manual and very cumbersome to do, and > yet I think it is an option people would want. > > Is publishing an XML scheme for describing this enough ? Could the > telepresence system join the computer sharing session? > Or can the computer sharing session join the telepresence as a > participant, albeit a non-media producing or consuming participant? I think either of these is *possible*, without any explicit support for it. But the coordination to do so could be cumbersome. We need to figure out if there is some mechanism we need to specify to make this convenient. Thanks, Paul > Regards > Marshall > > On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat wrote: >> On 4/28/12 1:18 PM, Stephen Botzko wrote: >> >>> [sb] As I mentioned above, the existing solutions usually include a >>> screen-scrape application, so you don't have to use a video cable. This >>> is essentially the same as using Webex for presenting (but not remote >>> control). >> >> >> How are these solutions connected? Does the captured application data go to >> the local room controller, or to an MCU in the middle of the TP session? Or >> something else? >> >> >>> Also, even though Webex allows remote control, in my >>> experience that feature is not used as much as simple presenting. I am >>> not saying it has no value, just that the most common case I see is a >>> simple presentation. >> >> >> That is my experience as well. I wasn't thinking about the >> multi-user-control aspect. >> >> >>> Supporting the video cable still has value, especially if you have guest >>> presenter who does not have access to your local network. Most of those >>> presenters are expecting to use a projector, so they have the cables >>> with them. >> >> >> Surely. In this case, I presume the cable connects to the local room >> controller. If there are multiple cable connectors (e.g. one at each seat) >> do they show up as multiple presentation streams? Or is there some sort of >> switch and floor control? If so, how does one manage the floor control? >> >> >>> My answer on application sharing falling "out of favor" related >>> specifically to vendor support for standards-based application sharing >>> (T.120 in particular) - which I thought was responsive to your original >>> question. Perhaps I misunderstood it. Anyway there were several >>> reasons [and perhaps various viewpoints] on why T.120 was dropped, >>> though I think it is probably not a useful discussion for this list. I >>> know of no other standards-based protocol for application sharing. >> >> >> I wasn't assuming there was, other than a pure video (and maybe audio) >> stream interface. There are other fora for that sort of thing, but its my >> impression that this is largely a world of proprietary and defacto >> standards. >> >> >>> BTW, it is relatively common for web screen sharing to co-exist with the >>> videoconferencing presentation methods. For instance, you can have a >>> stand-alone webex conference, with someone sharing their laptop screen >>> for the video participants.[/sb] >> >> >> I have done this. But it was cumbersome. IIRC, getting the sharing to be >> visible in the room I was in required using a video cable in addition to >> using webex sharing. >> >> >>> Of course that is still somewhat cumbersome, but presumably it will >>> be improved over time. Its the UI for driving it that is cumbersome, >>> not the output. >>> >>> A key difference is that if the computer output is via video cable >>> into the local room controller, then that is probably responsible >>> for displaying it locally on a display in the room as well as >>> sending it to the remote end. If the users connect their computers >>> directly to the MCU, then the capture will come to the room just >>> like anything else from the MCU. >>> >>> [sb]The standard model for videoconferencing presentations is a >>> token-controlled transmission. If you don't have the token, you are >>> receiving. The local equipment is always responsible for display. >>> Looping the presentation back through the MCU back to the originating >>> site wastes bandwidth. >>> >>> I don't know if web conferencing solutions do this differently or not. >>> I've always assumed that when I grab the webex "ball" I stop receiving >>> desktop images. Certainly there is no reason for the server to send >>> them back to me.[/sb] >> >> >> Thanks, >> Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From Even.roni@huawei.com Mon Apr 30 12:11:38 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EB621F88A2 for ; Mon, 30 Apr 2012 12:11:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXCRTi32yRvu for ; Mon, 30 Apr 2012 12:11:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 91E6521F889B for ; Mon, 30 Apr 2012 12:11:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFK32828; Mon, 30 Apr 2012 15:11:33 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Apr 2012 12:09:49 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Apr 2012 12:09:47 -0700 Received: from SZXEML536-MBX.china.huawei.com ([10.82.67.115]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 1 May 2012 03:09:39 +0800 From: Roni even To: Paul Kyzivat , Roni Even Thread-Topic: [clue] ways of managing presentations in telepresence sessions Thread-Index: AQHNI84a7nkR+jw5XUCzK/waIPY5UJas6IQAgAHAxoCAAAL1AIAAsVSAgAOtmQCAALVVXg== Date: Mon, 30 Apr 2012 19:09:38 +0000 Message-ID: References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4f9ba527.6265b40a.7cae.0d9d@mx.google.com>, <4F9EBA9C.8040208@alum.mit.edu> In-Reply-To: <4F9EBA9C.8040208@alum.mit.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'CLUE' Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:11:38 -0000 Paul, I think that the video conference based on SIP and the application sharing = are two separate application with vendor specific API between the two entit= ies. If you can describe the application sharing in SIP / SDP there may be = a CLUE integration. in all other cases this is not up to CLUE and I do not = think that there is a such standard integration even for a non CLUE SIP end= point and application sharing BTW" from the CLUE charter "This working group is not currently chartered t= o work on issues of continuous conference control including: far end camera control, floor control, conference roster." I think we have currently enough work in CLUE without this topic Roni ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Monday, April 30, 2012 19:15 To: Roni Even Cc: 'CLUE' Subject: Re: [clue] ways of managing presentations in telepresence sessions My thought was not about the application sharing mechanism details. What I was thinking is that the shared application would in some way be mapped to a presentation capture. The point that seems to matter the most is how this appears in the telepresence session topology. The share might show up as a capture from the room where the person doing the sharing resides. This implies that there is a connection between the computer doing the sharing to the controller for the room. And then the room controller will be deciding how to advertise it. E.g. it could display it on a screen in its own room and advertise it in the room scene with the position of that screen. Or the room controller could advertise the share as a presentation capture in a separate scene. Or the share might show up as a capture from a separate endpoint corresponding to the computer doing the sharing. Because this means there are at least three endpoints involved, it will require an MCU. And then the MCU will need to figure out what to advertise in order to make that capture available to all the rooms. ISTM that either of these approaches could be made to work. But if the computer doing the sharing is connecting over the web then it seems much more natural to me that it would be to a common point for the session, rather than to the room controller. I don't know how much of this it makes sense to address as part of CLUE, but I don't think we can ignore it entirely. Thanks, Paul On 4/28/12 4:05 AM, Roni Even wrote: > Hi, > Steve in his response mentioned that the there is a data collaboration > standard which is T.120 that was used in the past but is not used today. = The > presentation stream is not for collaboration but just presentation and wo= rks > well in TP rooms equipped with monitors for the presentation stream. > > As for application sharing like WebEx or Meetecho all these solution are > stimulus based and there is no standard for these solutions. Most of the > video conferencing providers have such solution with some integration to = the > video conference. > I do not think that Clue should work on this integration since there is n= o > standard application sharing to integrate with. > There was a proposal to work on application sharing in MMUSIC and AVT cou= ple > of years ago (I think Jonathan had a draft with Henning) based on RTP lev= el. > There was also a later draft > http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 but n= one > of this progressed. > > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Marshall Eubanks >> Sent: Saturday, April 28, 2012 12:31 AM >> To: Paul Kyzivat >> Cc: CLUE >> Subject: Re: [clue] ways of managing presentations in telepresence >> sessions >> >> On Fri, Apr 27, 2012 at 5:20 PM, Paul Kyzivat >> wrote: >>> On 4/26/12 2:33 PM, Stephen Botzko wrote: >>>> >>>> Most traditional videoconferencing systems support H.239 (with >>>> H.323), using a functionally equivalent method in SIP. The >>>> presentation video is assigned a role (e.g., slides), and the >> ability >>>> to send is token-controlled with BFCP. All endpoints in the >>>> conference receive the presentation. If there is a legacy device >>>> (which doesn't support >>>> presentations) on the far end, the sender usually chooses to send >> the >>>> presentation instead of the participant video. >>>> >>>> Computers can be connected using HDMI/Displayport/DVI/VGA directly >> to >>>> the video conferencing endpoint. Alternatively, there may be a PC >>>> application that screen-scrapes the display and sends it to the >>>> endpoint for distribution. These same options are used in >> telepresence systems. >>>> >>>> On the receiving side, there are several options. Sometimes the >>>> content is displayed on a separate monitor or projector. Sometimes >>>> the content is composed along with participants, and placed on a >>>> single display. In telepresence systems, there are frequently >>>> content monitors at each seat, all of which will display the >> presentation. >>>> >>>> Application sharing was common back in the 90's (using the T.120 >>>> protocol), but fell out of favor for a variety of reasons. >>> >>> >>> What is it that webex uses for application sharing? AFAIK that is not >>> falling out of favor. I would much rather use webex application >>> sharing than be forced to plug a video connector into my computer. >>> >>> Of course that is still somewhat cumbersome, but presumably it will >> be >>> improved over time. Its the UI for driving it that is cumbersome, not >>> the output. >>> >> >> Since this is true, and since it is very hard to change such behavior, >> this raises the question : >> >> Is there a CLUE role for metadata exchange with applications such as >> Webex? Or, are we going to be condemned to running separate >> asynchronous conferences for data and telepresence ? >> >> I am not sure of the answer, but I did want to raise the question. >> >> Regards >> Marshall >> >> >>> A key difference is that if the computer output is via video cable >>> into the local room controller, then that is probably responsible for >>> displaying it locally on a display in the room as well as sending it >>> to the remote end. If the users connect their computers directly to >>> the MCU, then the capture will come to the room just like anything >> else from the MCU. >>> >>> Thanks, >>> Paul >>> >>>> Stephen Botzko >>>> >>>> >>>> >>>> On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat >> >>> > wrote: >>>> >>>> I am working on my use cases for the question about how to select >>>> which captures to display. But I have a gap in my understanding, >>>> and >>>> would like to get input from those of you with more experience in >>>> a >>>> diversity of telepresence systems. >>>> >>>> My only live experience with telepresence systems is with the >>>> Cisco >>>> ones. I'm not aware of it having any explicit support for >>>> presentations, though that might just be my lack of >> understanding. >>>> >>>> So I'd like to hear what *is* supported, or is *intended* to be >>>> supported. >>>> >>>> I presume that for the most part presentations these days >>>> originate >>>> in a computer and are fed into the telepresence system, much like >>>> they are in webex - either by preloading documents to the >>>> conference >>>> controller and then interacting with it from a computer to have >>>> them >>>> displayed, or by "sharing an application" dynamically from a >>>> computer. I understand that in a system like webex, which is not >> a >>>> telepresence system. But what does that mean when married to a >>>> telepresence system? >>>> >>>> Some ways I can imagine this working: >>>> >>>> - visitors to a telepresence room bring their own computers. >>>> Each seat has a video connector that the visitor can connect to >>>> and originate a presentation stream. When active, these become >>>> additional captures from the room. But for others in the same >>>> room to see, these would then have to be treated as incoming >>>> captures (from where) and displayed on some display in the >> room. >>>> >>>> - visitors to a telepresence room bring their own computers. >>>> Each such computer connects to an MCU as if it were an >>>> independent >>>> endpoint/room. The computer then offers up whatever it wants to >>>> share as a capture. The room itself also connects to the MCU, >>>> with its cameras as captures. The MCU sorts this all out, >>>> handles >>>> floor control, and decides what to advertise. So it can include >>>> presentations from user's computers as well as captures from >> the >>>> rooms. The local room can then display one or more >> presentations >>>> on its diplays. Or, the user's computer could also serve as a >>>> display for presentations so that the room's displays could be >>>> reserved for showing participants in other rooms. >>>> >>>> - the telepresence room could have a personal display and >>>> controller >>>> at each seat. This could provide the user with a controller to >>>> request the floor, to review preloaded documents and request >>>> their >>>> display, etc. (Its a bit like the first one above.) >>>> >>>> There seems to be a big difference if the presentation is seen as >>>> coming from a room that has the typical telepresence layout, or >> if >>>> it is seen coming from a separate endpoint coupled to the >> computer >>>> generating it, and whether the presentation is displayed on >>>> equipment that is part of the room, or by a separate endpoint. >>>> >>>> I'd like feedback if any of the above makes sense, and whether >>>> there >>>> are other ways of looking at this I haven't imagined. >>>> >>>> Thanks, >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From marshall.eubanks@gmail.com Mon Apr 30 12:21:50 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E533121E8020 for ; Mon, 30 Apr 2012 12:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.629 X-Spam-Level: X-Spam-Status: No, score=-103.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTmNErxNRB48 for ; Mon, 30 Apr 2012 12:21:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB2321E8024 for ; Mon, 30 Apr 2012 12:21:49 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so2323328lbb.31 for ; Mon, 30 Apr 2012 12:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lmtUrmpqXNiwc35l5fulSpy5gmQzdymOyCUwzlYExFI=; b=Dsx++59ecuzwvKFW+znIHOlam6KuWwYULaPWFJ5J1l3EIg5yT/o56Rm9c6Oux0DhLk UDTkH1Yzob8hIkj+Y7OnCR1VA6xcHTr43ZsHjRVCBP7A4Rrb7z9wlClQB6vOMbIXftM0 XjKH33/OTcaYjFiPljBX0z6AZ9hIQMCydLG3jjTfeOpUIexB1c2dBps3Vsvz5v+iP6eO Bv5c35G0b9OMCbrqL8ldsEphoD/Bj5J+KCXARAv8BJyr0qKxYW7gTmr+ANu3THfYXqBN kIMQG6xu1FgjHLFQ2ZsKzbev5vNNIwiFIDGB+t3aRu0rpGX7DDPvwEVM1TrAbhz+61vh x7hg== MIME-Version: 1.0 Received: by 10.112.104.99 with SMTP id gd3mr8431429lbb.70.1335813708374; Mon, 30 Apr 2012 12:21:48 -0700 (PDT) Received: by 10.112.56.13 with HTTP; Mon, 30 Apr 2012 12:21:48 -0700 (PDT) In-Reply-To: <4F9ED7C5.70709@alum.mit.edu> References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <4F9ED7C5.70709@alum.mit.edu> Date: Mon, 30 Apr 2012 15:21:48 -0400 Message-ID: From: Marshall Eubanks To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:21:51 -0000 Dear Paul; On Mon, Apr 30, 2012 at 2:19 PM, Paul Kyzivat wrote= : > Thanks Marshall - this is a good use case. I'm inserting questions inline= . > > > On 4/30/12 1:49 PM, Marshall Eubanks wrote: >> >> Here is a potential use case : >> >> There is a telepresence session and an associated webex-like computer >> sharing session. >> >> At some time, person X has the floor on the computer sharing session >> (i.e., they are the presenter). >> >> I want to see person X on screen. (Or, maybe, I am the chair, and I >> want every telepresence participant to see >> person X on their screen.) I want to see X even if he or she is not >> talking =A0for a bit, so just doing voice switching is not enough. > > > Are you talking about the *computer* screen? Or one of the screens in the= TP > room? And are you just talking about displaying the presenter, or the > presentation as well? No, I was talking about - video screens display people - computer screens display someone's desktop (or application or...) So, this is really about unified floor control. When I give someone the floor, I want to see their face on the screen, and their presentation on my laptop. And, I want to do this once, not have to fuss with two autonomous systems. I don't care if I do it through the presentation system or through the telepresence system*, but the implication to me is that one has to be the driver, the other driven, and they have to talk to each o= ther. * My mental image was doing this through the telepresence system but thinking about it doing it through the presentation system may have some advantages, for example in authentication. > > I think its reasonable to expect that some but not all of the participant= s > in the room(s) will have a computer connected into the webex-like session= . Maybe. In lots of IETF meetings (to give one example) being in the webex session is close to being essential. > Those that don't will still want to see the presentation. That's a different but related use case, as is the use case where I am at the train station, have audio and webex, but no telepresence. "It would be nice" to have the webex display something of the telepresence session, assuming I have the bandwidth. > > I can see how the people with computers could use those as supplemental > displays, so that they could see more captures than are available in the > room as a whole. Presumably they wouldn't bother to locally display a > capture that is already being displayed on a room screen. This is interesting but not the use case I had in mind. Regards Marshall > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > >> After a while, person Y starts displaying viewgraphs from their >> computer (i.e., they are now the presenter). >> >> I want the presenter screen to switch to showing person Y. >> >> Right now, all of this would be manual and very cumbersome to do, and >> yet I think it is an option people would want. >> >> Is publishing an XML scheme for describing this enough ? Could the >> telepresence system join the computer sharing session? >> Or can the computer sharing session join the telepresence as a >> participant, albeit a non-media producing or consuming participant? > > > I think either of these is *possible*, without any explicit support for i= t. > But the coordination to do so could be cumbersome. We need to figure out = if > there is some mechanism we need to specify to make this convenient. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > >> Regards >> Marshall >> >> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat >> =A0wrote: >>> >>> On 4/28/12 1:18 PM, Stephen Botzko wrote: >>> >>>> [sb] As I mentioned above, the existing solutions usually include a >>>> screen-scrape application, so you don't have to use a video cable. Thi= s >>>> is essentially the same as using Webex for presenting (but not remote >>>> control). >>> >>> >>> >>> How are these solutions connected? Does the captured application data g= o >>> to >>> the local room controller, or to an MCU in the middle of the TP session= ? >>> Or >>> something else? >>> >>> >>>> Also, even though Webex allows remote control, in my >>>> experience that feature is not used as much as simple presenting. =A0I= am >>>> not saying it has no value, just that the most common case I see is a >>>> simple presentation. >>> >>> >>> >>> That is my experience as well. I wasn't thinking about the >>> multi-user-control aspect. >>> >>> >>>> Supporting the video cable still has value, especially if you have gue= st >>>> presenter who does not have access to your local network. =A0Most of t= hose >>>> presenters are expecting to use a projector, so they have the cables >>>> with them. >>> >>> >>> >>> Surely. In this case, I presume the cable connects to the local room >>> controller. If there are multiple cable connectors (e.g. one at each >>> seat) >>> do they show up as multiple presentation streams? Or is there some sort >>> of >>> switch and floor control? If so, how does one manage the floor control? >>> >>> >>>> My answer on application sharing falling "out of favor" related >>>> specifically to vendor support for standards-based application sharing >>>> (T.120 in particular) - which I thought was responsive to your origina= l >>>> question. =A0Perhaps I misunderstood it. =A0Anyway there were several >>>> reasons [and perhaps various viewpoints] on why T.120 was dropped, >>>> though I think it is probably not a useful discussion for this list. = =A0I >>>> know of no other standards-based protocol for application sharing. >>> >>> >>> >>> I wasn't assuming there was, other than a pure video (and maybe audio) >>> stream interface. There are other fora for that sort of thing, but its = my >>> impression that this is largely a world of proprietary and defacto >>> standards. >>> >>> >>>> BTW, it is relatively common for web screen sharing to co-exist with t= he >>>> videoconferencing presentation methods. =A0For instance, you can have = a >>>> stand-alone webex conference, with someone sharing their laptop screen >>>> for the video participants.[/sb] >>> >>> >>> >>> I have done this. But it was cumbersome. IIRC, getting the sharing to b= e >>> visible in the room I was in required using a video cable in addition t= o >>> using webex sharing. >>> >>> >>>> =A0 =A0Of course that is still somewhat cumbersome, but presumably it = will >>>> =A0 =A0be improved over time. Its the UI for driving it that is cumber= some, >>>> =A0 =A0not the output. >>>> >>>> =A0 =A0A key difference is that if the computer output is via video ca= ble >>>> =A0 =A0into the local room controller, then that is probably responsib= le >>>> =A0 =A0for displaying it locally on a display in the room as well as >>>> =A0 =A0sending it to the remote end. If the users connect their comput= ers >>>> =A0 =A0directly to the MCU, then the capture will come to the room jus= t >>>> =A0 =A0like anything else from the MCU. >>>> >>>> [sb]The standard model for videoconferencing presentations is a >>>> token-controlled transmission. =A0If you don't have the token, you are >>>> receiving. The local equipment is always responsible for display. >>>> Looping the presentation back through the MCU back to the originating >>>> site wastes bandwidth. >>>> >>>> I don't know if web conferencing solutions do this differently or not. >>>> I've always assumed that when I grab the webex "ball" I stop receiving >>>> desktop images. =A0Certainly there is no reason for the server to send >>>> them back to me.[/sb] >>> >>> >>> >>> =A0 =A0 =A0 =A0Thanks, >>> =A0 =A0 =A0 =A0Paul >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> > From john@jlc.net Mon Apr 30 13:14:20 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0F21E8051 for ; Mon, 30 Apr 2012 13:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-3A25E8Qt3B for ; Mon, 30 Apr 2012 13:14:19 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D1CA521E804E for ; Mon, 30 Apr 2012 13:14:19 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id E59E933C22; Mon, 30 Apr 2012 16:14:19 -0400 (EDT) Date: Mon, 30 Apr 2012 16:14:19 -0400 From: John Leslie To: Marshall Eubanks Message-ID: <20120430201419.GN99904@verdi> References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <4F9ED7C5.70709@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 20:14:20 -0000 Marshall Eubanks wrote: > > - video screens display people > - computer screens display someone's desktop (or application or...) > > So, this is really about unified floor control. When I give someone > the floor, I want to see their face on the screen, and their > presentation on my laptop. And, I want to do this once, not have to > fuss with two autonomous systems. Whether or not this is in CLUE scope, I endorse Marshall's desire. I don't believe the presenation screen should be easily confused with a telepresence screen; and there are real use-cases where "the" laptop screen is the right place for it. -- John Leslie From br@brianrosen.net Mon Apr 30 13:15:55 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0299621E8090 for ; Mon, 30 Apr 2012 13:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYGC9p9qHAcZ for ; Mon, 30 Apr 2012 13:15:54 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id E4EF921E8051 for ; Mon, 30 Apr 2012 13:15:53 -0700 (PDT) X-ASG-Debug-ID: 1335816952-04d0350ea20b2c0001-dOUo1C Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id bTpkGAILWyplp6wE; Mon, 30 Apr 2012 13:15:52 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[156.154.4.12]) by wwh1.winweblinux.com with esmtpa (Exim 4.69) (envelope-from ) id 1SOx0i-0020Dz-Sj; Mon, 30 Apr 2012 13:15:53 -0700 Mime-Version: 1.0 (Apple Message framework v1257) X-ASG-Orig-Subj: Re: [clue] ways of managing presentations in telepresence sessions Content-Type: text/plain; charset=iso-8859-1 From: Brian Rosen In-Reply-To: Date: Mon, 30 Apr 2012 16:15:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4281238F-4A41-4B6D-9B89-CDBD61923330@brianrosen.net> References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <4F9ED7C5.70709@alum.mit.edu> To: Marshall Eubanks X-Mailer: Apple Mail (2.1257) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1335816952 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.95622 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 20:15:55 -0000 I agree with this - you bring your laptop to the room, or there is a = desktop in the room for you, and you connect that to the presentation = sharing system. The audio/video is connected to a different system. = The challenge is to interwork these so change in presenter affects both. Brian On Apr 30, 2012, at 3:21 PM, Marshall Eubanks wrote: > Dear Paul; >=20 >=20 >=20 > On Mon, Apr 30, 2012 at 2:19 PM, Paul Kyzivat = wrote: >> Thanks Marshall - this is a good use case. I'm inserting questions = inline. >>=20 >>=20 >> On 4/30/12 1:49 PM, Marshall Eubanks wrote: >>>=20 >>> Here is a potential use case : >>>=20 >>> There is a telepresence session and an associated webex-like = computer >>> sharing session. >>>=20 >>> At some time, person X has the floor on the computer sharing session >>> (i.e., they are the presenter). >>>=20 >>> I want to see person X on screen. (Or, maybe, I am the chair, and I >>> want every telepresence participant to see >>> person X on their screen.) I want to see X even if he or she is not >>> talking for a bit, so just doing voice switching is not enough. >>=20 >>=20 >> Are you talking about the *computer* screen? Or one of the screens in = the TP >> room? And are you just talking about displaying the presenter, or the >> presentation as well? >=20 > No, I was talking about >=20 > - video screens display people > - computer screens display someone's desktop (or application or...) >=20 > So, this is really about unified floor control. When I give someone > the floor, I want to > see their face on the screen, and their presentation on my laptop. > And, I want to > do this once, not have to fuss with two autonomous systems. >=20 > I don't care if I do it through the presentation system or through the > telepresence system*, but the implication to me is that > one has to be the driver, the other driven, and they have to talk to = each other. >=20 > * My mental image was doing this through the telepresence system but > thinking about it doing it through the presentation system may have > some advantages, for example in authentication. >=20 >>=20 >> I think its reasonable to expect that some but not all of the = participants >> in the room(s) will have a computer connected into the webex-like = session. >=20 > Maybe. In lots of IETF meetings (to give one example) being in the > webex session is close to being essential. >=20 >> Those that don't will still want to see the presentation. >=20 > That's a different but related use case, as is the use case where I am > at the train station, have audio and webex, but > no telepresence. "It would be nice" to have the webex display > something of the telepresence session, assuming I have the bandwidth. >=20 >>=20 >> I can see how the people with computers could use those as = supplemental >> displays, so that they could see more captures than are available in = the >> room as a whole. Presumably they wouldn't bother to locally display a >> capture that is already being displayed on a room screen. >=20 > This is interesting but not the use case I had in mind. >=20 > Regards > Marshall >=20 >>=20 >> Thanks, >> Paul >>=20 >>=20 >>> After a while, person Y starts displaying viewgraphs from their >>> computer (i.e., they are now the presenter). >>>=20 >>> I want the presenter screen to switch to showing person Y. >>>=20 >>> Right now, all of this would be manual and very cumbersome to do, = and >>> yet I think it is an option people would want. >>>=20 >>> Is publishing an XML scheme for describing this enough ? Could the >>> telepresence system join the computer sharing session? >>> Or can the computer sharing session join the telepresence as a >>> participant, albeit a non-media producing or consuming participant? >>=20 >>=20 >> I think either of these is *possible*, without any explicit support = for it. >> But the coordination to do so could be cumbersome. We need to figure = out if >> there is some mechanism we need to specify to make this convenient. >>=20 >> Thanks, >> Paul >>=20 >>=20 >>> Regards >>> Marshall >>>=20 >>> On Mon, Apr 30, 2012 at 12:56 PM, Paul = Kyzivat >>> wrote: >>>>=20 >>>> On 4/28/12 1:18 PM, Stephen Botzko wrote: >>>>=20 >>>>> [sb] As I mentioned above, the existing solutions usually include = a >>>>> screen-scrape application, so you don't have to use a video cable. = This >>>>> is essentially the same as using Webex for presenting (but not = remote >>>>> control). >>>>=20 >>>>=20 >>>>=20 >>>> How are these solutions connected? Does the captured application = data go >>>> to >>>> the local room controller, or to an MCU in the middle of the TP = session? >>>> Or >>>> something else? >>>>=20 >>>>=20 >>>>> Also, even though Webex allows remote control, in my >>>>> experience that feature is not used as much as simple presenting. = I am >>>>> not saying it has no value, just that the most common case I see = is a >>>>> simple presentation. >>>>=20 >>>>=20 >>>>=20 >>>> That is my experience as well. I wasn't thinking about the >>>> multi-user-control aspect. >>>>=20 >>>>=20 >>>>> Supporting the video cable still has value, especially if you have = guest >>>>> presenter who does not have access to your local network. Most of = those >>>>> presenters are expecting to use a projector, so they have the = cables >>>>> with them. >>>>=20 >>>>=20 >>>>=20 >>>> Surely. In this case, I presume the cable connects to the local = room >>>> controller. If there are multiple cable connectors (e.g. one at = each >>>> seat) >>>> do they show up as multiple presentation streams? Or is there some = sort >>>> of >>>> switch and floor control? If so, how does one manage the floor = control? >>>>=20 >>>>=20 >>>>> My answer on application sharing falling "out of favor" related >>>>> specifically to vendor support for standards-based application = sharing >>>>> (T.120 in particular) - which I thought was responsive to your = original >>>>> question. Perhaps I misunderstood it. Anyway there were several >>>>> reasons [and perhaps various viewpoints] on why T.120 was dropped, >>>>> though I think it is probably not a useful discussion for this = list. I >>>>> know of no other standards-based protocol for application sharing. >>>>=20 >>>>=20 >>>>=20 >>>> I wasn't assuming there was, other than a pure video (and maybe = audio) >>>> stream interface. There are other fora for that sort of thing, but = its my >>>> impression that this is largely a world of proprietary and defacto >>>> standards. >>>>=20 >>>>=20 >>>>> BTW, it is relatively common for web screen sharing to co-exist = with the >>>>> videoconferencing presentation methods. For instance, you can = have a >>>>> stand-alone webex conference, with someone sharing their laptop = screen >>>>> for the video participants.[/sb] >>>>=20 >>>>=20 >>>>=20 >>>> I have done this. But it was cumbersome. IIRC, getting the sharing = to be >>>> visible in the room I was in required using a video cable in = addition to >>>> using webex sharing. >>>>=20 >>>>=20 >>>>> Of course that is still somewhat cumbersome, but presumably it = will >>>>> be improved over time. Its the UI for driving it that is = cumbersome, >>>>> not the output. >>>>>=20 >>>>> A key difference is that if the computer output is via video = cable >>>>> into the local room controller, then that is probably = responsible >>>>> for displaying it locally on a display in the room as well as >>>>> sending it to the remote end. If the users connect their = computers >>>>> directly to the MCU, then the capture will come to the room = just >>>>> like anything else from the MCU. >>>>>=20 >>>>> [sb]The standard model for videoconferencing presentations is a >>>>> token-controlled transmission. If you don't have the token, you = are >>>>> receiving. The local equipment is always responsible for display. >>>>> Looping the presentation back through the MCU back to the = originating >>>>> site wastes bandwidth. >>>>>=20 >>>>> I don't know if web conferencing solutions do this differently or = not. >>>>> I've always assumed that when I grab the webex "ball" I stop = receiving >>>>> desktop images. Certainly there is no reason for the server to = send >>>>> them back to me.[/sb] >>>>=20 >>>>=20 >>>>=20 >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>=20 >>>=20 >>=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Apr 30 15:01:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C927221E80CB for ; Mon, 30 Apr 2012 15:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqvS0W2NJdN9 for ; Mon, 30 Apr 2012 15:01:21 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9762F21E80A8 for ; Mon, 30 Apr 2012 15:01:21 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id 4D7g1j00327AodY55N1MVy; Mon, 30 Apr 2012 22:01:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id 4N1K1j00N07duvL3fN1KFY; Mon, 30 Apr 2012 22:01:21 +0000 Message-ID: <4F9F0BAE.7000500@alum.mit.edu> Date: Mon, 30 Apr 2012 18:01:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Brian Rosen References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <4F9ED7C5.70709@alum.mit.edu> <4281238F-4A41-4B6D-9B89-CDBD61923330@brianrosen.net> In-Reply-To: <4281238F-4A41-4B6D-9B89-CDBD61923330@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 22:01:22 -0000 On 4/30/12 4:15 PM, Brian Rosen wrote: > I agree with this - you bring your laptop to the room, or there is a desktop in the room for you, and you connect that to the presentation sharing system. The audio/video is connected to a different system. The challenge is to interwork these so change in presenter affects both. I agree with this. But I also think there needs to be a parity for presentations regardless of how they are brought in. There should be the same options for viewing a presentation regardless of whether it is captured from a video jack or over the web via application sharing. Either way there should be the option to show it on one of the screens in the various rooms. Of course it should also be possible for those participants who are connected to the sharing application to view this on their computers. And if everybody in a room is viewing the presentation from their own computer then the room system need not display it. This all points to some needs: - the sharing application to provide the shared info, as a presentation. This suggests that it be connected as a CLUE endpoint. - Some mechanism to identify to the CLUE system who is sourcing a presentation stream - which I guess means correlating a presentation stream to one or more other captures that contain the presenters. This could be hard if the endpoint sending the presentation stream is not the system sending the captures of the presenters. Thanks, Paul > Brian > > On Apr 30, 2012, at 3:21 PM, Marshall Eubanks wrote: > >> Dear Paul; >> >> >> >> On Mon, Apr 30, 2012 at 2:19 PM, Paul Kyzivat wrote: >>> Thanks Marshall - this is a good use case. I'm inserting questions inline. >>> >>> >>> On 4/30/12 1:49 PM, Marshall Eubanks wrote: >>>> >>>> Here is a potential use case : >>>> >>>> There is a telepresence session and an associated webex-like computer >>>> sharing session. >>>> >>>> At some time, person X has the floor on the computer sharing session >>>> (i.e., they are the presenter). >>>> >>>> I want to see person X on screen. (Or, maybe, I am the chair, and I >>>> want every telepresence participant to see >>>> person X on their screen.) I want to see X even if he or she is not >>>> talking for a bit, so just doing voice switching is not enough. >>> >>> >>> Are you talking about the *computer* screen? Or one of the screens in the TP >>> room? And are you just talking about displaying the presenter, or the >>> presentation as well? >> >> No, I was talking about >> >> - video screens display people >> - computer screens display someone's desktop (or application or...) >> >> So, this is really about unified floor control. When I give someone >> the floor, I want to >> see their face on the screen, and their presentation on my laptop. >> And, I want to >> do this once, not have to fuss with two autonomous systems. >> >> I don't care if I do it through the presentation system or through the >> telepresence system*, but the implication to me is that >> one has to be the driver, the other driven, and they have to talk to each other. >> >> * My mental image was doing this through the telepresence system but >> thinking about it doing it through the presentation system may have >> some advantages, for example in authentication. >> >>> >>> I think its reasonable to expect that some but not all of the participants >>> in the room(s) will have a computer connected into the webex-like session. >> >> Maybe. In lots of IETF meetings (to give one example) being in the >> webex session is close to being essential. >> >>> Those that don't will still want to see the presentation. >> >> That's a different but related use case, as is the use case where I am >> at the train station, have audio and webex, but >> no telepresence. "It would be nice" to have the webex display >> something of the telepresence session, assuming I have the bandwidth. >> >>> >>> I can see how the people with computers could use those as supplemental >>> displays, so that they could see more captures than are available in the >>> room as a whole. Presumably they wouldn't bother to locally display a >>> capture that is already being displayed on a room screen. >> >> This is interesting but not the use case I had in mind. >> >> Regards >> Marshall >> >>> >>> Thanks, >>> Paul >>> >>> >>>> After a while, person Y starts displaying viewgraphs from their >>>> computer (i.e., they are now the presenter). >>>> >>>> I want the presenter screen to switch to showing person Y. >>>> >>>> Right now, all of this would be manual and very cumbersome to do, and >>>> yet I think it is an option people would want. >>>> >>>> Is publishing an XML scheme for describing this enough ? Could the >>>> telepresence system join the computer sharing session? >>>> Or can the computer sharing session join the telepresence as a >>>> participant, albeit a non-media producing or consuming participant? >>> >>> >>> I think either of these is *possible*, without any explicit support for it. >>> But the coordination to do so could be cumbersome. We need to figure out if >>> there is some mechanism we need to specify to make this convenient. >>> >>> Thanks, >>> Paul >>> >>> >>>> Regards >>>> Marshall >>>> >>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul Kyzivat >>>> wrote: >>>>> >>>>> On 4/28/12 1:18 PM, Stephen Botzko wrote: >>>>> >>>>>> [sb] As I mentioned above, the existing solutions usually include a >>>>>> screen-scrape application, so you don't have to use a video cable. This >>>>>> is essentially the same as using Webex for presenting (but not remote >>>>>> control). >>>>> >>>>> >>>>> >>>>> How are these solutions connected? Does the captured application data go >>>>> to >>>>> the local room controller, or to an MCU in the middle of the TP session? >>>>> Or >>>>> something else? >>>>> >>>>> >>>>>> Also, even though Webex allows remote control, in my >>>>>> experience that feature is not used as much as simple presenting. I am >>>>>> not saying it has no value, just that the most common case I see is a >>>>>> simple presentation. >>>>> >>>>> >>>>> >>>>> That is my experience as well. I wasn't thinking about the >>>>> multi-user-control aspect. >>>>> >>>>> >>>>>> Supporting the video cable still has value, especially if you have guest >>>>>> presenter who does not have access to your local network. Most of those >>>>>> presenters are expecting to use a projector, so they have the cables >>>>>> with them. >>>>> >>>>> >>>>> >>>>> Surely. In this case, I presume the cable connects to the local room >>>>> controller. If there are multiple cable connectors (e.g. one at each >>>>> seat) >>>>> do they show up as multiple presentation streams? Or is there some sort >>>>> of >>>>> switch and floor control? If so, how does one manage the floor control? >>>>> >>>>> >>>>>> My answer on application sharing falling "out of favor" related >>>>>> specifically to vendor support for standards-based application sharing >>>>>> (T.120 in particular) - which I thought was responsive to your original >>>>>> question. Perhaps I misunderstood it. Anyway there were several >>>>>> reasons [and perhaps various viewpoints] on why T.120 was dropped, >>>>>> though I think it is probably not a useful discussion for this list. I >>>>>> know of no other standards-based protocol for application sharing. >>>>> >>>>> >>>>> >>>>> I wasn't assuming there was, other than a pure video (and maybe audio) >>>>> stream interface. There are other fora for that sort of thing, but its my >>>>> impression that this is largely a world of proprietary and defacto >>>>> standards. >>>>> >>>>> >>>>>> BTW, it is relatively common for web screen sharing to co-exist with the >>>>>> videoconferencing presentation methods. For instance, you can have a >>>>>> stand-alone webex conference, with someone sharing their laptop screen >>>>>> for the video participants.[/sb] >>>>> >>>>> >>>>> >>>>> I have done this. But it was cumbersome. IIRC, getting the sharing to be >>>>> visible in the room I was in required using a video cable in addition to >>>>> using webex sharing. >>>>> >>>>> >>>>>> Of course that is still somewhat cumbersome, but presumably it will >>>>>> be improved over time. Its the UI for driving it that is cumbersome, >>>>>> not the output. >>>>>> >>>>>> A key difference is that if the computer output is via video cable >>>>>> into the local room controller, then that is probably responsible >>>>>> for displaying it locally on a display in the room as well as >>>>>> sending it to the remote end. If the users connect their computers >>>>>> directly to the MCU, then the capture will come to the room just >>>>>> like anything else from the MCU. >>>>>> >>>>>> [sb]The standard model for videoconferencing presentations is a >>>>>> token-controlled transmission. If you don't have the token, you are >>>>>> receiving. The local equipment is always responsible for display. >>>>>> Looping the presentation back through the MCU back to the originating >>>>>> site wastes bandwidth. >>>>>> >>>>>> I don't know if web conferencing solutions do this differently or not. >>>>>> I've always assumed that when I grab the webex "ball" I stop receiving >>>>>> desktop images. Certainly there is no reason for the server to send >>>>>> them back to me.[/sb] >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From ron.even.tlv@gmail.com Mon Apr 30 15:09:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D950D21E80A8 for ; Mon, 30 Apr 2012 15:09:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y10ZcC4zhqp for ; Mon, 30 Apr 2012 15:09:34 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5872521E80A6 for ; Mon, 30 Apr 2012 15:09:34 -0700 (PDT) Received: by werb10 with SMTP id b10so2588988wer.31 for ; Mon, 30 Apr 2012 15:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=bnJnYjTTXSXxxTIF/a3Yyt+J46YYsvvj18LKSz7kQec=; b=ZbctvZcCDkDZapM50J4oOXGY6chFTr6StEIPFVAasKxiG4C1uWqrezX3ZcOuq1T8bS pUd5UhnlEUDyEfrhqwOe2lfeGWInpet6fNBdf2yFN1/3xWEF6mW+AHeGRn64nrDz0liD cCFvTwS0XVTecnaVI4h/YL8S9jMI6Vf276jwHs1uknAzMolWSess/oyutwBRwUTHsvLJ UTdEMTcFQ/EF/k5YzYyAD2NtJ7bLEeQ/2S2rScWsR/6H4LTkPAysVgbZXeMJ3PrW6ZGY htjayYKZIkGyAsoaVLEi906eq9B7u9jk34NpmESbu+rnUZCHmvGw6t/GGZRtXK0Nt+2R F9Rw== Received: by 10.180.94.161 with SMTP id dd1mr19764963wib.16.1335823773440; Mon, 30 Apr 2012 15:09:33 -0700 (PDT) Received: from windows8d787f9 ([109.67.230.123]) by mx.google.com with ESMTPS id k6sm31448644wiy.7.2012.04.30.15.09.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Apr 2012 15:09:32 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'Brian Rosen'" References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <4F9ED7C5.70709@alum.mit.edu> <4281238F-4A41-4B6D-9B89-CDBD61923330@brianrosen.net> <4F9F0BAE.7000500@alum.mit.edu> In-Reply-To: <4F9F0BAE.7000500@alum.mit.edu> Date: Tue, 1 May 2012 01:07:37 +0300 Message-ID: <4f9f0d9c.c652b40a.5efb.ffffb8c7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0nHMmwUZZWIZyeTlWNmcbRXTOtbwAAHQUA Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 22:09:36 -0000 Paul, My suggestion is to start with this integration for any video or audio SIP conference before going into CLUE. There is no such solution for this because there is no standard API between the application sharing and the SIP conference bridge. This topic can be discussed in DISPATCH I fail to see why we are discussing it here. This is defiantly not in the scope since these application sharing are not using RTP, SDP or SIP Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, May 01, 2012 1:01 AM > To: Brian Rosen > Cc: CLUE > Subject: Re: [clue] ways of managing presentations in telepresence > sessions > > On 4/30/12 4:15 PM, Brian Rosen wrote: > > I agree with this - you bring your laptop to the room, or there is a > desktop in the room for you, and you connect that to the presentation > sharing system. The audio/video is connected to a different system. > The challenge is to interwork these so change in presenter affects > both. > > I agree with this. > > But I also think there needs to be a parity for presentations > regardless of how they are brought in. There should be the same options > for viewing a presentation regardless of whether it is captured from a > video jack or over the web via application sharing. Either way there > should be the option to show it on one of the screens in the various > rooms. > > Of course it should also be possible for those participants who are > connected to the sharing application to view this on their computers. > And if everybody in a room is viewing the presentation from their own > computer then the room system need not display it. > > This all points to some needs: > > - the sharing application to provide the shared info, as a > presentation. > This suggests that it be connected as a CLUE endpoint. > > - Some mechanism to identify to the CLUE system who is sourcing a > presentation stream - which I guess means correlating a presentation > stream to one or more other captures that contain the presenters. > This could be hard if the endpoint sending the presentation stream > is not the system sending the captures of the presenters. > > Thanks, > Paul > > > Brian > > > > On Apr 30, 2012, at 3:21 PM, Marshall Eubanks wrote: > > > >> Dear Paul; > >> > >> > >> > >> On Mon, Apr 30, 2012 at 2:19 PM, Paul Kyzivat > wrote: > >>> Thanks Marshall - this is a good use case. I'm inserting questions > inline. > >>> > >>> > >>> On 4/30/12 1:49 PM, Marshall Eubanks wrote: > >>>> > >>>> Here is a potential use case : > >>>> > >>>> There is a telepresence session and an associated webex-like > >>>> computer sharing session. > >>>> > >>>> At some time, person X has the floor on the computer sharing > >>>> session (i.e., they are the presenter). > >>>> > >>>> I want to see person X on screen. (Or, maybe, I am the chair, and > I > >>>> want every telepresence participant to see person X on their > >>>> screen.) I want to see X even if he or she is not talking for a > >>>> bit, so just doing voice switching is not enough. > >>> > >>> > >>> Are you talking about the *computer* screen? Or one of the screens > >>> in the TP room? And are you just talking about displaying the > >>> presenter, or the presentation as well? > >> > >> No, I was talking about > >> > >> - video screens display people > >> - computer screens display someone's desktop (or application or...) > >> > >> So, this is really about unified floor control. When I give someone > >> the floor, I want to see their face on the screen, and their > >> presentation on my laptop. > >> And, I want to > >> do this once, not have to fuss with two autonomous systems. > >> > >> I don't care if I do it through the presentation system or through > >> the telepresence system*, but the implication to me is that one has > >> to be the driver, the other driven, and they have to talk to each > other. > >> > >> * My mental image was doing this through the telepresence system but > >> thinking about it doing it through the presentation system may have > >> some advantages, for example in authentication. > >> > >>> > >>> I think its reasonable to expect that some but not all of the > >>> participants in the room(s) will have a computer connected into the > webex-like session. > >> > >> Maybe. In lots of IETF meetings (to give one example) being in the > >> webex session is close to being essential. > >> > >>> Those that don't will still want to see the presentation. > >> > >> That's a different but related use case, as is the use case where I > >> am at the train station, have audio and webex, but no telepresence. > >> "It would be nice" to have the webex display something of the > >> telepresence session, assuming I have the bandwidth. > >> > >>> > >>> I can see how the people with computers could use those as > >>> supplemental displays, so that they could see more captures than > are > >>> available in the room as a whole. Presumably they wouldn't bother > to > >>> locally display a capture that is already being displayed on a room > screen. > >> > >> This is interesting but not the use case I had in mind. > >> > >> Regards > >> Marshall > >> > >>> > >>> Thanks, > >>> Paul > >>> > >>> > >>>> After a while, person Y starts displaying viewgraphs from their > >>>> computer (i.e., they are now the presenter). > >>>> > >>>> I want the presenter screen to switch to showing person Y. > >>>> > >>>> Right now, all of this would be manual and very cumbersome to do, > >>>> and yet I think it is an option people would want. > >>>> > >>>> Is publishing an XML scheme for describing this enough ? Could the > >>>> telepresence system join the computer sharing session? > >>>> Or can the computer sharing session join the telepresence as a > >>>> participant, albeit a non-media producing or consuming > participant? > >>> > >>> > >>> I think either of these is *possible*, without any explicit support > for it. > >>> But the coordination to do so could be cumbersome. We need to > figure > >>> out if there is some mechanism we need to specify to make this > convenient. > >>> > >>> Thanks, > >>> Paul > >>> > >>> > >>>> Regards > >>>> Marshall > >>>> > >>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul > Kyzivat > >>>> wrote: > >>>>> > >>>>> On 4/28/12 1:18 PM, Stephen Botzko wrote: > >>>>> > >>>>>> [sb] As I mentioned above, the existing solutions usually > include > >>>>>> a screen-scrape application, so you don't have to use a video > >>>>>> cable. This is essentially the same as using Webex for > presenting > >>>>>> (but not remote control). > >>>>> > >>>>> > >>>>> > >>>>> How are these solutions connected? Does the captured application > >>>>> data go to the local room controller, or to an MCU in the middle > >>>>> of the TP session? > >>>>> Or > >>>>> something else? > >>>>> > >>>>> > >>>>>> Also, even though Webex allows remote control, in my experience > >>>>>> that feature is not used as much as simple presenting. I am not > >>>>>> saying it has no value, just that the most common case I see is > a > >>>>>> simple presentation. > >>>>> > >>>>> > >>>>> > >>>>> That is my experience as well. I wasn't thinking about the > >>>>> multi-user-control aspect. > >>>>> > >>>>> > >>>>>> Supporting the video cable still has value, especially if you > >>>>>> have guest presenter who does not have access to your local > >>>>>> network. Most of those presenters are expecting to use a > >>>>>> projector, so they have the cables with them. > >>>>> > >>>>> > >>>>> > >>>>> Surely. In this case, I presume the cable connects to the local > >>>>> room controller. If there are multiple cable connectors (e.g. one > >>>>> at each > >>>>> seat) > >>>>> do they show up as multiple presentation streams? Or is there > some > >>>>> sort of switch and floor control? If so, how does one manage the > >>>>> floor control? > >>>>> > >>>>> > >>>>>> My answer on application sharing falling "out of favor" related > >>>>>> specifically to vendor support for standards-based application > >>>>>> sharing > >>>>>> (T.120 in particular) - which I thought was responsive to your > >>>>>> original question. Perhaps I misunderstood it. Anyway there > >>>>>> were several reasons [and perhaps various viewpoints] on why > >>>>>> T.120 was dropped, though I think it is probably not a useful > >>>>>> discussion for this list. I know of no other standards-based > protocol for application sharing. > >>>>> > >>>>> > >>>>> > >>>>> I wasn't assuming there was, other than a pure video (and maybe > >>>>> audio) stream interface. There are other fora for that sort of > >>>>> thing, but its my impression that this is largely a world of > >>>>> proprietary and defacto standards. > >>>>> > >>>>> > >>>>>> BTW, it is relatively common for web screen sharing to co-exist > >>>>>> with the videoconferencing presentation methods. For instance, > >>>>>> you can have a stand-alone webex conference, with someone > sharing > >>>>>> their laptop screen for the video participants.[/sb] > >>>>> > >>>>> > >>>>> > >>>>> I have done this. But it was cumbersome. IIRC, getting the > sharing > >>>>> to be visible in the room I was in required using a video cable > in > >>>>> addition to using webex sharing. > >>>>> > >>>>> > >>>>>> Of course that is still somewhat cumbersome, but presumably > it will > >>>>>> be improved over time. Its the UI for driving it that is > cumbersome, > >>>>>> not the output. > >>>>>> > >>>>>> A key difference is that if the computer output is via video > cable > >>>>>> into the local room controller, then that is probably > responsible > >>>>>> for displaying it locally on a display in the room as well > as > >>>>>> sending it to the remote end. If the users connect their > computers > >>>>>> directly to the MCU, then the capture will come to the room > just > >>>>>> like anything else from the MCU. > >>>>>> > >>>>>> [sb]The standard model for videoconferencing presentations is a > >>>>>> token-controlled transmission. If you don't have the token, you > >>>>>> are receiving. The local equipment is always responsible for > display. > >>>>>> Looping the presentation back through the MCU back to the > >>>>>> originating site wastes bandwidth. > >>>>>> > >>>>>> I don't know if web conferencing solutions do this differently > or not. > >>>>>> I've always assumed that when I grab the webex "ball" I stop > >>>>>> receiving desktop images. Certainly there is no reason for the > >>>>>> server to send them back to me.[/sb] > >>>>> > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >>>> > >>> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Apr 30 18:27:52 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD7E21E80AB for ; Mon, 30 Apr 2012 18:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSDaWM530XHn for ; Mon, 30 Apr 2012 18:27:51 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE9D21E8011 for ; Mon, 30 Apr 2012 18:27:51 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id 4JHU1j0031swQuc53RTqks; Tue, 01 May 2012 01:27:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id 4RTq1j01B07duvL3bRTrzJ; Tue, 01 May 2012 01:27:51 +0000 Message-ID: <4F9F3C14.60809@alum.mit.edu> Date: Mon, 30 Apr 2012 21:27:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roni Even References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <4F9ED7C5.70709@alum.mit.edu> <4281238F-4A41-4B6D-9B89-CDBD61923330@brianrosen.net> <4F9F0BAE.7000500@alum.mit.edu> <4f9f0d9c.c652b40a.5efb.ffffb8c7@mx.google.com> In-Reply-To: <4f9f0d9c.c652b40a.5efb.ffffb8c7@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'CLUE' Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 01:27:52 -0000 On 4/30/12 6:07 PM, Roni Even wrote: > Paul, > My suggestion is to start with this integration for any video or audio SIP > conference before going into CLUE. > There is no such solution for this because there is no standard API between > the application sharing and the SIP conference bridge. > This topic can be discussed in DISPATCH > I fail to see why we are discussing it here. This is defiantly not in the > scope since these application sharing are not using RTP, SDP or SIP > Roni Roni, I've been trying to walk a fine line here. I'm not proposing that we should discuss application sharing APIs, etc. But we do have presentation captures as part of CLUE, and I think we should not assume that they always come from sticking hard copy under a presentation camera or by plugging a computer into a video connector. It may be sufficient to acknowledge that computers used by participants to provide presentations might connect as independent CLUE endpoints. I'm trying to understand the rudiments of this to make a realistic use case involving presentations. Thanks, Paul >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Tuesday, May 01, 2012 1:01 AM >> To: Brian Rosen >> Cc: CLUE >> Subject: Re: [clue] ways of managing presentations in telepresence >> sessions >> >> On 4/30/12 4:15 PM, Brian Rosen wrote: >>> I agree with this - you bring your laptop to the room, or there is a >> desktop in the room for you, and you connect that to the presentation >> sharing system. The audio/video is connected to a different system. >> The challenge is to interwork these so change in presenter affects >> both. >> >> I agree with this. >> >> But I also think there needs to be a parity for presentations >> regardless of how they are brought in. There should be the same options >> for viewing a presentation regardless of whether it is captured from a >> video jack or over the web via application sharing. Either way there >> should be the option to show it on one of the screens in the various >> rooms. >> >> Of course it should also be possible for those participants who are >> connected to the sharing application to view this on their computers. >> And if everybody in a room is viewing the presentation from their own >> computer then the room system need not display it. >> >> This all points to some needs: >> >> - the sharing application to provide the shared info, as a >> presentation. >> This suggests that it be connected as a CLUE endpoint. >> >> - Some mechanism to identify to the CLUE system who is sourcing a >> presentation stream - which I guess means correlating a presentation >> stream to one or more other captures that contain the presenters. >> This could be hard if the endpoint sending the presentation stream >> is not the system sending the captures of the presenters. >> >> Thanks, >> Paul >> >>> Brian >>> >>> On Apr 30, 2012, at 3:21 PM, Marshall Eubanks wrote: >>> >>>> Dear Paul; >>>> >>>> >>>> >>>> On Mon, Apr 30, 2012 at 2:19 PM, Paul Kyzivat >> wrote: >>>>> Thanks Marshall - this is a good use case. I'm inserting questions >> inline. >>>>> >>>>> >>>>> On 4/30/12 1:49 PM, Marshall Eubanks wrote: >>>>>> >>>>>> Here is a potential use case : >>>>>> >>>>>> There is a telepresence session and an associated webex-like >>>>>> computer sharing session. >>>>>> >>>>>> At some time, person X has the floor on the computer sharing >>>>>> session (i.e., they are the presenter). >>>>>> >>>>>> I want to see person X on screen. (Or, maybe, I am the chair, and >> I >>>>>> want every telepresence participant to see person X on their >>>>>> screen.) I want to see X even if he or she is not talking for a >>>>>> bit, so just doing voice switching is not enough. >>>>> >>>>> >>>>> Are you talking about the *computer* screen? Or one of the screens >>>>> in the TP room? And are you just talking about displaying the >>>>> presenter, or the presentation as well? >>>> >>>> No, I was talking about >>>> >>>> - video screens display people >>>> - computer screens display someone's desktop (or application or...) >>>> >>>> So, this is really about unified floor control. When I give someone >>>> the floor, I want to see their face on the screen, and their >>>> presentation on my laptop. >>>> And, I want to >>>> do this once, not have to fuss with two autonomous systems. >>>> >>>> I don't care if I do it through the presentation system or through >>>> the telepresence system*, but the implication to me is that one has >>>> to be the driver, the other driven, and they have to talk to each >> other. >>>> >>>> * My mental image was doing this through the telepresence system but >>>> thinking about it doing it through the presentation system may have >>>> some advantages, for example in authentication. >>>> >>>>> >>>>> I think its reasonable to expect that some but not all of the >>>>> participants in the room(s) will have a computer connected into the >> webex-like session. >>>> >>>> Maybe. In lots of IETF meetings (to give one example) being in the >>>> webex session is close to being essential. >>>> >>>>> Those that don't will still want to see the presentation. >>>> >>>> That's a different but related use case, as is the use case where I >>>> am at the train station, have audio and webex, but no telepresence. >>>> "It would be nice" to have the webex display something of the >>>> telepresence session, assuming I have the bandwidth. >>>> >>>>> >>>>> I can see how the people with computers could use those as >>>>> supplemental displays, so that they could see more captures than >> are >>>>> available in the room as a whole. Presumably they wouldn't bother >> to >>>>> locally display a capture that is already being displayed on a room >> screen. >>>> >>>> This is interesting but not the use case I had in mind. >>>> >>>> Regards >>>> Marshall >>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> >>>>>> After a while, person Y starts displaying viewgraphs from their >>>>>> computer (i.e., they are now the presenter). >>>>>> >>>>>> I want the presenter screen to switch to showing person Y. >>>>>> >>>>>> Right now, all of this would be manual and very cumbersome to do, >>>>>> and yet I think it is an option people would want. >>>>>> >>>>>> Is publishing an XML scheme for describing this enough ? Could the >>>>>> telepresence system join the computer sharing session? >>>>>> Or can the computer sharing session join the telepresence as a >>>>>> participant, albeit a non-media producing or consuming >> participant? >>>>> >>>>> >>>>> I think either of these is *possible*, without any explicit support >> for it. >>>>> But the coordination to do so could be cumbersome. We need to >> figure >>>>> out if there is some mechanism we need to specify to make this >> convenient. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> >>>>>> Regards >>>>>> Marshall >>>>>> >>>>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul >> Kyzivat >>>>>> wrote: >>>>>>> >>>>>>> On 4/28/12 1:18 PM, Stephen Botzko wrote: >>>>>>> >>>>>>>> [sb] As I mentioned above, the existing solutions usually >> include >>>>>>>> a screen-scrape application, so you don't have to use a video >>>>>>>> cable. This is essentially the same as using Webex for >> presenting >>>>>>>> (but not remote control). >>>>>>> >>>>>>> >>>>>>> >>>>>>> How are these solutions connected? Does the captured application >>>>>>> data go to the local room controller, or to an MCU in the middle >>>>>>> of the TP session? >>>>>>> Or >>>>>>> something else? >>>>>>> >>>>>>> >>>>>>>> Also, even though Webex allows remote control, in my experience >>>>>>>> that feature is not used as much as simple presenting. I am not >>>>>>>> saying it has no value, just that the most common case I see is >> a >>>>>>>> simple presentation. >>>>>>> >>>>>>> >>>>>>> >>>>>>> That is my experience as well. I wasn't thinking about the >>>>>>> multi-user-control aspect. >>>>>>> >>>>>>> >>>>>>>> Supporting the video cable still has value, especially if you >>>>>>>> have guest presenter who does not have access to your local >>>>>>>> network. Most of those presenters are expecting to use a >>>>>>>> projector, so they have the cables with them. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Surely. In this case, I presume the cable connects to the local >>>>>>> room controller. If there are multiple cable connectors (e.g. one >>>>>>> at each >>>>>>> seat) >>>>>>> do they show up as multiple presentation streams? Or is there >> some >>>>>>> sort of switch and floor control? If so, how does one manage the >>>>>>> floor control? >>>>>>> >>>>>>> >>>>>>>> My answer on application sharing falling "out of favor" related >>>>>>>> specifically to vendor support for standards-based application >>>>>>>> sharing >>>>>>>> (T.120 in particular) - which I thought was responsive to your >>>>>>>> original question. Perhaps I misunderstood it. Anyway there >>>>>>>> were several reasons [and perhaps various viewpoints] on why >>>>>>>> T.120 was dropped, though I think it is probably not a useful >>>>>>>> discussion for this list. I know of no other standards-based >> protocol for application sharing. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I wasn't assuming there was, other than a pure video (and maybe >>>>>>> audio) stream interface. There are other fora for that sort of >>>>>>> thing, but its my impression that this is largely a world of >>>>>>> proprietary and defacto standards. >>>>>>> >>>>>>> >>>>>>>> BTW, it is relatively common for web screen sharing to co-exist >>>>>>>> with the videoconferencing presentation methods. For instance, >>>>>>>> you can have a stand-alone webex conference, with someone >> sharing >>>>>>>> their laptop screen for the video participants.[/sb] >>>>>>> >>>>>>> >>>>>>> >>>>>>> I have done this. But it was cumbersome. IIRC, getting the >> sharing >>>>>>> to be visible in the room I was in required using a video cable >> in >>>>>>> addition to using webex sharing. >>>>>>> >>>>>>> >>>>>>>> Of course that is still somewhat cumbersome, but presumably >> it will >>>>>>>> be improved over time. Its the UI for driving it that is >> cumbersome, >>>>>>>> not the output. >>>>>>>> >>>>>>>> A key difference is that if the computer output is via video >> cable >>>>>>>> into the local room controller, then that is probably >> responsible >>>>>>>> for displaying it locally on a display in the room as well >> as >>>>>>>> sending it to the remote end. If the users connect their >> computers >>>>>>>> directly to the MCU, then the capture will come to the room >> just >>>>>>>> like anything else from the MCU. >>>>>>>> >>>>>>>> [sb]The standard model for videoconferencing presentations is a >>>>>>>> token-controlled transmission. If you don't have the token, you >>>>>>>> are receiving. The local equipment is always responsible for >> display. >>>>>>>> Looping the presentation back through the MCU back to the >>>>>>>> originating site wastes bandwidth. >>>>>>>> >>>>>>>> I don't know if web conferencing solutions do this differently >> or not. >>>>>>>> I've always assumed that when I grab the webex "ball" I stop >>>>>>>> receiving desktop images. Certainly there is no reason for the >>>>>>>> server to send them back to me.[/sb] >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From mary.ietf.barnes@gmail.com Mon Apr 30 20:19:39 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8DB21E8044 for ; Mon, 30 Apr 2012 20:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x-DegDaOWQ9 for ; Mon, 30 Apr 2012 20:19:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 661E921E803A for ; Mon, 30 Apr 2012 20:19:39 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2991860vcb.31 for ; Mon, 30 Apr 2012 20:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7b189Vbvb6T0LKEOne+3NyZGQI68vKLU31cqRzpUVZA=; b=aOplIpX4DeCjsm3K/1Q6HgUO27wE2lY0ePP9vu7asJsa7Wfof0bMMBv48ZP41ovkmO 2yNzaRMlrkS+cYqh+xhX/jZ2UoZIDXYqArn3wPT+BpOseMJbETy0HSd4q1b4pl65NWDd irjtRjKLbiVT7qaJkeZMZ+/YB+1nbn/PUuMeV/Kb2wdyl5sdDMrwOn2FHZ1Zuf/czDq1 nwmuoE/egy0Sgi9ptPvPzJHMa4dfZFoVDqTgtxwO0k7JyxOPMsoIfGMw4KbzA75ILCaC qGXaWC7vLxrswocYtZWiDTO4fV47D27SX+NdNuDFmksx7rst+vcE7738Q7e1Tbyxcqop 3tfg== MIME-Version: 1.0 Received: by 10.52.67.203 with SMTP id p11mr20075127vdt.13.1335842378775; Mon, 30 Apr 2012 20:19:38 -0700 (PDT) Received: by 10.52.68.145 with HTTP; Mon, 30 Apr 2012 20:19:38 -0700 (PDT) Date: Mon, 30 Apr 2012 22:19:38 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307f32f0767c6f04bef10a8a Subject: [clue] Plans for call - Tuesday, May 1st @ 9am Central X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 03:19:40 -0000 --20cf307f32f0767c6f04bef10a8a Content-Type: text/plain; charset=ISO-8859-1 Hi all, We will have a call tomorrow. Let's see if we can get some clarity and common understanding around the presentation topic that's been under discussion on the list over the past week: http://www.ietf.org/mail-archive/web/clue/current/msg01367.html Webex info is here: http://www.ietf.org/mail-archive/web/clue/current/msg01287.html Mary. --20cf307f32f0767c6f04bef10a8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

We will have a call tomorrow. =A0Let's see i= f we can get some clarity and common understanding around the presentation = topic that's been under discussion on the list over the past week:
http://www.ietf.org/mail-archive/web/clue/current/msg01367.html


Mary.=A0
--20cf307f32f0767c6f04bef10a8a-- From allyn@cisco.com Mon Apr 30 21:57:09 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7B21F873D for ; Mon, 30 Apr 2012 21:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYtlon9tHgPy for ; Mon, 30 Apr 2012 21:57:08 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 419DE21F8736 for ; Mon, 30 Apr 2012 21:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=12546; q=dns/txt; s=iport; t=1335848228; x=1337057828; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=a1z2x7Yjm4IrXHJM6MicJ96WtvXjo15rS6aq4No3N+A=; b=Dw2GWpHDDBuNf1AjweLGGUQUOuvOoHSCKb+iK52XeK8+JYmn0EYjzvvs c4imvQtyEgRhpqxuB8hD8lZ0h1FhfFg6QydpxhjZUXrYlYt1LKrCMTetA g80TZs8fr7GjQxSTRuWsb63BRBZLfJQlJbY+7Cqd3KR1iqBdJlBG7JvkM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALBsn0+rRDoH/2dsb2JhbABEr2eDAYEHggkBAQEEAQEBDwEdCi4GFwQCAQgRBAEBAQoGFwEGASYfCQgCBAESCBMHh2oBC5oSoACQImMEiGSOK41IgWmDCA X-IronPort-AV: E=Sophos;i="4.75,508,1330905600"; d="scan'208";a="40335292" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 01 May 2012 04:57:07 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q414v7xY023312; Tue, 1 May 2012 04:57:07 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Apr 2012 21:57:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Apr 2012 21:57:05 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07635082@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] ways of managing presentations in telepresence sessions Thread-Index: AQHNI84a7nkR+jw5XUCzK/waIPY5UJas6IQAgAHAxoCAAAL1AIAAsVSAgAOtmQCAALVVXoAAoLOQ References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4f9ba527.6265b40a.7cae.0d9d@mx.google.com>, <4F9EBA9C.8040208@alum.mit.edu> From: "Allyn Romanow (allyn)" To: "Roni even" , "CLUE" X-OriginalArrivalTime: 01 May 2012 04:57:06.0963 (UTC) FILETIME=[DBA9EE30:01CD2756] Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 04:57:09 -0000 I agree with Roni, most of this discussion is out of scope. We can leave it to vendors to figure out how they want to use CLUE. The important thing is that the CLUE specification allows various types of endpoints - that it makes sense for different types of endpoints, such as software only. I believe that it currently does, though more scrutiny is always a good thing. This would mean stating rather precisely what Paul feels is missing from how CLUE handles presentation. Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni even > Sent: Monday, April 30, 2012 12:10 PM > To: Paul Kyzivat; Roni Even > Cc: 'CLUE' > Subject: Re: [clue] ways of managing presentations in telepresence > sessions >=20 > Paul, > I think that the video conference based on SIP and the application > sharing are two separate application with vendor specific API between > the two entities. If you can describe the application sharing in SIP / > SDP there may be a CLUE integration. in all other cases this is not up > to CLUE and I do not think that there is a such standard integration > even for a non CLUE SIP endpoint and application sharing > BTW" from the CLUE charter "This working group is not currently > chartered to work on issues of > continuous conference control including: far end camera control, > floor > control, conference roster." >=20 > I think we have currently enough work in CLUE without this topic > Roni >=20 > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul > Kyzivat [pkyzivat@alum.mit.edu] > Sent: Monday, April 30, 2012 19:15 > To: Roni Even > Cc: 'CLUE' > Subject: Re: [clue] ways of managing presentations in telepresence > sessions >=20 > My thought was not about the application sharing mechanism details. > What > I was thinking is that the shared application would in some way be > mapped to a presentation capture. >=20 > The point that seems to matter the most is how this appears in the > telepresence session topology. >=20 > The share might show up as a capture from the room where the person > doing the sharing resides. This implies that there is a connection > between the computer doing the sharing to the controller for the room. > And then the room controller will be deciding how to advertise it. E.g. > it could display it on a screen in its own room and advertise it in the > room scene with the position of that screen. Or the room controller > could advertise the share as a presentation capture in a separate > scene. >=20 > Or the share might show up as a capture from a separate endpoint > corresponding to the computer doing the sharing. Because this means > there are at least three endpoints involved, it will require an MCU. > And > then the MCU will need to figure out what to advertise in order to make > that capture available to all the rooms. >=20 > ISTM that either of these approaches could be made to work. But if the > computer doing the sharing is connecting over the web then it seems > much > more natural to me that it would be to a common point for the session, > rather than to the room controller. >=20 > I don't know how much of this it makes sense to address as part of > CLUE, but I don't think we can ignore it entirely. >=20 > Thanks, > Paul >=20 > On 4/28/12 4:05 AM, Roni Even wrote: > > Hi, > > Steve in his response mentioned that the there is a data > collaboration > > standard which is T.120 that was used in the past but is not used > today. The > > presentation stream is not for collaboration but just presentation > and works > > well in TP rooms equipped with monitors for the presentation stream. > > > > As for application sharing like WebEx or Meetecho all these solution > are > > stimulus based and there is no standard for these solutions. Most of > the > > video conferencing providers have such solution with some integration > to the > > video conference. > > I do not think that Clue should work on this integration since there > is no > > standard application sharing to integrate with. > > There was a proposal to work on application sharing in MMUSIC and AVT > couple > > of years ago (I think Jonathan had a draft with Henning) based on RTP > level. > > There was also a later draft > > http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 > but none > > of this progressed. > > > > Roni > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > >> Marshall Eubanks > >> Sent: Saturday, April 28, 2012 12:31 AM > >> To: Paul Kyzivat > >> Cc: CLUE > >> Subject: Re: [clue] ways of managing presentations in telepresence > >> sessions > >> > >> On Fri, Apr 27, 2012 at 5:20 PM, Paul Kyzivat > >> wrote: > >>> On 4/26/12 2:33 PM, Stephen Botzko wrote: > >>>> > >>>> Most traditional videoconferencing systems support H.239 (with > >>>> H.323), using a functionally equivalent method in SIP. The > >>>> presentation video is assigned a role (e.g., slides), and the > >> ability > >>>> to send is token-controlled with BFCP. All endpoints in the > >>>> conference receive the presentation. If there is a legacy device > >>>> (which doesn't support > >>>> presentations) on the far end, the sender usually chooses to send > >> the > >>>> presentation instead of the participant video. > >>>> > >>>> Computers can be connected using HDMI/Displayport/DVI/VGA directly > >> to > >>>> the video conferencing endpoint. Alternatively, there may be a PC > >>>> application that screen-scrapes the display and sends it to the > >>>> endpoint for distribution. These same options are used in > >> telepresence systems. > >>>> > >>>> On the receiving side, there are several options. Sometimes the > >>>> content is displayed on a separate monitor or projector. > Sometimes > >>>> the content is composed along with participants, and placed on a > >>>> single display. In telepresence systems, there are frequently > >>>> content monitors at each seat, all of which will display the > >> presentation. > >>>> > >>>> Application sharing was common back in the 90's (using the T.120 > >>>> protocol), but fell out of favor for a variety of reasons. > >>> > >>> > >>> What is it that webex uses for application sharing? AFAIK that is > not > >>> falling out of favor. I would much rather use webex application > >>> sharing than be forced to plug a video connector into my computer. > >>> > >>> Of course that is still somewhat cumbersome, but presumably it will > >> be > >>> improved over time. Its the UI for driving it that is cumbersome, > not > >>> the output. > >>> > >> > >> Since this is true, and since it is very hard to change such > behavior, > >> this raises the question : > >> > >> Is there a CLUE role for metadata exchange with applications such as > >> Webex? Or, are we going to be condemned to running separate > >> asynchronous conferences for data and telepresence ? > >> > >> I am not sure of the answer, but I did want to raise the question. > >> > >> Regards > >> Marshall > >> > >> > >>> A key difference is that if the computer output is via video cable > >>> into the local room controller, then that is probably responsible > for > >>> displaying it locally on a display in the room as well as sending > it > >>> to the remote end. If the users connect their computers directly to > >>> the MCU, then the capture will come to the room just like anything > >> else from the MCU. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Stephen Botzko > >>>> > >>>> > >>>> > >>>> On Thu, Apr 26, 2012 at 12:57 PM, Paul Kyzivat > >> >>>> > wrote: > >>>> > >>>> I am working on my use cases for the question about how to > select > >>>> which captures to display. But I have a gap in my > understanding, > >>>> and > >>>> would like to get input from those of you with more experience > in > >>>> a > >>>> diversity of telepresence systems. > >>>> > >>>> My only live experience with telepresence systems is with the > >>>> Cisco > >>>> ones. I'm not aware of it having any explicit support for > >>>> presentations, though that might just be my lack of > >> understanding. > >>>> > >>>> So I'd like to hear what *is* supported, or is *intended* to > be > >>>> supported. > >>>> > >>>> I presume that for the most part presentations these days > >>>> originate > >>>> in a computer and are fed into the telepresence system, much > like > >>>> they are in webex - either by preloading documents to the > >>>> conference > >>>> controller and then interacting with it from a computer to > have > >>>> them > >>>> displayed, or by "sharing an application" dynamically from a > >>>> computer. I understand that in a system like webex, which is > not > >> a > >>>> telepresence system. But what does that mean when married to a > >>>> telepresence system? > >>>> > >>>> Some ways I can imagine this working: > >>>> > >>>> - visitors to a telepresence room bring their own computers. > >>>> Each seat has a video connector that the visitor can connect > to > >>>> and originate a presentation stream. When active, these > become > >>>> additional captures from the room. But for others in the > same > >>>> room to see, these would then have to be treated as incoming > >>>> captures (from where) and displayed on some display in the > >> room. > >>>> > >>>> - visitors to a telepresence room bring their own computers. > >>>> Each such computer connects to an MCU as if it were an > >>>> independent > >>>> endpoint/room. The computer then offers up whatever it wants > to > >>>> share as a capture. The room itself also connects to the > MCU, > >>>> with its cameras as captures. The MCU sorts this all out, > >>>> handles > >>>> floor control, and decides what to advertise. So it can > include > >>>> presentations from user's computers as well as captures from > >> the > >>>> rooms. The local room can then display one or more > >> presentations > >>>> on its diplays. Or, the user's computer could also serve as > a > >>>> display for presentations so that the room's displays could > be > >>>> reserved for showing participants in other rooms. > >>>> > >>>> - the telepresence room could have a personal display and > >>>> controller > >>>> at each seat. This could provide the user with a controller > to > >>>> request the floor, to review preloaded documents and request > >>>> their > >>>> display, etc. (Its a bit like the first one above.) > >>>> > >>>> There seems to be a big difference if the presentation is seen > as > >>>> coming from a room that has the typical telepresence layout, > or > >> if > >>>> it is seen coming from a separate endpoint coupled to the > >> computer > >>>> generating it, and whether the presentation is displayed on > >>>> equipment that is part of the room, or by a separate endpoint. > >>>> > >>>> I'd like feedback if any of the above makes sense, and whether > >>>> there > >>>> are other ways of looking at this I haven't imagined. > >>>> > >>>> Thanks, > >>>> Paul > >>>> _________________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/clue > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Mon Apr 30 22:07:06 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE94A21F87A0 for ; Mon, 30 Apr 2012 22:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWR9L7esCN9S for ; Mon, 30 Apr 2012 22:07:05 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1E87E21F879E for ; Mon, 30 Apr 2012 22:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=11856; q=dns/txt; s=iport; t=1335848825; x=1337058425; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0wtFfKv9La9QCL93Dw2XmqC3FFNS1hOAnq2wGLCUNw8=; b=CTNESgCkqzFj7pPvX3SwTESuKbjnWgSpFeCmGwzaCn86rEH3MdLDNemc 6fqogubW7YFzdHw3VHMcn/Reo7PTPFOZTmzrRl2JpkC+jXKatvo7G77zz uzT/nIKFJWxzee2jNlpY+6yjfGFeWw8Vy0EQI/VxdBq3DRIQAoq5HLJtG o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOpun0+rRDoI/2dsb2JhbAA6Cg6vWYMBgQeCCQEBAQMBAQEBDwEdCi4GCwUHBAIBCA4DBAEBAQoGFwEGASYfCQgBAQQBEggTB4VvgXcEAQuaEp9/BIp5hSljBIhkm3OBaYIvWYE0BwE X-IronPort-AV: E=Sophos;i="4.75,508,1330905600"; d="scan'208";a="42910981" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 01 May 2012 05:07:04 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q41574Ik022795; Tue, 1 May 2012 05:07:04 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Apr 2012 22:07:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Apr 2012 22:07:03 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07635083@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4F9F0BAE.7000500@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] ways of managing presentations in telepresence sessions Thread-Index: Ac0nHNJdgznPAQxXQc2TT35yIEl5SgAOHrKA References: <4F997E6B.7070501@alum.mit.edu><4F9B0D81.4040608@alum.mit.edu><4F9EC454.3060605@alum.mit.edu><4F9ED7C5.70709@alum.mit.edu><4281238F-4A41-4B6D-9B89-CDBD61923330@brianrosen.net> <4F9F0BAE.7000500@alum.mit.edu> From: "Allyn Romanow (allyn)" To: "Paul Kyzivat" , "Brian Rosen" X-OriginalArrivalTime: 01 May 2012 05:07:04.0461 (UTC) FILETIME=[3FCCE3D0:01CD2758] Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 05:07:07 -0000 Hi - I agree with Brian's first main point=20 > the sharing application to provide the shared info, as a presentation. > This suggests that it be connected as a CLUE endpoint. I think our job is to make sure the CLUE spec works for different types of endpoints, rather than invent new telepresence systems that do presentation in new and interesting ways; nor do I think we should consider the details of integration that particular proprietary conferencing system such as webex may or may not want to do. IMO, our job is to make sure that CLUE is able to allow interoperability and a reasonable experience to any system that chooses to use it. Does that make sense?=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Monday, April 30, 2012 3:01 PM > To: Brian Rosen > Cc: CLUE > Subject: Re: [clue] ways of managing presentations in telepresence > sessions >=20 > On 4/30/12 4:15 PM, Brian Rosen wrote: > > I agree with this - you bring your laptop to the room, or there is a > desktop in the room for you, and you connect that to the presentation > sharing system. The audio/video is connected to a different system. > The challenge is to interwork these so change in presenter affects > both. >=20 > I agree with this. >=20 > But I also think there needs to be a parity for presentations > regardless > of how they are brought in. There should be the same options for > viewing > a presentation regardless of whether it is captured from a video jack > or > over the web via application sharing. Either way there should be the > option to show it on one of the screens in the various rooms. >=20 > Of course it should also be possible for those participants who are > connected to the sharing application to view this on their computers. > And if everybody in a room is viewing the presentation from their own > computer then the room system need not display it. >=20 > This all points to some needs: >=20 > - the sharing application to provide the shared info, as a > presentation. > This suggests that it be connected as a CLUE endpoint. >=20 > - Some mechanism to identify to the CLUE system who is sourcing a > presentation stream - which I guess means correlating a presentation > stream to one or more other captures that contain the presenters. > This could be hard if the endpoint sending the presentation stream > is not the system sending the captures of the presenters. >=20 > Thanks, > Paul >=20 > > Brian > > > > On Apr 30, 2012, at 3:21 PM, Marshall Eubanks wrote: > > > >> Dear Paul; > >> > >> > >> > >> On Mon, Apr 30, 2012 at 2:19 PM, Paul Kyzivat > wrote: > >>> Thanks Marshall - this is a good use case. I'm inserting questions > inline. > >>> > >>> > >>> On 4/30/12 1:49 PM, Marshall Eubanks wrote: > >>>> > >>>> Here is a potential use case : > >>>> > >>>> There is a telepresence session and an associated webex-like > computer > >>>> sharing session. > >>>> > >>>> At some time, person X has the floor on the computer sharing > session > >>>> (i.e., they are the presenter). > >>>> > >>>> I want to see person X on screen. (Or, maybe, I am the chair, and > I > >>>> want every telepresence participant to see > >>>> person X on their screen.) I want to see X even if he or she is > not > >>>> talking for a bit, so just doing voice switching is not enough. > >>> > >>> > >>> Are you talking about the *computer* screen? Or one of the screens > in the TP > >>> room? And are you just talking about displaying the presenter, or > the > >>> presentation as well? > >> > >> No, I was talking about > >> > >> - video screens display people > >> - computer screens display someone's desktop (or application or...) > >> > >> So, this is really about unified floor control. When I give someone > >> the floor, I want to > >> see their face on the screen, and their presentation on my laptop. > >> And, I want to > >> do this once, not have to fuss with two autonomous systems. > >> > >> I don't care if I do it through the presentation system or through > the > >> telepresence system*, but the implication to me is that > >> one has to be the driver, the other driven, and they have to talk to > each other. > >> > >> * My mental image was doing this through the telepresence system but > >> thinking about it doing it through the presentation system may have > >> some advantages, for example in authentication. > >> > >>> > >>> I think its reasonable to expect that some but not all of the > participants > >>> in the room(s) will have a computer connected into the webex-like > session. > >> > >> Maybe. In lots of IETF meetings (to give one example) being in the > >> webex session is close to being essential. > >> > >>> Those that don't will still want to see the presentation. > >> > >> That's a different but related use case, as is the use case where I > am > >> at the train station, have audio and webex, but > >> no telepresence. "It would be nice" to have the webex display > >> something of the telepresence session, assuming I have the > bandwidth. > >> > >>> > >>> I can see how the people with computers could use those as > supplemental > >>> displays, so that they could see more captures than are available > in the > >>> room as a whole. Presumably they wouldn't bother to locally display > a > >>> capture that is already being displayed on a room screen. > >> > >> This is interesting but not the use case I had in mind. > >> > >> Regards > >> Marshall > >> > >>> > >>> Thanks, > >>> Paul > >>> > >>> > >>>> After a while, person Y starts displaying viewgraphs from their > >>>> computer (i.e., they are now the presenter). > >>>> > >>>> I want the presenter screen to switch to showing person Y. > >>>> > >>>> Right now, all of this would be manual and very cumbersome to do, > and > >>>> yet I think it is an option people would want. > >>>> > >>>> Is publishing an XML scheme for describing this enough ? Could the > >>>> telepresence system join the computer sharing session? > >>>> Or can the computer sharing session join the telepresence as a > >>>> participant, albeit a non-media producing or consuming > participant? > >>> > >>> > >>> I think either of these is *possible*, without any explicit support > for it. > >>> But the coordination to do so could be cumbersome. We need to > figure out if > >>> there is some mechanism we need to specify to make this convenient. > >>> > >>> Thanks, > >>> Paul > >>> > >>> > >>>> Regards > >>>> Marshall > >>>> > >>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul > Kyzivat > >>>> wrote: > >>>>> > >>>>> On 4/28/12 1:18 PM, Stephen Botzko wrote: > >>>>> > >>>>>> [sb] As I mentioned above, the existing solutions usually > include a > >>>>>> screen-scrape application, so you don't have to use a video > cable. This > >>>>>> is essentially the same as using Webex for presenting (but not > remote > >>>>>> control). > >>>>> > >>>>> > >>>>> > >>>>> How are these solutions connected? Does the captured application > data go > >>>>> to > >>>>> the local room controller, or to an MCU in the middle of the TP > session? > >>>>> Or > >>>>> something else? > >>>>> > >>>>> > >>>>>> Also, even though Webex allows remote control, in my > >>>>>> experience that feature is not used as much as simple > presenting. I am > >>>>>> not saying it has no value, just that the most common case I see > is a > >>>>>> simple presentation. > >>>>> > >>>>> > >>>>> > >>>>> That is my experience as well. I wasn't thinking about the > >>>>> multi-user-control aspect. > >>>>> > >>>>> > >>>>>> Supporting the video cable still has value, especially if you > have guest > >>>>>> presenter who does not have access to your local network. Most > of those > >>>>>> presenters are expecting to use a projector, so they have the > cables > >>>>>> with them. > >>>>> > >>>>> > >>>>> > >>>>> Surely. In this case, I presume the cable connects to the local > room > >>>>> controller. If there are multiple cable connectors (e.g. one at > each > >>>>> seat) > >>>>> do they show up as multiple presentation streams? Or is there > some sort > >>>>> of > >>>>> switch and floor control? If so, how does one manage the floor > control? > >>>>> > >>>>> > >>>>>> My answer on application sharing falling "out of favor" related > >>>>>> specifically to vendor support for standards-based application > sharing > >>>>>> (T.120 in particular) - which I thought was responsive to your > original > >>>>>> question. Perhaps I misunderstood it. Anyway there were > several > >>>>>> reasons [and perhaps various viewpoints] on why T.120 was > dropped, > >>>>>> though I think it is probably not a useful discussion for this > list. I > >>>>>> know of no other standards-based protocol for application > sharing. > >>>>> > >>>>> > >>>>> > >>>>> I wasn't assuming there was, other than a pure video (and maybe > audio) > >>>>> stream interface. There are other fora for that sort of thing, > but its my > >>>>> impression that this is largely a world of proprietary and > defacto > >>>>> standards. > >>>>> > >>>>> > >>>>>> BTW, it is relatively common for web screen sharing to co-exist > with the > >>>>>> videoconferencing presentation methods. For instance, you can > have a > >>>>>> stand-alone webex conference, with someone sharing their laptop > screen > >>>>>> for the video participants.[/sb] > >>>>> > >>>>> > >>>>> > >>>>> I have done this. But it was cumbersome. IIRC, getting the > sharing to be > >>>>> visible in the room I was in required using a video cable in > addition to > >>>>> using webex sharing. > >>>>> > >>>>> > >>>>>> Of course that is still somewhat cumbersome, but presumably > it will > >>>>>> be improved over time. Its the UI for driving it that is > cumbersome, > >>>>>> not the output. > >>>>>> > >>>>>> A key difference is that if the computer output is via video > cable > >>>>>> into the local room controller, then that is probably > responsible > >>>>>> for displaying it locally on a display in the room as well > as > >>>>>> sending it to the remote end. If the users connect their > computers > >>>>>> directly to the MCU, then the capture will come to the room > just > >>>>>> like anything else from the MCU. > >>>>>> > >>>>>> [sb]The standard model for videoconferencing presentations is a > >>>>>> token-controlled transmission. If you don't have the token, you > are > >>>>>> receiving. The local equipment is always responsible for > display. > >>>>>> Looping the presentation back through the MCU back to the > originating > >>>>>> site wastes bandwidth. > >>>>>> > >>>>>> I don't know if web conferencing solutions do this differently > or not. > >>>>>> I've always assumed that when I grab the webex "ball" I stop > receiving > >>>>>> desktop images. Certainly there is no reason for the server to > send > >>>>>> them back to me.[/sb] > >>>>> > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >>>> > >>> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Mon Apr 30 22:09:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F4D21F8799 for ; Mon, 30 Apr 2012 22:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFdvaKxrtPsB for ; Mon, 30 Apr 2012 22:09:27 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A54F821F879E for ; Mon, 30 Apr 2012 22:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=12822; q=dns/txt; s=iport; t=1335848967; x=1337058567; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=8I31sWk/N8olIa3Vm4S5vTvG8A+8qChR3qsYh8EoNCU=; b=GOmks8Npy+zVi3KrfLsSZWv+5BFqiA4dGYXSQdqnA6u/ELTScAqBs0Xc gugtLLeEoGi2GufagxSpwh8+2MrSmJpiKXoAVSwul7vM1LWsVsdzxDdmH kI1toFPrn+lUcasqkkpAjNr1s3Ul3SyJkO9C/d9pCuihnIt3v2L7vqjmh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOpun0+rRDoJ/2dsb2JhbAA6Cg6vWYMBgQeCCQEBAQQBAQEPAR0KLgYLDAQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEARIIEweFb4F7AQuaEp9/BIp5hSljBIhkm3OBaYIvWYE8 X-IronPort-AV: E=Sophos;i="4.75,508,1330905600"; d="scan'208";a="40336540" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 01 May 2012 05:09:27 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4159RhV000484; Tue, 1 May 2012 05:09:27 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Apr 2012 22:09:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Apr 2012 22:09:25 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC07635084@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4f9f0d9c.c652b40a.5efb.ffffb8c7@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] ways of managing presentations in telepresence sessions Thread-Index: Ac0nHMmwUZZWIZyeTlWNmcbRXTOtbwAAHQUAAA7HZVA= References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <4F9ED7C5.70709@alum.mit.edu> <4281238F-4A41-4B6D-9B89-CDBD61923330@brianrosen.net><4F9F0BAE.7000500@alum.mit.edu> <4f9f0d9c.c652b40a.5efb.ffffb8c7@mx.google.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Paul Kyzivat" , "Brian Rosen" X-OriginalArrivalTime: 01 May 2012 05:09:26.0740 (UTC) FILETIME=[949AF140:01CD2758] Cc: CLUE Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 05:09:29 -0000 Agree- Integration is out of scope.. If someone feels there is something missing in CLUE for presentation, that's in scope. Thanks, Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni Even > Sent: Monday, April 30, 2012 3:08 PM > To: 'Paul Kyzivat'; 'Brian Rosen' > Cc: 'CLUE' > Subject: Re: [clue] ways of managing presentations in telepresence > sessions >=20 > Paul, > My suggestion is to start with this integration for any video or audio > SIP > conference before going into CLUE. > There is no such solution for this because there is no standard API > between > the application sharing and the SIP conference bridge. > This topic can be discussed in DISPATCH > I fail to see why we are discussing it here. This is defiantly not in > the > scope since these application sharing are not using RTP, SDP or SIP > Roni >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Paul Kyzivat > > Sent: Tuesday, May 01, 2012 1:01 AM > > To: Brian Rosen > > Cc: CLUE > > Subject: Re: [clue] ways of managing presentations in telepresence > > sessions > > > > On 4/30/12 4:15 PM, Brian Rosen wrote: > > > I agree with this - you bring your laptop to the room, or there is > a > > desktop in the room for you, and you connect that to the presentation > > sharing system. The audio/video is connected to a different system. > > The challenge is to interwork these so change in presenter affects > > both. > > > > I agree with this. > > > > But I also think there needs to be a parity for presentations > > regardless of how they are brought in. There should be the same > options > > for viewing a presentation regardless of whether it is captured from > a > > video jack or over the web via application sharing. Either way there > > should be the option to show it on one of the screens in the various > > rooms. > > > > Of course it should also be possible for those participants who are > > connected to the sharing application to view this on their computers. > > And if everybody in a room is viewing the presentation from their own > > computer then the room system need not display it. > > > > This all points to some needs: > > > > - the sharing application to provide the shared info, as a > > presentation. > > This suggests that it be connected as a CLUE endpoint. > > > > - Some mechanism to identify to the CLUE system who is sourcing a > > presentation stream - which I guess means correlating a > presentation > > stream to one or more other captures that contain the presenters. > > This could be hard if the endpoint sending the presentation stream > > is not the system sending the captures of the presenters. > > > > Thanks, > > Paul > > > > > Brian > > > > > > On Apr 30, 2012, at 3:21 PM, Marshall Eubanks wrote: > > > > > >> Dear Paul; > > >> > > >> > > >> > > >> On Mon, Apr 30, 2012 at 2:19 PM, Paul > Kyzivat > > wrote: > > >>> Thanks Marshall - this is a good use case. I'm inserting > questions > > inline. > > >>> > > >>> > > >>> On 4/30/12 1:49 PM, Marshall Eubanks wrote: > > >>>> > > >>>> Here is a potential use case : > > >>>> > > >>>> There is a telepresence session and an associated webex-like > > >>>> computer sharing session. > > >>>> > > >>>> At some time, person X has the floor on the computer sharing > > >>>> session (i.e., they are the presenter). > > >>>> > > >>>> I want to see person X on screen. (Or, maybe, I am the chair, > and > > I > > >>>> want every telepresence participant to see person X on their > > >>>> screen.) I want to see X even if he or she is not talking for a > > >>>> bit, so just doing voice switching is not enough. > > >>> > > >>> > > >>> Are you talking about the *computer* screen? Or one of the > screens > > >>> in the TP room? And are you just talking about displaying the > > >>> presenter, or the presentation as well? > > >> > > >> No, I was talking about > > >> > > >> - video screens display people > > >> - computer screens display someone's desktop (or application > or...) > > >> > > >> So, this is really about unified floor control. When I give > someone > > >> the floor, I want to see their face on the screen, and their > > >> presentation on my laptop. > > >> And, I want to > > >> do this once, not have to fuss with two autonomous systems. > > >> > > >> I don't care if I do it through the presentation system or through > > >> the telepresence system*, but the implication to me is that one > has > > >> to be the driver, the other driven, and they have to talk to each > > other. > > >> > > >> * My mental image was doing this through the telepresence system > but > > >> thinking about it doing it through the presentation system may > have > > >> some advantages, for example in authentication. > > >> > > >>> > > >>> I think its reasonable to expect that some but not all of the > > >>> participants in the room(s) will have a computer connected into > the > > webex-like session. > > >> > > >> Maybe. In lots of IETF meetings (to give one example) being in the > > >> webex session is close to being essential. > > >> > > >>> Those that don't will still want to see the presentation. > > >> > > >> That's a different but related use case, as is the use case where > I > > >> am at the train station, have audio and webex, but no > telepresence. > > >> "It would be nice" to have the webex display something of the > > >> telepresence session, assuming I have the bandwidth. > > >> > > >>> > > >>> I can see how the people with computers could use those as > > >>> supplemental displays, so that they could see more captures than > > are > > >>> available in the room as a whole. Presumably they wouldn't bother > > to > > >>> locally display a capture that is already being displayed on a > room > > screen. > > >> > > >> This is interesting but not the use case I had in mind. > > >> > > >> Regards > > >> Marshall > > >> > > >>> > > >>> Thanks, > > >>> Paul > > >>> > > >>> > > >>>> After a while, person Y starts displaying viewgraphs from their > > >>>> computer (i.e., they are now the presenter). > > >>>> > > >>>> I want the presenter screen to switch to showing person Y. > > >>>> > > >>>> Right now, all of this would be manual and very cumbersome to > do, > > >>>> and yet I think it is an option people would want. > > >>>> > > >>>> Is publishing an XML scheme for describing this enough ? Could > the > > >>>> telepresence system join the computer sharing session? > > >>>> Or can the computer sharing session join the telepresence as a > > >>>> participant, albeit a non-media producing or consuming > > participant? > > >>> > > >>> > > >>> I think either of these is *possible*, without any explicit > support > > for it. > > >>> But the coordination to do so could be cumbersome. We need to > > figure > > >>> out if there is some mechanism we need to specify to make this > > convenient. > > >>> > > >>> Thanks, > > >>> Paul > > >>> > > >>> > > >>>> Regards > > >>>> Marshall > > >>>> > > >>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul > > Kyzivat > > >>>> wrote: > > >>>>> > > >>>>> On 4/28/12 1:18 PM, Stephen Botzko wrote: > > >>>>> > > >>>>>> [sb] As I mentioned above, the existing solutions usually > > include > > >>>>>> a screen-scrape application, so you don't have to use a video > > >>>>>> cable. This is essentially the same as using Webex for > > presenting > > >>>>>> (but not remote control). > > >>>>> > > >>>>> > > >>>>> > > >>>>> How are these solutions connected? Does the captured > application > > >>>>> data go to the local room controller, or to an MCU in the > middle > > >>>>> of the TP session? > > >>>>> Or > > >>>>> something else? > > >>>>> > > >>>>> > > >>>>>> Also, even though Webex allows remote control, in my > experience > > >>>>>> that feature is not used as much as simple presenting. I am > not > > >>>>>> saying it has no value, just that the most common case I see > is > > a > > >>>>>> simple presentation. > > >>>>> > > >>>>> > > >>>>> > > >>>>> That is my experience as well. I wasn't thinking about the > > >>>>> multi-user-control aspect. > > >>>>> > > >>>>> > > >>>>>> Supporting the video cable still has value, especially if you > > >>>>>> have guest presenter who does not have access to your local > > >>>>>> network. Most of those presenters are expecting to use a > > >>>>>> projector, so they have the cables with them. > > >>>>> > > >>>>> > > >>>>> > > >>>>> Surely. In this case, I presume the cable connects to the local > > >>>>> room controller. If there are multiple cable connectors (e.g. > one > > >>>>> at each > > >>>>> seat) > > >>>>> do they show up as multiple presentation streams? Or is there > > some > > >>>>> sort of switch and floor control? If so, how does one manage > the > > >>>>> floor control? > > >>>>> > > >>>>> > > >>>>>> My answer on application sharing falling "out of favor" > related > > >>>>>> specifically to vendor support for standards-based application > > >>>>>> sharing > > >>>>>> (T.120 in particular) - which I thought was responsive to your > > >>>>>> original question. Perhaps I misunderstood it. Anyway there > > >>>>>> were several reasons [and perhaps various viewpoints] on why > > >>>>>> T.120 was dropped, though I think it is probably not a useful > > >>>>>> discussion for this list. I know of no other standards-based > > protocol for application sharing. > > >>>>> > > >>>>> > > >>>>> > > >>>>> I wasn't assuming there was, other than a pure video (and maybe > > >>>>> audio) stream interface. There are other fora for that sort of > > >>>>> thing, but its my impression that this is largely a world of > > >>>>> proprietary and defacto standards. > > >>>>> > > >>>>> > > >>>>>> BTW, it is relatively common for web screen sharing to co- > exist > > >>>>>> with the videoconferencing presentation methods. For > instance, > > >>>>>> you can have a stand-alone webex conference, with someone > > sharing > > >>>>>> their laptop screen for the video participants.[/sb] > > >>>>> > > >>>>> > > >>>>> > > >>>>> I have done this. But it was cumbersome. IIRC, getting the > > sharing > > >>>>> to be visible in the room I was in required using a video cable > > in > > >>>>> addition to using webex sharing. > > >>>>> > > >>>>> > > >>>>>> Of course that is still somewhat cumbersome, but > presumably > > it will > > >>>>>> be improved over time. Its the UI for driving it that is > > cumbersome, > > >>>>>> not the output. > > >>>>>> > > >>>>>> A key difference is that if the computer output is via > video > > cable > > >>>>>> into the local room controller, then that is probably > > responsible > > >>>>>> for displaying it locally on a display in the room as well > > as > > >>>>>> sending it to the remote end. If the users connect their > > computers > > >>>>>> directly to the MCU, then the capture will come to the > room > > just > > >>>>>> like anything else from the MCU. > > >>>>>> > > >>>>>> [sb]The standard model for videoconferencing presentations is > a > > >>>>>> token-controlled transmission. If you don't have the token, > you > > >>>>>> are receiving. The local equipment is always responsible for > > display. > > >>>>>> Looping the presentation back through the MCU back to the > > >>>>>> originating site wastes bandwidth. > > >>>>>> > > >>>>>> I don't know if web conferencing solutions do this differently > > or not. > > >>>>>> I've always assumed that when I grab the webex "ball" I stop > > >>>>>> receiving desktop images. Certainly there is no reason for > the > > >>>>>> server to send them back to me.[/sb] > > >>>>> > > >>>>> > > >>>>> > > >>>>> Thanks, > > >>>>> Paul > > >>>>> _______________________________________________ > > >>>>> clue mailing list > > >>>>> clue@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/clue > > >>>> > > >>>> > > >>> > > >> _______________________________________________ > > >> clue mailing list > > >> clue@ietf.org > > >> https://www.ietf.org/mailman/listinfo/clue > > > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Mon Apr 30 22:15:07 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BCD21F87D4 for ; Mon, 30 Apr 2012 22:15:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex5LlGlm2Inb for ; Mon, 30 Apr 2012 22:15:06 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E46C021F87CC for ; Mon, 30 Apr 2012 22:15:05 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so729075wgb.13 for ; Mon, 30 Apr 2012 22:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=3cvqE4YJTpvHQqP2iTBSJDmaS6d4VQzleXaEpHrgzu0=; b=znFj1fYWSr98WAH5lBJerVdz5HiAsFzykfbkkbl4oABXP0s4EZCVoHLYWkTgauz0M7 7ewGi1f9OuMxirdT61JLBedAyfjNOpjDqoTnSEt2+AuAwyc7Dejrdw34t5NgG3Xtu01i IHfco40t8skB3wGCweUaM3dfboXlilGC1jp4GvmcYPa0r9iMGoRV6BhdUPtHjZqff29F TwwEikupcMdjYkW7qPxHlIFupOHo//C40gb22w5/Mn7Maw2oE1HpBxapNFVzUdRq5zu7 CXkxv2LUCIVx7Bi8vMOmJmthWm+6o73YsTeB+lFy0UL5BLj8/vDhedKa52zqtdgdtDAA D8Xw== Received: by 10.180.102.101 with SMTP id fn5mr2297859wib.6.1335849304909; Mon, 30 Apr 2012 22:15:04 -0700 (PDT) Received: from windows8d787f9 ([109.67.230.123]) by mx.google.com with ESMTPS id ca3sm33499222wib.6.2012.04.30.22.15.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Apr 2012 22:15:04 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <4F997E6B.7070501@alum.mit.edu> <4F9B0D81.4040608@alum.mit.edu> <4F9EC454.3060605@alum.mit.edu> <4F9ED7C5.70709@alum.mit.edu> <4281238F-4A41-4B6D-9B89-CDBD61923330@brianrosen.net> <4F9F0BAE.7000500@alum.mit.edu> <4f9f0d9c.c652b40a.5efb.ffffb8c7@mx.google.com> <4F9F3C14.60809@alum.mit.edu> In-Reply-To: <4F9F3C14.60809@alum.mit.edu> Date: Tue, 1 May 2012 08:13:08 +0300 Message-ID: <4f9f7158.035bb40a.37af.047c@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0nOZ+6BWz3xS3dTsSyDwUwf/rkXAAHt2iw Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] ways of managing presentations in telepresence sessions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 05:15:07 -0000 Hi Paul, I suggest you start by describing the use case explaining the integration between the application sharing application and the video conference infrastructure. Still since this is not defined even for regular SIP conference I am not sure why we are discussing non-standard integration here. All you can say that there may be application sharing and that the application sharing application may need to interact with the CLUE environment. As for he use case, you can start by explaining how when someone gets the presentation token he become the presenter in the video conference. My assumption is that this is done by the external API to the MCU. Roni > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, May 01, 2012 4:28 AM > To: Roni Even > Cc: 'Brian Rosen'; 'CLUE' > Subject: Re: [clue] ways of managing presentations in telepresence > sessions > > On 4/30/12 6:07 PM, Roni Even wrote: > > Paul, > > My suggestion is to start with this integration for any video or > audio > > SIP conference before going into CLUE. > > There is no such solution for this because there is no standard API > > between the application sharing and the SIP conference bridge. > > This topic can be discussed in DISPATCH I fail to see why we are > > discussing it here. This is defiantly not in the scope since these > > application sharing are not using RTP, SDP or SIP Roni > > Roni, > > I've been trying to walk a fine line here. I'm not proposing that we > should discuss application sharing APIs, etc. But we do have > presentation captures as part of CLUE, and I think we should not assume > that they always come from sticking hard copy under a presentation > camera or by plugging a computer into a video connector. > > It may be sufficient to acknowledge that computers used by participants > to provide presentations might connect as independent CLUE endpoints. > > I'm trying to understand the rudiments of this to make a realistic use > case involving presentations. > > Thanks, > Paul > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Tuesday, May 01, 2012 1:01 AM > >> To: Brian Rosen > >> Cc: CLUE > >> Subject: Re: [clue] ways of managing presentations in telepresence > >> sessions > >> > >> On 4/30/12 4:15 PM, Brian Rosen wrote: > >>> I agree with this - you bring your laptop to the room, or there is > a > >> desktop in the room for you, and you connect that to the > presentation > >> sharing system. The audio/video is connected to a different system. > >> The challenge is to interwork these so change in presenter affects > >> both. > >> > >> I agree with this. > >> > >> But I also think there needs to be a parity for presentations > >> regardless of how they are brought in. There should be the same > >> options for viewing a presentation regardless of whether it is > >> captured from a video jack or over the web via application sharing. > >> Either way there should be the option to show it on one of the > >> screens in the various rooms. > >> > >> Of course it should also be possible for those participants who are > >> connected to the sharing application to view this on their > computers. > >> And if everybody in a room is viewing the presentation from their > own > >> computer then the room system need not display it. > >> > >> This all points to some needs: > >> > >> - the sharing application to provide the shared info, as a > >> presentation. > >> This suggests that it be connected as a CLUE endpoint. > >> > >> - Some mechanism to identify to the CLUE system who is sourcing a > >> presentation stream - which I guess means correlating a > presentation > >> stream to one or more other captures that contain the > presenters. > >> This could be hard if the endpoint sending the presentation > stream > >> is not the system sending the captures of the presenters. > >> > >> Thanks, > >> Paul > >> > >>> Brian > >>> > >>> On Apr 30, 2012, at 3:21 PM, Marshall Eubanks wrote: > >>> > >>>> Dear Paul; > >>>> > >>>> > >>>> > >>>> On Mon, Apr 30, 2012 at 2:19 PM, Paul > >>>> Kyzivat > >> wrote: > >>>>> Thanks Marshall - this is a good use case. I'm inserting > questions > >> inline. > >>>>> > >>>>> > >>>>> On 4/30/12 1:49 PM, Marshall Eubanks wrote: > >>>>>> > >>>>>> Here is a potential use case : > >>>>>> > >>>>>> There is a telepresence session and an associated webex-like > >>>>>> computer sharing session. > >>>>>> > >>>>>> At some time, person X has the floor on the computer sharing > >>>>>> session (i.e., they are the presenter). > >>>>>> > >>>>>> I want to see person X on screen. (Or, maybe, I am the chair, > and > >> I > >>>>>> want every telepresence participant to see person X on their > >>>>>> screen.) I want to see X even if he or she is not talking for a > >>>>>> bit, so just doing voice switching is not enough. > >>>>> > >>>>> > >>>>> Are you talking about the *computer* screen? Or one of the > screens > >>>>> in the TP room? And are you just talking about displaying the > >>>>> presenter, or the presentation as well? > >>>> > >>>> No, I was talking about > >>>> > >>>> - video screens display people > >>>> - computer screens display someone's desktop (or application > or...) > >>>> > >>>> So, this is really about unified floor control. When I give > someone > >>>> the floor, I want to see their face on the screen, and their > >>>> presentation on my laptop. > >>>> And, I want to > >>>> do this once, not have to fuss with two autonomous systems. > >>>> > >>>> I don't care if I do it through the presentation system or through > >>>> the telepresence system*, but the implication to me is that one > has > >>>> to be the driver, the other driven, and they have to talk to each > >> other. > >>>> > >>>> * My mental image was doing this through the telepresence system > >>>> but thinking about it doing it through the presentation system may > >>>> have some advantages, for example in authentication. > >>>> > >>>>> > >>>>> I think its reasonable to expect that some but not all of the > >>>>> participants in the room(s) will have a computer connected into > >>>>> the > >> webex-like session. > >>>> > >>>> Maybe. In lots of IETF meetings (to give one example) being in the > >>>> webex session is close to being essential. > >>>> > >>>>> Those that don't will still want to see the presentation. > >>>> > >>>> That's a different but related use case, as is the use case where > I > >>>> am at the train station, have audio and webex, but no > telepresence. > >>>> "It would be nice" to have the webex display something of the > >>>> telepresence session, assuming I have the bandwidth. > >>>> > >>>>> > >>>>> I can see how the people with computers could use those as > >>>>> supplemental displays, so that they could see more captures than > >> are > >>>>> available in the room as a whole. Presumably they wouldn't bother > >> to > >>>>> locally display a capture that is already being displayed on a > >>>>> room > >> screen. > >>>> > >>>> This is interesting but not the use case I had in mind. > >>>> > >>>> Regards > >>>> Marshall > >>>> > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>> > >>>>>> After a while, person Y starts displaying viewgraphs from their > >>>>>> computer (i.e., they are now the presenter). > >>>>>> > >>>>>> I want the presenter screen to switch to showing person Y. > >>>>>> > >>>>>> Right now, all of this would be manual and very cumbersome to > do, > >>>>>> and yet I think it is an option people would want. > >>>>>> > >>>>>> Is publishing an XML scheme for describing this enough ? Could > >>>>>> the telepresence system join the computer sharing session? > >>>>>> Or can the computer sharing session join the telepresence as a > >>>>>> participant, albeit a non-media producing or consuming > >> participant? > >>>>> > >>>>> > >>>>> I think either of these is *possible*, without any explicit > >>>>> support > >> for it. > >>>>> But the coordination to do so could be cumbersome. We need to > >> figure > >>>>> out if there is some mechanism we need to specify to make this > >> convenient. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>> > >>>>>> Regards > >>>>>> Marshall > >>>>>> > >>>>>> On Mon, Apr 30, 2012 at 12:56 PM, Paul > >> Kyzivat > >>>>>> wrote: > >>>>>>> > >>>>>>> On 4/28/12 1:18 PM, Stephen Botzko wrote: > >>>>>>> > >>>>>>>> [sb] As I mentioned above, the existing solutions usually > >> include > >>>>>>>> a screen-scrape application, so you don't have to use a video > >>>>>>>> cable. This is essentially the same as using Webex for > >> presenting > >>>>>>>> (but not remote control). > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> How are these solutions connected? Does the captured > application > >>>>>>> data go to the local room controller, or to an MCU in the > middle > >>>>>>> of the TP session? > >>>>>>> Or > >>>>>>> something else? > >>>>>>> > >>>>>>> > >>>>>>>> Also, even though Webex allows remote control, in my > experience > >>>>>>>> that feature is not used as much as simple presenting. I am > >>>>>>>> not saying it has no value, just that the most common case I > >>>>>>>> see is > >> a > >>>>>>>> simple presentation. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> That is my experience as well. I wasn't thinking about the > >>>>>>> multi-user-control aspect. > >>>>>>> > >>>>>>> > >>>>>>>> Supporting the video cable still has value, especially if you > >>>>>>>> have guest presenter who does not have access to your local > >>>>>>>> network. Most of those presenters are expecting to use a > >>>>>>>> projector, so they have the cables with them. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Surely. In this case, I presume the cable connects to the local > >>>>>>> room controller. If there are multiple cable connectors (e.g. > >>>>>>> one at each > >>>>>>> seat) > >>>>>>> do they show up as multiple presentation streams? Or is there > >> some > >>>>>>> sort of switch and floor control? If so, how does one manage > the > >>>>>>> floor control? > >>>>>>> > >>>>>>> > >>>>>>>> My answer on application sharing falling "out of favor" > related > >>>>>>>> specifically to vendor support for standards-based application > >>>>>>>> sharing > >>>>>>>> (T.120 in particular) - which I thought was responsive to your > >>>>>>>> original question. Perhaps I misunderstood it. Anyway there > >>>>>>>> were several reasons [and perhaps various viewpoints] on why > >>>>>>>> T.120 was dropped, though I think it is probably not a useful > >>>>>>>> discussion for this list. I know of no other standards-based > >> protocol for application sharing. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I wasn't assuming there was, other than a pure video (and maybe > >>>>>>> audio) stream interface. There are other fora for that sort of > >>>>>>> thing, but its my impression that this is largely a world of > >>>>>>> proprietary and defacto standards. > >>>>>>> > >>>>>>> > >>>>>>>> BTW, it is relatively common for web screen sharing to co- > exist > >>>>>>>> with the videoconferencing presentation methods. For > instance, > >>>>>>>> you can have a stand-alone webex conference, with someone > >> sharing > >>>>>>>> their laptop screen for the video participants.[/sb] > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I have done this. But it was cumbersome. IIRC, getting the > >> sharing > >>>>>>> to be visible in the room I was in required using a video cable > >> in > >>>>>>> addition to using webex sharing. > >>>>>>> > >>>>>>> > >>>>>>>> Of course that is still somewhat cumbersome, but > >>>>>>>> presumably > >> it will > >>>>>>>> be improved over time. Its the UI for driving it that is > >> cumbersome, > >>>>>>>> not the output. > >>>>>>>> > >>>>>>>> A key difference is that if the computer output is via > >>>>>>>> video > >> cable > >>>>>>>> into the local room controller, then that is probably > >> responsible > >>>>>>>> for displaying it locally on a display in the room as > well > >> as > >>>>>>>> sending it to the remote end. If the users connect their > >> computers > >>>>>>>> directly to the MCU, then the capture will come to the > >>>>>>>> room > >> just > >>>>>>>> like anything else from the MCU. > >>>>>>>> > >>>>>>>> [sb]The standard model for videoconferencing presentations is > a > >>>>>>>> token-controlled transmission. If you don't have the token, > >>>>>>>> you are receiving. The local equipment is always responsible > >>>>>>>> for > >> display. > >>>>>>>> Looping the presentation back through the MCU back to the > >>>>>>>> originating site wastes bandwidth. > >>>>>>>> > >>>>>>>> I don't know if web conferencing solutions do this differently > >> or not. > >>>>>>>> I've always assumed that when I grab the webex "ball" I stop > >>>>>>>> receiving desktop images. Certainly there is no reason for > the > >>>>>>>> server to send them back to me.[/sb] > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> _______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>> > >>>>>> > >>>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > >