From ron.even.tlv@gmail.com Wed Feb 1 02:34: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 900F121F8608 for ; Wed, 1 Feb 2012 02:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 Ecxsivb97sjM for ; Wed, 1 Feb 2012 02:34:16 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46A2321F8601 for ; Wed, 1 Feb 2012 02:34:16 -0800 (PST) Received: by eekc41 with SMTP id c41so255582eek.31 for ; Wed, 01 Feb 2012 02:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=n1uhRraUb6oQgy2CZa0Autsa/Asbakk0/R6g0iGfNNo=; b=V+xxPdSSs1ndrkPztBhNoNJpd+OMMiQyToSZADdlPYGwyegs2bffTo/MSR/FAIWLGh IhHwspjD2SFlxtjsWYxFr3V3myUd8iPmP4mC1KFF2c2ueUyj3FaWFWVXdaJeS+duKx2q BajcgqbHTzTGe6/k+fKfSdkOjx9K6LQyplpew= Received: by 10.14.52.17 with SMTP id d17mr2282470eec.56.1328092455067; Wed, 01 Feb 2012 02:34:15 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id x4sm97545524eeb.4.2012.02.01.02.34.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Feb 2012 02:34:13 -0800 (PST) From: "Roni Even" To: "'Espen Berger \(espeberg\)'" , References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org> <4f266f4c.d0770e0a.43c6.37fd@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com> <4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com> <4f272344.03bd0e0a.6983.3d7e@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com> Date: Wed, 1 Feb 2012 12:30:17 +0200 Message-ID: <4f291525.84310e0a.69d7.fffffd3b@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: AczaIHX5kbsR/L8BTXmfYvH+6pZxUwFEZeZQAAYsrwAABFxPgAABDkxwABCDGPAAIryQAAAnrpxA Content-Language: en-us 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, 01 Feb 2012 10:34:17 -0000 Hi Espen, I called site or segment switch a policy but I am not sure that it is a = switch policy by itself since segment switch for example can happen = based on active speakers or some round robin timing which is the = switching policy. Roni > -----Original Message----- > From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > Sent: Tuesday, January 31, 2012 5:38 PM > To: Roni Even; clue@ietf.org > Subject: RE: [clue] #7: Is composed attribute a boolean or data > structure >=20 > Hi Rony >=20 > To choose between site and segment switch is more a policy than a > , so in that case I would argue that you could offer a > Capture stream with a switch-policy =3D {site, segment} >=20 > My point about interoperability is that a single composed stream with > alternative layouts are easier to understand, than multiple capture > streams with alternative configurations. The last requires to pick the > first one or requires some sort of default marking. >=20 > Cheers >=20 > -Espen >=20 >=20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: 31. januar 2012 00:06 > To: Espen Berger (espeberg); clue@ietf.org > Subject: RE: [clue] #7: Is composed attribute a boolean or data > structure >=20 > Hi Espen, > If the provider wants to offer site switch and segment switch option = to > the consumer he cannot do it just with A. this is a basic use case. >=20 > In general, your option does not provide any interoperability since > both sides may have different views what composed means. In the > framework example of a PIP as composed image it is an assumption that > if the provider offers this composed offer, the consumer can = understand > that it is a PIP mix but there is nothing in the offer that will > indicate that it is. >=20 > Roni >=20 > > -----Original Message----- > > From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > > Sent: Monday, January 30, 2012 5:21 PM > > To: Roni Even; clue@ietf.org > > Subject: RE: [clue] #7: Is composed attribute a boolean or data > > structure > > > > Hi Roni > > > > If you=E2=80=99re a particular use cases requires control over the = composed > > layouts you need a) and b). In my example I used a single > > advertisement composed stream with optional meta-information about > > possible layout choices. A receiver that wants the default composed > > layout can request the composed stream and skip the optional video- > layout information. > > Optionally you could request the same composed stream with layouts > > hints for the receiver. > > > > For me use case c) does not include the selection mechanisms, only > the > > content you see in the video stream. > > > > Cheers > > > > -Espen > > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: 30. januar 2012 15:39 > > To: Espen Berger (espeberg); clue@ietf.org > > Subject: RE: [clue] #7: Is composed attribute a boolean or data > > structure > > > > Hi Espen, > > If you will look at the notes from the last call there was a support > > that a) is not enough. Having just compose does not address even the > > use cases I provided which are also based on the use case draft. > > > > > > I am not sure what you mean by C since what in the composed stream > can > > be either which VC you see or what is the selection criteria for > being > > in a composed stream. If you meant the second, my view is that C and > > also b should be in the basic framework and not in an extension. > > > > Roni Even > > > > > -----Original Message----- > > > From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > > > Sent: Monday, January 30, 2012 4:17 PM > > > To: Roni Even; clue@ietf.org > > > Subject: RE: [clue] #7: Is composed attribute a boolean or data > > > structure > > > > > > > > > To help with the direction of the discussions I think it's useful > to > > > divide the discussions into three use cases for composed streams. > > > a) How to express if a capture stream is composed or not > > > b) How to express layout choices? (e.g. with a video-layout > > > element) > > > c) How to express what's inside a composed stream > > > > > > For use case a) a composed attribute should be sufficient, you > > > either ask for the composed stream or you do not. > > > I also believe this should cover the interoperability requirement > we > > > have across multiple types of endpoints. > > > > > > For use case b) both mediactrl and xcon uses a > > > element to describe possible layouts and also to request the > > > preferred layout based on options. (as described in Roni's email) > > > > > > An example could be (inspired by mediactrl and xcon usage of > > > layout>): > > > > > > CLUE Advertisement > > > Capture id=3D2 Purpose=3Dpeople Composed=3Dfalse > > > Capture id=3D3 Purpose=3Dpeople Composed=3Dfalse > > > Capture id=3D4 Purpose=3DPeople Composed=3Dtrue > > > Video-layout=3D"'automatic', 'dual-view', ' single-view'" > > > > > > CLUE configure // Default composed stream > > > Capture id=3D4 > > > > > > // Or composed stream with layout hints > > > Capture id=3D4 Video-layout=3D'dual-view' > > > > > > The video-layout element is a list of strings and each string is a > > > layout-hint that can be requested. Video-layout is optional. A > > > layout hints about the requested rendering and the source is free > to > > > replace any stream as long as they fit the layout. > > > > > > Use case c) is more open in the sense that what you actually > receive > > > in a composed stream is depending on status of a room or who is in > a > > > MCU conference. E.g. from a room you could get a mix of different > > > capture stream representing cameras and from a transcoding MCU it > > > could be different room, different cameras or another mix of > > > possible input video streams. > > > > > > Having support for both b) and c) could be a good test for the > > > extensibility of CLUE. If the basis of CLUE only does use case a) > > > there should be room to extend CLUE with support for b) and c) as = a > > > CLUE + layout description extension. > > > > > > Cheers > > > > > > -Espen > > > > > > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > > Of Roni Even > > > Sent: 30. januar 2012 11:18 > > > To: clue@ietf.org > > > Subject: Re: [clue] #7: Is composed attribute a boolean or data > > > structure > > > > > > Hi, > > > During the last call I volunteered to provide some input. > > > > > > In current IETF work (XCON, Mediactrl WGs there is a video layout > > > element) > > > > > > http://tools.ietf.org/html/draft-ietf-mediactrl-mixer-control- > > package- > > > 14#section-4.2.1.4.2.1 > > > > > > and > > > http://tools.ietf.org/html/draft-ietf-xcon-common-data-model- > > > 32#section-4.2.7 (look at video-layout) > > > > > > I would like first to try to define the term "composed video" = since > > it > > > looks to me like we have different views here, and provide my > > > initial view on what should be described. > > > > > > Composed video can describes both the layout and the selection > > > algorithm for composing the content of the sub-windows in the > > "mixed" > > > video. > > > > > > The video layout which just describes the geometry of the composed > > > image and I think that the above references provide good structure > > > to define this part of the composed video attribute. > > > > > > The other part is the algorithm by which the provider select the > > > content of each element in the layout. Since the content of each > > > element may change dynamically by the provider this attribute only > > > address the static information which is the algorithm and not the > > > current content (who we see now in each element) which will need = to > > be > > > conveyed also but probably not using this attribute. Note that the > > > information is valid for point to point and multipoint so the > > > current content should reflect the TP end point and the specific = VC > > > used from it. > > > > > > The algorithms may be global or per element(or sub-window). The > > global > > > algorithms I see are site switch or segment switch. The per = element > > > may be voice activated, round robin (switch every x seconds) and > > fixed > > > (the same VC is displayed there (may be changed by some control > > > mechanism) > > > > > > > > > Roni > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > > > Of clue issue tracker > > > > Sent: Tuesday, January 24, 2012 12:43 AM > > > > To: draft-ietf-clue-framework@tools.ietf.org; > > > > mary.ietf.barnes@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@=E2=80=A6): > > > > > > > > * type: defect =3D> task > > > > > > > > > > > > -- > > > > = --------------------------------+-------------------------------- > - > > > > --------------------------------+- > > - > > > > --------------------------------+- > > > - > > > > --------------------------------+- > > > > ---- > > > > Reporter: mary.ietf.barnes@=E2=80=A6 | Owner: = draft-ietf-clue- > > > > framework@=E2=80=A6 > > > > Type: task | Status: new > > > > Priority: major | Milestone: > > > > Component: framework | Version: > > > > Severity: Active WG Document | Resolution: > > > > Keywords: | > > > > = --------------------------------+-------------------------------- > - > > > > --------------------------------+- > > - > > > > --------------------------------+- > > > - > > > > --------------------------------+- > > > > ---- > > > > > > > > Ticket URL: > > > > > > > > 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 From espeberg@cisco.com Wed Feb 1 05:00: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 CC21821F863D for ; Wed, 1 Feb 2012 05:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, 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 8EyWrXO+brkr for ; Wed, 1 Feb 2012 05:00:04 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B059721F8635 for ; Wed, 1 Feb 2012 05:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=15322; q=dns/txt; s=iport; t=1328101203; x=1329310803; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=sSQFg4EJxQ1vAwJLNsLFTS0ozOZpPlbjx4Hoff+rTTg=; b=gSJ5e/mfrN3s7msQ3WedKmOuawy6OqUHU+6qF1S0Nw2Jmg8lnfyTPTxn OssrivN6bB158dcS5LUT+V1uk3O8jpM18QYv4OkU3TAqp/Lbl/3WiYUib qfiw3BKg9cEhq7cP6KA4/hC8DT+/oz3yr2XVK55KghbyT0qHp3R5klBrp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFABs2KU+Q/khL/2dsb2JhbABDhQupAHCBBYFyAQEBBAEBAQ8BEA0ENAYXBAIBCA4DBAEBAwIGBhcBAgICAQEfBh8JCAIEARIIGodjmjIBjGWRdoEvhkGDNg0BKQYBLQwChDINAgoCgiczYwSgKIdO X-IronPort-AV: E=Sophos;i="4.71,601,1320624000"; d="scan'208";a="65134555" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Feb 2012 13:00:02 +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 q11D02jI024517; Wed, 1 Feb 2012 13:00:02 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); Wed, 1 Feb 2012 14:00:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 1 Feb 2012 14:00:01 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com> In-Reply-To: <4f291525.84310e0a.69d7.fffffd3b@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: AczaIHX5kbsR/L8BTXmfYvH+6pZxUwFEZeZQAAYsrwAABFxPgAABDkxwABCDGPAAIryQAAAnrpxAAAUmzlA= References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org> <4f266f4c.d0770e0a.43c6.37fd@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com> <4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com> <4f272344.03bd0e0a.6983.3d7e@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com> <4f291525.84310e0a.69d7.fffffd3b@mx.google.com> From: "Espen Berger (espeberg)" To: "Roni Even" , X-OriginalArrivalTime: 01 Feb 2012 13:00:02.0378 (UTC) FILETIME=[692DE2A0:01CCE0E1] 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, 01 Feb 2012 13:00:05 -0000 SSB3b3VsZCBzdGlsbCBjYWxsIGl0IHN3aXRjaC1wb2xpY3ksIGUuZy4gdGhlbiBwb3NzaWJsZSB2 YWx1ZXMgY291bGQgYmU6IA0KKiBTaXRlOiBDaGFuZ2UgYWxsIGF0IHRoZSBzYW1lIHRpbWUgDQoq IFNlZ21lbnQ6IE9ubHkgY2hhbmdlIHRoZSBhY3RpdmUgc2VnbWVudCANCiogUm91bmQgcm9iaW46 IENoYW5nZSBhY3RpdmUgc2VnbWVudCBhbmQgdGhlbiBjaGFuZ2UgdG8gb3RoZXIgc2VnbWVudHMg aW4gMTAgc2VjIGludGVydmFscy4gDQoNCkhvdyB5b3Ugc3dpdGNoIGJldHdlZW4gc3RyZWFtcyBh bmQgaG93IHlvdSByZW5kZXIgaGFzIGRpZmZlcmVudCByZXF1aXJlbWVudHMgYW5kIHBvbGljaWVz LCBzbyBJIGZpbmQgaXQgdmVyeSB1c2VmdWwgdG8gZGlzY3VzcyB0aGVtIGFzIHR3byBzZXBhcmF0 ZSBpc3N1ZXMgdG8gYXZvaWQgY29uZnVzaW9uLiANCg0KQ2hlZXJzIA0KDQotRXNwZW4gDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvbmkgRXZlbiBbbWFpbHRvOnJvbi5l dmVuLnRsdkBnbWFpbC5jb21dIA0KU2VudDogMS4gZmVicnVhciAyMDEyIDExOjMwDQpUbzogRXNw ZW4gQmVyZ2VyIChlc3BlYmVyZyk7IGNsdWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbY2x1ZV0g Izc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YSBzdHJ1Y3R1cmUNCg0K SGkgRXNwZW4sDQpJIGNhbGxlZCBzaXRlIG9yIHNlZ21lbnQgc3dpdGNoIGEgcG9saWN5IGJ1dCBJ IGFtIG5vdCBzdXJlIHRoYXQgaXQgaXMgYSBzd2l0Y2ggcG9saWN5IGJ5IGl0c2VsZiBzaW5jZSBz ZWdtZW50IHN3aXRjaCBmb3IgZXhhbXBsZSBjYW4gaGFwcGVuIGJhc2VkIG9uIGFjdGl2ZSBzcGVh a2VycyBvciBzb21lIHJvdW5kIHJvYmluIHRpbWluZyB3aGljaCBpcyB0aGUgc3dpdGNoaW5nIHBv bGljeS4NClJvbmkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFc3Bl biBCZXJnZXIgKGVzcGViZXJnKSBbbWFpbHRvOmVzcGViZXJnQGNpc2NvLmNvbV0NCj4gU2VudDog VHVlc2RheSwgSmFudWFyeSAzMSwgMjAxMiA1OjM4IFBNDQo+IFRvOiBSb25pIEV2ZW47IGNsdWVA aWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRl IGEgYm9vbGVhbiBvciBkYXRhDQo+IHN0cnVjdHVyZQ0KPiANCj4gSGkgUm9ueQ0KPiANCj4gVG8g Y2hvb3NlIGJldHdlZW4gc2l0ZSBhbmQgc2VnbWVudCBzd2l0Y2ggaXMgbW9yZSBhIHBvbGljeSB0 aGFuIGENCj4gPHZpZGVvLWxheW91dD4sIHNvIGluIHRoYXQgY2FzZSBJIHdvdWxkIGFyZ3VlIHRo YXQgeW91IGNvdWxkIG9mZmVyIGENCj4gQ2FwdHVyZSBzdHJlYW0gd2l0aCBhIHN3aXRjaC1wb2xp Y3kgPSB7c2l0ZSwgc2VnbWVudH0NCj4gDQo+IE15IHBvaW50IGFib3V0IGludGVyb3BlcmFiaWxp dHkgaXMgdGhhdCBhIHNpbmdsZSBjb21wb3NlZCBzdHJlYW0gd2l0aA0KPiBhbHRlcm5hdGl2ZSBs YXlvdXRzIGFyZSBlYXNpZXIgdG8gdW5kZXJzdGFuZCwgdGhhbiBtdWx0aXBsZSBjYXB0dXJlDQo+ IHN0cmVhbXMgd2l0aCBhbHRlcm5hdGl2ZSBjb25maWd1cmF0aW9ucy4gVGhlIGxhc3QgcmVxdWly ZXMgdG8gcGljayB0aGUNCj4gZmlyc3Qgb25lIG9yIHJlcXVpcmVzIHNvbWUgc29ydCBvZiBkZWZh dWx0IG1hcmtpbmcuDQo+IA0KPiBDaGVlcnMNCj4gDQo+IC1Fc3Blbg0KPiANCj4gDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvbmkgRXZlbiBbbWFpbHRvOnJvbi5ldmVu LnRsdkBnbWFpbC5jb21dDQo+IFNlbnQ6IDMxLiBqYW51YXIgMjAxMiAwMDowNg0KPiBUbzogRXNw ZW4gQmVyZ2VyIChlc3BlYmVyZyk7IGNsdWVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtjbHVl XSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhDQo+IHN0cnVjdHVy ZQ0KPiANCj4gSGkgRXNwZW4sDQo+IElmIHRoZSBwcm92aWRlciB3YW50cyB0byBvZmZlciBzaXRl IHN3aXRjaCBhbmQgc2VnbWVudCBzd2l0Y2ggb3B0aW9uIHRvDQo+IHRoZSBjb25zdW1lciBoZSBj YW5ub3QgZG8gaXQganVzdCB3aXRoIEEuIHRoaXMgaXMgYSBiYXNpYyB1c2UgY2FzZS4NCj4gDQo+ IEluIGdlbmVyYWwsIHlvdXIgb3B0aW9uIGRvZXMgbm90IHByb3ZpZGUgYW55IGludGVyb3BlcmFi aWxpdHkgc2luY2UNCj4gYm90aCBzaWRlcyBtYXkgaGF2ZSBkaWZmZXJlbnQgdmlld3Mgd2hhdCBj b21wb3NlZCBtZWFucy4gSW4gdGhlDQo+IGZyYW1ld29yayBleGFtcGxlIG9mIGEgUElQIGFzIGNv bXBvc2VkIGltYWdlIGl0IGlzIGFuIGFzc3VtcHRpb24gdGhhdA0KPiBpZiB0aGUgcHJvdmlkZXIg b2ZmZXJzIHRoaXMgY29tcG9zZWQgb2ZmZXIsIHRoZSBjb25zdW1lciBjYW4gdW5kZXJzdGFuZA0K PiB0aGF0IGl0IGlzIGEgUElQIG1peCBidXQgdGhlcmUgaXMgbm90aGluZyBpbiB0aGUgb2ZmZXIg dGhhdCB3aWxsDQo+IGluZGljYXRlIHRoYXQgaXQgaXMuDQo+IA0KPiBSb25pDQo+IA0KPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogRXNwZW4gQmVyZ2VyIChlc3BlYmVy ZykgW21haWx0bzplc3BlYmVyZ0BjaXNjby5jb21dDQo+ID4gU2VudDogTW9uZGF5LCBKYW51YXJ5 IDMwLCAyMDEyIDU6MjEgUE0NCj4gPiBUbzogUm9uaSBFdmVuOyBjbHVlQGlldGYub3JnDQo+ID4g U3ViamVjdDogUkU6IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBv ciBkYXRhDQo+ID4gc3RydWN0dXJlDQo+ID4NCj4gPiBIaSBSb25pDQo+ID4NCj4gPiBJZiB5b3Xi gJlyZSBhIHBhcnRpY3VsYXIgdXNlIGNhc2VzIHJlcXVpcmVzIGNvbnRyb2wgb3ZlciB0aGUgY29t cG9zZWQNCj4gPiBsYXlvdXRzIHlvdSBuZWVkIGEpIGFuZCBiKS4gSW4gbXkgZXhhbXBsZSBJIHVz ZWQgYSBzaW5nbGUNCj4gPiBhZHZlcnRpc2VtZW50IGNvbXBvc2VkIHN0cmVhbSB3aXRoIG9wdGlv bmFsIG1ldGEtaW5mb3JtYXRpb24gYWJvdXQNCj4gPiBwb3NzaWJsZSBsYXlvdXQgY2hvaWNlcy4g QSByZWNlaXZlciB0aGF0IHdhbnRzIHRoZSBkZWZhdWx0IGNvbXBvc2VkDQo+ID4gbGF5b3V0IGNh biByZXF1ZXN0IHRoZSBjb21wb3NlZCBzdHJlYW0gYW5kIHNraXAgdGhlIG9wdGlvbmFsIHZpZGVv LQ0KPiBsYXlvdXQgaW5mb3JtYXRpb24uDQo+ID4gT3B0aW9uYWxseSB5b3UgY291bGQgcmVxdWVz dCB0aGUgc2FtZSBjb21wb3NlZCBzdHJlYW0gd2l0aCBsYXlvdXRzDQo+ID4gaGludHMgZm9yIHRo ZSByZWNlaXZlci4NCj4gPg0KPiA+IEZvciBtZSB1c2UgY2FzZSBjKSBkb2VzIG5vdCBpbmNsdWRl IHRoZSBzZWxlY3Rpb24gbWVjaGFuaXNtcywgb25seQ0KPiB0aGUNCj4gPiBjb250ZW50IHlvdSBz ZWUgaW4gdGhlIHZpZGVvIHN0cmVhbS4NCj4gPg0KPiA+IENoZWVycw0KPiA+DQo+ID4gLUVzcGVu DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFJvbmkgRXZl biBbbWFpbHRvOnJvbi5ldmVuLnRsdkBnbWFpbC5jb21dDQo+ID4gU2VudDogMzAuIGphbnVhciAy MDEyIDE1OjM5DQo+ID4gVG86IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpOyBjbHVlQGlldGYub3Jn DQo+ID4gU3ViamVjdDogUkU6IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9v bGVhbiBvciBkYXRhDQo+ID4gc3RydWN0dXJlDQo+ID4NCj4gPiBIaSBFc3BlbiwNCj4gPiBJZiB5 b3Ugd2lsbCBsb29rIGF0IHRoZSBub3RlcyBmcm9tIHRoZSBsYXN0IGNhbGwgdGhlcmUgd2FzIGEg c3VwcG9ydA0KPiA+IHRoYXQgYSkgaXMgbm90IGVub3VnaC4gSGF2aW5nIGp1c3QgY29tcG9zZSBk b2VzIG5vdCBhZGRyZXNzIGV2ZW4gdGhlDQo+ID4gdXNlIGNhc2VzIEkgcHJvdmlkZWQgd2hpY2gg YXJlIGFsc28gYmFzZWQgb24gdGhlIHVzZSBjYXNlIGRyYWZ0Lg0KPiA+DQo+ID4NCj4gPiBJIGFt IG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgQyBzaW5jZSB3aGF0IGluIHRoZSBjb21wb3NlZCBz dHJlYW0NCj4gY2FuDQo+ID4gYmUgZWl0aGVyIHdoaWNoIFZDIHlvdSBzZWUgb3Igd2hhdCBpcyB0 aGUgc2VsZWN0aW9uIGNyaXRlcmlhIGZvcg0KPiBiZWluZw0KPiA+IGluIGEgY29tcG9zZWQgc3Ry ZWFtLiBJZiB5b3UgbWVhbnQgdGhlIHNlY29uZCwgbXkgdmlldyBpcyB0aGF0IEMgYW5kDQo+ID4g YWxzbyBiIHNob3VsZCBiZSBpbiB0aGUgYmFzaWMgZnJhbWV3b3JrIGFuZCBub3QgaW4gYW4gZXh0 ZW5zaW9uLg0KPiA+DQo+ID4gUm9uaSBFdmVuDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBFc3BlbiBCZXJnZXIgKGVzcGViZXJnKSBbbWFpbHRvOmVz cGViZXJnQGNpc2NvLmNvbV0NCj4gPiA+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAzMCwgMjAxMiA0 OjE3IFBNDQo+ID4gPiBUbzogUm9uaSBFdmVuOyBjbHVlQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0 OiBSRTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGEN Cj4gPiA+IHN0cnVjdHVyZQ0KPiA+ID4NCj4gPiA+DQo+ID4gPiBUbyBoZWxwIHdpdGggdGhlIGRp cmVjdGlvbiBvZiB0aGUgZGlzY3Vzc2lvbnMgSSB0aGluayBpdCdzIHVzZWZ1bA0KPiB0bw0KPiA+ ID4gZGl2aWRlIHRoZSBkaXNjdXNzaW9ucyBpbnRvIHRocmVlIHVzZSBjYXNlcyBmb3IgY29tcG9z ZWQgc3RyZWFtcy4NCj4gPiA+ICBhKSBIb3cgdG8gZXhwcmVzcyBpZiBhIGNhcHR1cmUgc3RyZWFt IGlzIGNvbXBvc2VkIG9yIG5vdA0KPiA+ID4gIGIpIEhvdyB0byBleHByZXNzIGxheW91dCBjaG9p Y2VzPyAoZS5nLiB3aXRoIGEgdmlkZW8tbGF5b3V0DQo+ID4gPiBlbGVtZW50KQ0KPiA+ID4gIGMp IEhvdyB0byBleHByZXNzIHdoYXQncyBpbnNpZGUgYSBjb21wb3NlZCBzdHJlYW0NCj4gPiA+DQo+ ID4gPiBGb3IgdXNlIGNhc2UgYSkgYSBjb21wb3NlZCBhdHRyaWJ1dGUgc2hvdWxkIGJlIHN1ZmZp Y2llbnQsIHlvdQ0KPiA+ID4gZWl0aGVyIGFzayBmb3IgdGhlIGNvbXBvc2VkIHN0cmVhbSBvciB5 b3UgZG8gbm90Lg0KPiA+ID4gSSBhbHNvIGJlbGlldmUgdGhpcyBzaG91bGQgY292ZXIgdGhlIGlu dGVyb3BlcmFiaWxpdHkgcmVxdWlyZW1lbnQNCj4gd2UNCj4gPiA+IGhhdmUgYWNyb3NzIG11bHRp cGxlIHR5cGVzIG9mIGVuZHBvaW50cy4NCj4gPiA+DQo+ID4gPiBGb3IgdXNlIGNhc2UgYikgYm90 aCBtZWRpYWN0cmwgYW5kIHhjb24gdXNlcyBhIDx2aWRlby1sYXlvdXQ+DQo+ID4gPiBlbGVtZW50 IHRvIGRlc2NyaWJlIHBvc3NpYmxlIGxheW91dHMgYW5kIGFsc28gdG8gcmVxdWVzdCB0aGUNCj4g PiA+IHByZWZlcnJlZCBsYXlvdXQgYmFzZWQgb24gb3B0aW9ucy4gKGFzIGRlc2NyaWJlZCBpbiBS b25pJ3MgZW1haWwpDQo+ID4gPg0KPiA+ID4gQW4gZXhhbXBsZSBjb3VsZCBiZSAoaW5zcGlyZWQg YnkgbWVkaWFjdHJsIGFuZCB4Y29uIHVzYWdlIG9mDQo+IDx2aWRlby0NCj4gPiA+IGxheW91dD4p Og0KPiA+ID4NCj4gPiA+IENMVUUgQWR2ZXJ0aXNlbWVudA0KPiA+ID4gICBDYXB0dXJlIGlkPTIg UHVycG9zZT1wZW9wbGUgQ29tcG9zZWQ9ZmFsc2UNCj4gPiA+ICAgQ2FwdHVyZSBpZD0zIFB1cnBv c2U9cGVvcGxlIENvbXBvc2VkPWZhbHNlDQo+ID4gPiAgIENhcHR1cmUgaWQ9NCBQdXJwb3NlPVBl b3BsZSBDb21wb3NlZD10cnVlDQo+ID4gPiAgICAgICBWaWRlby1sYXlvdXQ9IidhdXRvbWF0aWMn LCAnZHVhbC12aWV3JywgJyBzaW5nbGUtdmlldyciDQo+ID4gPg0KPiA+ID4gQ0xVRSBjb25maWd1 cmUgLy8gRGVmYXVsdCBjb21wb3NlZCBzdHJlYW0NCj4gPiA+ICAgQ2FwdHVyZSBpZD00DQo+ID4g Pg0KPiA+ID4gLy8gT3IgY29tcG9zZWQgc3RyZWFtIHdpdGggbGF5b3V0IGhpbnRzDQo+ID4gPiAg ICBDYXB0dXJlIGlkPTQgVmlkZW8tbGF5b3V0PSdkdWFsLXZpZXcnDQo+ID4gPg0KPiA+ID4gVGhl IHZpZGVvLWxheW91dCBlbGVtZW50IGlzIGEgbGlzdCBvZiBzdHJpbmdzIGFuZCBlYWNoIHN0cmlu ZyBpcyBhDQo+ID4gPiBsYXlvdXQtaGludCB0aGF0IGNhbiBiZSByZXF1ZXN0ZWQuIFZpZGVvLWxh eW91dCBpcyBvcHRpb25hbC4gQQ0KPiA+ID4gbGF5b3V0IGhpbnRzIGFib3V0IHRoZSByZXF1ZXN0 ZWQgcmVuZGVyaW5nIGFuZCB0aGUgc291cmNlIGlzIGZyZWUNCj4gdG8NCj4gPiA+IHJlcGxhY2Ug YW55IHN0cmVhbSBhcyBsb25nIGFzIHRoZXkgZml0IHRoZSBsYXlvdXQuDQo+ID4gPg0KPiA+ID4g VXNlIGNhc2UgYykgaXMgbW9yZSBvcGVuIGluIHRoZSBzZW5zZSB0aGF0IHdoYXQgeW91IGFjdHVh bGx5DQo+IHJlY2VpdmUNCj4gPiA+IGluIGEgY29tcG9zZWQgc3RyZWFtIGlzIGRlcGVuZGluZyBv biBzdGF0dXMgb2YgYSByb29tIG9yIHdobyBpcyBpbg0KPiBhDQo+ID4gPiBNQ1UgY29uZmVyZW5j ZS4gRS5nLiBmcm9tIGEgcm9vbSB5b3UgY291bGQgZ2V0IGEgbWl4IG9mIGRpZmZlcmVudA0KPiA+ ID4gY2FwdHVyZSBzdHJlYW0gcmVwcmVzZW50aW5nIGNhbWVyYXMgYW5kIGZyb20gYSB0cmFuc2Nv ZGluZyBNQ1UgaXQNCj4gPiA+IGNvdWxkIGJlIGRpZmZlcmVudCByb29tLCBkaWZmZXJlbnQgY2Ft ZXJhcyBvciBhbm90aGVyIG1peCBvZg0KPiA+ID4gcG9zc2libGUgaW5wdXQgdmlkZW8gc3RyZWFt cy4NCj4gPiA+DQo+ID4gPiBIYXZpbmcgc3VwcG9ydCBmb3IgYm90aCBiKSBhbmQgYykgY291bGQg YmUgYSBnb29kIHRlc3QgZm9yIHRoZQ0KPiA+ID4gZXh0ZW5zaWJpbGl0eSBvZiBDTFVFLiBJZiB0 aGUgYmFzaXMgb2YgQ0xVRSBvbmx5IGRvZXMgdXNlIGNhc2UgYSkNCj4gPiA+IHRoZXJlIHNob3Vs ZCBiZSByb29tIHRvIGV4dGVuZCBDTFVFIHdpdGggc3VwcG9ydCBmb3IgYikgYW5kIGMpIGFzIGEN Cj4gPiA+IENMVUUgKyBsYXlvdXQgZGVzY3JpcHRpb24gZXh0ZW5zaW9uLg0KPiA+ID4NCj4gPiA+ IENoZWVycw0KPiA+ID4NCj4gPiA+IC1Fc3Blbg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IGNsdWUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmDQo+ID4gPiBP ZiBSb25pIEV2ZW4NCj4gPiA+IFNlbnQ6IDMwLiBqYW51YXIgMjAxMiAxMToxOA0KPiA+ID4gVG86 IGNsdWVAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2Vk IGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPiA+ID4gc3RydWN0dXJlDQo+ID4gPg0KPiA+ ID4gSGksDQo+ID4gPiBEdXJpbmcgdGhlIGxhc3QgY2FsbCBJIHZvbHVudGVlcmVkIHRvIHByb3Zp ZGUgc29tZSBpbnB1dC4NCj4gPiA+DQo+ID4gPiBJbiBjdXJyZW50IElFVEYgd29yayAoWENPTiwg TWVkaWFjdHJsIFdHcyB0aGVyZSBpcyBhIHZpZGVvIGxheW91dA0KPiA+ID4gZWxlbWVudCkNCj4g PiA+DQo+ID4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1lZGlhY3Ry bC1taXhlci1jb250cm9sLQ0KPiA+IHBhY2thZ2UtDQo+ID4gPiAxNCNzZWN0aW9uLTQuMi4xLjQu Mi4xDQo+ID4gPg0KPiA+ID4gYW5kDQo+ID4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXhjb24tY29tbW9uLWRhdGEtbW9kZWwtDQo+ID4gPiAzMiNzZWN0aW9uLTQuMi43 IChsb29rIGF0IHZpZGVvLWxheW91dCkNCj4gPiA+DQo+ID4gPiBJIHdvdWxkIGxpa2UgZmlyc3Qg dG8gdHJ5IHRvIGRlZmluZSB0aGUgdGVybSAiY29tcG9zZWQgdmlkZW8iIHNpbmNlDQo+ID4gaXQN Cj4gPiA+IGxvb2tzIHRvIG1lIGxpa2Ugd2UgaGF2ZSBkaWZmZXJlbnQgdmlld3MgaGVyZSwgYW5k IHByb3ZpZGUgbXkNCj4gPiA+IGluaXRpYWwgdmlldyBvbiB3aGF0IHNob3VsZCBiZSBkZXNjcmli ZWQuDQo+ID4gPg0KPiA+ID4gQ29tcG9zZWQgdmlkZW8gY2FuIGRlc2NyaWJlcyBib3RoIHRoZSBs YXlvdXQgYW5kIHRoZSBzZWxlY3Rpb24NCj4gPiA+IGFsZ29yaXRobSBmb3IgY29tcG9zaW5nIHRo ZSAgY29udGVudCBvZiB0aGUgc3ViLXdpbmRvd3MgaW4gdGhlDQo+ID4gIm1peGVkIg0KPiA+ID4g dmlkZW8uDQo+ID4gPg0KPiA+ID4gVGhlIHZpZGVvIGxheW91dCB3aGljaCBqdXN0IGRlc2NyaWJl cyB0aGUgZ2VvbWV0cnkgb2YgdGhlIGNvbXBvc2VkDQo+ID4gPiBpbWFnZSBhbmQgSSB0aGluayB0 aGF0IHRoZSBhYm92ZSByZWZlcmVuY2VzIHByb3ZpZGUgZ29vZCBzdHJ1Y3R1cmUNCj4gPiA+IHRv IGRlZmluZSB0aGlzIHBhcnQgb2YgdGhlIGNvbXBvc2VkIHZpZGVvIGF0dHJpYnV0ZS4NCj4gPiA+ DQo+ID4gPiBUaGUgb3RoZXIgcGFydCBpcyB0aGUgYWxnb3JpdGhtIGJ5IHdoaWNoIHRoZSBwcm92 aWRlciBzZWxlY3QgdGhlDQo+ID4gPiBjb250ZW50IG9mIGVhY2ggZWxlbWVudCBpbiB0aGUgbGF5 b3V0LiBTaW5jZSB0aGUgY29udGVudCBvZiBlYWNoDQo+ID4gPiBlbGVtZW50IG1heSBjaGFuZ2Ug ZHluYW1pY2FsbHkgYnkgdGhlIHByb3ZpZGVyIHRoaXMgYXR0cmlidXRlIG9ubHkNCj4gPiA+IGFk ZHJlc3MgdGhlIHN0YXRpYyBpbmZvcm1hdGlvbiB3aGljaCBpcyB0aGUgYWxnb3JpdGhtIGFuZCBu b3QgdGhlDQo+ID4gPiBjdXJyZW50IGNvbnRlbnQgKHdobyB3ZSBzZWUgbm93IGluIGVhY2ggZWxl bWVudCkgd2hpY2ggd2lsbCBuZWVkIHRvDQo+ID4gYmUNCj4gPiA+IGNvbnZleWVkIGFsc28gYnV0 IHByb2JhYmx5IG5vdCB1c2luZyB0aGlzIGF0dHJpYnV0ZS4gTm90ZSB0aGF0IHRoZQ0KPiA+ID4g aW5mb3JtYXRpb24gaXMgdmFsaWQgZm9yIHBvaW50IHRvIHBvaW50IGFuZCBtdWx0aXBvaW50IHNv IHRoZQ0KPiA+ID4gY3VycmVudCBjb250ZW50IHNob3VsZCByZWZsZWN0IHRoZSBUUCBlbmQgcG9p bnQgYW5kIHRoZSBzcGVjaWZpYyBWQw0KPiA+ID4gdXNlZCBmcm9tIGl0Lg0KPiA+ID4NCj4gPiA+ IFRoZSBhbGdvcml0aG1zIG1heSBiZSBnbG9iYWwgb3IgcGVyIGVsZW1lbnQob3Igc3ViLXdpbmRv dykuIFRoZQ0KPiA+IGdsb2JhbA0KPiA+ID4gYWxnb3JpdGhtcyBJIHNlZSBhcmUgc2l0ZSBzd2l0 Y2ggb3Igc2VnbWVudCBzd2l0Y2guIFRoZSBwZXIgZWxlbWVudA0KPiA+ID4gbWF5IGJlIHZvaWNl IGFjdGl2YXRlZCwgcm91bmQgcm9iaW4gKHN3aXRjaCBldmVyeSB4IHNlY29uZHMpIGFuZA0KPiA+ IGZpeGVkDQo+ID4gPiAodGhlIHNhbWUgVkMgaXMgZGlzcGxheWVkIHRoZXJlIChtYXkgYmUgY2hh bmdlZCBieSBzb21lIGNvbnRyb2wNCj4gPiA+IG1lY2hhbmlzbSkNCj4gPiA+DQo+ID4gPg0KPiA+ ID4gUm9uaQ0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ ID4gRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYu b3JnXSBPbg0KPiA+IEJlaGFsZg0KPiA+ID4gPiBPZiBjbHVlIGlzc3VlIHRyYWNrZXINCj4gPiA+ ID4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNCwgMjAxMiAxMjo0MyBBTQ0KPiA+ID4gPiBUbzog ZHJhZnQtaWV0Zi1jbHVlLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZzsNCj4gPiA+ID4gbWFyeS5p ZXRmLmJhcm5lc0BnbWFpbC5jb20NCj4gPiA+ID4gQ2M6IGNsdWVAaWV0Zi5vcmcNCj4gPiA+ID4g U3ViamVjdDogUmU6IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBv ciBkYXRhDQo+ID4gPiA+IHN0cnVjdHVyZQ0KPiA+ID4gPg0KPiA+ID4gPiAjNzogSXMgY29tcG9z ZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhIHN0cnVjdHVyZQ0KPiA+ID4gPg0KPiA+ID4g PiBDaGFuZ2VzIChieSBtYXJ5LmlldGYuYmFybmVzQOKApik6DQo+ID4gPiA+DQo+ID4gPiA+ICAq IHR5cGU6ICBkZWZlY3QgPT4gdGFzaw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAtLQ0KPiA+ ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiAtDQo+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0NCj4gPiAtDQo+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0N Cj4gPiA+IC0NCj4gPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLQ0KPiA+ ID4gPiAtLS0tDQo+ID4gPiA+ICBSZXBvcnRlcjogIG1hcnkuaWV0Zi5iYXJuZXNA4oCmICB8ICAg ICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1jbHVlLQ0KPiA+ID4gPiBmcmFtZXdvcmtA4oCmDQo+ID4g PiA+ICAgICAgVHlwZTogIHRhc2sgICAgICAgICAgICAgICAgfCAgICAgIFN0YXR1czogIG5ldw0K PiA+ID4gPiAgUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6DQo+ ID4gPiA+IENvbXBvbmVudDogIGZyYW1ld29yayAgICAgICAgICAgfCAgICAgVmVyc2lvbjoNCj4g PiA+ID4gIFNldmVyaXR5OiAgQWN0aXZlIFdHIERvY3VtZW50ICB8ICBSZXNvbHV0aW9uOg0KPiA+ ID4gPiAgS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiA+ID4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gLQ0KPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+ID4gLQ0K PiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+ID4gPiAtDQo+ID4g PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0NCj4gPiA+ID4gLS0tLQ0KPiA+ ID4gPg0KPiA+ID4gPiBUaWNrZXQgVVJMOg0KPiA+ID4gPiA8aHR0cDovL3RyYWMudG9vbHMuaWV0 Zi5vcmcvd2cvY2x1ZS90cmFjL3RpY2tldC83I2NvbW1lbnQ6Mj4NCj4gPiA+ID4gY2x1ZSA8aHR0 cDovL3Rvb2xzLmlldGYub3JnL3dnL2NsdWUvPg0KPiA+ID4gPg0KPiA+ID4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiBjbHVlIG1haWxp bmcgbGlzdA0KPiA+ID4gPiBjbHVlQGlldGYub3JnDQo+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBjbHVlIG1haWxpbmcgbGlzdA0K PiA+ID4gY2x1ZUBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jbHVlDQo+IA0KDQoNCg== From pkyzivat@alum.mit.edu Wed Feb 1 09:29: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 DC8D521F8800 for ; Wed, 1 Feb 2012 09:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 1lUgmxHv-mBl for ; Wed, 1 Feb 2012 09:29:23 -0800 (PST) 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 A211521F87FF for ; Wed, 1 Feb 2012 09:29:22 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta09.westchester.pa.mail.comcast.net with comcast id UhSS1i00N16LCl059hVNNb; Wed, 01 Feb 2012 17:29:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta06.westchester.pa.mail.comcast.net with comcast id UhVN1i00E07duvL3ShVNrt; Wed, 01 Feb 2012 17:29:22 +0000 Message-ID: <4F29766F.1080101@alum.mit.edu> Date: Wed, 01 Feb 2012 12:29:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org> <4f266f4c.d0770e0a.43c6.37fd@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com> <4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com> <4f272344.03bd0e0a.6983.3d7e@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com> <4f291525.84310e0a.69d7.fffffd3b@mx.google.com> <92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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, 01 Feb 2012 17:29:24 -0000 Espen, ISTM that for a switched stream you have: - the set of candidate streams to be switched among - an algorithm for picking among them If the receiver has multiple screens, then there will be a stream for each one, and each could have different candidate input streams and a different policy. What you are describing as "site switching" adds another wrinkle, since it is coupling the switching policies for multiple streams. Also, I'm not sure how it works if the sites have differing numbers of screens and cameras. How would you describe the individual streams from the MCU so that a room could select an appropriate set of streams to get site switching? It would be helpful (to me anyway) if you could describe the interesting cases by enumerating the offered streams together with the inputs and the algorithm used for each. Right now, I'm not sure how to do that. Thanks, Paul On 2/1/12 8:00 AM, Espen Berger (espeberg) wrote: > I would still call it switch-policy, e.g. then possible values could be: > * Site: Change all at the same time > * Segment: Only change the active segment > * Round robin: Change active segment and then change to other segments in 10 sec intervals. > > How you switch between streams and how you render has different requirements and policies, so I find it very useful to discuss them as two separate issues to avoid confusion. > > Cheers > > -Espen > > > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: 1. februar 2012 11:30 > To: Espen Berger (espeberg); clue@ietf.org > Subject: RE: [clue] #7: Is composed attribute a boolean or data structure > > Hi Espen, > I called site or segment switch a policy but I am not sure that it is a switch policy by itself since segment switch for example can happen based on active speakers or some round robin timing which is the switching policy. > Roni > >> -----Original Message----- >> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >> Sent: Tuesday, January 31, 2012 5:38 PM >> To: Roni Even; clue@ietf.org >> Subject: RE: [clue] #7: Is composed attribute a boolean or data >> structure >> >> Hi Rony >> >> To choose between site and segment switch is more a policy than a >> , so in that case I would argue that you could offer a >> Capture stream with a switch-policy = {site, segment} >> >> My point about interoperability is that a single composed stream with >> alternative layouts are easier to understand, than multiple capture >> streams with alternative configurations. The last requires to pick the >> first one or requires some sort of default marking. >> >> Cheers >> >> -Espen >> >> >> -----Original Message----- >> From: Roni Even [mailto:ron.even.tlv@gmail.com] >> Sent: 31. januar 2012 00:06 >> To: Espen Berger (espeberg); clue@ietf.org >> Subject: RE: [clue] #7: Is composed attribute a boolean or data >> structure >> >> Hi Espen, >> If the provider wants to offer site switch and segment switch option to >> the consumer he cannot do it just with A. this is a basic use case. >> >> In general, your option does not provide any interoperability since >> both sides may have different views what composed means. In the >> framework example of a PIP as composed image it is an assumption that >> if the provider offers this composed offer, the consumer can understand >> that it is a PIP mix but there is nothing in the offer that will >> indicate that it is. >> >> Roni >> >>> -----Original Message----- >>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>> Sent: Monday, January 30, 2012 5:21 PM >>> To: Roni Even; clue@ietf.org >>> Subject: RE: [clue] #7: Is composed attribute a boolean or data >>> structure >>> >>> Hi Roni >>> >>> If you’re a particular use cases requires control over the composed >>> layouts you need a) and b). In my example I used a single >>> advertisement composed stream with optional meta-information about >>> possible layout choices. A receiver that wants the default composed >>> layout can request the composed stream and skip the optional video- >> layout information. >>> Optionally you could request the same composed stream with layouts >>> hints for the receiver. >>> >>> For me use case c) does not include the selection mechanisms, only >> the >>> content you see in the video stream. >>> >>> Cheers >>> >>> -Espen >>> >>> -----Original Message----- >>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>> Sent: 30. januar 2012 15:39 >>> To: Espen Berger (espeberg); clue@ietf.org >>> Subject: RE: [clue] #7: Is composed attribute a boolean or data >>> structure >>> >>> Hi Espen, >>> If you will look at the notes from the last call there was a support >>> that a) is not enough. Having just compose does not address even the >>> use cases I provided which are also based on the use case draft. >>> >>> >>> I am not sure what you mean by C since what in the composed stream >> can >>> be either which VC you see or what is the selection criteria for >> being >>> in a composed stream. If you meant the second, my view is that C and >>> also b should be in the basic framework and not in an extension. >>> >>> Roni Even >>> >>>> -----Original Message----- >>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>>> Sent: Monday, January 30, 2012 4:17 PM >>>> To: Roni Even; clue@ietf.org >>>> Subject: RE: [clue] #7: Is composed attribute a boolean or data >>>> structure >>>> >>>> >>>> To help with the direction of the discussions I think it's useful >> to >>>> divide the discussions into three use cases for composed streams. >>>> a) How to express if a capture stream is composed or not >>>> b) How to express layout choices? (e.g. with a video-layout >>>> element) >>>> c) How to express what's inside a composed stream >>>> >>>> For use case a) a composed attribute should be sufficient, you >>>> either ask for the composed stream or you do not. >>>> I also believe this should cover the interoperability requirement >> we >>>> have across multiple types of endpoints. >>>> >>>> For use case b) both mediactrl and xcon uses a >>>> element to describe possible layouts and also to request the >>>> preferred layout based on options. (as described in Roni's email) >>>> >>>> An example could be (inspired by mediactrl and xcon usage of >> >>> layout>): >>>> >>>> CLUE Advertisement >>>> Capture id=2 Purpose=people Composed=false >>>> Capture id=3 Purpose=people Composed=false >>>> Capture id=4 Purpose=People Composed=true >>>> Video-layout="'automatic', 'dual-view', ' single-view'" >>>> >>>> CLUE configure // Default composed stream >>>> Capture id=4 >>>> >>>> // Or composed stream with layout hints >>>> Capture id=4 Video-layout='dual-view' >>>> >>>> The video-layout element is a list of strings and each string is a >>>> layout-hint that can be requested. Video-layout is optional. A >>>> layout hints about the requested rendering and the source is free >> to >>>> replace any stream as long as they fit the layout. >>>> >>>> Use case c) is more open in the sense that what you actually >> receive >>>> in a composed stream is depending on status of a room or who is in >> a >>>> MCU conference. E.g. from a room you could get a mix of different >>>> capture stream representing cameras and from a transcoding MCU it >>>> could be different room, different cameras or another mix of >>>> possible input video streams. >>>> >>>> Having support for both b) and c) could be a good test for the >>>> extensibility of CLUE. If the basis of CLUE only does use case a) >>>> there should be room to extend CLUE with support for b) and c) as a >>>> CLUE + layout description extension. >>>> >>>> Cheers >>>> >>>> -Espen >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >> Behalf >>>> Of Roni Even >>>> Sent: 30. januar 2012 11:18 >>>> To: clue@ietf.org >>>> Subject: Re: [clue] #7: Is composed attribute a boolean or data >>>> structure >>>> >>>> Hi, >>>> During the last call I volunteered to provide some input. >>>> >>>> In current IETF work (XCON, Mediactrl WGs there is a video layout >>>> element) >>>> >>>> http://tools.ietf.org/html/draft-ietf-mediactrl-mixer-control- >>> package- >>>> 14#section-4.2.1.4.2.1 >>>> >>>> and >>>> http://tools.ietf.org/html/draft-ietf-xcon-common-data-model- >>>> 32#section-4.2.7 (look at video-layout) >>>> >>>> I would like first to try to define the term "composed video" since >>> it >>>> looks to me like we have different views here, and provide my >>>> initial view on what should be described. >>>> >>>> Composed video can describes both the layout and the selection >>>> algorithm for composing the content of the sub-windows in the >>> "mixed" >>>> video. >>>> >>>> The video layout which just describes the geometry of the composed >>>> image and I think that the above references provide good structure >>>> to define this part of the composed video attribute. >>>> >>>> The other part is the algorithm by which the provider select the >>>> content of each element in the layout. Since the content of each >>>> element may change dynamically by the provider this attribute only >>>> address the static information which is the algorithm and not the >>>> current content (who we see now in each element) which will need to >>> be >>>> conveyed also but probably not using this attribute. Note that the >>>> information is valid for point to point and multipoint so the >>>> current content should reflect the TP end point and the specific VC >>>> used from it. >>>> >>>> The algorithms may be global or per element(or sub-window). The >>> global >>>> algorithms I see are site switch or segment switch. The per element >>>> may be voice activated, round robin (switch every x seconds) and >>> fixed >>>> (the same VC is displayed there (may be changed by some control >>>> mechanism) >>>> >>>> >>>> Roni >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>> Behalf >>>>> Of clue issue tracker >>>>> Sent: Tuesday, January 24, 2012 12:43 AM >>>>> To: draft-ietf-clue-framework@tools.ietf.org; >>>>> mary.ietf.barnes@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@…): >>>>> >>>>> * type: defect => task >>>>> >>>>> >>>>> -- >>>>> --------------------------------+-------------------------------- >> - >>>>> --------------------------------+- >>> - >>>>> --------------------------------+- >>>> - >>>>> --------------------------------+- >>>>> ---- >>>>> Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue- >>>>> framework@… >>>>> Type: task | Status: new >>>>> Priority: major | Milestone: >>>>> Component: framework | Version: >>>>> Severity: Active WG Document | Resolution: >>>>> Keywords: | >>>>> --------------------------------+-------------------------------- >> - >>>>> --------------------------------+- >>> - >>>>> --------------------------------+- >>>> - >>>>> --------------------------------+- >>>>> ---- >>>>> >>>>> Ticket URL: >>>>> >>>>> 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 espeberg@cisco.com Thu Feb 2 08:42:25 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 46B0921F84CE for ; Thu, 2 Feb 2012 08:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.474 X-Spam-Level: X-Spam-Status: No, score=-9.474 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, 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 WlXC2uFVTgWV for ; Thu, 2 Feb 2012 08:42:23 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E094421F84C3 for ; Thu, 2 Feb 2012 08:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=19386; q=dns/txt; s=iport; t=1328200943; x=1329410543; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=0k9IIEPd8WPrztYyVNNKQ3cjlogKrzOsGeDEuGFlk6g=; b=P6RUdL2CtZYQqWWS3ncGWFT2ObihH28LCUOz6IAeF5eJ580BV1eas5dU kaQzl+QmiCMpyFJ/0nbMMKpL37GRJg7rBpIzPXRwRHBA/rMN7zr2CdfFA URLXnBI/N90eOOE5/JnTucrGnhrI1jVFFkcmCO3A4lrhsVWZYgcu2Q6f9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFW8Kk+Q/khL/2dsb2JhbABDDoR9qRNugQWBcgEBAQQBAQEPARANBDQGFwQCAQgOAwQBAQECAgYGFwECAgIBAR8GHwkIAQEEARIIGodjmVgBjGWSBYEvhkmDWgEpBgEtDAKEMg0CCgKCJzNjBKArhxY4 X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="65256444" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 02 Feb 2012 16:42:20 +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 q12GgKA4022642; Thu, 2 Feb 2012 16:42:20 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, 2 Feb 2012 17:42:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 2 Feb 2012 17:42:19 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com> In-Reply-To: <4F29766F.1080101@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] #7: Is composed attribute a boolean or data structure Thread-Index: AczhBxgZzsQM+HraTUCVftAm4h2iFAAvm5hg References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org><4f266f4c.d0770e0a.43c6.37fd@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com><4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com><4f272344.03bd0e0a.6983.3d7e@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com><4f291525.84310e0a.69d7.fffffd3b@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com> <4F29766F.1080101@alum.mit.edu> From: "Espen Berger (espeberg)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 02 Feb 2012 16:42:20.0303 (UTC) FILETIME=[A19D79F0:01CCE1C9] 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: Thu, 02 Feb 2012 16:42:25 -0000 SGkgUGF1bCANCg0KSSB3aWxsIG1ha2UgYSBicmllZiBhdHRlbXB0IHRvIGFuc3dlci4gDQoNClRo ZSBzY2VuYXJpb3MgYXJlIGhvdyB0byBtYXAgYSAzeCBjYW1lcmEgc3lzdGVtIHRvIGEgMnggc2Ny ZWVuIHN5c3RlbS4gVGhlIHRyaXBsZSBvZmZlciANCiBTdHJlbWEgPSAxIC0gMyANCiBQb2xpY2ll cyA9IFN3aXRjaGVkLCBzdGF0aWMsIGNvbXBvc2VkIA0KDQpBcyBhIHJlY2VpdmVyICh3aXRoIDJ4 IHNjcmVlbnMpIEkgd291bGQgZG8gdGhpcyBjaG9pY2VzIA0KDQoxKSBIb3cgbWFueSBzdHJlYW1z IHRvIHJlY2VpdmUgDQogICAxID0+IFRoZSB0cmlwbGUgc2VuZHMgYSBzaW5nbGUgc3RyZWFtIGJ5 IHNvbWUgc2VuZGVyIHByZWZlcnJlZCBwb2xpY3kgDQogICAyID0+IFRoZSB0cmlwbGUgc2VuZHMg dHdvIHN0cmVhbXMgYnkgc29tZSBwb2xpY3kgDQogICAzID0+IFRoZSB0cmlwbGUgc2VuZHMgdGhy ZWUgY2FtZXJhcyBpbiBzcGF0aWFsIG9yZGVyLCBhbmQgDQogICAgICB0aGUgcmVjZWl2ZXIgZGVj aWRlIGhvdyB0byByZW5kZXIgYWNyb3NzIHR3byBzY3JlZW5zIA0KDQoyKSBXaGljaCBzd2l0Y2hp bmcgcG9saWN5IA0KICBTdGF0aWMgPT4gVGhlIHJlcXVlc3RlciBhc2sgZm9yIGV4cGxpY2l0IGNh bWVyYSBzdHJlYW1zLCBlLmcuIGNhbTEgb3IgKGNhbTIrY2FtMykgIA0KICBTd2l0Y2hlZC9Db21w b3NlZCA9PiBUaGUgdHJpcGxlIGNob29zZXMgdGhlIHN0cmVhbXMgdG8gc2VuZCwgZS5nLiB0aGUg dHdvIGxvdWRlc3Qgc2VnbWVudHMgb3IgaXQgY291bGQgbWFrZSBhIG5pY2UgcmVuZGVyaW5nIG9m IDN4IGNhbWVyYXMgcmVuZGVyZWQgb24gdHdvIHN0cmVhbXMuIA0KDQpJIGFzc3VtZSB0aGF0IHlv dSB3b24ndCB1c2UgZGlmZmVyZW50IHN3aXRjaGluZyBwb2xpY2llcyBmb3IgdGhlIGRpZmZlcmVu dCBzdHJlYW1zLCBzaW5jZSBpdCBnaXZlcyB0aGUgc2VuZGVyIG9mIG1lZGlhIHRoZSBjaGFuY2Ug dG8gb3B0aW1pemUgd2hhdCBpdCBzZW5kIG9uIHRoZSBzdHJlYW1zIHJlcXVlc3RlZC4gDQoNClRo ZSAnc2l0ZScgc3dpdGNoaW5nIHBvbGljeSBtYWtlcyBtb3N0IHNlbnNlIGZyb20gYW4gTUNVLiBJ IGludGVycHJldGUgdGhlIHBvbGljeSBhcyB0cnkgdGhlIGJlc3QgeW91IGNhbiB0byBzd2l0Y2gg aW4gYWxsIGNhcHR1cmUgc3RyZWFtcyBmcm9tIGEgcm9vbSB3aGVuIHRoZSByb29tIGlzIGFjdGl2 ZS4gRXhhbXBsZSANCiBSb29tIEEgaGFzIHR3byBjYW1lcmFzIA0KIFJvb20gQiBoYXMgdGhyZWUg Y2FtZXJhcw0KIFJvb20gQyBoYXMgYSBzaW5nbGUgY2FtZXJhICANCiBSb29tIEQgaGFzIHRocmVl IHNjcmVlbnMgDQoNCjEpIFJvb20gRCByZWNlaXZlcyBtZWRpYSBmcm9tIHJvb20gQSBhbmQgQyAN CjIpIFJvb20gQiBzdGFydHMgdGFsa2luZw0KM2EpIHdpdGggc2l0ZSBzd2l0Y2hpbmcgDQogIFJv b20gRCByZWNlaXZlcyBtZWRpYSBvbmx5IGZyb20gRCBhY3Jvc3MgYWxsIHRocmVlIHNjcmVlbnMg DQozYikgd2l0aCBzZWdtZW50IHN3aXRjaGluZyANCiAgUm9vbSBEIHJlY2VpdmVzIG1lZGlhIGZy b20gQSwgYW5kIHRoZSBuZXcgYWN0aXZlIHNlZ21lbnQgZnJvbSBEIA0KDQpDaGVlcnMgIA0KIA0K LUVzcGVuIA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjbHVlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQ YXVsIEt5eml2YXQNClNlbnQ6IDEuIGZlYnJ1YXIgMjAxMiAxODoyOQ0KVG86IGNsdWVAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xl YW4gb3IgZGF0YSBzdHJ1Y3R1cmUNCg0KRXNwZW4sDQoNCklTVE0gdGhhdCBmb3IgYSBzd2l0Y2hl ZCBzdHJlYW0geW91IGhhdmU6DQotIHRoZSBzZXQgb2YgY2FuZGlkYXRlIHN0cmVhbXMgdG8gYmUg c3dpdGNoZWQgYW1vbmcNCi0gYW4gYWxnb3JpdGhtIGZvciBwaWNraW5nIGFtb25nIHRoZW0NCg0K SWYgdGhlIHJlY2VpdmVyIGhhcyBtdWx0aXBsZSBzY3JlZW5zLCB0aGVuIHRoZXJlIHdpbGwgYmUg YSBzdHJlYW0gZm9yIA0KZWFjaCBvbmUsIGFuZCBlYWNoIGNvdWxkIGhhdmUgZGlmZmVyZW50IGNh bmRpZGF0ZSBpbnB1dCBzdHJlYW1zIGFuZCBhIA0KZGlmZmVyZW50IHBvbGljeS4NCg0KV2hhdCB5 b3UgYXJlIGRlc2NyaWJpbmcgYXMgInNpdGUgc3dpdGNoaW5nIiBhZGRzIGFub3RoZXIgd3Jpbmts ZSwgc2luY2UgDQppdCBpcyBjb3VwbGluZyB0aGUgc3dpdGNoaW5nIHBvbGljaWVzIGZvciBtdWx0 aXBsZSBzdHJlYW1zLiBBbHNvLCBJJ20gDQpub3Qgc3VyZSBob3cgaXQgd29ya3MgaWYgdGhlIHNp dGVzIGhhdmUgZGlmZmVyaW5nIG51bWJlcnMgb2Ygc2NyZWVucyBhbmQgDQpjYW1lcmFzLiBIb3cg d291bGQgeW91IGRlc2NyaWJlIHRoZSBpbmRpdmlkdWFsIHN0cmVhbXMgZnJvbSB0aGUgTUNVIHNv IA0KdGhhdCBhIHJvb20gY291bGQgc2VsZWN0IGFuIGFwcHJvcHJpYXRlIHNldCBvZiBzdHJlYW1z IHRvIGdldCBzaXRlIA0Kc3dpdGNoaW5nPw0KDQpJdCB3b3VsZCBiZSBoZWxwZnVsICh0byBtZSBh bnl3YXkpIGlmIHlvdSBjb3VsZCBkZXNjcmliZSB0aGUgaW50ZXJlc3RpbmcgDQpjYXNlcyBieSBl bnVtZXJhdGluZyB0aGUgb2ZmZXJlZCBzdHJlYW1zIHRvZ2V0aGVyIHdpdGggdGhlIGlucHV0cyBh bmQgDQp0aGUgYWxnb3JpdGhtIHVzZWQgZm9yIGVhY2guIFJpZ2h0IG5vdywgSSdtIG5vdCBzdXJl IGhvdyB0byBkbyB0aGF0Lg0KDQoJVGhhbmtzLA0KCVBhdWwNCg0KT24gMi8xLzEyIDg6MDAgQU0s IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpIHdyb3RlOg0KPiBJIHdvdWxkIHN0aWxsIGNhbGwgaXQg c3dpdGNoLXBvbGljeSwgZS5nLiB0aGVuIHBvc3NpYmxlIHZhbHVlcyBjb3VsZCBiZToNCj4gKiBT aXRlOiBDaGFuZ2UgYWxsIGF0IHRoZSBzYW1lIHRpbWUNCj4gKiBTZWdtZW50OiBPbmx5IGNoYW5n ZSB0aGUgYWN0aXZlIHNlZ21lbnQNCj4gKiBSb3VuZCByb2JpbjogQ2hhbmdlIGFjdGl2ZSBzZWdt ZW50IGFuZCB0aGVuIGNoYW5nZSB0byBvdGhlciBzZWdtZW50cyBpbiAxMCBzZWMgaW50ZXJ2YWxz Lg0KPg0KPiBIb3cgeW91IHN3aXRjaCBiZXR3ZWVuIHN0cmVhbXMgYW5kIGhvdyB5b3UgcmVuZGVy IGhhcyBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIGFuZCBwb2xpY2llcywgc28gSSBmaW5kIGl0IHZl cnkgdXNlZnVsIHRvIGRpc2N1c3MgdGhlbSBhcyB0d28gc2VwYXJhdGUgaXNzdWVzIHRvIGF2b2lk IGNvbmZ1c2lvbi4NCj4NCj4gQ2hlZXJzDQo+DQo+IC1Fc3Blbg0KPg0KPg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb25pIEV2ZW4gW21haWx0bzpyb24uZXZlbi50bHZA Z21haWwuY29tXQ0KPiBTZW50OiAxLiBmZWJydWFyIDIwMTIgMTE6MzANCj4gVG86IEVzcGVuIEJl cmdlciAoZXNwZWJlcmcpOyBjbHVlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6 IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YSBzdHJ1Y3R1cmUNCj4NCj4g SGkgRXNwZW4sDQo+IEkgY2FsbGVkIHNpdGUgb3Igc2VnbWVudCBzd2l0Y2ggYSBwb2xpY3kgYnV0 IEkgYW0gbm90IHN1cmUgdGhhdCBpdCBpcyBhIHN3aXRjaCBwb2xpY3kgYnkgaXRzZWxmIHNpbmNl IHNlZ21lbnQgc3dpdGNoIGZvciBleGFtcGxlIGNhbiBoYXBwZW4gYmFzZWQgb24gYWN0aXZlIHNw ZWFrZXJzIG9yIHNvbWUgcm91bmQgcm9iaW4gdGltaW5nIHdoaWNoIGlzIHRoZSBzd2l0Y2hpbmcg cG9saWN5Lg0KPiBSb25pDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJv bTogRXNwZW4gQmVyZ2VyIChlc3BlYmVyZykgW21haWx0bzplc3BlYmVyZ0BjaXNjby5jb21dDQo+ PiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDMxLCAyMDEyIDU6MzggUE0NCj4+IFRvOiBSb25pIEV2 ZW47IGNsdWVAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2Vk IGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPj4gc3RydWN0dXJlDQo+Pg0KPj4gSGkgUm9u eQ0KPj4NCj4+IFRvIGNob29zZSBiZXR3ZWVuIHNpdGUgYW5kIHNlZ21lbnQgc3dpdGNoIGlzIG1v cmUgYSBwb2xpY3kgdGhhbiBhDQo+PiA8dmlkZW8tbGF5b3V0Piwgc28gaW4gdGhhdCBjYXNlIEkg d291bGQgYXJndWUgdGhhdCB5b3UgY291bGQgb2ZmZXIgYQ0KPj4gQ2FwdHVyZSBzdHJlYW0gd2l0 aCBhIHN3aXRjaC1wb2xpY3kgPSB7c2l0ZSwgc2VnbWVudH0NCj4+DQo+PiBNeSBwb2ludCBhYm91 dCBpbnRlcm9wZXJhYmlsaXR5IGlzIHRoYXQgYSBzaW5nbGUgY29tcG9zZWQgc3RyZWFtIHdpdGgN Cj4+IGFsdGVybmF0aXZlIGxheW91dHMgYXJlIGVhc2llciB0byB1bmRlcnN0YW5kLCB0aGFuIG11 bHRpcGxlIGNhcHR1cmUNCj4+IHN0cmVhbXMgd2l0aCBhbHRlcm5hdGl2ZSBjb25maWd1cmF0aW9u cy4gVGhlIGxhc3QgcmVxdWlyZXMgdG8gcGljayB0aGUNCj4+IGZpcnN0IG9uZSBvciByZXF1aXJl cyBzb21lIHNvcnQgb2YgZGVmYXVsdCBtYXJraW5nLg0KPj4NCj4+IENoZWVycw0KPj4NCj4+IC1F c3Blbg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUm9u aSBFdmVuIFttYWlsdG86cm9uLmV2ZW4udGx2QGdtYWlsLmNvbV0NCj4+IFNlbnQ6IDMxLiBqYW51 YXIgMjAxMiAwMDowNg0KPj4gVG86IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpOyBjbHVlQGlldGYu b3JnDQo+PiBTdWJqZWN0OiBSRTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBi b29sZWFuIG9yIGRhdGENCj4+IHN0cnVjdHVyZQ0KPj4NCj4+IEhpIEVzcGVuLA0KPj4gSWYgdGhl IHByb3ZpZGVyIHdhbnRzIHRvIG9mZmVyIHNpdGUgc3dpdGNoIGFuZCBzZWdtZW50IHN3aXRjaCBv cHRpb24gdG8NCj4+IHRoZSBjb25zdW1lciBoZSBjYW5ub3QgZG8gaXQganVzdCB3aXRoIEEuIHRo aXMgaXMgYSBiYXNpYyB1c2UgY2FzZS4NCj4+DQo+PiBJbiBnZW5lcmFsLCB5b3VyIG9wdGlvbiBk b2VzIG5vdCBwcm92aWRlIGFueSBpbnRlcm9wZXJhYmlsaXR5IHNpbmNlDQo+PiBib3RoIHNpZGVz IG1heSBoYXZlIGRpZmZlcmVudCB2aWV3cyB3aGF0IGNvbXBvc2VkIG1lYW5zLiBJbiB0aGUNCj4+ IGZyYW1ld29yayBleGFtcGxlIG9mIGEgUElQIGFzIGNvbXBvc2VkIGltYWdlIGl0IGlzIGFuIGFz c3VtcHRpb24gdGhhdA0KPj4gaWYgdGhlIHByb3ZpZGVyIG9mZmVycyB0aGlzIGNvbXBvc2VkIG9m ZmVyLCB0aGUgY29uc3VtZXIgY2FuIHVuZGVyc3RhbmQNCj4+IHRoYXQgaXQgaXMgYSBQSVAgbWl4 IGJ1dCB0aGVyZSBpcyBub3RoaW5nIGluIHRoZSBvZmZlciB0aGF0IHdpbGwNCj4+IGluZGljYXRl IHRoYXQgaXQgaXMuDQo+Pg0KPj4gUm9uaQ0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4+IEZyb206IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpIFttYWlsdG86ZXNwZWJlcmdA Y2lzY28uY29tXQ0KPj4+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAzMCwgMjAxMiA1OjIxIFBNDQo+ Pj4gVG86IFJvbmkgRXZlbjsgY2x1ZUBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJFOiBbY2x1ZV0g Izc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPj4+IHN0cnVjdHVy ZQ0KPj4+DQo+Pj4gSGkgUm9uaQ0KPj4+DQo+Pj4gSWYgeW914oCZcmUgYSBwYXJ0aWN1bGFyIHVz ZSBjYXNlcyByZXF1aXJlcyBjb250cm9sIG92ZXIgdGhlIGNvbXBvc2VkDQo+Pj4gbGF5b3V0cyB5 b3UgbmVlZCBhKSBhbmQgYikuIEluIG15IGV4YW1wbGUgSSB1c2VkIGEgc2luZ2xlDQo+Pj4gYWR2 ZXJ0aXNlbWVudCBjb21wb3NlZCBzdHJlYW0gd2l0aCBvcHRpb25hbCBtZXRhLWluZm9ybWF0aW9u IGFib3V0DQo+Pj4gcG9zc2libGUgbGF5b3V0IGNob2ljZXMuIEEgcmVjZWl2ZXIgdGhhdCB3YW50 cyB0aGUgZGVmYXVsdCBjb21wb3NlZA0KPj4+IGxheW91dCBjYW4gcmVxdWVzdCB0aGUgY29tcG9z ZWQgc3RyZWFtIGFuZCBza2lwIHRoZSBvcHRpb25hbCB2aWRlby0NCj4+IGxheW91dCBpbmZvcm1h dGlvbi4NCj4+PiBPcHRpb25hbGx5IHlvdSBjb3VsZCByZXF1ZXN0IHRoZSBzYW1lIGNvbXBvc2Vk IHN0cmVhbSB3aXRoIGxheW91dHMNCj4+PiBoaW50cyBmb3IgdGhlIHJlY2VpdmVyLg0KPj4+DQo+ Pj4gRm9yIG1lIHVzZSBjYXNlIGMpIGRvZXMgbm90IGluY2x1ZGUgdGhlIHNlbGVjdGlvbiBtZWNo YW5pc21zLCBvbmx5DQo+PiB0aGUNCj4+PiBjb250ZW50IHlvdSBzZWUgaW4gdGhlIHZpZGVvIHN0 cmVhbS4NCj4+Pg0KPj4+IENoZWVycw0KPj4+DQo+Pj4gLUVzcGVuDQo+Pj4NCj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IFJvbmkgRXZlbiBbbWFpbHRvOnJvbi5ldmVu LnRsdkBnbWFpbC5jb21dDQo+Pj4gU2VudDogMzAuIGphbnVhciAyMDEyIDE1OjM5DQo+Pj4gVG86 IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpOyBjbHVlQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUkU6 IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhDQo+Pj4g c3RydWN0dXJlDQo+Pj4NCj4+PiBIaSBFc3BlbiwNCj4+PiBJZiB5b3Ugd2lsbCBsb29rIGF0IHRo ZSBub3RlcyBmcm9tIHRoZSBsYXN0IGNhbGwgdGhlcmUgd2FzIGEgc3VwcG9ydA0KPj4+IHRoYXQg YSkgaXMgbm90IGVub3VnaC4gSGF2aW5nIGp1c3QgY29tcG9zZSBkb2VzIG5vdCBhZGRyZXNzIGV2 ZW4gdGhlDQo+Pj4gdXNlIGNhc2VzIEkgcHJvdmlkZWQgd2hpY2ggYXJlIGFsc28gYmFzZWQgb24g dGhlIHVzZSBjYXNlIGRyYWZ0Lg0KPj4+DQo+Pj4NCj4+PiBJIGFtIG5vdCBzdXJlIHdoYXQgeW91 IG1lYW4gYnkgQyBzaW5jZSB3aGF0IGluIHRoZSBjb21wb3NlZCBzdHJlYW0NCj4+IGNhbg0KPj4+ IGJlIGVpdGhlciB3aGljaCBWQyB5b3Ugc2VlIG9yIHdoYXQgaXMgdGhlIHNlbGVjdGlvbiBjcml0 ZXJpYSBmb3INCj4+IGJlaW5nDQo+Pj4gaW4gYSBjb21wb3NlZCBzdHJlYW0uIElmIHlvdSBtZWFu dCB0aGUgc2Vjb25kLCBteSB2aWV3IGlzIHRoYXQgQyBhbmQNCj4+PiBhbHNvIGIgc2hvdWxkIGJl IGluIHRoZSBiYXNpYyBmcmFtZXdvcmsgYW5kIG5vdCBpbiBhbiBleHRlbnNpb24uDQo+Pj4NCj4+ PiBSb25pIEV2ZW4NCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBG cm9tOiBFc3BlbiBCZXJnZXIgKGVzcGViZXJnKSBbbWFpbHRvOmVzcGViZXJnQGNpc2NvLmNvbV0N Cj4+Pj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDMwLCAyMDEyIDQ6MTcgUE0NCj4+Pj4gVG86IFJv bmkgRXZlbjsgY2x1ZUBpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSRTogW2NsdWVdICM3OiBJcyBj b21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4+Pj4gc3RydWN0dXJlDQo+Pj4+ DQo+Pj4+DQo+Pj4+IFRvIGhlbHAgd2l0aCB0aGUgZGlyZWN0aW9uIG9mIHRoZSBkaXNjdXNzaW9u cyBJIHRoaW5rIGl0J3MgdXNlZnVsDQo+PiB0bw0KPj4+PiBkaXZpZGUgdGhlIGRpc2N1c3Npb25z IGludG8gdGhyZWUgdXNlIGNhc2VzIGZvciBjb21wb3NlZCBzdHJlYW1zLg0KPj4+PiAgIGEpIEhv dyB0byBleHByZXNzIGlmIGEgY2FwdHVyZSBzdHJlYW0gaXMgY29tcG9zZWQgb3Igbm90DQo+Pj4+ ICAgYikgSG93IHRvIGV4cHJlc3MgbGF5b3V0IGNob2ljZXM/IChlLmcuIHdpdGggYSB2aWRlby1s YXlvdXQNCj4+Pj4gZWxlbWVudCkNCj4+Pj4gICBjKSBIb3cgdG8gZXhwcmVzcyB3aGF0J3MgaW5z aWRlIGEgY29tcG9zZWQgc3RyZWFtDQo+Pj4+DQo+Pj4+IEZvciB1c2UgY2FzZSBhKSBhIGNvbXBv c2VkIGF0dHJpYnV0ZSBzaG91bGQgYmUgc3VmZmljaWVudCwgeW91DQo+Pj4+IGVpdGhlciBhc2sg Zm9yIHRoZSBjb21wb3NlZCBzdHJlYW0gb3IgeW91IGRvIG5vdC4NCj4+Pj4gSSBhbHNvIGJlbGll dmUgdGhpcyBzaG91bGQgY292ZXIgdGhlIGludGVyb3BlcmFiaWxpdHkgcmVxdWlyZW1lbnQNCj4+ IHdlDQo+Pj4+IGhhdmUgYWNyb3NzIG11bHRpcGxlIHR5cGVzIG9mIGVuZHBvaW50cy4NCj4+Pj4N Cj4+Pj4gRm9yIHVzZSBjYXNlIGIpIGJvdGggbWVkaWFjdHJsIGFuZCB4Y29uIHVzZXMgYTx2aWRl by1sYXlvdXQ+DQo+Pj4+IGVsZW1lbnQgdG8gZGVzY3JpYmUgcG9zc2libGUgbGF5b3V0cyBhbmQg YWxzbyB0byByZXF1ZXN0IHRoZQ0KPj4+PiBwcmVmZXJyZWQgbGF5b3V0IGJhc2VkIG9uIG9wdGlv bnMuIChhcyBkZXNjcmliZWQgaW4gUm9uaSdzIGVtYWlsKQ0KPj4+Pg0KPj4+PiBBbiBleGFtcGxl IGNvdWxkIGJlIChpbnNwaXJlZCBieSBtZWRpYWN0cmwgYW5kIHhjb24gdXNhZ2Ugb2YNCj4+IDx2 aWRlby0NCj4+Pj4gbGF5b3V0Pik6DQo+Pj4+DQo+Pj4+IENMVUUgQWR2ZXJ0aXNlbWVudA0KPj4+ PiAgICBDYXB0dXJlIGlkPTIgUHVycG9zZT1wZW9wbGUgQ29tcG9zZWQ9ZmFsc2UNCj4+Pj4gICAg Q2FwdHVyZSBpZD0zIFB1cnBvc2U9cGVvcGxlIENvbXBvc2VkPWZhbHNlDQo+Pj4+ICAgIENhcHR1 cmUgaWQ9NCBQdXJwb3NlPVBlb3BsZSBDb21wb3NlZD10cnVlDQo+Pj4+ICAgICAgICBWaWRlby1s YXlvdXQ9IidhdXRvbWF0aWMnLCAnZHVhbC12aWV3JywgJyBzaW5nbGUtdmlldyciDQo+Pj4+DQo+ Pj4+IENMVUUgY29uZmlndXJlIC8vIERlZmF1bHQgY29tcG9zZWQgc3RyZWFtDQo+Pj4+ICAgIENh cHR1cmUgaWQ9NA0KPj4+Pg0KPj4+PiAvLyBPciBjb21wb3NlZCBzdHJlYW0gd2l0aCBsYXlvdXQg aGludHMNCj4+Pj4gICAgIENhcHR1cmUgaWQ9NCBWaWRlby1sYXlvdXQ9J2R1YWwtdmlldycNCj4+ Pj4NCj4+Pj4gVGhlIHZpZGVvLWxheW91dCBlbGVtZW50IGlzIGEgbGlzdCBvZiBzdHJpbmdzIGFu ZCBlYWNoIHN0cmluZyBpcyBhDQo+Pj4+IGxheW91dC1oaW50IHRoYXQgY2FuIGJlIHJlcXVlc3Rl ZC4gVmlkZW8tbGF5b3V0IGlzIG9wdGlvbmFsLiBBDQo+Pj4+IGxheW91dCBoaW50cyBhYm91dCB0 aGUgcmVxdWVzdGVkIHJlbmRlcmluZyBhbmQgdGhlIHNvdXJjZSBpcyBmcmVlDQo+PiB0bw0KPj4+ PiByZXBsYWNlIGFueSBzdHJlYW0gYXMgbG9uZyBhcyB0aGV5IGZpdCB0aGUgbGF5b3V0Lg0KPj4+ Pg0KPj4+PiBVc2UgY2FzZSBjKSBpcyBtb3JlIG9wZW4gaW4gdGhlIHNlbnNlIHRoYXQgd2hhdCB5 b3UgYWN0dWFsbHkNCj4+IHJlY2VpdmUNCj4+Pj4gaW4gYSBjb21wb3NlZCBzdHJlYW0gaXMgZGVw ZW5kaW5nIG9uIHN0YXR1cyBvZiBhIHJvb20gb3Igd2hvIGlzIGluDQo+PiBhDQo+Pj4+IE1DVSBj b25mZXJlbmNlLiBFLmcuIGZyb20gYSByb29tIHlvdSBjb3VsZCBnZXQgYSBtaXggb2YgZGlmZmVy ZW50DQo+Pj4+IGNhcHR1cmUgc3RyZWFtIHJlcHJlc2VudGluZyBjYW1lcmFzIGFuZCBmcm9tIGEg dHJhbnNjb2RpbmcgTUNVIGl0DQo+Pj4+IGNvdWxkIGJlIGRpZmZlcmVudCByb29tLCBkaWZmZXJl bnQgY2FtZXJhcyBvciBhbm90aGVyIG1peCBvZg0KPj4+PiBwb3NzaWJsZSBpbnB1dCB2aWRlbyBz dHJlYW1zLg0KPj4+Pg0KPj4+PiBIYXZpbmcgc3VwcG9ydCBmb3IgYm90aCBiKSBhbmQgYykgY291 bGQgYmUgYSBnb29kIHRlc3QgZm9yIHRoZQ0KPj4+PiBleHRlbnNpYmlsaXR5IG9mIENMVUUuIElm IHRoZSBiYXNpcyBvZiBDTFVFIG9ubHkgZG9lcyB1c2UgY2FzZSBhKQ0KPj4+PiB0aGVyZSBzaG91 bGQgYmUgcm9vbSB0byBleHRlbmQgQ0xVRSB3aXRoIHN1cHBvcnQgZm9yIGIpIGFuZCBjKSBhcyBh DQo+Pj4+IENMVUUgKyBsYXlvdXQgZGVzY3JpcHRpb24gZXh0ZW5zaW9uLg0KPj4+Pg0KPj4+PiBD aGVlcnMNCj4+Pj4NCj4+Pj4gLUVzcGVuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+IEJlaGFsZg0KPj4+PiBPZiBSb25pIEV2 ZW4NCj4+Pj4gU2VudDogMzAuIGphbnVhciAyMDEyIDExOjE4DQo+Pj4+IFRvOiBjbHVlQGlldGYu b3JnDQo+Pj4+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBh IGJvb2xlYW4gb3IgZGF0YQ0KPj4+PiBzdHJ1Y3R1cmUNCj4+Pj4NCj4+Pj4gSGksDQo+Pj4+IER1 cmluZyB0aGUgbGFzdCBjYWxsIEkgdm9sdW50ZWVyZWQgdG8gcHJvdmlkZSBzb21lIGlucHV0Lg0K Pj4+Pg0KPj4+PiBJbiBjdXJyZW50IElFVEYgd29yayAoWENPTiwgTWVkaWFjdHJsIFdHcyB0aGVy ZSBpcyBhIHZpZGVvIGxheW91dA0KPj4+PiBlbGVtZW50KQ0KPj4+Pg0KPj4+PiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1lZGlhY3RybC1taXhlci1jb250cm9sLQ0KPj4+ IHBhY2thZ2UtDQo+Pj4+IDE0I3NlY3Rpb24tNC4yLjEuNC4yLjENCj4+Pj4NCj4+Pj4gYW5kDQo+ Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYteGNvbi1jb21tb24tZGF0 YS1tb2RlbC0NCj4+Pj4gMzIjc2VjdGlvbi00LjIuNyAobG9vayBhdCB2aWRlby1sYXlvdXQpDQo+ Pj4+DQo+Pj4+IEkgd291bGQgbGlrZSBmaXJzdCB0byB0cnkgdG8gZGVmaW5lIHRoZSB0ZXJtICJj b21wb3NlZCB2aWRlbyIgc2luY2UNCj4+PiBpdA0KPj4+PiBsb29rcyB0byBtZSBsaWtlIHdlIGhh dmUgZGlmZmVyZW50IHZpZXdzIGhlcmUsIGFuZCBwcm92aWRlIG15DQo+Pj4+IGluaXRpYWwgdmll dyBvbiB3aGF0IHNob3VsZCBiZSBkZXNjcmliZWQuDQo+Pj4+DQo+Pj4+IENvbXBvc2VkIHZpZGVv IGNhbiBkZXNjcmliZXMgYm90aCB0aGUgbGF5b3V0IGFuZCB0aGUgc2VsZWN0aW9uDQo+Pj4+IGFs Z29yaXRobSBmb3IgY29tcG9zaW5nIHRoZSAgY29udGVudCBvZiB0aGUgc3ViLXdpbmRvd3MgaW4g dGhlDQo+Pj4gIm1peGVkIg0KPj4+PiB2aWRlby4NCj4+Pj4NCj4+Pj4gVGhlIHZpZGVvIGxheW91 dCB3aGljaCBqdXN0IGRlc2NyaWJlcyB0aGUgZ2VvbWV0cnkgb2YgdGhlIGNvbXBvc2VkDQo+Pj4+ IGltYWdlIGFuZCBJIHRoaW5rIHRoYXQgdGhlIGFib3ZlIHJlZmVyZW5jZXMgcHJvdmlkZSBnb29k IHN0cnVjdHVyZQ0KPj4+PiB0byBkZWZpbmUgdGhpcyBwYXJ0IG9mIHRoZSBjb21wb3NlZCB2aWRl byBhdHRyaWJ1dGUuDQo+Pj4+DQo+Pj4+IFRoZSBvdGhlciBwYXJ0IGlzIHRoZSBhbGdvcml0aG0g Ynkgd2hpY2ggdGhlIHByb3ZpZGVyIHNlbGVjdCB0aGUNCj4+Pj4gY29udGVudCBvZiBlYWNoIGVs ZW1lbnQgaW4gdGhlIGxheW91dC4gU2luY2UgdGhlIGNvbnRlbnQgb2YgZWFjaA0KPj4+PiBlbGVt ZW50IG1heSBjaGFuZ2UgZHluYW1pY2FsbHkgYnkgdGhlIHByb3ZpZGVyIHRoaXMgYXR0cmlidXRl IG9ubHkNCj4+Pj4gYWRkcmVzcyB0aGUgc3RhdGljIGluZm9ybWF0aW9uIHdoaWNoIGlzIHRoZSBh bGdvcml0aG0gYW5kIG5vdCB0aGUNCj4+Pj4gY3VycmVudCBjb250ZW50ICh3aG8gd2Ugc2VlIG5v dyBpbiBlYWNoIGVsZW1lbnQpIHdoaWNoIHdpbGwgbmVlZCB0bw0KPj4+IGJlDQo+Pj4+IGNvbnZl eWVkIGFsc28gYnV0IHByb2JhYmx5IG5vdCB1c2luZyB0aGlzIGF0dHJpYnV0ZS4gTm90ZSB0aGF0 IHRoZQ0KPj4+PiBpbmZvcm1hdGlvbiBpcyB2YWxpZCBmb3IgcG9pbnQgdG8gcG9pbnQgYW5kIG11 bHRpcG9pbnQgc28gdGhlDQo+Pj4+IGN1cnJlbnQgY29udGVudCBzaG91bGQgcmVmbGVjdCB0aGUg VFAgZW5kIHBvaW50IGFuZCB0aGUgc3BlY2lmaWMgVkMNCj4+Pj4gdXNlZCBmcm9tIGl0Lg0KPj4+ Pg0KPj4+PiBUaGUgYWxnb3JpdGhtcyBtYXkgYmUgZ2xvYmFsIG9yIHBlciBlbGVtZW50KG9yIHN1 Yi13aW5kb3cpLiBUaGUNCj4+PiBnbG9iYWwNCj4+Pj4gYWxnb3JpdGhtcyBJIHNlZSBhcmUgc2l0 ZSBzd2l0Y2ggb3Igc2VnbWVudCBzd2l0Y2guIFRoZSBwZXIgZWxlbWVudA0KPj4+PiBtYXkgYmUg dm9pY2UgYWN0aXZhdGVkLCByb3VuZCByb2JpbiAoc3dpdGNoIGV2ZXJ5IHggc2Vjb25kcykgYW5k DQo+Pj4gZml4ZWQNCj4+Pj4gKHRoZSBzYW1lIFZDIGlzIGRpc3BsYXllZCB0aGVyZSAobWF5IGJl IGNoYW5nZWQgYnkgc29tZSBjb250cm9sDQo+Pj4+IG1lY2hhbmlzbSkNCj4+Pj4NCj4+Pj4NCj4+ Pj4gUm9uaQ0KPj4+Pg0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZy b206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10g T24NCj4+PiBCZWhhbGYNCj4+Pj4+IE9mIGNsdWUgaXNzdWUgdHJhY2tlcg0KPj4+Pj4gU2VudDog VHVlc2RheSwgSmFudWFyeSAyNCwgMjAxMiAxMjo0MyBBTQ0KPj4+Pj4gVG86IGRyYWZ0LWlldGYt Y2x1ZS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc7DQo+Pj4+PiBtYXJ5LmlldGYuYmFybmVzQGdt YWlsLmNvbQ0KPj4+Pj4gQ2M6IGNsdWVAaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJlOiBbY2x1 ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPj4+Pj4gc3Ry dWN0dXJlDQo+Pj4+Pg0KPj4+Pj4gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4g b3IgZGF0YSBzdHJ1Y3R1cmUNCj4+Pj4+DQo+Pj4+PiBDaGFuZ2VzIChieSBtYXJ5LmlldGYuYmFy bmVzQOKApik6DQo+Pj4+Pg0KPj4+Pj4gICAqIHR5cGU6ICBkZWZlY3QgPT4gIHRhc2sNCj4+Pj4+ DQo+Pj4+Pg0KPj4+Pj4gLS0NCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAtDQo+Pj4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+Pj4gLQ0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rLQ0KPj4+PiAtDQo+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstDQo+Pj4+PiAtLS0tDQo+Pj4+PiAgIFJlcG9ydGVyOiAgbWFyeS5pZXRmLmJhcm5l c0DigKYgIHwgICAgICAgT3duZXI6ICBkcmFmdC1pZXRmLWNsdWUtDQo+Pj4+PiBmcmFtZXdvcmtA 4oCmDQo+Pj4+PiAgICAgICBUeXBlOiAgdGFzayAgICAgICAgICAgICAgICB8ICAgICAgU3RhdHVz OiAgbmV3DQo+Pj4+PiAgIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICB8ICAgTWlsZXN0 b25lOg0KPj4+Pj4gQ29tcG9uZW50OiAgZnJhbWV3b3JrICAgICAgICAgICB8ICAgICBWZXJzaW9u Og0KPj4+Pj4gICBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1bWVudCAgfCAgUmVzb2x1dGlvbjoN Cj4+Pj4+ICAgS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgICAgIHwNCj4+Pj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+PiAtDQo+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+Pj4gLQ0K Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLQ0KPj4+PiAtDQo+Pj4+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+Pj4+PiAtLS0tDQo+Pj4+Pg0KPj4+ Pj4gVGlja2V0IFVSTDoNCj4+Pj4+IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9jbHVl L3RyYWMvdGlja2V0LzcjY29tbWVudDoyPg0KPj4+Pj4gY2x1ZTxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvd2cvY2x1ZS8+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+Pj4+IGNsdWUgbWFpbGluZyBsaXN0DQo+Pj4+PiBjbHVlQGll dGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUN Cj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4+Pj4gY2x1ZUBpZXRmLm9yZw0KPj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4+DQo+DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNsdWUgbWFpbGlu ZyBsaXN0DQo+IGNsdWVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jbHVlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpjbHVlIG1haWxpbmcgbGlzdA0KY2x1ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo= From ron.even.tlv@gmail.com Thu Feb 2 14:21: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 D42DA21F86A2 for ; Thu, 2 Feb 2012 14:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 MR4i2lJKxy9G for ; Thu, 2 Feb 2012 14:21:39 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7D821F865B for ; Thu, 2 Feb 2012 14:21:39 -0800 (PST) Received: by eaae12 with SMTP id e12so1190634eaa.31 for ; Thu, 02 Feb 2012 14:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=AVbInMTUfQwoPLpPgkjR3CgSRWUV7BOgIGQEbyQoFqA=; b=bMoRGponygYruc3N5CocqEsrJJVF7TmnuTQoa8VOzeBGSEtqNe2RN+Ml2OUJ8llQrW SaG/C++QLMjicEw1+t9GWyd4nqMmhgoU/vpG86NxVZU0l4t5ouPvOXKJrJATCyH+bcgW Wkza3L61O8Z+ebwEnVbr6AyPgh5ETzh8CU1IQ= Received: by 10.213.2.142 with SMTP id 14mr801014ebj.15.1328221298207; Thu, 02 Feb 2012 14:21:38 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id c16sm14239745eei.1.2012.02.02.14.21.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Feb 2012 14:21:36 -0800 (PST) From: "Roni Even" To: "'Espen Berger \(espeberg\)'" , "'Paul Kyzivat'" , References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org><4f266f4c.d0770e0a.43c6.37fd@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com><4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com><4f272344.03bd0e0a.6983.3d7e@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com><4f291525.84310e0a.69d7.fffffd3b@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com> <4F29766F.1080101@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com> Date: Fri, 3 Feb 2012 00:17:35 +0200 Message-ID: <4f2b0c70.107f0e0a.44a7.061f@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: AczhBxgZzsQM+HraTUCVftAm4h2iFAAvm5hgAAxW4rA= Content-Language: en-us 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: Thu, 02 Feb 2012 22:21:40 -0000 Hi Espen, I see from your example that you make some assumptions while I have = different ones. I think that we probably see differently how the switch / compose is = done. My view is that the sender should list all the modes he supports = and let the receiver choose. The receiver must be able to select what it = wants to view and in order to do it the receiver need to know what the = sender is capable to produce. You write "The triple sends a single stream by some sender preferred = policy" - my view is that the sender can offer different options by = listing more than one VC and let the receiver select.=20 I also think that there can be different policies for different streams. = For the triple sends two streams one may be the active speaker and the = other may be static (for example middle camera or a mix of the other two = cameras). Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Espen Berger (espeberg) > Sent: Thursday, February 02, 2012 6:42 PM > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data > structure >=20 > Hi Paul >=20 > I will make a brief attempt to answer. >=20 > The scenarios are how to map a 3x camera system to a 2x screen system. > The triple offer Strema =3D 1 - 3 Policies =3D Switched, static, = composed >=20 > As a receiver (with 2x screens) I would do this choices >=20 > 1) How many streams to receive > 1 =3D> The triple sends a single stream by some sender preferred > policy > 2 =3D> The triple sends two streams by some policy > 3 =3D> The triple sends three cameras in spatial order, and > the receiver decide how to render across two screens >=20 > 2) Which switching policy > Static =3D> The requester ask for explicit camera streams, e.g. cam1 = or > (cam2+cam3) > Switched/Composed =3D> The triple chooses the streams to send, e.g. = the > two loudest segments or it could make a nice rendering of 3x cameras > rendered on two streams. >=20 > I assume that you won't use different switching policies for the > different streams, since it gives the sender of media the chance to > optimize what it send on the streams requested. >=20 > The 'site' switching policy makes most sense from an MCU. I interprete > the policy as try the best you can to switch in all capture streams > from a room when the room is active. Example Room A has two cameras > Room B has three cameras Room C has a single camera Room D has three > screens >=20 > 1) Room D receives media from room A and C > 2) Room B starts talking > 3a) with site switching > Room D receives media only from D across all three screens > 3b) with segment switching > Room D receives media from A, and the new active segment from D >=20 > Cheers >=20 > -Espen >=20 >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Paul Kyzivat > Sent: 1. februar 2012 18:29 > To: clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data > structure >=20 > Espen, >=20 > ISTM that for a switched stream you have: > - the set of candidate streams to be switched among > - an algorithm for picking among them >=20 > If the receiver has multiple screens, then there will be a stream for > each one, and each could have different candidate input streams and a > different policy. >=20 > What you are describing as "site switching" adds another wrinkle, = since > it is coupling the switching policies for multiple streams. Also, I'm > not sure how it works if the sites have differing numbers of screens > and cameras. How would you describe the individual streams from the = MCU > so that a room could select an appropriate set of streams to get site > switching? >=20 > It would be helpful (to me anyway) if you could describe the > interesting cases by enumerating the offered streams together with the > inputs and the algorithm used for each. Right now, I'm not sure how to > do that. >=20 > Thanks, > Paul >=20 > On 2/1/12 8:00 AM, Espen Berger (espeberg) wrote: > > I would still call it switch-policy, e.g. then possible values could > be: > > * Site: Change all at the same time > > * Segment: Only change the active segment > > * Round robin: Change active segment and then change to other > segments in 10 sec intervals. > > > > How you switch between streams and how you render has different > requirements and policies, so I find it very useful to discuss them as > two separate issues to avoid confusion. > > > > Cheers > > > > -Espen > > > > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: 1. februar 2012 11:30 > > To: Espen Berger (espeberg); clue@ietf.org > > Subject: RE: [clue] #7: Is composed attribute a boolean or data > > structure > > > > Hi Espen, > > I called site or segment switch a policy but I am not sure that it = is > a switch policy by itself since segment switch for example can happen > based on active speakers or some round robin timing which is the > switching policy. > > Roni > > > >> -----Original Message----- > >> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > >> Sent: Tuesday, January 31, 2012 5:38 PM > >> To: Roni Even; clue@ietf.org > >> Subject: RE: [clue] #7: Is composed attribute a boolean or data > >> structure > >> > >> Hi Rony > >> > >> To choose between site and segment switch is more a policy than a > >> , so in that case I would argue that you could offer = a > >> Capture stream with a switch-policy =3D {site, segment} > >> > >> My point about interoperability is that a single composed stream > with > >> alternative layouts are easier to understand, than multiple capture > >> streams with alternative configurations. The last requires to pick > >> the first one or requires some sort of default marking. > >> > >> Cheers > >> > >> -Espen > >> > >> > >> -----Original Message----- > >> From: Roni Even [mailto:ron.even.tlv@gmail.com] > >> Sent: 31. januar 2012 00:06 > >> To: Espen Berger (espeberg); clue@ietf.org > >> Subject: RE: [clue] #7: Is composed attribute a boolean or data > >> structure > >> > >> Hi Espen, > >> If the provider wants to offer site switch and segment switch = option > >> to the consumer he cannot do it just with A. this is a basic use > case. > >> > >> In general, your option does not provide any interoperability since > >> both sides may have different views what composed means. In the > >> framework example of a PIP as composed image it is an assumption > that > >> if the provider offers this composed offer, the consumer can > >> understand that it is a PIP mix but there is nothing in the offer > >> that will indicate that it is. > >> > >> Roni > >> > >>> -----Original Message----- > >>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > >>> Sent: Monday, January 30, 2012 5:21 PM > >>> To: Roni Even; clue@ietf.org > >>> Subject: RE: [clue] #7: Is composed attribute a boolean or data > >>> structure > >>> > >>> Hi Roni > >>> > >>> If you=E2=80=99re a particular use cases requires control over the = composed > >>> layouts you need a) and b). In my example I used a single > >>> advertisement composed stream with optional meta-information about > >>> possible layout choices. A receiver that wants the default = composed > >>> layout can request the composed stream and skip the optional = video- > >> layout information. > >>> Optionally you could request the same composed stream with layouts > >>> hints for the receiver. > >>> > >>> For me use case c) does not include the selection mechanisms, only > >> the > >>> content you see in the video stream. > >>> > >>> Cheers > >>> > >>> -Espen > >>> > >>> -----Original Message----- > >>> From: Roni Even [mailto:ron.even.tlv@gmail.com] > >>> Sent: 30. januar 2012 15:39 > >>> To: Espen Berger (espeberg); clue@ietf.org > >>> Subject: RE: [clue] #7: Is composed attribute a boolean or data > >>> structure > >>> > >>> Hi Espen, > >>> If you will look at the notes from the last call there was a > support > >>> that a) is not enough. Having just compose does not address even > the > >>> use cases I provided which are also based on the use case draft. > >>> > >>> > >>> I am not sure what you mean by C since what in the composed stream > >> can > >>> be either which VC you see or what is the selection criteria for > >> being > >>> in a composed stream. If you meant the second, my view is that C > and > >>> also b should be in the basic framework and not in an extension. > >>> > >>> Roni Even > >>> > >>>> -----Original Message----- > >>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > >>>> Sent: Monday, January 30, 2012 4:17 PM > >>>> To: Roni Even; clue@ietf.org > >>>> Subject: RE: [clue] #7: Is composed attribute a boolean or data > >>>> structure > >>>> > >>>> > >>>> To help with the direction of the discussions I think it's useful > >> to > >>>> divide the discussions into three use cases for composed streams. > >>>> a) How to express if a capture stream is composed or not > >>>> b) How to express layout choices? (e.g. with a video-layout > >>>> element) > >>>> c) How to express what's inside a composed stream > >>>> > >>>> For use case a) a composed attribute should be sufficient, you > >>>> either ask for the composed stream or you do not. > >>>> I also believe this should cover the interoperability requirement > >> we > >>>> have across multiple types of endpoints. > >>>> > >>>> For use case b) both mediactrl and xcon uses a > >>>> element to describe possible layouts and also to request the > >>>> preferred layout based on options. (as described in Roni's email) > >>>> > >>>> An example could be (inspired by mediactrl and xcon usage of > >> >>>> layout>): > >>>> > >>>> CLUE Advertisement > >>>> Capture id=3D2 Purpose=3Dpeople Composed=3Dfalse > >>>> Capture id=3D3 Purpose=3Dpeople Composed=3Dfalse > >>>> Capture id=3D4 Purpose=3DPeople Composed=3Dtrue > >>>> Video-layout=3D"'automatic', 'dual-view', ' single-view'" > >>>> > >>>> CLUE configure // Default composed stream > >>>> Capture id=3D4 > >>>> > >>>> // Or composed stream with layout hints > >>>> Capture id=3D4 Video-layout=3D'dual-view' > >>>> > >>>> The video-layout element is a list of strings and each string is = a > >>>> layout-hint that can be requested. Video-layout is optional. A > >>>> layout hints about the requested rendering and the source is free > >> to > >>>> replace any stream as long as they fit the layout. > >>>> > >>>> Use case c) is more open in the sense that what you actually > >> receive > >>>> in a composed stream is depending on status of a room or who is = in > >> a > >>>> MCU conference. E.g. from a room you could get a mix of different > >>>> capture stream representing cameras and from a transcoding MCU it > >>>> could be different room, different cameras or another mix of > >>>> possible input video streams. > >>>> > >>>> Having support for both b) and c) could be a good test for the > >>>> extensibility of CLUE. If the basis of CLUE only does use case a) > >>>> there should be room to extend CLUE with support for b) and c) as > a > >>>> CLUE + layout description extension. > >>>> > >>>> Cheers > >>>> > >>>> -Espen > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> Behalf > >>>> Of Roni Even > >>>> Sent: 30. januar 2012 11:18 > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] #7: Is composed attribute a boolean or data > >>>> structure > >>>> > >>>> Hi, > >>>> During the last call I volunteered to provide some input. > >>>> > >>>> In current IETF work (XCON, Mediactrl WGs there is a video layout > >>>> element) > >>>> > >>>> http://tools.ietf.org/html/draft-ietf-mediactrl-mixer-control- > >>> package- > >>>> 14#section-4.2.1.4.2.1 > >>>> > >>>> and > >>>> http://tools.ietf.org/html/draft-ietf-xcon-common-data-model- > >>>> 32#section-4.2.7 (look at video-layout) > >>>> > >>>> I would like first to try to define the term "composed video" > since > >>> it > >>>> looks to me like we have different views here, and provide my > >>>> initial view on what should be described. > >>>> > >>>> Composed video can describes both the layout and the selection > >>>> algorithm for composing the content of the sub-windows in the > >>> "mixed" > >>>> video. > >>>> > >>>> The video layout which just describes the geometry of the = composed > >>>> image and I think that the above references provide good = structure > >>>> to define this part of the composed video attribute. > >>>> > >>>> The other part is the algorithm by which the provider select the > >>>> content of each element in the layout. Since the content of each > >>>> element may change dynamically by the provider this attribute = only > >>>> address the static information which is the algorithm and not the > >>>> current content (who we see now in each element) which will need > to > >>> be > >>>> conveyed also but probably not using this attribute. Note that = the > >>>> information is valid for point to point and multipoint so the > >>>> current content should reflect the TP end point and the specific > VC > >>>> used from it. > >>>> > >>>> The algorithms may be global or per element(or sub-window). The > >>> global > >>>> algorithms I see are site switch or segment switch. The per > element > >>>> may be voice activated, round robin (switch every x seconds) and > >>> fixed > >>>> (the same VC is displayed there (may be changed by some control > >>>> mechanism) > >>>> > >>>> > >>>> Roni > >>>> > >>>>> -----Original Message----- > >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>> Behalf > >>>>> Of clue issue tracker > >>>>> Sent: Tuesday, January 24, 2012 12:43 AM > >>>>> To: draft-ietf-clue-framework@tools.ietf.org; > >>>>> mary.ietf.barnes@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@=E2=80=A6): > >>>>> > >>>>> * type: defect =3D> task > >>>>> > >>>>> > >>>>> -- > >>>>> = --------------------------------+-------------------------------- > >> - > >>>>> --------------------------------+- > >>> - > >>>>> --------------------------------+- > >>>> - > >>>>> --------------------------------+- > >>>>> ---- > >>>>> Reporter: mary.ietf.barnes@=E2=80=A6 | Owner: = draft-ietf-clue- > >>>>> framework@=E2=80=A6 > >>>>> Type: task | Status: new > >>>>> Priority: major | Milestone: > >>>>> Component: framework | Version: > >>>>> Severity: Active WG Document | Resolution: > >>>>> Keywords: | > >>>>> = --------------------------------+-------------------------------- > >> - > >>>>> --------------------------------+- > >>> - > >>>>> --------------------------------+- > >>>> - > >>>>> --------------------------------+- > >>>>> ---- > >>>>> > >>>>> Ticket URL: > >>>>> > >>>>> 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 >=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 pkyzivat@alum.mit.edu Thu Feb 2 16:07: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 6190421F8528 for ; Thu, 2 Feb 2012 16:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 qqJZSYTo2Cmo for ; Thu, 2 Feb 2012 16:07:26 -0800 (PST) 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 D9F5021F8567 for ; Thu, 2 Feb 2012 16:07:24 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id VAEl1i0021ZXKqc53C7Rmv; Fri, 03 Feb 2012 00:07:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id VC7Q1i00h07duvL3hC7Qly; Fri, 03 Feb 2012 00:07:25 +0000 Message-ID: <4F2B254F.9050504@alum.mit.edu> Date: Thu, 02 Feb 2012 19:07:43 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Espen Berger (espeberg)" References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org><4f266f4c.d0770e0a.43c6.37fd@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com><4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com><4f272344.03bd0e0a.6983.3d7e@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com><4f291525.84310e0a.69d7.fffffd3b@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com> <4F29766F.1080101@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Fri, 03 Feb 2012 00:07:27 -0000 On 2/2/12 11:42 AM, Espen Berger (espeberg) wrote: > Hi Paul > > I will make a brief attempt to answer. Its good to get into the details. As exhibited by Roni's reply, its not clear that all are on the same page. > The scenarios are how to map a 3x camera system to a 2x screen system. The triple offer > Strema = 1 - 3 > Policies = Switched, static, composed IIUC, in the above you have separated the policies from the streams - somehow the policies apply to all the streams. It was my impression that each offered stream is independent, and may be static, switched, or composed. So, I would assume that if the 3 camera system wants to accommodate dissimilar systems, it would offer more than three streams. E.g.: - left, static (!composed) - middle, static - right, static - composed (left, middle, and right) - switched (active speaker) - ... > As a receiver (with 2x screens) I would do this choices > > 1) How many streams to receive > 1 => The triple sends a single stream by some sender preferred policy This really confuses me. I assumed that if the receiver only wants one stream (perhaps because it has only one screen), it would simply pick one of the streams offered (as you described, it would be one of the three.) You seem to be suggesting that the act of requesting one stream will cause the sender to alter the policy used to produce that stream. That makes no sense to me. > 2 => The triple sends two streams by some policy More of same confusion above. ISTM that the if the recipient wants two streams to display, that it should be choosing two based on the descriptions. Not that the sender decides what to include in the two based on the fact that two have been requested. > 3 => The triple sends three cameras in spatial order, and > the receiver decide how to render across two screens This is clearly the most straightforward case. > 2) Which switching policy > Static => The requester ask for explicit camera streams, e.g. cam1 or (cam2+cam3) > Switched/Composed => The triple chooses the streams to send, e.g. the two loudest segments or it could make a nice rendering of 3x cameras rendered on two streams. > > I assume that you won't use different switching policies for the different streams, since it gives the sender of media the chance to optimize what it send on the streams requested. What I take from this is that you are assuming a single policy that impacts all the streams sent to this recipient. But I thought the intent was that the sender describes *each* available stream with an independent policy, and the recipient just chooses those that it wishes. > The 'site' switching policy makes most sense from an MCU. I interprete the policy as try the best you can to switch in all capture streams from a room when the room is active. Example > Room A has two cameras > Room B has three cameras > Room C has a single camera > Room D has three screens > > 1) Room D receives media from room A and C > 2) Room B starts talking > 3a) with site switching > Room D receives media only from D across all three screens > 3b) with segment switching > Room D receives media from A, and the new active segment from D I don't even want to *start* talking about this until the stuff above is resolved. Thanks, Paul > Cheers > > -Espen > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 1. februar 2012 18:29 > To: clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data structure > > Espen, > > ISTM that for a switched stream you have: > - the set of candidate streams to be switched among > - an algorithm for picking among them > > If the receiver has multiple screens, then there will be a stream for > each one, and each could have different candidate input streams and a > different policy. > > What you are describing as "site switching" adds another wrinkle, since > it is coupling the switching policies for multiple streams. Also, I'm > not sure how it works if the sites have differing numbers of screens and > cameras. How would you describe the individual streams from the MCU so > that a room could select an appropriate set of streams to get site > switching? > > It would be helpful (to me anyway) if you could describe the interesting > cases by enumerating the offered streams together with the inputs and > the algorithm used for each. Right now, I'm not sure how to do that. > > Thanks, > Paul > > On 2/1/12 8:00 AM, Espen Berger (espeberg) wrote: >> I would still call it switch-policy, e.g. then possible values could be: >> * Site: Change all at the same time >> * Segment: Only change the active segment >> * Round robin: Change active segment and then change to other segments in 10 sec intervals. >> >> How you switch between streams and how you render has different requirements and policies, so I find it very useful to discuss them as two separate issues to avoid confusion. >> >> Cheers >> >> -Espen >> >> >> -----Original Message----- >> From: Roni Even [mailto:ron.even.tlv@gmail.com] >> Sent: 1. februar 2012 11:30 >> To: Espen Berger (espeberg); clue@ietf.org >> Subject: RE: [clue] #7: Is composed attribute a boolean or data structure >> >> Hi Espen, >> I called site or segment switch a policy but I am not sure that it is a switch policy by itself since segment switch for example can happen based on active speakers or some round robin timing which is the switching policy. >> Roni >> >>> -----Original Message----- >>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>> Sent: Tuesday, January 31, 2012 5:38 PM >>> To: Roni Even; clue@ietf.org >>> Subject: RE: [clue] #7: Is composed attribute a boolean or data >>> structure >>> >>> Hi Rony >>> >>> To choose between site and segment switch is more a policy than a >>> , so in that case I would argue that you could offer a >>> Capture stream with a switch-policy = {site, segment} >>> >>> My point about interoperability is that a single composed stream with >>> alternative layouts are easier to understand, than multiple capture >>> streams with alternative configurations. The last requires to pick the >>> first one or requires some sort of default marking. >>> >>> Cheers >>> >>> -Espen >>> >>> >>> -----Original Message----- >>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>> Sent: 31. januar 2012 00:06 >>> To: Espen Berger (espeberg); clue@ietf.org >>> Subject: RE: [clue] #7: Is composed attribute a boolean or data >>> structure >>> >>> Hi Espen, >>> If the provider wants to offer site switch and segment switch option to >>> the consumer he cannot do it just with A. this is a basic use case. >>> >>> In general, your option does not provide any interoperability since >>> both sides may have different views what composed means. In the >>> framework example of a PIP as composed image it is an assumption that >>> if the provider offers this composed offer, the consumer can understand >>> that it is a PIP mix but there is nothing in the offer that will >>> indicate that it is. >>> >>> Roni >>> >>>> -----Original Message----- >>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>>> Sent: Monday, January 30, 2012 5:21 PM >>>> To: Roni Even; clue@ietf.org >>>> Subject: RE: [clue] #7: Is composed attribute a boolean or data >>>> structure >>>> >>>> Hi Roni >>>> >>>> If you’re a particular use cases requires control over the composed >>>> layouts you need a) and b). In my example I used a single >>>> advertisement composed stream with optional meta-information about >>>> possible layout choices. A receiver that wants the default composed >>>> layout can request the composed stream and skip the optional video- >>> layout information. >>>> Optionally you could request the same composed stream with layouts >>>> hints for the receiver. >>>> >>>> For me use case c) does not include the selection mechanisms, only >>> the >>>> content you see in the video stream. >>>> >>>> Cheers >>>> >>>> -Espen >>>> >>>> -----Original Message----- >>>> From: Roni Even [mailto:ron.even.tlv@gmail.com] >>>> Sent: 30. januar 2012 15:39 >>>> To: Espen Berger (espeberg); clue@ietf.org >>>> Subject: RE: [clue] #7: Is composed attribute a boolean or data >>>> structure >>>> >>>> Hi Espen, >>>> If you will look at the notes from the last call there was a support >>>> that a) is not enough. Having just compose does not address even the >>>> use cases I provided which are also based on the use case draft. >>>> >>>> >>>> I am not sure what you mean by C since what in the composed stream >>> can >>>> be either which VC you see or what is the selection criteria for >>> being >>>> in a composed stream. If you meant the second, my view is that C and >>>> also b should be in the basic framework and not in an extension. >>>> >>>> Roni Even >>>> >>>>> -----Original Message----- >>>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] >>>>> Sent: Monday, January 30, 2012 4:17 PM >>>>> To: Roni Even; clue@ietf.org >>>>> Subject: RE: [clue] #7: Is composed attribute a boolean or data >>>>> structure >>>>> >>>>> >>>>> To help with the direction of the discussions I think it's useful >>> to >>>>> divide the discussions into three use cases for composed streams. >>>>> a) How to express if a capture stream is composed or not >>>>> b) How to express layout choices? (e.g. with a video-layout >>>>> element) >>>>> c) How to express what's inside a composed stream >>>>> >>>>> For use case a) a composed attribute should be sufficient, you >>>>> either ask for the composed stream or you do not. >>>>> I also believe this should cover the interoperability requirement >>> we >>>>> have across multiple types of endpoints. >>>>> >>>>> For use case b) both mediactrl and xcon uses a >>>>> element to describe possible layouts and also to request the >>>>> preferred layout based on options. (as described in Roni's email) >>>>> >>>>> An example could be (inspired by mediactrl and xcon usage of >>> >>>> layout>): >>>>> >>>>> CLUE Advertisement >>>>> Capture id=2 Purpose=people Composed=false >>>>> Capture id=3 Purpose=people Composed=false >>>>> Capture id=4 Purpose=People Composed=true >>>>> Video-layout="'automatic', 'dual-view', ' single-view'" >>>>> >>>>> CLUE configure // Default composed stream >>>>> Capture id=4 >>>>> >>>>> // Or composed stream with layout hints >>>>> Capture id=4 Video-layout='dual-view' >>>>> >>>>> The video-layout element is a list of strings and each string is a >>>>> layout-hint that can be requested. Video-layout is optional. A >>>>> layout hints about the requested rendering and the source is free >>> to >>>>> replace any stream as long as they fit the layout. >>>>> >>>>> Use case c) is more open in the sense that what you actually >>> receive >>>>> in a composed stream is depending on status of a room or who is in >>> a >>>>> MCU conference. E.g. from a room you could get a mix of different >>>>> capture stream representing cameras and from a transcoding MCU it >>>>> could be different room, different cameras or another mix of >>>>> possible input video streams. >>>>> >>>>> Having support for both b) and c) could be a good test for the >>>>> extensibility of CLUE. If the basis of CLUE only does use case a) >>>>> there should be room to extend CLUE with support for b) and c) as a >>>>> CLUE + layout description extension. >>>>> >>>>> Cheers >>>>> >>>>> -Espen >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>> Behalf >>>>> Of Roni Even >>>>> Sent: 30. januar 2012 11:18 >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] #7: Is composed attribute a boolean or data >>>>> structure >>>>> >>>>> Hi, >>>>> During the last call I volunteered to provide some input. >>>>> >>>>> In current IETF work (XCON, Mediactrl WGs there is a video layout >>>>> element) >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-mediactrl-mixer-control- >>>> package- >>>>> 14#section-4.2.1.4.2.1 >>>>> >>>>> and >>>>> http://tools.ietf.org/html/draft-ietf-xcon-common-data-model- >>>>> 32#section-4.2.7 (look at video-layout) >>>>> >>>>> I would like first to try to define the term "composed video" since >>>> it >>>>> looks to me like we have different views here, and provide my >>>>> initial view on what should be described. >>>>> >>>>> Composed video can describes both the layout and the selection >>>>> algorithm for composing the content of the sub-windows in the >>>> "mixed" >>>>> video. >>>>> >>>>> The video layout which just describes the geometry of the composed >>>>> image and I think that the above references provide good structure >>>>> to define this part of the composed video attribute. >>>>> >>>>> The other part is the algorithm by which the provider select the >>>>> content of each element in the layout. Since the content of each >>>>> element may change dynamically by the provider this attribute only >>>>> address the static information which is the algorithm and not the >>>>> current content (who we see now in each element) which will need to >>>> be >>>>> conveyed also but probably not using this attribute. Note that the >>>>> information is valid for point to point and multipoint so the >>>>> current content should reflect the TP end point and the specific VC >>>>> used from it. >>>>> >>>>> The algorithms may be global or per element(or sub-window). The >>>> global >>>>> algorithms I see are site switch or segment switch. The per element >>>>> may be voice activated, round robin (switch every x seconds) and >>>> fixed >>>>> (the same VC is displayed there (may be changed by some control >>>>> mechanism) >>>>> >>>>> >>>>> Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf >>>>>> Of clue issue tracker >>>>>> Sent: Tuesday, January 24, 2012 12:43 AM >>>>>> To: draft-ietf-clue-framework@tools.ietf.org; >>>>>> mary.ietf.barnes@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@…): >>>>>> >>>>>> * type: defect => task >>>>>> >>>>>> >>>>>> -- >>>>>> --------------------------------+-------------------------------- >>> - >>>>>> --------------------------------+- >>>> - >>>>>> --------------------------------+- >>>>> - >>>>>> --------------------------------+- >>>>>> ---- >>>>>> Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue- >>>>>> framework@… >>>>>> Type: task | Status: new >>>>>> Priority: major | Milestone: >>>>>> Component: framework | Version: >>>>>> Severity: Active WG Document | Resolution: >>>>>> Keywords: | >>>>>> --------------------------------+-------------------------------- >>> - >>>>>> --------------------------------+- >>>> - >>>>>> --------------------------------+- >>>>> - >>>>>> --------------------------------+- >>>>>> ---- >>>>>> >>>>>> Ticket URL: >>>>>> >>>>>> 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 > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Fri Feb 3 14:15: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 7B4B421F84EF for ; Fri, 3 Feb 2012 14:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.894 X-Spam-Level: X-Spam-Status: No, score=-102.894 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_05=-1.11, 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 tsQapn+bDcSU for ; Fri, 3 Feb 2012 14:15:53 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98BB821F84EE for ; Fri, 3 Feb 2012 14:15:53 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3124327vcb.31 for ; Fri, 03 Feb 2012 14:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=RQCvfkj7ukUOlBVv/r4LudzlZhdHOjmL5Hn5iRR+q30=; b=CQCktqn9JLpyzFkoZFCQeGPWmWuv1ruQWeIN75W/GRlGsQAnFoFv3p5TR4DZ8ibFep Vi3oo5CGJECWxMeeGS4392TltMhGfOR7Aov/w1/6oElM3xTQtAlx7kC3PvYi5oxLCoQM 5kblptGSTn5n6pM4yMaKykI+jzf6RG2aKxc88= MIME-Version: 1.0 Received: by 10.52.67.35 with SMTP id k3mr4312057vdt.38.1328307353106; Fri, 03 Feb 2012 14:15:53 -0800 (PST) Received: by 10.52.114.200 with HTTP; Fri, 3 Feb 2012 14:15:53 -0800 (PST) Date: Fri, 3 Feb 2012 16:15:53 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Deadlines for 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: Fri, 03 Feb 2012 22:15:54 -0000 HI all, This is a reminder of the deadline for documents for the interim meeting: http://www.ietf.org/mail-archive/web/clue/current/msg00937.html If you plan on submitting a draft and think that you may not meet the deadline (you have just a few hours), please let the chairs know ASAP. If you are requesting agenda time for something for which you do not have a draft, please let us (myself and Paul) know no later than 17:00 Pacific on Monday, Feb. 6th. If you do not have a draft, then we need your .ppt charts at that time. In this case, priority will be given to topics that have been discussed on the mailing list. Otherwise, we need your charts no later than 17:00 Pacific on Friday, Feb. 10th. This is a hard deadline as we need to be able to get the materials organized for the meeting and finalize the agenda. If we get charts late, there is a high risk that your topic will be deferred. We *may* allow updates to original charts after this time, but there is no guarantee. In summary here's the deadlines: - Draft deadline. 17:00 Pacific, today, Feb. 3rd, 2012 - Deadline for agenda requests. 17:00 Pacific, Monday, Feb. 6th. - Deadline for .ppt for topics for which there is no draft. 17:00 Pacific, Monday, Feb. 6th. - Deadline for .ppt presentations for drafts. 17:00 Pacific, Friday, Feb. 10th. We'll shortly send the Webex details for folks that are participating remotely. As a reminder, if you have not replied to the doodle, please do so now: http://doodle.com/d86zeaqng28eh3ie We need a fairly firm headcount so we have things properly organized for the 3 Rs: remote participation, recording and refreshments. Thanks, Mary. From bo.burman@ericsson.com Fri Feb 3 14:20:28 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 53D2021F8547 for ; Fri, 3 Feb 2012 14:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 PGZbpvDQmzz0 for ; Fri, 3 Feb 2012 14:20:27 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 601E321F8530 for ; Fri, 3 Feb 2012 14:20:27 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-0b-4f2c5da94c26 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 38.7D.02613.9AD5C2F4; Fri, 3 Feb 2012 23:20:25 +0100 (CET) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.126]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 3 Feb 2012 23:20:25 +0100 From: Bo Burman To: "clue@ietf.org" Date: Fri, 3 Feb 2012 23:20:24 +0100 Thread-Topic: New informational draft on multistream conference Thread-Index: AcziwgZKdWNMSu01S5iF3Ck+HPB8zg== Message-ID: <05F760EF51FA6A4F804F9759C239313A3271CEF75F@ESESSCMS0361.eemea.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [clue] New informational draft on multistream conference 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, 03 Feb 2012 22:20:28 -0000 Dear All, I've just submitted a -00 draft with some use cases and scenarios for multi= -stream conferencing that can hopefully contribute to the discussion on the= mailing list and during the CLUE interim in a couple of week's time. Comments are welcome! https://datatracker.ietf.org/doc/draft-westerlund-clue-multistream-conferen= ce/ ---- A new version of I-D, draft-westerlund-clue-multistream-conference-00.txt h= as been successfully submitted by Bo Burman and posted to the IETF reposito= ry. Filename: draft-westerlund-clue-multistream-conference Revision: 00 Title: Multi-Stream Media Conferencing Creation date: 2012-02-03 WG ID: Individual Submission Number of pages: 20 Abstract: This memo describes a multimedia multi-party conferencing architecture based on use of multiple Real-Time Transport Protocol (RTP) streams. ---- Best Regards Bo Burman ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden| mailto: bo.burman@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Sat Feb 4 20:51: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 3CFFA21F84DE; Sat, 4 Feb 2012 20:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 TJVdX3mwyb8d; Sat, 4 Feb 2012 20:51:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131C421F84D5; Sat, 4 Feb 2012 20:50:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120205045055.28010.8062.idtracker@ietfa.amsl.com> Date: Sat, 04 Feb 2012 20:50:55 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-03.txt 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, 05 Feb 2012 04:51:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEle= presence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Allyn Romanow Mark Duckworth Andrew Pepperell Brian Baldino Filename : draft-ietf-clue-framework-03.txt Pages : 32 Date : 2012-02-04 This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-framework-03.txt From espeberg@cisco.com Mon Feb 6 11:01: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 CDAFA21F85FD for ; Mon, 6 Feb 2012 11:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.459 X-Spam-Level: X-Spam-Status: No, score=-9.459 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, 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 2jnQWSn6USZ4 for ; Mon, 6 Feb 2012 11:01:16 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 41E7621F85F0 for ; Mon, 6 Feb 2012 11:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=25104; q=dns/txt; s=iport; t=1328554875; x=1329764475; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=H0AHk1xwNZaRpIm+grxd6kr1d7cPVPaoQYf5PawepWk=; b=XwPYViK9BD+A5N9xEV7jxCqkjS6076NDq6nFLPPEE3fWGZHVNTuvCJJx oe5AfPPFmJuGHO4oSLQ9i7maDjOLj1fJVJp+BFQze3j/iZc78SpbXfyta w8ot46qVJ8w0OCrcYNPDB8TAhG2qtDB2aXIbJDoS4oisE7jbd54uCAIe5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOYiME+Q/khL/2dsb2JhbABDDoR9qUpwgQWBcgEBAQMBAQEBDwEQDQQ0BgsFBwQCAQgOAwQBAQECAgYGFwECAgIBAR8GHwkIAQEEEwgah1oJmiUBjGWSCoEvhmaDGgEpBgEtDAKEMg0CCgKCJzNjBKAyhxo4 X-IronPort-AV: E=Sophos;i="4.73,372,1325462400"; d="scan'208";a="128664915" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 06 Feb 2012 19:01:12 +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 q16J1CFg029981; Mon, 6 Feb 2012 19:01:12 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, 6 Feb 2012 20:01:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 6 Feb 2012 20:01:11 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EEC5677@XMB-AMS-214.cisco.com> In-Reply-To: <4F2B254F.9050504@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] #7: Is composed attribute a boolean or data structure Thread-Index: AcziB9AIh6yNdXEhRwCI9yCmS27iRwC9iznA References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org><4f266f4c.d0770e0a.43c6.37fd@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com><4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com><4f272344.03bd0e0a.6983.3d7e@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com><4f291525.84310e0a.69d7.fffffd3b@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com> <4F29766F.1080101@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com> <4F2B254F.9050504@alum.mit.edu> From: "Espen Berger (espeberg)" To: "Paul Kyzivat" X-OriginalArrivalTime: 06 Feb 2012 19:01:12.0751 (UTC) FILETIME=[B1CB23F0:01CCE501] 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: Mon, 06 Feb 2012 19:01:17 -0000 SSBzaG91bGQgaGF2ZSBkb2N1bWVudGVkIHRoZSB1c2UgY2FzZXMgSSB1c2VkIGJldHRlci4gSSB3 aWxsIG1ha2UgYSBzdW1tYXJ5IGR1cmluZyB0aGUgbmV4dCBkYXlzIHRoYXQgaG9wZWZ1bGx5IGlz IGNsZWFyZXIuIA0KDQpTZWUgaW5saW5lLiANCg0KLUVzcGVuIA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQu ZWR1XSANClNlbnQ6IDMuIGZlYnJ1YXIgMjAxMiAwMTowOA0KVG86IEVzcGVuIEJlcmdlciAoZXNw ZWJlcmcpDQpDYzogY2x1ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjbHVlXSAjNzogSXMgY29t cG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhIHN0cnVjdHVyZQ0KDQpPbiAyLzIvMTIg MTE6NDIgQU0sIEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpIHdyb3RlOg0KPiBIaSBQYXVsDQo+DQo+ IEkgd2lsbCBtYWtlIGEgYnJpZWYgYXR0ZW1wdCB0byBhbnN3ZXIuDQoNCkl0cyBnb29kIHRvIGdl dCBpbnRvIHRoZSBkZXRhaWxzLiBBcyBleGhpYml0ZWQgYnkgUm9uaSdzIHJlcGx5LCBpdHMgbm90 IA0KY2xlYXIgdGhhdCBhbGwgYXJlIG9uIHRoZSBzYW1lIHBhZ2UuDQoNCkVCRT4+IERldGFpbHMg YXJlIGdvb2QuIA0KDQo+IFRoZSBzY2VuYXJpb3MgYXJlIGhvdyB0byBtYXAgYSAzeCBjYW1lcmEg c3lzdGVtIHRvIGEgMnggc2NyZWVuIHN5c3RlbS4gVGhlIHRyaXBsZSBvZmZlcg0KPiAgIFN0cmVt YSA9IDEgLSAzDQo+ICAgUG9saWNpZXMgPSBTd2l0Y2hlZCwgc3RhdGljLCBjb21wb3NlZA0KDQpJ SVVDLCBpbiB0aGUgYWJvdmUgeW91IGhhdmUgc2VwYXJhdGVkIHRoZSBwb2xpY2llcyBmcm9tIHRo ZSBzdHJlYW1zIC0gDQpzb21laG93IHRoZSBwb2xpY2llcyBhcHBseSB0byBhbGwgdGhlIHN0cmVh bXMuDQoNCkl0IHdhcyBteSBpbXByZXNzaW9uIHRoYXQgZWFjaCBvZmZlcmVkIHN0cmVhbSBpcyBp bmRlcGVuZGVudCwgYW5kIG1heSBiZSANCnN0YXRpYywgc3dpdGNoZWQsIG9yIGNvbXBvc2VkLg0K DQpFQkU+PiBJdCdzIG5hdHVyYWwgdGhhdCB5b3UgaGF2ZSBhdCBsZWFzdCBvbmUgYWx0ZXJuYXRp dmUgaW4gYSBjYXB0dXJlIHNldCB3aGVyZSBhbGwgY2FwdHVyZXMgaGF2ZSB0aGUgc2FtZSBwb2xp Y2llcy4gSWYgd2Ugd3JpdGUgdGhlbSBvdXQgYXMgdGhlIHNhbWUgcG9saWN5IG9uIGluZGl2aWR1 YWwgY2FwdHVyZSBzdHJlYW1zIHRoYXQgc2hvdWxkIG1lYW4gdGhlIHNhbWUgYXMgYSBzaW5nbGUg cG9saWN5IG9uIGFsbCBjYXB0dXJlcyBpbiBhIGNhcHR1cmUgc2V0IGFsdGVybmF0aXZlLiAgDQoN ClNvLCBJIHdvdWxkIGFzc3VtZSB0aGF0IGlmIHRoZSAzIGNhbWVyYSBzeXN0ZW0gd2FudHMgdG8g YWNjb21tb2RhdGUgDQpkaXNzaW1pbGFyIHN5c3RlbXMsIGl0IHdvdWxkIG9mZmVyIG1vcmUgdGhh biB0aHJlZSBzdHJlYW1zLiBFLmcuOg0KDQotIGxlZnQsIHN0YXRpYyAoIWNvbXBvc2VkKQ0KLSBt aWRkbGUsIHN0YXRpYw0KLSByaWdodCwgc3RhdGljDQotIGNvbXBvc2VkIChsZWZ0LCBtaWRkbGUs IGFuZCByaWdodCkNCi0gc3dpdGNoZWQgKGFjdGl2ZSBzcGVha2VyKQ0KLSAuLi4NCg0KRUJFPj4g QWdyZWUsIEkgbWFkZSBhbiBleGFtcGxlIHdoZXJlIGFsc28gdHdvIHNjcmVlbiBhbHRlcm5hdGl2 ZXMgYXJlIGxpc3RlZC4gSW4gdGhlIGV4YW1wbGUgTGVmdCwgbWlkZGxlLCByaWdodCByZXByZXNl bnQgdGhlIGNhbWVyYXMsIFZDeCBhcmUgbG9naWNhbCBzdHJlYW1zLCBJIGFsc28gYXNzdW1lIHRo YXQgdGhlIG9ubHkgdGhyZWUgc3RyZWFtcyBhbHRlcm5hdGl2ZSBhbGxvd2VkIGlzIHRvIHJlcXVl c3QgYWxsIDN4IGNhbWVyYSBzdHJlYW1zLiANClN0YXRpYyAzLXN0cmVhbXMge2xlZnQsIG1pZGRs ZSwgcmlnaHR9DQpTdGF0aWMgMi1zdHJlYW1zIHtsZWZ0LCBtaWRkbGV9LCB7bGVmdCwgcmlnaHR9 IG9yIHttaWRkbGUsIHJpZ2h0fQ0KU3RhdGljIDEtc3RyZWFtIHtsZWZ0fSwge21pZGRsZX0gb3Ig e3JpZ2h0fQ0KQ29tcG9zZWQgMi1zdHJlYW1zIHtWQzAsIFZDMX0gDQpDb21wb3NlZCAxLXN0cmVh bSB7VkMyfSANClN3aXRjaGVkIDItc3RyZWFtcyB7VmMzLCBWYzR9IA0KU3dpdGNoZWQgMS1zdHJl YW0ge1ZDNX0gDQooV2hhdCBpcyB0aGUgcHJlZmVycmVkIGFsdGVybmF0aXZlIGZvciBhIHR3byBz Y3JlZW4gc3lzdGVtPykNCg0KPiBBcyBhIHJlY2VpdmVyICh3aXRoIDJ4IHNjcmVlbnMpIEkgd291 bGQgZG8gdGhpcyBjaG9pY2VzDQo+DQo+IDEpIEhvdyBtYW55IHN0cmVhbXMgdG8gcmVjZWl2ZQ0K PiAgICAgMSA9PiAgVGhlIHRyaXBsZSBzZW5kcyBhIHNpbmdsZSBzdHJlYW0gYnkgc29tZSBzZW5k ZXIgcHJlZmVycmVkIHBvbGljeQ0KDQpUaGlzIHJlYWxseSBjb25mdXNlcyBtZS4NCkkgYXNzdW1l ZCB0aGF0IGlmIHRoZSByZWNlaXZlciBvbmx5IHdhbnRzIG9uZSBzdHJlYW0gKHBlcmhhcHMgYmVj YXVzZSBpdCANCmhhcyBvbmx5IG9uZSBzY3JlZW4pLCBpdCB3b3VsZCBzaW1wbHkgcGljayBvbmUg b2YgdGhlIHN0cmVhbXMgb2ZmZXJlZCANCihhcyB5b3UgZGVzY3JpYmVkLCBpdCB3b3VsZCBiZSBv bmUgb2YgdGhlIHRocmVlLikNCg0KWW91IHNlZW0gdG8gYmUgc3VnZ2VzdGluZyB0aGF0IHRoZSBh Y3Qgb2YgcmVxdWVzdGluZyBvbmUgc3RyZWFtIHdpbGwgDQpjYXVzZSB0aGUgc2VuZGVyIHRvIGFs dGVyIHRoZSBwb2xpY3kgdXNlZCB0byBwcm9kdWNlIHRoYXQgc3RyZWFtLiBUaGF0IA0KbWFrZXMg bm8gc2Vuc2UgdG8gbWUuDQoNCkVCRT4+IEluIHRoZSB1c2UgY2FzZXMgSSBhc3N1bWVkIHRoYXQg YSBtZWRpYSBjb25zdW1lciB3YW50IHRvIHNlbGVjdCB0aGUgYWx0ZXJuYXRpdmUgdGhhdCB0aGUg bWVkaWEgcHJvdmlkZXIgdGhpbmsgaXMgbW9zdCBzZW5zaWJsZSBmb3IgYSB0aGUgbnVtYmVyIG9m IHN0cmVhbXMgc2VsZWN0ZWQuIEUuZy4gaWYgYW4gZW5kcG9pbnQgcmVxdWVzdCBhIHNpbmdsZSBj YXB0dXJlIHN0cmVhbXMgZnJvbSBhIHRyaXBsZSBjYW1lcmEgZW5kcG9pbnQsIHRoZSBwcmVmZXJy ZWQgYWx0ZXJuYXRpdmUgbWlnaHQgYmUgYSBjb21wb3NlZCB2aWV3LiBJZiB0aGUgbWVkaWEgY29u c3VtZXIgd2FudHMgYSBwYXJ0aWN1bGFyIGFsdGVybmF0aXZlLCBpdCBjYW4gcGFyc2UgdGhlbSBh bGwgYW5kIHNlbGVjdCB0aGUgb25lIHRoYXQgbWF0Y2hlcyB3aGF0IGl0IHdhbnRzLiANCg0KDQo+ ICAgICAyID0+ICBUaGUgdHJpcGxlIHNlbmRzIHR3byBzdHJlYW1zIGJ5IHNvbWUgcG9saWN5DQoN Ck1vcmUgb2Ygc2FtZSBjb25mdXNpb24gYWJvdmUuIElTVE0gdGhhdCB0aGUgaWYgdGhlIHJlY2lw aWVudCB3YW50cyB0d28gDQpzdHJlYW1zIHRvIGRpc3BsYXksIHRoYXQgaXQgc2hvdWxkIGJlIGNo b29zaW5nIHR3byBiYXNlZCBvbiB0aGUgDQpkZXNjcmlwdGlvbnMuIE5vdCB0aGF0IHRoZSBzZW5k ZXIgZGVjaWRlcyB3aGF0IHRvIGluY2x1ZGUgaW4gdGhlIHR3byANCmJhc2VkIG9uIHRoZSBmYWN0 IHRoYXQgdHdvIGhhdmUgYmVlbiByZXF1ZXN0ZWQuDQoNCkVCRT4+IFNhbWUgYXMgYWJvdmUuIA0K PiAgICAgMyA9PiAgVGhlIHRyaXBsZSBzZW5kcyB0aHJlZSBjYW1lcmFzIGluIHNwYXRpYWwgb3Jk ZXIsIGFuZA0KPiAgICAgICAgdGhlIHJlY2VpdmVyIGRlY2lkZSBob3cgdG8gcmVuZGVyIGFjcm9z cyB0d28gc2NyZWVucw0KDQpUaGlzIGlzIGNsZWFybHkgdGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJk IGNhc2UuDQoNCj4gMikgV2hpY2ggc3dpdGNoaW5nIHBvbGljeQ0KPiAgICBTdGF0aWMgPT4gIFRo ZSByZXF1ZXN0ZXIgYXNrIGZvciBleHBsaWNpdCBjYW1lcmEgc3RyZWFtcywgZS5nLiBjYW0xIG9y IChjYW0yK2NhbTMpDQo+ICAgIFN3aXRjaGVkL0NvbXBvc2VkID0+ICBUaGUgdHJpcGxlIGNob29z ZXMgdGhlIHN0cmVhbXMgdG8gc2VuZCwgZS5nLiB0aGUgdHdvIGxvdWRlc3Qgc2VnbWVudHMgb3Ig aXQgY291bGQgbWFrZSBhIG5pY2UgcmVuZGVyaW5nIG9mIDN4IGNhbWVyYXMgcmVuZGVyZWQgb24g dHdvIHN0cmVhbXMuDQo+DQo+IEkgYXNzdW1lIHRoYXQgeW91IHdvbid0IHVzZSBkaWZmZXJlbnQg c3dpdGNoaW5nIHBvbGljaWVzIGZvciB0aGUgZGlmZmVyZW50IHN0cmVhbXMsIHNpbmNlIGl0IGdp dmVzIHRoZSBzZW5kZXIgb2YgbWVkaWEgdGhlIGNoYW5jZSB0byBvcHRpbWl6ZSB3aGF0IGl0IHNl bmQgb24gdGhlIHN0cmVhbXMgcmVxdWVzdGVkLg0KDQpXaGF0IEkgdGFrZSBmcm9tIHRoaXMgaXMg dGhhdCB5b3UgYXJlIGFzc3VtaW5nIGEgc2luZ2xlIHBvbGljeSB0aGF0IA0KaW1wYWN0cyBhbGwg dGhlIHN0cmVhbXMgc2VudCB0byB0aGlzIHJlY2lwaWVudC4NCg0KQnV0IEkgdGhvdWdodCB0aGUg aW50ZW50IHdhcyB0aGF0IHRoZSBzZW5kZXIgZGVzY3JpYmVzICplYWNoKiBhdmFpbGFibGUgDQpz dHJlYW0gd2l0aCBhbiBpbmRlcGVuZGVudCBwb2xpY3ksIGFuZCB0aGUgcmVjaXBpZW50IGp1c3Qg Y2hvb3NlcyB0aG9zZSANCnRoYXQgaXQgd2lzaGVzLg0KDQpFQkU+PiBJdCdzIGEgbGltaXRhdGlv biB0byBvbmx5IGFsbG93IHRoZSBzYW1lIHBvbGljeSBvbiBhbGwgc3RyZWFtcyByZXF1ZXN0ZWQs IGJ1dCBpbiBtYW55IHVzZSBjYXNlcyBJIHRoaW5rIGl0J3MgbmF0dXJhbCB0byB1c2UgdGhlIHNh bWUgcG9saWN5IGFjcm9zcyBtdWx0aXBsZSBzdHJlYW1zLiANCg0KPiBUaGUgJ3NpdGUnIHN3aXRj aGluZyBwb2xpY3kgbWFrZXMgbW9zdCBzZW5zZSBmcm9tIGFuIE1DVS4gSSBpbnRlcnByZXRlIHRo ZSBwb2xpY3kgYXMgdHJ5IHRoZSBiZXN0IHlvdSBjYW4gdG8gc3dpdGNoIGluIGFsbCBjYXB0dXJl IHN0cmVhbXMgZnJvbSBhIHJvb20gd2hlbiB0aGUgcm9vbSBpcyBhY3RpdmUuIEV4YW1wbGUNCj4g ICBSb29tIEEgaGFzIHR3byBjYW1lcmFzDQo+ICAgUm9vbSBCIGhhcyB0aHJlZSBjYW1lcmFzDQo+ ICAgUm9vbSBDIGhhcyBhIHNpbmdsZSBjYW1lcmENCj4gICBSb29tIEQgaGFzIHRocmVlIHNjcmVl bnMNCj4NCj4gMSkgUm9vbSBEIHJlY2VpdmVzIG1lZGlhIGZyb20gcm9vbSBBIGFuZCBDDQo+IDIp IFJvb20gQiBzdGFydHMgdGFsa2luZw0KPiAzYSkgd2l0aCBzaXRlIHN3aXRjaGluZw0KPiAgICBS b29tIEQgcmVjZWl2ZXMgbWVkaWEgb25seSBmcm9tIEQgYWNyb3NzIGFsbCB0aHJlZSBzY3JlZW5z DQo+IDNiKSB3aXRoIHNlZ21lbnQgc3dpdGNoaW5nDQo+ICAgIFJvb20gRCByZWNlaXZlcyBtZWRp YSBmcm9tIEEsIGFuZCB0aGUgbmV3IGFjdGl2ZSBzZWdtZW50IGZyb20gRA0KDQpJIGRvbid0IGV2 ZW4gd2FudCB0byAqc3RhcnQqIHRhbGtpbmcgYWJvdXQgdGhpcyB1bnRpbCB0aGUgc3R1ZmYgYWJv dmUgaXMgDQpyZXNvbHZlZC4NCg0KRUJFPj4gYWdyZWUsIHdlIGNhbiB3YWl0IHdpdGggdGhpcyBv bmUuDQoNCglUaGFua3MsDQoJUGF1bA0KDQo+IENoZWVycw0KPg0KPiAtRXNwZW4NCj4NCj4NCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF1bCBLeXppdmF0 DQo+IFNlbnQ6IDEuIGZlYnJ1YXIgMjAxMiAxODoyOQ0KPiBUbzogY2x1ZUBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9y IGRhdGEgc3RydWN0dXJlDQo+DQo+IEVzcGVuLA0KPg0KPiBJU1RNIHRoYXQgZm9yIGEgc3dpdGNo ZWQgc3RyZWFtIHlvdSBoYXZlOg0KPiAtIHRoZSBzZXQgb2YgY2FuZGlkYXRlIHN0cmVhbXMgdG8g YmUgc3dpdGNoZWQgYW1vbmcNCj4gLSBhbiBhbGdvcml0aG0gZm9yIHBpY2tpbmcgYW1vbmcgdGhl bQ0KPg0KPiBJZiB0aGUgcmVjZWl2ZXIgaGFzIG11bHRpcGxlIHNjcmVlbnMsIHRoZW4gdGhlcmUg d2lsbCBiZSBhIHN0cmVhbSBmb3INCj4gZWFjaCBvbmUsIGFuZCBlYWNoIGNvdWxkIGhhdmUgZGlm ZmVyZW50IGNhbmRpZGF0ZSBpbnB1dCBzdHJlYW1zIGFuZCBhDQo+IGRpZmZlcmVudCBwb2xpY3ku DQo+DQo+IFdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGFzICJzaXRlIHN3aXRjaGluZyIgYWRkcyBh bm90aGVyIHdyaW5rbGUsIHNpbmNlDQo+IGl0IGlzIGNvdXBsaW5nIHRoZSBzd2l0Y2hpbmcgcG9s aWNpZXMgZm9yIG11bHRpcGxlIHN0cmVhbXMuIEFsc28sIEknbQ0KPiBub3Qgc3VyZSBob3cgaXQg d29ya3MgaWYgdGhlIHNpdGVzIGhhdmUgZGlmZmVyaW5nIG51bWJlcnMgb2Ygc2NyZWVucyBhbmQN Cj4gY2FtZXJhcy4gSG93IHdvdWxkIHlvdSBkZXNjcmliZSB0aGUgaW5kaXZpZHVhbCBzdHJlYW1z IGZyb20gdGhlIE1DVSBzbw0KPiB0aGF0IGEgcm9vbSBjb3VsZCBzZWxlY3QgYW4gYXBwcm9wcmlh dGUgc2V0IG9mIHN0cmVhbXMgdG8gZ2V0IHNpdGUNCj4gc3dpdGNoaW5nPw0KPg0KPiBJdCB3b3Vs ZCBiZSBoZWxwZnVsICh0byBtZSBhbnl3YXkpIGlmIHlvdSBjb3VsZCBkZXNjcmliZSB0aGUgaW50 ZXJlc3RpbmcNCj4gY2FzZXMgYnkgZW51bWVyYXRpbmcgdGhlIG9mZmVyZWQgc3RyZWFtcyB0b2dl dGhlciB3aXRoIHRoZSBpbnB1dHMgYW5kDQo+IHRoZSBhbGdvcml0aG0gdXNlZCBmb3IgZWFjaC4g UmlnaHQgbm93LCBJJ20gbm90IHN1cmUgaG93IHRvIGRvIHRoYXQuDQo+DQo+IAlUaGFua3MsDQo+ IAlQYXVsDQo+DQo+IE9uIDIvMS8xMiA4OjAwIEFNLCBFc3BlbiBCZXJnZXIgKGVzcGViZXJnKSB3 cm90ZToNCj4+IEkgd291bGQgc3RpbGwgY2FsbCBpdCBzd2l0Y2gtcG9saWN5LCBlLmcuIHRoZW4g cG9zc2libGUgdmFsdWVzIGNvdWxkIGJlOg0KPj4gKiBTaXRlOiBDaGFuZ2UgYWxsIGF0IHRoZSBz YW1lIHRpbWUNCj4+ICogU2VnbWVudDogT25seSBjaGFuZ2UgdGhlIGFjdGl2ZSBzZWdtZW50DQo+ PiAqIFJvdW5kIHJvYmluOiBDaGFuZ2UgYWN0aXZlIHNlZ21lbnQgYW5kIHRoZW4gY2hhbmdlIHRv IG90aGVyIHNlZ21lbnRzIGluIDEwIHNlYyBpbnRlcnZhbHMuDQo+Pg0KPj4gSG93IHlvdSBzd2l0 Y2ggYmV0d2VlbiBzdHJlYW1zIGFuZCBob3cgeW91IHJlbmRlciBoYXMgZGlmZmVyZW50IHJlcXVp cmVtZW50cyBhbmQgcG9saWNpZXMsIHNvIEkgZmluZCBpdCB2ZXJ5IHVzZWZ1bCB0byBkaXNjdXNz IHRoZW0gYXMgdHdvIHNlcGFyYXRlIGlzc3VlcyB0byBhdm9pZCBjb25mdXNpb24uDQo+Pg0KPj4g Q2hlZXJzDQo+Pg0KPj4gLUVzcGVuDQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiBGcm9tOiBSb25pIEV2ZW4gW21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXQ0K Pj4gU2VudDogMS4gZmVicnVhciAyMDEyIDExOjMwDQo+PiBUbzogRXNwZW4gQmVyZ2VyIChlc3Bl YmVyZyk7IGNsdWVAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBv c2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YSBzdHJ1Y3R1cmUNCj4+DQo+PiBIaSBFc3Bl biwNCj4+IEkgY2FsbGVkIHNpdGUgb3Igc2VnbWVudCBzd2l0Y2ggYSBwb2xpY3kgYnV0IEkgYW0g bm90IHN1cmUgdGhhdCBpdCBpcyBhIHN3aXRjaCBwb2xpY3kgYnkgaXRzZWxmIHNpbmNlIHNlZ21l bnQgc3dpdGNoIGZvciBleGFtcGxlIGNhbiBoYXBwZW4gYmFzZWQgb24gYWN0aXZlIHNwZWFrZXJz IG9yIHNvbWUgcm91bmQgcm9iaW4gdGltaW5nIHdoaWNoIGlzIHRoZSBzd2l0Y2hpbmcgcG9saWN5 Lg0KPj4gUm9uaQ0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206 IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpIFttYWlsdG86ZXNwZWJlcmdAY2lzY28uY29tXQ0KPj4+ IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMzEsIDIwMTIgNTozOCBQTQ0KPj4+IFRvOiBSb25pIEV2 ZW47IGNsdWVAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSRTogW2NsdWVdICM3OiBJcyBjb21wb3Nl ZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4+PiBzdHJ1Y3R1cmUNCj4+Pg0KPj4+IEhp IFJvbnkNCj4+Pg0KPj4+IFRvIGNob29zZSBiZXR3ZWVuIHNpdGUgYW5kIHNlZ21lbnQgc3dpdGNo IGlzIG1vcmUgYSBwb2xpY3kgdGhhbiBhDQo+Pj4gPHZpZGVvLWxheW91dD4sIHNvIGluIHRoYXQg Y2FzZSBJIHdvdWxkIGFyZ3VlIHRoYXQgeW91IGNvdWxkIG9mZmVyIGENCj4+PiBDYXB0dXJlIHN0 cmVhbSB3aXRoIGEgc3dpdGNoLXBvbGljeSA9IHtzaXRlLCBzZWdtZW50fQ0KPj4+DQo+Pj4gTXkg cG9pbnQgYWJvdXQgaW50ZXJvcGVyYWJpbGl0eSBpcyB0aGF0IGEgc2luZ2xlIGNvbXBvc2VkIHN0 cmVhbSB3aXRoDQo+Pj4gYWx0ZXJuYXRpdmUgbGF5b3V0cyBhcmUgZWFzaWVyIHRvIHVuZGVyc3Rh bmQsIHRoYW4gbXVsdGlwbGUgY2FwdHVyZQ0KPj4+IHN0cmVhbXMgd2l0aCBhbHRlcm5hdGl2ZSBj b25maWd1cmF0aW9ucy4gVGhlIGxhc3QgcmVxdWlyZXMgdG8gcGljayB0aGUNCj4+PiBmaXJzdCBv bmUgb3IgcmVxdWlyZXMgc29tZSBzb3J0IG9mIGRlZmF1bHQgbWFya2luZy4NCj4+Pg0KPj4+IENo ZWVycw0KPj4+DQo+Pj4gLUVzcGVuDQo+Pj4NCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4gRnJvbTogUm9uaSBFdmVuIFttYWlsdG86cm9uLmV2ZW4udGx2QGdtYWlsLmNv bV0NCj4+PiBTZW50OiAzMS4gamFudWFyIDIwMTIgMDA6MDYNCj4+PiBUbzogRXNwZW4gQmVyZ2Vy IChlc3BlYmVyZyk7IGNsdWVAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSRTogW2NsdWVdICM3OiBJ cyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4+PiBzdHJ1Y3R1cmUNCj4+ Pg0KPj4+IEhpIEVzcGVuLA0KPj4+IElmIHRoZSBwcm92aWRlciB3YW50cyB0byBvZmZlciBzaXRl IHN3aXRjaCBhbmQgc2VnbWVudCBzd2l0Y2ggb3B0aW9uIHRvDQo+Pj4gdGhlIGNvbnN1bWVyIGhl IGNhbm5vdCBkbyBpdCBqdXN0IHdpdGggQS4gdGhpcyBpcyBhIGJhc2ljIHVzZSBjYXNlLg0KPj4+ DQo+Pj4gSW4gZ2VuZXJhbCwgeW91ciBvcHRpb24gZG9lcyBub3QgcHJvdmlkZSBhbnkgaW50ZXJv cGVyYWJpbGl0eSBzaW5jZQ0KPj4+IGJvdGggc2lkZXMgbWF5IGhhdmUgZGlmZmVyZW50IHZpZXdz IHdoYXQgY29tcG9zZWQgbWVhbnMuIEluIHRoZQ0KPj4+IGZyYW1ld29yayBleGFtcGxlIG9mIGEg UElQIGFzIGNvbXBvc2VkIGltYWdlIGl0IGlzIGFuIGFzc3VtcHRpb24gdGhhdA0KPj4+IGlmIHRo ZSBwcm92aWRlciBvZmZlcnMgdGhpcyBjb21wb3NlZCBvZmZlciwgdGhlIGNvbnN1bWVyIGNhbiB1 bmRlcnN0YW5kDQo+Pj4gdGhhdCBpdCBpcyBhIFBJUCBtaXggYnV0IHRoZXJlIGlzIG5vdGhpbmcg aW4gdGhlIG9mZmVyIHRoYXQgd2lsbA0KPj4+IGluZGljYXRlIHRoYXQgaXQgaXMuDQo+Pj4NCj4+ PiBSb25pDQo+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTog RXNwZW4gQmVyZ2VyIChlc3BlYmVyZykgW21haWx0bzplc3BlYmVyZ0BjaXNjby5jb21dDQo+Pj4+ IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAzMCwgMjAxMiA1OjIxIFBNDQo+Pj4+IFRvOiBSb25pIEV2 ZW47IGNsdWVAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUkU6IFtjbHVlXSAjNzogSXMgY29tcG9z ZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhDQo+Pj4+IHN0cnVjdHVyZQ0KPj4+Pg0KPj4+ PiBIaSBSb25pDQo+Pj4+DQo+Pj4+IElmIHlvdeKAmXJlIGEgcGFydGljdWxhciB1c2UgY2FzZXMg cmVxdWlyZXMgY29udHJvbCBvdmVyIHRoZSBjb21wb3NlZA0KPj4+PiBsYXlvdXRzIHlvdSBuZWVk IGEpIGFuZCBiKS4gSW4gbXkgZXhhbXBsZSBJIHVzZWQgYSBzaW5nbGUNCj4+Pj4gYWR2ZXJ0aXNl bWVudCBjb21wb3NlZCBzdHJlYW0gd2l0aCBvcHRpb25hbCBtZXRhLWluZm9ybWF0aW9uIGFib3V0 DQo+Pj4+IHBvc3NpYmxlIGxheW91dCBjaG9pY2VzLiBBIHJlY2VpdmVyIHRoYXQgd2FudHMgdGhl IGRlZmF1bHQgY29tcG9zZWQNCj4+Pj4gbGF5b3V0IGNhbiByZXF1ZXN0IHRoZSBjb21wb3NlZCBz dHJlYW0gYW5kIHNraXAgdGhlIG9wdGlvbmFsIHZpZGVvLQ0KPj4+IGxheW91dCBpbmZvcm1hdGlv bi4NCj4+Pj4gT3B0aW9uYWxseSB5b3UgY291bGQgcmVxdWVzdCB0aGUgc2FtZSBjb21wb3NlZCBz dHJlYW0gd2l0aCBsYXlvdXRzDQo+Pj4+IGhpbnRzIGZvciB0aGUgcmVjZWl2ZXIuDQo+Pj4+DQo+ Pj4+IEZvciBtZSB1c2UgY2FzZSBjKSBkb2VzIG5vdCBpbmNsdWRlIHRoZSBzZWxlY3Rpb24gbWVj aGFuaXNtcywgb25seQ0KPj4+IHRoZQ0KPj4+PiBjb250ZW50IHlvdSBzZWUgaW4gdGhlIHZpZGVv IHN0cmVhbS4NCj4+Pj4NCj4+Pj4gQ2hlZXJzDQo+Pj4+DQo+Pj4+IC1Fc3Blbg0KPj4+Pg0KPj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBSb25pIEV2ZW4gW21haWx0 bzpyb24uZXZlbi50bHZAZ21haWwuY29tXQ0KPj4+PiBTZW50OiAzMC4gamFudWFyIDIwMTIgMTU6 MzkNCj4+Pj4gVG86IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpOyBjbHVlQGlldGYub3JnDQo+Pj4+ IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4g b3IgZGF0YQ0KPj4+PiBzdHJ1Y3R1cmUNCj4+Pj4NCj4+Pj4gSGkgRXNwZW4sDQo+Pj4+IElmIHlv dSB3aWxsIGxvb2sgYXQgdGhlIG5vdGVzIGZyb20gdGhlIGxhc3QgY2FsbCB0aGVyZSB3YXMgYSBz dXBwb3J0DQo+Pj4+IHRoYXQgYSkgaXMgbm90IGVub3VnaC4gSGF2aW5nIGp1c3QgY29tcG9zZSBk b2VzIG5vdCBhZGRyZXNzIGV2ZW4gdGhlDQo+Pj4+IHVzZSBjYXNlcyBJIHByb3ZpZGVkIHdoaWNo IGFyZSBhbHNvIGJhc2VkIG9uIHRoZSB1c2UgY2FzZSBkcmFmdC4NCj4+Pj4NCj4+Pj4NCj4+Pj4g SSBhbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IEMgc2luY2Ugd2hhdCBpbiB0aGUgY29tcG9z ZWQgc3RyZWFtDQo+Pj4gY2FuDQo+Pj4+IGJlIGVpdGhlciB3aGljaCBWQyB5b3Ugc2VlIG9yIHdo YXQgaXMgdGhlIHNlbGVjdGlvbiBjcml0ZXJpYSBmb3INCj4+PiBiZWluZw0KPj4+PiBpbiBhIGNv bXBvc2VkIHN0cmVhbS4gSWYgeW91IG1lYW50IHRoZSBzZWNvbmQsIG15IHZpZXcgaXMgdGhhdCBD IGFuZA0KPj4+PiBhbHNvIGIgc2hvdWxkIGJlIGluIHRoZSBiYXNpYyBmcmFtZXdvcmsgYW5kIG5v dCBpbiBhbiBleHRlbnNpb24uDQo+Pj4+DQo+Pj4+IFJvbmkgRXZlbg0KPj4+Pg0KPj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IEVzcGVuIEJlcmdlciAoZXNwZWJl cmcpIFttYWlsdG86ZXNwZWJlcmdAY2lzY28uY29tXQ0KPj4+Pj4gU2VudDogTW9uZGF5LCBKYW51 YXJ5IDMwLCAyMDEyIDQ6MTcgUE0NCj4+Pj4+IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0Zi5vcmcN Cj4+Pj4+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJv b2xlYW4gb3IgZGF0YQ0KPj4+Pj4gc3RydWN0dXJlDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRvIGhl bHAgd2l0aCB0aGUgZGlyZWN0aW9uIG9mIHRoZSBkaXNjdXNzaW9ucyBJIHRoaW5rIGl0J3MgdXNl ZnVsDQo+Pj4gdG8NCj4+Pj4+IGRpdmlkZSB0aGUgZGlzY3Vzc2lvbnMgaW50byB0aHJlZSB1c2Ug Y2FzZXMgZm9yIGNvbXBvc2VkIHN0cmVhbXMuDQo+Pj4+PiAgICBhKSBIb3cgdG8gZXhwcmVzcyBp ZiBhIGNhcHR1cmUgc3RyZWFtIGlzIGNvbXBvc2VkIG9yIG5vdA0KPj4+Pj4gICAgYikgSG93IHRv IGV4cHJlc3MgbGF5b3V0IGNob2ljZXM/IChlLmcuIHdpdGggYSB2aWRlby1sYXlvdXQNCj4+Pj4+ IGVsZW1lbnQpDQo+Pj4+PiAgICBjKSBIb3cgdG8gZXhwcmVzcyB3aGF0J3MgaW5zaWRlIGEgY29t cG9zZWQgc3RyZWFtDQo+Pj4+Pg0KPj4+Pj4gRm9yIHVzZSBjYXNlIGEpIGEgY29tcG9zZWQgYXR0 cmlidXRlIHNob3VsZCBiZSBzdWZmaWNpZW50LCB5b3UNCj4+Pj4+IGVpdGhlciBhc2sgZm9yIHRo ZSBjb21wb3NlZCBzdHJlYW0gb3IgeW91IGRvIG5vdC4NCj4+Pj4+IEkgYWxzbyBiZWxpZXZlIHRo aXMgc2hvdWxkIGNvdmVyIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHJlcXVpcmVtZW50DQo+Pj4gd2UN Cj4+Pj4+IGhhdmUgYWNyb3NzIG11bHRpcGxlIHR5cGVzIG9mIGVuZHBvaW50cy4NCj4+Pj4+DQo+ Pj4+PiBGb3IgdXNlIGNhc2UgYikgYm90aCBtZWRpYWN0cmwgYW5kIHhjb24gdXNlcyBhPHZpZGVv LWxheW91dD4NCj4+Pj4+IGVsZW1lbnQgdG8gZGVzY3JpYmUgcG9zc2libGUgbGF5b3V0cyBhbmQg YWxzbyB0byByZXF1ZXN0IHRoZQ0KPj4+Pj4gcHJlZmVycmVkIGxheW91dCBiYXNlZCBvbiBvcHRp b25zLiAoYXMgZGVzY3JpYmVkIGluIFJvbmkncyBlbWFpbCkNCj4+Pj4+DQo+Pj4+PiBBbiBleGFt cGxlIGNvdWxkIGJlIChpbnNwaXJlZCBieSBtZWRpYWN0cmwgYW5kIHhjb24gdXNhZ2Ugb2YNCj4+ PiA8dmlkZW8tDQo+Pj4+PiBsYXlvdXQ+KToNCj4+Pj4+DQo+Pj4+PiBDTFVFIEFkdmVydGlzZW1l bnQNCj4+Pj4+ICAgICBDYXB0dXJlIGlkPTIgUHVycG9zZT1wZW9wbGUgQ29tcG9zZWQ9ZmFsc2UN Cj4+Pj4+ICAgICBDYXB0dXJlIGlkPTMgUHVycG9zZT1wZW9wbGUgQ29tcG9zZWQ9ZmFsc2UNCj4+ Pj4+ICAgICBDYXB0dXJlIGlkPTQgUHVycG9zZT1QZW9wbGUgQ29tcG9zZWQ9dHJ1ZQ0KPj4+Pj4g ICAgICAgICBWaWRlby1sYXlvdXQ9IidhdXRvbWF0aWMnLCAnZHVhbC12aWV3JywgJyBzaW5nbGUt dmlldyciDQo+Pj4+Pg0KPj4+Pj4gQ0xVRSBjb25maWd1cmUgLy8gRGVmYXVsdCBjb21wb3NlZCBz dHJlYW0NCj4+Pj4+ICAgICBDYXB0dXJlIGlkPTQNCj4+Pj4+DQo+Pj4+PiAvLyBPciBjb21wb3Nl ZCBzdHJlYW0gd2l0aCBsYXlvdXQgaGludHMNCj4+Pj4+ICAgICAgQ2FwdHVyZSBpZD00IFZpZGVv LWxheW91dD0nZHVhbC12aWV3Jw0KPj4+Pj4NCj4+Pj4+IFRoZSB2aWRlby1sYXlvdXQgZWxlbWVu dCBpcyBhIGxpc3Qgb2Ygc3RyaW5ncyBhbmQgZWFjaCBzdHJpbmcgaXMgYQ0KPj4+Pj4gbGF5b3V0 LWhpbnQgdGhhdCBjYW4gYmUgcmVxdWVzdGVkLiBWaWRlby1sYXlvdXQgaXMgb3B0aW9uYWwuIEEN Cj4+Pj4+IGxheW91dCBoaW50cyBhYm91dCB0aGUgcmVxdWVzdGVkIHJlbmRlcmluZyBhbmQgdGhl IHNvdXJjZSBpcyBmcmVlDQo+Pj4gdG8NCj4+Pj4+IHJlcGxhY2UgYW55IHN0cmVhbSBhcyBsb25n IGFzIHRoZXkgZml0IHRoZSBsYXlvdXQuDQo+Pj4+Pg0KPj4+Pj4gVXNlIGNhc2UgYykgaXMgbW9y ZSBvcGVuIGluIHRoZSBzZW5zZSB0aGF0IHdoYXQgeW91IGFjdHVhbGx5DQo+Pj4gcmVjZWl2ZQ0K Pj4+Pj4gaW4gYSBjb21wb3NlZCBzdHJlYW0gaXMgZGVwZW5kaW5nIG9uIHN0YXR1cyBvZiBhIHJv b20gb3Igd2hvIGlzIGluDQo+Pj4gYQ0KPj4+Pj4gTUNVIGNvbmZlcmVuY2UuIEUuZy4gZnJvbSBh IHJvb20geW91IGNvdWxkIGdldCBhIG1peCBvZiBkaWZmZXJlbnQNCj4+Pj4+IGNhcHR1cmUgc3Ry ZWFtIHJlcHJlc2VudGluZyBjYW1lcmFzIGFuZCBmcm9tIGEgdHJhbnNjb2RpbmcgTUNVIGl0DQo+ Pj4+PiBjb3VsZCBiZSBkaWZmZXJlbnQgcm9vbSwgZGlmZmVyZW50IGNhbWVyYXMgb3IgYW5vdGhl ciBtaXggb2YNCj4+Pj4+IHBvc3NpYmxlIGlucHV0IHZpZGVvIHN0cmVhbXMuDQo+Pj4+Pg0KPj4+ Pj4gSGF2aW5nIHN1cHBvcnQgZm9yIGJvdGggYikgYW5kIGMpIGNvdWxkIGJlIGEgZ29vZCB0ZXN0 IGZvciB0aGUNCj4+Pj4+IGV4dGVuc2liaWxpdHkgb2YgQ0xVRS4gSWYgdGhlIGJhc2lzIG9mIENM VUUgb25seSBkb2VzIHVzZSBjYXNlIGEpDQo+Pj4+PiB0aGVyZSBzaG91bGQgYmUgcm9vbSB0byBl eHRlbmQgQ0xVRSB3aXRoIHN1cHBvcnQgZm9yIGIpIGFuZCBjKSBhcyBhDQo+Pj4+PiBDTFVFICsg bGF5b3V0IGRlc2NyaXB0aW9uIGV4dGVuc2lvbi4NCj4+Pj4+DQo+Pj4+PiBDaGVlcnMNCj4+Pj4+ DQo+Pj4+PiAtRXNwZW4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBjbHVlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpj bHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4gQmVoYWxmDQo+Pj4+PiBPZiBSb25pIEV2ZW4N Cj4+Pj4+IFNlbnQ6IDMwLiBqYW51YXIgMjAxMiAxMToxOA0KPj4+Pj4gVG86IGNsdWVAaWV0Zi5v cmcNCj4+Pj4+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBh IGJvb2xlYW4gb3IgZGF0YQ0KPj4+Pj4gc3RydWN0dXJlDQo+Pj4+Pg0KPj4+Pj4gSGksDQo+Pj4+ PiBEdXJpbmcgdGhlIGxhc3QgY2FsbCBJIHZvbHVudGVlcmVkIHRvIHByb3ZpZGUgc29tZSBpbnB1 dC4NCj4+Pj4+DQo+Pj4+PiBJbiBjdXJyZW50IElFVEYgd29yayAoWENPTiwgTWVkaWFjdHJsIFdH cyB0aGVyZSBpcyBhIHZpZGVvIGxheW91dA0KPj4+Pj4gZWxlbWVudCkNCj4+Pj4+DQo+Pj4+PiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1lZGlhY3RybC1taXhlci1jb250 cm9sLQ0KPj4+PiBwYWNrYWdlLQ0KPj4+Pj4gMTQjc2VjdGlvbi00LjIuMS40LjIuMQ0KPj4+Pj4N Cj4+Pj4+IGFuZA0KPj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi14 Y29uLWNvbW1vbi1kYXRhLW1vZGVsLQ0KPj4+Pj4gMzIjc2VjdGlvbi00LjIuNyAobG9vayBhdCB2 aWRlby1sYXlvdXQpDQo+Pj4+Pg0KPj4+Pj4gSSB3b3VsZCBsaWtlIGZpcnN0IHRvIHRyeSB0byBk ZWZpbmUgdGhlIHRlcm0gImNvbXBvc2VkIHZpZGVvIiBzaW5jZQ0KPj4+PiBpdA0KPj4+Pj4gbG9v a3MgdG8gbWUgbGlrZSB3ZSBoYXZlIGRpZmZlcmVudCB2aWV3cyBoZXJlLCBhbmQgcHJvdmlkZSBt eQ0KPj4+Pj4gaW5pdGlhbCB2aWV3IG9uIHdoYXQgc2hvdWxkIGJlIGRlc2NyaWJlZC4NCj4+Pj4+ DQo+Pj4+PiBDb21wb3NlZCB2aWRlbyBjYW4gZGVzY3JpYmVzIGJvdGggdGhlIGxheW91dCBhbmQg dGhlIHNlbGVjdGlvbg0KPj4+Pj4gYWxnb3JpdGhtIGZvciBjb21wb3NpbmcgdGhlICBjb250ZW50 IG9mIHRoZSBzdWItd2luZG93cyBpbiB0aGUNCj4+Pj4gIm1peGVkIg0KPj4+Pj4gdmlkZW8uDQo+ Pj4+Pg0KPj4+Pj4gVGhlIHZpZGVvIGxheW91dCB3aGljaCBqdXN0IGRlc2NyaWJlcyB0aGUgZ2Vv bWV0cnkgb2YgdGhlIGNvbXBvc2VkDQo+Pj4+PiBpbWFnZSBhbmQgSSB0aGluayB0aGF0IHRoZSBh Ym92ZSByZWZlcmVuY2VzIHByb3ZpZGUgZ29vZCBzdHJ1Y3R1cmUNCj4+Pj4+IHRvIGRlZmluZSB0 aGlzIHBhcnQgb2YgdGhlIGNvbXBvc2VkIHZpZGVvIGF0dHJpYnV0ZS4NCj4+Pj4+DQo+Pj4+PiBU aGUgb3RoZXIgcGFydCBpcyB0aGUgYWxnb3JpdGhtIGJ5IHdoaWNoIHRoZSBwcm92aWRlciBzZWxl Y3QgdGhlDQo+Pj4+PiBjb250ZW50IG9mIGVhY2ggZWxlbWVudCBpbiB0aGUgbGF5b3V0LiBTaW5j ZSB0aGUgY29udGVudCBvZiBlYWNoDQo+Pj4+PiBlbGVtZW50IG1heSBjaGFuZ2UgZHluYW1pY2Fs bHkgYnkgdGhlIHByb3ZpZGVyIHRoaXMgYXR0cmlidXRlIG9ubHkNCj4+Pj4+IGFkZHJlc3MgdGhl IHN0YXRpYyBpbmZvcm1hdGlvbiB3aGljaCBpcyB0aGUgYWxnb3JpdGhtIGFuZCBub3QgdGhlDQo+ Pj4+PiBjdXJyZW50IGNvbnRlbnQgKHdobyB3ZSBzZWUgbm93IGluIGVhY2ggZWxlbWVudCkgd2hp Y2ggd2lsbCBuZWVkIHRvDQo+Pj4+IGJlDQo+Pj4+PiBjb252ZXllZCBhbHNvIGJ1dCBwcm9iYWJs eSBub3QgdXNpbmcgdGhpcyBhdHRyaWJ1dGUuIE5vdGUgdGhhdCB0aGUNCj4+Pj4+IGluZm9ybWF0 aW9uIGlzIHZhbGlkIGZvciBwb2ludCB0byBwb2ludCBhbmQgbXVsdGlwb2ludCBzbyB0aGUNCj4+ Pj4+IGN1cnJlbnQgY29udGVudCBzaG91bGQgcmVmbGVjdCB0aGUgVFAgZW5kIHBvaW50IGFuZCB0 aGUgc3BlY2lmaWMgVkMNCj4+Pj4+IHVzZWQgZnJvbSBpdC4NCj4+Pj4+DQo+Pj4+PiBUaGUgYWxn b3JpdGhtcyBtYXkgYmUgZ2xvYmFsIG9yIHBlciBlbGVtZW50KG9yIHN1Yi13aW5kb3cpLiBUaGUN Cj4+Pj4gZ2xvYmFsDQo+Pj4+PiBhbGdvcml0aG1zIEkgc2VlIGFyZSBzaXRlIHN3aXRjaCBvciBz ZWdtZW50IHN3aXRjaC4gVGhlIHBlciBlbGVtZW50DQo+Pj4+PiBtYXkgYmUgdm9pY2UgYWN0aXZh dGVkLCByb3VuZCByb2JpbiAoc3dpdGNoIGV2ZXJ5IHggc2Vjb25kcykgYW5kDQo+Pj4+IGZpeGVk DQo+Pj4+PiAodGhlIHNhbWUgVkMgaXMgZGlzcGxheWVkIHRoZXJlIChtYXkgYmUgY2hhbmdlZCBi eSBzb21lIGNvbnRyb2wNCj4+Pj4+IG1lY2hhbmlzbSkNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gUm9u aQ0KPj4+Pj4NCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206 IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24N Cj4+Pj4gQmVoYWxmDQo+Pj4+Pj4gT2YgY2x1ZSBpc3N1ZSB0cmFja2VyDQo+Pj4+Pj4gU2VudDog VHVlc2RheSwgSmFudWFyeSAyNCwgMjAxMiAxMjo0MyBBTQ0KPj4+Pj4+IFRvOiBkcmFmdC1pZXRm LWNsdWUtZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnOw0KPj4+Pj4+IG1hcnkuaWV0Zi5iYXJuZXNA Z21haWwuY29tDQo+Pj4+Pj4gQ2M6IGNsdWVAaWV0Zi5vcmcNCj4+Pj4+PiBTdWJqZWN0OiBSZTog W2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4+Pj4+ PiBzdHJ1Y3R1cmUNCj4+Pj4+Pg0KPj4+Pj4+ICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBi b29sZWFuIG9yIGRhdGEgc3RydWN0dXJlDQo+Pj4+Pj4NCj4+Pj4+PiBDaGFuZ2VzIChieSBtYXJ5 LmlldGYuYmFybmVzQOKApik6DQo+Pj4+Pj4NCj4+Pj4+PiAgICAqIHR5cGU6ICBkZWZlY3QgPT4g ICB0YXNrDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IC0tDQo+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAt DQo+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLQ0KPj4+PiAtDQo+Pj4+ Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLQ0KPj4+Pj4gLQ0KPj4+Pj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0NCj4+Pj4+PiAtLS0tDQo+Pj4+Pj4gICAg UmVwb3J0ZXI6ICBtYXJ5LmlldGYuYmFybmVzQOKApiAgfCAgICAgICBPd25lcjogIGRyYWZ0LWll dGYtY2x1ZS0NCj4+Pj4+PiBmcmFtZXdvcmtA4oCmDQo+Pj4+Pj4gICAgICAgIFR5cGU6ICB0YXNr ICAgICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCj4+Pj4+PiAgICBQcmlvcml0eTog IG1ham9yICAgICAgICAgICAgICAgfCAgIE1pbGVzdG9uZToNCj4+Pj4+PiBDb21wb25lbnQ6ICBm cmFtZXdvcmsgICAgICAgICAgIHwgICAgIFZlcnNpb246DQo+Pj4+Pj4gICAgU2V2ZXJpdHk6ICBB Y3RpdmUgV0cgRG9jdW1lbnQgIHwgIFJlc29sdXRpb246DQo+Pj4+Pj4gICAgS2V5d29yZHM6ICAg ICAgICAgICAgICAgICAgICAgIHwNCj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IC0NCj4+Pj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+Pj4+IC0NCj4+Pj4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+Pj4+PiAtDQo+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLQ0KPj4+Pj4+IC0tLS0NCj4+Pj4+Pg0KPj4+Pj4+IFRpY2tldCBV Ukw6DQo+Pj4+Pj4gPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2NsdWUvdHJhYy90aWNr ZXQvNyNjb21tZW50OjI+DQo+Pj4+Pj4gY2x1ZTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvY2x1 ZS8+DQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4+IGNsdWUgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gY2x1ZUBpZXRmLm9y Zw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPj4+ Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+PiBjbHVlIG1haWxpbmcgbGlzdA0KPj4+Pj4gY2x1ZUBpZXRmLm9yZw0KPj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo+Pj4NCj4+DQo+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGNsdWUg bWFpbGluZyBsaXN0DQo+PiBjbHVlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg0K From pkyzivat@alum.mit.edu Mon Feb 6 11:52: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 6281421F872B for ; Mon, 6 Feb 2012 11:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 C7fa-6IIyfX0 for ; Mon, 6 Feb 2012 11:52:04 -0800 (PST) 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 73DE321F863B for ; Mon, 6 Feb 2012 11:52:03 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Wjdn1i0021ap0As5Bjs3Qw; Mon, 06 Feb 2012 19:52:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id Wjs31i01c07duvL3ijs3pv; Mon, 06 Feb 2012 19:52:03 +0000 Message-ID: <4F302F62.9070107@alum.mit.edu> Date: Mon, 06 Feb 2012 14:52:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: CLUE References: <270518902.1328557782838.JavaMail.nobody@jva2wl006.webex.com> In-Reply-To: <270518902.1328557782838.JavaMail.nobody@jva2wl006.webex.com> X-Forwarded-Message-Id: <270518902.1328557782838.JavaMail.nobody@jva2wl006.webex.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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, 06 Feb 2012 19:52:05 -0000 Hello Clue Working Group, Clue Working Group invites you to attend this online meeting. Topic: CLUE WG design team Date: Tuesday, February 7, 2012 Time: 9:00 am, Central Standard Time (Chicago, GMT-06:00) Meeting Number: 648 028 177 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=149709907&UID=1233737067&PW=NN2JiY2RiNTQz&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=149709907&UID=1233737067&PW=NN2JiY2RiNTQz&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code:648 028 177 ------------------------------------------------------- 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=149709907&UID=1233737067&ICS=MI&LD=1&RD=2&ST=1&SHA2=WZePToG0XatiHLmsQDhCZZB9aTZlNDXU6CbIXk02Nk0=&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:+14086003600x648028177# 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. From Mark.Duckworth@polycom.com Mon Feb 6 12:17:57 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 902DA21F874F for ; Mon, 6 Feb 2012 12:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 bHb5lU8kdLC0 for ; Mon, 6 Feb 2012 12:17:55 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id BAAD521F86B6 for ; Mon, 6 Feb 2012 12:17:48 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 6 Feb 2012 12:17:47 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 6 Feb 2012 12:17:45 -0800 Thread-Topic: Summary of changes to the framework document Thread-Index: AczlDEU6GNXUZR8WQqSL2/2kvzhckA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB202558@CRPMBOXPRD01.polycom.com> 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_44C6B6B2D0CF424AA90B6055548D7A6102FB202558CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Summary of changes to the framework document 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, 06 Feb 2012 20:17:57 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB202558CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The -03 version of the document is a reorganization to make the material mo= re readable and hopefully clarify some of the points that were unclear. It= also addresses many of the -02 version review comments from the email list= . It does not attempt to resolve any of the open issues from the issue tra= cker. We tried to make it easier to read by more concisely describing the key poi= nts of the main elements of the framework - spatial relationships, media ca= ptures, capture sets, simultaneous transmission sets, individual encodings,= and encoding groups. Some of the example material that was in various sec= tions of version 02 is now moved into the examples section. Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB202558CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The -03 version = of the document is a reorganization to make the material more readable and = hopefully clarify some of the points that were unclear.  It also addre= sses many of the -02 version review comments from the email list.  It = does not attempt to resolve any of the open issues from the issue tracker.<= o:p>

 

We tried to make it easier to read by more concisely describing the key p= oints of the main elements of the framework – spatial relationships, = media captures, capture sets, simultaneous transmission sets, individual en= codings, and encoding groups.  Some of the example material that was i= n various sections of version 02 is now moved into the examples section.

 

= Mark

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB202558CRPMBOXPRD01p_-- From pkyzivat@alum.mit.edu Mon Feb 6 13:31: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 ACE2A11E8083 for ; Mon, 6 Feb 2012 13:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 xa-pa4+APN1t for ; Mon, 6 Feb 2012 13:31:55 -0800 (PST) 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 E141111E8080 for ; Mon, 6 Feb 2012 13:31:54 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta13.westchester.pa.mail.comcast.net with comcast id Wjdq1i0031swQuc5DlXvLk; Mon, 06 Feb 2012 21:31:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id WlXu1i00d07duvL3blXvoK; Mon, 06 Feb 2012 21:31:55 +0000 Message-ID: <4F3046C9.4060401@alum.mit.edu> Date: Mon, 06 Feb 2012 16:31:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] VAD and speaker coordinates 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, 06 Feb 2012 21:31:55 -0000 (As individual) In the design team meeting last week there was discussion of representing the speaker location as part of the VAD data - concern with optimizing it. I'm somewhat naive here, but ISTM that there are principles to work out before getting to this. In particular, as I understand it a lot of inference is required to get from energy levels to VAD to speaker detection to speaker location. E.g. consider a case where there is a composed video stream that tiles a number of captures, and a corresponding composed audio stream that mixes corresponding audio captures. The audio mixer could do its own speaker detection by processing the audio, and tag it with the location in the video where the corresponding video is placed. But its possible that the sources for the individual audio and video streams have already tagged the audio with VAD info. If so, how would that information be handled by the mixer? Does it circumvent the explicit audio processing and replace it with a distinct mixing process for VAD info? Also, is it the case that energy level is filtered in some way so that loud non-voice noises are distinguished from actual speech? Thanks, Paul From pkyzivat@alum.mit.edu Mon Feb 6 14:31: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 B2CE111E809D for ; Mon, 6 Feb 2012 14:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 DZ7ZpYkaAfOn for ; Mon, 6 Feb 2012 14:31:04 -0800 (PST) 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 EAD9711E8075 for ; Mon, 6 Feb 2012 14:30:44 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta01.westchester.pa.mail.comcast.net with comcast id Wm1p1i0021YDfWL51mWlB0; Mon, 06 Feb 2012 22:30:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id WmWl1i00607duvL3gmWlXc; Mon, 06 Feb 2012 22:30:45 +0000 Message-ID: <4F305493.2060800@alum.mit.edu> Date: Mon, 06 Feb 2012 17:30:43 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Minutes: Design Team Meeting - Jan. 31, 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, 06 Feb 2012 22:31:05 -0000 Clueful, Below, please find the minutes from the design team meeting held on Jan 31th, 2012. The minutes will be posted to the wiki. Thanks to John Leslie for taking notes. Regards, Paul ============================================ CLUE WG Design Team Call January 31, 2012 Chairs: Mary Barnes, Paul Kyzivat * Attendees: Mary Barnes Paul Kyzivat Allyn Romanow Andy Pepperell Brian Baldino John Leslie Jonathan Lennox Mark Duckworth Rob Hansen Roni Even Stephan Wenger * Summary: Folks agree the general approach of conveying VAD info in audio streams, but there are a lot of details to be worked out. * Summary of action items: - The approach needs to be aligned with the coordinate system. - How to efficiently implement the conveyance of speaker location information _____________________ Notes by John Leslie: John Leslie, Paul Kyzivat, Roni Even, Stephan Wenger, Rob Hansen, Mark Duckworth, Brian Baldino, Allyn Romanow, Andy Pepperell, Mary @ 1004 Mary: talk about A5... Voice Activity Detection, should it me mandatory? Andy: if mandatory, stops need for everything to be decoded Brian: for switched case, we want some way to avoid need to calculate this... segment-switching... Mark: agree general approach sounds good... details left to be worked out, question for Andy, list of active linear positions Andy: talking about linear position rather than XYZ, three video streams, single pre-mixed audio. Levels mandatory Roni: position of microphone, people? not sure Mark: video captures would have an area of capture attribute, if two captures not of same area, audio stream could have coordinate associated with one of those video captures, receiver could tell which video capture would be associated with audio Roni: this information is not changing the relation Mark: VAD information is dynamic: could be different for each packet. There is an area of capture which is not dynamic. XYZ position with audio is an additional parameter, sender has more control over what portion of the scene is active Rob: how is this different Andy: you might have only a single audio and single video, you can influence the active region... more fine-grained Roni: mandatory means every ?? needs to support it Andy: one way is to say consumer always tells supplier which algorithm... issue of consistent VAD information. Making it mandatory ensures able to handle. Flip side is that conference may be talking to non-clue devices Roni: just say, coming from... Andy: also identifies loudest of many calls Roni: with one audio, one video, no way to say who's speaking... we need the spatial... Brian: for endpoints with only one video, but audio with directional capability, do we get directional information Roni: there is a way to provide (from mixer?), but linear position not there ??: any clue-compliant system should be sending those levels; separate question from whether there needs to be a way of associating audio with video captures Andy: VAD out needs to be consistens; whether it's mandatory, coordinates should be optional... decouple # audio streams from # video streams ??: currently, you send level in dB... additional bit which says ?? ??: energy level is the wrong measure... not sure we need to show where the audio is coming from... that's hard; do we need actual spatial Andy?: video streams may be different shapes... sub-scenes... ??: concerned that determining audio position is difficult Andy: selection of microphones... press a button... Roni: use case? ... be consistent with the naming. not an exact position Brian: could be specific location of a speaker Allyn: have we been recording this conference? Mary: starting recording now (1031) Roni: summarize, good idea to have that, not sure what "mandatory part" is Mark: if we're talking about sending location with every packet, is that overhead excessive Roni: thought we were talking about (non-coordinate) position Brian: think we can come up with a shorter way of describing the area Andy: send only where change; e.g. energy level all the time, position in different header Rob: (inaudible) Mary: I was kicked off the hotel network Allyn: discussing ways to achieve this, not clear which way most efficient Mary: we'll open an issue in tracker -- how to efficiently implement Rob: might be good to split the VAD stuff Roni: this is not part of the protocol, didn't hear ?? Rob?: how tightly coupled? ideally in same coordinate system Allyn: would it be good to flesh out the details in the framework document Roni: think Ron's point, talked of how to coordinate among media streams, don't know how or when we'll discuss it Allyn: develop solution further in the framework document -- just needs to be somewhere. Mary: framework is defining the overall functionality Roni: if we say something needs to be supported, which protocol remains open Mary: guys need to figure out where to fold this in Mark: that's OK Mary: are we done with this topic Allyn: should we bring up topic of composition Mary: does somebody have something to clarify discussion Stephan: ... Mary: I think we're done for today 1044 adjourn ______________________ Notes by Paul Kyzivat: Attendees: Mary Barnes Paul Kyzivat Allyn Romanow Andy Pepperell Brian Baldino John Leslie Jonathan Lennox Mark Duckworth Rob Hansen Roni Even Stephan Wenger John Leslie will take notes. Subject is section A.5 of framework: VAD - voice activity detection. Andy: Mark: agree general approach is ok, details to work out. Andy/Mark: this needs to be updated to include spacial coordinate that can be related to the streams. Roni: does this mean you want to have the position of the microphone, or the people, or what? Mark: e.g. if there are multiple video streams and only one audio stream, then the audio stream could have info about speaker location that can be correlated to a video stream. This could be different for each audio packet. Andy: level associated with the capture set should always be sent. Coordinates should be optional. Andy and Jonathan discussed value and issues with coordinates. Mark asks how much data is needed in each packet to carry coordinates. Roni: didn't think we were sending coordinates - just some sort of position info. Brian: we should be able to find something more compact than coordinates. Andy: could send energy level all the time, and send location info only when it changes. Mary: we should open an issue about how to efficiently implement this. There is question about how much of this needs to be in the framework. Rob said something, but couldn't understand what it was. (Bad audio from Rob.) From john@jlc.net Mon Feb 6 15:41: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 07DBC11E8075 for ; Mon, 6 Feb 2012 15:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.338 X-Spam-Level: X-Spam-Status: No, score=-106.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 wup77QH429oR for ; Mon, 6 Feb 2012 15:41:07 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6A59F21F86B2 for ; Mon, 6 Feb 2012 15:41:07 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id D5D8633C21; Mon, 6 Feb 2012 18:41:07 -0500 (EST) Date: Mon, 6 Feb 2012 18:41:07 -0500 From: John Leslie To: Paul Kyzivat Message-ID: <20120206234107.GH61963@verdi> References: <4F3046C9.4060401@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3046C9.4060401@alum.mit.edu> User-Agent: Mutt/1.4.1i Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates 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, 06 Feb 2012 23:41:08 -0000 Paul Kyzivat wrote: > > In the design team meeting last week there was discussion of > representing the speaker location as part of the VAD data - concern with > optimizing it. > > I'm somewhat naive here, but ISTM that there are principles to work out > before getting to this. In particular, as I understand it a lot of > inference is required to get from energy levels to VAD to speaker > detection to speaker location. I believe the technical term is "PFM". ;^) > E.g. consider a case where there is a composed video stream that tiles a > number of captures, and a corresponding composed audio stream that mixes > corresponding audio captures. Yes, that could happen too... > The audio mixer could do its own speaker detection by processing the > audio, and tag it with the location in the video where the corresponding > video is placed. I'll let someone else volunteer to do that... > But its possible that the sources for the individual audio and video > streams have already tagged the audio with VAD info. If so, how would > that information be handled by the mixer? Does it circumvent the > explicit audio processing and replace it with a distinct mixing process > for VAD info? This is a good question: if we had good speaker-location info, what could we do with it? > Also, is it the case that energy level is filtered in some way so that > loud non-voice noises are distinguished from actual speech? That is technically feasible... But I'd like to suggest we instead think in terms of identifying the physical location of the _microphone_ with greatest speech-like sound. That physical location is pretty easy to know; and if folks really care about identifying _speaker_ location, they can use more mikes. IMHO, the current state of the art can only _guess_ at speaker location when speakers share a microphone; and I'd rather not base our spec on guesses... -- John Leslie From pkyzivat@alum.mit.edu Mon Feb 6 17:16: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 4E07821F86DD for ; Mon, 6 Feb 2012 17:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 voQ9uuuyDF-c for ; Mon, 6 Feb 2012 17:16:08 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC1621F86DC for ; Mon, 6 Feb 2012 17:16:08 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta04.westchester.pa.mail.comcast.net with comcast id WpDw1i0080QuhwU54pG8G6; Tue, 07 Feb 2012 01:16:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta02.westchester.pa.mail.comcast.net with comcast id WpG81i00q07duvL3NpG8Ss; Tue, 07 Feb 2012 01:16:08 +0000 Message-ID: <4F307B56.5080707@alum.mit.edu> Date: Mon, 06 Feb 2012 20:16:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John Leslie References: <4F3046C9.4060401@alum.mit.edu> <20120206234107.GH61963@verdi> In-Reply-To: <20120206234107.GH61963@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates 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, 07 Feb 2012 01:16:09 -0000 On 2/6/12 6:41 PM, John Leslie wrote: > Paul Kyzivat wrote: >> >> In the design team meeting last week there was discussion of >> representing the speaker location as part of the VAD data - concern with >> optimizing it. >> >> I'm somewhat naive here, but ISTM that there are principles to work out >> before getting to this. In particular, as I understand it a lot of >> inference is required to get from energy levels to VAD to speaker >> detection to speaker location. > > I believe the technical term is "PFM". ;^) PFM = P??? F??? M??? >> E.g. consider a case where there is a composed video stream that tiles a >> number of captures, and a corresponding composed audio stream that mixes >> corresponding audio captures. > > Yes, that could happen too... > >> The audio mixer could do its own speaker detection by processing the >> audio, and tag it with the location in the video where the corresponding >> video is placed. > > I'll let someone else volunteer to do that... This actually seems like one of the easy things, if it is mixing matched pairs of audio/video. It only has to decide which audio is the loudest speaker and then tag it with the location in the mixed video where the corresponding video stream is being placed. >> But its possible that the sources for the individual audio and video >> streams have already tagged the audio with VAD info. If so, how would >> that information be handled by the mixer? Does it circumvent the >> explicit audio processing and replace it with a distinct mixing process >> for VAD info? > > This is a good question: if we had good speaker-location info, what > could we do with it? > >> Also, is it the case that energy level is filtered in some way so that >> loud non-voice noises are distinguished from actual speech? > > That is technically feasible... > > But I'd like to suggest we instead think in terms of identifying the > physical location of the _microphone_ with greatest speech-like sound. > That physical location is pretty easy to know; and if folks really > care about identifying _speaker_ location, they can use more mikes. > > IMHO, the current state of the art can only _guess_ at speaker > location when speakers share a microphone; and I'd rather not base > our spec on guesses... I'm easy - if that is the goal, then go ahead and specify that. At least there is a reasonable chance of defining it. Thanks, Paul From pkyzivat@alum.mit.edu Mon Feb 6 17:32: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 505FB21F8637 for ; Mon, 6 Feb 2012 17:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 8pDHaF4GQ7rl for ; Mon, 6 Feb 2012 17:32:57 -0800 (PST) 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 51C0421F8635 for ; Mon, 6 Feb 2012 17:32:57 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id Wovr1i00A1ap0As55pYxMo; Tue, 07 Feb 2012 01:32:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id WpYx1i00x07duvL3ipYxuc; Tue, 07 Feb 2012 01:32:57 +0000 Message-ID: <4F307F47.4080302@alum.mit.edu> Date: Mon, 06 Feb 2012 20:32:55 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Espen Berger (espeberg)" References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org><4f266f4c.d0770e0a.43c6.37fd@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com><4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com><4f272344.03bd0e0a.6983.3d7e@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com><4f291525.84310e0a.69d7.fffffd3b@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com> <4F29766F.1080101@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com> <4F2B254F.9050504@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9EEC5677@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EEC5677@XMB-AMS-214.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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, 07 Feb 2012 01:32:58 -0000 On 2/6/12 2:01 PM, Espen Berger (espeberg) wrote: > I should have documented the use cases I used better. I will make a summary during the next days that hopefully is clearer. > > See inline. Comments inline too. > -Espen > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 3. februar 2012 01:08 > To: Espen Berger (espeberg) > Cc: clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data structure > > On 2/2/12 11:42 AM, Espen Berger (espeberg) wrote: >> Hi Paul >> >> I will make a brief attempt to answer. > > Its good to get into the details. As exhibited by Roni's reply, its not > clear that all are on the same page. > > EBE>> Details are good. > >> The scenarios are how to map a 3x camera system to a 2x screen system. The triple offer >> Strema = 1 - 3 >> Policies = Switched, static, composed > > IIUC, in the above you have separated the policies from the streams - > somehow the policies apply to all the streams. > > It was my impression that each offered stream is independent, and may be > static, switched, or composed. > > EBE>> It's natural that you have at least one alternative in a capture set where all captures have the same policies. If we write them out as the same policy on individual capture streams that should mean the same as a single policy on all captures in a capture set alternative. > > So, I would assume that if the 3 camera system wants to accommodate > dissimilar systems, it would offer more than three streams. E.g.: > > - left, static (!composed) > - middle, static > - right, static > - composed (left, middle, and right) > - switched (active speaker) > - ... > > EBE>> Agree, I made an example where also two screen alternatives are listed. In the example Left, middle, right represent the cameras, VCx are logical streams, I also assume that the only three streams alternative allowed is to request all 3x camera streams. > Static 3-streams {left, middle, right} > Static 2-streams {left, middle}, {left, right} or {middle, right} > Static 1-stream {left}, {middle} or {right} > Composed 2-streams {VC0, VC1} > Composed 1-stream {VC2} > Switched 2-streams {Vc3, Vc4} > Switched 1-stream {VC5} > (What is the preferred alternative for a two screen system?) You show this as 7 alternatives, but its actually 12 streams, right? Each row above is a recommended selection of multiple streams that you think makes sense. And as you show it, the policy is associated with a set of streams, rather than a particular stream. I can't tell if that is the way you want to represent it, or just what you found convenient for this example. But I presume there is nothing to prevent selecting some other subset of those 12 streams, right? (E.g. middle, VC5) >> As a receiver (with 2x screens) I would do this choices >> >> 1) How many streams to receive >> 1 => The triple sends a single stream by some sender preferred policy > > This really confuses me. > I assumed that if the receiver only wants one stream (perhaps because it > has only one screen), it would simply pick one of the streams offered > (as you described, it would be one of the three.) > > You seem to be suggesting that the act of requesting one stream will > cause the sender to alter the policy used to produce that stream. That > makes no sense to me. > > EBE>> In the use cases I assumed that a media consumer want to select the alternative that the media provider think is most sensible for a the number of streams selected. E.g. if an endpoint request a single capture streams from a triple camera endpoint, the preferred alternative might be a composed view. If the media consumer wants a particular alternative, it can parse them all and select the one that matches what it wants. This presumes that the advertisement indicates a recommended grouping of streams for a particular number of screens. I hadn't previously seen a proposal to include that info. >> 2 => The triple sends two streams by some policy > > More of same confusion above. ISTM that the if the recipient wants two > streams to display, that it should be choosing two based on the > descriptions. Not that the sender decides what to include in the two > based on the fact that two have been requested. > > EBE>> Same as above. >> 3 => The triple sends three cameras in spatial order, and >> the receiver decide how to render across two screens > > This is clearly the most straightforward case. > >> 2) Which switching policy >> Static => The requester ask for explicit camera streams, e.g. cam1 or (cam2+cam3) >> Switched/Composed => The triple chooses the streams to send, e.g. the two loudest segments or it could make a nice rendering of 3x cameras rendered on two streams. >> >> I assume that you won't use different switching policies for the different streams, since it gives the sender of media the chance to optimize what it send on the streams requested. > > What I take from this is that you are assuming a single policy that > impacts all the streams sent to this recipient. > > But I thought the intent was that the sender describes *each* available > stream with an independent policy, and the recipient just chooses those > that it wishes. > > EBE>> It's a limitation to only allow the same policy on all streams requested, but in many use cases I think it's natural to use the same policy across multiple streams. This needs to be sorted out, because it is pretty fundamental to the way that all this info is represented. Thanks, Paul From marshall.eubanks@gmail.com Tue Feb 7 08:04: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 B4D1821F884F for ; Tue, 7 Feb 2012 08:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.504 X-Spam-Level: X-Spam-Status: No, score=-103.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 RKwL3l9Mx4oz for ; Tue, 7 Feb 2012 08:04:15 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B374221F881B for ; Tue, 7 Feb 2012 08:04:15 -0800 (PST) Received: by obbwd15 with SMTP id wd15so10323091obb.31 for ; Tue, 07 Feb 2012 08:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ozx+mXGsfd/9adsWgvC0dlfoYqaWMLBntSNEfW/0DWI=; b=vPP6hn3vAWmlGY+xTE5x5UdXry0APRLUj5HjkGzWZjYqIcNd17mO+SxEHyhrKDy+nj u42IbIbOOLvKRM5AHuRAldcIzKXWDJViPFU7NkH/spWGCpcrfumBl740pV1PMssH/7aA h3ANfq6DzXz35/kh7PSoprcxvr9qp2+ftmPFs= MIME-Version: 1.0 Received: by 10.182.75.102 with SMTP id b6mr21718662obw.9.1328630655295; Tue, 07 Feb 2012 08:04:15 -0800 (PST) Received: by 10.182.52.134 with HTTP; Tue, 7 Feb 2012 08:04:15 -0800 (PST) Date: Tue, 7 Feb 2012 11:04:15 -0500 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Raw notes from today's design team 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, 07 Feb 2012 16:04:16 -0000 Tue Feb 7 10:04:08 EST 2012 CLUE Design Team Meeting Marshall Eubanks Mary Barnes Paul K Brian Baldino Espen Berger John Leslie Jonathan Lennox Mark Duckworth Roni Even Spencer Dawkins Mary : I thought we would talk about the stuff in the appendix. None of that has changed ? Appendix A A.1 - Isn't this Issue 7 (in the tracker) ? Would it make more sense to remove it from here as it is in the tracker ? Roni : I think we should leave it here. It is still an issue. I don't think we should remove any open issues from here. Mary : We should at least update the tracker to point this out. If people are going to talk about it, they should refer to the tracker. Mark : Are you saying that the issue tracker should point to the document. You don't want to cross-reference the other way ? Mary, Ron : No Mary : A.2 - Source is selectable. Mark : Originally, this was in the main body as an attribute, but it no longer it is the main body. Should there be such an attribute is part of the open issue. There is nothing in 6.1 Jonathan : Is it an attribute of the source or the capture ? Mark : We thought that a media capture should have an attribute like this, so that the consumer can give input as to what source to select for example. Paul : Doesn't make much sense without a mechanism. Jonathan : Positive capture gets a little vague at this point. What is the point of sources you can't capture? Paul : If you can select where the camera pointed ? Mark : Let's go to A.3, I think it is overriding. Once we figure it out, then we can decide A.2. Mary : OK, let's do that then. Mark : Have the chairs determined that this is in charter ? Jonathan : And it is related to what's coming up in Dispatch in Paris. Mary : You mean Magnus's mess. (He called it that.) Mary : A roster is not needed? Roni : It doesn't talk about a roster of the participant, which is not in scope as I understand. It is a list of equipment. All of the examples have a very flat model. You can't see what's behind the MCU. The capture set describes some captures from your provider, which is an MCU in multipoint, and you don't know what is behind the MCU. I think that is what A.3 talks about. Mark : I think that's correct. Roni : We are not talking about the actual people in the conference. We are talking about more information in the case of an MCU. Mark : So in this context, roster is a list of end point equipment. Jonathan : It might have people's info. Person's X Desk. Paul : The equipment is a source of streams. This is a catalog of potential streams, both raw captures and streams from other equipment. Jonathan : The roster is every stream. It might well provide both the original streams and captures. Mary : So, I think we agree that a roster would not be a list of people. Jonathan : If there was a list of people anyway, it would be useful to have a simple way to correlate it with this roster. At some point we need to understand how to do that. Mary : Is there an action here ? Jonathan : The model for A.3 controls A.2. There are two models here. One is, you have a set, if an original source is available, you list all pure captures as well as any massaged captures. Whereas the other model is thinking more like meta-captures, and you get to chose which sources go into it. Sources may come and go quickly in a large conference. Roni : This can be very complicated. You don't do this in this case in the MCU ? It may be more relevant in the case where the MCU is mixing and you want to mix a specific capture to receive it. Jonathan : We are doing it now. Roni : This is OK in your system, where everyone will have the same codec. Mark : Or that is up to the middle box. Roni : To receive a stream directly from another site. Marshall : If people get to pick who (which equipment) is in a composition I think that they will want to have finer scale control of the composition (conference room XYZ goes in the upper left hand corner of the hollywood squares, that sort of thing). Mark (?) : That adds a whole extra layer of complexity to this. Marshall : But if people have the ability to select who is in a stream, they will want finer grain control. This is common now, just not at the machine layer, but the manual configuration layer. Jonathan : There is also Issue 1. Mary : A.4 - input requesting many streams. Marshall : I don't think that "many" is the problem here. There isn't a problem with size, per se, as long as there is bandwidth and CPU to handle it. The problem is more in a finer grain control of the selection. I see the example as problematic - 3 loudest speakers ? How do I do gain control ? Roni : In the previous question - how do you describe this from the MCU to the endpoint ? You describe it from the point of view of the MCU, not the ultimate endpoint. In the current model this is not achievable. Brian : You don't need a lot of information to do a few PIPs. Jonathan : The model I am familiar with is I want to see the current speaker large and the previous speaker small and don't send me the other ones. Mark : I don't think that the current system has enough information to do that. Jonathan : So, you want the ability to say "this capture is the 3rd most recent speaker." Espen : You are saying "I want the middle box to select the three most relevant speakers" Marshall : Are you saying that the end user should be able to control the middle box's algorithms ? Roni : No. Marshall : In the current framework, is there no information about who the current speaker (in a switched system) actually is ? If you knew that, picking the last speaker for a PIP is easy. Roni : No, it is not conveyed. There has been discussion about this. Brian : I think that people are talking about different use cases. Could we lay out the different scenarios here? Mark : The use case document is fairly high level. Perhaps we need some more technically oriented use case. Roni : All this discussion is relevant if we first agree that the end point can request the policy for switching or whatever from the MCU. Jonathan : I think that there are aspects of A.4 that are relevant even discounting the policy question. Brian : The use case I was thinking of did not have these policy issues. Espen : I think that more technical description would be useful. What is the minimum information we need to make a sensible choice. Defining the use case in more detail would be useful. Mary : In (?) we took the framework and the use cases and hashed them out in some detail. Is there a suitable use case in the use case document ? It would be useful to have one person to take one use case and flesh it out using the the framework. Jonathan : One use case could be implemented several ways. Mary ; That would be an ideal thing to work through in the face to face. I hope everyone on this call will be at the face to face next week. Jonathan : Do we know how long various (?) Mary : We will adjust the agenda based on materials received. There is a buffer in the afternoon as well. OK, thanks. See you next week. Meeting ended Tue Feb 7 10:57:24 EST 2012 From mary.ietf.barnes@gmail.com Tue Feb 7 12:49: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 3F31D11E8072 for ; Tue, 7 Feb 2012 12:49:26 -0800 (PST) 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.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 N2LxR3nCo6zN for ; Tue, 7 Feb 2012 12:49:25 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8235821F8644 for ; Tue, 7 Feb 2012 12:49:17 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so5464465vbb.31 for ; Tue, 07 Feb 2012 12:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=b5sCS6lDPBff6Ofw+d5FZuFkIE4pP0sQnpML3ur55Lo=; b=c2wh81zMLJvUBYPSSZ4DdAhbAmzbpNFd28y7kvaYX49LPdXQvZzJI0ovJOfIHlBYwA +QF2ts7YP4gYLVFuIupmZ6ewfbmdfM2sseZ08BQpGf9byqLNjUMqnZ3c1h3tqQQdsZbv +wmBa5v9YWzpKqIYUazk6/pj5xwwRfgYHQAmI= MIME-Version: 1.0 Received: by 10.52.35.148 with SMTP id h20mr11191539vdj.21.1328647757092; Tue, 07 Feb 2012 12:49:17 -0800 (PST) Received: by 10.52.114.200 with HTTP; Tue, 7 Feb 2012 12:49:17 -0800 (PST) In-Reply-To: <4F318A59.5020700@ericsson.com> References: <4F318A59.5020700@ericsson.com> Date: Tue, 7 Feb 2012 14:49:17 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: [MMUSIC] SDP directorate created 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, 07 Feb 2012 20:49:26 -0000 FYI... ---------- Forwarded message ---------- From: Gonzalo Camarillo Date: Tue, Feb 7, 2012 at 2:32 PM Subject: [MMUSIC] SDP directorate created To: mmusic Folks, per our discussions regarding SDP extension coordination, we have created an SDP directorate, which includes SDP experts that will review proposals for SDP extensions when needed. http://www.ietf.org/iesg/directorate/sdp.html Cheers, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From Mark.Duckworth@polycom.com Tue Feb 7 18: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 144081F0C3C for ; Tue, 7 Feb 2012 18:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Qih2mDsRDlLe for ; Tue, 7 Feb 2012 18:23:14 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 214D41F0C35 for ; Tue, 7 Feb 2012 18:23:13 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Tue, 7 Feb 2012 18:23:13 -0800 From: "Duckworth, Mark" To: John Leslie , Paul Kyzivat Date: Tue, 7 Feb 2012 18:23:10 -0800 Thread-Topic: [clue] VAD and speaker coordinates Thread-Index: AczlKM/lE6YbbCMBSQOE7OB8j+VSagA3ZyoA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB202BEA@CRPMBOXPRD01.polycom.com> References: <4F3046C9.4060401@alum.mit.edu> <20120206234107.GH61963@verdi> In-Reply-To: <20120206234107.GH61963@verdi> 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 Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates 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, 08 Feb 2012 02:23:16 -0000 John Leslie wrote: "But I'd like to suggest we instead think in terms of identifying the ph= ysical location of the _microphone_ with greatest speech-like sound. That = physical location is pretty easy to know; and if folks really care about id= entifying _speaker_ location, they can use more mikes." I disagree. If a media provider wants to estimate the speaker (talker) loc= ation based on which microphone has the greatest speech-like sound, that is= fine. But some microphone arrangements (along with the audio processing a= lgorithms) just don't work that way. For example, microphone arrays where= there is no direct constant relationship between a microphone element and = an encoded audio channel. So if those systems identified the location of the microphone with greatest= speech-like sound it wouldn't necessarily have any relation to the locatio= n of the talker. I think it is better for the media provider to estimate (= usually better than a guess!) where the talker is, using whatever method ma= kes sense for that provider. We don't want the media consumer to be making= incorrect assumptions about how the provider's microphone system works. Mark -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Joh= n Leslie Sent: Monday, February 06, 2012 6:41 PM To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates Paul Kyzivat wrote: >=20 > In the design team meeting last week there was discussion of=20 > representing the speaker location as part of the VAD data - concern=20 > with optimizing it. >=20 > I'm somewhat naive here, but ISTM that there are principles to work=20 > out before getting to this. In particular, as I understand it a lot of=20 > inference is required to get from energy levels to VAD to speaker=20 > detection to speaker location. I believe the technical term is "PFM". ;^) > E.g. consider a case where there is a composed video stream that tiles=20 > a number of captures, and a corresponding composed audio stream that=20 > mixes corresponding audio captures. Yes, that could happen too... > The audio mixer could do its own speaker detection by processing the=20 > audio, and tag it with the location in the video where the=20 > corresponding video is placed. I'll let someone else volunteer to do that... > But its possible that the sources for the individual audio and video=20 > streams have already tagged the audio with VAD info. If so, how would=20 > that information be handled by the mixer? Does it circumvent the=20 > explicit audio processing and replace it with a distinct mixing=20 > process for VAD info? This is a good question: if we had good speaker-location info, what coul= d we do with it? > Also, is it the case that energy level is filtered in some way so that=20 > loud non-voice noises are distinguished from actual speech? That is technically feasible... But I'd like to suggest we instead think in terms of identifying the phy= sical location of the _microphone_ with greatest speech-like sound. That physical location is pretty easy to know; and if folks really care abo= ut identifying _speaker_ location, they can use more mikes. IMHO, the current state of the art can only _guess_ at speaker location = when speakers share a microphone; and I'd rather not base our spec on guess= es... -- John Leslie _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Wed Feb 8 05:49: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 F355321F85D4 for ; Wed, 8 Feb 2012 05:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=0.346, 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 V--IMd6WFFFV for ; Wed, 8 Feb 2012 05:49:17 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC0421F85C3 for ; Wed, 8 Feb 2012 05:49:15 -0800 (PST) Received: by eaal12 with SMTP id l12so190017eaa.31 for ; Wed, 08 Feb 2012 05:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=KaDPfadcInbd5+AC+VAwdsCQrKXG7yA58CMIjlE4aSw=; b=cfMZDXyY7n2XPQ65KTe+kcWSgq6LSMM7ASybwJnt91m5SYXLtQKtigtUxhmC5KO1c5 8dFc0pLUm4pQrFdAbULWTFqa98bPYwXRNGibsN8k2x0yH3j5iqdnZ/wF7yR7dE0kSUX5 /GC9y+0xuRKtD8bvgTYCwXLhikeGycraWVM30= Received: by 10.14.127.6 with SMTP id c6mr8619032eei.49.1328708955266; Wed, 08 Feb 2012 05:49:15 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id n58sm5370217een.10.2012.02.08.05.49.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 05:49:13 -0800 (PST) From: "Roni Even" To: Date: Wed, 8 Feb 2012 15:48:58 +0200 Message-ID: <4f327d59.d2130e0a.3e4f.ffffe95a@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012F_01CCE679.2D4A5820" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczmaGdy5PVDLQ8nRHK9EFLGxp4ZMQ== Content-Language: en-us Subject: [clue] Review of draft-ietf-clue-framework-03 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, 08 Feb 2012 13:49:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_012F_01CCE679.2D4A5820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I read 03 and it is a bit clear than 01, 02 was not a real version. These are my initial comments. I will try also to start separate thread on the major issues from this long list 1. In section 3 the definition of media capture say "A Media Capture (MC) may be the source of one or more Media streams." What is the "more" in this case. Can you explain since my understanding of a media capture is that is one stream, can you give an example. 2. In section 4, "This constitutes a significant change from previous video conferencing systems in which transmission of content was determined primarily by the sender." I am not sure what is "content" here, is it the actual data or the semantics of the stream. I also do not believe that this statement is true. 3. The issue of capture scene / set / entry is not fully described yet. In section 4 the text says "A provider organizes its media captures that represent the same scene into capture sets. A consumer chooses which media captures it wants to receive according to the capture sets sent by the provider." I think that it will be good to clarify that there can be more than one capture set per capture scene and to add the term capture set entry to the terminology section. This is also relevant to the text in section 6.2. 4. The coordinate units are first discussed in section 4. The currents units which I am OK with are the mm and no unknown. The no scale as far as I understand provide units in the coordinates system that allows the provider to define a spatial order that the consumer will use to render, this option can be used for example by a MCU. I think that we can add two more units. The first is "no spatial information" this will allow the provider to leave it to the consumer to decide what order to use. The second is "priority" this is still no spatial relation between the media captures but the provider can use it to specify which media captures are more important allowing the consumer to select between media captures. 5. In section 6.1.1 "Media Capture (MC) Attributes describe static information about the captures that can be used by the consumer to help decide which Media Captures should be requested". I think that this sentence is using a passive language and I suggest rephrasing it to "Media Capture Attributes describe static information about the captures. A Provider use the MC attributes to propose multiple MC choices to the consumer. The consumer will select the MCs that he wants to render" 6. In section 6.1.1 I suggest adding one more purpose "SL" for sign language indicating that this is the sign language representation of the audio stream, see RFC4796. 7. In 6.1.1 the composed attribute is discussed elsewhere and is still an open issue. 8. In 6.1.1 I noticed that the audio channel format attribute values changed from previous version. I do not recall that it was discussed and that there was a consensus to remove the other values like 3.0, 3.1, 5.1 surround sound and binaural. As for the stereo value, does it represent one stereo or two mono channels. 9. In 6.1.1 for the switched attribute "What is 'most appropriate' is up to the producer and could be the active speaker, a lecturer or a VIP." I do not agree with this statement. The producer must be able to offer options and let the consumer decide what is appropriate. 10. In section 6.1.1 I suggest adding an attribute that will correlate between the MC and the SDP m-line or SSRC of this media stream. 11. When talking about capture set entry, my understanding is that a consumer can select part of the MCs in the entry and not all of them since they represent simultaneous streams. For example if the provider offers (VC0, VC1, VC2) the consumer can request (VC2) or (VC0, VC2). I think that this should be clear in the text. Maybe in add some text in section 6.3 fourth paragraph. 12. In 6.2 example bullet 2 "(VC3) - video capture associated with loudest room segment." My view is that using the current attribute values all you can say is that it is one of video captures based on some switching algorithm as decided but the provider. The consumer has no way of knowing that this is the loudest speaker. 13. In 6.2.1 the text says that the scale attribute is optional, I suggested in my comment 4 to have a value for the case where there is no scale. 14. In section 6.3 I think that there is a third type of constrain based on what is called concept in section 6.1. The provider can send a voice activated video switch content or switch between the MCs every 10 seconds. 15. In section 6.3 the text say that " The second type of limitation reflects the encoding resources available - bandwidth and macroblocks/second". This information is available in the SDP description and the CLUE protocol should not duplicate information. 16. The fourth paragraph of section 6.3 "Simultaneous transmission sets are expressed as sets of the MCs" I suggest changing "sets" to "entries of capture sets". 17. Section 7 talks about encoding. My view is that these constrains are already defined in the respective m-lines in the SDP. For example the first paragraph of section 7.1 describes the SDP and codec parameters so why do we need to duplicate the individual encoding which is also codec specific, see section 10 talking about new encoding parameters for new codecs. My suggestion is to add a correlation between the SDP information and the media capture that is sending the specific media stream. The same goes for the group information in section 7.2, at least to the bandwidth parameter which just repeats the logic defined in RFC4566. 18. Figure 1 in section 7.2 is not clear, what is the relation of the proposed encoding groups to the media captures. 19. The last sentence in 7.2 "There is no requirement for all encodings within an encoding group to be instantiated at once" is not clear to me with respect to the rest of the section. 20. In section 8 "Every media capture is associated with an encoding group" is it a media capture or a capture set entry? 21. I read section 8 and most of it is not clear. The last sentence is the only sentence that is needed. 22. The first paragraph of section 9 demonstrate the need to associate the MCs with the SDP since by choosing a MC the consumer must also receive the RTP media associated with it. 23. In section 9 I suggest changing the "has" in the last sentence of the first paragraph to a "may" . A provider may be able to support the capture set entries without any limitations on the encoding beside the ones specified in the SDP. 24. Section 9 fourth paragraph describes an exchange similar to offer answer. I think that even if the consumer current configuration is not affected by the new advertisement, the consumer still need to acknowledge that he received the new advertisement and understands it. 25. Section 9.4 discusses the message flow. I think that two messages are enough preferably the last two. This will enable the CLUE protocol to work with offer/answer for example for codec parameters like H.264 RFC6184. 26. In the example in section 11.1 there is a text definition for VC3 and VC4 but the current attribute do not make it explicit to the consumer for example without changing the attribute I can write VC3 (switch between the cameras every 10 second) and VC4 (a side by side composition of two out of the three cameras with the last two speakers) 27. In section 11.1 should AC3 also have composed attribute otherwise it may be a mix or a switch. 28. In section 11.1 there are two simultaneous information sets. The physical simultaneity information is: {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} And the capture sets +--------------------+ | Capture Set #1 | +---------------------+ | VC0, VC1, VC2 | | VC3 | | VC4 | | VC5 | | AC0, AC1, AC2 | | AC3 | +--------------------+ +--------------------+ | Capture Set #2 | +--------------------+ | VC6 | | AC4 | +--------------------+ Are both being specified in the data model? The Capture sets are subset of the physical simultaneity information. So why need both. Thanks Roni Even ------=_NextPart_000_012F_01CCE679.2D4A5820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I read 03 and = it is a bit clear than 01, 02 was not a real version.

These are my initial comments. I will try also to = start separate thread on the major issues from this long = list

 

1.       = In section = 3 the definition of media capture say “A Media = Capture (MC) may be the source of one or more Media = streams.”  What is the “more” in this case. Can = you explain since my understanding of a media capture is that is one = stream, can you give an example.

 =

2.       = In section = 4, “This constitutes a significant change from previous video = conferencing  systems in which transmission of content was = determined primarily by  the sender.” I am not sure what is = “content” here, is it the actual data or the semantics of = the stream. I also do not believe that this statement is = true.

 =

3.       = The issue = of capture scene / set / entry is not fully described yet. In section 4 = the text says “A provider organizes its media captures that = represent the same scene into capture sets.  A consumer chooses = which media captures it wants to receive according to the capture sets = sent by the provider.”  I think that it will be good to = clarify that there can be more than one capture set per capture scene = and to add the term capture set entry to the terminology section. This = is also relevant to the text in section 6.2.

 =

4.       = The = coordinate units are first discussed in section 4. The currents units = which I am OK with are the mm and no unknown. The no scale as far as I = understand provide units in the coordinates system that allows the = provider to define a spatial order that the consumer will use to render, = this option can be used for example by a MCU. I think that we can add = two more units. The first is “no spatial information” this = will allow the provider to leave it to the consumer to decide what order = to use. The second is “priority” this is still no spatial = relation between the media captures but the provider can use it to = specify which media captures are more important allowing the consumer to = select between media captures.

 =

5.       = In section = 6.1.1 “Media Capture (MC) Attributes describe static information = about the captures that can be used by the consumer to help decide which = Media  Captures should be requested”. I think that this = sentence is using a passive language and I suggest rephrasing it to = “Media Capture Attributes describe static information about the = captures. A Provider use the MC attributes to propose multiple MC = choices to the consumer. The consumer will select the MCs that he wants = to render”

 =

6.       = In section = 6.1.1 I suggest adding one more purpose “SL” for sign = language indicating that this is the sign language representation of the = audio stream, see RFC4796.

 =

7.       = In 6.1.1 = the composed attribute is discussed elsewhere and is still an open = issue.

 =

8.       = In 6.1.1 I = noticed that the audio channel format attribute values changed from = previous version. I do not recall that it was discussed and that there = was a consensus to remove the other values like 3.0, 3.1, 5.1 surround = sound and binaural. As for the stereo value, does it represent one = stereo or two mono channels.

 =

9.       = In 6.1.1 = for the switched attribute “What is 'most appropriate' is up to = the producer and could be the active speaker, a lecturer or a = VIP.” I do not agree with this statement. The producer must be = able to offer options and let the consumer decide what is = appropriate.

 =

10.   In section = 6.1.1 I suggest adding an attribute that will correlate between the MC = and the SDP m-line or SSRC of this media stream.

 =

11.   When = talking about capture set entry, my understanding is that a consumer can = select part of the MCs in the entry and not all of them since they = represent simultaneous streams. For example if the provider offers (VC0, = VC1, VC2) the consumer can request (VC2) or (VC0, VC2). I think that = this should be clear in the text. Maybe in add some text in section 6.3 = fourth paragraph.

 =

12.   In 6.2 = example bullet 2 “(VC3) - video capture associated with loudest = room segment.” My view is that using the current = attribute values all you can say is that it is one of video captures = based on some switching algorithm as decided but the provider. The = consumer has no way of knowing that this is the loudest = speaker.

 =

13.   In 6.2.1 = the text says that the scale attribute is optional, I suggested in my = comment 4 to have a value for the case where there is no = scale.

 =

14.   In section = 6.3 I think that there is a third type of constrain based on what is = called concept in section 6.1. The provider can send a voice activated = video switch content or switch between the MCs every 10 = seconds.

 =

15.   In section = 6.3 the text say that “ The second = type of limitation  reflects the encoding resources available - = bandwidth and macroblocks/second”. This information is available = in the SDP description and the CLUE protocol should not duplicate = information.=

 =

16.   The fourth = paragraph of section 6.3 “Simultaneou= s transmission sets are expressed as sets of the MCs” I suggest = changing “sets” to “entries of capture = sets”.=

 =

17.   Section 7 = talks about encoding. My view is that these constrains are already = defined in the respective m-lines in the SDP. For example the first = paragraph of section 7.1 describes the SDP and codec parameters so why = do we need to duplicate the individual encoding which is also codec = specific, see section 10 talking about new encoding parameters for new = codecs. My suggestion is to add a correlation between the SDP = information and the media capture that is sending the specific media = stream.  The = same goes for the group information in section 7.2, at least to the = bandwidth parameter which just repeats the logic defined in RFC4566. =

 =

18.   Figure 1 = in section 7.2 is not clear, what is the relation of the proposed = encoding groups to the media captures.

 =

19.   The last = sentence in 7.2 “Ther= e is no requirement for all encodings within an encoding group to be = instantiated at once” is not clear to me with respect to the rest = of the section.=

 =

20.   In section = 8 “Every media capture is associated with an encoding group” = is it a media capture or a capture set entry?=

 =

21.   I read = section 8 and most of it is not clear. The last sentence is the only = sentence that is needed.

 =

22.   The first = paragraph of section 9 demonstrate the need to associate the MCs with = the SDP since by choosing a MC the consumer must also receive the RTP = media associated with it.

 =

23.   In section = 9 I suggest changing the “has” in the last sentence of the = first paragraph to a “may” . A provider may be able to = support the capture set entries without any limitations on the encoding = beside the ones specified in the SDP.

 =

24.   Section 9 = fourth paragraph describes an exchange similar to offer answer. I think = that even if the consumer current configuration is not affected by the = new advertisement, the consumer still need to acknowledge that he = received the new advertisement and understands = it.

 =

25.    Secti= on 9.4 discusses the message flow. I think that two messages are enough = preferably the last two. This will enable the CLUE protocol to work with = offer/answer for example for codec parameters like H.264 = RFC6184.

 =

26.   In the = example in section 11.1 there is a text definition for VC3 and VC4 but = the current attribute do not make it explicit to the consumer for = example without changing the attribute I can write VC3 (switch = between the cameras every 10 second) and VC4 (a side by side composition = of two out of the three cameras with the last two speakers)=

 =

27.   In section = 11.1 should AC3 also have composed attribute otherwise it may be a mix = or a switch.=

 =

28.   In section = 11.1 there are two simultaneous information = sets.

 =

The = physical simultaneity information is:

 =

  = ;    {VC0, VC1, VC2, VC3, VC4, = VC6}

 =

  = ;    {VC0, VC2, VC5, VC6}

And the = capture sets

  = ;            =             &= nbsp; +--------------------+

  = ;            =             &= nbsp; | Capture Set #1 |

  = ;            =             &= nbsp; +---------------------+

  = ;            =             &= nbsp; | VC0, VC1, VC2  |

  = ;            =             &= nbsp; | = VC3           &nbs= p;         = |

  = ; =             &= nbsp;           &n= bsp;| = VC4           &nbs= p;        |

  = ;            =             &= nbsp; | = VC5           &nbs= p;        |

  = ;            =             &= nbsp; | AC0, AC1, AC2  |

  = ;            =             &= nbsp; | = AC3           &nbs= p;         = |

  = ;            =             &= nbsp; +--------------------+

 =

  = ;            =             &= nbsp; +--------------------+

  = ;            =             &= nbsp; | Capture Set #2 |

  = ;            =             &= nbsp; +--------------------+

  = ;            =             &= nbsp; | = VC6           &nbs= p;        |

  = ;            =             &= nbsp; | = AC4           &nbs= p;        |

  = ;            =             &= nbsp; +--------------------+

Are both = being specified in the data model? The Capture sets are subset of the = physical simultaneity information. So why need = both.

 =

 =

Thanks=

Roni = Even

 =

 =

 

------=_NextPart_000_012F_01CCE679.2D4A5820-- From Mark.Duckworth@polycom.com Wed Feb 8 07:53: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 F37AE21F865F for ; Wed, 8 Feb 2012 07:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, 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 xpiF2q0zHBqi for ; Wed, 8 Feb 2012 07:53:49 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4320521F842F for ; Wed, 8 Feb 2012 07:53:48 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 8 Feb 2012 07:53:48 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 8 Feb 2012 07:53:45 -0800 Thread-Topic: [clue] #7: Is composed attribute a boolean or data structure Thread-Index: AczhBxgZzsQM+HraTUCVftAm4h2iFAAvm5hgASwpd2A= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB202D20@CRPMBOXPRD01.polycom.com> References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org><4f266f4c.d0770e0a.43c6.37fd@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com><4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com><4f272344.03bd0e0a.6983.3d7e@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com><4f291525.84310e0a.69d7.fffffd3b@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com> <4F29766F.1080101@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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, 08 Feb 2012 15:53:51 -0000 SSdsbCBhZGQgbXkgdGhvdWdodHMgdG8gdGhpcywgZm9yIGhvdyBJIHNlZSB0aGlzIHNjZW5hcmlv IHdvcmtpbmcgKDN4IGNhbWVyYSBzeXN0ZW0gc2VuZGluZyB0byBhIDJ4IHNjcmVlbiBzeXN0ZW0p LCB1c2luZyBFc3BlbidzIGlkZWFzIGZvciB3aGF0IHRoZSBhbHRlcm5hdGl2ZXMgYXJlIGZvciB0 aGlzIHBhcnRpY3VsYXIgZXhhbXBsZSwgZ2l2ZW4gdGhpcyBwYXJ0aWN1bGFyIGh5cG90aGV0aWNh bCAzIHNjcmVlbiBwcm92aWRlcidzIGNhcGFiaWxpdGllcy4NCg0KUHJvdmlkZXIgYWR2ZXJ0aXNl cyB0aGVzZSA5IHZpZGVvIGNhcHR1cmVzOg0KVkMwIChsZWZ0KSBub3QgY29tcG9zZWQ7IG5vdCBz d2l0Y2hlZA0KVkMxIChtaWRkbGUpIG5vdCBjb21wb3NlZDsgbm90IHN3aXRjaGVkDQpWQzIgKHJp Z2h0KSBub3QgY29tcG9zZWQ7IG5vdCBzd2l0Y2hlZA0KVkMzIChsZWZ0IGhhbGYgb2YgdHdvIHNj cmVlbiBjb21wb3NpdGlvbikgY29tcG9zZWQ7IG5vdCBzd2l0Y2hlZA0KVkM0IChyaWdodCBoYWxm IG9mIHR3byBzY3JlZW4gY29tcG9zaXRpb24pIGNvbXBvc2VkOyBub3Qgc3dpdGNoZWQNClZDNSAo bGVmdCBoYWxmIG9mIHR3byBzY3JlZW4gc3dpdGNoZWQpIG5vdCBjb21wb3NlZDsgc3dpdGNoZWQN ClZDNiAocmlnaHQgaGFsZiBvZiB0d28gc2NyZWVuIHN3aXRjaGVkKSBub3QgY29tcG9zZWQ7IHN3 aXRjaGVkDQpWQzcgKHNpbmdsZSBzdHJlYW0gY29tcG9zaXRpb24pIGNvbXBvc2VkLCBub3Qgc3dp dGNoZWQNClZDOCAoc2luZ2xlIHN0cmVhbSBzd2l0Y2hlZCkgbm90IGNvbXBvc2VkLCBzd2l0Y2hl ZA0KDQpWQzMgdGhyb3VnaCBWQzggY291bGQgYWxzbyBoYXZlIGFkZGl0aW9uYWwgYXR0cmlidXRl cyBkZXNjcmliaW5nIHRoZSBhdmFpbGFibGUgdmlkZW8gbGF5b3V0IGNob2ljZXMgZm9yIGNvbXBv c2l0aW9uIG9yIHRoZSBhdmFpbGFibGUgc3dpdGNoaW5nIHBvbGljaWVzIHRoZSBwcm92aWRlciBp cyBvZmZlcmluZy4gIFRoZSBjb25zdW1lciBjb3VsZCBjaG9vc2UgYW1vbmcgdGhlc2UuICBJIHRo aW5rIHRoYXQgaXMgdGhlIHBvaW50IFJvbmkgaGFzIGJlZW4gbWFraW5nLiAgRGV0YWlscyBvZiB0 aGlzIG5lZWQgZnVydGhlciBkaXNjdXNzaW9uLiAgKE1heWJlIHRoZSBjb21wb3NlZCBhbmQgc3dp dGNoZWQgY2hvaWNlcyBzaG91bGQgYmUgY29sbGFwc2VkIGludG8gb25lIHNldCBvZiBzdHVmZiB0 byBjaG9vc2UgZnJvbSBmb3IgYSBwYXJ0aWN1bGFyIFZDLCByYXRoZXIgdGhhbiBzZXBhcmF0ZSBW Q3MsIHNvIHRoYXQgd291bGQgcmVkdWNlIHRoZSBudW1iZXIgb2YgVkNzIGhlcmUgZnJvbSA5IHRv IDYgPykuDQoNClByb3ZpZGVyIGFkdmVydGlzZXMgYSBjYXB0dXJlIHNldCB3aXRoIDUgZW50cmll czoNCkVudHJ5IDEgKFZDMCwgVkMxLCBWQzIpDQpFbnRyeSAyIChWQzMsIFZDNCkNCkVudHJ5IDMg KFZDNSwgVkM2KQ0KRW50cnkgNCAoVkM3KQ0KRW50cnkgNSAoVkM4KQ0KDQpCeSBhZHZlcnRpc2lu ZyB0aGUgY2FwdHVyZSBzZXQgaW4gdGhpcyB3YXksIHRoZSBwcm92aWRlciBpcyBzdWdnZXN0aW5n IHdoaWNoIHZpZGVvIGNhcHR1cmVzIGFyZSBtb3N0IHVzZWZ1bCB0byByZWNlaXZlIHRvZ2V0aGVy LCB0byBnZXQgYSB2aWV3IG9mIHRoZSB3aG9sZSBzY2VuZS4gIEVhY2ggZW50cnkgaW4gdGhlIGNh cHR1cmUgc2V0IGlzIGEgc3VnZ2VzdGVkIGFsdGVybmF0aXZlLg0KDQpBIDIgc2NyZWVuIGNvbnN1 bWVyIGNhbiBjaG9vc2UgVkMzIGFuZCBWQzQgaWYgaXQgd2FudHMgYSBjb21wb3NpdGlvbi4gIEl0 IGNhbiBjaG9vc2UgVkM1IGFuZCBWQzYgaWYgaXQgd2FudHMgYSBkeW5hbWljYWxseSBzd2l0Y2hl ZCB2aWV3LiAgQSAyIHNjcmVlbiBjb25zdW1lciBpcyBhbHNvIGZyZWUgdG8gaWdub3JlIHRoZSBz dWdnZXN0aW9ucyBpbiB0aGUgY2FwdHVyZSBzZXQgYW5kIGluc3RlYWQgY2hvb3NlIFZDMCBhbmQg VkMxIGlmIHRoYXQgaXMgd2hhdCBpdCB3YW50cy4gIEl0IGNvdWxkIGFsc28gY2hvb3NlIG90aGVy IGNvbWJpbmF0aW9ucyBmcm9tIGRpZmZlcmVudCBlbnRyaWVzLCBzYXkgVkMxIGFuZCBWQzgsIGFz c3VtaW5nIHRoZSBwcm92aWRlcidzIGFkdmVydGlzZWQgc2ltdWx0YW5lb3VzIHNldHMgYW5kIGVu Y29kaW5nIGdyb3VwcyBkbyBub3QgcHJvaGliaXQgdGhhdCBjb21iaW5hdGlvbi4NCg0KTWFyaw0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXNwZW4gQmVyZ2Vy IChlc3BlYmVyZykNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwMiwgMjAxMiAxMTo0MiBBTQ0K VG86IFBhdWwgS3l6aXZhdDsgY2x1ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjbHVlXSAjNzog SXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhIHN0cnVjdHVyZQ0KDQpIaSBQ YXVsDQoNCkkgd2lsbCBtYWtlIGEgYnJpZWYgYXR0ZW1wdCB0byBhbnN3ZXIuDQoNClRoZSBzY2Vu YXJpb3MgYXJlIGhvdyB0byBtYXAgYSAzeCBjYW1lcmEgc3lzdGVtIHRvIGEgMnggc2NyZWVuIHN5 c3RlbS4gVGhlIHRyaXBsZSBvZmZlciAgU3RyZW1hID0gMSAtIDMgIFBvbGljaWVzID0gU3dpdGNo ZWQsIHN0YXRpYywgY29tcG9zZWQNCg0KQXMgYSByZWNlaXZlciAod2l0aCAyeCBzY3JlZW5zKSBJ IHdvdWxkIGRvIHRoaXMgY2hvaWNlcw0KDQoxKSBIb3cgbWFueSBzdHJlYW1zIHRvIHJlY2VpdmUN CiAgIDEgPT4gVGhlIHRyaXBsZSBzZW5kcyBhIHNpbmdsZSBzdHJlYW0gYnkgc29tZSBzZW5kZXIg cHJlZmVycmVkIHBvbGljeQ0KICAgMiA9PiBUaGUgdHJpcGxlIHNlbmRzIHR3byBzdHJlYW1zIGJ5 IHNvbWUgcG9saWN5DQogICAzID0+IFRoZSB0cmlwbGUgc2VuZHMgdGhyZWUgY2FtZXJhcyBpbiBz cGF0aWFsIG9yZGVyLCBhbmQNCiAgICAgIHRoZSByZWNlaXZlciBkZWNpZGUgaG93IHRvIHJlbmRl ciBhY3Jvc3MgdHdvIHNjcmVlbnMNCg0KMikgV2hpY2ggc3dpdGNoaW5nIHBvbGljeQ0KICBTdGF0 aWMgPT4gVGhlIHJlcXVlc3RlciBhc2sgZm9yIGV4cGxpY2l0IGNhbWVyYSBzdHJlYW1zLCBlLmcu IGNhbTEgb3IgKGNhbTIrY2FtMykNCiAgU3dpdGNoZWQvQ29tcG9zZWQgPT4gVGhlIHRyaXBsZSBj aG9vc2VzIHRoZSBzdHJlYW1zIHRvIHNlbmQsIGUuZy4gdGhlIHR3byBsb3VkZXN0IHNlZ21lbnRz IG9yIGl0IGNvdWxkIG1ha2UgYSBuaWNlIHJlbmRlcmluZyBvZiAzeCBjYW1lcmFzIHJlbmRlcmVk IG9uIHR3byBzdHJlYW1zLg0KDQpJIGFzc3VtZSB0aGF0IHlvdSB3b24ndCB1c2UgZGlmZmVyZW50 IHN3aXRjaGluZyBwb2xpY2llcyBmb3IgdGhlIGRpZmZlcmVudCBzdHJlYW1zLCBzaW5jZSBpdCBn aXZlcyB0aGUgc2VuZGVyIG9mIG1lZGlhIHRoZSBjaGFuY2UgdG8gb3B0aW1pemUgd2hhdCBpdCBz ZW5kIG9uIHRoZSBzdHJlYW1zIHJlcXVlc3RlZC4NCg0KVGhlICdzaXRlJyBzd2l0Y2hpbmcgcG9s aWN5IG1ha2VzIG1vc3Qgc2Vuc2UgZnJvbSBhbiBNQ1UuIEkgaW50ZXJwcmV0ZSB0aGUgcG9saWN5 IGFzIHRyeSB0aGUgYmVzdCB5b3UgY2FuIHRvIHN3aXRjaCBpbiBhbGwgY2FwdHVyZSBzdHJlYW1z IGZyb20gYSByb29tIHdoZW4gdGhlIHJvb20gaXMgYWN0aXZlLiBFeGFtcGxlICBSb29tIEEgaGFz IHR3byBjYW1lcmFzICBSb29tIEIgaGFzIHRocmVlIGNhbWVyYXMgIFJvb20gQyBoYXMgYSBzaW5n bGUgY2FtZXJhICBSb29tIEQgaGFzIHRocmVlIHNjcmVlbnMNCg0KMSkgUm9vbSBEIHJlY2VpdmVz IG1lZGlhIGZyb20gcm9vbSBBIGFuZCBDDQoyKSBSb29tIEIgc3RhcnRzIHRhbGtpbmcNCjNhKSB3 aXRoIHNpdGUgc3dpdGNoaW5nDQogIFJvb20gRCByZWNlaXZlcyBtZWRpYSBvbmx5IGZyb20gRCBh Y3Jvc3MgYWxsIHRocmVlIHNjcmVlbnMNCjNiKSB3aXRoIHNlZ21lbnQgc3dpdGNoaW5nDQogIFJv b20gRCByZWNlaXZlcyBtZWRpYSBmcm9tIEEsIGFuZCB0aGUgbmV3IGFjdGl2ZSBzZWdtZW50IGZy b20gRA0KDQpDaGVlcnMNCg0KLUVzcGVuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFBhdWwgS3l6aXZhdA0KU2VudDogMS4gZmVicnVhciAyMDEyIDE4OjI5 DQpUbzogY2x1ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjbHVlXSAjNzogSXMgY29tcG9zZWQg YXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhIHN0cnVjdHVyZQ0KDQpFc3BlbiwNCg0KSVNUTSB0 aGF0IGZvciBhIHN3aXRjaGVkIHN0cmVhbSB5b3UgaGF2ZToNCi0gdGhlIHNldCBvZiBjYW5kaWRh dGUgc3RyZWFtcyB0byBiZSBzd2l0Y2hlZCBhbW9uZw0KLSBhbiBhbGdvcml0aG0gZm9yIHBpY2tp bmcgYW1vbmcgdGhlbQ0KDQpJZiB0aGUgcmVjZWl2ZXIgaGFzIG11bHRpcGxlIHNjcmVlbnMsIHRo ZW4gdGhlcmUgd2lsbCBiZSBhIHN0cmVhbSBmb3IgZWFjaCBvbmUsIGFuZCBlYWNoIGNvdWxkIGhh dmUgZGlmZmVyZW50IGNhbmRpZGF0ZSBpbnB1dCBzdHJlYW1zIGFuZCBhIGRpZmZlcmVudCBwb2xp Y3kuDQoNCldoYXQgeW91IGFyZSBkZXNjcmliaW5nIGFzICJzaXRlIHN3aXRjaGluZyIgYWRkcyBh bm90aGVyIHdyaW5rbGUsIHNpbmNlIGl0IGlzIGNvdXBsaW5nIHRoZSBzd2l0Y2hpbmcgcG9saWNp ZXMgZm9yIG11bHRpcGxlIHN0cmVhbXMuIEFsc28sIEknbSBub3Qgc3VyZSBob3cgaXQgd29ya3Mg aWYgdGhlIHNpdGVzIGhhdmUgZGlmZmVyaW5nIG51bWJlcnMgb2Ygc2NyZWVucyBhbmQgY2FtZXJh cy4gSG93IHdvdWxkIHlvdSBkZXNjcmliZSB0aGUgaW5kaXZpZHVhbCBzdHJlYW1zIGZyb20gdGhl IE1DVSBzbyB0aGF0IGEgcm9vbSBjb3VsZCBzZWxlY3QgYW4gYXBwcm9wcmlhdGUgc2V0IG9mIHN0 cmVhbXMgdG8gZ2V0IHNpdGUgc3dpdGNoaW5nPw0KDQpJdCB3b3VsZCBiZSBoZWxwZnVsICh0byBt ZSBhbnl3YXkpIGlmIHlvdSBjb3VsZCBkZXNjcmliZSB0aGUgaW50ZXJlc3RpbmcgY2FzZXMgYnkg ZW51bWVyYXRpbmcgdGhlIG9mZmVyZWQgc3RyZWFtcyB0b2dldGhlciB3aXRoIHRoZSBpbnB1dHMg YW5kIHRoZSBhbGdvcml0aG0gdXNlZCBmb3IgZWFjaC4gUmlnaHQgbm93LCBJJ20gbm90IHN1cmUg aG93IHRvIGRvIHRoYXQuDQoNCiAgICAgICAgVGhhbmtzLA0KICAgICAgICBQYXVsDQoNCk9uIDIv MS8xMiA4OjAwIEFNLCBFc3BlbiBCZXJnZXIgKGVzcGViZXJnKSB3cm90ZToNCj4gSSB3b3VsZCBz dGlsbCBjYWxsIGl0IHN3aXRjaC1wb2xpY3ksIGUuZy4gdGhlbiBwb3NzaWJsZSB2YWx1ZXMgY291 bGQgYmU6DQo+ICogU2l0ZTogQ2hhbmdlIGFsbCBhdCB0aGUgc2FtZSB0aW1lDQo+ICogU2VnbWVu dDogT25seSBjaGFuZ2UgdGhlIGFjdGl2ZSBzZWdtZW50DQo+ICogUm91bmQgcm9iaW46IENoYW5n ZSBhY3RpdmUgc2VnbWVudCBhbmQgdGhlbiBjaGFuZ2UgdG8gb3RoZXIgc2VnbWVudHMgaW4gMTAg c2VjIGludGVydmFscy4NCj4NCj4gSG93IHlvdSBzd2l0Y2ggYmV0d2VlbiBzdHJlYW1zIGFuZCBo b3cgeW91IHJlbmRlciBoYXMgZGlmZmVyZW50IHJlcXVpcmVtZW50cyBhbmQgcG9saWNpZXMsIHNv IEkgZmluZCBpdCB2ZXJ5IHVzZWZ1bCB0byBkaXNjdXNzIHRoZW0gYXMgdHdvIHNlcGFyYXRlIGlz c3VlcyB0byBhdm9pZCBjb25mdXNpb24uDQo+DQo+IENoZWVycw0KPg0KPiAtRXNwZW4NCj4NCj4N Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9uaSBFdmVuIFttYWlsdG86 cm9uLmV2ZW4udGx2QGdtYWlsLmNvbV0NCj4gU2VudDogMS4gZmVicnVhciAyMDEyIDExOjMwDQo+ IFRvOiBFc3BlbiBCZXJnZXIgKGVzcGViZXJnKTsgY2x1ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS RTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4g c3RydWN0dXJlDQo+DQo+IEhpIEVzcGVuLA0KPiBJIGNhbGxlZCBzaXRlIG9yIHNlZ21lbnQgc3dp dGNoIGEgcG9saWN5IGJ1dCBJIGFtIG5vdCBzdXJlIHRoYXQgaXQgaXMgYSBzd2l0Y2ggcG9saWN5 IGJ5IGl0c2VsZiBzaW5jZSBzZWdtZW50IHN3aXRjaCBmb3IgZXhhbXBsZSBjYW4gaGFwcGVuIGJh c2VkIG9uIGFjdGl2ZSBzcGVha2VycyBvciBzb21lIHJvdW5kIHJvYmluIHRpbWluZyB3aGljaCBp cyB0aGUgc3dpdGNoaW5nIHBvbGljeS4NCj4gUm9uaQ0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+IEZyb206IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpIFttYWlsdG86ZXNwZWJl cmdAY2lzY28uY29tXQ0KPj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAzMSwgMjAxMiA1OjM4IFBN DQo+PiBUbzogUm9uaSBFdmVuOyBjbHVlQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSRTogW2NsdWVd ICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4+IHN0cnVjdHVy ZQ0KPj4NCj4+IEhpIFJvbnkNCj4+DQo+PiBUbyBjaG9vc2UgYmV0d2VlbiBzaXRlIGFuZCBzZWdt ZW50IHN3aXRjaCBpcyBtb3JlIGEgcG9saWN5IHRoYW4gYQ0KPj4gPHZpZGVvLWxheW91dD4sIHNv IGluIHRoYXQgY2FzZSBJIHdvdWxkIGFyZ3VlIHRoYXQgeW91IGNvdWxkIG9mZmVyIGENCj4+IENh cHR1cmUgc3RyZWFtIHdpdGggYSBzd2l0Y2gtcG9saWN5ID0ge3NpdGUsIHNlZ21lbnR9DQo+Pg0K Pj4gTXkgcG9pbnQgYWJvdXQgaW50ZXJvcGVyYWJpbGl0eSBpcyB0aGF0IGEgc2luZ2xlIGNvbXBv c2VkIHN0cmVhbSB3aXRoDQo+PiBhbHRlcm5hdGl2ZSBsYXlvdXRzIGFyZSBlYXNpZXIgdG8gdW5k ZXJzdGFuZCwgdGhhbiBtdWx0aXBsZSBjYXB0dXJlDQo+PiBzdHJlYW1zIHdpdGggYWx0ZXJuYXRp dmUgY29uZmlndXJhdGlvbnMuIFRoZSBsYXN0IHJlcXVpcmVzIHRvIHBpY2sNCj4+IHRoZSBmaXJz dCBvbmUgb3IgcmVxdWlyZXMgc29tZSBzb3J0IG9mIGRlZmF1bHQgbWFya2luZy4NCj4+DQo+PiBD aGVlcnMNCj4+DQo+PiAtRXNwZW4NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+IEZyb206IFJvbmkgRXZlbiBbbWFpbHRvOnJvbi5ldmVuLnRsdkBnbWFpbC5jb21dDQo+ PiBTZW50OiAzMS4gamFudWFyIDIwMTIgMDA6MDYNCj4+IFRvOiBFc3BlbiBCZXJnZXIgKGVzcGVi ZXJnKTsgY2x1ZUBpZXRmLm9yZw0KPj4gU3ViamVjdDogUkU6IFtjbHVlXSAjNzogSXMgY29tcG9z ZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhDQo+PiBzdHJ1Y3R1cmUNCj4+DQo+PiBIaSBF c3BlbiwNCj4+IElmIHRoZSBwcm92aWRlciB3YW50cyB0byBvZmZlciBzaXRlIHN3aXRjaCBhbmQg c2VnbWVudCBzd2l0Y2ggb3B0aW9uDQo+PiB0byB0aGUgY29uc3VtZXIgaGUgY2Fubm90IGRvIGl0 IGp1c3Qgd2l0aCBBLiB0aGlzIGlzIGEgYmFzaWMgdXNlIGNhc2UuDQo+Pg0KPj4gSW4gZ2VuZXJh bCwgeW91ciBvcHRpb24gZG9lcyBub3QgcHJvdmlkZSBhbnkgaW50ZXJvcGVyYWJpbGl0eSBzaW5j ZQ0KPj4gYm90aCBzaWRlcyBtYXkgaGF2ZSBkaWZmZXJlbnQgdmlld3Mgd2hhdCBjb21wb3NlZCBt ZWFucy4gSW4gdGhlDQo+PiBmcmFtZXdvcmsgZXhhbXBsZSBvZiBhIFBJUCBhcyBjb21wb3NlZCBp bWFnZSBpdCBpcyBhbiBhc3N1bXB0aW9uIHRoYXQNCj4+IGlmIHRoZSBwcm92aWRlciBvZmZlcnMg dGhpcyBjb21wb3NlZCBvZmZlciwgdGhlIGNvbnN1bWVyIGNhbg0KPj4gdW5kZXJzdGFuZCB0aGF0 IGl0IGlzIGEgUElQIG1peCBidXQgdGhlcmUgaXMgbm90aGluZyBpbiB0aGUgb2ZmZXINCj4+IHRo YXQgd2lsbCBpbmRpY2F0ZSB0aGF0IGl0IGlzLg0KPj4NCj4+IFJvbmkNCj4+DQo+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBFc3BlbiBCZXJnZXIgKGVzcGViZXJnKSBb bWFpbHRvOmVzcGViZXJnQGNpc2NvLmNvbV0NCj4+PiBTZW50OiBNb25kYXksIEphbnVhcnkgMzAs IDIwMTIgNToyMSBQTQ0KPj4+IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0Zi5vcmcNCj4+PiBTdWJq ZWN0OiBSRTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRh dGENCj4+PiBzdHJ1Y3R1cmUNCj4+Pg0KPj4+IEhpIFJvbmkNCj4+Pg0KPj4+IElmIHlvdeKAmXJl IGEgcGFydGljdWxhciB1c2UgY2FzZXMgcmVxdWlyZXMgY29udHJvbCBvdmVyIHRoZSBjb21wb3Nl ZA0KPj4+IGxheW91dHMgeW91IG5lZWQgYSkgYW5kIGIpLiBJbiBteSBleGFtcGxlIEkgdXNlZCBh IHNpbmdsZQ0KPj4+IGFkdmVydGlzZW1lbnQgY29tcG9zZWQgc3RyZWFtIHdpdGggb3B0aW9uYWwg bWV0YS1pbmZvcm1hdGlvbiBhYm91dA0KPj4+IHBvc3NpYmxlIGxheW91dCBjaG9pY2VzLiBBIHJl Y2VpdmVyIHRoYXQgd2FudHMgdGhlIGRlZmF1bHQgY29tcG9zZWQNCj4+PiBsYXlvdXQgY2FuIHJl cXVlc3QgdGhlIGNvbXBvc2VkIHN0cmVhbSBhbmQgc2tpcCB0aGUgb3B0aW9uYWwgdmlkZW8tDQo+ PiBsYXlvdXQgaW5mb3JtYXRpb24uDQo+Pj4gT3B0aW9uYWxseSB5b3UgY291bGQgcmVxdWVzdCB0 aGUgc2FtZSBjb21wb3NlZCBzdHJlYW0gd2l0aCBsYXlvdXRzDQo+Pj4gaGludHMgZm9yIHRoZSBy ZWNlaXZlci4NCj4+Pg0KPj4+IEZvciBtZSB1c2UgY2FzZSBjKSBkb2VzIG5vdCBpbmNsdWRlIHRo ZSBzZWxlY3Rpb24gbWVjaGFuaXNtcywgb25seQ0KPj4gdGhlDQo+Pj4gY29udGVudCB5b3Ugc2Vl IGluIHRoZSB2aWRlbyBzdHJlYW0uDQo+Pj4NCj4+PiBDaGVlcnMNCj4+Pg0KPj4+IC1Fc3Blbg0K Pj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBSb25pIEV2ZW4g W21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXQ0KPj4+IFNlbnQ6IDMwLiBqYW51YXIgMjAx MiAxNTozOQ0KPj4+IFRvOiBFc3BlbiBCZXJnZXIgKGVzcGViZXJnKTsgY2x1ZUBpZXRmLm9yZw0K Pj4+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xl YW4gb3IgZGF0YQ0KPj4+IHN0cnVjdHVyZQ0KPj4+DQo+Pj4gSGkgRXNwZW4sDQo+Pj4gSWYgeW91 IHdpbGwgbG9vayBhdCB0aGUgbm90ZXMgZnJvbSB0aGUgbGFzdCBjYWxsIHRoZXJlIHdhcyBhIHN1 cHBvcnQNCj4+PiB0aGF0IGEpIGlzIG5vdCBlbm91Z2guIEhhdmluZyBqdXN0IGNvbXBvc2UgZG9l cyBub3QgYWRkcmVzcyBldmVuIHRoZQ0KPj4+IHVzZSBjYXNlcyBJIHByb3ZpZGVkIHdoaWNoIGFy ZSBhbHNvIGJhc2VkIG9uIHRoZSB1c2UgY2FzZSBkcmFmdC4NCj4+Pg0KPj4+DQo+Pj4gSSBhbSBu b3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IEMgc2luY2Ugd2hhdCBpbiB0aGUgY29tcG9zZWQgc3Ry ZWFtDQo+PiBjYW4NCj4+PiBiZSBlaXRoZXIgd2hpY2ggVkMgeW91IHNlZSBvciB3aGF0IGlzIHRo ZSBzZWxlY3Rpb24gY3JpdGVyaWEgZm9yDQo+PiBiZWluZw0KPj4+IGluIGEgY29tcG9zZWQgc3Ry ZWFtLiBJZiB5b3UgbWVhbnQgdGhlIHNlY29uZCwgbXkgdmlldyBpcyB0aGF0IEMgYW5kDQo+Pj4g YWxzbyBiIHNob3VsZCBiZSBpbiB0aGUgYmFzaWMgZnJhbWV3b3JrIGFuZCBub3QgaW4gYW4gZXh0 ZW5zaW9uLg0KPj4+DQo+Pj4gUm9uaSBFdmVuDQo+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+Pj4gRnJvbTogRXNwZW4gQmVyZ2VyIChlc3BlYmVyZykgW21haWx0bzplc3Bl YmVyZ0BjaXNjby5jb21dDQo+Pj4+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAzMCwgMjAxMiA0OjE3 IFBNDQo+Pj4+IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUkU6 IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhDQo+Pj4+ IHN0cnVjdHVyZQ0KPj4+Pg0KPj4+Pg0KPj4+PiBUbyBoZWxwIHdpdGggdGhlIGRpcmVjdGlvbiBv ZiB0aGUgZGlzY3Vzc2lvbnMgSSB0aGluayBpdCdzIHVzZWZ1bA0KPj4gdG8NCj4+Pj4gZGl2aWRl IHRoZSBkaXNjdXNzaW9ucyBpbnRvIHRocmVlIHVzZSBjYXNlcyBmb3IgY29tcG9zZWQgc3RyZWFt cy4NCj4+Pj4gICBhKSBIb3cgdG8gZXhwcmVzcyBpZiBhIGNhcHR1cmUgc3RyZWFtIGlzIGNvbXBv c2VkIG9yIG5vdA0KPj4+PiAgIGIpIEhvdyB0byBleHByZXNzIGxheW91dCBjaG9pY2VzPyAoZS5n LiB3aXRoIGEgdmlkZW8tbGF5b3V0DQo+Pj4+IGVsZW1lbnQpDQo+Pj4+ICAgYykgSG93IHRvIGV4 cHJlc3Mgd2hhdCdzIGluc2lkZSBhIGNvbXBvc2VkIHN0cmVhbQ0KPj4+Pg0KPj4+PiBGb3IgdXNl IGNhc2UgYSkgYSBjb21wb3NlZCBhdHRyaWJ1dGUgc2hvdWxkIGJlIHN1ZmZpY2llbnQsIHlvdQ0K Pj4+PiBlaXRoZXIgYXNrIGZvciB0aGUgY29tcG9zZWQgc3RyZWFtIG9yIHlvdSBkbyBub3QuDQo+ Pj4+IEkgYWxzbyBiZWxpZXZlIHRoaXMgc2hvdWxkIGNvdmVyIHRoZSBpbnRlcm9wZXJhYmlsaXR5 IHJlcXVpcmVtZW50DQo+PiB3ZQ0KPj4+PiBoYXZlIGFjcm9zcyBtdWx0aXBsZSB0eXBlcyBvZiBl bmRwb2ludHMuDQo+Pj4+DQo+Pj4+IEZvciB1c2UgY2FzZSBiKSBib3RoIG1lZGlhY3RybCBhbmQg eGNvbiB1c2VzIGE8dmlkZW8tbGF5b3V0Pg0KPj4+PiBlbGVtZW50IHRvIGRlc2NyaWJlIHBvc3Np YmxlIGxheW91dHMgYW5kIGFsc28gdG8gcmVxdWVzdCB0aGUNCj4+Pj4gcHJlZmVycmVkIGxheW91 dCBiYXNlZCBvbiBvcHRpb25zLiAoYXMgZGVzY3JpYmVkIGluIFJvbmkncyBlbWFpbCkNCj4+Pj4N Cj4+Pj4gQW4gZXhhbXBsZSBjb3VsZCBiZSAoaW5zcGlyZWQgYnkgbWVkaWFjdHJsIGFuZCB4Y29u IHVzYWdlIG9mDQo+PiA8dmlkZW8tDQo+Pj4+IGxheW91dD4pOg0KPj4+Pg0KPj4+PiBDTFVFIEFk dmVydGlzZW1lbnQNCj4+Pj4gICAgQ2FwdHVyZSBpZD0yIFB1cnBvc2U9cGVvcGxlIENvbXBvc2Vk PWZhbHNlDQo+Pj4+ICAgIENhcHR1cmUgaWQ9MyBQdXJwb3NlPXBlb3BsZSBDb21wb3NlZD1mYWxz ZQ0KPj4+PiAgICBDYXB0dXJlIGlkPTQgUHVycG9zZT1QZW9wbGUgQ29tcG9zZWQ9dHJ1ZQ0KPj4+ PiAgICAgICAgVmlkZW8tbGF5b3V0PSInYXV0b21hdGljJywgJ2R1YWwtdmlldycsICcgc2luZ2xl LXZpZXcnIg0KPj4+Pg0KPj4+PiBDTFVFIGNvbmZpZ3VyZSAvLyBEZWZhdWx0IGNvbXBvc2VkIHN0 cmVhbQ0KPj4+PiAgICBDYXB0dXJlIGlkPTQNCj4+Pj4NCj4+Pj4gLy8gT3IgY29tcG9zZWQgc3Ry ZWFtIHdpdGggbGF5b3V0IGhpbnRzDQo+Pj4+ICAgICBDYXB0dXJlIGlkPTQgVmlkZW8tbGF5b3V0 PSdkdWFsLXZpZXcnDQo+Pj4+DQo+Pj4+IFRoZSB2aWRlby1sYXlvdXQgZWxlbWVudCBpcyBhIGxp c3Qgb2Ygc3RyaW5ncyBhbmQgZWFjaCBzdHJpbmcgaXMgYQ0KPj4+PiBsYXlvdXQtaGludCB0aGF0 IGNhbiBiZSByZXF1ZXN0ZWQuIFZpZGVvLWxheW91dCBpcyBvcHRpb25hbC4gQQ0KPj4+PiBsYXlv dXQgaGludHMgYWJvdXQgdGhlIHJlcXVlc3RlZCByZW5kZXJpbmcgYW5kIHRoZSBzb3VyY2UgaXMg ZnJlZQ0KPj4gdG8NCj4+Pj4gcmVwbGFjZSBhbnkgc3RyZWFtIGFzIGxvbmcgYXMgdGhleSBmaXQg dGhlIGxheW91dC4NCj4+Pj4NCj4+Pj4gVXNlIGNhc2UgYykgaXMgbW9yZSBvcGVuIGluIHRoZSBz ZW5zZSB0aGF0IHdoYXQgeW91IGFjdHVhbGx5DQo+PiByZWNlaXZlDQo+Pj4+IGluIGEgY29tcG9z ZWQgc3RyZWFtIGlzIGRlcGVuZGluZyBvbiBzdGF0dXMgb2YgYSByb29tIG9yIHdobyBpcyBpbg0K Pj4gYQ0KPj4+PiBNQ1UgY29uZmVyZW5jZS4gRS5nLiBmcm9tIGEgcm9vbSB5b3UgY291bGQgZ2V0 IGEgbWl4IG9mIGRpZmZlcmVudA0KPj4+PiBjYXB0dXJlIHN0cmVhbSByZXByZXNlbnRpbmcgY2Ft ZXJhcyBhbmQgZnJvbSBhIHRyYW5zY29kaW5nIE1DVSBpdA0KPj4+PiBjb3VsZCBiZSBkaWZmZXJl bnQgcm9vbSwgZGlmZmVyZW50IGNhbWVyYXMgb3IgYW5vdGhlciBtaXggb2YNCj4+Pj4gcG9zc2li bGUgaW5wdXQgdmlkZW8gc3RyZWFtcy4NCj4+Pj4NCj4+Pj4gSGF2aW5nIHN1cHBvcnQgZm9yIGJv dGggYikgYW5kIGMpIGNvdWxkIGJlIGEgZ29vZCB0ZXN0IGZvciB0aGUNCj4+Pj4gZXh0ZW5zaWJp bGl0eSBvZiBDTFVFLiBJZiB0aGUgYmFzaXMgb2YgQ0xVRSBvbmx5IGRvZXMgdXNlIGNhc2UgYSkN Cj4+Pj4gdGhlcmUgc2hvdWxkIGJlIHJvb20gdG8gZXh0ZW5kIENMVUUgd2l0aCBzdXBwb3J0IGZv ciBiKSBhbmQgYykgYXMgYQ0KPj4+PiBDTFVFICsgbGF5b3V0IGRlc2NyaXB0aW9uIGV4dGVuc2lv bi4NCj4+Pj4NCj4+Pj4gQ2hlZXJzDQo+Pj4+DQo+Pj4+IC1Fc3Blbg0KPj4+Pg0KPj4+Pg0KPj4+ Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBjbHVlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+PiBCZWhhbGYN Cj4+Pj4gT2YgUm9uaSBFdmVuDQo+Pj4+IFNlbnQ6IDMwLiBqYW51YXIgMjAxMiAxMToxOA0KPj4+ PiBUbzogY2x1ZUBpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogW2NsdWVdICM3OiBJcyBjb21w b3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4+Pj4gc3RydWN0dXJlDQo+Pj4+DQo+ Pj4+IEhpLA0KPj4+PiBEdXJpbmcgdGhlIGxhc3QgY2FsbCBJIHZvbHVudGVlcmVkIHRvIHByb3Zp ZGUgc29tZSBpbnB1dC4NCj4+Pj4NCj4+Pj4gSW4gY3VycmVudCBJRVRGIHdvcmsgKFhDT04sIE1l ZGlhY3RybCBXR3MgdGhlcmUgaXMgYSB2aWRlbyBsYXlvdXQNCj4+Pj4gZWxlbWVudCkNCj4+Pj4N Cj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tZWRpYWN0cmwtbWl4 ZXItY29udHJvbC0NCj4+PiBwYWNrYWdlLQ0KPj4+PiAxNCNzZWN0aW9uLTQuMi4xLjQuMi4xDQo+ Pj4+DQo+Pj4+IGFuZA0KPj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXhjb24tY29tbW9uLWRhdGEtbW9kZWwtDQo+Pj4+IDMyI3NlY3Rpb24tNC4yLjcgKGxvb2sgYXQg dmlkZW8tbGF5b3V0KQ0KPj4+Pg0KPj4+PiBJIHdvdWxkIGxpa2UgZmlyc3QgdG8gdHJ5IHRvIGRl ZmluZSB0aGUgdGVybSAiY29tcG9zZWQgdmlkZW8iIHNpbmNlDQo+Pj4gaXQNCj4+Pj4gbG9va3Mg dG8gbWUgbGlrZSB3ZSBoYXZlIGRpZmZlcmVudCB2aWV3cyBoZXJlLCBhbmQgcHJvdmlkZSBteQ0K Pj4+PiBpbml0aWFsIHZpZXcgb24gd2hhdCBzaG91bGQgYmUgZGVzY3JpYmVkLg0KPj4+Pg0KPj4+ PiBDb21wb3NlZCB2aWRlbyBjYW4gZGVzY3JpYmVzIGJvdGggdGhlIGxheW91dCBhbmQgdGhlIHNl bGVjdGlvbg0KPj4+PiBhbGdvcml0aG0gZm9yIGNvbXBvc2luZyB0aGUgIGNvbnRlbnQgb2YgdGhl IHN1Yi13aW5kb3dzIGluIHRoZQ0KPj4+ICJtaXhlZCINCj4+Pj4gdmlkZW8uDQo+Pj4+DQo+Pj4+ IFRoZSB2aWRlbyBsYXlvdXQgd2hpY2gganVzdCBkZXNjcmliZXMgdGhlIGdlb21ldHJ5IG9mIHRo ZSBjb21wb3NlZA0KPj4+PiBpbWFnZSBhbmQgSSB0aGluayB0aGF0IHRoZSBhYm92ZSByZWZlcmVu Y2VzIHByb3ZpZGUgZ29vZCBzdHJ1Y3R1cmUNCj4+Pj4gdG8gZGVmaW5lIHRoaXMgcGFydCBvZiB0 aGUgY29tcG9zZWQgdmlkZW8gYXR0cmlidXRlLg0KPj4+Pg0KPj4+PiBUaGUgb3RoZXIgcGFydCBp cyB0aGUgYWxnb3JpdGhtIGJ5IHdoaWNoIHRoZSBwcm92aWRlciBzZWxlY3QgdGhlDQo+Pj4+IGNv bnRlbnQgb2YgZWFjaCBlbGVtZW50IGluIHRoZSBsYXlvdXQuIFNpbmNlIHRoZSBjb250ZW50IG9m IGVhY2gNCj4+Pj4gZWxlbWVudCBtYXkgY2hhbmdlIGR5bmFtaWNhbGx5IGJ5IHRoZSBwcm92aWRl ciB0aGlzIGF0dHJpYnV0ZSBvbmx5DQo+Pj4+IGFkZHJlc3MgdGhlIHN0YXRpYyBpbmZvcm1hdGlv biB3aGljaCBpcyB0aGUgYWxnb3JpdGhtIGFuZCBub3QgdGhlDQo+Pj4+IGN1cnJlbnQgY29udGVu dCAod2hvIHdlIHNlZSBub3cgaW4gZWFjaCBlbGVtZW50KSB3aGljaCB3aWxsIG5lZWQgdG8NCj4+ PiBiZQ0KPj4+PiBjb252ZXllZCBhbHNvIGJ1dCBwcm9iYWJseSBub3QgdXNpbmcgdGhpcyBhdHRy aWJ1dGUuIE5vdGUgdGhhdCB0aGUNCj4+Pj4gaW5mb3JtYXRpb24gaXMgdmFsaWQgZm9yIHBvaW50 IHRvIHBvaW50IGFuZCBtdWx0aXBvaW50IHNvIHRoZQ0KPj4+PiBjdXJyZW50IGNvbnRlbnQgc2hv dWxkIHJlZmxlY3QgdGhlIFRQIGVuZCBwb2ludCBhbmQgdGhlIHNwZWNpZmljIFZDDQo+Pj4+IHVz ZWQgZnJvbSBpdC4NCj4+Pj4NCj4+Pj4gVGhlIGFsZ29yaXRobXMgbWF5IGJlIGdsb2JhbCBvciBw ZXIgZWxlbWVudChvciBzdWItd2luZG93KS4gVGhlDQo+Pj4gZ2xvYmFsDQo+Pj4+IGFsZ29yaXRo bXMgSSBzZWUgYXJlIHNpdGUgc3dpdGNoIG9yIHNlZ21lbnQgc3dpdGNoLiBUaGUgcGVyIGVsZW1l bnQNCj4+Pj4gbWF5IGJlIHZvaWNlIGFjdGl2YXRlZCwgcm91bmQgcm9iaW4gKHN3aXRjaCBldmVy eSB4IHNlY29uZHMpIGFuZA0KPj4+IGZpeGVkDQo+Pj4+ICh0aGUgc2FtZSBWQyBpcyBkaXNwbGF5 ZWQgdGhlcmUgKG1heSBiZSBjaGFuZ2VkIGJ5IHNvbWUgY29udHJvbA0KPj4+PiBtZWNoYW5pc20p DQo+Pj4+DQo+Pj4+DQo+Pj4+IFJvbmkNCj4+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+PiBGcm9tOiBjbHVlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjbHVlLWJv dW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4gQmVoYWxmDQo+Pj4+PiBPZiBjbHVlIGlzc3VlIHRyYWNr ZXINCj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjQsIDIwMTIgMTI6NDMgQU0NCj4+Pj4+ IFRvOiBkcmFmdC1pZXRmLWNsdWUtZnJhbWV3b3JrQHRvb2xzLmlldGYub3JnOw0KPj4+Pj4gbWFy eS5pZXRmLmJhcm5lc0BnbWFpbC5jb20NCj4+Pj4+IENjOiBjbHVlQGlldGYub3JnDQo+Pj4+PiBT dWJqZWN0OiBSZTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9y IGRhdGENCj4+Pj4+IHN0cnVjdHVyZQ0KPj4+Pj4NCj4+Pj4+ICM3OiBJcyBjb21wb3NlZCBhdHRy aWJ1dGUgYSBib29sZWFuIG9yIGRhdGEgc3RydWN0dXJlDQo+Pj4+Pg0KPj4+Pj4gQ2hhbmdlcyAo YnkgbWFyeS5pZXRmLmJhcm5lc0DigKYpOg0KPj4+Pj4NCj4+Pj4+ICAgKiB0eXBlOiAgZGVmZWN0 ID0+ICB0YXNrDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IC0tDQo+Pj4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gLQ0K Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLQ0KPj4+IC0NCj4+Pj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0NCj4+Pj4gLQ0KPj4+Pj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLQ0KPj4+Pj4gLS0tLQ0KPj4+Pj4gICBSZXBvcnRlcjog IG1hcnkuaWV0Zi5iYXJuZXNA4oCmICB8ICAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1jbHVlLQ0K Pj4+Pj4gZnJhbWV3b3JrQOKApg0KPj4+Pj4gICAgICAgVHlwZTogIHRhc2sgICAgICAgICAgICAg ICAgfCAgICAgIFN0YXR1czogIG5ldw0KPj4+Pj4gICBQcmlvcml0eTogIG1ham9yICAgICAgICAg ICAgICAgfCAgIE1pbGVzdG9uZToNCj4+Pj4+IENvbXBvbmVudDogIGZyYW1ld29yayAgICAgICAg ICAgfCAgICAgVmVyc2lvbjoNCj4+Pj4+ICAgU2V2ZXJpdHk6ICBBY3RpdmUgV0cgRG9jdW1lbnQg IHwgIFJlc29sdXRpb246DQo+Pj4+PiAgIEtleXdvcmRzOiAgICAgICAgICAgICAgICAgICAgICB8 DQo+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4gLQ0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLQ0KPj4+IC0NCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0N Cj4+Pj4gLQ0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLQ0KPj4+Pj4g LS0tLQ0KPj4+Pj4NCj4+Pj4+IFRpY2tldCBVUkw6DQo+Pj4+PiA8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvd2cvY2x1ZS90cmFjL3RpY2tldC83I2NvbW1lbnQ6Mj4NCj4+Pj4+IGNsdWU8aHR0 cDovL3Rvb2xzLmlldGYub3JnL3dnL2NsdWUvPg0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBjbHVlIG1haWxpbmcgbGlz dA0KPj4+Pj4gY2x1ZUBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jbHVlDQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+IGNsdWUgbWFpbGluZyBsaXN0DQo+Pj4+IGNsdWVAaWV0 Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo+ Pg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBjbHVlIG1haWxpbmcgbGlzdA0KPiBjbHVlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KY2x1ZSBtYWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNsdWUgbWFpbGluZyBsaXN0DQpj bHVlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUN Cg== From ron.even.tlv@gmail.com Wed Feb 8 08:58: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 91E7121F853B for ; Wed, 8 Feb 2012 08:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 Kz64gt44Mm5m for ; Wed, 8 Feb 2012 08:58:20 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEC5721F851C for ; Wed, 8 Feb 2012 08:58:19 -0800 (PST) Received: by eaal12 with SMTP id l12so253968eaa.31 for ; Wed, 08 Feb 2012 08:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=zl2dm6yqCEyX4qdQwkdphdaSBbjtgkaZEaMDrFghyUA=; b=cLFINCtAiLCIbqBlqGPfrtjUhMjYD9r91th/BSncX7ZM43lCZ3xg47aq//ZYPklh0C 0vU0lQiCb1Nbpuf1tnobM68sbUk9WmvQ6rAGzFjH/uZFjfR2XUvvGANHKahxVClY/UTc Pc47yR3vsr+wIA3eU43SXA94001SfmKMlmgQ4= Received: by 10.213.16.142 with SMTP id o14mr3051514eba.144.1328720298745; Wed, 08 Feb 2012 08:58:18 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id o49sm4146180eei.0.2012.02.08.08.58.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 08:58:17 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org><4f266f4c.d0770e0a.43c6.37fd@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com><4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com><4f272344.03bd0e0a.6983.3d7e@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com><4f291525.84310e0a.69d7.fffffd3b@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com> <4F29766F.1080101@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB202D20@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB202D20@CRPMBOXPRD01.polycom.com> Date: Wed, 8 Feb 2012 18:58:02 +0200 Message-ID: <4f32a9a9.c9840e0a.492a.ffffd4d9@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: AczhBxgZzsQM+HraTUCVftAm4h2iFAAvm5hgASwpd2AAAwipoA== Content-Language: en-us 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, 08 Feb 2012 16:58:21 -0000 Hi Mark, I can add two more options. 1. Two out of three which will include the current and previous speaker 2. Two out of three which will rotate between the three every 10 seconds These two cannot be differentiated with binary composed and switched. If we go from three to one we have even more options that cannot be = differentiated by binary values and I think that three to one will be = more common. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Duckworth, Mark > Sent: Wednesday, February 08, 2012 5:54 PM > To: clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data > structure >=20 > I'll add my thoughts to this, for how I see this scenario working (3x > camera system sending to a 2x screen system), using Espen's ideas for > what the alternatives are for this particular example, given this > particular hypothetical 3 screen provider's capabilities. >=20 > Provider advertises these 9 video captures: > VC0 (left) not composed; not switched > VC1 (middle) not composed; not switched > VC2 (right) not composed; not switched > VC3 (left half of two screen composition) composed; not switched > VC4 (right half of two screen composition) composed; not switched > VC5 (left half of two screen switched) not composed; switched > VC6 (right half of two screen switched) not composed; switched > VC7 (single stream composition) composed, not switched > VC8 (single stream switched) not composed, switched >=20 > VC3 through VC8 could also have additional attributes describing the > available video layout choices for composition or the available > switching policies the provider is offering. The consumer could = choose > among these. I think that is the point Roni has been making. Details > of this need further discussion. (Maybe the composed and switched > choices should be collapsed into one set of stuff to choose from for a > particular VC, rather than separate VCs, so that would reduce the > number of VCs here from 9 to 6 ?). >=20 > Provider advertises a capture set with 5 entries: > Entry 1 (VC0, VC1, VC2) > Entry 2 (VC3, VC4) > Entry 3 (VC5, VC6) > Entry 4 (VC7) > Entry 5 (VC8) >=20 > By advertising the capture set in this way, the provider is suggesting > which video captures are most useful to receive together, to get a = view > of the whole scene. Each entry in the capture set is a suggested > alternative. >=20 > A 2 screen consumer can choose VC3 and VC4 if it wants a composition. > It can choose VC5 and VC6 if it wants a dynamically switched view. A = 2 > screen consumer is also free to ignore the suggestions in the capture > set and instead choose VC0 and VC1 if that is what it wants. It could > also choose other combinations from different entries, say VC1 and = VC8, > assuming the provider's advertised simultaneous sets and encoding > groups do not prohibit that combination. >=20 > Mark >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Espen Berger (espeberg) > Sent: Thursday, February 02, 2012 11:42 AM > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data > structure >=20 > Hi Paul >=20 > I will make a brief attempt to answer. >=20 > The scenarios are how to map a 3x camera system to a 2x screen system. > The triple offer Strema =3D 1 - 3 Policies =3D Switched, static, = composed >=20 > As a receiver (with 2x screens) I would do this choices >=20 > 1) How many streams to receive > 1 =3D> The triple sends a single stream by some sender preferred > policy > 2 =3D> The triple sends two streams by some policy > 3 =3D> The triple sends three cameras in spatial order, and > the receiver decide how to render across two screens >=20 > 2) Which switching policy > Static =3D> The requester ask for explicit camera streams, e.g. cam1 = or > (cam2+cam3) > Switched/Composed =3D> The triple chooses the streams to send, e.g. = the > two loudest segments or it could make a nice rendering of 3x cameras > rendered on two streams. >=20 > I assume that you won't use different switching policies for the > different streams, since it gives the sender of media the chance to > optimize what it send on the streams requested. >=20 > The 'site' switching policy makes most sense from an MCU. I interprete > the policy as try the best you can to switch in all capture streams > from a room when the room is active. Example Room A has two cameras > Room B has three cameras Room C has a single camera Room D has three > screens >=20 > 1) Room D receives media from room A and C > 2) Room B starts talking > 3a) with site switching > Room D receives media only from D across all three screens > 3b) with segment switching > Room D receives media from A, and the new active segment from D >=20 > Cheers >=20 > -Espen >=20 >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Paul Kyzivat > Sent: 1. februar 2012 18:29 > To: clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data > structure >=20 > Espen, >=20 > ISTM that for a switched stream you have: > - the set of candidate streams to be switched among > - an algorithm for picking among them >=20 > If the receiver has multiple screens, then there will be a stream for > each one, and each could have different candidate input streams and a > different policy. >=20 > What you are describing as "site switching" adds another wrinkle, = since > it is coupling the switching policies for multiple streams. Also, I'm > not sure how it works if the sites have differing numbers of screens > and cameras. How would you describe the individual streams from the = MCU > so that a room could select an appropriate set of streams to get site > switching? >=20 > It would be helpful (to me anyway) if you could describe the > interesting cases by enumerating the offered streams together with the > inputs and the algorithm used for each. Right now, I'm not sure how to > do that. >=20 > Thanks, > Paul >=20 > On 2/1/12 8:00 AM, Espen Berger (espeberg) wrote: > > I would still call it switch-policy, e.g. then possible values could > be: > > * Site: Change all at the same time > > * Segment: Only change the active segment > > * Round robin: Change active segment and then change to other > segments in 10 sec intervals. > > > > How you switch between streams and how you render has different > requirements and policies, so I find it very useful to discuss them as > two separate issues to avoid confusion. > > > > Cheers > > > > -Espen > > > > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: 1. februar 2012 11:30 > > To: Espen Berger (espeberg); clue@ietf.org > > Subject: RE: [clue] #7: Is composed attribute a boolean or data > > structure > > > > Hi Espen, > > I called site or segment switch a policy but I am not sure that it = is > a switch policy by itself since segment switch for example can happen > based on active speakers or some round robin timing which is the > switching policy. > > Roni > > > >> -----Original Message----- > >> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > >> Sent: Tuesday, January 31, 2012 5:38 PM > >> To: Roni Even; clue@ietf.org > >> Subject: RE: [clue] #7: Is composed attribute a boolean or data > >> structure > >> > >> Hi Rony > >> > >> To choose between site and segment switch is more a policy than a > >> , so in that case I would argue that you could offer = a > >> Capture stream with a switch-policy =3D {site, segment} > >> > >> My point about interoperability is that a single composed stream > with > >> alternative layouts are easier to understand, than multiple capture > >> streams with alternative configurations. The last requires to pick > >> the first one or requires some sort of default marking. > >> > >> Cheers > >> > >> -Espen > >> > >> > >> -----Original Message----- > >> From: Roni Even [mailto:ron.even.tlv@gmail.com] > >> Sent: 31. januar 2012 00:06 > >> To: Espen Berger (espeberg); clue@ietf.org > >> Subject: RE: [clue] #7: Is composed attribute a boolean or data > >> structure > >> > >> Hi Espen, > >> If the provider wants to offer site switch and segment switch = option > >> to the consumer he cannot do it just with A. this is a basic use > case. > >> > >> In general, your option does not provide any interoperability since > >> both sides may have different views what composed means. In the > >> framework example of a PIP as composed image it is an assumption > that > >> if the provider offers this composed offer, the consumer can > >> understand that it is a PIP mix but there is nothing in the offer > >> that will indicate that it is. > >> > >> Roni > >> > >>> -----Original Message----- > >>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > >>> Sent: Monday, January 30, 2012 5:21 PM > >>> To: Roni Even; clue@ietf.org > >>> Subject: RE: [clue] #7: Is composed attribute a boolean or data > >>> structure > >>> > >>> Hi Roni > >>> > >>> If you=E2=80=99re a particular use cases requires control over the = composed > >>> layouts you need a) and b). In my example I used a single > >>> advertisement composed stream with optional meta-information about > >>> possible layout choices. A receiver that wants the default = composed > >>> layout can request the composed stream and skip the optional = video- > >> layout information. > >>> Optionally you could request the same composed stream with layouts > >>> hints for the receiver. > >>> > >>> For me use case c) does not include the selection mechanisms, only > >> the > >>> content you see in the video stream. > >>> > >>> Cheers > >>> > >>> -Espen > >>> > >>> -----Original Message----- > >>> From: Roni Even [mailto:ron.even.tlv@gmail.com] > >>> Sent: 30. januar 2012 15:39 > >>> To: Espen Berger (espeberg); clue@ietf.org > >>> Subject: RE: [clue] #7: Is composed attribute a boolean or data > >>> structure > >>> > >>> Hi Espen, > >>> If you will look at the notes from the last call there was a > support > >>> that a) is not enough. Having just compose does not address even > the > >>> use cases I provided which are also based on the use case draft. > >>> > >>> > >>> I am not sure what you mean by C since what in the composed stream > >> can > >>> be either which VC you see or what is the selection criteria for > >> being > >>> in a composed stream. If you meant the second, my view is that C > and > >>> also b should be in the basic framework and not in an extension. > >>> > >>> Roni Even > >>> > >>>> -----Original Message----- > >>>> From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] > >>>> Sent: Monday, January 30, 2012 4:17 PM > >>>> To: Roni Even; clue@ietf.org > >>>> Subject: RE: [clue] #7: Is composed attribute a boolean or data > >>>> structure > >>>> > >>>> > >>>> To help with the direction of the discussions I think it's useful > >> to > >>>> divide the discussions into three use cases for composed streams. > >>>> a) How to express if a capture stream is composed or not > >>>> b) How to express layout choices? (e.g. with a video-layout > >>>> element) > >>>> c) How to express what's inside a composed stream > >>>> > >>>> For use case a) a composed attribute should be sufficient, you > >>>> either ask for the composed stream or you do not. > >>>> I also believe this should cover the interoperability requirement > >> we > >>>> have across multiple types of endpoints. > >>>> > >>>> For use case b) both mediactrl and xcon uses a > >>>> element to describe possible layouts and also to request the > >>>> preferred layout based on options. (as described in Roni's email) > >>>> > >>>> An example could be (inspired by mediactrl and xcon usage of > >> >>>> layout>): > >>>> > >>>> CLUE Advertisement > >>>> Capture id=3D2 Purpose=3Dpeople Composed=3Dfalse > >>>> Capture id=3D3 Purpose=3Dpeople Composed=3Dfalse > >>>> Capture id=3D4 Purpose=3DPeople Composed=3Dtrue > >>>> Video-layout=3D"'automatic', 'dual-view', ' single-view'" > >>>> > >>>> CLUE configure // Default composed stream > >>>> Capture id=3D4 > >>>> > >>>> // Or composed stream with layout hints > >>>> Capture id=3D4 Video-layout=3D'dual-view' > >>>> > >>>> The video-layout element is a list of strings and each string is = a > >>>> layout-hint that can be requested. Video-layout is optional. A > >>>> layout hints about the requested rendering and the source is free > >> to > >>>> replace any stream as long as they fit the layout. > >>>> > >>>> Use case c) is more open in the sense that what you actually > >> receive > >>>> in a composed stream is depending on status of a room or who is = in > >> a > >>>> MCU conference. E.g. from a room you could get a mix of different > >>>> capture stream representing cameras and from a transcoding MCU it > >>>> could be different room, different cameras or another mix of > >>>> possible input video streams. > >>>> > >>>> Having support for both b) and c) could be a good test for the > >>>> extensibility of CLUE. If the basis of CLUE only does use case a) > >>>> there should be room to extend CLUE with support for b) and c) as > a > >>>> CLUE + layout description extension. > >>>> > >>>> Cheers > >>>> > >>>> -Espen > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> Behalf > >>>> Of Roni Even > >>>> Sent: 30. januar 2012 11:18 > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] #7: Is composed attribute a boolean or data > >>>> structure > >>>> > >>>> Hi, > >>>> During the last call I volunteered to provide some input. > >>>> > >>>> In current IETF work (XCON, Mediactrl WGs there is a video layout > >>>> element) > >>>> > >>>> http://tools.ietf.org/html/draft-ietf-mediactrl-mixer-control- > >>> package- > >>>> 14#section-4.2.1.4.2.1 > >>>> > >>>> and > >>>> http://tools.ietf.org/html/draft-ietf-xcon-common-data-model- > >>>> 32#section-4.2.7 (look at video-layout) > >>>> > >>>> I would like first to try to define the term "composed video" > since > >>> it > >>>> looks to me like we have different views here, and provide my > >>>> initial view on what should be described. > >>>> > >>>> Composed video can describes both the layout and the selection > >>>> algorithm for composing the content of the sub-windows in the > >>> "mixed" > >>>> video. > >>>> > >>>> The video layout which just describes the geometry of the = composed > >>>> image and I think that the above references provide good = structure > >>>> to define this part of the composed video attribute. > >>>> > >>>> The other part is the algorithm by which the provider select the > >>>> content of each element in the layout. Since the content of each > >>>> element may change dynamically by the provider this attribute = only > >>>> address the static information which is the algorithm and not the > >>>> current content (who we see now in each element) which will need > to > >>> be > >>>> conveyed also but probably not using this attribute. Note that = the > >>>> information is valid for point to point and multipoint so the > >>>> current content should reflect the TP end point and the specific > VC > >>>> used from it. > >>>> > >>>> The algorithms may be global or per element(or sub-window). The > >>> global > >>>> algorithms I see are site switch or segment switch. The per > element > >>>> may be voice activated, round robin (switch every x seconds) and > >>> fixed > >>>> (the same VC is displayed there (may be changed by some control > >>>> mechanism) > >>>> > >>>> > >>>> Roni > >>>> > >>>>> -----Original Message----- > >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>> Behalf > >>>>> Of clue issue tracker > >>>>> Sent: Tuesday, January 24, 2012 12:43 AM > >>>>> To: draft-ietf-clue-framework@tools.ietf.org; > >>>>> mary.ietf.barnes@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@=E2=80=A6): > >>>>> > >>>>> * type: defect =3D> task > >>>>> > >>>>> > >>>>> -- > >>>>> = --------------------------------+-------------------------------- > >> - > >>>>> --------------------------------+- > >>> - > >>>>> --------------------------------+- > >>>> - > >>>>> --------------------------------+- > >>>>> ---- > >>>>> Reporter: mary.ietf.barnes@=E2=80=A6 | Owner: = draft-ietf-clue- > >>>>> framework@=E2=80=A6 > >>>>> Type: task | Status: new > >>>>> Priority: major | Milestone: > >>>>> Component: framework | Version: > >>>>> Severity: Active WG Document | Resolution: > >>>>> Keywords: | > >>>>> = --------------------------------+-------------------------------- > >> - > >>>>> --------------------------------+- > >>> - > >>>>> --------------------------------+- > >>>> - > >>>>> --------------------------------+- > >>>>> ---- > >>>>> > >>>>> Ticket URL: > >>>>> > >>>>> 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 >=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 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Feb 8 10:14: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 9A44D21F86C9 for ; Wed, 8 Feb 2012 10:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, 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 9J6neMs4Ux2F for ; Wed, 8 Feb 2012 10:14:20 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 21C8721F86B9 for ; Wed, 8 Feb 2012 10:14:19 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 8 Feb 2012 10:14:19 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Wed, 8 Feb 2012 10:14:17 -0800 Thread-Topic: [clue] #7: Is composed attribute a boolean or data structure Thread-Index: AczhBxgZzsQM+HraTUCVftAm4h2iFAAvm5hgASwpd2AAAwipoAACU9dw Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB202E57@CRPMBOXPRD01.polycom.com> References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org><4f266f4c.d0770e0a.43c6.37fd@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com><4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com><4f272344.03bd0e0a.6983.3d7e@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com><4f291525.84310e0a.69d7.fffffd3b@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com> <4F29766F.1080101@alum.mit.edu> <92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB202D20@CRPMBOXPRD01.polycom.com> <4f32a9a9.c9840e0a.492a.ffffd4d9@mx.google.com> In-Reply-To: <4f32a9a9.c9840e0a.492a.ffffd4d9@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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, 08 Feb 2012 18:14:21 -0000 SGkgUm9uaSwNClllcywgSSBhZ3JlZS4gIFRoYXQgaXMgd2hhdCBJIG1lYW50IGJ5IHRoZSBzdGF0 ZW1lbnQgIlZDMyB0aHJvdWdoIFZDOCBjb3VsZCBhbHNvIGhhdmUgYWRkaXRpb25hbCBhdHRyaWJ1 dGVzIGRlc2NyaWJpbmcgdGhlIGF2YWlsYWJsZSB2aWRlbyBsYXlvdXQgY2hvaWNlcyBmb3IgY29t cG9zaXRpb24gb3IgdGhlIGF2YWlsYWJsZSBzd2l0Y2hpbmcgcG9saWNpZXMgdGhlIHByb3ZpZGVy IGlzIG9mZmVyaW5nLiAgVGhlIGNvbnN1bWVyIGNvdWxkIGNob29zZSBhbW9uZyB0aGVzZS4iDQoN Ck1hcmsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvbmkgRXZlbiBbbWFp bHRvOnJvbi5ldmVuLnRsdkBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA4 LCAyMDEyIDExOjU4IEFNDQpUbzogRHVja3dvcnRoLCBNYXJrOyBjbHVlQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRh dGEgc3RydWN0dXJlDQoNCkhpIE1hcmssDQpJIGNhbiBhZGQgdHdvIG1vcmUgb3B0aW9ucy4NCg0K MS4gVHdvIG91dCBvZiB0aHJlZSB3aGljaCB3aWxsIGluY2x1ZGUgdGhlIGN1cnJlbnQgYW5kIHBy ZXZpb3VzIHNwZWFrZXIgMi4gVHdvIG91dCBvZiB0aHJlZSB3aGljaCB3aWxsIHJvdGF0ZSBiZXR3 ZWVuIHRoZSB0aHJlZSBldmVyeSAxMCBzZWNvbmRzIFRoZXNlIHR3byBjYW5ub3QgYmUgZGlmZmVy ZW50aWF0ZWQgd2l0aCBiaW5hcnkgY29tcG9zZWQgYW5kIHN3aXRjaGVkLg0KDQpJZiB3ZSBnbyBm cm9tIHRocmVlIHRvIG9uZSB3ZSBoYXZlIGV2ZW4gbW9yZSBvcHRpb25zIHRoYXQgY2Fubm90IGJl IGRpZmZlcmVudGlhdGVkIGJ5IGJpbmFyeSB2YWx1ZXMgYW5kIEkgdGhpbmsgdGhhdCB0aHJlZSB0 byBvbmUgd2lsbCBiZSBtb3JlIGNvbW1vbi4NCg0KUm9uaQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIER1Y2t3b3J0aCwgTWFyaw0KPiBTZW50OiBX ZWRuZXNkYXksIEZlYnJ1YXJ5IDA4LCAyMDEyIDU6NTQgUE0NCj4gVG86IGNsdWVAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVh biBvciBkYXRhDQo+IHN0cnVjdHVyZQ0KPg0KPiBJJ2xsIGFkZCBteSB0aG91Z2h0cyB0byB0aGlz LCBmb3IgaG93IEkgc2VlIHRoaXMgc2NlbmFyaW8gd29ya2luZyAoM3gNCj4gY2FtZXJhIHN5c3Rl bSBzZW5kaW5nIHRvIGEgMnggc2NyZWVuIHN5c3RlbSksIHVzaW5nIEVzcGVuJ3MgaWRlYXMgZm9y DQo+IHdoYXQgdGhlIGFsdGVybmF0aXZlcyBhcmUgZm9yIHRoaXMgcGFydGljdWxhciBleGFtcGxl LCBnaXZlbiB0aGlzDQo+IHBhcnRpY3VsYXIgaHlwb3RoZXRpY2FsIDMgc2NyZWVuIHByb3ZpZGVy J3MgY2FwYWJpbGl0aWVzLg0KPg0KPiBQcm92aWRlciBhZHZlcnRpc2VzIHRoZXNlIDkgdmlkZW8g Y2FwdHVyZXM6DQo+IFZDMCAobGVmdCkgbm90IGNvbXBvc2VkOyBub3Qgc3dpdGNoZWQNCj4gVkMx IChtaWRkbGUpIG5vdCBjb21wb3NlZDsgbm90IHN3aXRjaGVkDQo+IFZDMiAocmlnaHQpIG5vdCBj b21wb3NlZDsgbm90IHN3aXRjaGVkDQo+IFZDMyAobGVmdCBoYWxmIG9mIHR3byBzY3JlZW4gY29t cG9zaXRpb24pIGNvbXBvc2VkOyBub3Qgc3dpdGNoZWQNCj4gVkM0IChyaWdodCBoYWxmIG9mIHR3 byBzY3JlZW4gY29tcG9zaXRpb24pIGNvbXBvc2VkOyBub3Qgc3dpdGNoZWQNCj4gVkM1IChsZWZ0 IGhhbGYgb2YgdHdvIHNjcmVlbiBzd2l0Y2hlZCkgbm90IGNvbXBvc2VkOyBzd2l0Y2hlZA0KPiBW QzYgKHJpZ2h0IGhhbGYgb2YgdHdvIHNjcmVlbiBzd2l0Y2hlZCkgbm90IGNvbXBvc2VkOyBzd2l0 Y2hlZA0KPiBWQzcgKHNpbmdsZSBzdHJlYW0gY29tcG9zaXRpb24pIGNvbXBvc2VkLCBub3Qgc3dp dGNoZWQNCj4gVkM4IChzaW5nbGUgc3RyZWFtIHN3aXRjaGVkKSBub3QgY29tcG9zZWQsIHN3aXRj aGVkDQo+DQo+IFZDMyB0aHJvdWdoIFZDOCBjb3VsZCBhbHNvIGhhdmUgYWRkaXRpb25hbCBhdHRy aWJ1dGVzIGRlc2NyaWJpbmcgdGhlDQo+IGF2YWlsYWJsZSB2aWRlbyBsYXlvdXQgY2hvaWNlcyBm b3IgY29tcG9zaXRpb24gb3IgdGhlIGF2YWlsYWJsZQ0KPiBzd2l0Y2hpbmcgcG9saWNpZXMgdGhl IHByb3ZpZGVyIGlzIG9mZmVyaW5nLiAgVGhlIGNvbnN1bWVyIGNvdWxkDQo+IGNob29zZSBhbW9u ZyB0aGVzZS4gIEkgdGhpbmsgdGhhdCBpcyB0aGUgcG9pbnQgUm9uaSBoYXMgYmVlbiBtYWtpbmcu DQo+IERldGFpbHMgb2YgdGhpcyBuZWVkIGZ1cnRoZXIgZGlzY3Vzc2lvbi4gIChNYXliZSB0aGUg Y29tcG9zZWQgYW5kDQo+IHN3aXRjaGVkIGNob2ljZXMgc2hvdWxkIGJlIGNvbGxhcHNlZCBpbnRv IG9uZSBzZXQgb2Ygc3R1ZmYgdG8gY2hvb3NlDQo+IGZyb20gZm9yIGEgcGFydGljdWxhciBWQywg cmF0aGVyIHRoYW4gc2VwYXJhdGUgVkNzLCBzbyB0aGF0IHdvdWxkDQo+IHJlZHVjZSB0aGUgbnVt YmVyIG9mIFZDcyBoZXJlIGZyb20gOSB0byA2ID8pLg0KPg0KPiBQcm92aWRlciBhZHZlcnRpc2Vz IGEgY2FwdHVyZSBzZXQgd2l0aCA1IGVudHJpZXM6DQo+IEVudHJ5IDEgKFZDMCwgVkMxLCBWQzIp DQo+IEVudHJ5IDIgKFZDMywgVkM0KQ0KPiBFbnRyeSAzIChWQzUsIFZDNikNCj4gRW50cnkgNCAo VkM3KQ0KPiBFbnRyeSA1IChWQzgpDQo+DQo+IEJ5IGFkdmVydGlzaW5nIHRoZSBjYXB0dXJlIHNl dCBpbiB0aGlzIHdheSwgdGhlIHByb3ZpZGVyIGlzIHN1Z2dlc3RpbmcNCj4gd2hpY2ggdmlkZW8g Y2FwdHVyZXMgYXJlIG1vc3QgdXNlZnVsIHRvIHJlY2VpdmUgdG9nZXRoZXIsIHRvIGdldCBhDQo+ IHZpZXcgb2YgdGhlIHdob2xlIHNjZW5lLiAgRWFjaCBlbnRyeSBpbiB0aGUgY2FwdHVyZSBzZXQg aXMgYSBzdWdnZXN0ZWQNCj4gYWx0ZXJuYXRpdmUuDQo+DQo+IEEgMiBzY3JlZW4gY29uc3VtZXIg Y2FuIGNob29zZSBWQzMgYW5kIFZDNCBpZiBpdCB3YW50cyBhIGNvbXBvc2l0aW9uLg0KPiBJdCBj YW4gY2hvb3NlIFZDNSBhbmQgVkM2IGlmIGl0IHdhbnRzIGEgZHluYW1pY2FsbHkgc3dpdGNoZWQg dmlldy4gIEENCj4gMiBzY3JlZW4gY29uc3VtZXIgaXMgYWxzbyBmcmVlIHRvIGlnbm9yZSB0aGUg c3VnZ2VzdGlvbnMgaW4gdGhlDQo+IGNhcHR1cmUgc2V0IGFuZCBpbnN0ZWFkIGNob29zZSBWQzAg YW5kIFZDMSBpZiB0aGF0IGlzIHdoYXQgaXQgd2FudHMuDQo+IEl0IGNvdWxkIGFsc28gY2hvb3Nl IG90aGVyIGNvbWJpbmF0aW9ucyBmcm9tIGRpZmZlcmVudCBlbnRyaWVzLCBzYXkNCj4gVkMxIGFu ZCBWQzgsIGFzc3VtaW5nIHRoZSBwcm92aWRlcidzIGFkdmVydGlzZWQgc2ltdWx0YW5lb3VzIHNl dHMgYW5kDQo+IGVuY29kaW5nIGdyb3VwcyBkbyBub3QgcHJvaGliaXQgdGhhdCBjb21iaW5hdGlv bi4NCj4NCj4gTWFyaw0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBj bHVlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZg0KPiBPZiBFc3BlbiBCZXJnZXIgKGVzcGViZXJnKQ0KPiBTZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgMDIsIDIwMTIgMTE6NDIgQU0NCj4gVG86IFBhdWwgS3l6aXZhdDsgY2x1ZUBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29s ZWFuIG9yIGRhdGENCj4gc3RydWN0dXJlDQo+DQo+IEhpIFBhdWwNCj4NCj4gSSB3aWxsIG1ha2Ug YSBicmllZiBhdHRlbXB0IHRvIGFuc3dlci4NCj4NCj4gVGhlIHNjZW5hcmlvcyBhcmUgaG93IHRv IG1hcCBhIDN4IGNhbWVyYSBzeXN0ZW0gdG8gYSAyeCBzY3JlZW4gc3lzdGVtLg0KPiBUaGUgdHJp cGxlIG9mZmVyICBTdHJlbWEgPSAxIC0gMyAgUG9saWNpZXMgPSBTd2l0Y2hlZCwgc3RhdGljLA0K PiBjb21wb3NlZA0KPg0KPiBBcyBhIHJlY2VpdmVyICh3aXRoIDJ4IHNjcmVlbnMpIEkgd291bGQg ZG8gdGhpcyBjaG9pY2VzDQo+DQo+IDEpIEhvdyBtYW55IHN0cmVhbXMgdG8gcmVjZWl2ZQ0KPiAg ICAxID0+IFRoZSB0cmlwbGUgc2VuZHMgYSBzaW5nbGUgc3RyZWFtIGJ5IHNvbWUgc2VuZGVyIHBy ZWZlcnJlZA0KPiBwb2xpY3kNCj4gICAgMiA9PiBUaGUgdHJpcGxlIHNlbmRzIHR3byBzdHJlYW1z IGJ5IHNvbWUgcG9saWN5DQo+ICAgIDMgPT4gVGhlIHRyaXBsZSBzZW5kcyB0aHJlZSBjYW1lcmFz IGluIHNwYXRpYWwgb3JkZXIsIGFuZA0KPiAgICAgICB0aGUgcmVjZWl2ZXIgZGVjaWRlIGhvdyB0 byByZW5kZXIgYWNyb3NzIHR3byBzY3JlZW5zDQo+DQo+IDIpIFdoaWNoIHN3aXRjaGluZyBwb2xp Y3kNCj4gICBTdGF0aWMgPT4gVGhlIHJlcXVlc3RlciBhc2sgZm9yIGV4cGxpY2l0IGNhbWVyYSBz dHJlYW1zLCBlLmcuIGNhbTENCj4gb3INCj4gKGNhbTIrY2FtMykNCj4gICBTd2l0Y2hlZC9Db21w b3NlZCA9PiBUaGUgdHJpcGxlIGNob29zZXMgdGhlIHN0cmVhbXMgdG8gc2VuZCwgZS5nLg0KPiB0 aGUgdHdvIGxvdWRlc3Qgc2VnbWVudHMgb3IgaXQgY291bGQgbWFrZSBhIG5pY2UgcmVuZGVyaW5n IG9mIDN4DQo+IGNhbWVyYXMgcmVuZGVyZWQgb24gdHdvIHN0cmVhbXMuDQo+DQo+IEkgYXNzdW1l IHRoYXQgeW91IHdvbid0IHVzZSBkaWZmZXJlbnQgc3dpdGNoaW5nIHBvbGljaWVzIGZvciB0aGUN Cj4gZGlmZmVyZW50IHN0cmVhbXMsIHNpbmNlIGl0IGdpdmVzIHRoZSBzZW5kZXIgb2YgbWVkaWEg dGhlIGNoYW5jZSB0bw0KPiBvcHRpbWl6ZSB3aGF0IGl0IHNlbmQgb24gdGhlIHN0cmVhbXMgcmVx dWVzdGVkLg0KPg0KPiBUaGUgJ3NpdGUnIHN3aXRjaGluZyBwb2xpY3kgbWFrZXMgbW9zdCBzZW5z ZSBmcm9tIGFuIE1DVS4gSSBpbnRlcnByZXRlDQo+IHRoZSBwb2xpY3kgYXMgdHJ5IHRoZSBiZXN0 IHlvdSBjYW4gdG8gc3dpdGNoIGluIGFsbCBjYXB0dXJlIHN0cmVhbXMNCj4gZnJvbSBhIHJvb20g d2hlbiB0aGUgcm9vbSBpcyBhY3RpdmUuIEV4YW1wbGUgIFJvb20gQSBoYXMgdHdvIGNhbWVyYXMN Cj4gUm9vbSBCIGhhcyB0aHJlZSBjYW1lcmFzICBSb29tIEMgaGFzIGEgc2luZ2xlIGNhbWVyYSAg Um9vbSBEIGhhcyB0aHJlZQ0KPiBzY3JlZW5zDQo+DQo+IDEpIFJvb20gRCByZWNlaXZlcyBtZWRp YSBmcm9tIHJvb20gQSBhbmQgQw0KPiAyKSBSb29tIEIgc3RhcnRzIHRhbGtpbmcNCj4gM2EpIHdp dGggc2l0ZSBzd2l0Y2hpbmcNCj4gICBSb29tIEQgcmVjZWl2ZXMgbWVkaWEgb25seSBmcm9tIEQg YWNyb3NzIGFsbCB0aHJlZSBzY3JlZW5zDQo+IDNiKSB3aXRoIHNlZ21lbnQgc3dpdGNoaW5nDQo+ ICAgUm9vbSBEIHJlY2VpdmVzIG1lZGlhIGZyb20gQSwgYW5kIHRoZSBuZXcgYWN0aXZlIHNlZ21l bnQgZnJvbSBEDQo+DQo+IENoZWVycw0KPg0KPiAtRXNwZW4NCj4NCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2x1 ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgUGF1bCBLeXppdmF0DQo+IFNlbnQ6 IDEuIGZlYnJ1YXIgMjAxMiAxODoyOQ0KPiBUbzogY2x1ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4g c3RydWN0dXJlDQo+DQo+IEVzcGVuLA0KPg0KPiBJU1RNIHRoYXQgZm9yIGEgc3dpdGNoZWQgc3Ry ZWFtIHlvdSBoYXZlOg0KPiAtIHRoZSBzZXQgb2YgY2FuZGlkYXRlIHN0cmVhbXMgdG8gYmUgc3dp dGNoZWQgYW1vbmcNCj4gLSBhbiBhbGdvcml0aG0gZm9yIHBpY2tpbmcgYW1vbmcgdGhlbQ0KPg0K PiBJZiB0aGUgcmVjZWl2ZXIgaGFzIG11bHRpcGxlIHNjcmVlbnMsIHRoZW4gdGhlcmUgd2lsbCBi ZSBhIHN0cmVhbSBmb3INCj4gZWFjaCBvbmUsIGFuZCBlYWNoIGNvdWxkIGhhdmUgZGlmZmVyZW50 IGNhbmRpZGF0ZSBpbnB1dCBzdHJlYW1zIGFuZCBhDQo+IGRpZmZlcmVudCBwb2xpY3kuDQo+DQo+ IFdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGFzICJzaXRlIHN3aXRjaGluZyIgYWRkcyBhbm90aGVy IHdyaW5rbGUsDQo+IHNpbmNlIGl0IGlzIGNvdXBsaW5nIHRoZSBzd2l0Y2hpbmcgcG9saWNpZXMg Zm9yIG11bHRpcGxlIHN0cmVhbXMuDQo+IEFsc28sIEknbSBub3Qgc3VyZSBob3cgaXQgd29ya3Mg aWYgdGhlIHNpdGVzIGhhdmUgZGlmZmVyaW5nIG51bWJlcnMgb2YNCj4gc2NyZWVucyBhbmQgY2Ft ZXJhcy4gSG93IHdvdWxkIHlvdSBkZXNjcmliZSB0aGUgaW5kaXZpZHVhbCBzdHJlYW1zDQo+IGZy b20gdGhlIE1DVSBzbyB0aGF0IGEgcm9vbSBjb3VsZCBzZWxlY3QgYW4gYXBwcm9wcmlhdGUgc2V0 IG9mIHN0cmVhbXMNCj4gdG8gZ2V0IHNpdGUgc3dpdGNoaW5nPw0KPg0KPiBJdCB3b3VsZCBiZSBo ZWxwZnVsICh0byBtZSBhbnl3YXkpIGlmIHlvdSBjb3VsZCBkZXNjcmliZSB0aGUNCj4gaW50ZXJl c3RpbmcgY2FzZXMgYnkgZW51bWVyYXRpbmcgdGhlIG9mZmVyZWQgc3RyZWFtcyB0b2dldGhlciB3 aXRoIHRoZQ0KPiBpbnB1dHMgYW5kIHRoZSBhbGdvcml0aG0gdXNlZCBmb3IgZWFjaC4gUmlnaHQg bm93LCBJJ20gbm90IHN1cmUgaG93IHRvDQo+IGRvIHRoYXQuDQo+DQo+ICAgICAgICAgVGhhbmtz LA0KPiAgICAgICAgIFBhdWwNCj4NCj4gT24gMi8xLzEyIDg6MDAgQU0sIEVzcGVuIEJlcmdlciAo ZXNwZWJlcmcpIHdyb3RlOg0KPiA+IEkgd291bGQgc3RpbGwgY2FsbCBpdCBzd2l0Y2gtcG9saWN5 LCBlLmcuIHRoZW4gcG9zc2libGUgdmFsdWVzIGNvdWxkDQo+IGJlOg0KPiA+ICogU2l0ZTogQ2hh bmdlIGFsbCBhdCB0aGUgc2FtZSB0aW1lDQo+ID4gKiBTZWdtZW50OiBPbmx5IGNoYW5nZSB0aGUg YWN0aXZlIHNlZ21lbnQNCj4gPiAqIFJvdW5kIHJvYmluOiBDaGFuZ2UgYWN0aXZlIHNlZ21lbnQg YW5kIHRoZW4gY2hhbmdlIHRvIG90aGVyDQo+IHNlZ21lbnRzIGluIDEwIHNlYyBpbnRlcnZhbHMu DQo+ID4NCj4gPiBIb3cgeW91IHN3aXRjaCBiZXR3ZWVuIHN0cmVhbXMgYW5kIGhvdyB5b3UgcmVu ZGVyIGhhcyBkaWZmZXJlbnQNCj4gcmVxdWlyZW1lbnRzIGFuZCBwb2xpY2llcywgc28gSSBmaW5k IGl0IHZlcnkgdXNlZnVsIHRvIGRpc2N1c3MgdGhlbSBhcw0KPiB0d28gc2VwYXJhdGUgaXNzdWVz IHRvIGF2b2lkIGNvbmZ1c2lvbi4NCj4gPg0KPiA+IENoZWVycw0KPiA+DQo+ID4gLUVzcGVuDQo+ ID4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogUm9uaSBF dmVuIFttYWlsdG86cm9uLmV2ZW4udGx2QGdtYWlsLmNvbV0NCj4gPiBTZW50OiAxLiBmZWJydWFy IDIwMTIgMTE6MzANCj4gPiBUbzogRXNwZW4gQmVyZ2VyIChlc3BlYmVyZyk7IGNsdWVAaWV0Zi5v cmcNCj4gPiBTdWJqZWN0OiBSRTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBi b29sZWFuIG9yIGRhdGENCj4gPiBzdHJ1Y3R1cmUNCj4gPg0KPiA+IEhpIEVzcGVuLA0KPiA+IEkg Y2FsbGVkIHNpdGUgb3Igc2VnbWVudCBzd2l0Y2ggYSBwb2xpY3kgYnV0IEkgYW0gbm90IHN1cmUg dGhhdCBpdA0KPiA+IGlzDQo+IGEgc3dpdGNoIHBvbGljeSBieSBpdHNlbGYgc2luY2Ugc2VnbWVu dCBzd2l0Y2ggZm9yIGV4YW1wbGUgY2FuIGhhcHBlbg0KPiBiYXNlZCBvbiBhY3RpdmUgc3BlYWtl cnMgb3Igc29tZSByb3VuZCByb2JpbiB0aW1pbmcgd2hpY2ggaXMgdGhlDQo+IHN3aXRjaGluZyBw b2xpY3kuDQo+ID4gUm9uaQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+IEZyb206IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpIFttYWlsdG86ZXNwZWJlcmdAY2lzY28u Y29tXQ0KPiA+PiBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDMxLCAyMDEyIDU6MzggUE0NCj4gPj4g VG86IFJvbmkgRXZlbjsgY2x1ZUBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSRTogW2NsdWVdICM3 OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4gPj4gc3RydWN0dXJl DQo+ID4+DQo+ID4+IEhpIFJvbnkNCj4gPj4NCj4gPj4gVG8gY2hvb3NlIGJldHdlZW4gc2l0ZSBh bmQgc2VnbWVudCBzd2l0Y2ggaXMgbW9yZSBhIHBvbGljeSB0aGFuIGENCj4gPj4gPHZpZGVvLWxh eW91dD4sIHNvIGluIHRoYXQgY2FzZSBJIHdvdWxkIGFyZ3VlIHRoYXQgeW91IGNvdWxkIG9mZmVy DQo+ID4+IGEgQ2FwdHVyZSBzdHJlYW0gd2l0aCBhIHN3aXRjaC1wb2xpY3kgPSB7c2l0ZSwgc2Vn bWVudH0NCj4gPj4NCj4gPj4gTXkgcG9pbnQgYWJvdXQgaW50ZXJvcGVyYWJpbGl0eSBpcyB0aGF0 IGEgc2luZ2xlIGNvbXBvc2VkIHN0cmVhbQ0KPiB3aXRoDQo+ID4+IGFsdGVybmF0aXZlIGxheW91 dHMgYXJlIGVhc2llciB0byB1bmRlcnN0YW5kLCB0aGFuIG11bHRpcGxlIGNhcHR1cmUNCj4gPj4g c3RyZWFtcyB3aXRoIGFsdGVybmF0aXZlIGNvbmZpZ3VyYXRpb25zLiBUaGUgbGFzdCByZXF1aXJl cyB0byBwaWNrDQo+ID4+IHRoZSBmaXJzdCBvbmUgb3IgcmVxdWlyZXMgc29tZSBzb3J0IG9mIGRl ZmF1bHQgbWFya2luZy4NCj4gPj4NCj4gPj4gQ2hlZXJzDQo+ID4+DQo+ID4+IC1Fc3Blbg0KPiA+ Pg0KPiA+Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBSb25p IEV2ZW4gW21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXQ0KPiA+PiBTZW50OiAzMS4gamFu dWFyIDIwMTIgMDA6MDYNCj4gPj4gVG86IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpOyBjbHVlQGll dGYub3JnDQo+ID4+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0 ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPiA+PiBzdHJ1Y3R1cmUNCj4gPj4NCj4gPj4gSGkgRXNwZW4s DQo+ID4+IElmIHRoZSBwcm92aWRlciB3YW50cyB0byBvZmZlciBzaXRlIHN3aXRjaCBhbmQgc2Vn bWVudCBzd2l0Y2gNCj4gPj4gb3B0aW9uIHRvIHRoZSBjb25zdW1lciBoZSBjYW5ub3QgZG8gaXQg anVzdCB3aXRoIEEuIHRoaXMgaXMgYSBiYXNpYw0KPiA+PiB1c2UNCj4gY2FzZS4NCj4gPj4NCj4g Pj4gSW4gZ2VuZXJhbCwgeW91ciBvcHRpb24gZG9lcyBub3QgcHJvdmlkZSBhbnkgaW50ZXJvcGVy YWJpbGl0eSBzaW5jZQ0KPiA+PiBib3RoIHNpZGVzIG1heSBoYXZlIGRpZmZlcmVudCB2aWV3cyB3 aGF0IGNvbXBvc2VkIG1lYW5zLiBJbiB0aGUNCj4gPj4gZnJhbWV3b3JrIGV4YW1wbGUgb2YgYSBQ SVAgYXMgY29tcG9zZWQgaW1hZ2UgaXQgaXMgYW4gYXNzdW1wdGlvbg0KPiB0aGF0DQo+ID4+IGlm IHRoZSBwcm92aWRlciBvZmZlcnMgdGhpcyBjb21wb3NlZCBvZmZlciwgdGhlIGNvbnN1bWVyIGNh bg0KPiA+PiB1bmRlcnN0YW5kIHRoYXQgaXQgaXMgYSBQSVAgbWl4IGJ1dCB0aGVyZSBpcyBub3Ro aW5nIGluIHRoZSBvZmZlcg0KPiA+PiB0aGF0IHdpbGwgaW5kaWNhdGUgdGhhdCBpdCBpcy4NCj4g Pj4NCj4gPj4gUm9uaQ0KPiA+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g Pj4+IEZyb206IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpIFttYWlsdG86ZXNwZWJlcmdAY2lzY28u Y29tXQ0KPiA+Pj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDMwLCAyMDEyIDU6MjEgUE0NCj4gPj4+ IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0Zi5vcmcNCj4gPj4+IFN1YmplY3Q6IFJFOiBbY2x1ZV0g Izc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPiA+Pj4gc3RydWN0 dXJlDQo+ID4+Pg0KPiA+Pj4gSGkgUm9uaQ0KPiA+Pj4NCj4gPj4+IElmIHlvdeKAmXJlIGEgcGFy dGljdWxhciB1c2UgY2FzZXMgcmVxdWlyZXMgY29udHJvbCBvdmVyIHRoZQ0KPiA+Pj4gY29tcG9z ZWQgbGF5b3V0cyB5b3UgbmVlZCBhKSBhbmQgYikuIEluIG15IGV4YW1wbGUgSSB1c2VkIGEgc2lu Z2xlDQo+ID4+PiBhZHZlcnRpc2VtZW50IGNvbXBvc2VkIHN0cmVhbSB3aXRoIG9wdGlvbmFsIG1l dGEtaW5mb3JtYXRpb24gYWJvdXQNCj4gPj4+IHBvc3NpYmxlIGxheW91dCBjaG9pY2VzLiBBIHJl Y2VpdmVyIHRoYXQgd2FudHMgdGhlIGRlZmF1bHQNCj4gPj4+IGNvbXBvc2VkIGxheW91dCBjYW4g cmVxdWVzdCB0aGUgY29tcG9zZWQgc3RyZWFtIGFuZCBza2lwIHRoZQ0KPiA+Pj4gb3B0aW9uYWwg dmlkZW8tDQo+ID4+IGxheW91dCBpbmZvcm1hdGlvbi4NCj4gPj4+IE9wdGlvbmFsbHkgeW91IGNv dWxkIHJlcXVlc3QgdGhlIHNhbWUgY29tcG9zZWQgc3RyZWFtIHdpdGggbGF5b3V0cw0KPiA+Pj4g aGludHMgZm9yIHRoZSByZWNlaXZlci4NCj4gPj4+DQo+ID4+PiBGb3IgbWUgdXNlIGNhc2UgYykg ZG9lcyBub3QgaW5jbHVkZSB0aGUgc2VsZWN0aW9uIG1lY2hhbmlzbXMsIG9ubHkNCj4gPj4gdGhl DQo+ID4+PiBjb250ZW50IHlvdSBzZWUgaW4gdGhlIHZpZGVvIHN0cmVhbS4NCj4gPj4+DQo+ID4+ PiBDaGVlcnMNCj4gPj4+DQo+ID4+PiAtRXNwZW4NCj4gPj4+DQo+ID4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogUm9uaSBFdmVuIFttYWlsdG86cm9uLmV2ZW4udGx2 QGdtYWlsLmNvbV0NCj4gPj4+IFNlbnQ6IDMwLiBqYW51YXIgMjAxMiAxNTozOQ0KPiA+Pj4gVG86 IEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpOyBjbHVlQGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBS RTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4g Pj4+IHN0cnVjdHVyZQ0KPiA+Pj4NCj4gPj4+IEhpIEVzcGVuLA0KPiA+Pj4gSWYgeW91IHdpbGwg bG9vayBhdCB0aGUgbm90ZXMgZnJvbSB0aGUgbGFzdCBjYWxsIHRoZXJlIHdhcyBhDQo+IHN1cHBv cnQNCj4gPj4+IHRoYXQgYSkgaXMgbm90IGVub3VnaC4gSGF2aW5nIGp1c3QgY29tcG9zZSBkb2Vz IG5vdCBhZGRyZXNzIGV2ZW4NCj4gdGhlDQo+ID4+PiB1c2UgY2FzZXMgSSBwcm92aWRlZCB3aGlj aCBhcmUgYWxzbyBiYXNlZCBvbiB0aGUgdXNlIGNhc2UgZHJhZnQuDQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+IEkgYW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSBDIHNpbmNlIHdoYXQgaW4gdGhlIGNv bXBvc2VkIHN0cmVhbQ0KPiA+PiBjYW4NCj4gPj4+IGJlIGVpdGhlciB3aGljaCBWQyB5b3Ugc2Vl IG9yIHdoYXQgaXMgdGhlIHNlbGVjdGlvbiBjcml0ZXJpYSBmb3INCj4gPj4gYmVpbmcNCj4gPj4+ IGluIGEgY29tcG9zZWQgc3RyZWFtLiBJZiB5b3UgbWVhbnQgdGhlIHNlY29uZCwgbXkgdmlldyBp cyB0aGF0IEMNCj4gYW5kDQo+ID4+PiBhbHNvIGIgc2hvdWxkIGJlIGluIHRoZSBiYXNpYyBmcmFt ZXdvcmsgYW5kIG5vdCBpbiBhbiBleHRlbnNpb24uDQo+ID4+Pg0KPiA+Pj4gUm9uaSBFdmVuDQo+ ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogRXNw ZW4gQmVyZ2VyIChlc3BlYmVyZykgW21haWx0bzplc3BlYmVyZ0BjaXNjby5jb21dDQo+ID4+Pj4g U2VudDogTW9uZGF5LCBKYW51YXJ5IDMwLCAyMDEyIDQ6MTcgUE0NCj4gPj4+PiBUbzogUm9uaSBF dmVuOyBjbHVlQGlldGYub3JnDQo+ID4+Pj4gU3ViamVjdDogUkU6IFtjbHVlXSAjNzogSXMgY29t cG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhDQo+ID4+Pj4gc3RydWN0dXJlDQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+IFRvIGhlbHAgd2l0aCB0aGUgZGlyZWN0aW9uIG9mIHRoZSBkaXNj dXNzaW9ucyBJIHRoaW5rIGl0J3MgdXNlZnVsDQo+ID4+IHRvDQo+ID4+Pj4gZGl2aWRlIHRoZSBk aXNjdXNzaW9ucyBpbnRvIHRocmVlIHVzZSBjYXNlcyBmb3IgY29tcG9zZWQgc3RyZWFtcy4NCj4g Pj4+PiAgIGEpIEhvdyB0byBleHByZXNzIGlmIGEgY2FwdHVyZSBzdHJlYW0gaXMgY29tcG9zZWQg b3Igbm90DQo+ID4+Pj4gICBiKSBIb3cgdG8gZXhwcmVzcyBsYXlvdXQgY2hvaWNlcz8gKGUuZy4g d2l0aCBhIHZpZGVvLWxheW91dA0KPiA+Pj4+IGVsZW1lbnQpDQo+ID4+Pj4gICBjKSBIb3cgdG8g ZXhwcmVzcyB3aGF0J3MgaW5zaWRlIGEgY29tcG9zZWQgc3RyZWFtDQo+ID4+Pj4NCj4gPj4+PiBG b3IgdXNlIGNhc2UgYSkgYSBjb21wb3NlZCBhdHRyaWJ1dGUgc2hvdWxkIGJlIHN1ZmZpY2llbnQs IHlvdQ0KPiA+Pj4+IGVpdGhlciBhc2sgZm9yIHRoZSBjb21wb3NlZCBzdHJlYW0gb3IgeW91IGRv IG5vdC4NCj4gPj4+PiBJIGFsc28gYmVsaWV2ZSB0aGlzIHNob3VsZCBjb3ZlciB0aGUgaW50ZXJv cGVyYWJpbGl0eSByZXF1aXJlbWVudA0KPiA+PiB3ZQ0KPiA+Pj4+IGhhdmUgYWNyb3NzIG11bHRp cGxlIHR5cGVzIG9mIGVuZHBvaW50cy4NCj4gPj4+Pg0KPiA+Pj4+IEZvciB1c2UgY2FzZSBiKSBi b3RoIG1lZGlhY3RybCBhbmQgeGNvbiB1c2VzIGE8dmlkZW8tbGF5b3V0Pg0KPiA+Pj4+IGVsZW1l bnQgdG8gZGVzY3JpYmUgcG9zc2libGUgbGF5b3V0cyBhbmQgYWxzbyB0byByZXF1ZXN0IHRoZQ0K PiA+Pj4+IHByZWZlcnJlZCBsYXlvdXQgYmFzZWQgb24gb3B0aW9ucy4gKGFzIGRlc2NyaWJlZCBp biBSb25pJ3MgZW1haWwpDQo+ID4+Pj4NCj4gPj4+PiBBbiBleGFtcGxlIGNvdWxkIGJlIChpbnNw aXJlZCBieSBtZWRpYWN0cmwgYW5kIHhjb24gdXNhZ2Ugb2YNCj4gPj4gPHZpZGVvLQ0KPiA+Pj4+ IGxheW91dD4pOg0KPiA+Pj4+DQo+ID4+Pj4gQ0xVRSBBZHZlcnRpc2VtZW50DQo+ID4+Pj4gICAg Q2FwdHVyZSBpZD0yIFB1cnBvc2U9cGVvcGxlIENvbXBvc2VkPWZhbHNlDQo+ID4+Pj4gICAgQ2Fw dHVyZSBpZD0zIFB1cnBvc2U9cGVvcGxlIENvbXBvc2VkPWZhbHNlDQo+ID4+Pj4gICAgQ2FwdHVy ZSBpZD00IFB1cnBvc2U9UGVvcGxlIENvbXBvc2VkPXRydWUNCj4gPj4+PiAgICAgICAgVmlkZW8t bGF5b3V0PSInYXV0b21hdGljJywgJ2R1YWwtdmlldycsICcgc2luZ2xlLXZpZXcnIg0KPiA+Pj4+ DQo+ID4+Pj4gQ0xVRSBjb25maWd1cmUgLy8gRGVmYXVsdCBjb21wb3NlZCBzdHJlYW0NCj4gPj4+ PiAgICBDYXB0dXJlIGlkPTQNCj4gPj4+Pg0KPiA+Pj4+IC8vIE9yIGNvbXBvc2VkIHN0cmVhbSB3 aXRoIGxheW91dCBoaW50cw0KPiA+Pj4+ICAgICBDYXB0dXJlIGlkPTQgVmlkZW8tbGF5b3V0PSdk dWFsLXZpZXcnDQo+ID4+Pj4NCj4gPj4+PiBUaGUgdmlkZW8tbGF5b3V0IGVsZW1lbnQgaXMgYSBs aXN0IG9mIHN0cmluZ3MgYW5kIGVhY2ggc3RyaW5nIGlzDQo+ID4+Pj4gYSBsYXlvdXQtaGludCB0 aGF0IGNhbiBiZSByZXF1ZXN0ZWQuIFZpZGVvLWxheW91dCBpcyBvcHRpb25hbC4gQQ0KPiA+Pj4+ IGxheW91dCBoaW50cyBhYm91dCB0aGUgcmVxdWVzdGVkIHJlbmRlcmluZyBhbmQgdGhlIHNvdXJj ZSBpcyBmcmVlDQo+ID4+IHRvDQo+ID4+Pj4gcmVwbGFjZSBhbnkgc3RyZWFtIGFzIGxvbmcgYXMg dGhleSBmaXQgdGhlIGxheW91dC4NCj4gPj4+Pg0KPiA+Pj4+IFVzZSBjYXNlIGMpIGlzIG1vcmUg b3BlbiBpbiB0aGUgc2Vuc2UgdGhhdCB3aGF0IHlvdSBhY3R1YWxseQ0KPiA+PiByZWNlaXZlDQo+ ID4+Pj4gaW4gYSBjb21wb3NlZCBzdHJlYW0gaXMgZGVwZW5kaW5nIG9uIHN0YXR1cyBvZiBhIHJv b20gb3Igd2hvIGlzDQo+ID4+Pj4gaW4NCj4gPj4gYQ0KPiA+Pj4+IE1DVSBjb25mZXJlbmNlLiBF LmcuIGZyb20gYSByb29tIHlvdSBjb3VsZCBnZXQgYSBtaXggb2YgZGlmZmVyZW50DQo+ID4+Pj4g Y2FwdHVyZSBzdHJlYW0gcmVwcmVzZW50aW5nIGNhbWVyYXMgYW5kIGZyb20gYSB0cmFuc2NvZGlu ZyBNQ1UgaXQNCj4gPj4+PiBjb3VsZCBiZSBkaWZmZXJlbnQgcm9vbSwgZGlmZmVyZW50IGNhbWVy YXMgb3IgYW5vdGhlciBtaXggb2YNCj4gPj4+PiBwb3NzaWJsZSBpbnB1dCB2aWRlbyBzdHJlYW1z Lg0KPiA+Pj4+DQo+ID4+Pj4gSGF2aW5nIHN1cHBvcnQgZm9yIGJvdGggYikgYW5kIGMpIGNvdWxk IGJlIGEgZ29vZCB0ZXN0IGZvciB0aGUNCj4gPj4+PiBleHRlbnNpYmlsaXR5IG9mIENMVUUuIElm IHRoZSBiYXNpcyBvZiBDTFVFIG9ubHkgZG9lcyB1c2UgY2FzZSBhKQ0KPiA+Pj4+IHRoZXJlIHNo b3VsZCBiZSByb29tIHRvIGV4dGVuZCBDTFVFIHdpdGggc3VwcG9ydCBmb3IgYikgYW5kIGMpIGFz DQo+IGENCj4gPj4+PiBDTFVFICsgbGF5b3V0IGRlc2NyaXB0aW9uIGV4dGVuc2lvbi4NCj4gPj4+ Pg0KPiA+Pj4+IENoZWVycw0KPiA+Pj4+DQo+ID4+Pj4gLUVzcGVuDQo+ID4+Pj4NCj4gPj4+Pg0K PiA+Pj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBj bHVlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ ID4+IEJlaGFsZg0KPiA+Pj4+IE9mIFJvbmkgRXZlbg0KPiA+Pj4+IFNlbnQ6IDMwLiBqYW51YXIg MjAxMiAxMToxOA0KPiA+Pj4+IFRvOiBjbHVlQGlldGYub3JnDQo+ID4+Pj4gU3ViamVjdDogUmU6 IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhDQo+ID4+ Pj4gc3RydWN0dXJlDQo+ID4+Pj4NCj4gPj4+PiBIaSwNCj4gPj4+PiBEdXJpbmcgdGhlIGxhc3Qg Y2FsbCBJIHZvbHVudGVlcmVkIHRvIHByb3ZpZGUgc29tZSBpbnB1dC4NCj4gPj4+Pg0KPiA+Pj4+ IEluIGN1cnJlbnQgSUVURiB3b3JrIChYQ09OLCBNZWRpYWN0cmwgV0dzIHRoZXJlIGlzIGEgdmlk ZW8gbGF5b3V0DQo+ID4+Pj4gZWxlbWVudCkNCj4gPj4+Pg0KPiA+Pj4+IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWVkaWFjdHJsLW1peGVyLWNvbnRyb2wtDQo+ID4+PiBw YWNrYWdlLQ0KPiA+Pj4+IDE0I3NlY3Rpb24tNC4yLjEuNC4yLjENCj4gPj4+Pg0KPiA+Pj4+IGFu ZA0KPiA+Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYteGNvbi1jb21t b24tZGF0YS1tb2RlbC0NCj4gPj4+PiAzMiNzZWN0aW9uLTQuMi43IChsb29rIGF0IHZpZGVvLWxh eW91dCkNCj4gPj4+Pg0KPiA+Pj4+IEkgd291bGQgbGlrZSBmaXJzdCB0byB0cnkgdG8gZGVmaW5l IHRoZSB0ZXJtICJjb21wb3NlZCB2aWRlbyINCj4gc2luY2UNCj4gPj4+IGl0DQo+ID4+Pj4gbG9v a3MgdG8gbWUgbGlrZSB3ZSBoYXZlIGRpZmZlcmVudCB2aWV3cyBoZXJlLCBhbmQgcHJvdmlkZSBt eQ0KPiA+Pj4+IGluaXRpYWwgdmlldyBvbiB3aGF0IHNob3VsZCBiZSBkZXNjcmliZWQuDQo+ID4+ Pj4NCj4gPj4+PiBDb21wb3NlZCB2aWRlbyBjYW4gZGVzY3JpYmVzIGJvdGggdGhlIGxheW91dCBh bmQgdGhlIHNlbGVjdGlvbg0KPiA+Pj4+IGFsZ29yaXRobSBmb3IgY29tcG9zaW5nIHRoZSAgY29u dGVudCBvZiB0aGUgc3ViLXdpbmRvd3MgaW4gdGhlDQo+ID4+PiAibWl4ZWQiDQo+ID4+Pj4gdmlk ZW8uDQo+ID4+Pj4NCj4gPj4+PiBUaGUgdmlkZW8gbGF5b3V0IHdoaWNoIGp1c3QgZGVzY3JpYmVz IHRoZSBnZW9tZXRyeSBvZiB0aGUNCj4gPj4+PiBjb21wb3NlZCBpbWFnZSBhbmQgSSB0aGluayB0 aGF0IHRoZSBhYm92ZSByZWZlcmVuY2VzIHByb3ZpZGUgZ29vZA0KPiA+Pj4+IHN0cnVjdHVyZSB0 byBkZWZpbmUgdGhpcyBwYXJ0IG9mIHRoZSBjb21wb3NlZCB2aWRlbyBhdHRyaWJ1dGUuDQo+ID4+ Pj4NCj4gPj4+PiBUaGUgb3RoZXIgcGFydCBpcyB0aGUgYWxnb3JpdGhtIGJ5IHdoaWNoIHRoZSBw cm92aWRlciBzZWxlY3QgdGhlDQo+ID4+Pj4gY29udGVudCBvZiBlYWNoIGVsZW1lbnQgaW4gdGhl IGxheW91dC4gU2luY2UgdGhlIGNvbnRlbnQgb2YgZWFjaA0KPiA+Pj4+IGVsZW1lbnQgbWF5IGNo YW5nZSBkeW5hbWljYWxseSBieSB0aGUgcHJvdmlkZXIgdGhpcyBhdHRyaWJ1dGUNCj4gPj4+PiBv bmx5IGFkZHJlc3MgdGhlIHN0YXRpYyBpbmZvcm1hdGlvbiB3aGljaCBpcyB0aGUgYWxnb3JpdGht IGFuZA0KPiA+Pj4+IG5vdCB0aGUgY3VycmVudCBjb250ZW50ICh3aG8gd2Ugc2VlIG5vdyBpbiBl YWNoIGVsZW1lbnQpIHdoaWNoDQo+ID4+Pj4gd2lsbCBuZWVkDQo+IHRvDQo+ID4+PiBiZQ0KPiA+ Pj4+IGNvbnZleWVkIGFsc28gYnV0IHByb2JhYmx5IG5vdCB1c2luZyB0aGlzIGF0dHJpYnV0ZS4g Tm90ZSB0aGF0DQo+ID4+Pj4gdGhlIGluZm9ybWF0aW9uIGlzIHZhbGlkIGZvciBwb2ludCB0byBw b2ludCBhbmQgbXVsdGlwb2ludCBzbyB0aGUNCj4gPj4+PiBjdXJyZW50IGNvbnRlbnQgc2hvdWxk IHJlZmxlY3QgdGhlIFRQIGVuZCBwb2ludCBhbmQgdGhlIHNwZWNpZmljDQo+IFZDDQo+ID4+Pj4g dXNlZCBmcm9tIGl0Lg0KPiA+Pj4+DQo+ID4+Pj4gVGhlIGFsZ29yaXRobXMgbWF5IGJlIGdsb2Jh bCBvciBwZXIgZWxlbWVudChvciBzdWItd2luZG93KS4gVGhlDQo+ID4+PiBnbG9iYWwNCj4gPj4+ PiBhbGdvcml0aG1zIEkgc2VlIGFyZSBzaXRlIHN3aXRjaCBvciBzZWdtZW50IHN3aXRjaC4gVGhl IHBlcg0KPiBlbGVtZW50DQo+ID4+Pj4gbWF5IGJlIHZvaWNlIGFjdGl2YXRlZCwgcm91bmQgcm9i aW4gKHN3aXRjaCBldmVyeSB4IHNlY29uZHMpIGFuZA0KPiA+Pj4gZml4ZWQNCj4gPj4+PiAodGhl IHNhbWUgVkMgaXMgZGlzcGxheWVkIHRoZXJlIChtYXkgYmUgY2hhbmdlZCBieSBzb21lIGNvbnRy b2wNCj4gPj4+PiBtZWNoYW5pc20pDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IFJvbmkNCj4gPj4+ Pg0KPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+PiBGcm9tOiBjbHVl LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4+ PiBCZWhhbGYNCj4gPj4+Pj4gT2YgY2x1ZSBpc3N1ZSB0cmFja2VyDQo+ID4+Pj4+IFNlbnQ6IFR1 ZXNkYXksIEphbnVhcnkgMjQsIDIwMTIgMTI6NDMgQU0NCj4gPj4+Pj4gVG86IGRyYWZ0LWlldGYt Y2x1ZS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc7DQo+ID4+Pj4+IG1hcnkuaWV0Zi5iYXJuZXNA Z21haWwuY29tDQo+ID4+Pj4+IENjOiBjbHVlQGlldGYub3JnDQo+ID4+Pj4+IFN1YmplY3Q6IFJl OiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPiA+ Pj4+PiBzdHJ1Y3R1cmUNCj4gPj4+Pj4NCj4gPj4+Pj4gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0 ZSBhIGJvb2xlYW4gb3IgZGF0YSBzdHJ1Y3R1cmUNCj4gPj4+Pj4NCj4gPj4+Pj4gQ2hhbmdlcyAo YnkgbWFyeS5pZXRmLmJhcm5lc0DigKYpOg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICogdHlwZTogIGRl ZmVjdCA9PiAgdGFzaw0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiAtLQ0KPiA+Pj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0NCj4gPj4gLQ0K PiA+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+ID4+PiAtDQo+ID4+ Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0NCj4gPj4+PiAtDQo+ID4+Pj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0NCj4gPj4+Pj4gLS0tLQ0KPiA+Pj4+ PiAgIFJlcG9ydGVyOiAgbWFyeS5pZXRmLmJhcm5lc0DigKYgIHwgICAgICAgT3duZXI6ICBkcmFm dC1pZXRmLWNsdWUtDQo+ID4+Pj4+IGZyYW1ld29ya0DigKYNCj4gPj4+Pj4gICAgICAgVHlwZTog IHRhc2sgICAgICAgICAgICAgICAgfCAgICAgIFN0YXR1czogIG5ldw0KPiA+Pj4+PiAgIFByaW9y aXR5OiAgbWFqb3IgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOg0KPiA+Pj4+PiBDb21wb25l bnQ6ICBmcmFtZXdvcmsgICAgICAgICAgIHwgICAgIFZlcnNpb246DQo+ID4+Pj4+ICAgU2V2ZXJp dHk6ICBBY3RpdmUgV0cgRG9jdW1lbnQgIHwgIFJlc29sdXRpb246DQo+ID4+Pj4+ICAgS2V5d29y ZHM6ICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+ID4+IC0NCj4gPj4+Pj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLQ0KPiA+Pj4gLQ0KPiA+Pj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+ID4+Pj4gLQ0KPiA+Pj4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstDQo+ID4+Pj4+IC0tLS0NCj4gPj4+Pj4NCj4gPj4+Pj4gVGlja2V0 IFVSTDoNCj4gPj4+Pj4gPGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2NsdWUvdHJhYy90 aWNrZXQvNyNjb21tZW50OjI+DQo+ID4+Pj4+IGNsdWU8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dn L2NsdWUvPg0KPiA+Pj4+Pg0KPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+Pj4+PiBjbHVlIG1haWxpbmcgbGlzdA0KPiA+Pj4+PiBjbHVl QGlldGYub3JnDQo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2x1ZQ0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4+PiBjbHVlIG1haWxpbmcgbGlzdA0KPiA+Pj4+IGNsdWVAaWV0Zi5v cmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4g Pj4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBjbHVlIG1haWxpbmcgbGlzdA0KPiA+IGNsdWVAaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY2x1ZSBtYWlsaW5nIGxp c3QNCj4gY2x1ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NsdWUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gY2x1ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gY2x1ZUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg0K From Mark.Duckworth@polycom.com Wed Feb 8 13:27:47 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 A623721F84D8 for ; Wed, 8 Feb 2012 13:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 SziUeF0kcais for ; Wed, 8 Feb 2012 13:27:43 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9F621F84D4 for ; Wed, 8 Feb 2012 13:27:43 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 8 Feb 2012 13:27:42 -0800 From: "Duckworth, Mark" To: Marshall Eubanks , "clue@ietf.org" Date: Wed, 8 Feb 2012 13:27:40 -0800 Thread-Topic: [clue] #7: Is composed attribute a boolean or data structure (was: Is compose attribute a boolean or data structure) Thread-Index: AczatCrHYXZFXrJoQhOuu0hnfw80QAL8PFfQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB301794@CRPMBOXPRD01.polycom.com> References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> <083.6853ec8d97dcdb1adcf1dba473d6d65f@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] #7: Is composed attribute a boolean or data structure (was: Is compose 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, 08 Feb 2012 21:27:47 -0000 Hi Marshall, I'm trying to put your proposal in perspective of some other related issues= . Basically you are proposing a way for a media provider to advertise comp= osed media captures, including a list of sources that go into the compositi= on, right? And this could potentially be done by adding some additional at= tributes to media captures. (I'm using the term capture, to be consistent w= ith the framework, where you use the term stream). So this would work for cases where the source list does not change often, r= ight? Or are you thinking this would work for cases where the source list = in a composed capture changes due to a change in current talker or a due to= a participant joining or leaving the conference? Would you suggest the pr= ovider must advertise a media capture with new attribute values every time = a change like this occurs? I was thinking that would not be practical. This proposal sounds similar to Stephan's proposal from the discussion "Kic= k-Off Item 5: description of composed pictures" about three months ago. Do= you see this as a subset of Stephan's proposal, without the x,y bitstream = coordinates? Or do you see this as something else entirely? It seems like= a subset to me. Separate from your proposal, which you say does not cover detailed formatti= ng information, we could also potentially define a video-layout attribute l= ike what Roni referred to from mediactrl and xcon. I think the two ideas c= ould be used together. Also we could potentially add something about switc= hing/composing policies or algorithms, of which your special character "A = =3D active speaker" is just one example. Mark -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= shall Eubanks Sent: Tuesday, January 24, 2012 11:21 AM To: clue issue tracker Cc: draft-ietf-clue-framework@tools.ietf.org; clue@ietf.org Subject: Re: [clue] #7: Is composed attribute a boolean or data structure (= was: Is compose attribute a boolean or data structure) Here is a specific suggestion based on the discussion today : Composition is described by two (or more) booleans, and associated lists First boolean : Is the stream composed of other streams ? Yes, or no. Second boolean : Is this composed stream composed of other streams that the= offerer is also offering. Associated List : A list of those streams. This second boolean has no meaning and MUST be ignored if the first boolea= n is missing or negative. So, suppose there is a 4 screen unit (with streams 1-4), which also offers - Stream 5 : a composition of screens 1 and 2 - Stream 6 : a composition of screens 3 and 4 - Stream 7 : a composition of screens 1, 2, 3 and 4 So, stream 5 might have a pseudocode description like composed=3Dtrue {composed_stream_set=3Dtrue {stream_set=3D"1,2"}} while stream 7 would be composed=3Dtrue {composed_stream_set=3Dtrue {stream_set=3D"1,2,3,4"}} I would strongly suggest that composed streams can be nested (as indeed the= y are frequently in practice). I would also suggest two "special characters" - call them D =3D=3D "data" and A =3D=3D "active speaker" So, a stream 8 with composed=3Dtrue {composed_stream_set=3Dtrue {stream_set=3D"7, A, D"}} would mean a composed combination of (a composition of all of the true streams) + the screen containing the active speaker + a data screen. It would be useful to allow for virtual streams (i.e., maybe in my example = stream "7" only exists inside the unit and is not available to others). Tha= t would make description more straightforward. It is not clear to me wheth= er or not virtual streams should have a virtual attribute, or whether or no= t that can conveyed within the existing framework. Of course, dependency lo= ops MUST be avoided. The "A" attribute would be most useful for middle boxes. If a composition= is really coming from a 4 screen unit, then "A" may be at some remote unit= , so this would be not so useful. However, if a composition is actually co= ming from a middle box, then A can be the speaker, and having the attribute= would be useful. I believe that this proposal would capture essentially all of the compositi= on use cases that do not require detailed formatting information. Regards Marshall On Mon, Jan 23, 2012 at 5:15 PM, clue issue tracker wrote: > #7: Is composed attribute a boolean or data structure > > > -- > --------------------------------+------------------------------------- > --------------------------------+----- > =A0Reporter: =A0mary.ietf.barnes@. =A0| =A0 =A0 =A0 Owner: =A0 > draft-ietf-clue-framework@. > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: = =A0new > =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: > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > --------------------------------+------------------------------------- > --------------------------------+----- > > Ticket URL:=20 > > 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 Wed Feb 8 13:59: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 E640611E8083 for ; Wed, 8 Feb 2012 13:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.364 X-Spam-Level: X-Spam-Status: No, score=-106.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 zCLbSuumFW3H for ; Wed, 8 Feb 2012 13:59:05 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD7811E807F for ; Wed, 8 Feb 2012 13:59:05 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3B53933C22; Wed, 8 Feb 2012 16:59:05 -0500 (EST) Date: Wed, 8 Feb 2012 16:59:05 -0500 From: John Leslie To: "Duckworth, Mark" Message-ID: <20120208215905.GP61963@verdi> References: <4F3046C9.4060401@alum.mit.edu> <20120206234107.GH61963@verdi> <44C6B6B2D0CF424AA90B6055548D7A6102FB202BEA@CRPMBOXPRD01.polycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB202BEA@CRPMBOXPRD01.polycom.com> User-Agent: Mutt/1.4.1i Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates 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, 08 Feb 2012 21:59:06 -0000 Duckworth, Mark wrote: > John Leslie wrote: > >> "But I'd like to suggest we instead think in terms of identifying >> the physical location of the _microphone_ with greatest speech-like >> sound. That physical location is pretty easy to know; and if folks >> really care about identifying _speaker_ location, they can use more >> mikes." > > I disagree. If a media provider wants to estimate the speaker (talker) > location based on which microphone has the greatest speech-like sound, > that is fine. But some microphone arrangements (along with the audio > processing algorithms) just don't work that way. Umm... > For example, microphone arrays where there is no direct constant > relationship between a microphone element and an encoded audio channel. If you're talking about the likes of Polycom HDX, I consider that a microphone "pointed" down with a time-variable pattern. Granted, "greatest speech-like sound" is hand-waving, but I think we're stuck with that problem anyway: there needs to be an algorithm to say "none of the individual mikes seem to be close to this speaker; thus we select the room-general mike". And as a sound guy, I want to know that the room-general mike is the one selected _before_ I worry about the coordinates of the actual speaker. I would likely treat the computed coordinates as a hint rather than an established fact. > So if those systems identified the location of the microphone with > greatest speech-like sound it wouldn't necessarily have any relation > to the location of the talker. Correct! > I think it is better for the media provider to estimate (usually better > than a guess!) where the talker is, using whatever method makes sense > for that provider. It is reasonable to provide that estimate in addition to the location of the room-general microphone. But IMHO, different providers will use different algorithms, and I don't see how to know the accuracy of the estimate. > We don't want the media consumer to be making incorrect assumptions > about how the provider's microphone system works. Exactly! -- John Leslie From espeberg@cisco.com Wed Feb 8 14:42: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 C261111E8080 for ; Wed, 8 Feb 2012 14:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_84=0.6, 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 s97FrvvXYTiq for ; Wed, 8 Feb 2012 14:42:30 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AFA6321F848C for ; Wed, 8 Feb 2012 14:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=28820; q=dns/txt; s=iport; t=1328740948; x=1329950548; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=G5HhoDxSUI87aADJm0J1JzxrhX8LsHqXIXFyQshmakA=; b=Yc8OLn7GA+zWRuwy3VmpWZpt6y3lNDLXwS0CM+08O0ncGnZs6/g4EZYm +Kp4iluQmxrcyirsibvw7gEzF2qgpPe0R409S8y7emrIFCGBOXTse4Cc5 RcT4mmXBwEBqg2cKnwz1J34X0wJgBcY5ZJNbVfURXiyB3/vLWapXMg4LY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMb5Mk+Q/khM/2dsb2JhbABDhQ2pDXGBB4FyAQEBBAEBAQ8BEA0ENAYXBAIBCBEEAQEBAgIGBhcBAgICAQEfBh8JCAEBBAESCBqHY5pJAYxlkWSBL4ZtgzABKQYBLQwChDINAgoCgigzYwSgOYdS X-IronPort-AV: E=Sophos;i="4.73,386,1325462400"; d="scan'208";a="65698161" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 08 Feb 2012 22:42:27 +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 q18MgR3V003252; Wed, 8 Feb 2012 22:42:27 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); Wed, 8 Feb 2012 23:42:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 8 Feb 2012 23:42:25 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EEC5B04@XMB-AMS-214.cisco.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB202E57@CRPMBOXPRD01.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] #7: Is composed attribute a boolean or data structure Thread-Index: AczhBxgZzsQM+HraTUCVftAm4h2iFAAvm5hgASwpd2AAAwipoAACU9dwAAa5QAA= References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org><083.e4945b5c72773c1362efdf7bb0443c4a@trac.tools.ietf.org><4f266f4c.d0770e0a.43c6.37fd@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48845@XMB-AMS-214.cisco.com><4f26ac4f.11840e0a.6db6.ffff9756@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48877@XMB-AMS-214.cisco.com><4f272344.03bd0e0a.6983.3d7e@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48A3C@XMB-AMS-214.cisco.com><4f291525.84310e0a.69d7.fffffd3b@mx.google.com><92DF9533227FC14F946C7321074B8C9EE48BCD@XMB-AMS-214.cisco.com><4F29766F.1080101@alum.mit.edu><92DF9533227FC14F946C7321074B8C9EEC526F@XMB-AMS-214.cisco.com><44C6B6B2D0CF424AA90B6055548D7A6102FB202D20@CRPMBOXPRD01.polycom.com><4f32a9a9.c9840e0a.492a.ffffd4d9@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB202E57@CRPMBOXPRD01.polycom.com> From: "Espen Berger (espeberg)" To: "Duckworth, Mark" , "Roni Even" , X-OriginalArrivalTime: 08 Feb 2012 22:42:27.0172 (UTC) FILETIME=[EECA8A40:01CCE6B2] 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, 08 Feb 2012 22:42:31 -0000 SSBhZ3JlZSB3aXRoIE1hcmtzIHN1bW1hcnkgb2YgdGhlIHByb3ZpZGVyIGNhcGFiaWxpdGllcyBm b3IgYSB0cmlwbGUgY2FtZXJhIHN5c3RlbS4gIA0KDQpSb25pJ3MgY29tbWVudHMgcG9pbnRlZCBv dXQgdGhlIGZhY3QgdGhhdCB3ZSBjb3VsZCBhcHBseSBkaWZmZXJlbnQgcG9saWNpZXMgdG8gYSBj YXB0dXJlIHNldCBvciBpbmRpdmlkdWFsIHN0cmVhbXMuIFdlIGhhdmUgZGlzY3Vzc2VkIHBvbGlj aWVzIGZvciBzd2l0Y2hlZCBzdHJlYW1zIGFuZCB2aWRlbyBsYXlvdXRzLCBzdW1tYXJpemVkIGhl cmU6DQoNClN3aXRjaGVkIHBvbGljaWVzIA0KIC0gU2VnbWVudCANCiAtIFNpdGUgDQogLSBSb3Vu ZCByb2JpbiAoZS5nLiBpdGVyYXRlIG92ZXIgYXZhaWxhYmxlIHNlZ21lbnRzLCBjaGFuZ2UgZXZl cnkgMTAgc2VjKSANCg0KVmlkZW8tbGF5b3V0IChJbnNwaXJlZCBieSB4Y29uIFsxXSkNCiAtIGR1 YWwtdmlldw0KIC0gc2luZ2xlLXZpZXcgDQogLSBIb2xseXdvb2Qtc3F1YXJlcw0KIC0gLy8gYW5k IHNvIG9uDQoNCkEgbW9kZWwgd2hlcmUgYSBtZWRpYSBwcm9kdWNlciBhbm5vdW5jZSB0aGUgYXZh aWxhYmlsaXR5IG9mIGEgcG9saWN5IGNvdWxkIHdvcmsuIEEgY2FwdHVyZSBzZXQgY2FuIHRoZW4g YW5ub3VuY2UgYSB2aWRlby1sYXlvdXQgYXR0cmlidXRlIHRvIGxldCBhIG1lZGlhIGNvbnN1bWVy IHJlcXVlc3QgYSBjYXB0dXJlcyB3aXRoIGEgcHJlZmVycmVkIHZpZGVvLWxheW91dCBhbHRlcm5h dGl2ZSwgaWYgYWx0ZXJuYXRpdmVzIGFyZSBhdmFpbGFibGUuIFRoZSB2aWRlby1sYXlvdXQgYXR0 cmlidXRlIGNvdWxkIGFsc28gYmUgYW5ub3VuY2VkIG9uIHRoZSBpbmRpdmlkdWFsIGNhcHR1cmUu DQoNCkFuIGV4YW1wbGUgYmFzZWQgb24gTWFya3MgZW1haWw6IA0KIENhcHR1cmUgVkM3IChzaW5n bGUgc3RyZWFtIGNvbXBvc2l0aW9uKSBjb21wb3NlZCwgbm90IHN3aXRjaGVkDQogQ2FwdHVyZSBz ZXQgQWx0ZXJuYXRpdmUgNCAoVkM3KSB2aWRlby1sYXlvdXQge2R1YWwtdmlldywgc2luZ2xlLXZp ZXcsIEhvbGx5d29vZC1zcXVhcmVzIH0gDQoNClRvIHJlcXVlc3QgdGhlIHNpbmdsZSBjb21wb3Nl ZCBzdHJlYW0gKHdpdGggZGVmYXVsdCB2aWRlby1sYXlvdXQpDQogIFZDNQ0KDQpUbyByZXF1ZXN0 IHRoZSBzaW5nbGUgY29tcG9zZWQgc3RyZWFtLCB3aXRoIGEgc3BlY2lmaWMgdmlkZW8tbGF5b3V0 DQogIFZDNSwgdmlkZW8tbGF5b3V0PSdkdWFsLXZpZXcnDQoNClRoZSBleGFtcGxlIFJvbmkgbWVu dGlvbmVkIHdpdGggZGV0YWlsZWQgY29udHJvbCBvZiB3aG8gaXMgaW5jbHVkZWQgaW4gYSBjb21w b3NlZCBsYXlvdXQgaXMgbm90IG1lbnRpb25lZCBpbiB0aGUgdXNlIGNhc2UgZG9jdW1lbnQsIHNv IG1heWJlIHdlIGNvdWxkIHNlZSBpdCBhcyBvdXQgb2Ygc2NvcGUgZm9yIG5vdz8gDQoNClJlZ2Fy ZHMgDQoNCi1Fc3BlbiANCiBbMV0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi14Y29uLWNvbW1vbi1kYXRhLW1vZGVsLTMyI3NlY3Rpb24tNC4yLjcNCg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjbHVlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpj bHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEdWNrd29ydGgsIE1hcmsNClNlbnQ6 IDguIGZlYnJ1YXIgMjAxMiAxOToxNA0KVG86IFJvbmkgRXZlbjsgY2x1ZUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBk YXRhIHN0cnVjdHVyZQ0KDQpIaSBSb25pLA0KWWVzLCBJIGFncmVlLiAgVGhhdCBpcyB3aGF0IEkg bWVhbnQgYnkgdGhlIHN0YXRlbWVudCAiVkMzIHRocm91Z2ggVkM4IGNvdWxkIGFsc28gaGF2ZSBh ZGRpdGlvbmFsIGF0dHJpYnV0ZXMgZGVzY3JpYmluZyB0aGUgYXZhaWxhYmxlIHZpZGVvIGxheW91 dCBjaG9pY2VzIGZvciBjb21wb3NpdGlvbiBvciB0aGUgYXZhaWxhYmxlIHN3aXRjaGluZyBwb2xp Y2llcyB0aGUgcHJvdmlkZXIgaXMgb2ZmZXJpbmcuICBUaGUgY29uc3VtZXIgY291bGQgY2hvb3Nl IGFtb25nIHRoZXNlLiINCg0KTWFyaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogUm9uaSBFdmVuIFttYWlsdG86cm9uLmV2ZW4udGx2QGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5l c2RheSwgRmVicnVhcnkgMDgsIDIwMTIgMTE6NTggQU0NClRvOiBEdWNrd29ydGgsIE1hcms7IGNs dWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0 ZSBhIGJvb2xlYW4gb3IgZGF0YSBzdHJ1Y3R1cmUNCg0KSGkgTWFyaywNCkkgY2FuIGFkZCB0d28g bW9yZSBvcHRpb25zLg0KDQoxLiBUd28gb3V0IG9mIHRocmVlIHdoaWNoIHdpbGwgaW5jbHVkZSB0 aGUgY3VycmVudCBhbmQgcHJldmlvdXMgc3BlYWtlciAyLiBUd28gb3V0IG9mIHRocmVlIHdoaWNo IHdpbGwgcm90YXRlIGJldHdlZW4gdGhlIHRocmVlIGV2ZXJ5IDEwIHNlY29uZHMgVGhlc2UgdHdv IGNhbm5vdCBiZSBkaWZmZXJlbnRpYXRlZCB3aXRoIGJpbmFyeSBjb21wb3NlZCBhbmQgc3dpdGNo ZWQuDQoNCklmIHdlIGdvIGZyb20gdGhyZWUgdG8gb25lIHdlIGhhdmUgZXZlbiBtb3JlIG9wdGlv bnMgdGhhdCBjYW5ub3QgYmUgZGlmZmVyZW50aWF0ZWQgYnkgYmluYXJ5IHZhbHVlcyBhbmQgSSB0 aGluayB0aGF0IHRocmVlIHRvIG9uZSB3aWxsIGJlIG1vcmUgY29tbW9uLg0KDQpSb25pDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgRHVja3dvcnRo LCBNYXJrDQo+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDgsIDIwMTIgNTo1NCBQTQ0KPiBU bzogY2x1ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBh dHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4gc3RydWN0dXJlDQo+DQo+IEknbGwgYWRkIG15 IHRob3VnaHRzIHRvIHRoaXMsIGZvciBob3cgSSBzZWUgdGhpcyBzY2VuYXJpbyB3b3JraW5nICgz eA0KPiBjYW1lcmEgc3lzdGVtIHNlbmRpbmcgdG8gYSAyeCBzY3JlZW4gc3lzdGVtKSwgdXNpbmcg RXNwZW4ncyBpZGVhcyBmb3INCj4gd2hhdCB0aGUgYWx0ZXJuYXRpdmVzIGFyZSBmb3IgdGhpcyBw YXJ0aWN1bGFyIGV4YW1wbGUsIGdpdmVuIHRoaXMNCj4gcGFydGljdWxhciBoeXBvdGhldGljYWwg MyBzY3JlZW4gcHJvdmlkZXIncyBjYXBhYmlsaXRpZXMuDQo+DQo+IFByb3ZpZGVyIGFkdmVydGlz ZXMgdGhlc2UgOSB2aWRlbyBjYXB0dXJlczoNCj4gVkMwIChsZWZ0KSBub3QgY29tcG9zZWQ7IG5v dCBzd2l0Y2hlZA0KPiBWQzEgKG1pZGRsZSkgbm90IGNvbXBvc2VkOyBub3Qgc3dpdGNoZWQNCj4g VkMyIChyaWdodCkgbm90IGNvbXBvc2VkOyBub3Qgc3dpdGNoZWQNCj4gVkMzIChsZWZ0IGhhbGYg b2YgdHdvIHNjcmVlbiBjb21wb3NpdGlvbikgY29tcG9zZWQ7IG5vdCBzd2l0Y2hlZA0KPiBWQzQg KHJpZ2h0IGhhbGYgb2YgdHdvIHNjcmVlbiBjb21wb3NpdGlvbikgY29tcG9zZWQ7IG5vdCBzd2l0 Y2hlZA0KPiBWQzUgKGxlZnQgaGFsZiBvZiB0d28gc2NyZWVuIHN3aXRjaGVkKSBub3QgY29tcG9z ZWQ7IHN3aXRjaGVkDQo+IFZDNiAocmlnaHQgaGFsZiBvZiB0d28gc2NyZWVuIHN3aXRjaGVkKSBu b3QgY29tcG9zZWQ7IHN3aXRjaGVkDQo+IFZDNyAoc2luZ2xlIHN0cmVhbSBjb21wb3NpdGlvbikg Y29tcG9zZWQsIG5vdCBzd2l0Y2hlZA0KPiBWQzggKHNpbmdsZSBzdHJlYW0gc3dpdGNoZWQpIG5v dCBjb21wb3NlZCwgc3dpdGNoZWQNCj4NCj4gVkMzIHRocm91Z2ggVkM4IGNvdWxkIGFsc28gaGF2 ZSBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgZGVzY3JpYmluZyB0aGUNCj4gYXZhaWxhYmxlIHZpZGVv IGxheW91dCBjaG9pY2VzIGZvciBjb21wb3NpdGlvbiBvciB0aGUgYXZhaWxhYmxlDQo+IHN3aXRj aGluZyBwb2xpY2llcyB0aGUgcHJvdmlkZXIgaXMgb2ZmZXJpbmcuICBUaGUgY29uc3VtZXIgY291 bGQNCj4gY2hvb3NlIGFtb25nIHRoZXNlLiAgSSB0aGluayB0aGF0IGlzIHRoZSBwb2ludCBSb25p IGhhcyBiZWVuIG1ha2luZy4NCj4gRGV0YWlscyBvZiB0aGlzIG5lZWQgZnVydGhlciBkaXNjdXNz aW9uLiAgKE1heWJlIHRoZSBjb21wb3NlZCBhbmQNCj4gc3dpdGNoZWQgY2hvaWNlcyBzaG91bGQg YmUgY29sbGFwc2VkIGludG8gb25lIHNldCBvZiBzdHVmZiB0byBjaG9vc2UNCj4gZnJvbSBmb3Ig YSBwYXJ0aWN1bGFyIFZDLCByYXRoZXIgdGhhbiBzZXBhcmF0ZSBWQ3MsIHNvIHRoYXQgd291bGQN Cj4gcmVkdWNlIHRoZSBudW1iZXIgb2YgVkNzIGhlcmUgZnJvbSA5IHRvIDYgPykuDQo+DQo+IFBy b3ZpZGVyIGFkdmVydGlzZXMgYSBjYXB0dXJlIHNldCB3aXRoIDUgZW50cmllczoNCj4gRW50cnkg MSAoVkMwLCBWQzEsIFZDMikNCj4gRW50cnkgMiAoVkMzLCBWQzQpDQo+IEVudHJ5IDMgKFZDNSwg VkM2KQ0KPiBFbnRyeSA0IChWQzcpDQo+IEVudHJ5IDUgKFZDOCkNCj4NCj4gQnkgYWR2ZXJ0aXNp bmcgdGhlIGNhcHR1cmUgc2V0IGluIHRoaXMgd2F5LCB0aGUgcHJvdmlkZXIgaXMgc3VnZ2VzdGlu Zw0KPiB3aGljaCB2aWRlbyBjYXB0dXJlcyBhcmUgbW9zdCB1c2VmdWwgdG8gcmVjZWl2ZSB0b2dl dGhlciwgdG8gZ2V0IGENCj4gdmlldyBvZiB0aGUgd2hvbGUgc2NlbmUuICBFYWNoIGVudHJ5IGlu IHRoZSBjYXB0dXJlIHNldCBpcyBhIHN1Z2dlc3RlZA0KPiBhbHRlcm5hdGl2ZS4NCj4NCj4gQSAy IHNjcmVlbiBjb25zdW1lciBjYW4gY2hvb3NlIFZDMyBhbmQgVkM0IGlmIGl0IHdhbnRzIGEgY29t cG9zaXRpb24uDQo+IEl0IGNhbiBjaG9vc2UgVkM1IGFuZCBWQzYgaWYgaXQgd2FudHMgYSBkeW5h bWljYWxseSBzd2l0Y2hlZCB2aWV3LiAgQQ0KPiAyIHNjcmVlbiBjb25zdW1lciBpcyBhbHNvIGZy ZWUgdG8gaWdub3JlIHRoZSBzdWdnZXN0aW9ucyBpbiB0aGUNCj4gY2FwdHVyZSBzZXQgYW5kIGlu c3RlYWQgY2hvb3NlIFZDMCBhbmQgVkMxIGlmIHRoYXQgaXMgd2hhdCBpdCB3YW50cy4NCj4gSXQg Y291bGQgYWxzbyBjaG9vc2Ugb3RoZXIgY29tYmluYXRpb25zIGZyb20gZGlmZmVyZW50IGVudHJp ZXMsIHNheQ0KPiBWQzEgYW5kIFZDOCwgYXNzdW1pbmcgdGhlIHByb3ZpZGVyJ3MgYWR2ZXJ0aXNl ZCBzaW11bHRhbmVvdXMgc2V0cyBhbmQNCj4gZW5jb2RpbmcgZ3JvdXBzIGRvIG5vdCBwcm9oaWJp dCB0aGF0IGNvbWJpbmF0aW9uLg0KPg0KPiBNYXJrDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIEVzcGVuIEJlcmdlciAoZXNwZWJlcmcpDQo+IFNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwMiwgMjAxMiAxMTo0MiBBTQ0KPiBUbzogUGF1bCBLeXpp dmF0OyBjbHVlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2Vk IGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPiBzdHJ1Y3R1cmUNCj4NCj4gSGkgUGF1bA0K Pg0KPiBJIHdpbGwgbWFrZSBhIGJyaWVmIGF0dGVtcHQgdG8gYW5zd2VyLg0KPg0KPiBUaGUgc2Nl bmFyaW9zIGFyZSBob3cgdG8gbWFwIGEgM3ggY2FtZXJhIHN5c3RlbSB0byBhIDJ4IHNjcmVlbiBz eXN0ZW0uDQo+IFRoZSB0cmlwbGUgb2ZmZXIgIFN0cmVtYSA9IDEgLSAzICBQb2xpY2llcyA9IFN3 aXRjaGVkLCBzdGF0aWMsDQo+IGNvbXBvc2VkDQo+DQo+IEFzIGEgcmVjZWl2ZXIgKHdpdGggMngg c2NyZWVucykgSSB3b3VsZCBkbyB0aGlzIGNob2ljZXMNCj4NCj4gMSkgSG93IG1hbnkgc3RyZWFt cyB0byByZWNlaXZlDQo+ICAgIDEgPT4gVGhlIHRyaXBsZSBzZW5kcyBhIHNpbmdsZSBzdHJlYW0g Ynkgc29tZSBzZW5kZXIgcHJlZmVycmVkDQo+IHBvbGljeQ0KPiAgICAyID0+IFRoZSB0cmlwbGUg c2VuZHMgdHdvIHN0cmVhbXMgYnkgc29tZSBwb2xpY3kNCj4gICAgMyA9PiBUaGUgdHJpcGxlIHNl bmRzIHRocmVlIGNhbWVyYXMgaW4gc3BhdGlhbCBvcmRlciwgYW5kDQo+ICAgICAgIHRoZSByZWNl aXZlciBkZWNpZGUgaG93IHRvIHJlbmRlciBhY3Jvc3MgdHdvIHNjcmVlbnMNCj4NCj4gMikgV2hp Y2ggc3dpdGNoaW5nIHBvbGljeQ0KPiAgIFN0YXRpYyA9PiBUaGUgcmVxdWVzdGVyIGFzayBmb3Ig ZXhwbGljaXQgY2FtZXJhIHN0cmVhbXMsIGUuZy4gY2FtMQ0KPiBvcg0KPiAoY2FtMitjYW0zKQ0K PiAgIFN3aXRjaGVkL0NvbXBvc2VkID0+IFRoZSB0cmlwbGUgY2hvb3NlcyB0aGUgc3RyZWFtcyB0 byBzZW5kLCBlLmcuDQo+IHRoZSB0d28gbG91ZGVzdCBzZWdtZW50cyBvciBpdCBjb3VsZCBtYWtl IGEgbmljZSByZW5kZXJpbmcgb2YgM3gNCj4gY2FtZXJhcyByZW5kZXJlZCBvbiB0d28gc3RyZWFt cy4NCj4NCj4gSSBhc3N1bWUgdGhhdCB5b3Ugd29uJ3QgdXNlIGRpZmZlcmVudCBzd2l0Y2hpbmcg cG9saWNpZXMgZm9yIHRoZQ0KPiBkaWZmZXJlbnQgc3RyZWFtcywgc2luY2UgaXQgZ2l2ZXMgdGhl IHNlbmRlciBvZiBtZWRpYSB0aGUgY2hhbmNlIHRvDQo+IG9wdGltaXplIHdoYXQgaXQgc2VuZCBv biB0aGUgc3RyZWFtcyByZXF1ZXN0ZWQuDQo+DQo+IFRoZSAnc2l0ZScgc3dpdGNoaW5nIHBvbGlj eSBtYWtlcyBtb3N0IHNlbnNlIGZyb20gYW4gTUNVLiBJIGludGVycHJldGUNCj4gdGhlIHBvbGlj eSBhcyB0cnkgdGhlIGJlc3QgeW91IGNhbiB0byBzd2l0Y2ggaW4gYWxsIGNhcHR1cmUgc3RyZWFt cw0KPiBmcm9tIGEgcm9vbSB3aGVuIHRoZSByb29tIGlzIGFjdGl2ZS4gRXhhbXBsZSAgUm9vbSBB IGhhcyB0d28gY2FtZXJhcw0KPiBSb29tIEIgaGFzIHRocmVlIGNhbWVyYXMgIFJvb20gQyBoYXMg YSBzaW5nbGUgY2FtZXJhICBSb29tIEQgaGFzIHRocmVlDQo+IHNjcmVlbnMNCj4NCj4gMSkgUm9v bSBEIHJlY2VpdmVzIG1lZGlhIGZyb20gcm9vbSBBIGFuZCBDDQo+IDIpIFJvb20gQiBzdGFydHMg dGFsa2luZw0KPiAzYSkgd2l0aCBzaXRlIHN3aXRjaGluZw0KPiAgIFJvb20gRCByZWNlaXZlcyBt ZWRpYSBvbmx5IGZyb20gRCBhY3Jvc3MgYWxsIHRocmVlIHNjcmVlbnMNCj4gM2IpIHdpdGggc2Vn bWVudCBzd2l0Y2hpbmcNCj4gICBSb29tIEQgcmVjZWl2ZXMgbWVkaWEgZnJvbSBBLCBhbmQgdGhl IG5ldyBhY3RpdmUgc2VnbWVudCBmcm9tIEQNCj4NCj4gQ2hlZXJzDQo+DQo+IC1Fc3Blbg0KPg0K Pg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjbHVlLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBQYXVs IEt5eml2YXQNCj4gU2VudDogMS4gZmVicnVhciAyMDEyIDE4OjI5DQo+IFRvOiBjbHVlQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJv b2xlYW4gb3IgZGF0YQ0KPiBzdHJ1Y3R1cmUNCj4NCj4gRXNwZW4sDQo+DQo+IElTVE0gdGhhdCBm b3IgYSBzd2l0Y2hlZCBzdHJlYW0geW91IGhhdmU6DQo+IC0gdGhlIHNldCBvZiBjYW5kaWRhdGUg c3RyZWFtcyB0byBiZSBzd2l0Y2hlZCBhbW9uZw0KPiAtIGFuIGFsZ29yaXRobSBmb3IgcGlja2lu ZyBhbW9uZyB0aGVtDQo+DQo+IElmIHRoZSByZWNlaXZlciBoYXMgbXVsdGlwbGUgc2NyZWVucywg dGhlbiB0aGVyZSB3aWxsIGJlIGEgc3RyZWFtIGZvcg0KPiBlYWNoIG9uZSwgYW5kIGVhY2ggY291 bGQgaGF2ZSBkaWZmZXJlbnQgY2FuZGlkYXRlIGlucHV0IHN0cmVhbXMgYW5kIGENCj4gZGlmZmVy ZW50IHBvbGljeS4NCj4NCj4gV2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgYXMgInNpdGUgc3dpdGNo aW5nIiBhZGRzIGFub3RoZXIgd3JpbmtsZSwNCj4gc2luY2UgaXQgaXMgY291cGxpbmcgdGhlIHN3 aXRjaGluZyBwb2xpY2llcyBmb3IgbXVsdGlwbGUgc3RyZWFtcy4NCj4gQWxzbywgSSdtIG5vdCBz dXJlIGhvdyBpdCB3b3JrcyBpZiB0aGUgc2l0ZXMgaGF2ZSBkaWZmZXJpbmcgbnVtYmVycyBvZg0K PiBzY3JlZW5zIGFuZCBjYW1lcmFzLiBIb3cgd291bGQgeW91IGRlc2NyaWJlIHRoZSBpbmRpdmlk dWFsIHN0cmVhbXMNCj4gZnJvbSB0aGUgTUNVIHNvIHRoYXQgYSByb29tIGNvdWxkIHNlbGVjdCBh biBhcHByb3ByaWF0ZSBzZXQgb2Ygc3RyZWFtcw0KPiB0byBnZXQgc2l0ZSBzd2l0Y2hpbmc/DQo+ DQo+IEl0IHdvdWxkIGJlIGhlbHBmdWwgKHRvIG1lIGFueXdheSkgaWYgeW91IGNvdWxkIGRlc2Ny aWJlIHRoZQ0KPiBpbnRlcmVzdGluZyBjYXNlcyBieSBlbnVtZXJhdGluZyB0aGUgb2ZmZXJlZCBz dHJlYW1zIHRvZ2V0aGVyIHdpdGggdGhlDQo+IGlucHV0cyBhbmQgdGhlIGFsZ29yaXRobSB1c2Vk IGZvciBlYWNoLiBSaWdodCBub3csIEknbSBub3Qgc3VyZSBob3cgdG8NCj4gZG8gdGhhdC4NCj4N Cj4gICAgICAgICBUaGFua3MsDQo+ICAgICAgICAgUGF1bA0KPg0KPiBPbiAyLzEvMTIgODowMCBB TSwgRXNwZW4gQmVyZ2VyIChlc3BlYmVyZykgd3JvdGU6DQo+ID4gSSB3b3VsZCBzdGlsbCBjYWxs IGl0IHN3aXRjaC1wb2xpY3ksIGUuZy4gdGhlbiBwb3NzaWJsZSB2YWx1ZXMgY291bGQNCj4gYmU6 DQo+ID4gKiBTaXRlOiBDaGFuZ2UgYWxsIGF0IHRoZSBzYW1lIHRpbWUNCj4gPiAqIFNlZ21lbnQ6 IE9ubHkgY2hhbmdlIHRoZSBhY3RpdmUgc2VnbWVudA0KPiA+ICogUm91bmQgcm9iaW46IENoYW5n ZSBhY3RpdmUgc2VnbWVudCBhbmQgdGhlbiBjaGFuZ2UgdG8gb3RoZXINCj4gc2VnbWVudHMgaW4g MTAgc2VjIGludGVydmFscy4NCj4gPg0KPiA+IEhvdyB5b3Ugc3dpdGNoIGJldHdlZW4gc3RyZWFt cyBhbmQgaG93IHlvdSByZW5kZXIgaGFzIGRpZmZlcmVudA0KPiByZXF1aXJlbWVudHMgYW5kIHBv bGljaWVzLCBzbyBJIGZpbmQgaXQgdmVyeSB1c2VmdWwgdG8gZGlzY3VzcyB0aGVtIGFzDQo+IHR3 byBzZXBhcmF0ZSBpc3N1ZXMgdG8gYXZvaWQgY29uZnVzaW9uLg0KPiA+DQo+ID4gQ2hlZXJzDQo+ ID4NCj4gPiAtRXNwZW4NCj4gPg0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiBGcm9tOiBSb25pIEV2ZW4gW21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXQ0KPiA+ IFNlbnQ6IDEuIGZlYnJ1YXIgMjAxMiAxMTozMA0KPiA+IFRvOiBFc3BlbiBCZXJnZXIgKGVzcGVi ZXJnKTsgY2x1ZUBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBv c2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0YQ0KPiA+IHN0cnVjdHVyZQ0KPiA+DQo+ID4g SGkgRXNwZW4sDQo+ID4gSSBjYWxsZWQgc2l0ZSBvciBzZWdtZW50IHN3aXRjaCBhIHBvbGljeSBi dXQgSSBhbSBub3Qgc3VyZSB0aGF0IGl0DQo+ID4gaXMNCj4gYSBzd2l0Y2ggcG9saWN5IGJ5IGl0 c2VsZiBzaW5jZSBzZWdtZW50IHN3aXRjaCBmb3IgZXhhbXBsZSBjYW4gaGFwcGVuDQo+IGJhc2Vk IG9uIGFjdGl2ZSBzcGVha2VycyBvciBzb21lIHJvdW5kIHJvYmluIHRpbWluZyB3aGljaCBpcyB0 aGUNCj4gc3dpdGNoaW5nIHBvbGljeS4NCj4gPiBSb25pDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogRXNwZW4gQmVyZ2VyIChlc3BlYmVyZykgW21haWx0 bzplc3BlYmVyZ0BjaXNjby5jb21dDQo+ID4+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMzEsIDIw MTIgNTozOCBQTQ0KPiA+PiBUbzogUm9uaSBFdmVuOyBjbHVlQGlldGYub3JnDQo+ID4+IFN1Ympl Y3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJvb2xlYW4gb3IgZGF0 YQ0KPiA+PiBzdHJ1Y3R1cmUNCj4gPj4NCj4gPj4gSGkgUm9ueQ0KPiA+Pg0KPiA+PiBUbyBjaG9v c2UgYmV0d2VlbiBzaXRlIGFuZCBzZWdtZW50IHN3aXRjaCBpcyBtb3JlIGEgcG9saWN5IHRoYW4g YQ0KPiA+PiA8dmlkZW8tbGF5b3V0Piwgc28gaW4gdGhhdCBjYXNlIEkgd291bGQgYXJndWUgdGhh dCB5b3UgY291bGQgb2ZmZXINCj4gPj4gYSBDYXB0dXJlIHN0cmVhbSB3aXRoIGEgc3dpdGNoLXBv bGljeSA9IHtzaXRlLCBzZWdtZW50fQ0KPiA+Pg0KPiA+PiBNeSBwb2ludCBhYm91dCBpbnRlcm9w ZXJhYmlsaXR5IGlzIHRoYXQgYSBzaW5nbGUgY29tcG9zZWQgc3RyZWFtDQo+IHdpdGgNCj4gPj4g YWx0ZXJuYXRpdmUgbGF5b3V0cyBhcmUgZWFzaWVyIHRvIHVuZGVyc3RhbmQsIHRoYW4gbXVsdGlw bGUgY2FwdHVyZQ0KPiA+PiBzdHJlYW1zIHdpdGggYWx0ZXJuYXRpdmUgY29uZmlndXJhdGlvbnMu IFRoZSBsYXN0IHJlcXVpcmVzIHRvIHBpY2sNCj4gPj4gdGhlIGZpcnN0IG9uZSBvciByZXF1aXJl cyBzb21lIHNvcnQgb2YgZGVmYXVsdCBtYXJraW5nLg0KPiA+Pg0KPiA+PiBDaGVlcnMNCj4gPj4N Cj4gPj4gLUVzcGVuDQo+ID4+DQo+ID4+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IFJvbmkgRXZlbiBbbWFpbHRvOnJvbi5ldmVuLnRsdkBnbWFpbC5jb21dDQo+ ID4+IFNlbnQ6IDMxLiBqYW51YXIgMjAxMiAwMDowNg0KPiA+PiBUbzogRXNwZW4gQmVyZ2VyIChl c3BlYmVyZyk7IGNsdWVAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUkU6IFtjbHVlXSAjNzogSXMg Y29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhDQo+ID4+IHN0cnVjdHVyZQ0KPiA+ Pg0KPiA+PiBIaSBFc3BlbiwNCj4gPj4gSWYgdGhlIHByb3ZpZGVyIHdhbnRzIHRvIG9mZmVyIHNp dGUgc3dpdGNoIGFuZCBzZWdtZW50IHN3aXRjaA0KPiA+PiBvcHRpb24gdG8gdGhlIGNvbnN1bWVy IGhlIGNhbm5vdCBkbyBpdCBqdXN0IHdpdGggQS4gdGhpcyBpcyBhIGJhc2ljDQo+ID4+IHVzZQ0K PiBjYXNlLg0KPiA+Pg0KPiA+PiBJbiBnZW5lcmFsLCB5b3VyIG9wdGlvbiBkb2VzIG5vdCBwcm92 aWRlIGFueSBpbnRlcm9wZXJhYmlsaXR5IHNpbmNlDQo+ID4+IGJvdGggc2lkZXMgbWF5IGhhdmUg ZGlmZmVyZW50IHZpZXdzIHdoYXQgY29tcG9zZWQgbWVhbnMuIEluIHRoZQ0KPiA+PiBmcmFtZXdv cmsgZXhhbXBsZSBvZiBhIFBJUCBhcyBjb21wb3NlZCBpbWFnZSBpdCBpcyBhbiBhc3N1bXB0aW9u DQo+IHRoYXQNCj4gPj4gaWYgdGhlIHByb3ZpZGVyIG9mZmVycyB0aGlzIGNvbXBvc2VkIG9mZmVy LCB0aGUgY29uc3VtZXIgY2FuDQo+ID4+IHVuZGVyc3RhbmQgdGhhdCBpdCBpcyBhIFBJUCBtaXgg YnV0IHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIG9mZmVyDQo+ID4+IHRoYXQgd2lsbCBpbmRpY2F0 ZSB0aGF0IGl0IGlzLg0KPiA+Pg0KPiA+PiBSb25pDQo+ID4+DQo+ID4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogRXNwZW4gQmVyZ2VyIChlc3BlYmVyZykgW21haWx0 bzplc3BlYmVyZ0BjaXNjby5jb21dDQo+ID4+PiBTZW50OiBNb25kYXksIEphbnVhcnkgMzAsIDIw MTIgNToyMSBQTQ0KPiA+Pj4gVG86IFJvbmkgRXZlbjsgY2x1ZUBpZXRmLm9yZw0KPiA+Pj4gU3Vi amVjdDogUkU6IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBk YXRhDQo+ID4+PiBzdHJ1Y3R1cmUNCj4gPj4+DQo+ID4+PiBIaSBSb25pDQo+ID4+Pg0KPiA+Pj4g SWYgeW914oCZcmUgYSBwYXJ0aWN1bGFyIHVzZSBjYXNlcyByZXF1aXJlcyBjb250cm9sIG92ZXIg dGhlDQo+ID4+PiBjb21wb3NlZCBsYXlvdXRzIHlvdSBuZWVkIGEpIGFuZCBiKS4gSW4gbXkgZXhh bXBsZSBJIHVzZWQgYSBzaW5nbGUNCj4gPj4+IGFkdmVydGlzZW1lbnQgY29tcG9zZWQgc3RyZWFt IHdpdGggb3B0aW9uYWwgbWV0YS1pbmZvcm1hdGlvbiBhYm91dA0KPiA+Pj4gcG9zc2libGUgbGF5 b3V0IGNob2ljZXMuIEEgcmVjZWl2ZXIgdGhhdCB3YW50cyB0aGUgZGVmYXVsdA0KPiA+Pj4gY29t cG9zZWQgbGF5b3V0IGNhbiByZXF1ZXN0IHRoZSBjb21wb3NlZCBzdHJlYW0gYW5kIHNraXAgdGhl DQo+ID4+PiBvcHRpb25hbCB2aWRlby0NCj4gPj4gbGF5b3V0IGluZm9ybWF0aW9uLg0KPiA+Pj4g T3B0aW9uYWxseSB5b3UgY291bGQgcmVxdWVzdCB0aGUgc2FtZSBjb21wb3NlZCBzdHJlYW0gd2l0 aCBsYXlvdXRzDQo+ID4+PiBoaW50cyBmb3IgdGhlIHJlY2VpdmVyLg0KPiA+Pj4NCj4gPj4+IEZv ciBtZSB1c2UgY2FzZSBjKSBkb2VzIG5vdCBpbmNsdWRlIHRoZSBzZWxlY3Rpb24gbWVjaGFuaXNt cywgb25seQ0KPiA+PiB0aGUNCj4gPj4+IGNvbnRlbnQgeW91IHNlZSBpbiB0aGUgdmlkZW8gc3Ry ZWFtLg0KPiA+Pj4NCj4gPj4+IENoZWVycw0KPiA+Pj4NCj4gPj4+IC1Fc3Blbg0KPiA+Pj4NCj4g Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBSb25pIEV2ZW4gW21h aWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXQ0KPiA+Pj4gU2VudDogMzAuIGphbnVhciAyMDEy IDE1OjM5DQo+ID4+PiBUbzogRXNwZW4gQmVyZ2VyIChlc3BlYmVyZyk7IGNsdWVAaWV0Zi5vcmcN Cj4gPj4+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gIzc6IElzIGNvbXBvc2VkIGF0dHJpYnV0ZSBhIGJv b2xlYW4gb3IgZGF0YQ0KPiA+Pj4gc3RydWN0dXJlDQo+ID4+Pg0KPiA+Pj4gSGkgRXNwZW4sDQo+ ID4+PiBJZiB5b3Ugd2lsbCBsb29rIGF0IHRoZSBub3RlcyBmcm9tIHRoZSBsYXN0IGNhbGwgdGhl cmUgd2FzIGENCj4gc3VwcG9ydA0KPiA+Pj4gdGhhdCBhKSBpcyBub3QgZW5vdWdoLiBIYXZpbmcg anVzdCBjb21wb3NlIGRvZXMgbm90IGFkZHJlc3MgZXZlbg0KPiB0aGUNCj4gPj4+IHVzZSBjYXNl cyBJIHByb3ZpZGVkIHdoaWNoIGFyZSBhbHNvIGJhc2VkIG9uIHRoZSB1c2UgY2FzZSBkcmFmdC4N Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4gSSBhbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IEMgc2lu Y2Ugd2hhdCBpbiB0aGUgY29tcG9zZWQgc3RyZWFtDQo+ID4+IGNhbg0KPiA+Pj4gYmUgZWl0aGVy IHdoaWNoIFZDIHlvdSBzZWUgb3Igd2hhdCBpcyB0aGUgc2VsZWN0aW9uIGNyaXRlcmlhIGZvcg0K PiA+PiBiZWluZw0KPiA+Pj4gaW4gYSBjb21wb3NlZCBzdHJlYW0uIElmIHlvdSBtZWFudCB0aGUg c2Vjb25kLCBteSB2aWV3IGlzIHRoYXQgQw0KPiBhbmQNCj4gPj4+IGFsc28gYiBzaG91bGQgYmUg aW4gdGhlIGJhc2ljIGZyYW1ld29yayBhbmQgbm90IGluIGFuIGV4dGVuc2lvbi4NCj4gPj4+DQo+ ID4+PiBSb25pIEV2ZW4NCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4+PiBGcm9tOiBFc3BlbiBCZXJnZXIgKGVzcGViZXJnKSBbbWFpbHRvOmVzcGViZXJnQGNp c2NvLmNvbV0NCj4gPj4+PiBTZW50OiBNb25kYXksIEphbnVhcnkgMzAsIDIwMTIgNDoxNyBQTQ0K PiA+Pj4+IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSRTog W2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29sZWFuIG9yIGRhdGENCj4gPj4+ PiBzdHJ1Y3R1cmUNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gVG8gaGVscCB3aXRoIHRoZSBkaXJl Y3Rpb24gb2YgdGhlIGRpc2N1c3Npb25zIEkgdGhpbmsgaXQncyB1c2VmdWwNCj4gPj4gdG8NCj4g Pj4+PiBkaXZpZGUgdGhlIGRpc2N1c3Npb25zIGludG8gdGhyZWUgdXNlIGNhc2VzIGZvciBjb21w b3NlZCBzdHJlYW1zLg0KPiA+Pj4+ICAgYSkgSG93IHRvIGV4cHJlc3MgaWYgYSBjYXB0dXJlIHN0 cmVhbSBpcyBjb21wb3NlZCBvciBub3QNCj4gPj4+PiAgIGIpIEhvdyB0byBleHByZXNzIGxheW91 dCBjaG9pY2VzPyAoZS5nLiB3aXRoIGEgdmlkZW8tbGF5b3V0DQo+ID4+Pj4gZWxlbWVudCkNCj4g Pj4+PiAgIGMpIEhvdyB0byBleHByZXNzIHdoYXQncyBpbnNpZGUgYSBjb21wb3NlZCBzdHJlYW0N Cj4gPj4+Pg0KPiA+Pj4+IEZvciB1c2UgY2FzZSBhKSBhIGNvbXBvc2VkIGF0dHJpYnV0ZSBzaG91 bGQgYmUgc3VmZmljaWVudCwgeW91DQo+ID4+Pj4gZWl0aGVyIGFzayBmb3IgdGhlIGNvbXBvc2Vk IHN0cmVhbSBvciB5b3UgZG8gbm90Lg0KPiA+Pj4+IEkgYWxzbyBiZWxpZXZlIHRoaXMgc2hvdWxk IGNvdmVyIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHJlcXVpcmVtZW50DQo+ID4+IHdlDQo+ID4+Pj4g aGF2ZSBhY3Jvc3MgbXVsdGlwbGUgdHlwZXMgb2YgZW5kcG9pbnRzLg0KPiA+Pj4+DQo+ID4+Pj4g Rm9yIHVzZSBjYXNlIGIpIGJvdGggbWVkaWFjdHJsIGFuZCB4Y29uIHVzZXMgYTx2aWRlby1sYXlv dXQ+DQo+ID4+Pj4gZWxlbWVudCB0byBkZXNjcmliZSBwb3NzaWJsZSBsYXlvdXRzIGFuZCBhbHNv IHRvIHJlcXVlc3QgdGhlDQo+ID4+Pj4gcHJlZmVycmVkIGxheW91dCBiYXNlZCBvbiBvcHRpb25z LiAoYXMgZGVzY3JpYmVkIGluIFJvbmkncyBlbWFpbCkNCj4gPj4+Pg0KPiA+Pj4+IEFuIGV4YW1w bGUgY291bGQgYmUgKGluc3BpcmVkIGJ5IG1lZGlhY3RybCBhbmQgeGNvbiB1c2FnZSBvZg0KPiA+ PiA8dmlkZW8tDQo+ID4+Pj4gbGF5b3V0Pik6DQo+ID4+Pj4NCj4gPj4+PiBDTFVFIEFkdmVydGlz ZW1lbnQNCj4gPj4+PiAgICBDYXB0dXJlIGlkPTIgUHVycG9zZT1wZW9wbGUgQ29tcG9zZWQ9ZmFs c2UNCj4gPj4+PiAgICBDYXB0dXJlIGlkPTMgUHVycG9zZT1wZW9wbGUgQ29tcG9zZWQ9ZmFsc2UN Cj4gPj4+PiAgICBDYXB0dXJlIGlkPTQgUHVycG9zZT1QZW9wbGUgQ29tcG9zZWQ9dHJ1ZQ0KPiA+ Pj4+ICAgICAgICBWaWRlby1sYXlvdXQ9IidhdXRvbWF0aWMnLCAnZHVhbC12aWV3JywgJyBzaW5n bGUtdmlldyciDQo+ID4+Pj4NCj4gPj4+PiBDTFVFIGNvbmZpZ3VyZSAvLyBEZWZhdWx0IGNvbXBv c2VkIHN0cmVhbQ0KPiA+Pj4+ICAgIENhcHR1cmUgaWQ9NA0KPiA+Pj4+DQo+ID4+Pj4gLy8gT3Ig Y29tcG9zZWQgc3RyZWFtIHdpdGggbGF5b3V0IGhpbnRzDQo+ID4+Pj4gICAgIENhcHR1cmUgaWQ9 NCBWaWRlby1sYXlvdXQ9J2R1YWwtdmlldycNCj4gPj4+Pg0KPiA+Pj4+IFRoZSB2aWRlby1sYXlv dXQgZWxlbWVudCBpcyBhIGxpc3Qgb2Ygc3RyaW5ncyBhbmQgZWFjaCBzdHJpbmcgaXMNCj4gPj4+ PiBhIGxheW91dC1oaW50IHRoYXQgY2FuIGJlIHJlcXVlc3RlZC4gVmlkZW8tbGF5b3V0IGlzIG9w dGlvbmFsLiBBDQo+ID4+Pj4gbGF5b3V0IGhpbnRzIGFib3V0IHRoZSByZXF1ZXN0ZWQgcmVuZGVy aW5nIGFuZCB0aGUgc291cmNlIGlzIGZyZWUNCj4gPj4gdG8NCj4gPj4+PiByZXBsYWNlIGFueSBz dHJlYW0gYXMgbG9uZyBhcyB0aGV5IGZpdCB0aGUgbGF5b3V0Lg0KPiA+Pj4+DQo+ID4+Pj4gVXNl IGNhc2UgYykgaXMgbW9yZSBvcGVuIGluIHRoZSBzZW5zZSB0aGF0IHdoYXQgeW91IGFjdHVhbGx5 DQo+ID4+IHJlY2VpdmUNCj4gPj4+PiBpbiBhIGNvbXBvc2VkIHN0cmVhbSBpcyBkZXBlbmRpbmcg b24gc3RhdHVzIG9mIGEgcm9vbSBvciB3aG8gaXMNCj4gPj4+PiBpbg0KPiA+PiBhDQo+ID4+Pj4g TUNVIGNvbmZlcmVuY2UuIEUuZy4gZnJvbSBhIHJvb20geW91IGNvdWxkIGdldCBhIG1peCBvZiBk aWZmZXJlbnQNCj4gPj4+PiBjYXB0dXJlIHN0cmVhbSByZXByZXNlbnRpbmcgY2FtZXJhcyBhbmQg ZnJvbSBhIHRyYW5zY29kaW5nIE1DVSBpdA0KPiA+Pj4+IGNvdWxkIGJlIGRpZmZlcmVudCByb29t LCBkaWZmZXJlbnQgY2FtZXJhcyBvciBhbm90aGVyIG1peCBvZg0KPiA+Pj4+IHBvc3NpYmxlIGlu cHV0IHZpZGVvIHN0cmVhbXMuDQo+ID4+Pj4NCj4gPj4+PiBIYXZpbmcgc3VwcG9ydCBmb3IgYm90 aCBiKSBhbmQgYykgY291bGQgYmUgYSBnb29kIHRlc3QgZm9yIHRoZQ0KPiA+Pj4+IGV4dGVuc2li aWxpdHkgb2YgQ0xVRS4gSWYgdGhlIGJhc2lzIG9mIENMVUUgb25seSBkb2VzIHVzZSBjYXNlIGEp DQo+ID4+Pj4gdGhlcmUgc2hvdWxkIGJlIHJvb20gdG8gZXh0ZW5kIENMVUUgd2l0aCBzdXBwb3J0 IGZvciBiKSBhbmQgYykgYXMNCj4gYQ0KPiA+Pj4+IENMVUUgKyBsYXlvdXQgZGVzY3JpcHRpb24g ZXh0ZW5zaW9uLg0KPiA+Pj4+DQo+ID4+Pj4gQ2hlZXJzDQo+ID4+Pj4NCj4gPj4+PiAtRXNwZW4N Cj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+Pj4+IEZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUtYm91bmNl c0BpZXRmLm9yZ10gT24NCj4gPj4gQmVoYWxmDQo+ID4+Pj4gT2YgUm9uaSBFdmVuDQo+ID4+Pj4g U2VudDogMzAuIGphbnVhciAyMDEyIDExOjE4DQo+ID4+Pj4gVG86IGNsdWVAaWV0Zi5vcmcNCj4g Pj4+PiBTdWJqZWN0OiBSZTogW2NsdWVdICM3OiBJcyBjb21wb3NlZCBhdHRyaWJ1dGUgYSBib29s ZWFuIG9yIGRhdGENCj4gPj4+PiBzdHJ1Y3R1cmUNCj4gPj4+Pg0KPiA+Pj4+IEhpLA0KPiA+Pj4+ IER1cmluZyB0aGUgbGFzdCBjYWxsIEkgdm9sdW50ZWVyZWQgdG8gcHJvdmlkZSBzb21lIGlucHV0 Lg0KPiA+Pj4+DQo+ID4+Pj4gSW4gY3VycmVudCBJRVRGIHdvcmsgKFhDT04sIE1lZGlhY3RybCBX R3MgdGhlcmUgaXMgYSB2aWRlbyBsYXlvdXQNCj4gPj4+PiBlbGVtZW50KQ0KPiA+Pj4+DQo+ID4+ Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tZWRpYWN0cmwtbWl4ZXIt Y29udHJvbC0NCj4gPj4+IHBhY2thZ2UtDQo+ID4+Pj4gMTQjc2VjdGlvbi00LjIuMS40LjIuMQ0K PiA+Pj4+DQo+ID4+Pj4gYW5kDQo+ID4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi14Y29uLWNvbW1vbi1kYXRhLW1vZGVsLQ0KPiA+Pj4+IDMyI3NlY3Rpb24tNC4yLjcg KGxvb2sgYXQgdmlkZW8tbGF5b3V0KQ0KPiA+Pj4+DQo+ID4+Pj4gSSB3b3VsZCBsaWtlIGZpcnN0 IHRvIHRyeSB0byBkZWZpbmUgdGhlIHRlcm0gImNvbXBvc2VkIHZpZGVvIg0KPiBzaW5jZQ0KPiA+ Pj4gaXQNCj4gPj4+PiBsb29rcyB0byBtZSBsaWtlIHdlIGhhdmUgZGlmZmVyZW50IHZpZXdzIGhl cmUsIGFuZCBwcm92aWRlIG15DQo+ID4+Pj4gaW5pdGlhbCB2aWV3IG9uIHdoYXQgc2hvdWxkIGJl IGRlc2NyaWJlZC4NCj4gPj4+Pg0KPiA+Pj4+IENvbXBvc2VkIHZpZGVvIGNhbiBkZXNjcmliZXMg Ym90aCB0aGUgbGF5b3V0IGFuZCB0aGUgc2VsZWN0aW9uDQo+ID4+Pj4gYWxnb3JpdGhtIGZvciBj b21wb3NpbmcgdGhlICBjb250ZW50IG9mIHRoZSBzdWItd2luZG93cyBpbiB0aGUNCj4gPj4+ICJt aXhlZCINCj4gPj4+PiB2aWRlby4NCj4gPj4+Pg0KPiA+Pj4+IFRoZSB2aWRlbyBsYXlvdXQgd2hp Y2gganVzdCBkZXNjcmliZXMgdGhlIGdlb21ldHJ5IG9mIHRoZQ0KPiA+Pj4+IGNvbXBvc2VkIGlt YWdlIGFuZCBJIHRoaW5rIHRoYXQgdGhlIGFib3ZlIHJlZmVyZW5jZXMgcHJvdmlkZSBnb29kDQo+ ID4+Pj4gc3RydWN0dXJlIHRvIGRlZmluZSB0aGlzIHBhcnQgb2YgdGhlIGNvbXBvc2VkIHZpZGVv IGF0dHJpYnV0ZS4NCj4gPj4+Pg0KPiA+Pj4+IFRoZSBvdGhlciBwYXJ0IGlzIHRoZSBhbGdvcml0 aG0gYnkgd2hpY2ggdGhlIHByb3ZpZGVyIHNlbGVjdCB0aGUNCj4gPj4+PiBjb250ZW50IG9mIGVh Y2ggZWxlbWVudCBpbiB0aGUgbGF5b3V0LiBTaW5jZSB0aGUgY29udGVudCBvZiBlYWNoDQo+ID4+ Pj4gZWxlbWVudCBtYXkgY2hhbmdlIGR5bmFtaWNhbGx5IGJ5IHRoZSBwcm92aWRlciB0aGlzIGF0 dHJpYnV0ZQ0KPiA+Pj4+IG9ubHkgYWRkcmVzcyB0aGUgc3RhdGljIGluZm9ybWF0aW9uIHdoaWNo IGlzIHRoZSBhbGdvcml0aG0gYW5kDQo+ID4+Pj4gbm90IHRoZSBjdXJyZW50IGNvbnRlbnQgKHdo byB3ZSBzZWUgbm93IGluIGVhY2ggZWxlbWVudCkgd2hpY2gNCj4gPj4+PiB3aWxsIG5lZWQNCj4g dG8NCj4gPj4+IGJlDQo+ID4+Pj4gY29udmV5ZWQgYWxzbyBidXQgcHJvYmFibHkgbm90IHVzaW5n IHRoaXMgYXR0cmlidXRlLiBOb3RlIHRoYXQNCj4gPj4+PiB0aGUgaW5mb3JtYXRpb24gaXMgdmFs aWQgZm9yIHBvaW50IHRvIHBvaW50IGFuZCBtdWx0aXBvaW50IHNvIHRoZQ0KPiA+Pj4+IGN1cnJl bnQgY29udGVudCBzaG91bGQgcmVmbGVjdCB0aGUgVFAgZW5kIHBvaW50IGFuZCB0aGUgc3BlY2lm aWMNCj4gVkMNCj4gPj4+PiB1c2VkIGZyb20gaXQuDQo+ID4+Pj4NCj4gPj4+PiBUaGUgYWxnb3Jp dGhtcyBtYXkgYmUgZ2xvYmFsIG9yIHBlciBlbGVtZW50KG9yIHN1Yi13aW5kb3cpLiBUaGUNCj4g Pj4+IGdsb2JhbA0KPiA+Pj4+IGFsZ29yaXRobXMgSSBzZWUgYXJlIHNpdGUgc3dpdGNoIG9yIHNl Z21lbnQgc3dpdGNoLiBUaGUgcGVyDQo+IGVsZW1lbnQNCj4gPj4+PiBtYXkgYmUgdm9pY2UgYWN0 aXZhdGVkLCByb3VuZCByb2JpbiAoc3dpdGNoIGV2ZXJ5IHggc2Vjb25kcykgYW5kDQo+ID4+PiBm aXhlZA0KPiA+Pj4+ICh0aGUgc2FtZSBWQyBpcyBkaXNwbGF5ZWQgdGhlcmUgKG1heSBiZSBjaGFu Z2VkIGJ5IHNvbWUgY29udHJvbA0KPiA+Pj4+IG1lY2hhbmlzbSkNCj4gPj4+Pg0KPiA+Pj4+DQo+ ID4+Pj4gUm9uaQ0KPiA+Pj4+DQo+ID4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+Pj4+IEZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUtYm91bmNlc0Bp ZXRmLm9yZ10gT24NCj4gPj4+IEJlaGFsZg0KPiA+Pj4+PiBPZiBjbHVlIGlzc3VlIHRyYWNrZXIN Cj4gPj4+Pj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAyNCwgMjAxMiAxMjo0MyBBTQ0KPiA+Pj4+ PiBUbzogZHJhZnQtaWV0Zi1jbHVlLWZyYW1ld29ya0B0b29scy5pZXRmLm9yZzsNCj4gPj4+Pj4g bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20NCj4gPj4+Pj4gQ2M6IGNsdWVAaWV0Zi5vcmcNCj4g Pj4+Pj4gU3ViamVjdDogUmU6IFtjbHVlXSAjNzogSXMgY29tcG9zZWQgYXR0cmlidXRlIGEgYm9v bGVhbiBvciBkYXRhDQo+ID4+Pj4+IHN0cnVjdHVyZQ0KPiA+Pj4+Pg0KPiA+Pj4+PiAjNzogSXMg Y29tcG9zZWQgYXR0cmlidXRlIGEgYm9vbGVhbiBvciBkYXRhIHN0cnVjdHVyZQ0KPiA+Pj4+Pg0K PiA+Pj4+PiBDaGFuZ2VzIChieSBtYXJ5LmlldGYuYmFybmVzQOKApik6DQo+ID4+Pj4+DQo+ID4+ Pj4+ICAgKiB0eXBlOiAgZGVmZWN0ID0+ICB0YXNrDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+ IC0tDQo+ID4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLQ0KPiA+PiAtDQo+ID4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0NCj4gPj4+IC0NCj4gPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLQ0K PiA+Pj4+IC0NCj4gPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLQ0KPiA+ Pj4+PiAtLS0tDQo+ID4+Pj4+ICAgUmVwb3J0ZXI6ICBtYXJ5LmlldGYuYmFybmVzQOKApiAgfCAg ICAgICBPd25lcjogIGRyYWZ0LWlldGYtY2x1ZS0NCj4gPj4+Pj4gZnJhbWV3b3JrQOKApg0KPiA+ Pj4+PiAgICAgICBUeXBlOiAgdGFzayAgICAgICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3 DQo+ID4+Pj4+ICAgUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6 DQo+ID4+Pj4+IENvbXBvbmVudDogIGZyYW1ld29yayAgICAgICAgICAgfCAgICAgVmVyc2lvbjoN Cj4gPj4+Pj4gICBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1bWVudCAgfCAgUmVzb2x1dGlvbjoN Cj4gPj4+Pj4gICBLZXl3b3JkczogICAgICAgICAgICAgICAgICAgICAgfA0KPiA+Pj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0NCj4gPj4gLQ0K PiA+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstDQo+ID4+PiAtDQo+ID4+ Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0NCj4gPj4+PiAtDQo+ID4+Pj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0NCj4gPj4+Pj4gLS0tLQ0KPiA+Pj4+ Pg0KPiA+Pj4+PiBUaWNrZXQgVVJMOg0KPiA+Pj4+PiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvd2cvY2x1ZS90cmFjL3RpY2tldC83I2NvbW1lbnQ6Mj4NCj4gPj4+Pj4gY2x1ZTxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvd2cvY2x1ZS8+DQo+ID4+Pj4+DQo+ID4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+IGNsdWUgbWFpbGluZyBs aXN0DQo+ID4+Pj4+IGNsdWVAaWV0Zi5vcmcNCj4gPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jbHVlDQo+ID4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+IGNsdWUgbWFpbGluZyBsaXN0DQo+ ID4+Pj4gY2x1ZUBpZXRmLm9yZw0KPiA+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2x1ZQ0KPiA+Pg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGNsdWUgbWFpbGluZyBsaXN0DQo+ID4gY2x1 ZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1 ZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBjbHVlIG1haWxpbmcgbGlzdA0KPiBjbHVlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcgbGlzdA0KPiBjbHVlQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcg bGlzdA0KPiBjbHVlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2x1ZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KY2x1ZSBtYWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K From espeberg@cisco.com Wed Feb 8 15:53: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 0C99911E80B1 for ; Wed, 8 Feb 2012 15:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.042 X-Spam-Level: X-Spam-Status: No, score=-10.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 hHuV6QKPLXGP for ; Wed, 8 Feb 2012 15:53:02 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 28F9C11E8099 for ; Wed, 8 Feb 2012 15:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=3232; q=dns/txt; s=iport; t=1328745182; x=1329954782; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oD/KpgPbK7CSbofGF2E9HtUkQwUy/Y2ov0gP02WYTBM=; b=lcz35Ymla7Pfcwv18aVxqrHBl7pYjYqJ1kbUod4J01OHspw0wNzA1u6+ 3QZ9l5qBw5+TwhYcdygESV7OBv+j1Ppqod3Z0aaR0DgJKzFMFafv0nFWH W/sFG3zRizDmVfJsFwYHDWlhsFa3bZa+Sf1972CYtxsv0TnIp1Cqz5S7x o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEYKM0+Q/khL/2dsb2JhbABDrxCBB4FyAQEBAwEBAQEPAR0KNAQHBQcEAgEIEQQBAQEKBhcBBgEmHwkIAQEEEwgah1oJmkcBnkMEi0osBgEtDAKEMiUEgk1jBKgL X-IronPort-AV: E=Sophos;i="4.73,387,1325462400"; d="scan'208";a="65701171" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 08 Feb 2012 23:53:01 +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 q18Nr0aW021515; Wed, 8 Feb 2012 23:53:00 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, 9 Feb 2012 00:53:00 +0100 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, 9 Feb 2012 00:52:59 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EEC5B0C@XMB-AMS-214.cisco.com> In-Reply-To: <20120208215905.GP61963@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] VAD and speaker coordinates Thread-Index: AczmrO70/2x4Upd2T4+iddYYYAScFgACAkJA References: <4F3046C9.4060401@alum.mit.edu> <20120206234107.GH61963@verdi><44C6B6B2D0CF424AA90B6055548D7A6102FB202BEA@CRPMBOXPRD01.polycom.com> <20120208215905.GP61963@verdi> From: "Espen Berger (espeberg)" To: "John Leslie" , "Duckworth, Mark" X-OriginalArrivalTime: 08 Feb 2012 23:53:00.0902 (UTC) FILETIME=[CA4A7860:01CCE6BC] Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates 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, 08 Feb 2012 23:53:03 -0000 Are we discussing a use case where we want information about the speaker position, e.g "User Bob is in a call with Alice, Bob see that Alice is standing left in the video stream. Bob wants to hear the audio from Alice being from the left side" =20 Some comments=20 * A single audio stream is enough=20 * Without any speaker position information the default is to play out audio in the center of the video stream=20 * If dynamic speaker position is sent, you could play out the audio in the correct position=20 * Speaker position is not always possible to detect or some rooms might skip the whole thing, so it's optional.=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie Sent: 8. februar 2012 22:59 To: Duckworth, Mark Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates Duckworth, Mark wrote: > John Leslie wrote: >=20 >> "But I'd like to suggest we instead think in terms of identifying >> the physical location of the _microphone_ with greatest speech-like >> sound. That physical location is pretty easy to know; and if folks >> really care about identifying _speaker_ location, they can use more >> mikes." >=20 > I disagree. If a media provider wants to estimate the speaker (talker) > location based on which microphone has the greatest speech-like sound, > that is fine. But some microphone arrangements (along with the audio > processing algorithms) just don't work that way. Umm... > For example, microphone arrays where there is no direct constant > relationship between a microphone element and an encoded audio channel. If you're talking about the likes of Polycom HDX, I consider that a microphone "pointed" down with a time-variable pattern. Granted, "greatest speech-like sound" is hand-waving, but I think we're stuck with that problem anyway: there needs to be an algorithm to say "none of the individual mikes seem to be close to this speaker; thus we select the room-general mike". And as a sound guy, I want to know that the room-general mike is the one selected _before_ I worry about the coordinates of the actual speaker. I would likely treat the computed coordinates as a hint rather than an established fact. > So if those systems identified the location of the microphone with > greatest speech-like sound it wouldn't necessarily have any relation > to the location of the talker. Correct! > I think it is better for the media provider to estimate (usually better > than a guess!) where the talker is, using whatever method makes sense > for that provider. It is reasonable to provide that estimate in addition to the location of the room-general microphone. But IMHO, different providers will use different algorithms, and I don't see how to know the accuracy of the estimate. > We don't want the media consumer to be making incorrect assumptions > about how the provider's microphone system works. Exactly! -- John Leslie _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Feb 8 18:25: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 4F6D911E8073 for ; Wed, 8 Feb 2012 18:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.291, 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 pcwXNySuvNOk for ; Wed, 8 Feb 2012 18:25:36 -0800 (PST) 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 22AD021F8615 for ; Wed, 8 Feb 2012 18:25:35 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta14.westchester.pa.mail.comcast.net with comcast id XePx1i0020cZkys5EeRc0l; Thu, 09 Feb 2012 02:25:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta10.westchester.pa.mail.comcast.net with comcast id XeRc1i00n07duvL3WeRc26; Thu, 09 Feb 2012 02:25:36 +0000 Message-ID: <4F332E9E.7090203@alum.mit.edu> Date: Wed, 08 Feb 2012 21:25:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <068.03e705c774d30abee11ba5026a664a26@trac.tools.ietf.org> <083.6853ec8d97dcdb1adcf1dba473d6d65f@trac.tools.ietf.org> <44C6B6B2D0CF424AA90B6055548D7A6102FB301794@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB301794@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 09 Feb 2012 02:25:37 -0000 On 2/8/12 4:27 PM, Duckworth, Mark wrote: > Hi Marshall, > > I'm trying to put your proposal in perspective of some other related issues. Basically you are proposing a way for a media provider to advertise composed media captures, including a list of sources that go into the composition, right? And this could potentially be done by adding some additional attributes to media captures. (I'm using the term capture, to be consistent with the framework, where you use the term stream). > > So this would work for cases where the source list does not change often, right? Or are you thinking this would work for cases where the source list in a composed capture changes due to a change in current talker or a due to a participant joining or leaving the conference? Would you suggest the provider must advertise a media capture with new attribute values every time a change like this occurs? I was thinking that would not be practical. ISTM that you would report the set of sources that are *candidates* for composition or switching. Especially in the case of switching, the list of candidates will normally be greater than the number in the mix at any one time. At least for switching, the actual source included can be determined by examining the media. For composition it is harder. Perhaps we could say that in the case of composition, all the described sources are included. But that only partially solves the problem. There may be a case where a composition includes a source that is itself switched. Then it could be problematic to discover at any particular time which source is being shown in each portion of the composition. Thanks, Paul > This proposal sounds similar to Stephan's proposal from the discussion "Kick-Off Item 5: description of composed pictures" about three months ago. Do you see this as a subset of Stephan's proposal, without the x,y bitstream coordinates? Or do you see this as something else entirely? It seems like a subset to me. > > Separate from your proposal, which you say does not cover detailed formatting information, we could also potentially define a video-layout attribute like what Roni referred to from mediactrl and xcon. I think the two ideas could be used together. Also we could potentially add something about switching/composing policies or algorithms, of which your special character "A = active speaker" is just one example. > > Mark > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Marshall Eubanks > Sent: Tuesday, January 24, 2012 11:21 AM > To: clue issue tracker > Cc: draft-ietf-clue-framework@tools.ietf.org; clue@ietf.org > Subject: Re: [clue] #7: Is composed attribute a boolean or data structure (was: Is compose attribute a boolean or data structure) > > Here is a specific suggestion based on the discussion today : > > Composition is described by two (or more) booleans, and associated lists > > First boolean : Is the stream composed of other streams ? Yes, or no. > > Second boolean : Is this composed stream composed of other streams that the offerer is also offering. > Associated List : A list of those streams. > > This second boolean has no meaning and MUST be ignored if the first boolean is missing or negative. > > So, suppose there is a 4 screen unit (with streams 1-4), which also offers > > - Stream 5 : a composition of screens 1 and 2 > - Stream 6 : a composition of screens 3 and 4 > - Stream 7 : a composition of screens 1, 2, 3 and 4 > > So, stream 5 might have a pseudocode description like > > composed=true {composed_stream_set=true {stream_set="1,2"}} > > while stream 7 would be > > composed=true {composed_stream_set=true {stream_set="1,2,3,4"}} > > I would strongly suggest that composed streams can be nested (as indeed they are frequently in practice). > > I would also suggest two "special characters" - call them > > D == "data" > > and > > A == "active speaker" > > So, a stream 8 with > > composed=true {composed_stream_set=true {stream_set="7, A, D"}} > > would mean a composed combination of (a composition of all of the true > streams) + the screen containing the active speaker + a data screen. > > It would be useful to allow for virtual streams (i.e., maybe in my example stream "7" only exists inside the unit and is not available to others). That would make description more straightforward. It is not clear to me whether or not virtual streams should have a virtual attribute, or whether or not that can conveyed within the existing framework. Of course, dependency loops MUST be avoided. > > The "A" attribute would be most useful for middle boxes. If a composition is really coming from a 4 screen unit, then "A" may be at some remote unit, so this would be not so useful. However, if a composition is actually coming from a middle box, then A can be the speaker, and having the attribute would be useful. > > I believe that this proposal would capture essentially all of the composition use cases that do not require detailed formatting information. > > Regards > Marshall > > > > > > On Mon, Jan 23, 2012 at 5:15 PM, clue issue tracker wrote: >> #7: Is composed attribute a boolean or data structure >> >> >> -- >> --------------------------------+------------------------------------- >> --------------------------------+----- >> Reporter: mary.ietf.barnes@. | Owner: >> draft-ietf-clue-framework@. >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: framework | Version: >> Severity: Active WG Document | Resolution: >> Keywords: | >> --------------------------------+------------------------------------- >> --------------------------------+----- >> >> Ticket URL: >> >> 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 Mark.Duckworth@polycom.com Thu Feb 9 13:44: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 40E7C21E8050 for ; Thu, 9 Feb 2012 13:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.72 X-Spam-Level: X-Spam-Status: No, score=-5.72 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_05=-1.11, 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 3fS9whapJa8i for ; Thu, 9 Feb 2012 13:44:52 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id ABD3B21E8019 for ; Thu, 9 Feb 2012 13:44:52 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 9 Feb 2012 13:44:51 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 9 Feb 2012 13:44:50 -0800 Thread-Topic: Is there an existing standard for VAD? Thread-Index: Acznc8LtF/40KTQRQSy+WdRRK7crlw== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB301C0E@CRPMBOXPRD01.polycom.com> 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_44C6B6B2D0CF424AA90B6055548D7A6102FB301C0ECRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Is there an existing standard for VAD? 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, 09 Feb 2012 21:44:53 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB301C0ECRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm trying to remember what was said at the design team meeting when we tal= ked about VAD - voice activity indications and voice energy level. Is ther= e already a standard way to convey this information? Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB301C0ECRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m trying= to remember what was said at the design team meeting when we talked about = VAD – voice activity indications and voice energy level.  Is the= re already a standard way to convey this information?

 

Mark

=
= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB301C0ECRPMBOXPRD01p_-- From espeberg@cisco.com Thu Feb 9 13:56: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 BD8EA21F86A6 for ; Thu, 9 Feb 2012 13:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.111 X-Spam-Level: X-Spam-Status: No, score=-10.111 tagged_above=-999 required=5 tests=[AWL=0.487, 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 933HFMm-Z45s for ; Thu, 9 Feb 2012 13:56:20 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 564B721F86A5 for ; Thu, 9 Feb 2012 13:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=4681; q=dns/txt; s=iport; t=1328824580; x=1330034180; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=Mk7krHCb+R9hhlGKdFVN89c0bv1y1oTIwFYFXCusT4s=; b=VU7A66zGxpeLQl3/kJhqR5d3F2F1EkPQUca6gmCgB/KyyjcglOBF6fW8 70uNlum8GbwD0Ym/mNXbdes3fWO7jAYp2//sR1lTWLr8jMs56hh3T0wXP 1KB3c61tgG3zyPZhlHhmTtKPXuckaZoM5F1NpETBOCxQQQUjw4ODcVc8x U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAIxANE+Q/khN/2dsb2JhbABDgk2kTgGIQIEHgXIBAQEEEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHY5odAZ8Ei3sLFkMBJoN5EgEEAwECDYJ2YwSoEw X-IronPort-AV: E=Sophos;i="4.73,393,1325462400"; d="scan'208,217";a="129024250" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2012 21:56:19 +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 q19LuINh032381; Thu, 9 Feb 2012 21:56:19 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, 9 Feb 2012 22:56:19 +0100 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_01CCE775.A713AA64" Date: Thu, 9 Feb 2012 22:56:17 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EEC5CC6@XMB-AMS-214.cisco.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB301C0E@CRPMBOXPRD01.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Is there an existing standard for VAD? Thread-Index: Acznc8LtF/40KTQRQSy+WdRRK7crlwAAa53A References: <44C6B6B2D0CF424AA90B6055548D7A6102FB301C0E@CRPMBOXPRD01.polycom.com> From: "Espen Berger (espeberg)" To: "Duckworth, Mark" , X-OriginalArrivalTime: 09 Feb 2012 21:56:19.0011 (UTC) FILETIME=[A7407130:01CCE775] Subject: Re: [clue] Is there an existing standard for VAD? 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, 09 Feb 2012 21:56:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCE775.A713AA64 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication http://tools.ietf.org/html/rfc6464 =20 =20 -Espen=20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 9. februar 2012 22:45 To: clue@ietf.org Subject: [clue] Is there an existing standard for VAD? =20 I'm trying to remember what was said at the design team meeting when we talked about VAD - voice activity indications and voice energy level. Is there already a standard way to convey this information? =20 Mark ------_=_NextPart_001_01CCE775.A713AA64 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A Real-time Transport Protocol = (RTP) Header Extension for Client-to-Mixer Audio Level = Indication

http://tools.ietf.org/html/rfc6464

 

-Espen =

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: 9. februar 2012 22:45
To: = clue@ietf.org
Subject: [clue] Is there an existing standard = for VAD?

 

I’m trying to remember what was said at the design = team meeting when we talked about VAD – voice activity indications = and voice energy level.  Is there already a standard way to convey = this information?

 

Mark

------_=_NextPart_001_01CCE775.A713AA64-- From pkyzivat@alum.mit.edu Fri Feb 10 11: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 41F0921F87D0 for ; Fri, 10 Feb 2012 11:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 FyIXHWYpipaR for ; Fri, 10 Feb 2012 11:27:51 -0800 (PST) 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 898C021F8796 for ; Fri, 10 Feb 2012 11:27:51 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta09.westchester.pa.mail.comcast.net with comcast id YKKH1i0061wpRvQ59KTskQ; Fri, 10 Feb 2012 19:27:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id YKTr1i01q07duvL3eKTrKH; Fri, 10 Feb 2012 19:27:52 +0000 Message-ID: <4F356FB5.1090608@alum.mit.edu> Date: Fri, 10 Feb 2012 14:27:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Call for Consensus on framework spatial relationships 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, 10 Feb 2012 19:27:52 -0000 CLUE WG participants: There has been a lot of discussion about coordinate systems and spatial relationships. The editors of the framework think they have reflected the group understanding of that topic in framework-03. (This is primarily in sections 5, 6.1.1, and 6.2.1, with an example in section 11.1) This is a request for everyone who cares to indicate if they are satisfied with the treatment of this topic. If not, please specify what you object to, in a constructive way. It would be helpful to have comments by the start of the interim meeting next Wed, Feb 15, so that they can be considered during discussions there. But that may be too tight for some people traveling. So lets set a secondary target date of Monday, Feb 20. Thanks, Paul (as co-chair) From maestro@samsung.com Fri Feb 10 11:52: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 18ECD21F8608 for ; Fri, 10 Feb 2012 11:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.307 X-Spam-Level: X-Spam-Status: No, score=-5.307 tagged_above=-999 required=5 tests=[AWL=2.209, BAYES_05=-1.11, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RELAY_IS_203=0.994] 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 cnlRxGNNNkqa for ; Fri, 10 Feb 2012 11:52:44 -0800 (PST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by ietfa.amsl.com (Postfix) with ESMTP id D8A5B21F8597 for ; Fri, 10 Feb 2012 11:52:32 -0800 (PST) Received: from epcpsbgm1.samsung.com (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built Sep 7 2010)) with ESMTP id <0LZ7006AX0JI8U20@mailout3.samsung.com> for clue@ietf.org; Sat, 11 Feb 2012 04:52:30 +0900 (KST) X-AuditID: cbfee61a-b7b78ae000001ceb-7f-4f35757eb79b Received: from epmmp1.local.host ( [203.254.227.16]) by epcpsbgm1.samsung.com (MMPCPMTA) with SMTP id 63.C3.07403.E75753F4; Sat, 11 Feb 2012 04:52:30 +0900 (KST) Received: from NOMAESTRO02 ([168.219.197.174]) by mmp1.samsung.com (Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built Sep 7 2010)) with ESMTPA id <0LZ7007TL0JITB10@mmp1.samsung.com> for clue@ietf.org; Sat, 11 Feb 2012 04:52:30 +0900 (KST) From: Gyubong Oh To: clue@ietf.org Date: Sat, 11 Feb 2012 04:52:30 +0900 Message-id: <048101cce82d$85d0ae80$91720b80$@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: AczoLYGRi/uM5SFBQ+mACZSpHqIYFQ== Content-language: ko X-Brightmail-Tracker: AAAAAA== Subject: [clue] [CLUE] Use cases from my 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: Fri, 10 Feb 2012 19:52:48 -0000 Dear all, I wish you have a great new year. This is Gyubong Oh from Samsung Electronics. During the review of current use cases, I had a two topics to be considered 1. Full-duplex Presentation A. Currently, the presentation use cases only handle half-duplex interaction on presentation. B. What I think is about full-duplex interaction on presentation. C. For example, the manager and his assistant may want to draft their document on presentation under the telepresence environment. D. If both can work it in a real-time on the same document, it absolutely provides the effectiveness. E. This use case seems to increases the complexity of the CLUE framework F. However, I think there is a value to loot into this use case in the CLUE WG 2. Multiple devices (e.g. handheld, phone, PC etc) A. Current use cases handle Use case for telepresence extensions in heterogeneous and multipoint environment. REQMT-10: The solution MUST make it possible for endpoints without support for telepresence extensions to participate in a telepresence session with those that do. REQMT-11: The solution MUST support a mechanism for determining whether or not an endpoint or MCU is capable of telepresence extensions. REQMT-12: The solution MUST support a means to enable more than two sites to participate in a teleconference. B. By the way, if the user wants to get two media stream at each device (i.e. AV streams at mobile, presentation at PC), how can this work? C. My approach is i.MCU or end point can distribute it to each device or ii. the originating side establishes the separate session for each device (i.e. a session for AV streams at mobile, a session for presentation at PC) D. And I would like to be also clear whether REQMT-11 covers my approach or not. Could you provide your view on these use cases? Thanks & Best Regards, Gyubong Oh From pkyzivat@alum.mit.edu Fri Feb 10 13:04: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 9BACA21F858D for ; Fri, 10 Feb 2012 13:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 wydrdv6SdrFG for ; Fri, 10 Feb 2012 13:04:08 -0800 (PST) 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 90E6121F858A for ; Fri, 10 Feb 2012 13:04:08 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id YLr01i00416LCl053M481m; Fri, 10 Feb 2012 21:04:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta06.westchester.pa.mail.comcast.net with comcast id YM481i01N07duvL3SM48B4; Fri, 10 Feb 2012 21:04:08 +0000 Message-ID: <4F358646.4010108@alum.mit.edu> Date: Fri, 10 Feb 2012 16:04:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <4F356FB5.1090608@alum.mit.edu> In-Reply-To: <4F356FB5.1090608@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Call for Consensus on framework spatial relationships 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, 10 Feb 2012 21:04:09 -0000 (As individual) Now I get to reply to myself. I've been meaning to make these comments before but somehow didn't get to it: * Identification of independent coordinate systems Section 5 doesn't say much about this. It only says that systems without multiple media captures to be spatially associated don't need a coordinate system. This implies that captures in the same capture set should use the same coordinate system. But a capture set is limited to captures of the same media type. So audio and video captures of the same room are different capture sets. But to be related to one another they should share the same coordinate system. ISTM that Capture Scene needs to be raised to first class status, and separated from Capture Set. A coordinate system should be associated with the Scene, and then Capture Sets should be subordinated to a specific Scene. This also impacts the specification of Purpose in 6.1.1. IIUC Purpose is just an incomplete identification of scene. Specifically, it assumes that a source (room) has at most two scenes - the main one and one for presentations. This seems quite limiting: - certainly there can be multiple presentations. Each is likely to be a separate scene in that it isn't spatially related to the other. But a presentation could have both video capture and an audio capture that should be related. (Its also possible that you have a "two projector" presentation that has two video captures in a fixed relationship to one another.) - there could be multiple independent endpoints in the same room. Ideally they should share a coordinate system and an origin, so that their captures can be related. (But its also possible that they don't know about each other and don't share a coordinate system. In that case I see little alternative to treating them as separate scenes. But maybe this bears discussion.) So, I propose that: - Capture Scene becomes a first class entity, with its own attributes. The Area of Scene, and Scale attribute should belong to it, rather than to Capture Set. - each capture set should be associated with a capture scene. (an attribute is the name, or some sort of reference, to the scene.) - an endpoint may source capture sets from an arbitrary number of capture scenes - different endpoints can source capture sets from the same capture scene. (Though this may be an unusual case.) This will require some sort of naming system for scenes makes it easy for each endpoint to have some unique names, but that also allows multiple endpoints to reference some common names. The details of that are TBD. * Area of Capture (Depth?) I could swear that there was some discussion of depth of field that isn't reflected in the current text. What is there now is four points in three-space, defining a quadrilateral, but without depth. I had thought there was going to be the possibility of eight points, describing a "quadrilaterally-faced hexahedron". Did I just imagine this? A better way to do this might be to specify a quadrilateral and a camera origin, with the intent that what is included is everything in the tetrahedron specified by those five points and extending beyond until it extends beyond the area of scene. * Area of Scene Even more than area of capture, area of scene seems inadequate without being specified as a volume. 2D might work if all the captures taken from the same origin. Otherwise not so much. This could be especially obvious if you have microphones scattered throughout a large room. It also doesn't work for theater in the round. Of course its complicated to specify a room with complex geometry. But perhaps its sufficient for now to define it as a "quadrilaterally-faced hexahedron", via eight points. Thanks, Paul From ron.even.tlv@gmail.com Fri Feb 10 14:32: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 6113C21F85B8 for ; Fri, 10 Feb 2012 14:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 OL0hlhKDRlJN for ; Fri, 10 Feb 2012 14:32:47 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA0C821F85AC for ; Fri, 10 Feb 2012 14:32:46 -0800 (PST) Received: by eekc41 with SMTP id c41so1110414eek.31 for ; Fri, 10 Feb 2012 14:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=Mbt6hi4s4IXvMK+VcHjxie8g14vKjUDtQOxVSIXexBM=; b=n4tGfXPQYtlkYJmHjYjECV2/kReuq13TPDFcqMczfvsOIcaB56pnsfIcCwr+1V9hT5 l4J8vc0bdSMoDFxZHasA0tppCXPP8FzFnDXw1Ei/JhOkIvnS1kU+2GqvcE9ff0ODEoMD aUbQIjwGHmnEd0KFIkT2FUHdIKhGe/l9JvV4M= Received: by 10.14.51.9 with SMTP id a9mr2188078eec.92.1328913164304; Fri, 10 Feb 2012 14:32:44 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id n58sm27240219een.10.2012.02.10.14.32.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 14:32:43 -0800 (PST) From: "Roni Even" To: "'Paul Kyzivat'" , "'CLUE'" References: <4F356FB5.1090608@alum.mit.edu> In-Reply-To: <4F356FB5.1090608@alum.mit.edu> Date: Sat, 11 Feb 2012 00:32:24 +0200 Message-ID: <4f359b0b.d2130e0a.69f8.ffffebf1@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: AczoKhvTtpR06yPjSkmrStaQLIsNZgAGbWxg Content-Language: en-us Subject: Re: [clue] Call for Consensus on framework spatial relationships 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, 10 Feb 2012 22:32:50 -0000 HI, I made some comments in my review Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, February 10, 2012 9:28 PM > To: CLUE > Subject: [clue] Call for Consensus on framework spatial relationships > > CLUE WG participants: > > There has been a lot of discussion about coordinate systems and spatial > relationships. The editors of the framework think they have reflected > the group understanding of that topic in framework-03. (This is > primarily in sections 5, 6.1.1, and 6.2.1, with an example in section > 11.1) > > This is a request for everyone who cares to indicate if they are > satisfied with the treatment of this topic. If not, please specify what > you object to, in a constructive way. > > It would be helpful to have comments by the start of the interim > meeting next Wed, Feb 15, so that they can be considered during > discussions there. But that may be too tight for some people traveling. > So lets set a secondary target date of Monday, Feb 20. > > Thanks, > Paul (as co-chair) > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Sun Feb 12 21:35:11 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 E6BBD21F85F9 for ; Sun, 12 Feb 2012 21:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 Ez4gGH1GIKzH for ; Sun, 12 Feb 2012 21:35:09 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B63521F85E6 for ; Sun, 12 Feb 2012 21:35:08 -0800 (PST) Received: by eekc41 with SMTP id c41so1735539eek.31 for ; Sun, 12 Feb 2012 21:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:content-language:thread-index; bh=gI5+rvJTkN1CtHKAWNKBjtuEVX/WMrpZZqg4KVbFnYo=; b=MX9IDhDBv7Kpr2XpBtLX+bxiSuXbuYbgArYk41AYioXpD6CNMSvttkHIBSSquuNyrt ULm2E/cuBxn6SLwQpmIjiM/vcFvS0H1MER29Lz8OrFKwFUoOCjSgbSLG50nl5tQTrzPT kQ3yk4EDowRUeLv2FexnAx/XwTtfgSjEhjru4= Received: by 10.14.47.8 with SMTP id s8mr4905188eeb.91.1329111307791; Sun, 12 Feb 2012 21:35:07 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id v51sm57167343eef.2.2012.02.12.21.35.05 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Feb 2012 21:35:06 -0800 (PST) From: "Roni Even" To: Date: Mon, 13 Feb 2012 07:34:49 +0200 Message-ID: <4f38a10a.cb620e0a.362f.6914@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 Content-language: en-us Thread-index: Aczp1AmUqgwVw4uwRHOawgTudSIdawAPR4tg Subject: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-00.txt 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, 13 Feb 2012 05:35:11 -0000 FYI -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, February 13, 2012 12:17 AM To: ron.even.tlv@gmail.com Cc: ron.even.tlv@gmail.com Subject: New Version Notification for draft-even-clue-rtp-mapping-00.txt A new version of I-D, draft-even-clue-rtp-mapping-00.txt has been = successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-clue-rtp-mapping Revision: 00 Title: Mapping RTP streams to CLUE media captures Creation date: 2012-02-13 WG ID: Individual Submission Number of pages: 7 Abstract: This document describes mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. = =20 The IETF Secretariat From ron.even.tlv@gmail.com Mon Feb 13 03:21: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 11E7621F85AF for ; Mon, 13 Feb 2012 03:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=0.283, 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 sDLp7A2OTyRm for ; Mon, 13 Feb 2012 03:21:43 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 243B121F85B1 for ; Mon, 13 Feb 2012 03:21:42 -0800 (PST) Received: by eaal12 with SMTP id l12so1751724eaa.31 for ; Mon, 13 Feb 2012 03:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :content-language:thread-index; bh=pJY1jkyTFvUwPhzAWUfUCRGUWTgboXfosqICKWDqLu4=; b=wLe8LPzTi1vJPcLh53z1XyPv4F1ecLHHnidzGoIGXbOT5hb4rwbZwIVvPhaJ6m9X0e WqWoEHXvrV2nFmTM4wJUq/5XdqkvcQsqEbqP1SK372L/DcaH6+If7ipTVxWP5shOKcCG XSLYTYBSjnm1W1/GUqX2SP3NOUY4/GREQjogs= Received: by 10.213.9.8 with SMTP id j8mr2554103ebj.27.1329132090278; Mon, 13 Feb 2012 03:21:30 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id z47sm59994769eeh.9.2012.02.13.03.21.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 03:21:29 -0800 (PST) From: "Roni Even" To: Date: Mon, 13 Feb 2012 13:21:11 +0200 Message-ID: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01CCEA52.5C2331D0" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AczqQZbet2tZzr5TTIGnqnddD7r6fQ== Subject: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 13 Feb 2012 11:21:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003A_01CCEA52.5C2331D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, My view is that there are two separate problems that the draft discusses: 1. The co-relation between the media capture and the codec information in the offer answer 2. Multiplexing multiple media streams. I think that the second problem is addressed in http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-negotiation-00 As for the mapping I have a proposal to use a capture set group in the SDP for the ampping Roni ------=_NextPart_000_003A_01CCEA52.5C2331D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

My view is that = there are two separate problems that the draft = discusses:

 

1.       = The co-relation between = the media capture and the codec information in the offer = answer

2.       = Multiplexing multiple = media streams.

 

I think that = the second problem is addressed in http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-ne= gotiation-00

As for the mapping = I have a proposal to use a capture set group in the SDP for the = ampping

Roni

------=_NextPart_000_003A_01CCEA52.5C2331D0-- From Mark.Duckworth@polycom.com Mon Feb 13 07:47: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 CC58D21F84B5 for ; Mon, 13 Feb 2012 07:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 XiVULoE9mNI7 for ; Mon, 13 Feb 2012 07:47:20 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 09A4B21F84AA for ; Mon, 13 Feb 2012 07:47:19 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Mon, 13 Feb 2012 07:47:18 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Mon, 13 Feb 2012 07:47:16 -0800 Thread-Topic: [clue] purpose attribute - Review of framework-03 Thread-Index: AczqZdor6Y4oJ5G+QCy1B+TG8u15kw== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] purpose attribute - Review of framework-03 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, 13 Feb 2012 15:47:21 -0000 Hi Roni, Thanks for all the comments. We'll start addressing different topics in di= fferent email threads. I was thinking the media capture purpose attribute really should mean the s= ame thing as the SDP content attribute in RFC4796. Can CLUE just refer to = RFC4796 for the definition of the purpose attribute values? RFC4796 alread= y has an extension mechanism, so we can add new values when needed. Mark =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Wednesday, February 08, 2012 8:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 6. In section 6.1.1 I suggest adding one more purpose "SL" for sign langua= ge indicating that this is the sign language representation of the audio st= ream, see RFC4796. Thanks Roni Even From pkyzivat@alum.mit.edu Mon Feb 13 07:57: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 18EA321F8526 for ; Mon, 13 Feb 2012 07:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 E7TomBDgO-So for ; Mon, 13 Feb 2012 07:57:52 -0800 (PST) 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 1CEA121F8492 for ; Mon, 13 Feb 2012 07:57:51 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta13.westchester.pa.mail.comcast.net with comcast id ZTmu1i0070SCNGk5DTxs8G; Mon, 13 Feb 2012 15:57:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta09.westchester.pa.mail.comcast.net with comcast id ZTxs1i00R07duvL3VTxsFx; Mon, 13 Feb 2012 15:57:52 +0000 Message-ID: <4F3932FE.7050803@alum.mit.edu> Date: Mon, 13 Feb 2012 10:57:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> In-Reply-To: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 13 Feb 2012 15:57:53 -0000 On 2/13/12 6:21 AM, Roni Even wrote: > Hi, > > My view is that there are two separate problems that the draft discusses: > > 1.The co-relation between the media capture and the codec information in > the offer answer > > 2.Multiplexing multiple media streams. > > I think that the second problem is addressed in > http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-negotiation-00 > As for the mapping I have a proposal to use a capture set group in the > SDP for the ampping Using that solution means that there will be one or more lines in the SDP for each capture that *might* be carried. In the case of a large conference and switched streams this could potentially be hundreds of captures. I expect that having an SDP with hundreds of m-lines will likely be considered unacceptable. I presume you are assuming somehow the number of m-lines need not be so great. I guess that means that either its limited to conferences with fewer total captures, or else that the number of captures described in SDP can be very limited compared to the total number that exist. Can you elaborate your thinking? Thanks, Paul From jonathan@vidyo.com Mon Feb 13 08:08: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 7458521F8510 for ; Mon, 13 Feb 2012 08:08:20 -0800 (PST) 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=[AWL=-0.000, 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 igMZbI3zv7aT for ; Mon, 13 Feb 2012 08:08:19 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id A285821F8508 for ; Mon, 13 Feb 2012 08:08:18 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C24A8416F10; Mon, 13 Feb 2012 11:08:17 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 13DC9416F1F; Mon, 13 Feb 2012 11:08:16 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Mon, 13 Feb 2012 11:07:53 -0500 From: Jonathan Lennox To: Roni Even , "clue@ietf.org" Date: Mon, 13 Feb 2012 11:08:13 -0500 Thread-Topic: [clue] comment on draft-lennox-clue-rtp-usage-0 Thread-Index: AczqQZbet2tZzr5TTIGnqnddD7r6fQAJqSIQ Message-ID: References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> In-Reply-To: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> 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_C3759687E4991243A1A0BD44EAC823034DD493CBC2BE235maillan_" MIME-Version: 1.0 Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 13 Feb 2012 16:08:20 -0000 --_000_C3759687E4991243A1A0BD44EAC823034DD493CBC2BE235maillan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Roni - I don't think my draft discusses "codec information" at all, at least as I = understand the term, so I'm not sure quite what you mean by it. As for BUNDLE, I think it'll emerge that it doesn't work or scale well for = complicated cases (e.g., cases where you have many potential captures, or w= here a source moves between captures, or where a single source could be sen= t for more than one capture simultaneously). Also, to avoid confusion, when you say "stream," what do you mean? The ter= m (unfortunately) means very different things in SDP and in RTP - in the fo= rmer case, it's the thing identified by an m=3D line (and thus, pre-BUNDLE,= a transport flow), whereas in the latter case, it's the thing identified b= y an SSRC. So I'm not quite sure what your draft, and this e-mail, is disc= ussing. - Jonathan Lennox jonathan@vidyo.com From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Monday, February 13, 2012 6:21 AM To: clue@ietf.org Subject: [clue] comment on draft-lennox-clue-rtp-usage-0 Hi, My view is that there are two separate problems that the draft discusses: 1. The co-relation between the media capture and the codec informatio= n in the offer answer 2. Multiplexing multiple media streams. I think that the second problem is addressed in http://tools.ietf.org/html/= draft-holmberg-mmusic-sdp-bundle-negotiation-00 As for the mapping I have a proposal to use a capture set group in the SDP = for the ampping Roni --_000_C3759687E4991243A1A0BD44EAC823034DD493CBC2BE235maillan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Roni –

 

I don’t think my draft discusses R= 20;codec information” at all, at least as I understand the term, so I= ’m not sure quite what you mean by it.

 

As for BUNDLE, I think it= 217;ll emerge that it doesn’t work or scale well for complicated case= s (e.g., cases where you have many potential captures, or where a source mo= ves between captures, or where a single source could be sent for more than = one capture simultaneously).

 

= Also, to avoid confusion, when you say “= ;stream,” what do you mean?  The term (unfortunately) means very= different things in SDP and in RTP – in the former case, it’s = the thing identified by an m=3D line (and thus, pre-BUNDLE, a transport flo= w), whereas in the latter case, it’s the thing identified by an SSRC.=   So I’m not quite sure what your draft, and this e-mail, is dis= cussing.

 

–

Jonathan Lennox

<= span style=3D'color:#1F497D'>jonathan@vidyo.com

 

From: Roni Even [mailto:ron.even.tlv@gmail.c= om]
Sent: Monday, February 13, 2012 6:21 AM
To: clue@i= etf.org
Subject: [clue] comment on draft-lennox-clue-rtp-usage-0<= o:p>

 

=

Hi,

My view is that= there are two separate problems that the draft discusses:

 

1.       The co-rel= ation between the media capture and the codec information in the offer answ= er

2= .&nbs= p;      Multiplexing multiple media streams= .

 

I think that the second problem is addressed in http://tool= s.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-negotiation-00

As for the mapping I have a proposal to use a = capture set group in the SDP for the ampping

Roni

= --_000_C3759687E4991243A1A0BD44EAC823034DD493CBC2BE235maillan_-- From john@jlc.net Mon Feb 13 08:23: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 9380E21F853E for ; Mon, 13 Feb 2012 08:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.378 X-Spam-Level: X-Spam-Status: No, score=-106.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 YdSUT1WhPXjR for ; Mon, 13 Feb 2012 08:23:07 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id ADBA021F853B for ; Mon, 13 Feb 2012 08:23:07 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7600C33C2D; Mon, 13 Feb 2012 11:23:07 -0500 (EST) Date: Mon, 13 Feb 2012 11:23:07 -0500 From: John Leslie To: "Espen Berger (espeberg)" Message-ID: <20120213162307.GW61963@verdi> References: <4F3046C9.4060401@alum.mit.edu> <20120208215905.GP61963@verdi> <92DF9533227FC14F946C7321074B8C9EEC5B0C@XMB-AMS-214.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92DF9533227FC14F946C7321074B8C9EEC5B0C@XMB-AMS-214.cisco.com> User-Agent: Mutt/1.4.1i Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates 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, 13 Feb 2012 16:23:08 -0000 This really deserves a reply, but it is proving hard to write: :^( Espen Berger (espeberg) wrote: > > Are we discussing a use case where we want information about the speaker > position, e.g > > "User Bob is in a call with Alice, Bob see that Alice is standing left > in the video stream. Bob wants to hear the audio from Alice being from > the left side" It's _really_ not that simple. Having mono audio bounce between speakers will sort-of work if we're all agreed there are only two speakers. If there are more than two, it won't work at all. > Some comments > * A single audio stream is enough Enough for what? A single monophonic speaker does have the advantage of never confusing the listener by having the current speaker's position move arbitrarily... > * Without any speaker position information the default is to play out > audio in the center of the video stream Yes, that is a reasonable default. > * If dynamic speaker position is sent, you could play out the audio in > the correct position There-Ain't-No-Such-Thing-As-A "correct position". :^( We're trying to create a virtual room; and except in the trivial case where one room has half the speakers and a second room has the other half, we're reduced to asking the participants to suspend their disbelief that they're in this virtual room. For that trivial case, we can treat each set of screens as a virtual glass partition, let participants listen to the folks on their side without any amplification, and reproduce the audio which "would" pass through the partition if it weren't there. (There _will_ be some extended echo problems, but those can be managed.) Once we get past this virtual-room-in-two-pieces, we're in trouble! IMHO, we shouldn't even try to define how the audio will be managed -- but we should provide a means of passing the information which may be needed for _different_ ways of presenting the audio. One example would be to keep the "divided-room" paradigm, and add in individuals (perhaps shown in insets on one of the screens), always in the same virtual (three-dimensional) audio position, when they are speaking. (A better way, of course, would be to give them their own screen and speaker.) IMHO, the critical information is the _virtual_ position of the speaker, the actual position of the microphone, and _perhaps_ the relative actual position of the speaker to the microphone. Room acoustics is a critical part of how humans "place" a sound source; and screwing up the room acoustics to "help" them won't help. (IMHO, of course...) > * Speaker position is not always possible to detect or some rooms might > skip the whole thing, so it's optional. Agreed! -- John Leslie From jonathan@vidyo.com Mon Feb 13 08:45: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 C69A121F8745 for ; Mon, 13 Feb 2012 08:45:46 -0800 (PST) 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=[AWL=-0.000, 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 wB8DV78lU5-O for ; Mon, 13 Feb 2012 08:45:45 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF3121F8743 for ; Mon, 13 Feb 2012 08:45:45 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 24AD08BF0C9 for ; Mon, 13 Feb 2012 11:45:45 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id AB32C8BF070 for ; Mon, 13 Feb 2012 11:45:42 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Mon, 13 Feb 2012 11:45:20 -0500 From: Jonathan Lennox To: "clue@ietf.org" Date: Mon, 13 Feb 2012 11:45:28 -0500 Thread-Topic: Use case: source selection Thread-Index: AczqabZRxx4jPZOyQaiC7USGcM+8cA== Message-ID: 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_C3759687E4991243A1A0BD44EAC823034DD493CBF1BE235maillan_" MIME-Version: 1.0 Subject: [clue] Use case: source selection 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, 13 Feb 2012 16:45:46 -0000 --_000_C3759687E4991243A1A0BD44EAC823034DD493CBF1BE235maillan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As discussed, here's some draft text for my proposed use case for source se= lection for CLUE. In the use cases document, this would presumably get add= ed to section 3.3 (multipoint meetings), in the discussion of policies. In some cases an endpoint may wish to permanently view one remote camera vi= ew, while simultaneously also watching a policy-chosen view -- for example,= a participant who wants to see both the current speaker, and also the reac= tions of a specific participant (such as his or her manager, or a potential= customer) to what that speaker is saying. For this case, there would need= to be a mechanism by which an endpoint can select from among all of the po= ssible remote camera views, and indicate one to be viewed statically. -- Jonathan Lennox jonathan@vidyo.com --_000_C3759687E4991243A1A0BD44EAC823034DD493CBF1BE235maillan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As discussed, he= re’s some draft text for my proposed use case for source selection fo= r CLUE.  In the use cases document, this would presumably get added to= section 3.3 (multipoint meetings), in the discussion of policies.

 

In som= e cases an endpoint may wish to permanently view one remote camera view, wh= ile simultaneously also watching a policy-chosen view -- for example, a par= ticipant who wants to see both the current speaker, and also the reactions = of a specific participant (such as his or her manager, or a potential custo= mer) to what that speaker is saying.  For this case, there would need = to be a mechanism by which an endpoint can select from among all of the pos= sible remote camera views, and indicate one to be viewed statically.

 

-- <= o:p>

Jonathan Lennox

jonathan@vidyo.com

&nb= sp;

= --_000_C3759687E4991243A1A0BD44EAC823034DD493CBF1BE235maillan_-- From Mark.Duckworth@polycom.com Mon Feb 13 08:58: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 A13F821F84DF for ; Mon, 13 Feb 2012 08:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, 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 MUfP71Em2K3W for ; Mon, 13 Feb 2012 08:58:32 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 19CA521F8489 for ; Mon, 13 Feb 2012 08:58:31 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Mon, 13 Feb 2012 08:58:31 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 13 Feb 2012 08:58:29 -0800 Thread-Topic: RE: [clue] audio channel format - Review of framework-03 Thread-Index: AczqcKcdpB3K7tyJSxG/tsqCjqefAQ== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB302425@CRPMBOXPRD01.polycom.com> 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_44C6B6B2D0CF424AA90B6055548D7A6102FB302425CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] audio channel format - Review of framework-03 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, 13 Feb 2012 16:58:32 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB302425CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, The framework-02 version had this additional sentence about audio channel f= ormat: "TBD - other possible future values (to potentially include other things li= ke 3.0, 3.1, 5.1 surround sound and binaural)" This was just an example of other values for the attribute that could possi= bly be added in the future. So we didn't remove anything that was already = decided. A channel format of stereo means a single audio capture includes two channe= ls - left stereo channel and right stereo channel. This is not the same as= two separate mono channels. We can clarify this in the text. Mark =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Wednesday, February 08, 2012 8:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 Hi, 8. In 6.1.1 I noticed that the audio channel format attribute values change= d from previous version. I do not recall that it was discussed and that the= re was a consensus to remove the other values like 3.0, 3.1, 5.1 surround s= ound and binaural. As for the stereo value, does it represent one stereo or= two mono channels. Thanks Roni Even --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB302425CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,=

 

The framework-02 version had this additional sentence about audio chann= el format:

 

"TBD - other possible future values (to potentially= include other things like 3.0, 3.1, 5.1 surround sound and binaural)"=

 

This was just an example of other values for the attribute that co= uld possibly be added in the future.  So we didn't remove anything tha= t was already decided.

 

A channel format of stereo means a single au= dio capture includes two channels - left stereo channel and right stereo ch= annel.  This is not the same as two separate mono channels.  We c= an clarify this in the text.

&nb= sp;

Mark

 

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

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

Sent: Wednesday, February 08, 2012 8:49 AM

=

To: clue@ietf.org

Subject: [clue] Review of draft-ietf-clue-framework-03

<= p class=3DMsoPlainText> 

Hi,

 

8. In 6.1.1 I noticed that the audio channel format attribute values c= hanged from previous version. I do not recall that it was discussed and tha= t there was a consensus to remove the other values like 3.0, 3.1, 5.1 surro= und sound and binaural. As for the stereo value, does it represent one ster= eo or two mono channels.

 <= /o:p>

Thanks

Roni Even

 

= = --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB302425CRPMBOXPRD01p_-- From ron.even.tlv@gmail.com Mon Feb 13 10:01: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 D035A21F866C for ; Mon, 13 Feb 2012 10:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=0.268, 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 2o7+Z3TyanwC for ; Mon, 13 Feb 2012 10:01:03 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBCEF21F86C5 for ; Mon, 13 Feb 2012 10:01:02 -0800 (PST) Received: by eaal12 with SMTP id l12so1870424eaa.31 for ; Mon, 13 Feb 2012 10:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:content-language:thread-index; bh=pnLg+XtRudDDabUXpE495Uo4CJaD66ghZ6X4dkhwVjI=; b=rRyQ4bnaqU6Hqh8xPaZO/Peg1e1P7n2DI1RHarw+Szy3JqxqZ/HP3JqVHICBdWAoko iqTwveI/q4gc/32T1mo6yuA+VChumT34a8CyfHWADTU6pLvONgZGsnDh/MZ9jkFeCzfl 5AmDuuUA5sU2Cc2pr+S9plcSsPmHGNAQ7WaXc= Received: by 10.14.48.7 with SMTP id u7mr5434391eeb.89.1329156056564; Mon, 13 Feb 2012 10:00:56 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id n52sm3970498eea.5.2012.02.13.10.00.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 10:00:55 -0800 (PST) From: "Roni Even" To: "'Jonathan Lennox'" , References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> In-Reply-To: Date: Mon, 13 Feb 2012 20:00:28 +0200 Message-ID: <4f394fd7.4c200e0a.14fd.ffffc4b2@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01CCEA8A.23A42C50" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AczqQZbet2tZzr5TTIGnqnddD7r6fQAJqSIQAANSx7A= Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 13 Feb 2012 18:01:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0066_01CCEA8A.23A42C50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jonathan, First to clarify, when I say media capture I refer to the CLUE description on the semantics of the data. Stream is the RTP stream. In SDP I do not differentiate between the case where you have an m-line for each RTP media stream or you multiplex them using SSRC. The bundle draft still has an m-line for each RTP stream. The difference is that without bundle they each one is an RTP session while in the bundle case at least for now they are all part of the same RTP session. Now I am not sure what you mean when you are talking about hundreds of descriptions. In the point to point the number of RTP streams described in the SDP should probably be the number of media captures in the capture set entry with the largest number of MCs, see the draft I submitted yesterday. In the multipoint case I assume that we are only talking about an MCU that serves as a central signaling point and not about some distributed signaling. In this case the MCU receives all MCs and the SDP from all end point it needs to provide all MCs if it wants but as for the SDP it only need to provide the number of m-lines (using bundle) that will allow him to send and receive the maximum that the end point will receive simultaneously. The content of each of these RTP streams or channels will change based on the current configured capture set entry. For example in your 2 out of three the number of m-lines or RTP streams will be two. The content inside will change using the SSRC to identify the specific one. BTW: I think that it will work better if all three VC use the same codec. I do not see an endpoint receiving hundreds of streams or a large full mesh conference as a valid use case. In your draft you do not address the relation between the codec information (What I mean is all the codec parameters in the m-line) but they exist and need to be conveyed to the consumer with the realtion to the MC to allow the consumer to know what he is currently receiving. Roni From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: Monday, February 13, 2012 6:08 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0 Hi, Roni - I don't think my draft discusses "codec information" at all, at least as I understand the term, so I'm not sure quite what you mean by it. As for BUNDLE, I think it'll emerge that it doesn't work or scale well for complicated cases (e.g., cases where you have many potential captures, or where a source moves between captures, or where a single source could be sent for more than one capture simultaneously). Also, to avoid confusion, when you say "stream," what do you mean? The term (unfortunately) means very different things in SDP and in RTP - in the former case, it's the thing identified by an m= line (and thus, pre-BUNDLE, a transport flow), whereas in the latter case, it's the thing identified by an SSRC. So I'm not quite sure what your draft, and this e-mail, is discussing. - Jonathan Lennox jonathan@vidyo.com From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Monday, February 13, 2012 6:21 AM To: clue@ietf.org Subject: [clue] comment on draft-lennox-clue-rtp-usage-0 Hi, My view is that there are two separate problems that the draft discusses: 1. The co-relation between the media capture and the codec information in the offer answer 2. Multiplexing multiple media streams. I think that the second problem is addressed in http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-negotiation-00 As for the mapping I have a proposal to use a capture set group in the SDP for the ampping Roni ------=_NextPart_000_0066_01CCEA8A.23A42C50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

First to clarify, when I = say media capture I refer to the CLUE description on the semantics of = the data. Stream is the RTP stream. In SDP I do not differentiate = between the case where you have an m-line for each RTP media stream or = you multiplex them using SSRC. The bundle draft still has an m-line for = each RTP stream. The difference is that without bundle they each one is = an RTP session while in the bundle case at least for now they are all = part of the same RTP session.

 

Now I am not sure what = you mean when you are talking about hundreds of = descriptions.

In the point to point the number of RTP streams = described in the SDP should probably be the number of media captures in = the capture set entry with the largest number of MCs, see the draft I = submitted yesterday.

In the multipoint case I assume that we are only = talking about an MCU that serves as a central signaling point and not = about some distributed signaling. In this case the MCU receives all MCs = and the SDP from all end point it needs to provide all MCs if it wants = but as for the SDP it only need to provide the number of m-lines (using = bundle) that will allow him to send and receive the maximum that the end = point will receive simultaneously. The content of each of these RTP = streams or channels will change based on the current configured capture = set entry. For example in your 2 out of three the number of m-lines or = RTP streams will be two. The content inside will change using the SSRC = to identify the specific one. BTW: I think that it will work better if = all three VC use the same codec.

I do not see an endpoint = receiving hundreds of streams or a large full mesh conference as a valid = use case.

 

In your draft you do not = address the relation between the codec information (What I mean is all = the codec parameters in the m-line) but they exist and need to be = conveyed to the consumer with the realtion to the MC to allow the = consumer to know what he is currently receiving.

 

Roni

 

From:= = Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: Monday, = February 13, 2012 6:08 PM
To: Roni Even; = clue@ietf.org
Subject: RE: [clue] comment on = draft-lennox-clue-rtp-usage-0

 

Hi, Roni –

 

I don’t think my = draft discusses “codec information” at all, at least as I = understand the term, so I’m not sure quite what you mean by = it.

 

As for BUNDLE, I think = it’ll emerge that it doesn’t work or scale well for = complicated cases (e.g., cases where you have many potential captures, = or where a source moves between captures, or where a single source could = be sent for more than one capture = simultaneously).

 

Also, to avoid = confusion, when you say “stream,” what do you mean?  = The term (unfortunately) means very different things in SDP and in RTP = – in the former case, it’s the thing identified by an m=3D = line (and thus, pre-BUNDLE, a transport flow), whereas in the latter = case, it’s the thing identified by an SSRC.  So I’m not = quite sure what your draft, and this e-mail, is = discussing.

 

– =

Jonathan Lennox

jonathan@vidyo.com

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]=
Sent: Monday, February 13, 2012 6:21 AM
To: clue@ietf.org
Subject: = [clue] comment on = draft-lennox-clue-rtp-usage-0

 

Hi,

My view is that = there are two separate problems that the draft = discusses:

 

1.       The = co-relation between the media capture and the codec information in the = offer answer

2.       Multiplexing = multiple media streams.

 

I think that = the second problem is addressed in http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-ne= gotiation-00

As for the mapping = I have a proposal to use a capture set group in the SDP for the = ampping

Roni

------=_NextPart_000_0066_01CCEA8A.23A42C50-- From pkyzivat@alum.mit.edu Mon Feb 13 10:16:15 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 76EDB21F873E for ; Mon, 13 Feb 2012 10:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 7UvD6ef9vDtV for ; Mon, 13 Feb 2012 10:16:14 -0800 (PST) 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 3BE0921F873C for ; Mon, 13 Feb 2012 10:16:09 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta06.westchester.pa.mail.comcast.net with comcast id ZU1R1i0051ap0As56WG9t9; Mon, 13 Feb 2012 18:16:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id ZWG91i00907duvL3iWG9yT; Mon, 13 Feb 2012 18:16:09 +0000 Message-ID: <4F395367.8050504@alum.mit.edu> Date: Mon, 13 Feb 2012 13:16:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> <4f394fd7.4c200e0a.14fd.ffffc4b2@mx.google.com> In-Reply-To: <4f394fd7.4c200e0a.14fd.ffffc4b2@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 13 Feb 2012 18:16:15 -0000 Roni - at end On 2/13/12 1:00 PM, Roni Even wrote: > Hi Jonathan, > > First to clarify, when I say media capture I refer to the CLUE > description on the semantics of the data. Stream is the RTP stream. In > SDP I do not differentiate between the case where you have an m-line for > each RTP media stream or you multiplex them using SSRC. The bundle draft > still has an m-line for each RTP stream. The difference is that without > bundle they each one is an RTP session while in the bundle case at least > for now they are all part of the same RTP session. > > Now I am not sure what you mean when you are talking about hundreds of > descriptions. > > In the point to point the number of RTP streams described in the SDP > should probably be the number of media captures in the capture set entry > with the largest number of MCs, see the draft I submitted yesterday. > > In the multipoint case I assume that we are only talking about an MCU > that serves as a central signaling point and not about some distributed > signaling. In this case the MCU receives all MCs and the SDP from all > end point it needs to provide all MCs if it wants but as for the SDP it > only need to provide the number of m-lines (using bundle) that will > allow him to send and receive the maximum that the end point will > receive simultaneously. The content of each of these RTP streams or > channels will change based on the current configured capture set entry. > For example in your 2 out of three the number of m-lines or RTP streams > will be two. The content inside will change using the SSRC to identify > the specific one. BTW: I think that it will work better if all three VC > use the same codec. > > I do not see an endpoint receiving hundreds of streams or a large full > mesh conference as a valid use case. Suppose we have an MCU with many (e.g. hundreds) of captures coming into it. And then suppose the MCU wants to advertise a switched capture that switches among all of those. IIUC, you would represent that as a single m-line for the switched capture, but with any one of the many SSRCs indicating which capture was being sent at any given time. But then how does the recipient discover which of the switched captures it is receiving? And how does it sort out which SSRCs correspond to the switched capture, vs. others that correspond to other captures in the capture set mapped to the same RTP addr/port? Thanks, Paul From Mark.Duckworth@polycom.com Mon Feb 13 10:23: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 DFEB821F8758 for ; Mon, 13 Feb 2012 10:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 lfmduiGeEROb for ; Mon, 13 Feb 2012 10:23:40 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 48FCB21F8714 for ; Mon, 13 Feb 2012 10:23:39 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 13 Feb 2012 10:23:39 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Mon, 13 Feb 2012 10:23:38 -0800 Thread-Topic: [clue] MC -> multiple streams - Review of framework-03 Thread-Index: Aczqe+0S6ZD2JJVhRoywnX9oDv1guA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB3024D4@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] MC -> multiple streams - Review of framework-03 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, 13 Feb 2012 18:23:41 -0000 Hi Roni, A media capture may be encoded into multiple streams simultaneously, perhap= s with different codecs or different encoding parameters. For example simu= lcast of a video capture at CIF and 1080p resolutions. Each of those could= be a different stream. >From section 8 of the draft framework-03: "If there are multiple individual encodings in the group, then a single med= ia capture can be encoded into multiple different streams at the same time,= with each stream following the constraints of a different individual encod= ing." Mark =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Wednesday, February 08, 2012 8:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 1. In section 3 the definition of media capture say "A Media Capture (MC) m= ay be the source of one or more Media streams."=A0 What is the "more" in th= is case. Can you explain since my understanding of a media capture is that = is one stream, can you give an example. Thanks Roni Even From bbaldino@cisco.com Mon Feb 13 10:36: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 78FEF21F87C5 for ; Mon, 13 Feb 2012 10:36:07 -0800 (PST) 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 vBb5W+6lm7pa for ; Mon, 13 Feb 2012 10:36:05 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9252E21F87C4 for ; Mon, 13 Feb 2012 10:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=11093; q=dns/txt; s=iport; t=1329158165; x=1330367765; h=mime-version:subject:date:message-id:from:to; bh=fja+drMOpaY6kXSWrDqkWbWsrjNilK8icdRCFl82Vb0=; b=aCfcUulj07L89Vk8q0KL+oRrwEqeCFEEG1J0zqOyUMUBCERV2Sqtfn1S r8w9wjWfdBSALF/7lKqmUSdoRmRHiyGxPo5SkUkzbj2dkYkYdgDpxybia X0Gw0iuuxYW6wb4mC2ka11AxbTyoWwexYmCt5s7cbDtik965TaO15fBLZ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAORXOU+rRDoH/2dsb2JhbABDglGtQ4EHgXIBAQEEEgEJEQNCGQEIDgMEAQELBhcBB0UJCQEEARIIGqUHAZZ2i0YIGgMJAwcEPhoCBAIEgyABMoNNYwSISp9t X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="scan'208,217";a="30189499" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 13 Feb 2012 18:36:05 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1DIa416015717; Mon, 13 Feb 2012 18:36:05 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, 13 Feb 2012 10:36:04 -0800 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_01CCEA7E.5776DF79" Date: Mon, 13 Feb 2012 10:36:03 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Spatial information - Review of draft-ietf-clue-framework-03 Thread-Index: AczqflaBKakYMuZXS4ChqE3TJmyEiQ== From: "Brian Baldino (bbaldino)" To: "Roni Even" , X-OriginalArrivalTime: 13 Feb 2012 18:36:04.0589 (UTC) FILETIME=[57C021D0:01CCEA7E] Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-framework-03 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, 13 Feb 2012 18:36:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCEA7E.5776DF79 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Roni, Was wondering if you could clarify what you mean here: The coordinate units are first discussed in section 4. The currents units which I am OK with are the mm and no unknown. The no scale as far as I understand provide units in the coordinates system that allows the provider to define a spatial order that the consumer will use to render, this option can be used for example by a MCU. I think that we can add two more units. The first is "no spatial information" this will allow the provider to leave it to the consumer to decide what order to use. The second is "priority" this is still no spatial relation between the media captures but the provider can use it to specify which media captures are more important allowing the consumer to select between media captures. =20 You mention two scales but the framework currently allows for three scales: mm, unknown and no scale...would having these 3 options address your first point? I'm not sure what you're looking for when you describe allowing the consumer to decide what order to use. Also, as far as priority, that seems like something that should be separate from the spatial information...do you think it belongs with the spatial stuff or perhaps we can address it somewhere else? -Brian From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, February 08, 2012 5:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 =20 The coordinate units are first discussed in section 4. The currents units which I am OK with are the mm and no unknown. The no scale as far as I understand provide units in the coordinates system that allows the provider to define a spatial order that the consumer will use to render, this option can be used for example by a MCU. I think that we can add two more units. The first is "no spatial information" this will allow the provider to leave it to the consumer to decide what order to use. The second is "priority" this is still no spatial relation between the media captures but the provider can use it to specify which media captures are more important allowing the consumer to select between media captures. =20 Thanks Roni Even =20 =20 =20 ------_=_NextPart_001_01CCEA7E.5776DF79 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Roni,

Was wondering if you could clarify what you mean = here:

The = coordinate units are first discussed in section 4. The currents units = which I am OK with are the mm and no unknown. The no scale as far as I = understand provide units in the coordinates system that allows the = provider to define a spatial order that the consumer will use to render, = this option can be used for example by a MCU. I think that we can add = two more units. The first is “no spatial information” this = will allow the provider to leave it to the consumer to decide what order = to use. The second is “priority” this is still no spatial = relation between the media captures but the provider can use it to = specify which media captures are more important allowing the consumer to = select between media captures.

 

You mention two scales but the framework currently = allows for three scales: mm, unknown and no scale...would having these 3 = options address your first point?  I’m not sure what = you’re looking for when you describe allowing the consumer to = decide what order to use.

Also, as far as priority, that seems like something = that should be separate from the spatial information...do you think it = belongs with the spatial stuff or perhaps we can address it somewhere = else?

-Brian

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Wednesday, February 08, 2012 5:49 = AM
To: clue@ietf.org
Subject: [clue] Review of = draft-ietf-clue-framework-03

 =

The = coordinate units are first discussed in section 4. The currents units = which I am OK with are the mm and no unknown. The no scale as far as I = understand provide units in the coordinates system that allows the = provider to define a spatial order that the consumer will use to render, = this option can be used for example by a MCU. I think that we can add = two more units. The first is “no spatial information” this = will allow the provider to leave it to the consumer to decide what order = to use. The second is “priority” this is still no spatial = relation between the media captures but the provider can use it to = specify which media captures are more important allowing the consumer to = select between media captures.

 =

Thanks=

Roni = Even

 =

 =

 

------_=_NextPart_001_01CCEA7E.5776DF79-- From ron.even.tlv@gmail.com Mon Feb 13 10:46: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 E89C521F8712 for ; Mon, 13 Feb 2012 10:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 6UqM7Tuxugkn for ; Mon, 13 Feb 2012 10:46:17 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92CCB21F8721 for ; Mon, 13 Feb 2012 10:46:16 -0800 (PST) Received: by eekc41 with SMTP id c41so1964294eek.31 for ; Mon, 13 Feb 2012 10:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:content-language :thread-index; bh=YAeh9lGeFyvEWqu7gVR++IJ15PMtV0ZD0WeRiabEuGI=; b=XxxdLxxf5U2frPsFWqOTlGshcdxWNsiQteDEsbja7jgIX9rFg1gxRGPGKW1N1YCM45 VyyrYGHwRWJtLopGgDSaSgZlW2fHelLnxxgtaRbFGHbOL3/6xNTHQtxljXivuy+5CVsv /yTmC1TVHHb2uz09n2LFpajYlfexjX0hPdrWI= Received: by 10.14.51.9 with SMTP id a9mr5244237eec.92.1329158775704; Mon, 13 Feb 2012 10:46:15 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id n17sm63789961eei.3.2012.02.13.10.46.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 10:46:14 -0800 (PST) From: "Roni Even" To: "'Paul Kyzivat'" , References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> <4f394fd7.4c200e0a.14fd.ffffc4b2@mx.google.com> <4F395367.8050504@alum.mit.edu> In-Reply-To: <4F395367.8050504@alum.mit.edu> Date: Mon, 13 Feb 2012 20:45:48 +0200 Message-ID: <4f395a76.11840e0a.1d12.ffffac02@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 Content-language: en-us Thread-index: Aczqe5ZGi6oDAfqlSqO0pxF0Yqb3YQABBIOw Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 13 Feb 2012 18:46:18 -0000 Hi Paul, This is what the conference event package is for Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Monday, February 13, 2012 8:16 PM > To: clue@ietf.org > Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > Roni - at end > > On 2/13/12 1:00 PM, Roni Even wrote: > > Hi Jonathan, > > > > First to clarify, when I say media capture I refer to the CLUE > > description on the semantics of the data. Stream is the RTP stream. > In > > SDP I do not differentiate between the case where you have an m-line > > for each RTP media stream or you multiplex them using SSRC. The > bundle > > draft still has an m-line for each RTP stream. The difference is that > > without bundle they each one is an RTP session while in the bundle > > case at least for now they are all part of the same RTP session. > > > > Now I am not sure what you mean when you are talking about hundreds > of > > descriptions. > > > > In the point to point the number of RTP streams described in the SDP > > should probably be the number of media captures in the capture set > > entry with the largest number of MCs, see the draft I submitted > yesterday. > > > > In the multipoint case I assume that we are only talking about an MCU > > that serves as a central signaling point and not about some > > distributed signaling. In this case the MCU receives all MCs and the > > SDP from all end point it needs to provide all MCs if it wants but as > > for the SDP it only need to provide the number of m-lines (using > > bundle) that will allow him to send and receive the maximum that the > > end point will receive simultaneously. The content of each of these > > RTP streams or channels will change based on the current configured > capture set entry. > > For example in your 2 out of three the number of m-lines or RTP > > streams will be two. The content inside will change using the SSRC to > > identify the specific one. BTW: I think that it will work better if > > all three VC use the same codec. > > > > I do not see an endpoint receiving hundreds of streams or a large > full > > mesh conference as a valid use case. > > Suppose we have an MCU with many (e.g. hundreds) of captures coming > into it. > > And then suppose the MCU wants to advertise a switched capture that > switches among all of those. > > IIUC, you would represent that as a single m-line for the switched > capture, but with any one of the many SSRCs indicating which capture > was being sent at any given time. > > But then how does the recipient discover which of the switched captures > it is receiving? And how does it sort out which SSRCs correspond to the > switched capture, vs. others that correspond to other captures in the > capture set mapped to the same RTP addr/port? > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Mon Feb 13 11:30:47 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 DF7F521E8011 for ; Mon, 13 Feb 2012 11:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Op5TsxeIO8mX for ; Mon, 13 Feb 2012 11:30:47 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0585A21E8010 for ; Mon, 13 Feb 2012 11:30:46 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 13 Feb 2012 11:30:46 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Mon, 13 Feb 2012 11:30:44 -0800 Thread-Topic: [clue] Review of draft-ietf-clue-framework-03 Thread-Index: AczmaGdy5PVDLQ8nRHK9EFLGxp4ZMQEG6rxA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB302559@CRPMBOXPRD01.polycom.com> References: <4f327d59.d2130e0a.3e4f.ffffe95a@mx.google.com> In-Reply-To: <4f327d59.d2130e0a.3e4f.ffffe95a@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Review of draft-ietf-clue-framework-03 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, 13 Feb 2012 19:30:48 -0000 Hi Roni, I think your example is this: A provider wants to advertise that it can provide a capture with voice acti= vated switching, or it can provide a capture that switches every 10 seconds= , but not both at the same time, is that right? This is related to the ticket #7 discussion of how to distinguish between t= hese two different switching policies. That discussion leads to two possib= ilities of how a provider can advertise this: Possibility 1: advertise a single media capture with a "switch policy" attr= ibute with (loudest talker, round robin) values, and the consumer can pick = which one it wants. Possibility 2: advertise a media capture with a "switch policy" attribute w= ith (loudest talker); and advertise another media capture with a "switch po= licy" attribute with (round robin). Then to indicate it can't send them bo= th at once, the provider must also advertise simultaneous sets that do not = have these two media captures in the same set, or it can advertise them bot= h with the same encoding group that has only a single individual encoding i= n it. Possibility 1 seems a lot simpler for both provider and consumer to deal wi= th. Does this address your idea about this constraint? Mark =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Wednesday, February 08, 2012 8:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 14. In section 6.3 I think that there is a third type of constrain based on= what is called concept in section 6.1. The provider can send a voice activ= ated video switch content or switch between the MCs every 10 seconds. Thanks Roni Even From Mark.Duckworth@polycom.com Mon Feb 13 11:33: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 82E8C21E8014 for ; Mon, 13 Feb 2012 11:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 LG4E194rfMLj for ; Mon, 13 Feb 2012 11:33:32 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5821E8010 for ; Mon, 13 Feb 2012 11:33:32 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 13 Feb 2012 11:33:32 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Mon, 13 Feb 2012 11:33:31 -0800 Thread-Topic: [clue] Policy constraints - Review of framework-03 Thread-Index: Aczqhk49MZsiDP4kRDaEIWTtrdq65A== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB30255E@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Policy constraints - Review of framework-03 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, 13 Feb 2012 19:33:33 -0000 Sorry, I should have put a more descriptive subject line Mark -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: Monday, February 13, 2012 2:31 PM To: Roni Even; clue@ietf.org Subject: Re: [clue] Review of draft-ietf-clue-framework-03 Hi Roni, I think your example is this: A provider wants to advertise that it can provide a capture with voice acti= vated switching, or it can provide a capture that switches every 10 seconds= , but not both at the same time, is that right? This is related to the ticket #7 discussion of how to distinguish between t= hese two different switching policies. That discussion leads to two possib= ilities of how a provider can advertise this: Possibility 1: advertise a single media capture with a "switch policy" attr= ibute with (loudest talker, round robin) values, and the consumer can pick = which one it wants. Possibility 2: advertise a media capture with a "switch policy" attribute w= ith (loudest talker); and advertise another media capture with a "switch po= licy" attribute with (round robin). Then to indicate it can't send them bo= th at once, the provider must also advertise simultaneous sets that do not = have these two media captures in the same set, or it can advertise them bot= h with the same encoding group that has only a single individual encoding i= n it. Possibility 1 seems a lot simpler for both provider and consumer to deal wi= th. Does this address your idea about this constraint? Mark =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Wednesday, February 08, 2012 8:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 14. In section 6.3 I think that there is a third type of constrain based on= what is called concept in section 6.1. The provider can send a voice activ= ated video switch content or switch between the MCs every 10 seconds. Thanks Roni Even _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Tue Feb 14 09:17: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 49E2821F849D for ; Tue, 14 Feb 2012 09:17:53 -0800 (PST) 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 ufVO3hrYMeG4 for ; Tue, 14 Feb 2012 09:17:52 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id BA8C121F8489 for ; Tue, 14 Feb 2012 09:17:51 -0800 (PST) Received: by qan41 with SMTP id 41so408400qan.10 for ; Tue, 14 Feb 2012 09:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=KHaDvXEIYtgsL02NKFSLEGM5Lm56GaPvnogPwGpexUQ=; b=CBeVaQs7nyT/yFlcBA1F0dVOduDU86oVFGie72naXWselZYlA97auc64XfqPXamptf Blc8JDiJ3DfM/92/9V/ABjjnWs0RjT91oylaQZ92ruSKfoUsDt7qsMJyATYmOoifFeXW M64+U/P+QDFTmdx8yFZH2fkIubpZoUqFSutd0= Received: by 10.229.105.195 with SMTP id u3mr3522012qco.82.1329239871186; Tue, 14 Feb 2012 09:17:51 -0800 (PST) Received: from windows8d787f9 (75-147-4-157-NewEngland.hfc.comcastbusiness.net. [75.147.4.157]) by mx.google.com with ESMTPS id eo4sm4511542qab.16.2012.02.14.09.17.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Feb 2012 09:17:49 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB3024D4@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB3024D4@CRPMBOXPRD01.polycom.com> Date: Tue, 14 Feb 2012 19:17:34 +0200 Message-ID: <4f3a973d.84c6e00a.2c4e.7a0b@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: Aczqe+0S6ZD2JJVhRoywnX9oDv1guAAwEcqA Content-Language: en-us Subject: Re: [clue] MC -> multiple streams - Review of framework-03 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, 14 Feb 2012 17:17:53 -0000 Hi Mark, So do you see that the capture set may include a MC with a simulcast and = a different one with just one RTP stream. I think that goes to the = discussion we are having on mapping the SDP information to the MCs Roni > -----Original Message----- > From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > Sent: Monday, February 13, 2012 8:24 PM > To: Roni Even; clue@ietf.org > Subject: RE: [clue] MC -> multiple streams - Review of framework-03 >=20 > Hi Roni, >=20 > A media capture may be encoded into multiple streams simultaneously, > perhaps with different codecs or different encoding parameters. For > example simulcast of a video capture at CIF and 1080p resolutions. > Each of those could be a different stream. >=20 > From section 8 of the draft framework-03: > "If there are multiple individual encodings in the group, then a = single > media capture can be encoded into multiple different streams at the > same time, with each stream following the constraints of a different > individual encoding." >=20 > Mark >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Roni Even > Sent: Wednesday, February 08, 2012 8:49 AM > To: clue@ietf.org > Subject: [clue] Review of draft-ietf-clue-framework-03 >=20 > 1. In section 3 the definition of media capture say "A Media Capture > (MC) may be the source of one or more Media streams."=A0 What is the > "more" in this case. Can you explain since my understanding of a media > capture is that is one stream, can you give an example. >=20 > Thanks > Roni Even >=20 From ron.even.tlv@gmail.com Tue Feb 14 09: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 EF87621F85E7 for ; Tue, 14 Feb 2012 09:25:04 -0800 (PST) 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=[AWL=-0.001, 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 xIq7kG28XoFF for ; Tue, 14 Feb 2012 09:25:02 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF39E21F85F2 for ; Tue, 14 Feb 2012 09:25:02 -0800 (PST) Received: by qcsq5 with SMTP id q5so139921qcs.31 for ; Tue, 14 Feb 2012 09:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=lA8u+6+Hv047S2/C5AIEUrR9eeSb+sKWBbhca5hQQyo=; b=Cyb2GzmWeX1mgNy/RpiPBZiUG165DPyVpB/3LQDV0VX2fwP+7geQ2AXEsByiIiceyS Hmo4uoDox1lYQJ1mAgywrddKbkFLX0D7vV+FFO/iPfJR6ve4Bc2iT+7hAcTfEjdLqgLE H75kKYrbWBItDnixc5UXZT6kPJ1ewohlCUw00= Received: by 10.229.102.72 with SMTP id f8mr12771334qco.51.1329240302217; Tue, 14 Feb 2012 09:25:02 -0800 (PST) Received: from windows8d787f9 (75-147-4-157-NewEngland.hfc.comcastbusiness.net. [75.147.4.157]) by mx.google.com with ESMTPS id gq6sm1232093qab.21.2012.02.14.09.25.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Feb 2012 09:25:01 -0800 (PST) From: "Roni Even" To: "'Brian Baldino \(bbaldino\)'" , References: In-Reply-To: Date: Tue, 14 Feb 2012 19:24:46 +0200 Message-ID: <4f3a98ed.06d4e00a.5730.3bbf@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B3_01CCEB4E.50348F20" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczqflaBKakYMuZXS4ChqE3TJmyEiQAvlJaQ Content-Language: en-us Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-framework-03 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, 14 Feb 2012 17:25:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B3_01CCEB4E.50348F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Brian, Sorry if I was not clear, I meant adding to the current three. The no scale still provide spatial order as seen by the provider. I propose a "no spatial order" which will tell the consumer to render as it wishes. As for priority, I agree that it can be a separate attribute. Roni From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] Sent: Monday, February 13, 2012 8:36 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Spatial information - Review of draft-ietf-clue-framework-03 Hey Roni, Was wondering if you could clarify what you mean here: The coordinate units are first discussed in section 4. The currents units which I am OK with are the mm and no unknown. The no scale as far as I understand provide units in the coordinates system that allows the provider to define a spatial order that the consumer will use to render, this option can be used for example by a MCU. I think that we can add two more units. The first is "no spatial information" this will allow the provider to leave it to the consumer to decide what order to use. The second is "priority" this is still no spatial relation between the media captures but the provider can use it to specify which media captures are more important allowing the consumer to select between media captures. You mention two scales but the framework currently allows for three scales: mm, unknown and no scale...would having these 3 options address your first point? I'm not sure what you're looking for when you describe allowing the consumer to decide what order to use. Also, as far as priority, that seems like something that should be separate from the spatial information...do you think it belongs with the spatial stuff or perhaps we can address it somewhere else? -Brian From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, February 08, 2012 5:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 The coordinate units are first discussed in section 4. The currents units which I am OK with are the mm and no unknown. The no scale as far as I understand provide units in the coordinates system that allows the provider to define a spatial order that the consumer will use to render, this option can be used for example by a MCU. I think that we can add two more units. The first is "no spatial information" this will allow the provider to leave it to the consumer to decide what order to use. The second is "priority" this is still no spatial relation between the media captures but the provider can use it to specify which media captures are more important allowing the consumer to select between media captures. Thanks Roni Even ------=_NextPart_000_00B3_01CCEB4E.50348F20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian,

Sorry if I was not = clear, I meant adding to the current three.

The no scale still = provide spatial order as seen by the provider. I propose a "no = spatial order" which will tell the consumer to render as it wishes. =

As for priority, I agree that it can be a = separate attribute.

 

Roni =

 

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= = Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]
Sent: = Monday, February 13, 2012 8:36 PM
To: Roni Even; = clue@ietf.org
Subject: RE: [clue] Spatial information - Review = of draft-ietf-clue-framework-03

 

Hey Roni,

Was wondering if you could clarify what you mean = here:

The = coordinate units are first discussed in section 4. The currents units = which I am OK with are the mm and no unknown. The no scale as far as I = understand provide units in the coordinates system that allows the = provider to define a spatial order that the consumer will use to render, = this option can be used for example by a MCU. I think that we can add = two more units. The first is “no spatial information” this = will allow the provider to leave it to the consumer to decide what order = to use. The second is “priority” this is still no spatial = relation between the media captures but the provider can use it to = specify which media captures are more important allowing the consumer to = select between media captures.

 

You mention two scales but the framework currently = allows for three scales: mm, unknown and no scale...would having these 3 = options address your first point?  I’m not sure what = you’re looking for when you describe allowing the consumer to = decide what order to use.

Also, as far as priority, that seems like something = that should be separate from the spatial information...do you think it = belongs with the spatial stuff or perhaps we can address it somewhere = else?

-Brian

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Roni Even
Sent: Wednesday, February 08, = 2012 5:49 AM
To: clue@ietf.org
Subject: = [clue] Review of = draft-ietf-clue-framework-03

 =

The = coordinate units are first discussed in section 4. The currents units = which I am OK with are the mm and no unknown. The no scale as far as I = understand provide units in the coordinates system that allows the = provider to define a spatial order that the consumer will use to render, = this option can be used for example by a MCU. I think that we can add = two more units. The first is “no spatial information” this = will allow the provider to leave it to the consumer to decide what order = to use. The second is “priority” this is still no spatial = relation between the media captures but the provider can use it to = specify which media captures are more important allowing the consumer to = select between media captures.

 =

Thanks=

Roni = Even

 =

 =

 

------=_NextPart_000_00B3_01CCEB4E.50348F20-- From Mark.Duckworth@polycom.com Tue Feb 14 09:41: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 2751F21E809F for ; Tue, 14 Feb 2012 09:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 ErmpugrYy16D for ; Tue, 14 Feb 2012 09:41:06 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7D421E8029 for ; Tue, 14 Feb 2012 09:40:59 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Tue, 14 Feb 2012 09:40:59 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Tue, 14 Feb 2012 09:40:57 -0800 Thread-Topic: [clue] MC -> multiple streams - Review of framework-03 Thread-Index: Aczqe+0S6ZD2JJVhRoywnX9oDv1guAAwEcqAAACrzdA= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB3ECE69@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB3024D4@CRPMBOXPRD01.polycom.com> <4f3a973d.84c6e00a.2c4e.7a0b@mx.google.com> In-Reply-To: <4f3a973d.84c6e00a.2c4e.7a0b@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] MC -> multiple streams - Review of framework-03 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, 14 Feb 2012 17:41:07 -0000 Hi Roni, No, we did not intend to use different MCs for different ways of encoding t= he same thing. If the consumer wants to get different encodings of the sam= e MC, it asks for that when it sends the "configure encodings" message to t= he provider. The consumer specifies which individual encodings to use, tak= en from the encoding group the provider advertised for that MC. Mark -----Original Message----- From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Tuesday, February 14, 2012 12:18 PM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] MC -> multiple streams - Review of framework-03 Hi Mark, So do you see that the capture set may include a MC with a simulcast and a = different one with just one RTP stream. I think that goes to the discussion= we are having on mapping the SDP information to the MCs Roni > -----Original Message----- > From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > Sent: Monday, February 13, 2012 8:24 PM > To: Roni Even; clue@ietf.org > Subject: RE: [clue] MC -> multiple streams - Review of framework-03 >=20 > Hi Roni, >=20 > A media capture may be encoded into multiple streams simultaneously,=20 > perhaps with different codecs or different encoding parameters. For=20 > example simulcast of a video capture at CIF and 1080p resolutions. > Each of those could be a different stream. >=20 > From section 8 of the draft framework-03: > "If there are multiple individual encodings in the group, then a=20 > single media capture can be encoded into multiple different streams at=20 > the same time, with each stream following the constraints of a=20 > different individual encoding." >=20 > Mark >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Roni Even > Sent: Wednesday, February 08, 2012 8:49 AM > To: clue@ietf.org > Subject: [clue] Review of draft-ietf-clue-framework-03 >=20 > 1. In section 3 the definition of media capture say "A Media Capture > (MC) may be the source of one or more Media streams."=A0 What is the=20 > "more" in this case. Can you explain since my understanding of a media=20 > capture is that is one stream, can you give an example. >=20 > Thanks > Roni Even >=20 From espeberg@cisco.com Tue Feb 14 12:36: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 1CD1521F866B for ; Tue, 14 Feb 2012 12:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.166 X-Spam-Level: X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 6N50+yETo0qO for ; Tue, 14 Feb 2012 12:36:43 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D4C9C21F8668 for ; Tue, 14 Feb 2012 12:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=4401; q=dns/txt; s=iport; t=1329251795; x=1330461395; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6BuftZm5+XpzqwUK69yUbEMDVfQCxQ/INBcPj0Tt08w=; b=WnA+04xUryEArwhPteAX/kGu9Zhd+1vxzxn+cSbvDgAx/MXGS8BVD2gT sm6LhLxqb6eXf7mM9jViXHMugtUbw17OgDllXiTCb/4md91Xqi9mZQeMi UfsDBqYSUBIRGNAEfRade558JtSsh3u3+vijIdnKiIfTLJXWuGIp+VWM9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA/FOk+Q/khN/2dsb2JhbABDsFGBB4FyAQEBAwESAR0KPwUHBAIBCBEEAQEBCgYXAQYBRQkIAQEEEwgah1qaHQGeYotUBQEMBAMFBgMQBwIECDgchCUECAMGBQaCTGMEqBc X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="129426555" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2012 20:36:33 +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 q1EKaX9C031184; Tue, 14 Feb 2012 20:36:33 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); Tue, 14 Feb 2012 21:36:33 +0100 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, 14 Feb 2012 21:36:33 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EF45166@XMB-AMS-214.cisco.com> In-Reply-To: <20120213162307.GW61963@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] VAD and speaker coordinates Thread-Index: Aczqa9HRvKE+Odv6R3CdZ7oICYWxKAAr/dXA References: <4F3046C9.4060401@alum.mit.edu> <20120208215905.GP61963@verdi> <92DF9533227FC14F946C7321074B8C9EEC5B0C@XMB-AMS-214.cisco.com> <20120213162307.GW61963@verdi> From: "Espen Berger (espeberg)" To: "John Leslie" X-OriginalArrivalTime: 14 Feb 2012 20:36:33.0639 (UTC) FILETIME=[57035F70:01CCEB58] Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates 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, 14 Feb 2012 20:36:44 -0000 Hi John=20 Discussions of Audio recording and playback is something that will benefits from a whiteboard!=20 See inline.=20 -Espen=20 -----Original Message----- From: John Leslie [mailto:john@jlc.net]=20 Sent: 13. februar 2012 17:23 To: Espen Berger (espeberg) Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates This really deserves a reply, but it is proving hard to write: :^( Espen Berger (espeberg) wrote: >=20 > Are we discussing a use case where we want information about the speaker > position, e.g >=20 > "User Bob is in a call with Alice, Bob see that Alice is standing left > in the video stream. Bob wants to hear the audio from Alice being from > the left side" =20 It's _really_ not that simple. [Espen Berger (espeberg)] My use case is this simple, other use cases might be more complex. With a single speaker in a room, dynamic speaker position work nicely. [Espen] Having mono audio bounce between speakers will sort-of work if we're all agreed there are only two speakers. If there are more than two, it won't work at all. [Espen Berger (espeberg)] I do not see that modeling more than two active talkers is hard. To do proper playback is hard, but last resort is always to mix all audio together and play back on a single speaker.=20 > Some comments=20 > * A single audio stream is enough=20 Enough for what? [Espen Berger (espeberg)] Enough to play out on active talker in any position, as long as you receive the dynamic position information.=20 A single monophonic speaker does have the advantage of never confusing the listener by having the current speaker's position move arbitrarily... > * Without any speaker position information the default is to play out > audio in the center of the video stream Yes, that is a reasonable default. =20 > * If dynamic speaker position is sent, you could play out the audio in > the correct position=20 There-Ain't-No-Such-Thing-As-A "correct position". :^( We're trying to create a virtual room; and except in the trivial case where one room has half the speakers and a second room has the other half, we're reduced to asking the participants to suspend their disbelief that they're in this virtual room. [Espen Berger (espeberg)] The term Virtual room is not well defined.=20 For that trivial case, we can treat each set of screens as a virtual glass partition, let participants listen to the folks on their side without any amplification, and reproduce the audio which "would" pass through the partition if it weren't there. (There _will_ be some extended echo problems, but those can be managed.) [Espen Berger (espeberg)] AFAIK the echo cancelation is a implementation challenge more than a modeling challenge.=20 Once we get past this virtual-room-in-two-pieces, we're in trouble! IMHO, we shouldn't even try to define how the audio will be managed -- but we should provide a means of passing the information which may be needed for _different_ ways of presenting the audio. [Espen Berger (espeberg)] Agree, we should focus on the meta-information sent and received. One example would be to keep the "divided-room" paradigm, and add in individuals (perhaps shown in insets on one of the screens), always in the same virtual (three-dimensional) audio position, when they are speaking. (A better way, of course, would be to give them their own screen and speaker.) IMHO, the critical information is the _virtual_ position of the speaker, the actual position of the microphone, and _perhaps_ the relative actual position of the speaker to the microphone. Room acoustics is a critical part of how humans "place" a sound source; and screwing up the room acoustics to "help" them won't help. (IMHO, of course...) [Espen Berger (espeberg)] I still believe that the capture room is better at figuring out the speaker position than the reproducing room. At capture time you can do pre-processing if needed to calculate position and also mix multiple microphone inputs together into a single audio stream, e.g. when two microphones picks up the audio from the same speaker. > * Speaker position is not always possible to detect or some rooms might > skip the whole thing, so it's optional.=20 Agreed! -- John Leslie From pkyzivat@alum.mit.edu Tue Feb 14 13:50:28 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 DB45E21E8016 for ; Tue, 14 Feb 2012 13:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 v37z--zi4W7v for ; Tue, 14 Feb 2012 13:50:28 -0800 (PST) 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 8D14621E80B8 for ; Tue, 14 Feb 2012 13:50:23 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id Zvpo1i00927AodY55xqP3o; Tue, 14 Feb 2012 21:50:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id ZxqP1i01T07duvL3fxqPHx; Tue, 14 Feb 2012 21:50:23 +0000 Message-ID: <4F3AD71E.7030503@alum.mit.edu> Date: Tue, 14 Feb 2012 16:50:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Roni Even References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> <4f394fd7.4c200e0a.14fd.ffffc4b2@mx.google.com> <4F395367.8050504@alum.mit.edu> <4f395a76.11840e0a.1d12.ffffac02@mx.google.com> In-Reply-To: <4f395a76.11840e0a.1d12.ffffac02@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 14 Feb 2012 21:50:29 -0000 On 2/13/12 1:45 PM, Roni Even wrote: > Hi Paul, > This is what the conference event package is for > Roni Hmm. Maybe there is some way to make that work. But I'm not convinced. I think the discussion of RTP usage this week will be lively and mutually educational. Thanks, Paul >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Monday, February 13, 2012 8:16 PM >> To: clue@ietf.org >> Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 >> >> Roni - at end >> >> On 2/13/12 1:00 PM, Roni Even wrote: >>> Hi Jonathan, >>> >>> First to clarify, when I say media capture I refer to the CLUE >>> description on the semantics of the data. Stream is the RTP stream. >> In >>> SDP I do not differentiate between the case where you have an m-line >>> for each RTP media stream or you multiplex them using SSRC. The >> bundle >>> draft still has an m-line for each RTP stream. The difference is that >>> without bundle they each one is an RTP session while in the bundle >>> case at least for now they are all part of the same RTP session. >>> >>> Now I am not sure what you mean when you are talking about hundreds >> of >>> descriptions. >>> >>> In the point to point the number of RTP streams described in the SDP >>> should probably be the number of media captures in the capture set >>> entry with the largest number of MCs, see the draft I submitted >> yesterday. >>> >>> In the multipoint case I assume that we are only talking about an MCU >>> that serves as a central signaling point and not about some >>> distributed signaling. In this case the MCU receives all MCs and the >>> SDP from all end point it needs to provide all MCs if it wants but as >>> for the SDP it only need to provide the number of m-lines (using >>> bundle) that will allow him to send and receive the maximum that the >>> end point will receive simultaneously. The content of each of these >>> RTP streams or channels will change based on the current configured >> capture set entry. >>> For example in your 2 out of three the number of m-lines or RTP >>> streams will be two. The content inside will change using the SSRC to >>> identify the specific one. BTW: I think that it will work better if >>> all three VC use the same codec. >>> >>> I do not see an endpoint receiving hundreds of streams or a large >> full >>> mesh conference as a valid use case. >> >> Suppose we have an MCU with many (e.g. hundreds) of captures coming >> into it. >> >> And then suppose the MCU wants to advertise a switched capture that >> switches among all of those. >> >> IIUC, you would represent that as a single m-line for the switched >> capture, but with any one of the many SSRCs indicating which capture >> was being sent at any given time. >> >> But then how does the recipient discover which of the switched captures >> it is receiving? And how does it sort out which SSRCs correspond to the >> switched capture, vs. others that correspond to other captures in the >> capture set mapped to the same RTP addr/port? >> >> Thanks, >> Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From ron.even.tlv@gmail.com Tue Feb 14 19: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 D2A1621E809D for ; Tue, 14 Feb 2012 19:57:20 -0800 (PST) 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=[AWL=0.000, 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 3EwTWHS+WeAE for ; Tue, 14 Feb 2012 19:57:20 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id D8B2A21E8091 for ; Tue, 14 Feb 2012 19:57:19 -0800 (PST) Received: by qan41 with SMTP id 41so707615qan.10 for ; Tue, 14 Feb 2012 19:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=aaAXwp5DVXl4q7Kh7JuHi07AriYkcbRIYVzenzZggQo=; b=AlGZJrPm5B8HAYd1h1HlofB7raBbcTxOGuYfTaZEjXz0No7/XktbpUx60s04rtlze0 CUiGBNQbf662FeqiGpGcL6gR+TJK4RrngPAGPYtl8vhrOHgSZFQvb4yIytUnLi2LKNZ1 kjsP3kJx61RLHZirTs+vy2zWxr6u66XriiasY= Received: by 10.229.136.75 with SMTP id q11mr7520656qct.107.1329278239278; Tue, 14 Feb 2012 19:57:19 -0800 (PST) Received: from windows8d787f9 (75-147-4-157-NewEngland.hfc.comcastbusiness.net. [75.147.4.157]) by mx.google.com with ESMTPS id k19sm7956238qak.4.2012.02.14.19.57.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Feb 2012 19:57:18 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB3024D4@CRPMBOXPRD01.polycom.com> <4f3a973d.84c6e00a.2c4e.7a0b@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB3ECE69@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB3ECE69@CRPMBOXPRD01.polycom.com> Date: Wed, 15 Feb 2012 05:57:03 +0200 Message-ID: <4f3b2d1e.5309e00a.6747.ffffed77@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: Aczqe+0S6ZD2JJVhRoywnX9oDv1guAAwEcqAAACrzdAAFZPTUA== Content-Language: en-us Subject: Re: [clue] MC -> multiple streams - Review of framework-03 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, 15 Feb 2012 03:57:20 -0000 Hi Mark, In my view you may need different m-lines or payload type numbers to describe the two options, as for MCs this is a question if this is a different semantic or a single one since they represent the same source = like left camera. Still the left camera may need to be mapped to different = SDP specified streams. I do not think that the individual encoding should be used for it since = this will be a duplication of SDP. I already said in a different comment that = I see no value in individual encodes since they duplicate SDP but even if = you use them for constrains they should not be used for replacing SDP. Roni > -----Original Message----- > From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > Sent: Tuesday, February 14, 2012 7:41 PM > To: Roni Even; clue@ietf.org > Subject: RE: [clue] MC -> multiple streams - Review of framework-03 >=20 > Hi Roni, > No, we did not intend to use different MCs for different ways of > encoding the same thing. If the consumer wants to get different > encodings of the same MC, it asks for that when it sends the = "configure > encodings" message to the provider. The consumer specifies which > individual encodings to use, taken from the encoding group the = provider > advertised for that MC. > Mark >=20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Tuesday, February 14, 2012 12:18 PM > To: Duckworth, Mark; clue@ietf.org > Subject: RE: [clue] MC -> multiple streams - Review of framework-03 >=20 > Hi Mark, > So do you see that the capture set may include a MC with a simulcast > and a different one with just one RTP stream. I think that goes to the > discussion we are having on mapping the SDP information to the MCs = Roni >=20 > > -----Original Message----- > > From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > > Sent: Monday, February 13, 2012 8:24 PM > > To: Roni Even; clue@ietf.org > > Subject: RE: [clue] MC -> multiple streams - Review of framework-03 > > > > Hi Roni, > > > > A media capture may be encoded into multiple streams simultaneously, > > perhaps with different codecs or different encoding parameters. For > > example simulcast of a video capture at CIF and 1080p resolutions. > > Each of those could be a different stream. > > > > From section 8 of the draft framework-03: > > "If there are multiple individual encodings in the group, then a > > single media capture can be encoded into multiple different streams > at > > the same time, with each stream following the constraints of a > > different individual encoding." > > > > Mark > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Roni Even > > Sent: Wednesday, February 08, 2012 8:49 AM > > To: clue@ietf.org > > Subject: [clue] Review of draft-ietf-clue-framework-03 > > > > 1. In section 3 the definition of media capture say "A Media Capture > > (MC) may be the source of one or more Media streams."=A0 What is the > > "more" in this case. Can you explain since my understanding of a > media > > capture is that is one stream, can you give an example. > > > > Thanks > > Roni Even > > From ron.even.tlv@gmail.com Tue Feb 14 20:02: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 8B20A21F84A7 for ; Tue, 14 Feb 2012 20:02:27 -0800 (PST) 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=[AWL=0.000, 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 HYF+nhrpglrS for ; Tue, 14 Feb 2012 20:02:26 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id A42C621F84A6 for ; Tue, 14 Feb 2012 20:02:26 -0800 (PST) Received: by qan41 with SMTP id 41so709124qan.10 for ; Tue, 14 Feb 2012 20:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=8AskMdiPW0KZMBFNB1wbj6tRwUxUrTT8irqyzbKRnyE=; b=MrzdC61O0lKamJuZDfwDhOewrHyp9Rj7zzLcxuUyvKS51Gxf/zLevICs4YjqRb3zuC ffVWbKmITiwEiBDwkHddrX0my2N0PB19qMQQYpbhjr8dGKhk+xw61VtBfDRaP6bBc8L5 NT55z5J88cwEoev/XqZ+d2CgrhPM59dMVLjIs= Received: by 10.229.135.193 with SMTP id o1mr13970221qct.74.1329278545744; Tue, 14 Feb 2012 20:02:25 -0800 (PST) Received: from windows8d787f9 (75-147-4-157-NewEngland.hfc.comcastbusiness.net. [75.147.4.157]) by mx.google.com with ESMTPS id r10sm7968148qaz.7.2012.02.14.20.02.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Feb 2012 20:02:25 -0800 (PST) From: "Roni Even" To: "'Paul Kyzivat'" References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> <4f394fd7.4c200e0a.14fd.ffffc4b2@mx.google.com> <4F395367.8050504@alum.mit.edu> <4f395a76.11840e0a.1d12.ffffac02@mx.google.com> <4F3AD71E.7030503@alum.mit.edu> In-Reply-To: <4F3AD71E.7030503@alum.mit.edu> Date: Wed, 15 Feb 2012 06:02:10 +0200 Message-ID: <4f3b2e51.0aaee00a.45b8.fffff1e8@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: AczrYqcerV7UkX7lQuqiv+hiUfKaKQAM0yPg Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 15 Feb 2012 04:02:27 -0000 Hi Paul, I think that the discussion should start with the ground rules. My assumption is that we have a SIP offer/answer that provides in the SDP all the RTP streams that may be used with the relevant parameters like profile and level and the other optional parameters. In parallel we have the CLUE information which describes the semantics of the streams based on purpose and co-ordinates. There need to be mapping between them. For multipoint case if we want to convey what we call roster information there is the conference event package. BR Roni > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, February 14, 2012 11:50 PM > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > On 2/13/12 1:45 PM, Roni Even wrote: > > Hi Paul, > > This is what the conference event package is for Roni > > Hmm. Maybe there is some way to make that work. But I'm not convinced. > I think the discussion of RTP usage this week will be lively and > mutually educational. > > Thanks, > Paul > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Monday, February 13, 2012 8:16 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > >> > >> Roni - at end > >> > >> On 2/13/12 1:00 PM, Roni Even wrote: > >>> Hi Jonathan, > >>> > >>> First to clarify, when I say media capture I refer to the CLUE > >>> description on the semantics of the data. Stream is the RTP stream. > >> In > >>> SDP I do not differentiate between the case where you have an m- > line > >>> for each RTP media stream or you multiplex them using SSRC. The > >> bundle > >>> draft still has an m-line for each RTP stream. The difference is > >>> that without bundle they each one is an RTP session while in the > >>> bundle case at least for now they are all part of the same RTP > session. > >>> > >>> Now I am not sure what you mean when you are talking about hundreds > >> of > >>> descriptions. > >>> > >>> In the point to point the number of RTP streams described in the > SDP > >>> should probably be the number of media captures in the capture set > >>> entry with the largest number of MCs, see the draft I submitted > >> yesterday. > >>> > >>> In the multipoint case I assume that we are only talking about an > >>> MCU that serves as a central signaling point and not about some > >>> distributed signaling. In this case the MCU receives all MCs and > the > >>> SDP from all end point it needs to provide all MCs if it wants but > >>> as for the SDP it only need to provide the number of m-lines (using > >>> bundle) that will allow him to send and receive the maximum that > the > >>> end point will receive simultaneously. The content of each of these > >>> RTP streams or channels will change based on the current configured > >> capture set entry. > >>> For example in your 2 out of three the number of m-lines or RTP > >>> streams will be two. The content inside will change using the SSRC > >>> to identify the specific one. BTW: I think that it will work better > >>> if all three VC use the same codec. > >>> > >>> I do not see an endpoint receiving hundreds of streams or a large > >> full > >>> mesh conference as a valid use case. > >> > >> Suppose we have an MCU with many (e.g. hundreds) of captures coming > >> into it. > >> > >> And then suppose the MCU wants to advertise a switched capture that > >> switches among all of those. > >> > >> IIUC, you would represent that as a single m-line for the switched > >> capture, but with any one of the many SSRCs indicating which capture > >> was being sent at any given time. > >> > >> But then how does the recipient discover which of the switched > >> captures it is receiving? And how does it sort out which SSRCs > >> correspond to the switched capture, vs. others that correspond to > >> other captures in the capture set mapped to the same RTP addr/port? > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > From pkyzivat@alum.mit.edu Tue Feb 14 21:02: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 7639221F8595 for ; Tue, 14 Feb 2012 21:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[AWL=0.989, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 EDCudKbMJzyC for ; Tue, 14 Feb 2012 21:02:45 -0800 (PST) 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 C71EC21F858D for ; Tue, 14 Feb 2012 21:02:44 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta15.westchester.pa.mail.comcast.net with comcast id a51g1i00216LCl05F52ljL; Wed, 15 Feb 2012 05:02:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta06.westchester.pa.mail.comcast.net with comcast id a52k1i00B07duvL3S52k6R; Wed, 15 Feb 2012 05:02:45 +0000 Message-ID: <4F3B3C73.9030906@alum.mit.edu> Date: Wed, 15 Feb 2012 00:02:43 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: CLUE References: <235519175.1329281344658.JavaMail.nobody@jva2wl002.webex.com> In-Reply-To: <235519175.1329281344658.JavaMail.nobody@jva2wl002.webex.com> X-Forwarded-Message-Id: <235519175.1329281344658.JavaMail.nobody@jva2wl002.webex.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Meeting invitation: CLUE WG 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: Wed, 15 Feb 2012 05:02:46 -0000 -------- Original Message -------- Subject: (Forward to attendees) Meeting invitation: CLUE WG F2F Interim meeting Date: Wed, 15 Feb 2012 04:49:04 +0000 (GMT) From: Clue Working Group Reply-To: clue-chairs@tools.ietf.org To: clue-chairs@tools.ietf.org **** You can forward this email invitation to attendees **** Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG F2F Interim meeting Date: Every 1 day, from Wednesday, February 15, 2012 to Thursday, February 16, 2012 Time: 7:30 am, Central Standard Time (Chicago, GMT-06:00) Meeting Number: 649 605 367 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=150036847&UID=0&PW=NOWNlMjI5ZTU4&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=150036847&UID=0&PW=NOWNlMjI5ZTU4&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code:649 605 367 ------------------------------------------------------- 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=150036847&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=VIDM95ftSE/yAdFB5aIcRLiJALs0/lOFpsumNkCzCMY=&RT=MiM3 Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14086003600x649605367# 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. From mary.ietf.barnes@gmail.com Tue Feb 14 21:13: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 56A7521F8674 for ; Tue, 14 Feb 2012 21:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.609 X-Spam-Level: X-Spam-Status: No, score=-104.609 tagged_above=-999 required=5 tests=[AWL=0.990, 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 E6ElicTTr3TS for ; Tue, 14 Feb 2012 21:13:05 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90AD921F8671 for ; Tue, 14 Feb 2012 21:13:05 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so570423vcb.31 for ; Tue, 14 Feb 2012 21:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OHxvciKis2FWKNSQqkimLq5GjbSfIWXT2Q8TX9R0X0c=; b=W42yt5tpHQel7GeXLLnny1CS/PYmyb/+NuWiZQ0LBsqf5fCrJG0XArO0Jh52jKpLUh RSuYda6L8BcR/uFAgKfPU5yjJha7azYNCJZjGX62w6pBrqRTD9O1MS33bWb2I4kl+Wi+ fgEZUUPHq/S78uKBNpcKffeRzIAEJEAwzC47I= MIME-Version: 1.0 Received: by 10.52.21.174 with SMTP id w14mr9899620vde.21.1329282785126; Tue, 14 Feb 2012 21:13:05 -0800 (PST) Received: by 10.52.114.200 with HTTP; Tue, 14 Feb 2012 21:13:05 -0800 (PST) In-Reply-To: <4F3B3C73.9030906@alum.mit.edu> References: <235519175.1329281344658.JavaMail.nobody@jva2wl002.webex.com> <4F3B3C73.9030906@alum.mit.edu> Date: Tue, 14 Feb 2012 23:13:05 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [clue] Meeting invitation: CLUE WG 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: Wed, 15 Feb 2012 05:13:06 -0000 As a reminder, the meeting materials and detailed agenda are all available here: http://www.ietf.org/proceedings/interim/2012/02/15/clue/proceedings.html Mary. On Tue, Feb 14, 2012 at 11:02 PM, Paul Kyzivat wrote: > > > > Hello , > > Clue Working Group invites you to attend this online meeting. > > Topic: CLUE WG F2F Interim meeting > Date: Every 1 day, from Wednesday, February 15, 2012 to Thursday, > February 16, 2012 > Time: 7:30 am, Central Standard Time (Chicago, GMT-06:00) > Meeting Number: 649 605 367 > Meeting Password: 1234 > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://ietf.webex.com/ietf/j.php?ED=150036847&UID=0&PW=NOWNlMjI5ZTU4&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=150036847&UID=0&PW=NOWNlMjI5ZTU4&ORT=MiM3 > > > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > Call-in toll number (US/Canada): +1-408-600-3600 > > Access code:649 605 367 > > ------------------------------------------------------- > 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=150036847&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=VIDM95ftSE/yAdFB5aIcRLiJALs0/lOFpsumNkCzCMY=&RT=MiM3 > > > > > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+14086003600x649605367# > > 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. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Tue Feb 14 21:18: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 0529D11E808A for ; Tue, 14 Feb 2012 21:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.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 FMzJA0G7ggrI for ; Tue, 14 Feb 2012 21:18:36 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9733211E8073 for ; Tue, 14 Feb 2012 21:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=7046; q=dns/txt; s=iport; t=1329283116; x=1330492716; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=zeWSuu+MsH00iIZ0KGaT39H+Ytw7y87WH76bvUAoeZI=; b=WHqN3MkL0ENCndS4sM7NZ6/S09yiHX58h4jNo9fU4dwXOQO6+hq5lmow 5X5cg7uXw0ho0gdBkIZ/CIt8BPgb/itqNVzmri4te2N4S7hmPbENSUJER tVPz70t6t1IZOqeXuUF2Lllxy17gwy1lICgh9sf+bnI0HVMcdYQJFGjQ7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADE/O0+rRDoG/2dsb2JhbABDgk2uFYEHgXIBAQEEEgEJEQNJEAIBCA4DBAEBCwYXAQYBRQkIAQEEEwgaolQBnleMFxBNA4MQAQpuCYJOYwSIS59w X-IronPort-AV: E=Sophos;i="4.73,421,1325462400"; d="scan'208,217";a="30518406" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 15 Feb 2012 05:18:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1F5IZev003084; Wed, 15 Feb 2012 05:18:35 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); Tue, 14 Feb 2012 21:18:34 -0800 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_01CCEBA1.43BB3CED" Date: Tue, 14 Feb 2012 21:18:35 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06C5E3F6@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4f327d59.d2130e0a.3e4f.ffffe95a@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] significant change in transmission of content-- Review of draft-ietf-clue-framework-03 Thread-Index: AczmaGdy5PVDLQ8nRHK9EFLGxp4ZMQFOCJnw References: <4f327d59.d2130e0a.3e4f.ffffe95a@mx.google.com> From: "Allyn Romanow (allyn)" To: "Roni Even" X-OriginalArrivalTime: 15 Feb 2012 05:18:34.0947 (UTC) FILETIME=[43F7B130:01CCEBA1] Cc: clue@ietf.org Subject: Re: [clue] significant change in transmission of content-- Review of draft-ietf-clue-framework-03 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, 15 Feb 2012 05:18:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCEBA1.43BB3CED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni,=20 Content meant what the audio or video is focused on. I suggest removing this sentence; it was a side comment which, if controversial, is not interesting. =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, February 08, 2012 5:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 =20 =20 1. In section 4, "This constitutes a significant change from previous video conferencing systems in which transmission of content was determined primarily by the sender." I am not sure what is "content" here, is it the actual data or the semantics of the stream. I also do not believe that this statement is true. ------_=_NextPart_001_01CCEBA1.43BB3CED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni, =

Content meant what the audio or video is focused = on. I suggest removing  this sentence; it was a side comment which, if controversial, is not interesting.

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, February 08, 2012 5:49 AM
To: clue@ietf.org
Subject: [clue] Review of = draft-ietf-clue-framework-03

 

 

1.       In section 4, “This constitutes a significant change from previous = video conferencing  systems in which transmission of content was = determined primarily by  the sender.” I am not sure what is “content” here, is it the actual data or the semantics of = the stream. I also do not believe that this statement is = true.

------_=_NextPart_001_01CCEBA1.43BB3CED-- From allyn@cisco.com Tue Feb 14 21:35: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 14B3E21F8685 for ; Tue, 14 Feb 2012 21:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.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 1tTI93cn-RtS for ; Tue, 14 Feb 2012 21:35:19 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A7A7E21F8684 for ; Tue, 14 Feb 2012 21:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=5471; q=dns/txt; s=iport; t=1329284118; x=1330493718; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=d9F/DZGlfVYj8UWoU2m1ZQPRs9VN7P4Y6XDeaM57Ync=; b=BTDo+BYbQWJ7vShKKJJsi/ObnujNTdg9oZgYCPoxrKYEZb3+GgoNhQb3 wyUUkqLLTTyXHzMTkjYEyK7k2TV8I5AnbasZHrNDAJF9vbrtdpBZQBREf erauHolmXU4TsZ8z5XpDswIzLvOQkIkUDHxc5J63Svkm9XjE23A48Kekr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPVCO0+rRDoI/2dsb2JhbAA5Cg6wVYEHgXIBAQEEAQEBDwEdCi4GCwwEAgEIDgMEAQEBCgYXAQYBJh8JCAEBBAESCBMHh2OaaQGeVASJFoJDBQUIAQQBCQUEBQQJCAICBgaDWgFdDgMBCQUEB4JHYwSIS58YWA X-IronPort-AV: E=Sophos;i="4.73,421,1325462400"; d="scan'208";a="30522409" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 15 Feb 2012 05:35:18 +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 q1F5ZIMi031580; Wed, 15 Feb 2012 05:35:18 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); Tue, 14 Feb 2012 21:35:18 -0800 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, 14 Feb 2012 21:35:17 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06C5E403@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4f3b2e51.0aaee00a.45b8.fffff1e8@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] comment on draft-lennox-clue-rtp-usage-0 Thread-Index: AczrYqcerV7UkX7lQuqiv+hiUfKaKQAM0yPgAAMiYOA= References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> <4f394fd7.4c200e0a.14fd.ffffc4b2@mx.google.com><4F395367.8050504@alum.mit.edu><4f395a76.11840e0a.1d12.ffffac02@mx.google.com><4F3AD71E.7030503@alum.mit.edu> <4f3b2e51.0aaee00a.45b8.fffff1e8@mx.google.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Paul Kyzivat" X-OriginalArrivalTime: 15 Feb 2012 05:35:18.0332 (UTC) FILETIME=[9A0817C0:01CCEBA3] Cc: clue@ietf.org Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 15 Feb 2012 05:35:20 -0000 Perhaps I've misunderstand what you meant Roni, but I am surprised by your comment. Ground rules? Aren't we considering alternate architectures that work best, rather than having ground-rules based on assumptions on how things will be done? Don't we have a ways to go yet to understand where offer/answer is viable for CLUE, and where it is not? and then to evaluate different possible solutions for where the current infrastructure may not work for CLUE? Allyn=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni Even > Sent: Tuesday, February 14, 2012 8:02 PM > To: 'Paul Kyzivat' > Cc: clue@ietf.org > Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 >=20 > Hi Paul, > I think that the discussion should start with the ground rules. > My assumption is that we have a SIP offer/answer that provides in the > SDP > all the RTP streams that may be used with the relevant parameters like > profile and level and the other optional parameters. In parallel we > have the > CLUE information which describes the semantics of the streams based on > purpose and co-ordinates. > There need to be mapping between them. > For multipoint case if we want to convey what we call roster > information > there is the conference event package. > BR > Roni >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: Tuesday, February 14, 2012 11:50 PM > > To: Roni Even > > Cc: clue@ietf.org > > Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > On 2/13/12 1:45 PM, Roni Even wrote: > > > Hi Paul, > > > This is what the conference event package is for Roni > > > > Hmm. Maybe there is some way to make that work. But I'm not > convinced. > > I think the discussion of RTP usage this week will be lively and > > mutually educational. > > > > Thanks, > > Paul > > > > >> -----Original Message----- > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > >> Of Paul Kyzivat > > >> Sent: Monday, February 13, 2012 8:16 PM > > >> To: clue@ietf.org > > >> Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > >> > > >> Roni - at end > > >> > > >> On 2/13/12 1:00 PM, Roni Even wrote: > > >>> Hi Jonathan, > > >>> > > >>> First to clarify, when I say media capture I refer to the CLUE > > >>> description on the semantics of the data. Stream is the RTP > stream. > > >> In > > >>> SDP I do not differentiate between the case where you have an m- > > line > > >>> for each RTP media stream or you multiplex them using SSRC. The > > >> bundle > > >>> draft still has an m-line for each RTP stream. The difference is > > >>> that without bundle they each one is an RTP session while in the > > >>> bundle case at least for now they are all part of the same RTP > > session. > > >>> > > >>> Now I am not sure what you mean when you are talking about > hundreds > > >> of > > >>> descriptions. > > >>> > > >>> In the point to point the number of RTP streams described in the > > SDP > > >>> should probably be the number of media captures in the capture > set > > >>> entry with the largest number of MCs, see the draft I submitted > > >> yesterday. > > >>> > > >>> In the multipoint case I assume that we are only talking about an > > >>> MCU that serves as a central signaling point and not about some > > >>> distributed signaling. In this case the MCU receives all MCs and > > the > > >>> SDP from all end point it needs to provide all MCs if it wants > but > > >>> as for the SDP it only need to provide the number of m-lines > (using > > >>> bundle) that will allow him to send and receive the maximum that > > the > > >>> end point will receive simultaneously. The content of each of > these > > >>> RTP streams or channels will change based on the current > configured > > >> capture set entry. > > >>> For example in your 2 out of three the number of m-lines or RTP > > >>> streams will be two. The content inside will change using the > SSRC > > >>> to identify the specific one. BTW: I think that it will work > better > > >>> if all three VC use the same codec. > > >>> > > >>> I do not see an endpoint receiving hundreds of streams or a large > > >> full > > >>> mesh conference as a valid use case. > > >> > > >> Suppose we have an MCU with many (e.g. hundreds) of captures > coming > > >> into it. > > >> > > >> And then suppose the MCU wants to advertise a switched capture > that > > >> switches among all of those. > > >> > > >> IIUC, you would represent that as a single m-line for the switched > > >> capture, but with any one of the many SSRCs indicating which > capture > > >> was being sent at any given time. > > >> > > >> But then how does the recipient discover which of the switched > > >> captures it is receiving? And how does it sort out which SSRCs > > >> correspond to the switched capture, vs. others that correspond to > > >> other captures in the capture set mapped to the same RTP > addr/port? > > >> > > >> Thanks, > > >> Paul > > >> _______________________________________________ > > >> 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 christer.holmberg@ericsson.com Tue Feb 14 23: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 8A61A21F8595 for ; Tue, 14 Feb 2012 23:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[AWL=1.168, 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 dfgpNlvUUKqC for ; Tue, 14 Feb 2012 23:36:56 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 381E221F8594 for ; Tue, 14 Feb 2012 23:36:50 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-4e-4f3b609159d1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 00.CA.01970.1906B3F4; Wed, 15 Feb 2012 08:36:49 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 15 Feb 2012 08:36:49 +0100 From: Christer Holmberg To: Jonathan Lennox , Roni Even , "clue@ietf.org" Date: Wed, 15 Feb 2012 08:36:47 +0100 Thread-Topic: [clue] comment on draft-lennox-clue-rtp-usage-0 Thread-Index: AczqQZbet2tZzr5TTIGnqnddD7r6fQAJqSIQAFMAVzA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D87DE16@ESESSCMS0356.eemea.ericsson.se> References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> 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_7F2072F1E0DE894DA4B517B93C6A05852C3D87DE16ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 15 Feb 2012 07:36:58 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87DE16ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Just a reminder, that BUNDLE is only about multiple m- lines sharing the sa= me port number. It does not prevent you from, within a single m- line, e.g.= having multiple SSRC-multiplexed streams. One of the ideas in RTCWEB has been to have one audio m- line, and one vide= o m- line, sharing the same port number (using BUNDLE), but those m- lines = can then contain multiple streams. Regards, Christer ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Jon= athan Lennox Sent: 13. helmikuuta 2012 18:08 To: Roni Even; clue@ietf.org Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 Hi, Roni - I don't think my draft discusses "codec information" at all, at least as I = understand the term, so I'm not sure quite what you mean by it. As for BUNDLE, I think it'll emerge that it doesn't work or scale well for = complicated cases (e.g., cases where you have many potential captures, or w= here a source moves between captures, or where a single source could be sen= t for more than one capture simultaneously). Also, to avoid confusion, when you say "stream," what do you mean? The ter= m (unfortunately) means very different things in SDP and in RTP - in the fo= rmer case, it's the thing identified by an m=3D line (and thus, pre-BUNDLE,= a transport flow), whereas in the latter case, it's the thing identified b= y an SSRC. So I'm not quite sure what your draft, and this e-mail, is disc= ussing. - Jonathan Lennox jonathan@vidyo.com From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Monday, February 13, 2012 6:21 AM To: clue@ietf.org Subject: [clue] comment on draft-lennox-clue-rtp-usage-0 Hi, My view is that there are two separate problems that the draft discusses: 1. The co-relation between the media capture and the codec informatio= n in the offer answer 2. Multiplexing multiple media streams. I think that the second problem is addressed in http://tools.ietf.org/html/= draft-holmberg-mmusic-sdp-bundle-negotiation-00 As for the mapping I have a proposal to use a capture set group in the SDP = for the ampping Roni --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87DE16ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Just a reminder, that BUNDLE is only about multipl= e m-=20 lines sharing the same port number. It does not prevent you from, within a= =20 single m- line, e.g. having multiple SSRC-multiplexed=20 streams.
 
One of the ideas in RTCWEB has been to have one au= dio m-=20 line, and one video m- line, sharing the same port number (using BUNDLE), b= ut=20 those m- lines can then contain multiple streams.
 
Regards,
 
Christer
 
From: clue-bounces@ietf.org=20 [mailto:clue-bounces@ietf.org] On Behalf Of Jonathan=20 Lennox
Sent: 13. helmikuuta 2012 18:08
To: Roni Even;=20 clue@ietf.org
Subject: Re: [clue] comment on=20 draft-lennox-clue-rtp-usage-0

Hi, Roni –

 

I don’t think my = draft discusses=20 “codec information” at all, at least as I understand the term, = so I’m not sure=20 quite what you mean by it.

 

As for BUNDLE, I think = it’ll=20 emerge that it doesn’t work or scale well for complicated cases (e.g.= , cases=20 where you have many potential captures, or where a source moves between=20 captures, or where a single source could be sent for more than one capture= =20 simultaneously).

 

Also, to avoid confusio= n, when=20 you say “stream,” what do you mean?  The term (unfortunate= ly) means very=20 different things in SDP and in RTP – in the former case, it’s t= he thing=20 identified by an m=3D line (and thus, pre-BUNDLE, a transport flow), wherea= s in=20 the latter case, it’s the thing identified by an SSRC.  So IR= 17;m not quite=20 sure what your draft, and this e-mail, is discussing.

 

–

Jonathan=20 Lennox

jonathan@vidyo.com

 

From:<= /B> Roni Even=20 [mailto:ron.even.tlv@gmail.com]
Sent: Monday, February 13, 2012 = 6:21=20 AM
To: clue@ietf.org
Subject: [clue] comment on=20 draft-lennox-clue-rtp-usage-0

 

Hi,

My view is that there are two separate problems that t= he=20 draft discusses:

 

1. &nbs= p;    =20 The co-relation between the media capture and the codec information = in=20 the offer answer

2. &nbs= p;    =20 Multiplexing multiple media streams.

 

I think that the second problem is addressed in http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-negoti= ation-00=20

As for the mapping I have a proposal to use a capture = set=20 group in the SDP for the ampping

Roni

--_000_7F2072F1E0DE894DA4B517B93C6A05852C3D87DE16ESESSCMS0356e_-- From ron.even.tlv@gmail.com Wed Feb 15 02:00: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 9EE7321F87D0 for ; Wed, 15 Feb 2012 02:00:37 -0800 (PST) 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=[AWL=0.000, 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 b0-WVd295KQM for ; Wed, 15 Feb 2012 02:00:33 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 626F921F87C1 for ; Wed, 15 Feb 2012 02:00:33 -0800 (PST) Received: by qan41 with SMTP id 41so820906qan.10 for ; Wed, 15 Feb 2012 02:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=UIrYxX2mD+jPihhzNZF3AzrX+h2V6b5V7CBN/gAoyKc=; b=We3/j9eeXuXkW9CTdEnLAV0xiVAniImlpIcZFPb6bwCCGZ5B/n5E2BU5NGX3F8NWMT ewZBhZYUqGDg5MYvKcrbrAOkHNYGKX+8Aqfp2fA4wjPZ3wNnyOdZE5e8z+ehQxo8H141 TMIkoNjYCserfnPR9IpTf+tz42KE352loV0KA= Received: by 10.229.136.19 with SMTP id p19mr14910656qct.133.1329300032899; Wed, 15 Feb 2012 02:00:32 -0800 (PST) Received: from windows8d787f9 (75-147-4-157-NewEngland.hfc.comcastbusiness.net. [75.147.4.157]) by mx.google.com with ESMTPS id g16sm9621945qah.6.2012.02.15.02.00.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 02:00:31 -0800 (PST) From: "Roni Even" To: "'Allyn Romanow \(allyn\)'" , "'Paul Kyzivat'" References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> <4f394fd7.4c200e0a.14fd.ffffc4b2@mx.google.com><4F395367.8050504@alum.mit.edu><4f395a76.11840e0a.1d12.ffffac02@mx.google.com><4F3AD71E.7030503@alum.mit.edu> <4f3b2e51.0aaee00a.45b8.fffff1e8@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06C5E403@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06C5E403@xmb-sjc-221.amer.cisco.com> Date: Wed, 15 Feb 2012 12:00:16 +0200 Message-ID: <4f3b823f.903ae00a.7503.0c59@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: AczrYqcerV7UkX7lQuqiv+hiUfKaKQAM0yPgAAMiYOAACUQmUA== Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 15 Feb 2012 10:00:37 -0000 Allyn, Do you see CLUE replacing any of the SDP information like describing all the RTP streams that will be sent and received in a call? For example for a video switch MCU do you see the following done in CLUE and not in SDP? m=video 49170 RTP/AVP 98 a=ssrc:SSRC-B cname:CNAME-B a=ssrc:SSRC-C cname:CNAME-C a=ssrc:SSRC-D cname:CNAME-D a=ssrc:SSRC-B fmtp:98 sprop-parameter-sets= a=ssrc:SSRC-C fmtp:98 sprop-parameter-sets= a=ssrc:SSRC-D fmtp:98 sprop-parameter-sets= a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 packetization-mode=1 Roni > -----Original Message----- > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > Sent: Wednesday, February 15, 2012 7:35 AM > To: Roni Even; Paul Kyzivat > Cc: clue@ietf.org > Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0 > > Perhaps I've misunderstand what you meant Roni, but I am surprised by > your comment. > Ground rules? Aren't we considering alternate architectures that work > best, rather than having ground-rules based on assumptions on how > things will be done? > > Don't we have a ways to go yet to understand where offer/answer is > viable for CLUE, and where it is not? and then to evaluate different > possible solutions for where the current infrastructure may not work > for CLUE? > > Allyn > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Roni Even > > Sent: Tuesday, February 14, 2012 8:02 PM > > To: 'Paul Kyzivat' > > Cc: clue@ietf.org > > Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > Hi Paul, > > I think that the discussion should start with the ground rules. > > My assumption is that we have a SIP offer/answer that provides in the > > SDP all the RTP streams that may be used with the relevant parameters > > like profile and level and the other optional parameters. In parallel > > we have the CLUE information which describes the semantics of the > > streams based on purpose and co-ordinates. > > There need to be mapping between them. > > For multipoint case if we want to convey what we call roster > > information there is the conference event package. > > BR > > Roni > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > > Sent: Tuesday, February 14, 2012 11:50 PM > > > To: Roni Even > > > Cc: clue@ietf.org > > > Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > > > On 2/13/12 1:45 PM, Roni Even wrote: > > > > Hi Paul, > > > > This is what the conference event package is for Roni > > > > > > Hmm. Maybe there is some way to make that work. But I'm not > > convinced. > > > I think the discussion of RTP usage this week will be lively and > > > mutually educational. > > > > > > Thanks, > > > Paul > > > > > > >> -----Original Message----- > > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > > >> Of Paul Kyzivat > > > >> Sent: Monday, February 13, 2012 8:16 PM > > > >> To: clue@ietf.org > > > >> Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > >> > > > >> Roni - at end > > > >> > > > >> On 2/13/12 1:00 PM, Roni Even wrote: > > > >>> Hi Jonathan, > > > >>> > > > >>> First to clarify, when I say media capture I refer to the CLUE > > > >>> description on the semantics of the data. Stream is the RTP > > stream. > > > >> In > > > >>> SDP I do not differentiate between the case where you have an > m- > > > line > > > >>> for each RTP media stream or you multiplex them using SSRC. The > > > >> bundle > > > >>> draft still has an m-line for each RTP stream. The difference > is > > > >>> that without bundle they each one is an RTP session while in > the > > > >>> bundle case at least for now they are all part of the same RTP > > > session. > > > >>> > > > >>> Now I am not sure what you mean when you are talking about > > hundreds > > > >> of > > > >>> descriptions. > > > >>> > > > >>> In the point to point the number of RTP streams described in > the > > > SDP > > > >>> should probably be the number of media captures in the capture > > set > > > >>> entry with the largest number of MCs, see the draft I submitted > > > >> yesterday. > > > >>> > > > >>> In the multipoint case I assume that we are only talking about > an > > > >>> MCU that serves as a central signaling point and not about some > > > >>> distributed signaling. In this case the MCU receives all MCs > and > > > the > > > >>> SDP from all end point it needs to provide all MCs if it wants > > but > > > >>> as for the SDP it only need to provide the number of m-lines > > (using > > > >>> bundle) that will allow him to send and receive the maximum > that > > > the > > > >>> end point will receive simultaneously. The content of each of > > these > > > >>> RTP streams or channels will change based on the current > > configured > > > >> capture set entry. > > > >>> For example in your 2 out of three the number of m-lines or RTP > > > >>> streams will be two. The content inside will change using the > > SSRC > > > >>> to identify the specific one. BTW: I think that it will work > > better > > > >>> if all three VC use the same codec. > > > >>> > > > >>> I do not see an endpoint receiving hundreds of streams or a > large > > > >> full > > > >>> mesh conference as a valid use case. > > > >> > > > >> Suppose we have an MCU with many (e.g. hundreds) of captures > > coming > > > >> into it. > > > >> > > > >> And then suppose the MCU wants to advertise a switched capture > > that > > > >> switches among all of those. > > > >> > > > >> IIUC, you would represent that as a single m-line for the > switched > > > >> capture, but with any one of the many SSRCs indicating which > > capture > > > >> was being sent at any given time. > > > >> > > > >> But then how does the recipient discover which of the switched > > > >> captures it is receiving? And how does it sort out which SSRCs > > > >> correspond to the switched capture, vs. others that correspond > to > > > >> other captures in the capture set mapped to the same RTP > > addr/port? > > > >> > > > >> 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 Wed Feb 15 02:06: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 4D61821F87D0 for ; Wed, 15 Feb 2012 02:06:41 -0800 (PST) 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=[AWL=-0.000, 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 lnhjDFSen2uR for ; Wed, 15 Feb 2012 02:06:37 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B06D421F87A1 for ; Wed, 15 Feb 2012 02:06:36 -0800 (PST) Received: by qan41 with SMTP id 41so826022qan.10 for ; Wed, 15 Feb 2012 02:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=pvouXsHSxZg7fulP5Z0So76Oy9NLFXKOZnmb65cFSB8=; b=jgRR754IK5afFWyfBuBGlk94/zgGS6FLip2NzDXwf8IrWcgmnWqkaEVsBFw62It4BX jPkqhFha95zmP0uV4ETohdYOm8kIs+gp57kJe6dbLSsod0S3dW0TOwJamgCepyQEm3lz TPoJSB9WszKaIR0RGn1P151nP9uEjaRT+lOTk= Received: by 10.229.136.16 with SMTP id p16mr15068174qct.24.1329300396104; Wed, 15 Feb 2012 02:06:36 -0800 (PST) Received: from windows8d787f9 (75-147-4-157-NewEngland.hfc.comcastbusiness.net. [75.147.4.157]) by mx.google.com with ESMTPS id dk2sm9621261qab.12.2012.02.15.02.06.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 02:06:35 -0800 (PST) From: "Roni Even" To: "'Christer Holmberg'" , "'Jonathan Lennox'" , References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D87DE16@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D87DE16@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Feb 2012 12:06:19 +0200 Message-ID: <4f3b83ab.02bfe00a.55f8.1234@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A3_01CCEBDA.3AE3D770" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczqQZbet2tZzr5TTIGnqnddD7r6fQAJqSIQAFMAVzAABSmL0A== Content-Language: en-us Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 15 Feb 2012 10:06:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A3_01CCEBDA.3AE3D770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Christer, I assume BUNDLE allows you also to provide the multiplexing information also for multiple m-lines of the same media type, one example if they represent different contend using the SDP content attribute to describe each stream. It provides you one more degree a freedom when describing the media streams Roni From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, February 15, 2012 9:37 AM To: Jonathan Lennox; Roni Even; clue@ietf.org Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0 Hi, Just a reminder, that BUNDLE is only about multiple m- lines sharing the same port number. It does not prevent you from, within a single m- line, e.g. having multiple SSRC-multiplexed streams. One of the ideas in RTCWEB has been to have one audio m- line, and one video m- line, sharing the same port number (using BUNDLE), but those m- lines can then contain multiple streams. Regards, Christer _____ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Jonathan Lennox Sent: 13. helmikuuta 2012 18:08 To: Roni Even; clue@ietf.org Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 Hi, Roni - I don't think my draft discusses "codec information" at all, at least as I understand the term, so I'm not sure quite what you mean by it. As for BUNDLE, I think it'll emerge that it doesn't work or scale well for complicated cases (e.g., cases where you have many potential captures, or where a source moves between captures, or where a single source could be sent for more than one capture simultaneously). Also, to avoid confusion, when you say "stream," what do you mean? The term (unfortunately) means very different things in SDP and in RTP - in the former case, it's the thing identified by an m= line (and thus, pre-BUNDLE, a transport flow), whereas in the latter case, it's the thing identified by an SSRC. So I'm not quite sure what your draft, and this e-mail, is discussing. - Jonathan Lennox jonathan@vidyo.com From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Monday, February 13, 2012 6:21 AM To: clue@ietf.org Subject: [clue] comment on draft-lennox-clue-rtp-usage-0 Hi, My view is that there are two separate problems that the draft discusses: 1. The co-relation between the media capture and the codec information in the offer answer 2. Multiplexing multiple media streams. I think that the second problem is addressed in http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-negotiation-00 As for the mapping I have a proposal to use a capture set group in the SDP for the ampping Roni ------=_NextPart_000_00A3_01CCEBDA.3AE3D770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

I assume BUNDLE allows = you also to provide the multiplexing information also for multiple = m-lines of the same media type, one example if they represent different = contend using the SDP content attribute to describe each stream. It = provides you one more degree a freedom when describing the media = streams

 

Roni

From:= = Christer Holmberg [mailto:christer.holmberg@ericsson.com] =
Sent: Wednesday, February 15, 2012 9:37 AM
To: = Jonathan Lennox; Roni Even; clue@ietf.org
Subject: RE: [clue] = comment on = draft-lennox-clue-rtp-usage-0

 

Hi= ,

 

Ju= st a reminder, that BUNDLE is only about multiple m- lines sharing the = same port number. It does not prevent you from, within a single m- line, = e.g. having multiple SSRC-multiplexed streams.

 

On= e of the ideas in RTCWEB has been to have one audio m- line, and one = video m- line, sharing the same port number (using BUNDLE), but those m- = lines can then contain multiple streams.

 

Re= gards,

 

Ch= rister

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Jonathan Lennox
Sent: 13. helmikuuta 2012 = 18:08
To: Roni Even; clue@ietf.org
Subject: Re: = [clue] comment on draft-lennox-clue-rtp-usage-0

Hi, Roni –

 

I don’t think my = draft discusses “codec information” at all, at least as I = understand the term, so I’m not sure quite what you mean by = it.

 

As for BUNDLE, I think = it’ll emerge that it doesn’t work or scale well for = complicated cases (e.g., cases where you have many potential captures, = or where a source moves between captures, or where a single source could = be sent for more than one capture = simultaneously).

 

Also, to avoid = confusion, when you say “stream,” what do you mean?  = The term (unfortunately) means very different things in SDP and in RTP = – in the former case, it’s the thing identified by an m=3D = line (and thus, pre-BUNDLE, a transport flow), whereas in the latter = case, it’s the thing identified by an SSRC.  So I’m not = quite sure what your draft, and this e-mail, is = discussing.

 

– =

Jonathan Lennox

jonathan@vidyo.com

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]=
Sent: Monday, February 13, 2012 6:21 AM
To: clue@ietf.org
Subject: = [clue] comment on = draft-lennox-clue-rtp-usage-0

 

Hi,

My view is that = there are two separate problems that the draft = discusses:

 

1.       The = co-relation between the media capture and the codec information in the = offer answer

2.       Multiplexing = multiple media streams.

 

I think that = the second problem is addressed in http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-bundle-ne= gotiation-00

As for the mapping = I have a proposal to use a capture set group in the SDP for the = ampping

Roni

------=_NextPart_000_00A3_01CCEBDA.3AE3D770-- From christer.holmberg@ericsson.com Wed Feb 15 02:18:36 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 5A28821F85BD for ; Wed, 15 Feb 2012 02:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.479 X-Spam-Level: X-Spam-Status: No, score=-9.479 tagged_above=-999 required=5 tests=[AWL=1.120, 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 MVIREaqY9xPG for ; Wed, 15 Feb 2012 02:18:32 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E413A21F85AD for ; Wed, 15 Feb 2012 02:18:27 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-db-4f3b8672e6c6 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 81.5A.27041.2768B3F4; Wed, 15 Feb 2012 11:18:26 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 15 Feb 2012 11:18:26 +0100 From: Christer Holmberg To: Roni Even , 'Jonathan Lennox' , "clue@ietf.org" Date: Wed, 15 Feb 2012 11:18:24 +0100 Thread-Topic: [clue] comment on draft-lennox-clue-rtp-usage-0 Thread-Index: AczqQZbet2tZzr5TTIGnqnddD7r6fQAJqSIQAFMAVzAABSmL0AAAhrpg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D87E01B@ESESSCMS0356.eemea.ericsson.se> References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D87DE16@ESESSCMS0356.eemea.ericsson.se> <4f3b83ab.02bfe00a.55f8.1234@mx.google.com> In-Reply-To: <4f3b83ab.02bfe00a.55f8.1234@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 15 Feb 2012 10:18:36 -0000 Hi,=20 > I assume BUNDLE allows you also to provide the multiplexing information a= lso for multiple m-lines of the same media type, one=20 > example if they represent different contend using the SDP content attribu= te to describe each stream. It provides you one more=20 > degree a freedom when describing the media streams Sure. BUNDLE does not put any restrictions on the number of m- lines, numbe= r of m- lines with the same media type, etc. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Wednesday, February 15, 2012 9:37 AM To: Jonathan Lennox; Roni Even; clue@ietf.org Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0 =20 Hi, =20 Just a reminder, that BUNDLE is only about multiple m- lines sharing the sa= me port number. It does not prevent you from, within a single m- line, e.g.= having multiple SSRC-multiplexed streams. =20 One of the ideas in RTCWEB has been to have one audio m- line, and one vide= o m- line, sharing the same port number (using BUNDLE), but those m- lines = can then contain multiple streams. =20 Regards, =20 Christer =20 ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Jon= athan Lennox Sent: 13. helmikuuta 2012 18:08 To: Roni Even; clue@ietf.org Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 Hi, Roni - =20 I don't think my draft discusses "codec information" at all, at least as I = understand the term, so I'm not sure quite what you mean by it. =20 As for BUNDLE, I think it'll emerge that it doesn't work or scale well for = complicated cases (e.g., cases where you have many potential captures, or w= here a source moves between captures, or where a single source could be sen= t for more than one capture simultaneously). =20 Also, to avoid confusion, when you say "stream," what do you mean? The ter= m (unfortunately) means very different things in SDP and in RTP - in the fo= rmer case, it's the thing identified by an m=3D line (and thus, pre-BUNDLE,= a transport flow), whereas in the latter case, it's the thing identified b= y an SSRC. So I'm not quite sure what your draft, and this e-mail, is disc= ussing. =20 -=20 Jonathan Lennox jonathan@vidyo.com =20 From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Monday, February 13, 2012 6:21 AM To: clue@ietf.org Subject: [clue] comment on draft-lennox-clue-rtp-usage-0 =20 Hi, My view is that there are two separate problems that the draft discusses: =20 1. The co-relation between the media capture and the codec informatio= n in the offer answer 2. Multiplexing multiple media streams. =20 I think that the second problem is addressed in http://tools.ietf.org/html/= draft-holmberg-mmusic-sdp-bundle-negotiation-00=20 As for the mapping I have a proposal to use a capture set group in the SDP = for the ampping Roni From john@jlc.net Wed Feb 15 03:53: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 B736C21F8752 for ; Wed, 15 Feb 2012 03:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.391 X-Spam-Level: X-Spam-Status: No, score=-106.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 TEym1k7BFgqy for ; Wed, 15 Feb 2012 03:53:03 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A7EF421F86FC for ; Wed, 15 Feb 2012 03:53:02 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5A80533C20; Wed, 15 Feb 2012 06:53:00 -0500 (EST) Date: Wed, 15 Feb 2012 06:53:00 -0500 From: John Leslie To: "Espen Berger (espeberg)" Message-ID: <20120215115300.GY61963@verdi> References: <4F3046C9.4060401@alum.mit.edu> <20120208215905.GP61963@verdi> <92DF9533227FC14F946C7321074B8C9EEC5B0C@XMB-AMS-214.cisco.com> <20120213162307.GW61963@verdi> <92DF9533227FC14F946C7321074B8C9EF45166@XMB-AMS-214.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92DF9533227FC14F946C7321074B8C9EF45166@XMB-AMS-214.cisco.com> User-Agent: Mutt/1.4.1i Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates 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, 15 Feb 2012 11:53:03 -0000 Espen Berger (espeberg) wrote: > > Discussions of Audio recording and playback is something that will > benefits from a whiteboard! Indeed... especially a three-dimensional one! ;^) > From: John Leslie [mailto:john@jlc.net] >> Espen Berger (espeberg) wrote: >> >>> "User Bob is in a call with Alice, Bob see that Alice is standing left >>> in the video stream. Bob wants to hear the audio from Alice being from >>> the left side" >> >> It's _really_ not that simple. > > [Espen Berger (espeberg)] My use case is this simple, other use cases > might be more complex. With a single speaker in a room, dynamic speaker > position work nicely. We really ought to come up with a better way of distinguishing a human speaking from an audio transducer... There are use-cases simple enough to be processed into a position in a stereo or surround system -- I don't find them interesting... >> Having mono audio bounce between speakers will sort-of work if we're >> all agreed there are only two speakers. If there are more than two, it >> won't work at all. > > [Espen Berger (espeberg)] I do not see that modeling more than two > active talkers is hard. To do proper playback is hard, but last resort > is always to mix all audio together and play back on a single speaker. Indeed, that works. >>> * A single audio stream is enough >> >> Enough for what? > > [Espen Berger (espeberg)] Enough to play out on active talker in any > position, as long as you receive the dynamic position information. Well, no. If we're dealing with a lapel mike in a reasonably dead room, we can process that into a "position" in stereo / surround. In practice, it's seldom that straightforward. Folks share microphones, the room is too noisy, echos become too confusing... >>> * If dynamic speaker position is sent, you could play out the audio >>> in the correct position >> >> There-Ain't-No-Such-Thing-As-A "correct position". :^( >> >> We're trying to create a virtual room; and except in the trivial case >> where one room has half the speakers and a second room has the other >> half, we're reduced to asking the participants to suspend their >> disbelief that they're in this virtual room. > > [Espen Berger (espeberg)] The term Virtual room is not well defined. My bad. I see that my post could be read to ask CLUE to define a virtual room. That was not my intent. It's merely how I think about the audio issue: others are free to think about it differently. I think about it that way because that is my model of how _participants_ experience telepresence: they're in a room which doesn't actually exist, but "feels" like it does. >> For that trivial case, we can treat each set of screens as a virtual >> glass partition, let participants listen to the folks on their side >> without any amplification, and reproduce the audio which "would" pass >> through the partition if it weren't there. >> >> (There _will_ be some extended echo problems, but those can be >> managed.) > > [Espen Berger (espeberg)] AFAIK the echo cancelation is a implementation > challenge more than a modeling challenge. Actually, there is a modeling challenge there -- to accurately map the delay times so the jitter doesn't kill you... But I inherently don't trust "echo cancellation" algorithms. They work pretty well in simple cases (two speakers, no jitter), but fall apart when you switch more speakers in and out in the presence of jitter. >> IMHO, the critical information is the _virtual_ position of the >> speaker, My bad, again. :^( For _my_ rendering purposes, I need this virtual position. That does _not_ mean it needs to be the same as any other renderer's virtual position for that (human) speaker. >> the actual position of the microphone, and _perhaps_ the relative actual >> position of the speaker to the microphone. Room acoustics is a critical >> part of how humans "place" a sound source; and screwing up the room >> acoustics to "help" them won't help. (IMHO, of course...) > > [Espen Berger (espeberg)] I still believe that the capture room is > better at figuring out the speaker position than the reproducing room. Agreed, the capture room has better information with which to guess the (human) speaker postion. But the rendering room must take responsibility for the audio experience of its occupants. Trusting the capture room too much about the physical positions of its occupants is hazardous. > At capture time you can do pre-processing if needed to calculate > position and also mix multiple microphone inputs together into a single > audio stream, e.g. when two microphones picks up the audio from the same > speaker. Indeed you can -- though for the most part I wish you wouldn't. Calculating position should be harmless (assuming you don't change the audio being captured); but mixing two audio streams screws with the room acoustics. My intended point, really, is that I prefer knowing microphone positions to guessing (human) speaker positions. Were I to accurately map each microphone audio capture to a virtual audio transducer in my corresponding virtual room (and not change things too suddenly), the human listeners would pretty much work it out by themselves. What does this mean to a CLUE protocol? Not a whole lot, perhaps. If someone is mixing audio to create the streams sent, I want to be warned: other than that, I really want microphone positions. -- John Leslie From johaniel@cisco.com Wed Feb 15 02:14: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 3F5DE21F8757 for ; Wed, 15 Feb 2012 02:14:50 -0800 (PST) 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 5nPAiiaS7EtQ for ; Wed, 15 Feb 2012 02:14:46 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1B79F21F874C for ; Wed, 15 Feb 2012 02:14:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johaniel@cisco.com; l=3770; q=dns/txt; s=iport; t=1329300882; x=1330510482; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=IINLGKBvIZcfVGrN84z+x3jVJoLiMfPBxiWRarf48YM=; b=JlnHjfXYzIYvteriEm+s9BKe/iG7PIV1yTkrEKzfHT0WstQsWAn+07gt zyKZu4XaIZFtWzhPyVN4gq8Xsw6Z3NenjuTEvSvSea4keOs7UxHACAEri haXvuUbwSn3y+MdHw59wtdnJVOFnYEiloOPA+O+KIwItXSDyWksBgc2tR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGSEO0+Q/khM/2dsb2JhbABDsEuBB4FyAQEBBAEBAQ8BChMKLgYEEwQCAQgRBAEBCwYXAQYBJh8JCAEBBBMIGodmmnkBnlkEi2sGEQYEFA0wg3IKDBIJBQQHgkdjBKgf X-IronPort-AV: E=Sophos;i="4.73,422,1325462400"; d="scan'208";a="129472409" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Feb 2012 10:14:40 +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 q1FAEeAL022282 for ; Wed, 15 Feb 2012 10:14:40 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); Wed, 15 Feb 2012 11:14:40 +0100 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, 15 Feb 2012 11:14:39 +0100 Message-ID: <05DD269BD82AA549BC4B2619BBAC466AD95D31@XMB-AMS-206.cisco.com> In-Reply-To: <4F356FB5.1090608@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Call for Consensus on framework spatial relationships Thread-Index: AczoKhsveQLyVrRaRw+TERiMAJUSkQDkWhmQ References: <4F356FB5.1090608@alum.mit.edu> From: "Johan Ludvig Nielsen (johaniel)" To: X-OriginalArrivalTime: 15 Feb 2012 10:14:40.0318 (UTC) FILETIME=[A0F42DE0:01CCEBCA] X-Mailman-Approved-At: Wed, 15 Feb 2012 04:14:25 -0800 Subject: Re: [clue] Call for Consensus on framework spatial relationships 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, 15 Feb 2012 10:20:16 -0000 Hi all I am new to this mailing list and haven't read the full history, so please forgive me if I go where you have already been. I have however followed the framework development, and work closely with Espen. As I understand the framework, media captures in a capture set may have spatial relationships, and these relationships are supposed to be fully described using the capture area attribute. My view is that the capture area coordinates are useful for describing static relationships of the capture devices in a physical capture scene. However, they may not be sufficient for describing relationships necessary for proper spatial rendering of video and audio in some usecases. Additional mechanisms for explicitly relating audio and video captures and/or expressing dynamically varying relationships may be necessary. I suggest to expand on the examples 11.1 and 11.3 in the framework to investigate this further. Specifically, to include more audio capabilities and test how the capture area concept works in a switched, pre-composed and/or dynamically changing situation. Take the example in 11.1. The consumer is free to pick the switched capture VC4 and the directional audio set of captures AC0-AC1-AC2. The spatial relationships between these captures are well defined by the capture area and can be used for rendering. But whether the rendering will be perceived as correct or not depends on which video segment is active at any given time, and which of the two persons on the segment is talking. The MCU example in 11.3 is an excellent usecase for directional audio, and multiple audio streams should be included as options for the various multi-screen consumers. To conclude on the capture area concept it is necessary to see how such a capture set is described, including the capture areas. How do they define relationships between streams. How does a 4-screen/4-speaker receiver and a 4-screen/2-speaker receiver know which streams to choose. The switched stream in 11.1 is an example where spatial relationships change during the course of the conference. The 11.3 MCU case may be another, depending on how multiple audio streams are composed. The static capture area concept is not well suited to convey such changes.=20 The active coordinate concept mentioned in A.5 can be one additional mechanism that complements the capture area (although it should not be mixed up with the VAD concept). I am in favour of consensus on the capture area coordinates, but I don't think the topic of spatial relationships is fully resolved. Regards Johan -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 10. februar 2012 20:28 To: CLUE Subject: [clue] Call for Consensus on framework spatial relationships CLUE WG participants: There has been a lot of discussion about coordinate systems and spatial relationships. The editors of the framework think they have reflected the group understanding of that topic in framework-03. (This is primarily in sections 5, 6.1.1, and 6.2.1, with an example in section 11.1) This is a request for everyone who cares to indicate if they are satisfied with the treatment of this topic. If not, please specify what you object to, in a constructive way. It would be helpful to have comments by the start of the interim meeting next Wed, Feb 15, so that they can be considered during discussions there. But that may be too tight for some people traveling. So lets set a secondary target date of Monday, Feb 20. Thanks, Paul (as co-chair) _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Feb 15 04:20: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 24A0F21F8799 for ; Wed, 15 Feb 2012 04:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 I5wXW1K+OqgM for ; Wed, 15 Feb 2012 04:20:40 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id F224421F864E for ; Wed, 15 Feb 2012 04:20:38 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 15 Feb 2012 04:20:37 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Wed, 15 Feb 2012 04:20:34 -0800 Thread-Topic: [clue] Call for Consensus on framework spatial relationships Thread-Index: AczoN4xu20EC5SujSaeGBIsa8YgvdQDpBt2g Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB3ED1A9@CRPMBOXPRD01.polycom.com> References: <4F356FB5.1090608@alum.mit.edu> <4F358646.4010108@alum.mit.edu> In-Reply-To: <4F358646.4010108@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] Call for Consensus on framework spatial relationships 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, 15 Feb 2012 12:20:41 -0000 Hi Paul, Some comments in line. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, February 10, 2012 4:04 PM > To: clue@ietf.org > Subject: Re: [clue] Call for Consensus on framework spatial relationships >=20 > (As individual) >=20 > Now I get to reply to myself. I've been meaning to make these comments > before but somehow didn't get to it: >=20 > * Identification of independent coordinate systems >=20 > Section 5 doesn't say much about this. It only says that systems without > multiple media captures to be spatially associated don't need a coordinat= e > system. This implies that captures in the same capture set should use the > same coordinate system. But a capture set is limited to captures of the s= ame > media type. So audio and video captures of the same room are different > capture sets. But to be related to one another they should share the same > coordinate system. [Duckworth, Mark] This is not correct. A capture set can contain entries o= f different media types. From section 6.2: "Capture sets will commonly include media captures of different types, for = instance, audio captures and video captures. " > ISTM that Capture Scene needs to be raised to first class status, and > separated from Capture Set. A coordinate system should be associated with > the Scene, and then Capture Sets should be subordinated to a specific Sce= ne. >=20 > This also impacts the specification of Purpose in 6.1.1. IIUC Purpose is = just an > incomplete identification of scene. Specifically, it assumes that a sourc= e > (room) has at most two scenes - the main one and one for presentations. > This seems quite limiting: =20 [Duckworth, Mark] It wasn't the intent to limit it to two scenes. > - certainly there can be multiple presentations. Each is likely to be > a separate scene in that it isn't spatially related to the other. > But a presentation could have both video capture and an audio capture > that should be related. (Its also possible that you have a "two > projector" presentation that has two video captures in a fixed > relationship to one another.) [Duckworth, Mark] Agree. > - there could be multiple independent endpoints in the same room. > Ideally they should share a coordinate system and an origin, so that > their captures can be related. (But its also possible that they > don't know about each other and don't share a coordinate system. > In that case I see little alternative to treating them as separate > scenes. But maybe this bears discussion.) [Duckworth, Mark] I don't understand how independent endpoints can share a = coordinate system. They would be signaling things completely independent o= f each other. > So, I propose that: >=20 > - Capture Scene becomes a first class entity, with its own attributes. > The Area of Scene, and Scale attribute should belong to it, > rather than to Capture Set. [Duckworth, Mark] Maybe, but the intent was that one capture set correspond= s to one scene. I'm not sure if there is a need to have multiple capture s= ets specifically associated with the same scene. > - each capture set should be associated with a capture scene. > (an attribute is the name, or some sort of reference, to the scene.) >=20 > - an endpoint may source capture sets from an arbitrary number of > capture scenes >=20 > - different endpoints can source capture sets from the same > capture scene. (Though this may be an unusual case.) >=20 > This will require some sort of naming system for scenes makes it easy for > each endpoint to have some unique names, but that also allows multiple > endpoints to reference some common names. The details of that are TBD. >=20 > * Area of Capture (Depth?) >=20 > I could swear that there was some discussion of depth of field that isn't > reflected in the current text. What is there now is four points in three-= space, > defining a quadrilateral, but without depth. I had thought there was goin= g to > be the possibility of eight points, describing a "quadrilaterally-faced > hexahedron". >=20 > Did I just imagine this? [Duckworth, Mark] I remember the topic being discussed, but I thought peopl= e generally agreed we did not need to represent depth in the area of captur= e. > A better way to do this might be to specify a quadrilateral and a camera > origin, with the intent that what is included is everything in the tetrah= edron > specified by those five points and extending beyond until it extends beyo= nd > the area of scene. [Duckworth, Mark] That is what we have today with area of capture and point= of capture. > * Area of Scene >=20 > Even more than area of capture, area of scene seems inadequate without > being specified as a volume. 2D might work if all the captures taken from= the > same origin. Otherwise not so much. This could be especially obvious if y= ou > have microphones scattered throughout a large room. It also doesn't work > for theater in the round. [Duckworth, Mark] I'm not sure specifying a volume of space instead of a qu= adrilateral will add anything useful. > Of course its complicated to specify a room with complex geometry. But > perhaps its sufficient for now to define it as a "quadrilaterally-faced > hexahedron", via eight points. >=20 > Thanks, > Paul From allyn@cisco.com Wed Feb 15 06:56: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 D7F6721E8018 for ; Wed, 15 Feb 2012 06:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.632 X-Spam-Level: X-Spam-Status: No, score=-9.632 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 RSeU4EjRzi-h for ; Wed, 15 Feb 2012 06:56:10 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8054621E8040 for ; Wed, 15 Feb 2012 06:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=7666; q=dns/txt; s=iport; t=1329317770; x=1330527370; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=VvrZ7VApcbFC3hk2ujZxZloAwr5ocR0drRFpSYE7kzU=; b=BKtJHmm9eEjqhRZl9vH74kxnwQHNtR7yE65ITh/rAG6qodOA2xOgI7OZ 6x0HE0tD0HmQVA/fDhCcxjMNXgsJJ1ycLJh+IFZ8+SKLeUzFUSW/3B2S2 +cHo6tUrBBqhbwewreyDY3iDG5En3F+6RieQd01+/KF3o+ONFU/Rlp/gj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGfHO0+rRDoJ/2dsb2JhbAA5Cg6wPoEHgXIBAQEEAQEBDwEdCi4GCwwEAgEIDgMEAQEBCgYXAQYBIAYfCQgBAQQBEggTB4dmmxIBnlgEiERSgkMFBQUDAQQBCQMCBAUEBwIIAQECAgQGg1oBXQ4CAQEJBQQHgkdjBIhNl3yHHlg X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="30550216" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 15 Feb 2012 14:55:49 +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 q1FEtmot014414; Wed, 15 Feb 2012 14:55:48 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, 15 Feb 2012 06:55:48 -0800 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, 15 Feb 2012 06:55:45 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06CFD9EB@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4f3b823f.903ae00a.7503.0c59@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] comment on draft-lennox-clue-rtp-usage-0 Thread-Index: AczrYqcerV7UkX7lQuqiv+hiUfKaKQAM0yPgAAMiYOAACUQmUAAE5n8g References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> <4f394fd7.4c200e0a.14fd.ffffc4b2@mx.google.com><4F395367.8050504@alum.mit.edu><4f395a76.11840e0a.1d12.ffffac02@mx.google.com><4F3AD71E.7030503@alum.mit.edu> <4f3b2e51.0aaee00a.45b8.fffff1e8@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06C5E403@xmb-sjc-221.amer.cisco.com> <4f3b823f.903ae00a.7503.0c59@mx.google.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Paul Kyzivat" X-OriginalArrivalTime: 15 Feb 2012 14:55:48.0659 (UTC) FILETIME=[E744C030:01CCEBF1] Cc: clue@ietf.org Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 15 Feb 2012 14:56:15 -0000 Hi Roni, Excellent question, thanks for clarifying your comment. No, I don't see CLUE replacing this SDP information. > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Wednesday, February 15, 2012 2:00 AM > To: Allyn Romanow (allyn); 'Paul Kyzivat' > Cc: clue@ietf.org > Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0 >=20 > Allyn, > Do you see CLUE replacing any of the SDP information like describing > all the > RTP streams that will be sent and received in a call? > For example for a video switch MCU do you see the following done in > CLUE and > not in SDP? >=20 >=20 >=20 > m=3Dvideo 49170 RTP/AVP 98 > a=3Dssrc:SSRC-B cname:CNAME-B > a=3Dssrc:SSRC-C cname:CNAME-C > a=3Dssrc:SSRC-D cname:CNAME-D > a=3Dssrc:SSRC-B fmtp:98 > sprop-parameter-sets=3D > a=3Dssrc:SSRC-C fmtp:98 > sprop-parameter-sets=3D > a=3Dssrc:SSRC-D fmtp:98 > sprop-parameter-sets=3D > a=3Drtpmap:98 H264/90000 > a=3Dfmtp:98 profile-level-id=3D42A01E; //Baseline profile, Level = 3.0 > packetization-mode=3D1 >=20 >=20 >=20 > Roni >=20 > > -----Original Message----- > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > Sent: Wednesday, February 15, 2012 7:35 AM > > To: Roni Even; Paul Kyzivat > > Cc: clue@ietf.org > > Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > Perhaps I've misunderstand what you meant Roni, but I am surprised by > > your comment. > > Ground rules? Aren't we considering alternate architectures that work > > best, rather than having ground-rules based on assumptions on how > > things will be done? > > > > Don't we have a ways to go yet to understand where offer/answer is > > viable for CLUE, and where it is not? and then to evaluate different > > possible solutions for where the current infrastructure may not work > > for CLUE? > > > > Allyn > > > > > > > -----Original Message----- > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > Of > > > Roni Even > > > Sent: Tuesday, February 14, 2012 8:02 PM > > > To: 'Paul Kyzivat' > > > Cc: clue@ietf.org > > > Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > > > Hi Paul, > > > I think that the discussion should start with the ground rules. > > > My assumption is that we have a SIP offer/answer that provides in > the > > > SDP all the RTP streams that may be used with the relevant > parameters > > > like profile and level and the other optional parameters. In > parallel > > > we have the CLUE information which describes the semantics of the > > > streams based on purpose and co-ordinates. > > > There need to be mapping between them. > > > For multipoint case if we want to convey what we call roster > > > information there is the conference event package. > > > BR > > > Roni > > > > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > > > Sent: Tuesday, February 14, 2012 11:50 PM > > > > To: Roni Even > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > > > > > On 2/13/12 1:45 PM, Roni Even wrote: > > > > > Hi Paul, > > > > > This is what the conference event package is for Roni > > > > > > > > Hmm. Maybe there is some way to make that work. But I'm not > > > convinced. > > > > I think the discussion of RTP usage this week will be lively and > > > > mutually educational. > > > > > > > > Thanks, > > > > Paul > > > > > > > > >> -----Original Message----- > > > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > Behalf > > > > >> Of Paul Kyzivat > > > > >> Sent: Monday, February 13, 2012 8:16 PM > > > > >> To: clue@ietf.org > > > > >> Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > >> > > > > >> Roni - at end > > > > >> > > > > >> On 2/13/12 1:00 PM, Roni Even wrote: > > > > >>> Hi Jonathan, > > > > >>> > > > > >>> First to clarify, when I say media capture I refer to the > CLUE > > > > >>> description on the semantics of the data. Stream is the RTP > > > stream. > > > > >> In > > > > >>> SDP I do not differentiate between the case where you have an > > m- > > > > line > > > > >>> for each RTP media stream or you multiplex them using SSRC. > The > > > > >> bundle > > > > >>> draft still has an m-line for each RTP stream. The difference > > is > > > > >>> that without bundle they each one is an RTP session while in > > the > > > > >>> bundle case at least for now they are all part of the same > RTP > > > > session. > > > > >>> > > > > >>> Now I am not sure what you mean when you are talking about > > > hundreds > > > > >> of > > > > >>> descriptions. > > > > >>> > > > > >>> In the point to point the number of RTP streams described in > > the > > > > SDP > > > > >>> should probably be the number of media captures in the > capture > > > set > > > > >>> entry with the largest number of MCs, see the draft I > submitted > > > > >> yesterday. > > > > >>> > > > > >>> In the multipoint case I assume that we are only talking > about > > an > > > > >>> MCU that serves as a central signaling point and not about > some > > > > >>> distributed signaling. In this case the MCU receives all MCs > > and > > > > the > > > > >>> SDP from all end point it needs to provide all MCs if it > wants > > > but > > > > >>> as for the SDP it only need to provide the number of m-lines > > > (using > > > > >>> bundle) that will allow him to send and receive the maximum > > that > > > > the > > > > >>> end point will receive simultaneously. The content of each of > > > these > > > > >>> RTP streams or channels will change based on the current > > > configured > > > > >> capture set entry. > > > > >>> For example in your 2 out of three the number of m-lines or > RTP > > > > >>> streams will be two. The content inside will change using the > > > SSRC > > > > >>> to identify the specific one. BTW: I think that it will work > > > better > > > > >>> if all three VC use the same codec. > > > > >>> > > > > >>> I do not see an endpoint receiving hundreds of streams or a > > large > > > > >> full > > > > >>> mesh conference as a valid use case. > > > > >> > > > > >> Suppose we have an MCU with many (e.g. hundreds) of captures > > > coming > > > > >> into it. > > > > >> > > > > >> And then suppose the MCU wants to advertise a switched capture > > > that > > > > >> switches among all of those. > > > > >> > > > > >> IIUC, you would represent that as a single m-line for the > > switched > > > > >> capture, but with any one of the many SSRCs indicating which > > > capture > > > > >> was being sent at any given time. > > > > >> > > > > >> But then how does the recipient discover which of the switched > > > > >> captures it is receiving? And how does it sort out which SSRCs > > > > >> correspond to the switched capture, vs. others that correspond > > to > > > > >> other captures in the capture set mapped to the same RTP > > > addr/port? > > > > >> > > > > >> 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 stewe@stewe.org Wed Feb 15 08:04: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 4956021F8718 for ; Wed, 15 Feb 2012 08:04:00 -0800 (PST) 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 KZN7kOznXWHe for ; Wed, 15 Feb 2012 08:03:59 -0800 (PST) Received: from DB3EHSOBE006.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2186321F8717 for ; Wed, 15 Feb 2012 08:03:57 -0800 (PST) Received: from mail23-db3-R.bigfish.com (10.3.81.236) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Feb 2012 16:03:56 +0000 Received: from mail23-db3 (localhost [127.0.0.1]) by mail23-db3-R.bigfish.com (Postfix) with ESMTP id F31AD605A2 for ; Wed, 15 Feb 2012 16:03:55 +0000 (UTC) X-SpamScore: 6 X-BigFish: PS6(zzc85ehzz1202h1082kzz8275bhz2fh2a8h668h839hbe3k) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT005.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail23-db3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT005.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail23-db3 (localhost.localdomain [127.0.0.1]) by mail23-db3 (MessageSwitch) id 1329321832227832_8041; Wed, 15 Feb 2012 16:03:52 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.247]) by mail23-db3.bigfish.com (Postfix) with ESMTP id 2B3A3C0045 for ; Wed, 15 Feb 2012 16:03:52 +0000 (UTC) Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Feb 2012 16:03:51 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.128]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0117.001; Wed, 15 Feb 2012 16:03:50 +0000 From: Stephan Wenger To: "clue@ietf.org" Thread-Topic: Language re capture axis Thread-Index: AQHM6/tnLytIKH/OzUOAFdCyR7eqWA== Date: Wed, 15 Feb 2012 16:03:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: multipart/alternative; boundary="_000_CB6141963839Cstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: [clue] Language re capture axis 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, 15 Feb 2012 16:04:00 -0000 --_000_CB6141963839Cstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The issue I mentioned in the meeting is that nowhere in the framework (as f= ar as I recall) the axis of capture of a video capture (or directional audi= o capture=97anything that is not omnidirectional) is undefined. Without th= at axis being defined, receiver-side geometric correction is not possible. The issue could be solved in two ways: include attributes, per capture, ind= icating angle of capture in 3D space (relative to what???), or by making th= e bold assumption that the coordinates defining area of capture plus captur= e point define the axis of capture. I suggest the latter as it is easy to = implement and (I believe) practical. The language could be something like: " Note that, for the purpose of receiver-side geometric correction, it can be= assumed that the axis of capture of directional capture devices (cameras, = directional microphones etc.) is the line from the capture point to the cen= ter of the plane of capture. " Stephan --_000_CB6141963839Cstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

The issue I mentioned in the meeting is that nowhere in the framework = (as far as I recall) the axis of capture of a video capture (or directional= audio capture=97anything that is not omnidirectional) is undefined.  = Without that axis being defined, receiver-side geometric correction is not possible.

The issue could be solved in two ways: include attributes, per capture= , indicating angle of capture in 3D space (relative to what???), or by maki= ng the bold assumption that the coordinates defining area of capture plus c= apture point define the axis of capture.  I suggest the latter as it is easy to implement and (I beli= eve) practical.

The language could be something like:

"
Note that, for the purpose of receiver-side geometric correction, it c= an be assumed that the axis of capture of directional capture devices (came= ras, directional microphones etc.) is the line from the capture point to th= e center of the plane of capture. 
"

Stephan


--_000_CB6141963839Cstewesteweorg_-- From allyn@cisco.com Wed Feb 15 08:14: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 6077F21F86C1 for ; Wed, 15 Feb 2012 08:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.023 X-Spam-Level: X-Spam-Status: No, score=-10.023 tagged_above=-999 required=5 tests=[AWL=0.575, 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 3DeypORINo7U for ; Wed, 15 Feb 2012 08:14:27 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id ABB4721F86B7 for ; Wed, 15 Feb 2012 08:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=7955; q=dns/txt; s=iport; t=1329322467; x=1330532067; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=Pme9DRhrF14r/8hYUtC17iAHaV+V9SXyJW6l+vfsicw=; b=Q3fDJUvziKrvXe8aRwoNcC2fELr/Pl7KHlTmsSp+Nh8ZndafQ7qsnZ9y MENOG6GMwT7T0Eo0AOITE/bo0ycRDcCKopbWgiM0qvr6YnHkvQF7cGOzZ P63vyxEAZZaKohFLfS+fOAejd40u8e8G/58jQ4ATT8o2IYmMcEHMkANj6 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPTYO0+rRDoJ/2dsb2JhbABDgk2tf4EHgXIBAQUSAQkRAzciAgEIDgMEAQELBhcBBgFFCQgBAQQBGhqjAAGeXYthCAICBQcIBwUMB4NnAQqDRWMEiE2fcg Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 15 Feb 2012 16:06:30 +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 q1FG6UaU014833; Wed, 15 Feb 2012 16:06:30 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, 15 Feb 2012 08:06:09 -0800 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_01CCEBFB.BB04FF91" Date: Wed, 15 Feb 2012 08:06:07 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06CFDA23@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4f327d59.d2130e0a.3e4f.ffffe95a@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] correlation between MC and SDP mline -- Review of draft-ietf-clue-framework-03 Thread-Index: AczmaGdy5PVDLQ8nRHK9EFLGxp4ZMQFkmKmw References: <4f327d59.d2130e0a.3e4f.ffffe95a@mx.google.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , X-OriginalArrivalTime: 15 Feb 2012 16:06:09.0605 (UTC) FILETIME=[BB25FF50:01CCEBFB] Subject: Re: [clue] correlation between MC and SDP mline -- Review of draft-ietf-clue-framework-03 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, 15 Feb 2012 16:14:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCEBFB.BB04FF91 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, There is already an attribute that correlates the VC with the encoding group, so that the consumer can know which Encodings it can potentially use for this VC. If the Encodings are carried in SDP, I believe the connection you are asking for will be made. If there were no encoding, as you suggest in another comment, then there would need to be a link between the capture and the media attribute, as you here suggest. I don't think the SSRC is appropriate because it may change, the mline in SDP would seem more appropriate. Regards, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, February 08, 2012 5:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 =20 Hi, =20 1. In section 6.1.1 I suggest adding an attribute that will correlate between the MC and the SDP m-line or SSRC of this media stream. =20 ------_=_NextPart_001_01CCEBFB.BB04FF91 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

There is already an attribute that correlates the VC with the encoding group, = so that the consumer can know which Encodings it can potentially use for this = VC.  If the Encodings are carried in SDP, I believe the connection you are = asking for will be made.

If there were no encoding, as you suggest in another comment, then there = would need to be a link between the capture and the media attribute, as you = here suggest. I don’t think the SSRC is appropriate because it may = change, the mline in SDP would seem more appropriate.

Regards,

Allyn

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Wednesday, February 08, 2012 5:49 AM
To: clue@ietf.org
Subject: [clue] Review of = draft-ietf-clue-framework-03

 

Hi,

 =

1.       In section 6.1.1 I suggest adding an attribute that will correlate between = the MC and the SDP m-line or SSRC of this media stream.

 =

------_=_NextPart_001_01CCEBFB.BB04FF91-- From mphmmr@gmail.com Wed Feb 15 12:22:43 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 ADB3721F84E4 for ; Wed, 15 Feb 2012 12:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.776, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=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 72H7NFa1+eeR for ; Wed, 15 Feb 2012 12:22:39 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 960FB21F84E2 for ; Wed, 15 Feb 2012 12:22:38 -0800 (PST) Received: by lahl5 with SMTP id l5so1664942lah.31 for ; Wed, 15 Feb 2012 12:22:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NowB2yIdgzcTQPhTbWVsUwVtH0h56zgQ7+Yb8D4S/10=; b=ZGUpHWop6lFabD1uyVCy0gc0Jcz/tBS5M6dMMcrsXxUeEaSPkbl5Kk1+KAxMFNkv8o SQjgc8qOs172laayvhqcwIRUQ2RpypIRZ8KaGxY6fEwKsMm6VtmLnfSZLCZtKJ+vvwuV emARgM8CcDnRxlNXHAGUT2C/iHORyMz8HqaWw= MIME-Version: 1.0 Received: by 10.152.148.230 with SMTP id tv6mr18438932lab.12.1329337357328; Wed, 15 Feb 2012 12:22:37 -0800 (PST) Received: by 10.112.104.70 with HTTP; Wed, 15 Feb 2012 12:22:37 -0800 (PST) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06CFD9EB@xmb-sjc-221.amer.cisco.com> References: <4f38f239.c77d0e0a.7414.fffff1b2@mx.google.com> <4f394fd7.4c200e0a.14fd.ffffc4b2@mx.google.com> <4F395367.8050504@alum.mit.edu> <4f395a76.11840e0a.1d12.ffffac02@mx.google.com> <4F3AD71E.7030503@alum.mit.edu> <4f3b2e51.0aaee00a.45b8.fffff1e8@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06C5E403@xmb-sjc-221.amer.cisco.com> <4f3b823f.903ae00a.7503.0c59@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06CFD9EB@xmb-sjc-221.amer.cisco.com> Date: Wed, 15 Feb 2012 15:22:37 -0500 Message-ID: From: Michael Hammer To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=e89a8f22c33ff862c504b90678ba Cc: clue@ietf.org Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 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, 15 Feb 2012 20:22:43 -0000 --e89a8f22c33ff862c504b90678ba Content-Type: text/plain; charset=ISO-8859-1 I have been watching this topic loosely to see how it develops. But, that is not always easy to follow. I like the analogy of the SDP defining who is on the roster of players that can be sent onto the pitch/field. Whereas, the new stuff defines who is actually playing at the moment and in what position. I would not expect the lineup sent to the referee to have to provide the height/weight and whatever stats ad nauseum of the player. So, would hope that those details are confined to the SDP and not replicated redundantly. A reference to each component should be sufficient, no? Also, do you expect to have free agents added to the roster at any time? That might be a new SDP offer/answer. (Does offer/answer also refer to the new stuff?) What is also not clear, not even within this thread is whether (perhaps unlike SDP) the sender is defining who should be on the field, or whether the crowd watching (receivers) are defining what is sent. Does the MCU define a consistent view of the game for everyone? Or, does each receiver command this and everyone gets their own view? >From the peanut gallery, Mike On Wed, Feb 15, 2012 at 9:55 AM, Allyn Romanow (allyn) wrote: > Hi Roni, > > Excellent question, thanks for clarifying your comment. No, I don't see > CLUE replacing this SDP information. > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Wednesday, February 15, 2012 2:00 AM > > To: Allyn Romanow (allyn); 'Paul Kyzivat' > > Cc: clue@ietf.org > > Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > Allyn, > > Do you see CLUE replacing any of the SDP information like describing > > all the > > RTP streams that will be sent and received in a call? > > For example for a video switch MCU do you see the following done in > > CLUE and > > not in SDP? > > > > > > > > m=video 49170 RTP/AVP 98 > > a=ssrc:SSRC-B cname:CNAME-B > > a=ssrc:SSRC-C cname:CNAME-C > > a=ssrc:SSRC-D cname:CNAME-D > > a=ssrc:SSRC-B fmtp:98 > > sprop-parameter-sets= > > a=ssrc:SSRC-C fmtp:98 > > sprop-parameter-sets= > > a=ssrc:SSRC-D fmtp:98 > > sprop-parameter-sets= > > a=rtpmap:98 H264/90000 > > a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 > > packetization-mode=1 > > > > > > > > Roni > > > > > -----Original Message----- > > > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] > > > Sent: Wednesday, February 15, 2012 7:35 AM > > > To: Roni Even; Paul Kyzivat > > > Cc: clue@ietf.org > > > Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > > > Perhaps I've misunderstand what you meant Roni, but I am surprised > by > > > your comment. > > > Ground rules? Aren't we considering alternate architectures that > work > > > best, rather than having ground-rules based on assumptions on how > > > things will be done? > > > > > > Don't we have a ways to go yet to understand where offer/answer is > > > viable for CLUE, and where it is not? and then to evaluate different > > > possible solutions for where the current infrastructure may not work > > > for CLUE? > > > > > > Allyn > > > > > > > > > > -----Original Message----- > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf > > > Of > > > > Roni Even > > > > Sent: Tuesday, February 14, 2012 8:02 PM > > > > To: 'Paul Kyzivat' > > > > Cc: clue@ietf.org > > > > Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > > > > > Hi Paul, > > > > I think that the discussion should start with the ground rules. > > > > My assumption is that we have a SIP offer/answer that provides in > > the > > > > SDP all the RTP streams that may be used with the relevant > > parameters > > > > like profile and level and the other optional parameters. In > > parallel > > > > we have the CLUE information which describes the semantics of the > > > > streams based on purpose and co-ordinates. > > > > There need to be mapping between them. > > > > For multipoint case if we want to convey what we call roster > > > > information there is the conference event package. > > > > BR > > > > Roni > > > > > > > > > -----Original Message----- > > > > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > > > > Sent: Tuesday, February 14, 2012 11:50 PM > > > > > To: Roni Even > > > > > Cc: clue@ietf.org > > > > > Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > > > > > > > On 2/13/12 1:45 PM, Roni Even wrote: > > > > > > Hi Paul, > > > > > > This is what the conference event package is for Roni > > > > > > > > > > Hmm. Maybe there is some way to make that work. But I'm not > > > > convinced. > > > > > I think the discussion of RTP usage this week will be lively and > > > > > mutually educational. > > > > > > > > > > Thanks, > > > > > Paul > > > > > > > > > > >> -----Original Message----- > > > > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > > > Behalf > > > > > >> Of Paul Kyzivat > > > > > >> Sent: Monday, February 13, 2012 8:16 PM > > > > > >> To: clue@ietf.org > > > > > >> Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0 > > > > > >> > > > > > >> Roni - at end > > > > > >> > > > > > >> On 2/13/12 1:00 PM, Roni Even wrote: > > > > > >>> Hi Jonathan, > > > > > >>> > > > > > >>> First to clarify, when I say media capture I refer to the > > CLUE > > > > > >>> description on the semantics of the data. Stream is the RTP > > > > stream. > > > > > >> In > > > > > >>> SDP I do not differentiate between the case where you have > an > > > m- > > > > > line > > > > > >>> for each RTP media stream or you multiplex them using SSRC. > > The > > > > > >> bundle > > > > > >>> draft still has an m-line for each RTP stream. The > difference > > > is > > > > > >>> that without bundle they each one is an RTP session while in > > > the > > > > > >>> bundle case at least for now they are all part of the same > > RTP > > > > > session. > > > > > >>> > > > > > >>> Now I am not sure what you mean when you are talking about > > > > hundreds > > > > > >> of > > > > > >>> descriptions. > > > > > >>> > > > > > >>> In the point to point the number of RTP streams described in > > > the > > > > > SDP > > > > > >>> should probably be the number of media captures in the > > capture > > > > set > > > > > >>> entry with the largest number of MCs, see the draft I > > submitted > > > > > >> yesterday. > > > > > >>> > > > > > >>> In the multipoint case I assume that we are only talking > > about > > > an > > > > > >>> MCU that serves as a central signaling point and not about > > some > > > > > >>> distributed signaling. In this case the MCU receives all MCs > > > and > > > > > the > > > > > >>> SDP from all end point it needs to provide all MCs if it > > wants > > > > but > > > > > >>> as for the SDP it only need to provide the number of m-lines > > > > (using > > > > > >>> bundle) that will allow him to send and receive the maximum > > > that > > > > > the > > > > > >>> end point will receive simultaneously. The content of each > of > > > > these > > > > > >>> RTP streams or channels will change based on the current > > > > configured > > > > > >> capture set entry. > > > > > >>> For example in your 2 out of three the number of m-lines or > > RTP > > > > > >>> streams will be two. The content inside will change using > the > > > > SSRC > > > > > >>> to identify the specific one. BTW: I think that it will work > > > > better > > > > > >>> if all three VC use the same codec. > > > > > >>> > > > > > >>> I do not see an endpoint receiving hundreds of streams or a > > > large > > > > > >> full > > > > > >>> mesh conference as a valid use case. > > > > > >> > > > > > >> Suppose we have an MCU with many (e.g. hundreds) of captures > > > > coming > > > > > >> into it. > > > > > >> > > > > > >> And then suppose the MCU wants to advertise a switched > capture > > > > that > > > > > >> switches among all of those. > > > > > >> > > > > > >> IIUC, you would represent that as a single m-line for the > > > switched > > > > > >> capture, but with any one of the many SSRCs indicating which > > > > capture > > > > > >> was being sent at any given time. > > > > > >> > > > > > >> But then how does the recipient discover which of the > switched > > > > > >> captures it is receiving? And how does it sort out which > SSRCs > > > > > >> correspond to the switched capture, vs. others that > correspond > > > to > > > > > >> other captures in the capture set mapped to the same RTP > > > > addr/port? > > > > > >> > > > > > >> 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 > --e89a8f22c33ff862c504b90678ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have been watching this topic loosely to see how it develops.
But, th= at is not always easy to follow.

I like the analog= y of the SDP defining who is on the roster of players that can be sent onto= the pitch/field.
Whereas, the new stuff defines who is actually playing at the moment a= nd in what position.

I would not expect the lineup= sent to the referee to have to provide the height/weight and whatever stat= s ad nauseum of the player.
So, would hope that those details are confined to the SDP and not repl= icated redundantly.
A reference to each component should be suffi= cient, no?
Also, do you expect to have free agents added to the r= oster at any time?
That might be a new SDP offer/answer. =A0(Does offer/answer also refer= to the new stuff?)

What is also not clear, not ev= en within this thread is whether (perhaps unlike SDP) the sender is definin= g who should be on the field,
or whether the crowd watching (receivers) are defining what is sent.
Does the MCU define a consistent view of the game for everyone?
Or, does each receiver command this and everyone gets their own vie= w?

From the peanut gallery,
Mike

<= /div>

On Wed, Feb 15, 2012 at 9:55 AM, A= llyn Romanow (allyn) <allyn@cisco.com> wrote:
Hi Roni,

Excellent question, thanks for clarifying your comment. No, I don't see=
CLUE replacing this SDP information.

> -----Original Message-----
> From: Roni Even [mailto:ron.= even.tlv@gmail.com]
> Sent: Wednesday, Februar= y 15, 2012 2:00 AM
> To: Allyn Romanow (allyn); 'Paul Kyzivat'
> Cc: clue@ietf.org
> Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0
>
> Allyn,
> Do you see CLUE replacing any of the SDP information like describing > all the
> RTP streams that will be sent and received in a call?
> For example for a video switch MCU do you see the following done in > CLUE and
> not in SDP?
>
>
>
> m=3Dvideo 49170 RTP/AVP 98
> =A0 =A0 =A0 a=3Dssrc:SSRC-B cname:CNAME-B
> =A0 =A0 =A0 a=3Dssrc:SSRC-C cname:CNAME-C
> =A0 =A0 =A0 a=3Dssrc:SSRC-D cname:CNAME-D
> =A0 =A0 =A0 a=3Dssrc:SSRC-B fmtp:98
> =A0 =A0 =A0 =A0 sprop-parameter-sets=3D<parameter sets data#B> > =A0 =A0 =A0 a=3Dssrc:SSRC-C fmtp:98
> =A0 =A0 =A0 =A0 sprop-parameter-sets=3D<parameter sets data#C> > =A0 =A0 =A0 a=3Dssrc:SSRC-D fmtp:98
> =A0 =A0 =A0 =A0 sprop-parameter-sets=3D<parameter sets data#D> > =A0 =A0 =A0 a=3Drtpmap:98 H264/90000
> =A0 =A0 =A0 a=3Dfmtp:98 profile-level-id=3D42A01E; //Baseline profile,= Level 3.0
> =A0 =A0 =A0 =A0 packetization-mode=3D1
>
>
>
> Roni
>
> > -----Original Message-----
> > From: Allyn Romanow (allyn) [mailto:allyn@cisco.com]
> > Sent: Wednesday, February 15, 2012 7:35 AM
> > To: Roni Even; Paul Kyzivat
> > Cc: clue@ietf.org
> > Subject: RE: [clue] comment on draft-lennox-clue-rtp-usage-0
> >
> > Perhaps I've misunderstand what you meant Roni, but I am surp= rised
by
> > your comment.
> > Ground rules? Aren't we considering alternate architectures t= hat
work
> > best, rather than having ground-rules based on assumptions on how=
> > things will be done?
> >
> > Don't we have a ways to go yet to understand where offer/answ= er is
> > viable for CLUE, and where it is not? and then to evaluate differ= ent
> > possible solutions for where the current infrastructure may not w= ork
> > for CLUE?
> >
> > Allyn
> >
> >
> > > -----Original Message-----
> > > From: clue-bounces@= ietf.org [mailto:clue-bounces@= ietf.org] On
> Behalf
> > Of
> > > Roni Even
> > > Sent: Tuesday, February 14, 2012 8:02 PM
> > > To: 'Paul Kyzivat'
> > > Cc: clue@ietf.org
> > > Subject: Re: [clue] comment on draft-lennox-clue-rtp-usage-0=
> > >
> > > Hi Paul,
> > > I think that the discussion should start with the ground rul= es.
> > > My assumption is that we have a SIP offer/answer that provid= es in
> the
> > > SDP all the RTP streams that may be used with the relevant > parameters
> > > like profile and level and the other optional parameters. In=
> parallel
> > > we have the CLUE information which describes the semantics o= f the
> > > streams based on purpose and co-ordinates.
> > > There need to be mapping between them.
> > > For multipoint case if we want to convey what we call roster=
> > > information there is the conference event package.
> > > BR
> > > Roni
> > >
> > > > -----Original Message-----
> > > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> > > > Sent: Tuesday, February 14, 2012 11:50 PM
> > > > To: Roni Even
> > > > Cc: clue@ietf.org<= br> > > > > Subject: Re: [clue] comment on draft-lennox-clue-rtp-us= age-0
> > > >
> > > > On 2/13/12 1:45 PM, Roni Even wrote:
> > > > > Hi Paul,
> > > > > This is what the conference event package is for R= oni
> > > >
> > > > Hmm. Maybe there is some way to make that work. But I&#= 39;m not
> > > convinced.
> > > > I think the discussion of RTP usage this week will be l= ively and
> > > > mutually educational.
> > > >
> > > > =A0 =A0 =A0 =A0 Thanks,
> > > > =A0 =A0 =A0 =A0 Paul
> > > >
> > > > >> -----Original Message-----
> > > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On
> > > Behalf
> > > > >> Of Paul Kyzivat
> > > > >> Sent: Monday, February 13, 2012 8:16 PM
> > > > >> To: clue@ietf= .org
> > > > >> Subject: Re: [clue] comment on draft-lennox-cl= ue-rtp-usage-0
> > > > >>
> > > > >> Roni - at end
> > > > >>
> > > > >> On 2/13/12 1:00 PM, Roni Even wrote:
> > > > >>> Hi Jonathan,
> > > > >>>
> > > > >>> First to clarify, when I say media capture= I refer to the
> CLUE
> > > > >>> description on the semantics of the data. = Stream is the RTP
> > > stream.
> > > > >> In
> > > > >>> SDP I do not differentiate between the cas= e where you have
an
> > m-
> > > > line
> > > > >>> for each RTP media stream or you multiplex= them using SSRC.
> The
> > > > >> bundle
> > > > >>> draft still has an m-line for each RTP str= eam. The
difference
> > is
> > > > >>> that without bundle they each one is an RT= P session while in
> > the
> > > > >>> bundle case at least for now they are all = part of the same
> RTP
> > > > session.
> > > > >>>
> > > > >>> Now I am not sure what you mean when you a= re talking about
> > > hundreds
> > > > >> of
> > > > >>> descriptions.
> > > > >>>
> > > > >>> In the point to point the number of RTP st= reams described in
> > the
> > > > SDP
> > > > >>> should probably be the number of media cap= tures in the
> capture
> > > set
> > > > >>> entry with the largest number of MCs, see = the draft I
> submitted
> > > > >> yesterday.
> > > > >>>
> > > > >>> In the multipoint case I assume that we ar= e only talking
> about
> > an
> > > > >>> MCU that serves as a central signaling poi= nt and not about
> some
> > > > >>> distributed signaling. In this case the MC= U receives all MCs
> > and
> > > > the
> > > > >>> SDP from all end point it needs to provide= all MCs if it
> wants
> > > but
> > > > >>> as for the SDP it only need to provide the= number of m-lines
> > > (using
> > > > >>> bundle) that will allow him to send and re= ceive the maximum
> > that
> > > > the
> > > > >>> end point will receive simultaneously. The= content of each
of
> > > these
> > > > >>> RTP streams or channels will change based = on the current
> > > configured
> > > > >> capture set entry.
> > > > >>> For example in your 2 out of three the num= ber of m-lines or
> RTP
> > > > >>> streams will be two. The content inside wi= ll change using
the
> > > SSRC
> > > > >>> to identify the specific one. BTW: I think= that it will work
> > > better
> > > > >>> if all three VC use the same codec.
> > > > >>>
> > > > >>> I do not see an endpoint receiving hundred= s of streams or a
> > large
> > > > >> full
> > > > >>> mesh conference as a valid use case.
> > > > >>
> > > > >> Suppose we have an MCU with many (e.g. hundred= s) of captures
> > > coming
> > > > >> into it.
> > > > >>
> > > > >> And then suppose the MCU wants to advertise a = switched
capture
> > > that
> > > > >> switches among all of those.
> > > > >>
> > > > >> IIUC, you would represent that as a single m-l= ine for the
> > switched
> > > > >> capture, but with any one of the many SSRCs in= dicating which
> > > capture
> > > > >> was being sent at any given time.
> > > > >>
> > > > >> But then how does the recipient discover which= of the
switched
> > > > >> captures it is receiving? And how does it sort= out which
SSRCs
> > > > >> correspond to the switched capture, vs. others= that
correspond
> > to
> > > > >> other captures in the capture set mapped to th= e same RTP
> > > addr/port?
> > > > >>
> > > > >> =A0 =A0 =A0Thanks,
> > > > >> =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
ht= tps://www.ietf.org/mailman/listinfo/clue

--e89a8f22c33ff862c504b90678ba-- From mary.ietf.barnes@gmail.com Wed Feb 15 15:58: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 4E0B321E807F for ; Wed, 15 Feb 2012 15:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.637 X-Spam-Level: X-Spam-Status: No, score=-103.637 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 6tvBD21Kn-qJ for ; Wed, 15 Feb 2012 15:58:21 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB54121E801D for ; Wed, 15 Feb 2012 15:58:21 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so1300590vcb.31 for ; Wed, 15 Feb 2012 15:58:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Q0lttvKpZSiO/bLt0+L+lavT/Bkx4T6pC3i2PlDGK6A=; b=kW/UO9Z3ZKRSA7uJlOe/Rbz4BNNuqDRRZEqej0JIpQzZWDX0+KaJqhD1cEc8lj7mYj Ww6kO+HMjL5O02iYWu1YkXDOYhFI3ijAYQQCVW6fbYSRP+BqFH0FifXao15+YM24nvIO 6tCO602j+8CM98+S2xM9+7klgP0DltwZWctPw= MIME-Version: 1.0 Received: by 10.220.156.208 with SMTP id y16mr119583vcw.28.1329350301246; Wed, 15 Feb 2012 15:58:21 -0800 (PST) Received: by 10.52.114.200 with HTTP; Wed, 15 Feb 2012 15:58:21 -0800 (PST) Date: Wed, 15 Feb 2012 17:58:21 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d043c7bc47ce55704b9097ca4 Subject: [clue] PRIORITY for topics tomorrow 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, 15 Feb 2012 23:58:22 -0000 --f46d043c7bc47ce55704b9097ca4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Here is the list that came (roughly) from the votes: 1. How do we start the call with SIP? -i.e., call flow =96 start to finish. 2. Consumer Capabilities =96 do we need it? 3. Relationship between capture scene and capture set 4. Source Selection 5. Policies 6. Spatial Relationship (SR) =96 do we need to discuss or can we resolve on ML? 7. How SR interact with Switched and/vs Composed? 8. CLUE & SDP 9. Ticket#5/#7 10. Encoding =93hard coded=94 for H.264 11. Data model 12. Multiple use case Mary and Paul --f46d043c7bc47ce55704b9097ca4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Here is the list that came (roughly) from the votes:
  1. How = do we start the call with SIP? =A0-i.e., call flow =96 start to finish.=A0<= /li>
  2. Consumer Capabilities =96 do we need it?=A0
  3. Relationship be= tween capture scene and capture set
  4. Source Selection
  5. Policies
  6. Spatial Relationship (SR) =96= do we need to discuss or can we resolve on ML?=A0
  7. How SR interact = with Switched and/vs Composed?=A0
  8. CLUE & SDP
  9. Ticket#5/#= 7
  10. Encoding =93hard coded=94 for H.264
  11. Data model=A0
  12. Multi= ple use case

Mary and Paul


--f46d043c7bc47ce55704b9097ca4-- From johaniel@cisco.com Thu Feb 16 05: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 204C721F855D for ; Thu, 16 Feb 2012 05:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 L6dRpdhGmKAX for ; Thu, 16 Feb 2012 05:57:40 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id DB18721F8549 for ; Thu, 16 Feb 2012 05:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johaniel@cisco.com; l=1688; q=dns/txt; s=iport; t=1329400660; x=1330610260; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=xSiLxGqlW/LDUycoOMSmGNVrN+XkXlaJBy3XT8rqj6k=; b=VZtzBZzz1tgRfcy1iOGTEDemCDKvdRhRVjoR6Sa18knQZVQ4N2ZygZqZ GgJMnjGQL+nenOWLxTPFuqzur6mUyAFPOnX8A3tYfj2/3LdKb0BVEECpr zf4owKpGsn43Jq9dUeANxCYKl0mTiFV+6rHQBTA1ErBvA49wp5xGx8qAI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACkKPU+Q/khL/2dsb2JhbABEsGGBB4FyAQEBAwESAQoTCjgMBwQCAQgRBAEBCwYXAQYBRQkIAQEEEwgah12aNwGeRItuBAQrKgQQBgMCg3EBBQ04gjpjBKgg X-IronPort-AV: E=Sophos;i="4.73,429,1325462400"; d="scan'208";a="66298760" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 16 Feb 2012 13:57:38 +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 q1GDvcSi024948 for ; Thu, 16 Feb 2012 13:57:38 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); Thu, 16 Feb 2012 14:57:37 +0100 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, 16 Feb 2012 14:57:37 +0100 Message-ID: <05DD269BD82AA549BC4B2619BBAC466AD95F6B@XMB-AMS-206.cisco.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB3ED1A9@CRPMBOXPRD01.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Call for Consensus on framework spatial relationships Thread-Index: AczoN4xu20EC5SujSaeGBIsa8YgvdQDpBt2gADVA6QA= References: <4F356FB5.1090608@alum.mit.edu> <4F358646.4010108@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FB3ED1A9@CRPMBOXPRD01.polycom.com> From: "Johan Ludvig Nielsen (johaniel)" To: X-OriginalArrivalTime: 16 Feb 2012 13:57:37.0845 (UTC) FILETIME=[F0FE8E50:01CCECB2] Subject: Re: [clue] Call for Consensus on framework spatial relationships 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, 16 Feb 2012 13:57:44 -0000 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 15. februar 2012 13:21 To: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] Call for Consensus on framework spatial relationships > So, I propose that: >=20 > - Capture Scene becomes a first class entity, with its own attributes. > The Area of Scene, and Scale attribute should belong to it, > rather than to Capture Set. [Duckworth, Mark] Maybe, but the intent was that one capture set corresponds to one scene. I'm not sure if there is a need to have multiple capture sets specifically associated with the same scene. [Nielsen, Johan L]=20 It would be interesting to see an example of how the framework would represent a case with multiple captures from the same scene, but where functional relationship is more important to convey than physical spatial relationship.=20 For instance a lecture. One camera capturing the lecturer, another the audience raising questions. Capture area can describe the physical relationship between the captures, whether the lecturer is visible in both streams or not. However, the consumer is not interested in that relationship, but need to know that they are from the same scene, which function the captures have, the priority, activity, ...=20 Would these video captures be in a single or in different capture sets? In this case there may be audio captures to be connected to one of the video captures and not to the other. How do you convey that using the capture area attribute? Having different capture sets from the same scene may solve this. (Wasn't my idea, but I steal it.) From maestro@samsung.com Thu Feb 16 08:04: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 7F6E321F869F for ; Thu, 16 Feb 2012 08:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.115 X-Spam-Level: X-Spam-Status: No, score=-8.115 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RELAY_IS_203=0.994] 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 Kg0cx-cwbHjf for ; Thu, 16 Feb 2012 08:04:34 -0800 (PST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1747821F85E0 for ; Thu, 16 Feb 2012 08:04:33 -0800 (PST) Received: from epcpsbgm2.samsung.com (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built Sep 7 2010)) with ESMTP id <0LZH00MSNTZJFZQ0@mailout1.samsung.com> for clue@ietf.org; Fri, 17 Feb 2012 01:04:31 +0900 (KST) X-AuditID: cbfee61b-b7c62ae000000989-cf-4f3d290e6764 Received: from epmmp2 ( [203.254.227.17]) by epcpsbgm2.samsung.com (MMPCPMTA) with SMTP id 66.04.02441.E092D3F4; Fri, 17 Feb 2012 01:04:31 +0900 (KST) Received: from NOMAESTRO02 ([105.210.1.2]) by mmp2.samsung.com (Oracle Communications Messaging Exchange Server 7u4-19.01 64bit (built Sep 7 2010)) with ESMTPA id <0LZH008GBTZEAZ50@mmp2.samsung.com> for clue@ietf.org; Fri, 17 Feb 2012 01:04:30 +0900 (KST) From: Gyubong Oh To: 'CLUE' References: In-reply-to: Date: Thu, 16 Feb 2012 11:04:18 -0500 Message-id: <002401ccecc4$a60d0cc0$f2272640$@com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_0025_01CCEC9A.BD3704C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AczsPbT0vS6+tOE4T4iGoqjzF3tcxQAhofQg Content-language: ko X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] PRIORITY for topics tomorrow 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, 16 Feb 2012 16:04:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0025_01CCEC9A.BD3704C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Mary and all, Thank you for prioritization. One comment from side is to fix the name of topic. Multiple devices use cases, not multiple use case Could you please correct the topic in no.12? Thank you in advance. Best Regards, Gyubong From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Wednesday, February 15, 2012 6:58 PM To: CLUE Subject: [clue] PRIORITY for topics tomorrow Here is the list that came (roughly) from the votes: 1. How do we start the call with SIP? -i.e., call flow - start to finish. 2. Consumer Capabilities - do we need it? 3. Relationship between capture scene and capture set 4. Source Selection 5. Policies 6. Spatial Relationship (SR) - do we need to discuss or can we resolve on ML? 7. How SR interact with Switched and/vs Composed? 8. CLUE & SDP 9. Ticket#5/#7 10. Encoding "hard coded" for H.264 11. Data model 12. Multiple use case Mary and Paul ------=_NextPart_000_0025_01CCEC9A.BD3704C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Mary and all,

 

Thank you for prioritization.

 

One comment from side is to fix the name of = topic.

Multiple devices use = cases, not multiple use case

 

Could you please correct the topic in no.12?

 

Thank you in advance.

 

Best Regards,

Gyubong

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: Wednesday, February 15, 2012 6:58 = PM
To: CLUE
Subject: [clue] PRIORITY for topics = tomorrow

 

Here is the list that came (roughly) from the = votes:

  1. How do we start the call with SIP? =  -i.e., call flow – start to = finish. 
  2. Consumer Capabilities – do we need = it? 
  3. Relationship between capture scene and = capture set
  4. Source = Selection
  5. Policies
  6. Spatial Relationship (SR) – do we = need to discuss or can we resolve on ML? 
  7. How SR interact with Switched and/vs = Composed? 
  8. CLUE & SDP
  9. Ticket#5/#7
  10. Encoding “hard coded” for = H.264
  11. Data = model 
  12. Multiple use = case

 

Mary and = Paul

 

 

------=_NextPart_000_0025_01CCEC9A.BD3704C0-- From espeberg@cisco.com Sun Feb 19 14:12: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 75AAE21F8570 for ; Sun, 19 Feb 2012 14:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.002 X-Spam-Level: X-Spam-Status: No, score=-9.002 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_40=-0.185, 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 gCwcrzUVugoT for ; Sun, 19 Feb 2012 14:12:41 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 13A8721F855D for ; Sun, 19 Feb 2012 14:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=6582; q=dns/txt; s=iport; t=1329689560; x=1330899160; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ItlZ9DM57F35DY53Yfs2D05GNChSn40htb9lUsrHzas=; b=CzFYgm2WIQxTpwOyzE5HWc8fHyal31S2uJvMLuscvba/HPtkhVt4ze1y nloBPZgnw/Vfu1nAjBLIZ4xogVOnpOOY60UTd8uYz2Lr+LrM305r919b/ z1SL1zKfZNAYz1DZcZ8sI8s5ZVDw76VMNnOKCuy6y1c5MVLXF+oU3zGPL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJpyQU+Q/khL/2dsb2JhbABEsimBB4FzAQEBAwESAR0KPwUHBAIBCBEEAQEBCgYXAQYBRQkIAQEEEwgah16bAwGdWIlIgjQBAgEIAgUDAQMDAwEBBwkthCQcgkpjBKglgVIECw X-IronPort-AV: E=Sophos;i="4.73,446,1325462400"; d="scan'208";a="66493632" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 19 Feb 2012 22:12:29 +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 q1JMCSMe008541; Sun, 19 Feb 2012 22:12:28 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, 19 Feb 2012 23:12:29 +0100 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, 19 Feb 2012 23:12:28 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EF455E5@XMB-AMS-214.cisco.com> In-Reply-To: <20120215115300.GY61963@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] VAD and speaker coordinates Thread-Index: Aczr2GBS6xB3ORfZRTCJov9FbnE16wDdmhNg References: <4F3046C9.4060401@alum.mit.edu> <20120208215905.GP61963@verdi> <92DF9533227FC14F946C7321074B8C9EEC5B0C@XMB-AMS-214.cisco.com> <20120213162307.GW61963@verdi> <92DF9533227FC14F946C7321074B8C9EF45166@XMB-AMS-214.cisco.com> <20120215115300.GY61963@verdi> From: "Espen Berger (espeberg)" To: "John Leslie" X-OriginalArrivalTime: 19 Feb 2012 22:12:29.0424 (UTC) FILETIME=[91CB3700:01CCEF53] Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates 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, 19 Feb 2012 22:12:59 -0000 I think we need a better understanding of what should be done at record time and what should be done at playback is needed. It would be valuable to have more detailed use cases, to make us better equipped to discuss the same scenarios. The best would be to find a model where a room can do pre-processing and send a single audio stream with position information, which I also is important for interoperability with systems only capable of process a limited set of audio information. At the same time it would be great to allow for more meta-information to be sent and received when needed.=20 Cheers -Espen =20 -----Original Message----- From: John Leslie [mailto:john@jlc.net]=20 Sent: 15. februar 2012 12:53 To: Espen Berger (espeberg) Cc: CLUE Subject: Re: [clue] VAD and speaker coordinates Espen Berger (espeberg) wrote: >=20 > Discussions of Audio recording and playback is something that will=20 > benefits from a whiteboard! Indeed... especially a three-dimensional one! ;^) > From: John Leslie [mailto:john@jlc.net] >> Espen Berger (espeberg) wrote: >>=20 >>> "User Bob is in a call with Alice, Bob see that Alice is standing=20 >>> left in the video stream. Bob wants to hear the audio from Alice=20 >>> being from the left side" >> >> It's _really_ not that simple. >=20 > [Espen Berger (espeberg)] My use case is this simple, other use cases=20 > might be more complex. With a single speaker in a room, dynamic=20 > speaker position work nicely. We really ought to come up with a better way of distinguishing a human speaking from an audio transducer... There are use-cases simple enough to be processed into a position in a stereo or surround system -- I don't find them interesting... >> Having mono audio bounce between speakers will sort-of work if we're=20 >> all agreed there are only two speakers. If there are more than two,=20 >> it won't work at all. >=20 > [Espen Berger (espeberg)] I do not see that modeling more than two=20 > active talkers is hard. To do proper playback is hard, but last resort > is always to mix all audio together and play back on a single speaker. Indeed, that works. >>> * A single audio stream is enough >>=20 >> Enough for what? >=20 > [Espen Berger (espeberg)] Enough to play out on active talker in any=20 > position, as long as you receive the dynamic position information. Well, no. If we're dealing with a lapel mike in a reasonably dead room, we can process that into a "position" in stereo / surround. In practice, it's seldom that straightforward. Folks share microphones, the room is too noisy, echos become too confusing... >>> * If dynamic speaker position is sent, you could play out the audio >>> in the correct position >> >> There-Ain't-No-Such-Thing-As-A "correct position". :^( >>=20 >> We're trying to create a virtual room; and except in the trivial case >> where one room has half the speakers and a second room has the other=20 >> half, we're reduced to asking the participants to suspend their=20 >> disbelief that they're in this virtual room. > > [Espen Berger (espeberg)] The term Virtual room is not well defined.=20 My bad. I see that my post could be read to ask CLUE to define a virtual room. That was not my intent. It's merely how I think about the audio issue: others are free to think about it differently. I think about it that way because that is my model of how _participants_ experience telepresence: they're in a room which doesn't actually exist, but "feels" like it does. >> For that trivial case, we can treat each set of screens as a virtual=20 >> glass partition, let participants listen to the folks on their side=20 >> without any amplification, and reproduce the audio which "would" pass >> through the partition if it weren't there. >>=20 >> (There _will_ be some extended echo problems, but those can be >> managed.) >=20 > [Espen Berger (espeberg)] AFAIK the echo cancelation is a=20 > implementation challenge more than a modeling challenge. Actually, there is a modeling challenge there -- to accurately map the delay times so the jitter doesn't kill you... But I inherently don't trust "echo cancellation" algorithms. They work pretty well in simple cases (two speakers, no jitter), but fall apart when you switch more speakers in and out in the presence of jitter. >> IMHO, the critical information is the _virtual_ position of the=20 >> speaker, My bad, again. :^( For _my_ rendering purposes, I need this virtual position. That does _not_ mean it needs to be the same as any other renderer's virtual position for that (human) speaker. >> the actual position of the microphone, and _perhaps_ the relative=20 >> actual position of the speaker to the microphone. Room acoustics is a >> critical part of how humans "place" a sound source; and screwing up=20 >> the room acoustics to "help" them won't help. (IMHO, of course...) >=20 > [Espen Berger (espeberg)] I still believe that the capture room is=20 > better at figuring out the speaker position than the reproducing room. Agreed, the capture room has better information with which to guess the (human) speaker postion. But the rendering room must take responsibility for the audio experience of its occupants. Trusting the capture room too much about the physical positions of its occupants is hazardous. > At capture time you can do pre-processing if needed to calculate=20 > position and also mix multiple microphone inputs together into a=20 > single audio stream, e.g. when two microphones picks up the audio from > the same speaker. Indeed you can -- though for the most part I wish you wouldn't. Calculating position should be harmless (assuming you don't change the audio being captured); but mixing two audio streams screws with the room acoustics. My intended point, really, is that I prefer knowing microphone positions to guessing (human) speaker positions. Were I to accurately map each microphone audio capture to a virtual audio transducer in my corresponding virtual room (and not change things too suddenly), the human listeners would pretty much work it out by themselves. What does this mean to a CLUE protocol? Not a whole lot, perhaps. If someone is mixing audio to create the streams sent, I want to be warned: other than that, I really want microphone positions. -- John Leslie From pkyzivat@alum.mit.edu Mon Feb 20 14:18: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 26CAA21E800C for ; Mon, 20 Feb 2012 14:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.056, 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 JrhwCVHFgvbT for ; Mon, 20 Feb 2012 14:18:19 -0800 (PST) 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 459BD21E8011 for ; Mon, 20 Feb 2012 14:18:19 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id cMoD1i0021ZXKqc59NJKeC; Mon, 20 Feb 2012 22:18:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id cNJK1i00R07duvL3hNJKxM; Mon, 20 Feb 2012 22:18:19 +0000 Message-ID: <4F42C6A8.3000602@alum.mit.edu> Date: Mon, 20 Feb 2012 17:18:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Clue signaling alternatives discussed at the 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: Mon, 20 Feb 2012 22:18:20 -0000 I promised to post a cleaned up version of the three alternative approaches to signaling for CLUE that we discussed and wrote on the whiteboard during the interim last Thursday. Following is my attempt at that. Thanks, Paul This covers the signaling for establishment of a point-to-point clue session. It assumes symmetry - that the two participants are comparable and it doesn't matter which one initiates the session. However I think everyone agreed that its also applicable to a session established between a room and an MCU. This assumes that there are two capabilities/advertisement/selection exchanges traveling in opposite directions. These are denoted as caller-capabilties, callee-capabilties, etc. So the two exchanges consist of: - caller-capabilities, callee-advertisement, caller-selection - callee-capabilities, caller-advertisement, callee-selection Each approach is a different way of combining/coordinating these exchanges with sip signaling. In the meeting we labeled these alternatives A, B, C. I've preserved and extended this to A1, A2, B1, B2, C. _______________________________ A) (this was really two alternatives run together. I've broken it out as two.) A1) The advertisement/selection are encoded in SDP offers and answers, using some combination of existing and new SDP syntax. - caller-advertisement in the SDP of the initial SDP offer. - callee-selection in the SDP of the initial SDP answer. - callee-advertisement is also in the SDP of the initial SDP answer. - caller-selection in the SDP of a 2nd SDP offer. This doesn't include a way to send capabilities. The encoding is presumed to build on standard SDP audio and video media syntax in such a way that a callee that doesn't support clue will still be able to accept the basic audio and/or video. A2) The capabilities/advertisement/selection are encoded in a separate body part with the sip messages, coexisting with the SDP offers and answers. This entails use of multipart/mixed so that both can reside in the same message. The encoding within this body part could be XML or something else. - caller-advertisement in a separate body part with the initial SDP offer. - callee-selection in a separate body part with the initial SDP answer. - callee-advertisement is also in a separate body part with the initial SDP answer. - caller-selection in a separate body part with a 2nd SDP offer. This doesn't include a way to send capabilities. Its hoped that a UA that doesn't support CLUE will be able to deal with the multipart and find the SDP offers and answers while ignoring the clue-specific body part. _______________________________ B) The initial INVITE offers "generic" audio and video, designed to be widely acceptable to audio and video UAs that don't support CLUE. It includes added syntax proposing establishment of a separate channel for clue signaling. Then clue capabilities/advertisemens/selections are exchanged over this channel. Finally there is a 2nd offer/answer exchange to establish media streams in accord with the selections. There are two variations on this: B1) and added m-line that establishes a "media" stream for signaling clue (analogous to bfcp). B2) OR the offer of support for a new clue INFO-package. If the callee doesn't support clue, then the clue channel will not be established, and the caller will set things up accordingly using the generic audio and video streams. _______________________________ C) This is a variation on (B). It differs in that the encodings and encoding groups are represented in the SDP of the offer and answer (as they are in A1) but the remainder of the clue-specific info is exchanged in the separate clue signaling channel specified in (B). From pkyzivat@alum.mit.edu Mon Feb 20 15:16: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 F2F8421E8027 for ; Mon, 20 Feb 2012 15:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 4XtrPcp0FFiF for ; Mon, 20 Feb 2012 15:16:54 -0800 (PST) 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 EE8A021E8026 for ; Mon, 20 Feb 2012 15:16:53 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id cMNz1i01T1c6gX855PGteR; Mon, 20 Feb 2012 23:16:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id cPGt1i00m07duvL3jPGtpj; Mon, 20 Feb 2012 23:16:53 +0000 Message-ID: <4F42D460.60208@alum.mit.edu> Date: Mon, 20 Feb 2012 18:16:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <4F42C6A8.3000602@alum.mit.edu> In-Reply-To: <4F42C6A8.3000602@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Clue signaling alternatives discussed at the 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: Mon, 20 Feb 2012 23:16:58 -0000 Note - I intentionally didn't comment on the pros/cons of these alternatives. I'm leaving that for followup discussion. Feel free to expand these, or offer further alternatives. Thanks, Paul On 2/20/12 5:18 PM, Paul Kyzivat wrote: > I promised to post a cleaned up version of the three alternative > approaches to signaling for CLUE that we discussed and wrote on the > whiteboard during the interim last Thursday. Following is my attempt at > that. > > Thanks, > Paul > > This covers the signaling for establishment of a point-to-point clue > session. It assumes symmetry - that the two participants are comparable > and it doesn't matter which one initiates the session. However I think > everyone agreed that its also applicable to a session established > between a room and an MCU. This assumes that there are two > capabilities/advertisement/selection exchanges traveling in opposite > directions. These are denoted as caller-capabilties, callee-capabilties, > etc. So the two exchanges consist of: > > - caller-capabilities, callee-advertisement, caller-selection > - callee-capabilities, caller-advertisement, callee-selection > > Each approach is a different way of combining/coordinating these > exchanges with sip signaling. In the meeting we labeled these > alternatives A, B, C. I've preserved and extended this to A1, A2, B1, > B2, C. > > _______________________________ > > A) (this was really two alternatives run together. I've broken it out as > two.) > > A1) The advertisement/selection are encoded in SDP offers and answers, > using some combination of existing and new SDP syntax. > > - caller-advertisement in the SDP of the initial SDP offer. > > - callee-selection in the SDP of the initial SDP answer. > - callee-advertisement is also in the SDP of the initial SDP answer. > > - caller-selection in the SDP of a 2nd SDP offer. > > This doesn't include a way to send capabilities. > > The encoding is presumed to build on standard SDP audio and video media > syntax in such a way that a callee that doesn't support clue will still > be able to accept the basic audio and/or video. > > A2) The capabilities/advertisement/selection are encoded in a separate > body part with the sip messages, coexisting with the SDP offers and > answers. This entails use of multipart/mixed so that both can reside in > the same message. The encoding within this body part could be XML or > something else. > > - caller-advertisement in a separate body part with the > initial SDP offer. > > - callee-selection in a separate body part with the > initial SDP answer. > - callee-advertisement is also in a separate body part with the > initial SDP answer. > > - caller-selection in a separate body part with a > 2nd SDP offer. > > This doesn't include a way to send capabilities. > > Its hoped that a UA that doesn't support CLUE will be able to deal with > the multipart and find the SDP offers and answers while ignoring the > clue-specific body part. > > _______________________________ > > B) The initial INVITE offers "generic" audio and video, designed to be > widely acceptable to audio and video UAs that don't support CLUE. It > includes added syntax proposing establishment of a separate channel for > clue signaling. Then clue capabilities/advertisemens/selections are > exchanged over this channel. Finally there is a 2nd offer/answer > exchange to establish media streams in accord with the selections. > > There are two variations on this: > > B1) and added m-line that establishes a "media" stream for signaling > clue (analogous to bfcp). > > B2) OR the offer of support for a new clue INFO-package. > > If the callee doesn't support clue, then the clue channel will not be > established, and the caller will set things up accordingly using the > generic audio and video streams. > > _______________________________ > > C) This is a variation on (B). It differs in that the encodings and > encoding groups are represented in the SDP of the offer and answer (as > they are in A1) but the remainder of the clue-specific info is exchanged > in the separate clue signaling channel specified in (B). > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Tue Feb 21 07:02: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 928DA21F87D2 for ; Tue, 21 Feb 2012 07:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.633 X-Spam-Level: X-Spam-Status: No, score=-103.633 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 W7253LhVNdo6 for ; Tue, 21 Feb 2012 07:02:19 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3D321F87C6 for ; Tue, 21 Feb 2012 07:02:17 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so4986669vbb.31 for ; Tue, 21 Feb 2012 07:02:17 -0800 (PST) Received-SPF: pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.220.151.5 as permitted sender) client-ip=10.220.151.5; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.220.151.5 as permitted sender) smtp.mail=mary.ietf.barnes@gmail.com; dkim=pass header.i=mary.ietf.barnes@gmail.com Received: from mr.google.com ([10.220.151.5]) by 10.220.151.5 with SMTP id a5mr14440506vcw.8.1329836537008 (num_hops = 1); Tue, 21 Feb 2012 07:02:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=rG76xXQ7aaPfiktorbjeRRFWTkxeCzFZ2uo+FLvqVdg=; b=wbpdh8ys8uovoXp1fCs3srMfX/a/A9qJn4iH7rUC9aN3JpOJhO7nBww8szMHoTKfim L9rRxpW2tqlVKNAZsPeajJQMUXw2UFPlqMC6OWps5T6XWL6HYbDcaDcRYVxxdZrTlJa+ PFOYeefcgs9KRlsKjIrhhJW98ZiRgeHUclqAU= MIME-Version: 1.0 Received: by 10.220.151.5 with SMTP id a5mr11596113vcw.8.1329836536925; Tue, 21 Feb 2012 07:02:16 -0800 (PST) Received: by 10.52.114.200 with HTTP; Tue, 21 Feb 2012 07:02:16 -0800 (PST) Date: Tue, 21 Feb 2012 09:02:16 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d043be016648d1d04b97ab22d Subject: [clue] No Design team meeting today - we'll restart next Tuesday. 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, 21 Feb 2012 15:02:19 -0000 --f46d043be016648d1d04b97ab22d Content-Type: text/plain; charset=ISO-8859-1 As the subject says, we won't be having a meeting today. Mary. --f46d043be016648d1d04b97ab22d Content-Type: text/html; charset=ISO-8859-1 As the subject says, we won't be having a meeting today.

Mary.
--f46d043be016648d1d04b97ab22d-- From allyn@cisco.com Tue Feb 21 17:41: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 CE43221F86BD for ; Tue, 21 Feb 2012 17:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.838 X-Spam-Level: X-Spam-Status: No, score=-9.838 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, 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 XnRAU5LtmOE9 for ; Tue, 21 Feb 2012 17:41:45 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B479921F86BB for ; Tue, 21 Feb 2012 17:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=17367; q=dns/txt; s=iport; t=1329874905; x=1331084505; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=X+zd9Du/IAdZicNHPxGRcc7YsRS1iWU88GDX35ANhkQ=; b=a8M/Kc5awdEEY+i781WGpwLQXIFLQp6rA81ggnArhb40m9nlOp914vRn NizRb60XYNTSm5WVweiLA/3sUYAEFlnFfY5zz6THTgK04ReNFAqhOAbcc zwv7UO66DNT8vau5k3OwAC/m2ELsKdGxwo9vtJv2GFurTu7Uh4RU/b4Pj U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALtHRE+rRDoH/2dsb2JhbABEglGwDYEHgXMBAQEEEgEJEQNZAgEIDgMEAQELBhcBBgFFCQgBAQQBEggap18Bly2MRQ8BAgMPXhGEVgENHwQ5CAIIOIJZYwSIT593 X-IronPort-AV: E=Sophos;i="4.73,460,1325462400"; d="scan'208,217";a="31683431" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 22 Feb 2012 01:41:24 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1M1fOND023889; Wed, 22 Feb 2012 01:41:24 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); Tue, 21 Feb 2012 17:41:24 -0800 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_01CCF103.15FE8ABE" Date: Tue, 21 Feb 2012 17:41:22 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06DB0085@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4f327d59.d2130e0a.3e4f.ffffe95a@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] 3 comments on encodings and encoding groups --Review of draft-ietf-clue-framework-03 Thread-Index: AczmaGdy5PVDLQ8nRHK9EFLGxp4ZMQKmZxYQ References: <4f327d59.d2130e0a.3e4f.ffffe95a@mx.google.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , X-OriginalArrivalTime: 22 Feb 2012 01:41:24.0525 (UTC) FILETIME=[161F55D0:01CCF103] Subject: Re: [clue] 3 comments on encodings and encoding groups --Review of draft-ietf-clue-framework-03 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, 22 Feb 2012 01:41:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF103.15FE8ABE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Some responses below on 3 of your comments about encodings and encoding groups. Best regards, Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, February 08, 2012 5:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 =20 Hi Roni, The constraints expressed by the encoding group aren't duplicating what's already in the SDP - true, the parameters may be superficially the same, but the m lines in the SDP refer to the whole call, whereas the CLUE constraints break down this total capability into what can be done in multiple, separate chunks. This is not already expressed in SDP. The text could be changed to: " The second type of limitation reflects the encoding resources available - bandwidth and macroblocks/second. This type of constraint refines the existing call-level SDP parameters, and gives the consumer information on how those overall limitations can be subdivided when instantiating multiple individual encodings." 15. In section 6.3 the text say that " The second type of limitation reflects the encoding resources available - bandwidth and macroblocks/second". This information is available in the SDP description and the CLUE protocol should not duplicate information. =20 =20 With reference to your comment below, I do not believe that the encodings described in CLUE are already in SDP. When you say,=20 My suggestion is to add a correlation between the SDP information and the media capture that is sending the specific media stream. That is fine, once the consumer has selected one or more of the possible media streams for each capture that it wants. But currently SDP does not allow expression of groups of potential encodings from the sender in which each group is subject to a group constraint (the encoding group parameters), and from which the consumer can select. I am not saying it could not be said in SDP,though it would probably require some extensions, but such groups of individual encodings are not currently expressed in SDP. So, I don't think that there is duplication between the constraints currently expressed in SDP and the encodings and encoding groups in the CLUE framework. =20 17. Section 7 talks about encoding. My view is that these constrains are already defined in the respective m-lines in the SDP. For example the first paragraph of section 7.1 describes the SDP and codec parameters so why do we need to duplicate the individual encoding which is also codec specific, see section 10 talking about new encoding parameters for new codecs. My suggestion is to add a correlation between the SDP information and the media capture that is sending the specific media stream. The same goes for the group information in section 7.2, at least to the bandwidth parameter which just repeats the logic defined in RFC4566.=20 =20 =20 I think there always needs to be an Encoding Group ID in the media capture so that the consumer knows from which pool to pull streams for the capture. So I guess I don't see the "may", or how a provider can support capture set entries without encoding group limitations bounding the resources on the streams with which the captures are instantiated. The way the framework is written now, there is always a need for the encoding group and encoding to instantiate a potential stream with a capture =20 23. In section 9 I suggest changing the "has" in the last sentence of the first paragraph to a "may" . A provider may be able to support the capture set entries without any limitations on the encoding beside the ones specified in the SDP. =20 =20 =20 ------_=_NextPart_001_01CCF103.15FE8ABE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Roni,

Some responses below = on 3 of your comments about encodings and encoding groups.

Best = regards,

Allyn

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Wednesday, February 08, 2012 5:49 AM
To: clue@ietf.org
Subject: [clue] Review of = draft-ietf-clue-framework-03

 

Hi Roni,

The constraints expressed by the encoding group aren't = duplicating what's already in the SDP - true, the parameters may be superficially = the same, but the m lines in the SDP refer to the whole call, whereas the CLUE constraints break down this total capability into what can be done in = multiple, separate chunks.  This is not already = expressed in SDP.

The text could be changed = to:

“ The second type of limitation reflects the = encoding resources available - bandwidth and macroblocks/second. This type of = constraint refines the existing call-level SDP parameters, and gives the consumer information on how those overall limitations can be subdivided when instantiating multiple individual encodings."

15.   In section 6.3 the text say that “ The second type of = limitation  reflects the encoding resources available - bandwidth and macroblocks/second”. This information is available in the SDP = description and the CLUE protocol should not duplicate = information.

 

 

With reference to your comment = below, I do not believe that the encodings described in CLUE are already in SDP. = When you say,

My suggestion is to add a correlation between the = SDP information and the media capture that is sending the specific media = stream.

That is fine, once the consumer has = selected one or more of the possible media streams for each capture that it = wants.

But currently SDP does not allow = expression of groups of potential encodings from the sender in which each group is = subject to a group constraint (the encoding group parameters), and from which = the consumer can select. I am not saying it could not be said in SDP,though = it would probably require some extensions, but such groups of individual = encodings are not currently expressed in SDP. So, I don’t think that there = is duplication between the constraints currently expressed in SDP and the encodings and encoding groups in the CLUE = framework.

 =

17.   Section 7 talks about encoding. My view is that these constrains are already = defined in the respective m-lines in the SDP. For example the first paragraph of = section 7.1 describes the SDP and codec parameters so why do we need to = duplicate the individual encoding which is also codec specific, see section 10 talking = about new encoding parameters for new codecs. My suggestion is to add a = correlation between the SDP information and the media capture that is sending the = specific media stream.  The same goes for the group information in section = 7.2, at least to the bandwidth parameter which just repeats the logic defined in RFC4566.

 

 

I think there always needs to be an Encoding Group ID in = the media capture so that the consumer knows from which pool to pull streams for = the capture.  So I guess I don’t see the “may”, or = how a provider can support capture set entries without encoding group = limitations bounding the resources on the streams with which the captures are = instantiated. The way the framework is written now, there is always a need for the = encoding group and encoding to instantiate a potential stream with a = capture

 

23.   In section 9 I suggest changing the “has” in the last sentence = of the first paragraph to a “may” . A provider may be able to = support the capture set entries without any limitations on the encoding beside the = ones specified in the SDP.

 =

 =

 

------_=_NextPart_001_01CCF103.15FE8ABE-- From Mark.Duckworth@polycom.com Wed Feb 22 11:52: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 564E121F86DF for ; Wed, 22 Feb 2012 11:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 kJ-bjJnN9K+W for ; Wed, 22 Feb 2012 11:52:04 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDD121E8010 for ; Wed, 22 Feb 2012 11:52:03 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 22 Feb 2012 11:52:00 -0800 From: "Duckworth, Mark" To: "Johan Ludvig Nielsen (johaniel)" , "clue@ietf.org" Date: Wed, 22 Feb 2012 11:51:54 -0800 Thread-Topic: [clue] Call for Consensus on framework spatial relationships Thread-Index: AczoN4xu20EC5SujSaeGBIsa8YgvdQDpBt2gADVA6QABOjc8QA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB4C5A9A@CRPMBOXPRD01.polycom.com> References: <4F356FB5.1090608@alum.mit.edu> <4F358646.4010108@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FB3ED1A9@CRPMBOXPRD01.polycom.com> <05DD269BD82AA549BC4B2619BBAC466AD95F6B@XMB-AMS-206.cisco.com> In-Reply-To: <05DD269BD82AA549BC4B2619BBAC466AD95F6B@XMB-AMS-206.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Call for Consensus on framework spatial relationships 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, 22 Feb 2012 19:52:05 -0000 At the interim meeting last week, we decided we should propose a change to = the framework to eliminate the two different concepts of "capture scene" an= d "capture set". Most people thought we don't need the two different (but = closely coupled) concepts. One suggestion was to rename a capture set to b= e called a capture scene, and that one entity would then encompass both of = the original concepts. The original intent was to have a one to one relati= onship between a capture scene and a capture set anyway. So I'll send anot= her message later with a proposal along those lines. More comments inline. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Johan Ludvig Nielsen (johaniel) > Sent: Thursday, February 16, 2012 8:58 AM > To: clue@ietf.org > Subject: Re: [clue] Call for Consensus on framework spatial relationships >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Duckworth, Mark > Sent: 15. februar 2012 13:21 > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] Call for Consensus on framework spatial relationships >=20 >=20 > > So, I propose that: > > > > - Capture Scene becomes a first class entity, with its own attributes. > > The Area of Scene, and Scale attribute should belong to it, > > rather than to Capture Set. >=20 > [Duckworth, Mark] Maybe, but the intent was that one capture set > corresponds to one scene. I'm not sure if there is a need to have multip= le > capture sets specifically associated with the same scene. >=20 > [Nielsen, Johan L] > It would be interesting to see an example of how the framework would > represent a case with multiple captures from the same scene, but where > functional relationship is more important to convey than physical spatial > relationship [Duckworth, Mark] If the spatial relationship is not important, then they d= on't have to be in the same capture set/scene. > For instance a lecture. One camera capturing the lecturer, another the > audience raising questions. Capture area can describe the physical > relationship between the captures, whether the lecturer is visible in bot= h > streams or not. However, the consumer is not interested in that relations= hip, > but need to know that they are from the same scene, which function the > captures have, the priority, activity, ... [Duckworth, Mark] Maybe you have a different idea of what is the "scene". = I say if spatial relationship is not important, then they are not in the sa= me scene. If I understand what you mean by function, then that is handled = by the purpose attribute. I made a proposal in another message that this s= hould just use enumerated values from RFC4796. > Would these video captures be in a single or in different capture sets? > In this case there may be audio captures to be connected to one of the vi= deo > captures and not to the other. How do you convey that using the capture > area attribute? Having different capture sets from the same scene may sol= ve > this. (Wasn't my idea, but I steal it.) [Duckworth, Mark] If the same audio capture is associated with multiple vid= eo captures, then they should all be in the same capture set/scene. If on = the other hand a video capture is not associated with the audio, and not sp= atially related to other video in the set/scene, then that video capture sh= ould be in a different set/scene. From Mark.Duckworth@polycom.com Wed Feb 22 12:11:28 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 2B35C21F84F1 for ; Wed, 22 Feb 2012 12:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 O8XHxB62nbT8 for ; Wed, 22 Feb 2012 12:11:26 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 316C221E800F for ; Wed, 22 Feb 2012 12:11:19 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 22 Feb 2012 12:11:19 -0800 From: "Duckworth, Mark" To: "Johan Ludvig Nielsen (johaniel)" , "clue@ietf.org" Date: Wed, 22 Feb 2012 12:11:16 -0800 Thread-Topic: [clue] Call for Consensus on framework spatial relationships Thread-Index: AczoKhsveQLyVrRaRw+TERiMAJUSkQDkWhmQAXho+dA= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB4C5AC0@CRPMBOXPRD01.polycom.com> References: <4F356FB5.1090608@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466AD95D31@XMB-AMS-206.cisco.com> In-Reply-To: <05DD269BD82AA549BC4B2619BBAC466AD95D31@XMB-AMS-206.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Call for Consensus on framework spatial relationships 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, 22 Feb 2012 20:11:28 -0000 Hi Johan, I agree the cases you point out do not yet have a clear answer as to how to= spatially associate audio to video. Yes, as you say, the active coordinat= e idea from A.5 is intended to address this, and it is in addition to VAD, = but maybe not enough information. I think Andy was planning on sending a m= ore detailed proposal to the list. Your question about choosing VC4 (switched) along with A0, A1, A2 (left, ce= nter, right) is a good one. So far, we have not defined a way for the cons= umer to know which specific spatial area is represented by VC4 at any given= time. The consumer just knows that overall it represents the "entire area= " (or whatever the provider advertised with the static area of capture for = VC4). But we haven't defined any way for the provider to indicate which su= bset of the area it represents _right now_ as it switches between different= camera images. Do you think it is necessary to provide that information? Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Johan Ludvig Nielsen (johaniel) > Sent: Wednesday, February 15, 2012 5:15 AM > To: clue@ietf.org > Subject: Re: [clue] Call for Consensus on framework spatial relationships >=20 > Hi all >=20 > I am new to this mailing list and haven't read the full history, so pleas= e forgive > me if I go where you have already been. I have however followed the > framework development, and work closely with Espen. >=20 > As I understand the framework, media captures in a capture set may have > spatial relationships, and these relationships are supposed to be fully > described using the capture area attribute. >=20 > My view is that the capture area coordinates are useful for describing st= atic > relationships of the capture devices in a physical capture scene. > However, they may not be sufficient for describing relationships necessar= y > for proper spatial rendering of video and audio in some usecases. Additio= nal > mechanisms for explicitly relating audio and video captures and/or > expressing dynamically varying relationships may be necessary. >=20 > I suggest to expand on the examples 11.1 and 11.3 in the framework to > investigate this further. Specifically, to include more audio capabilitie= s and > test how the capture area concept works in a switched, pre-composed > and/or dynamically changing situation. >=20 >=20 > Take the example in 11.1. The consumer is free to pick the switched captu= re > VC4 and the directional audio set of captures AC0-AC1-AC2. The spatial > relationships between these captures are well defined by the capture area > and can be used for rendering. But whether the rendering will be perceive= d > as correct or not depends on which video segment is active at any given t= ime, > and which of the two persons on the segment is talking. >=20 > The MCU example in 11.3 is an excellent usecase for directional audio, an= d > multiple audio streams should be included as options for the various mult= i- > screen consumers. To conclude on the capture area concept it is necessary= to > see how such a capture set is described, including the capture areas. How= do > they define relationships between streams. How does a 4-screen/4-speaker > receiver and a 4-screen/2-speaker receiver know which streams to choose. >=20 > The switched stream in 11.1 is an example where spatial relationships cha= nge > during the course of the conference. The 11.3 MCU case may be another, > depending on how multiple audio streams are composed. The static capture > area concept is not well suited to convey such changes. >=20 > The active coordinate concept mentioned in A.5 can be one additional > mechanism that complements the capture area (although it should not be > mixed up with the VAD concept). >=20 > I am in favour of consensus on the capture area coordinates, but I don't = think > the topic of spatial relationships is fully resolved. >=20 > Regards > Johan >=20 >=20 >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 10. februar 2012 20:28 > To: CLUE > Subject: [clue] Call for Consensus on framework spatial relationships >=20 > CLUE WG participants: >=20 > There has been a lot of discussion about coordinate systems and spatial > relationships. The editors of the framework think they have reflected the > group understanding of that topic in framework-03. (This is primarily in > sections 5, 6.1.1, and 6.2.1, with an example in section > 11.1) >=20 > This is a request for everyone who cares to indicate if they are satisfie= d with > the treatment of this topic. If not, please specify what you object to, i= n a > constructive way. >=20 > It would be helpful to have comments by the start of the interim meeting > next Wed, Feb 15, so that they can be considered during discussions there= . > But that may be too tight for some people traveling. So lets set a second= ary > target date of Monday, Feb 20. >=20 >=20 > Thanks, > Paul (as co-chair) > _______________________________________________ > 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 Mark.Duckworth@polycom.com Wed Feb 22 12:17:57 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 706BF21E804A for ; Wed, 22 Feb 2012 12:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.103, 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 4ODZ2ax3Hp4s for ; Wed, 22 Feb 2012 12:17:55 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0F721E8014 for ; Wed, 22 Feb 2012 12:17:49 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 22 Feb 2012 12:17:49 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Wed, 22 Feb 2012 12:17:46 -0800 Thread-Topic: clarifying statements RE: [clue] Review of framework-03 Thread-Index: Aczxnq2/5E4Z4nvJT76enk7WjZK4gg== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB4C5AD1@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] clarifying statements RE: Review of framework-03 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, 22 Feb 2012 20:17:57 -0000 Hi Roni, I agree with your suggestions below to clarify a couple of things. We'll c= larify it in the next version. Mark =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Wednesday, February 08, 2012 8:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 5. In section 6.1.1 "Media Capture (MC) Attributes describe static informat= ion about the captures that can be used by the consumer to help decide whic= h Media=A0 Captures should be requested". I think that this sentence is usi= ng a passive language and I suggest rephrasing it to "Media Capture Attribu= tes describe static information about the captures. A Provider use the MC a= ttributes to propose multiple MC choices to the consumer. The consumer will= select the MCs that he wants to render" 11. When talking about capture set entry, my understanding is that a consum= er can select part of the MCs in the entry and not all of them since they r= epresent simultaneous streams. For example if the provider offers (VC0, VC1= , VC2) the consumer can request (VC2) or (VC0, VC2). I think that this shou= ld be clear in the text. Maybe in add some text in section 6.3 fourth parag= raph. From ron.even.tlv@gmail.com Wed Feb 22 14: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 606B521F8557 for ; Wed, 22 Feb 2012 14:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 4Tt4qajaqTNt for ; Wed, 22 Feb 2012 14:21:40 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA4B21F8552 for ; Wed, 22 Feb 2012 14:21:39 -0800 (PST) Received: by eekc41 with SMTP id c41so210614eek.31 for ; Wed, 22 Feb 2012 14:21:39 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.47.8 as permitted sender) client-ip=10.14.47.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.47.8 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.47.8]) by 10.14.47.8 with SMTP id s8mr16876925eeb.91.1329949299351 (num_hops = 1); Wed, 22 Feb 2012 14:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=B2Jhx0Dn4qfqdKh9Noz70KdBkI7UrQojkDRJ+c1mZis=; b=mEIYBpsFkXDQBEeYh3RY3apof0Q4n5GcUWac5Gwo/pmlSmtmh5fl4jdQUXbLp2Gcpm 3Zouc9V92WTY6cnBwQohFZssG+VJJ4V9RWqFx52QRXePWAR2jdBIUkqRgxL5smgqvlj/ b8b/wSCx+xCBVQO6X7NO/QMrFPSHwPSYjtvrQ= Received: by 10.14.47.8 with SMTP id s8mr13502848eeb.91.1329949299205; Wed, 22 Feb 2012 14:21:39 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id u9sm90365037eem.11.2012.02.22.14.21.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 14:21:38 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , "'Johan Ludvig Nielsen \(johaniel\)'" , References: <4F356FB5.1090608@alum.mit.edu> <05DD269BD82AA549BC4B2619BBAC466AD95D31@XMB-AMS-206.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB4C5AC0@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB4C5AC0@CRPMBOXPRD01.polycom.com> Date: Thu, 23 Feb 2012 00:21:12 +0200 Message-ID: <4f456a72.89b90e0a.6035.ffffa2fc@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: AczoKhsveQLyVrRaRw+TERiMAJUSkQDkWhmQAXho+dAABBgiYA== Content-Language: en-us Subject: Re: [clue] Call for Consensus on framework spatial relationships 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, 22 Feb 2012 22:21:41 -0000 Hi Mark, I think that if you chose the first signaling alternative and provide the full SDP as explained in my individual draft for the VC1, VC2, VC3 with the SSRC all bundled with VC4 than you will know which VC is currently transmitted in the switched channel. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Duckworth, Mark > Sent: Wednesday, February 22, 2012 10:11 PM > To: Johan Ludvig Nielsen (johaniel); clue@ietf.org > Subject: Re: [clue] Call for Consensus on framework spatial > relationships > > Hi Johan, > > I agree the cases you point out do not yet have a clear answer as to > how to spatially associate audio to video. Yes, as you say, the active > coordinate idea from A.5 is intended to address this, and it is in > addition to VAD, but maybe not enough information. I think Andy was > planning on sending a more detailed proposal to the list. > > Your question about choosing VC4 (switched) along with A0, A1, A2 > (left, center, right) is a good one. So far, we have not defined a way > for the consumer to know which specific spatial area is represented by > VC4 at any given time. The consumer just knows that overall it > represents the "entire area" (or whatever the provider advertised with > the static area of capture for VC4). But we haven't defined any way > for the provider to indicate which subset of the area it represents > _right now_ as it switches between different camera images. Do you > think it is necessary to provide that information? > > Mark > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Johan Ludvig Nielsen (johaniel) > > Sent: Wednesday, February 15, 2012 5:15 AM > > To: clue@ietf.org > > Subject: Re: [clue] Call for Consensus on framework spatial > > relationships > > > > Hi all > > > > I am new to this mailing list and haven't read the full history, so > > please forgive me if I go where you have already been. I have however > > followed the framework development, and work closely with Espen. > > > > As I understand the framework, media captures in a capture set may > > have spatial relationships, and these relationships are supposed to > be > > fully described using the capture area attribute. > > > > My view is that the capture area coordinates are useful for > describing > > static relationships of the capture devices in a physical capture > scene. > > However, they may not be sufficient for describing relationships > > necessary for proper spatial rendering of video and audio in some > > usecases. Additional mechanisms for explicitly relating audio and > > video captures and/or expressing dynamically varying relationships > may be necessary. > > > > I suggest to expand on the examples 11.1 and 11.3 in the framework to > > investigate this further. Specifically, to include more audio > > capabilities and test how the capture area concept works in a > > switched, pre-composed and/or dynamically changing situation. > > > > > > Take the example in 11.1. The consumer is free to pick the switched > > capture > > VC4 and the directional audio set of captures AC0-AC1-AC2. The > spatial > > relationships between these captures are well defined by the capture > > area and can be used for rendering. But whether the rendering will be > > perceived as correct or not depends on which video segment is active > > at any given time, and which of the two persons on the segment is > talking. > > > > The MCU example in 11.3 is an excellent usecase for directional > audio, > > and multiple audio streams should be included as options for the > > various multi- screen consumers. To conclude on the capture area > > concept it is necessary to see how such a capture set is described, > > including the capture areas. How do they define relationships between > > streams. How does a 4-screen/4-speaker receiver and a 4-screen/2- > speaker receiver know which streams to choose. > > > > The switched stream in 11.1 is an example where spatial relationships > > change during the course of the conference. The 11.3 MCU case may be > > another, depending on how multiple audio streams are composed. The > > static capture area concept is not well suited to convey such > changes. > > > > The active coordinate concept mentioned in A.5 can be one additional > > mechanism that complements the capture area (although it should not > be > > mixed up with the VAD concept). > > > > I am in favour of consensus on the capture area coordinates, but I > > don't think the topic of spatial relationships is fully resolved. > > > > Regards > > Johan > > > > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Paul Kyzivat > > Sent: 10. februar 2012 20:28 > > To: CLUE > > Subject: [clue] Call for Consensus on framework spatial relationships > > > > CLUE WG participants: > > > > There has been a lot of discussion about coordinate systems and > > spatial relationships. The editors of the framework think they have > > reflected the group understanding of that topic in framework-03. > (This > > is primarily in sections 5, 6.1.1, and 6.2.1, with an example in > > section > > 11.1) > > > > This is a request for everyone who cares to indicate if they are > > satisfied with the treatment of this topic. If not, please specify > > what you object to, in a constructive way. > > > > It would be helpful to have comments by the start of the interim > > meeting next Wed, Feb 15, so that they can be considered during > discussions there. > > But that may be too tight for some people traveling. So lets set a > > secondary target date of Monday, Feb 20. > > > > > > Thanks, > > Paul (as co-chair) > > _______________________________________________ > > 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 Thu Feb 23 07:04: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 697BD21F8828 for ; Thu, 23 Feb 2012 07:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.077 X-Spam-Level: X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=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 Y7JKezl2z89b for ; Thu, 23 Feb 2012 07:04:50 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id AFD0D21F859B for ; Thu, 23 Feb 2012 07:04:49 -0800 (PST) Received: by eekc41 with SMTP id c41so514672eek.31 for ; Thu, 23 Feb 2012 07:04:48 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.28.4 as permitted sender) client-ip=10.14.28.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.28.4 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.28.4]) by 10.14.28.4 with SMTP id f4mr1101657eea.52.1330009488932 (num_hops = 1); Thu, 23 Feb 2012 07:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=89DcEgd/GVABLgCrkFFSbZgraFXDAI3uZMaPFgp+H4Q=; b=pXheCeItDD1dgToLorNZE2mUKweTBCTODvv94SperIbPgTnu4U7kHb5mXElTmvixjv ufVD3+ffynemHuEqwgcUdHvVCjRupGYcJ4bzD9wJJzRebloliDQxqPOK7C1h5gxEN7Zn BqJInHAJ3fWMlSmF7dlHETOPSpwiec3npatYs= Received: by 10.14.28.4 with SMTP id f4mr861411eea.52.1330009488773; Thu, 23 Feb 2012 07:04:48 -0800 (PST) Received: from windows8d787f9 (bzq-109-67-208-29.red.bezeqint.net. [109.67.208.29]) by mx.google.com with ESMTPS id v51sm6291044eef.2.2012.02.23.07.04.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 07:04:46 -0800 (PST) From: "Roni Even" To: "'Allyn Romanow \(allyn\)'" , References: <4f327d59.d2130e0a.3e4f.ffffe95a@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06DB0085@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06DB0085@xmb-sjc-221.amer.cisco.com> Date: Thu, 23 Feb 2012 17:04:19 +0200 Message-ID: <4f46558e.cb620e0a.7f4c.ffffe950@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B8_01CCF24D.301EA4E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczmaGdy5PVDLQ8nRHK9EFLGxp4ZMQKmZxYQABlOavA= Content-Language: en-us Subject: Re: [clue] 3 comments on encodings and encoding groups --Review of draft-ietf-clue-framework-03 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, 23 Feb 2012 15:04:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01B8_01CCF24D.301EA4E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Allyn, I will try to explain why it works and what is the problem in the multipoint case using the solution in the multistream conference draft. I am basing my description on the first signaling alternative discussed in the interim meeting with the mapping described in http://tools.ietf.org/html/draft-even-clue-rtp-mapping-00 . In the point to point for a 3 camera/monitor system case the CLUE proposal may include three individual streams each from each camera (VC1, VC2 and VC3) and a VC4 which is the loudest speaker switched. The SDP will include the SDP parameters for the VC1, VC2 , VC3, VC4 and if using SSRC multiplex with BUNDLE and including the SSRC attribute for each stream, the receiver can identify based on the SSRC which stream it is currently receiving. In the multipoint case, the question will be if the MCU will use his own ssrc when sending streams to receiving acting similar to an RTP mixer. (note that an RTP mixer can switch source but use its own ssrc). In this case the conference event package can be used to know whose media are received. Again a full SDP will be exchanged between the consumer and the provider. I believe that your view is based on the RTP translator model where the SSRC will be the original ones and sending partial codec information as specified by the individual encodes to all parties. I am not sure that this method will work without having an offer answer (RFC3264) between the parties unless there is just one codec in fixed configuration defined for CLUE . The consumer need to know which codec it is receiving (h.264, H.263, H.265, VP8,..) in order to know that it can support it including a specific configuration like for H.264 which profile. A provider may be able to send H.264 and H.263 and if there are some consumers that support H.264 and all support H.263 how will he know to send H.263 and with which annexes. This will be worse when we will start using H.265. This is without addressing the issue of SBCs in the middle. Roni Even From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] Sent: Wednesday, February 22, 2012 3:41 AM To: Roni Even; clue@ietf.org Subject: RE: [clue] 3 comments on encodings and encoding groups --Review of draft-ietf-clue-framework-03 Hi Roni, Some responses below on 3 of your comments about encodings and encoding groups. Best regards, Allyn From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, February 08, 2012 5:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 Hi Roni, The constraints expressed by the encoding group aren't duplicating what's already in the SDP - true, the parameters may be superficially the same, but the m lines in the SDP refer to the whole call, whereas the CLUE constraints break down this total capability into what can be done in multiple, separate chunks. This is not already expressed in SDP. The text could be changed to: " The second type of limitation reflects the encoding resources available - bandwidth and macroblocks/second. This type of constraint refines the existing call-level SDP parameters, and gives the consumer information on how those overall limitations can be subdivided when instantiating multiple individual encodings." 15. In section 6.3 the text say that " The second type of limitation reflects the encoding resources available - bandwidth and macroblocks/second". This information is available in the SDP description and the CLUE protocol should not duplicate information. With reference to your comment below, I do not believe that the encodings described in CLUE are already in SDP. When you say, My suggestion is to add a correlation between the SDP information and the media capture that is sending the specific media stream. That is fine, once the consumer has selected one or more of the possible media streams for each capture that it wants. But currently SDP does not allow expression of groups of potential encodings from the sender in which each group is subject to a group constraint (the encoding group parameters), and from which the consumer can select. I am not saying it could not be said in SDP,though it would probably require some extensions, but such groups of individual encodings are not currently expressed in SDP. So, I don't think that there is duplication between the constraints currently expressed in SDP and the encodings and encoding groups in the CLUE framework. 17. Section 7 talks about encoding. My view is that these constrains are already defined in the respective m-lines in the SDP. For example the first paragraph of section 7.1 describes the SDP and codec parameters so why do we need to duplicate the individual encoding which is also codec specific, see section 10 talking about new encoding parameters for new codecs. My suggestion is to add a correlation between the SDP information and the media capture that is sending the specific media stream. The same goes for the group information in section 7.2, at least to the bandwidth parameter which just repeats the logic defined in RFC4566. I think there always needs to be an Encoding Group ID in the media capture so that the consumer knows from which pool to pull streams for the capture. So I guess I don't see the "may", or how a provider can support capture set entries without encoding group limitations bounding the resources on the streams with which the captures are instantiated. The way the framework is written now, there is always a need for the encoding group and encoding to instantiate a potential stream with a capture 23. In section 9 I suggest changing the "has" in the last sentence of the first paragraph to a "may" . A provider may be able to support the capture set entries without any limitations on the encoding beside the ones specified in the SDP. ------=_NextPart_000_01B8_01CCF24D.301EA4E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Allyn,

I will try to explain = why it works and what is the problem in the multipoint case using the = solution in the multistream conference  = draft.

I am basing my description on the first = signaling alternative discussed in the interim meeting with the mapping = described in http:/= /tools.ietf.org/html/draft-even-clue-rtp-mapping-00 = .

 

In the point to point =  for a 3 camera/monitor system case the CLUE proposal may include = three individual streams each from each camera (VC1, VC2 and VC3) and a = VC4 which is the loudest speaker switched. The SDP will include the SDP = parameters for the VC1, VC2 , VC3, VC4 and if using SSRC multiplex with = BUNDLE  and including the SSRC attribute for each stream, the = receiver can identify based on the SSRC which stream it is currently = receiving.

In the multipoint case, the question will be if = the MCU will use his own ssrc when sending streams to receiving acting = similar to an RTP mixer. (note that an RTP mixer can switch source but = use its own ssrc). In this case the conference event package can be used = to know whose media are received. Again a full SDP will be exchanged = between the consumer and the provider. I believe that your view is based = on the RTP translator model where the SSRC will be the original ones and = sending partial codec information as specified by the individual encodes = to all parties. I am not sure that this method will work without having = an offer answer (RFC3264) between the parties unless there is just one = codec in fixed configuration defined for CLUE . The consumer need to = know which codec it is receiving (h.264, H.263, H.265, VP8,..) in order = to know that it can support it including a specific configuration like = for H.264 which profile. A provider may be able to send H.264 and H.263 = and if there are some consumers that support H.264 and all support H.263 = how will he know to send H.263 and with which annexes. This will be = worse when we will start using H.265. This is without addressing the = issue of SBCs in the middle.

 

Roni = Even

 

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= = Allyn Romanow (allyn) [mailto:allyn@cisco.com]
Sent: = Wednesday, February 22, 2012 3:41 AM
To: Roni Even; = clue@ietf.org
Subject: RE: [clue] 3 comments on encodings and = encoding groups --Review of = draft-ietf-clue-framework-03

 

Hi Roni,

Some responses below on = 3 of your comments about encodings and encoding = groups.

Best regards,

Allyn

 

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Roni Even
Sent: Wednesday, February 08, = 2012 5:49 AM
To: clue@ietf.org
Subject: = [clue] Review of = draft-ietf-clue-framework-03

 

Hi = Roni,

The = constraints expressed by the encoding group aren't duplicating what's = already in the SDP - true, the parameters may be superficially the same, = but the m lines in the SDP refer to the whole call, whereas the CLUE = constraints break down this total capability into what can be done in = multiple, separate chunks.  This is not = already expressed in SDP.

The text could be changed = to:

“ The second type of = limitation reflects the encoding resources available - bandwidth and = macroblocks/second. This type of constraint refines the existing = call-level SDP parameters, and gives the consumer information on how = those overall limitations can be subdivided when instantiating multiple = individual encodings."

15.   In section = 6.3 the text say that “ The second type of limitation  = reflects the encoding resources available - bandwidth and = macroblocks/second”. This information is available in the SDP = description and the CLUE protocol should not duplicate = information.

 

 

With reference to your comment below, I do not = believe that the encodings described in CLUE are already in SDP. When = you say,

My suggestion is to add a correlation between the = SDP information and the media capture that is sending the specific media = stream.

That is fine, once the consumer has selected one = or more of the possible media streams for each capture that it = wants.

But currently SDP does not allow expression of = groups of potential encodings from the sender in which each group is = subject to a group constraint (the encoding group parameters), and from = which the consumer can select. I am not saying it could not be said in = SDP,though it would probably require some extensions, but such groups of = individual encodings are not currently expressed in SDP. So, I = don’t think that there is duplication between the constraints = currently expressed in SDP and the encodings and encoding groups in the = CLUE framework.

 =

17.   Section 7 = talks about encoding. My view is that these constrains are already = defined in the respective m-lines in the SDP. For example the first = paragraph of section 7.1 describes the SDP and codec parameters so why = do we need to duplicate the individual encoding which is also codec = specific, see section 10 talking about new encoding parameters for new = codecs. My suggestion is to add a correlation between the SDP = information and the media capture that is sending the specific media = stream.  The same goes for the group information in section 7.2, at = least to the bandwidth parameter which just repeats the logic defined in = RFC4566.

 

 

I think there = always needs to be an Encoding Group ID in the media capture so that the = consumer knows from which pool to pull streams for the capture.  So = I guess I don’t see the “may”, or how a provider can = support capture set entries without encoding group limitations bounding = the resources on the streams with which the captures are instantiated. = The way the framework is written now, there is always a need for the = encoding group and encoding to instantiate a potential stream with a = capture

 

23.   In section = 9 I suggest changing the “has” in the last sentence of the = first paragraph to a “may” . A provider may be able to = support the capture set entries without any limitations on the encoding = beside the ones specified in the SDP.

 =

 =

 

------=_NextPart_000_01B8_01CCF24D.301EA4E0-- From mary.ietf.barnes@gmail.com Thu Feb 23 14:03: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 0C70121F8725 for ; Thu, 23 Feb 2012 14:03:10 -0800 (PST) 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.031, 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 KHtmqy-Mwtkd for ; Thu, 23 Feb 2012 14:03:09 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4743621F8720 for ; Thu, 23 Feb 2012 14:03:09 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so1346710vcb.31 for ; Thu, 23 Feb 2012 14:03:08 -0800 (PST) Received-SPF: pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.220.156.139 as permitted sender) client-ip=10.220.156.139; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.220.156.139 as permitted sender) smtp.mail=mary.ietf.barnes@gmail.com; dkim=pass header.i=mary.ietf.barnes@gmail.com Received: from mr.google.com ([10.220.156.139]) by 10.220.156.139 with SMTP id x11mr20806vcw.18.1330034588862 (num_hops = 1); Thu, 23 Feb 2012 14:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=olZS5zEn0+BeCqF/IERLfv3q0Bzq+rp4dyKNBzfWy6Y=; b=A8SQmcBlx5P5M3eysC/oJRsrwO2Bp0MrRfJ7Da//7VxWaJzAMlD7tPVUAouwW5BE4V alf7Uy7PNfo25U/INNWUp94BZQjwNIU30cENhB3aZF6WC/eJ2ET3UteXgdbN+pS3diwn AgsNuSu0GGm+IaHECywfiUg5t0vKtFQWgRk5w= MIME-Version: 1.0 Received: by 10.220.156.139 with SMTP id x11mr16326vcw.18.1330034588660; Thu, 23 Feb 2012 14:03:08 -0800 (PST) Received: by 10.52.114.200 with HTTP; Thu, 23 Feb 2012 14:03:08 -0800 (PST) Date: Thu, 23 Feb 2012 16:03:08 -0600 Message-ID: From: Mary Barnes To: CLUE , Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d0438915b32332404b9a8cfcc Subject: [clue] Clue - Requested sessions have been scheduled for IETF 83 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, 23 Feb 2012 22:03:10 -0000 --f46d0438915b32332404b9a8cfcc Content-Type: text/plain; charset=ISO-8859-1 FYI...Please note that the IETF meeting agenda is not yet final, so it is possible that there will be changes to the schedule. For example, we may end up with a conflict for a key group for us (that happens) when the full agenda is published. Regards, Mary. -----Original Message----- From: "IETF Secretariat" [mailto:agenda@ietf.org] Sent: Thursday, February 23, 2012 2:07 PM To: Barnes, Mary Cc: clue-ads@tools.ietf.org; clue-chairs@tools.ietf.org; wlo@amsl.com Subject: clue - Requested sessions have been scheduled for IETF 83 Dear Mary Barnes, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the original request. clue Session 1 (2.5 hours) Tuesday, Morning Session I 0900-1130 Room Name: 252B --------------------------------------------- clue Session 2 (2 hours) Thursday, Afternoon Session III 1740-1940 Room Name: Maillot --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: ControLling mUltiple streams for tElepresence Area Name: Real-time Applications and Infrastructure Area Session Requester: Wanda Lo Number of Sessions: 2 Length of Session(s): 2.5 hours, 2 hours Number of Attendees: 150 Conflicts to Avoid: First Priority: atoca avtcore avtext bfcpbis bliss codec clue cuss drinks ecrit geopriv mmusic payload p2psip rtcweb salud simple sipclf sipcore siprec soc splices xmpp xrblock vipr Special Requests: --------------------------------------------------------- --f46d0438915b32332404b9a8cfcc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI...Please note that the IETF meeting agenda is not yet final, so it is p= ossible that there will be changes to the schedule. =A0For example, we may = end up with a conflict for a key group for us (that happens) when the full = agenda is published.=A0

Regards,
Mary.=A0



-----Original Message-----
From: "IETF Secretariat" [mailto:agenda@ietf.org]
Sent: Thursday, February 23, 2012 2:07 PM
To: Barnes, Mary
Cc: clue-ads@tools.ietf.org;= clue-chairs@tools.ietf.org; wlo@amsl.com
Subject: clue - Requested sessions have been scheduled for IETF 83

Dear Mary Barnes,

The sessions that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

clue Session 1 (2.5 hours)
=A0 =A0Tuesday, Morning Session I 0900-1130
=A0 =A0Room Name: 252B
=A0 =A0---------------------------------------------
=A0 =A0clue Session 2 (2 hours)
=A0 =A0Thursday, Afternoon Session III 1740-1940
=A0 =A0Room Name: Maillot
=A0 =A0---------------------------------------------



Request Information:

---------------------------------------------------------
Working Group Name: ControLling mUltiple streams for tElepresence
Area Name: Real-time Applications and Infrastructure Area
Session Requester: Wanda Lo

Number of Sessions: 2
Length of Session(s): =A02.5 hours, 2 hours
Number of Attendees: 150
Conflicts to Avoid:
=A0First Priority: atoca avtcore avtext bfcpbis bliss =A0codec clue cuss dr= inks ecrit geopriv mmusic payload p2psip rtcweb salud simple sipclf sipcore= siprec soc splices xmpp xrblock vipr





Special Requests:

---------------------------------------------------------


--f46d0438915b32332404b9a8cfcc-- From mary.ietf.barnes@gmail.com Thu Feb 23 14:07: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 0206D21F8740 for ; Thu, 23 Feb 2012 14:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.628 X-Spam-Level: X-Spam-Status: No, score=-103.628 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 Yu98vPPhMbNq for ; Thu, 23 Feb 2012 14:07:02 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 028D821F872B for ; Thu, 23 Feb 2012 14:07:01 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so1348956vcb.31 for ; Thu, 23 Feb 2012 14:07:01 -0800 (PST) Received-SPF: pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.220.156.139 as permitted sender) client-ip=10.220.156.139; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.220.156.139 as permitted sender) smtp.mail=mary.ietf.barnes@gmail.com; dkim=pass header.i=mary.ietf.barnes@gmail.com Received: from mr.google.com ([10.220.156.139]) by 10.220.156.139 with SMTP id x11mr27456vcw.18.1330034821577 (num_hops = 1); Thu, 23 Feb 2012 14:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=86+7N+lEsaUdKUX6Cdf8fTNVmgtJkbgo3OMOp1XiME0=; b=lx0XYlhdBDtKgXObUPoEg6MsrKAiTocSfIlKIYPUrXG8ythdguaExnlThnET265d2s qi7Lp3B3zhfeNP1YksNENx3zHUEnWS2Oj6y7YgFdnWw5W9o3zd8cMyfUEnTLUlTsrDMk 3ncnnp7PPwiGzfCK7ECSR+wxTD9cJdCL58+PA= MIME-Version: 1.0 Received: by 10.220.156.139 with SMTP id x11mr21887vcw.18.1330034821505; Thu, 23 Feb 2012 14:07:01 -0800 (PST) Received: by 10.52.114.200 with HTTP; Thu, 23 Feb 2012 14:07:01 -0800 (PST) In-Reply-To: References: Date: Thu, 23 Feb 2012 16:07:01 -0600 Message-ID: From: Mary Barnes To: CLUE , Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d0438915b1322b804b9a8dd79 Subject: Re: [clue] Clue - Requested sessions have been scheduled for IETF 83 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, 23 Feb 2012 22:07:03 -0000 --f46d0438915b1322b804b9a8dd79 Content-Type: text/plain; charset=ISO-8859-1 The full draft agenda is out: https://datatracker.ietf.org/meeting/83/agenda.txt It looks like we're okay conflict wise. Our second session is scheduled opposite GEOPRIV, so if anyone has concerns about that please let the chairs know ASAP. Thanks, Mary. On Thu, Feb 23, 2012 at 4:03 PM, Mary Barnes wrote: > FYI...Please note that the IETF meeting agenda is not yet final, so it is > possible that there will be changes to the schedule. For example, we may > end up with a conflict for a key group for us (that happens) when the full > agenda is published. > > Regards, > Mary. > > > > -----Original Message----- > From: "IETF Secretariat" [mailto:agenda@ietf.org] > Sent: Thursday, February 23, 2012 2:07 PM > To: Barnes, Mary > Cc: clue-ads@tools.ietf.org; clue-chairs@tools.ietf.org; wlo@amsl.com > Subject: clue - Requested sessions have been scheduled for IETF 83 > > Dear Mary Barnes, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > clue Session 1 (2.5 hours) > Tuesday, Morning Session I 0900-1130 > Room Name: 252B > --------------------------------------------- > clue Session 2 (2 hours) > Thursday, Afternoon Session III 1740-1940 > Room Name: Maillot > --------------------------------------------- > > > > Request Information: > > --------------------------------------------------------- > Working Group Name: ControLling mUltiple streams for tElepresence > Area Name: Real-time Applications and Infrastructure Area > Session Requester: Wanda Lo > > Number of Sessions: 2 > Length of Session(s): 2.5 hours, 2 hours > Number of Attendees: 150 > Conflicts to Avoid: > First Priority: atoca avtcore avtext bfcpbis bliss codec clue cuss > drinks ecrit geopriv mmusic payload p2psip rtcweb salud simple sipclf > sipcore siprec soc splices xmpp xrblock vipr > > > > > > Special Requests: > > --------------------------------------------------------- > > > --f46d0438915b1322b804b9a8dd79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The full draft agenda is out:


Thanks,
Mary.=A0

On Thu, Feb 23, 2012 at 4:03 PM, Mary Barnes <mary.ietf= .barnes@gmail.com> wrote:
FYI...Please note that the IETF meeting agen= da is not yet final, so it is possible that there will be changes to the sc= hedule. =A0For example, we may end up with a conflict for a key group for u= s (that happens) when the full agenda is published.=A0

Regards,
Mary.=A0



-----Original Message-----
From: "IETF Secretariat" [mailto:agenda@ietf.org]
Sent: Thursday, February 23, 2012 2:07 PM
To: Barnes, Mary
Cc: clue-ads@t= ools.ietf.org; clue-chairs@tools.ietf.org; wlo@amsl.com
Subject: clue - Requested sessions have been scheduled for IETF 83

Dear Mary Barnes,

The sessions that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

clue Session 1 (2.5 hours)
=A0 =A0Tuesday, Morning Session I 0900-1130
=A0 =A0Room Name: 252B
=A0 =A0---------------------------------------------
=A0 =A0clue Session 2 (2 hours)
=A0 =A0Thursday, Afternoon Session III 1740-1940
=A0 =A0Room Name: Maillot
=A0 =A0---------------------------------------------



Request Information:

---------------------------------------------------------
Working Group Name: ControLling mUltiple streams for tElepresence
Area Name: Real-time Applications and Infrastructure Area
Session Requester: Wanda Lo

Number of Sessions: 2
Length of Session(s): =A02.5 hours, 2 hours
Number of Attendees: 150
Conflicts to Avoid:
=A0First Priority: atoca avtcore avtext bfcpbis bliss =A0codec clue cuss dr= inks ecrit geopriv mmusic payload p2psip rtcweb salud simple sipclf sipcore= siprec soc splices xmpp xrblock vipr





Special Requests:

---------------------------------------------------------



--f46d0438915b1322b804b9a8dd79-- From christer.holmberg@ericsson.com Thu Feb 23 23:10:15 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 651D421F85A1 for ; Thu, 23 Feb 2012 23:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.121 X-Spam-Level: X-Spam-Status: No, score=-10.121 tagged_above=-999 required=5 tests=[AWL=0.478, 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 iNpqz2acdgyS for ; Thu, 23 Feb 2012 23:10:13 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 74F3321E8020 for ; Thu, 23 Feb 2012 23:10:13 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-c7-4f4737d4c3e0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B5.DD.27041.4D7374F4; Fri, 24 Feb 2012 08:10:12 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 24 Feb 2012 08:10:11 +0100 From: Christer Holmberg To: "clue@ietf.org" Date: Fri, 24 Feb 2012 08:10:10 +0100 Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt Thread-Index: AczywlP2evfTkWzBSNiYTWIDPD9D5AAAP8LQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D9614CE@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [clue] FW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.txt 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, 24 Feb 2012 07:10:15 -0000 =20 FYI, A milestone for BUNDLE has been created in MMUSIC, and the first draft-ietf= version of the draft has been submitted. Regards, Christer -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: 24. helmikuuta 2012 9:02 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-00.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control= Working Group of the IETF. Title : Multiplexing Negotiation Using Session Description Proto= col (SDP) Port Numbers Author(s) : Christer Holmberg Harald Tveit Alvestrand Filename : draft-ietf-mmusic-sdp-bundle-negotiation-00.txt Pages : 11 Date : 2012-02-23 This specification defines a new SDP Grouping Framework SDP grouping framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=3D" lines). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiatio= n-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiation= -00.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mary.ietf.barnes@gmail.com Fri Feb 24 08: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 47B0821F881B for ; Fri, 24 Feb 2012 08:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.628 X-Spam-Level: X-Spam-Status: No, score=-103.628 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 rCIsZeo8o2dR for ; Fri, 24 Feb 2012 08:53:43 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00E1D21F87E4 for ; Fri, 24 Feb 2012 08:53:42 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so2001217vcb.31 for ; Fri, 24 Feb 2012 08:53:42 -0800 (PST) Received-SPF: pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.70.165 as permitted sender) client-ip=10.52.70.165; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.70.165 as permitted sender) smtp.mail=mary.ietf.barnes@gmail.com; dkim=pass header.i=mary.ietf.barnes@gmail.com Received: from mr.google.com ([10.52.70.165]) by 10.52.70.165 with SMTP id n5mr1715545vdu.55.1330102422553 (num_hops = 1); Fri, 24 Feb 2012 08:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=NBjKRTfgkBMka2PIaBBvSPUcuVM33HyinPp/pBwKyic=; b=gt9L/UjYzBkprgqCiu46uroQj0X7hjide/BEYxRH8uSAky48QGhQu6b9rtyx/oem2H 2CLmFNvr7ieucQPisSUTbJZAH/Z7hFYBjXEdILSrpNA1+i2A0jPAaRuI1yJ6ZIjYmTB9 0OEcNIjBCuMrO7LKgOpzT/l1G5Qjwy/HSE9xE= MIME-Version: 1.0 Received: by 10.52.70.165 with SMTP id n5mr1371721vdu.55.1330102422516; Fri, 24 Feb 2012 08:53:42 -0800 (PST) Received: by 10.52.114.200 with HTTP; Fri, 24 Feb 2012 08:53:40 -0800 (PST) Date: Fri, 24 Feb 2012 10:53:40 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec5015e5368b52004b9b89a5d Subject: [clue] WG Deadlines for IETF-83 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, 24 Feb 2012 16:53:47 -0000 --bcaec5015e5368b52004b9b89a5d Content-Type: text/plain; charset=ISO-8859-1 Per the email forwarded yesterday, we have been allocated two slots (one 2.5 and one 2.0 hours) at IETF-83. The draft deadlines are as follows: March 5th, 17:00 Pacific: -00 drafts (One week from this coming Monday!!!) March 12th, 17:00 Pacific: -01+ drafts (Two weeks from this coming Monday!!!) We will publish a preliminary agenda no later than March 14th. We will not be allowing presentations without corresponding documents. Rough -00 drafts are perfectly fine - we just need folks to have some context for the topics for each presentation. Please notify the chairs if you would like an agenda slot for your document(s) no later than March 7th, 2012. Agenda time will be allocated based on the level of WG discussion on each of the documents before the meeting. A revised final WG agenda will be published no later than March 19th. We may modify the agenda for the 2nd WG session based on the outcome of the 1st. Thanks, Mary and Paul (CLUE WG co-chairs) --bcaec5015e5368b52004b9b89a5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Per the email forwarded yesterday, we have been allocated two slots (one 2.= 5 and one 2.0 hours) at IETF-83. =A0The draft deadlines are as follows:March 5th, 17:00 Pacific: =A0-00 drafts =A0(One week from this coming Mond= ay!!!)
March 12th, 17:00 Pacific: -01+ drafts (Two weeks from this coming Mon= day!!!)

We will publish a preliminary agenda no la= ter than March 14th. We will not be allowing presentations without correspo= nding documents. =A0Rough -00 drafts are perfectly fine - we just need folk= s to have some context for the topics for each presentation. =A0=A0

Please notify the chairs if you would like an agenda sl= ot for your document(s) no later than March 7th, 2012. =A0Agenda time will = be allocated based on the level of WG discussion on each of the documents b= efore the meeting. A revised final WG agenda will be published no later tha= n March 19th. We may modify the agenda for the 2nd WG session based on the = outcome of the 1st. =A0=A0

Thanks,
Mary and Paul
(CLUE WG co-c= hairs)
--bcaec5015e5368b52004b9b89a5d-- From ron.even.tlv@gmail.com Mon Feb 27 01:18: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 9499D21F85A5 for ; Mon, 27 Feb 2012 01:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 3H6VYzIEO6FL for ; Mon, 27 Feb 2012 01:18:26 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2510721F85A3 for ; Mon, 27 Feb 2012 01:18:22 -0800 (PST) Received: by eeke51 with SMTP id e51so732432eek.31 for ; Mon, 27 Feb 2012 01:18:21 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.194.136 as permitted sender) client-ip=10.14.194.136; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.194.136 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.194.136]) by 10.14.194.136 with SMTP id m8mr7370374een.97.1330334301760 (num_hops = 1); Mon, 27 Feb 2012 01:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=B1+YFYxkQO5JpefhBh2AUouLVqiCSr11Q9UyoC0H4XY=; b=UvEs+x8HgbGFPPNf7jNVLT502SGX9TVKbqP6lfADgKaakQTPLDDWQerMGKxr2AhKhq WhGmOBasT12tBpqvhA9js511Cjp6/F4iM9nWoIbKXCgXYiowTMiAL3valNqp64AXbtDN vpXDcdpXtbbgPMr+KhiN84gUizxgnGpLlRlC8= Received: by 10.14.194.136 with SMTP id m8mr5577563een.97.1330334301592; Mon, 27 Feb 2012 01:18:21 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id w60sm55915083eeb.4.2012.02.27.01.18.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Feb 2012 01:18:20 -0800 (PST) From: "Roni Even" To: "'Paul Kyzivat'" , "'CLUE'" References: <4F42C6A8.3000602@alum.mit.edu> In-Reply-To: <4F42C6A8.3000602@alum.mit.edu> Date: Mon, 27 Feb 2012 11:17:45 +0200 Message-ID: <4f4b4a5c.54310e0a.531a.47b1@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: AczwHZAluKYtCV6MSQKR0Xv5qTRGdAFBspMQ Content-Language: en-us Subject: Re: [clue] Clue signaling alternatives discussed at the 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: Mon, 27 Feb 2012 09:18:30 -0000 Hi Paul, A general comment, I think that we have an open issue if CLUE need three messages or two messages. Consumer capabilities message is still in question. As for the description I think we should use the consumer, provider terms so we have for example in A caller provider advertisement and callee consumer configuration. As for A1, I am not sure that this was the proposal on the whiteboard but it is a valid option for the moment. My understanding is that we discussed A2 where the CLUE exchange is done in a separate MIME body in the offer answer exchange and having the individual encodes as part of the regular SDP. The major point about A is that the initial offer may include all media channels using grouping probably based on http://www.ietf.org/id/draft-ietf-mmusic-sdp-bundle-negotiation-00.txt . We also had another option based on A2 which will carry the CLUE messages in a separate SIP method for example using an INFO package. This will mean a two stage call setup starting with one audio and maybe one video and adding the rest after doing the CLUE negotiation. I think that this is what you call B2. I think it can be broken differently Three main topics: A) how to carry the CLUE information: 1. Using SIP offer answer with a second MIME body for CLUE. 2. Using SIP offer answer with an offer for a CLUE channel (similar to BFCP channel open) 3. Using SIP offer answer and doing CLUE using another SIP method for example using INFO package B) What does the initial offer answer include (here we are also assuming that CLUE endpoint MUST support ssrc multiplexing but not necessarily using one UDP port): 1. All possible simultaneous media lines described in SDP (based on bundle) in the initial offer answer. See http://tools.ietf.org/html/draft-even-clue-rtp-mapping-00 2. SDP will have one audio and one video (maybe two) and all media captures will be negotiated based on CLUE and http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-02 C) Is it required to have the offer answer with SDP refelct all the currently configured media streams in order to address intermediaries like SBCs. This was discuss in MMUSIC see http://tools.ietf.org/html/rfc5939#section-3.12 Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, February 21, 2012 12:18 AM > To: CLUE > Subject: [clue] Clue signaling alternatives discussed at the interim > > I promised to post a cleaned up version of the three alternative > approaches to signaling for CLUE that we discussed and wrote on the > whiteboard during the interim last Thursday. Following is my attempt at > that. > > Thanks, > Paul > > This covers the signaling for establishment of a point-to-point clue > session. It assumes symmetry - that the two participants are comparable > and it doesn't matter which one initiates the session. However I think > everyone agreed that its also applicable to a session established > between a room and an MCU. This assumes that there are two > capabilities/advertisement/selection exchanges traveling in opposite > directions. These are denoted as caller-capabilties, callee- > capabilties, etc. So the two exchanges consist of: > > - caller-capabilities, callee-advertisement, caller-selection > - callee-capabilities, caller-advertisement, callee-selection > > Each approach is a different way of combining/coordinating these > exchanges with sip signaling. In the meeting we labeled these > alternatives A, B, C. I've preserved and extended this to A1, A2, B1, > B2, C. > > _______________________________ > > A) (this was really two alternatives run together. I've broken it out > as > two.) > > A1) The advertisement/selection are encoded in SDP offers and answers, > using some combination of existing and new SDP syntax. > > - caller-advertisement in the SDP of the initial SDP offer. > > - callee-selection in the SDP of the initial SDP answer. > - callee-advertisement is also in the SDP of the initial SDP answer. > > - caller-selection in the SDP of a 2nd SDP offer. > > This doesn't include a way to send capabilities. > > The encoding is presumed to build on standard SDP audio and video media > syntax in such a way that a callee that doesn't support clue will still > be able to accept the basic audio and/or video. > > A2) The capabilities/advertisement/selection are encoded in a separate > body part with the sip messages, coexisting with the SDP offers and > answers. This entails use of multipart/mixed so that both can reside in > the same message. The encoding within this body part could be XML or > something else. > > - caller-advertisement in a separate body part with the > initial SDP offer. > > - callee-selection in a separate body part with the > initial SDP answer. > - callee-advertisement is also in a separate body part with the > initial SDP answer. > > - caller-selection in a separate body part with a > 2nd SDP offer. > > This doesn't include a way to send capabilities. > > Its hoped that a UA that doesn't support CLUE will be able to deal with > the multipart and find the SDP offers and answers while ignoring the > clue-specific body part. > > _______________________________ > > B) The initial INVITE offers "generic" audio and video, designed to be > widely acceptable to audio and video UAs that don't support CLUE. It > includes added syntax proposing establishment of a separate channel for > clue signaling. Then clue capabilities/advertisemens/selections are > exchanged over this channel. Finally there is a 2nd offer/answer > exchange to establish media streams in accord with the selections. > > There are two variations on this: > > B1) and added m-line that establishes a "media" stream for signaling > clue (analogous to bfcp). > > B2) OR the offer of support for a new clue INFO-package. > > If the callee doesn't support clue, then the clue channel will not be > established, and the caller will set things up accordingly using the > generic audio and video streams. > > _______________________________ > > C) This is a variation on (B). It differs in that the encodings and > encoding groups are represented in the SDP of the offer and answer (as > they are in A1) but the remainder of the clue-specific info is > exchanged in the separate clue signaling channel specified in (B). > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Feb 27 09:44: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 5AEAE21F84B9 for ; Mon, 27 Feb 2012 09:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 gM1QgUGyG0rc for ; Mon, 27 Feb 2012 09:44:22 -0800 (PST) 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 E844121F84D3 for ; Mon, 27 Feb 2012 09:44:21 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id f2gX1i0061swQuc515kNnB; Mon, 27 Feb 2012 17:44:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id f5kN1i00607duvL3b5kNc8; Mon, 27 Feb 2012 17:44:22 +0000 Message-ID: <4F4BC0F4.1050407@alum.mit.edu> Date: Mon, 27 Feb 2012 12:44:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Roni Even References: <4F42C6A8.3000602@alum.mit.edu> <4f4b4a5c.54310e0a.531a.47b1@mx.google.com> In-Reply-To: <4f4b4a5c.54310e0a.531a.47b1@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'CLUE' Subject: Re: [clue] Clue signaling alternatives discussed at the 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: Mon, 27 Feb 2012 17:44:23 -0000 On 2/27/12 4:17 AM, Roni Even wrote: > Hi Paul, > A general comment, I think that we have an open issue if CLUE need three > messages or two messages. Consumer capabilities message is still in > question. Yes, I realize that. I think part of this exercise is to explore alternatives, including those that support it and those that don't. > As for the description I think we should use the consumer, provider terms so > we have for example in A caller provider advertisement and callee consumer > configuration. Perhaps. I hadn't thought about it when writing those words. I think this can be added, though I don't think it really changes anything fundamentally. The provider/consumer distinction is analogous to the UAS/UAC distinction - its a role, with most devices supporting both. When sending an advertisement, it is necessarily the case that the device sending it is the provider and the one receiving it is the consumer with respect to that message. My point in using the caller/callee distinction in this description was because that distinguishes one endpoint from the other. > As for A1, I am not sure that this was the proposal on the whiteboard but it > is a valid option for the moment. On the board I had written "in/with" to cover the two alternative ways of conveying the clue messages - either "in" the SDP, or "with" the SDP but in a separate body part. My intent with A1 and A2 was to cover both of these cases in a way that is more explicit and less confusing. Your questioning of this is evidence of the value of clarifying what we thought we were talking about. And of course, just because it is included as an alternative doesn't mean that it will ultimately be chosen. Maybe it will quickly be discarded. But lets see what others have to say about it. > My understanding is that we discussed A2 where the CLUE exchange is done in > a separate MIME body in the offer answer exchange and having the individual > encodes as part of the regular SDP. The major point about A is that the > initial offer may include all media channels using grouping probably based > on http://www.ietf.org/id/draft-ietf-mmusic-sdp-bundle-negotiation-00.txt . > We also had another option based on A2 which will carry the CLUE messages in > a separate SIP method for example using an INFO package. This will mean a > two stage call setup starting with one audio and maybe one video and adding > the rest after doing the CLUE negotiation. I think that this is what you > call B2. > > I think it can be broken differently My hope was that what I wrote described what we discussed in the room. I was expecting the subsequent development to: - refine one or more of the alternatives I documented. (this could just add/change the text, if there is general agreement, or further split an alternative, such as A1.1, A1.2 if we want to explore different directions - adding additional alternatives - e.g. B3 or D or E - agreeing that we are not interested in further pursuing some of the alternatives. I think what you are describing below is a different perspective on the same thing. What we did in the meeting was, effectively, some alternative Use Cases. The breakdown below is a start at describing some mechanisms to support those use cases. IMO both are useful, as long as we are clear that they are distinct, though related, things. > Three main topics: > > A) how to carry the CLUE information: > > 1. Using SIP offer answer with a second MIME body for CLUE. Note that when going this way, it isn't necessary that the new bodies always accompany offers or answers. There may be cases when no offer or answer is needed but there is still a desire to convey CLUE info - e.g. capabilities. I realized that while writing up the alternatives, but was waiting to bring it up because I first wanted to get down what we had discussed. > 2. Using SIP offer answer with an offer for a CLUE channel (similar to BFCP > channel open) > 3. Using SIP offer answer and doing CLUE using another SIP method for > example using INFO package > > B) What does the initial offer answer include (here we are also assuming > that CLUE endpoint MUST support ssrc multiplexing but not necessarily using > one UDP port): > > 1. All possible simultaneous media lines described in SDP (based on bundle) > in the initial offer answer. See > http://tools.ietf.org/html/draft-even-clue-rtp-mapping-00 > 2. SDP will have one audio and one video (maybe two) and all media captures > will be negotiated based on CLUE and > http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-02 Just to check if I understand you: you mean that the negotiations in (2) above will be confirmed by (C) below? > C) Is it required to have the offer answer with SDP refelct all the > currently configured media streams in order to address intermediaries like > SBCs. This was discuss in MMUSIC see > http://tools.ietf.org/html/rfc5939#section-3.12 > > > Roni Even Thanks, Paul >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Tuesday, February 21, 2012 12:18 AM >> To: CLUE >> Subject: [clue] Clue signaling alternatives discussed at the interim >> >> I promised to post a cleaned up version of the three alternative >> approaches to signaling for CLUE that we discussed and wrote on the >> whiteboard during the interim last Thursday. Following is my attempt at >> that. >> >> Thanks, >> Paul >> >> This covers the signaling for establishment of a point-to-point clue >> session. It assumes symmetry - that the two participants are comparable >> and it doesn't matter which one initiates the session. However I think >> everyone agreed that its also applicable to a session established >> between a room and an MCU. This assumes that there are two >> capabilities/advertisement/selection exchanges traveling in opposite >> directions. These are denoted as caller-capabilties, callee- >> capabilties, etc. So the two exchanges consist of: >> >> - caller-capabilities, callee-advertisement, caller-selection >> - callee-capabilities, caller-advertisement, callee-selection >> >> Each approach is a different way of combining/coordinating these >> exchanges with sip signaling. In the meeting we labeled these >> alternatives A, B, C. I've preserved and extended this to A1, A2, B1, >> B2, C. >> >> _______________________________ >> >> A) (this was really two alternatives run together. I've broken it out >> as >> two.) >> >> A1) The advertisement/selection are encoded in SDP offers and answers, >> using some combination of existing and new SDP syntax. >> >> - caller-advertisement in the SDP of the initial SDP offer. >> >> - callee-selection in the SDP of the initial SDP answer. >> - callee-advertisement is also in the SDP of the initial SDP answer. >> >> - caller-selection in the SDP of a 2nd SDP offer. >> >> This doesn't include a way to send capabilities. >> >> The encoding is presumed to build on standard SDP audio and video media >> syntax in such a way that a callee that doesn't support clue will still >> be able to accept the basic audio and/or video. >> >> A2) The capabilities/advertisement/selection are encoded in a separate >> body part with the sip messages, coexisting with the SDP offers and >> answers. This entails use of multipart/mixed so that both can reside in >> the same message. The encoding within this body part could be XML or >> something else. >> >> - caller-advertisement in a separate body part with the >> initial SDP offer. >> >> - callee-selection in a separate body part with the >> initial SDP answer. >> - callee-advertisement is also in a separate body part with the >> initial SDP answer. >> >> - caller-selection in a separate body part with a >> 2nd SDP offer. >> >> This doesn't include a way to send capabilities. >> >> Its hoped that a UA that doesn't support CLUE will be able to deal with >> the multipart and find the SDP offers and answers while ignoring the >> clue-specific body part. >> >> _______________________________ >> >> B) The initial INVITE offers "generic" audio and video, designed to be >> widely acceptable to audio and video UAs that don't support CLUE. It >> includes added syntax proposing establishment of a separate channel for >> clue signaling. Then clue capabilities/advertisemens/selections are >> exchanged over this channel. Finally there is a 2nd offer/answer >> exchange to establish media streams in accord with the selections. >> >> There are two variations on this: >> >> B1) and added m-line that establishes a "media" stream for signaling >> clue (analogous to bfcp). >> >> B2) OR the offer of support for a new clue INFO-package. >> >> If the callee doesn't support clue, then the clue channel will not be >> established, and the caller will set things up accordingly using the >> generic audio and video streams. >> >> _______________________________ >> >> C) This is a variation on (B). It differs in that the encodings and >> encoding groups are represented in the SDP of the offer and answer (as >> they are in A1) but the remainder of the clue-specific info is >> exchanged in the separate clue signaling channel specified in (B). >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From Mark.Duckworth@polycom.com Mon Feb 27 14:32: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 EA59B21E802B for ; Mon, 27 Feb 2012 14:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 SjtyF2fch2M4 for ; Mon, 27 Feb 2012 14:32:17 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8706721E8036 for ; Mon, 27 Feb 2012 14:32:01 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 27 Feb 2012 14:32:00 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Mon, 27 Feb 2012 14:31:59 -0800 Thread-Topic: [clue] Encoding groups - Review of framework-03 Thread-Index: AczxoJk+KwR6Kwu7R+apYodvYYunXA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB5DFB1A@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Encoding groups - Review of framework-03 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, 27 Feb 2012 22:32:18 -0000 Hi Roni, Comments inline. Mark =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Wednesday, February 08, 2012 8:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 18. Figure 1 in section 7.2 is not clear, what is the relation of the propo= sed encoding groups to the media captures. [Duckworth, Mark] Section 8 explains that relationship. Figure 1 is not su= pposed to show the relationship. I hope the relationship will be more clea= r from the data model, which I think will be a different document. 19. The last sentence in 7.2 "There is no requirement for all encodings wit= hin an encoding group to be instantiated at once" is not clear to me with r= espect to the rest of the section. [Duckworth, Mark] The consumer chooses an individual encoding to use for an= y stream it wants to receive from a media capture. If the provider adverti= ses the availability of more individual encodings than what the consumer wa= nts to receive, then there is no problem, some of them will not be used. 20. In section 8 "Every media capture is associated with an encoding group"= is it a media capture or a capture set entry? [Duckworth, Mark] It is a media capture. A capture set entry can contain m= ultiple media captures. Each media capture can use a different encoding gr= oup. 21. I read section 8 and most of it is not clear. The last sentence is the = only sentence that is needed. [Duckworth, Mark] I think most of this information in section 8 is needed. = If you read section 9 and then go back and read section 8 again does it be= come more clear? If not, can you ask more specific questions to help us cl= arify it? Maybe these sections about encoding groups can be clarified (or changed) af= ter we make more progress on knowing how SDP m-lines will be used with CLUE= . =20 Mark From mary.ietf.barnes@gmail.com Mon Feb 27 16:16: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 EA42821F86FD for ; Mon, 27 Feb 2012 16:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.602 X-Spam-Level: X-Spam-Status: No, score=-104.602 tagged_above=-999 required=5 tests=[AWL=0.996, 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 nEt7WYrAHOwU for ; Mon, 27 Feb 2012 16:16:32 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD3DD21F86F9 for ; Mon, 27 Feb 2012 16:16:31 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1766232vbb.31 for ; Mon, 27 Feb 2012 16:16:31 -0800 (PST) Received-SPF: pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.91.193 as permitted sender) client-ip=10.52.91.193; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.91.193 as permitted sender) smtp.mail=mary.ietf.barnes@gmail.com; dkim=pass header.i=mary.ietf.barnes@gmail.com Received: from mr.google.com ([10.52.91.193]) by 10.52.91.193 with SMTP id cg1mr9283810vdb.21.1330388191378 (num_hops = 1); Mon, 27 Feb 2012 16:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=RHcPWHjpM6a/GF2Edcdk0B79LddDiAH40W6QuoXP+iM=; b=vOiXnmpqLe6MQNTghzB8F9jmrG34PNEqlTyDTufF5SsdeCBl2D1rW4o+9KfkAiuU2V rg5Kd5Fe5HUJExj8DkoT5dtMsMumBA9Dzh8JyyMQo6bFR81uLbwxg7XQKx58vI8xmwwN p7owGgvNTETxkRrKFpuQqZjI2xWg5/ikfZkQU= MIME-Version: 1.0 Received: by 10.52.91.193 with SMTP id cg1mr7597135vdb.21.1330388191150; Mon, 27 Feb 2012 16:16:31 -0800 (PST) Received: by 10.52.34.138 with HTTP; Mon, 27 Feb 2012 16:16:31 -0800 (PST) Date: Mon, 27 Feb 2012 18:16:31 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec5015d238c02ef04b9fb2316 Subject: [clue] 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: Tue, 28 Feb 2012 00:16:33 -0000 --bcaec5015d238c02ef04b9fb2316 Content-Type: text/plain; charset=ISO-8859-1 Let's have a meeting tomorrow and discuss the signaling options that are being discussed on the mailing list: http://www.ietf.org/mail-archive/web/clue/current/msg01076.html Regards, Mary. =========================================== Topic: CLUE WG Design Team Date: Tuesday, February 28, 2012 Time: 9:00 am, Central Standard Time (Chicago, GMT-06:00) Meeting Number: 640 231 272 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=150507847&UID=0&PW=NYWQ0NzNhYmYy&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=150507847&UID=0&PW=NYWQ0NzNhYmYy&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): +1-408-600-3600 Access code:640 231 272 ------------------------------------------------------- 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=150507847&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=9b-045xLdAOgtFE7d/7fifMF2twrRz-mS2mPAmn79Bg=&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:+14086003600x640231272# 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. **** --bcaec5015d238c02ef04b9fb2316 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Let's have a meeting tomorrow and discuss the signaling options that ar= e being discussed on the mailing list:

Regards,
Mary.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: CLUE W= G Design Team
Date: Tuesday, February 28, 2012
Time: 9:00 am, Centr= al Standard Time (Chicago, GMT-06:00)
Meeting Number: 640 231 272
M= eeting Password: 1234


-------------------------------------------------------
To join= the online meeting (Now from mobile devices!)
------------------------= -------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?ED=3D150507847&= ;UID=3D0&PW=3DNYWQ0NzNhYmYy&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.co= m/ietf/j.php?ED=3D150507847&UID=3D0&PW=3DNYWQ0NzNhYmYy&ORT=3DMi= M3

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

Access code:640 231 272

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

You can c= ontact me at:
clue-chairs@tools.ietf.org


To add this meeting to yo= ur calendar program (for example Microsoft Outlook), click this link:
https://ietf.web= ex.com/ietf/j.php?ED=3D150507847&UID=3D0&ICS=3DMI&LD=3D1&RD= =3D2&ST=3D1&SHA2=3D9b-045xLdAOgtFE7d/7fifMF2twrRz-mS2mPAmn79Bg=3D&a= mp;RT=3DMiM3

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 comput= er 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.web= ex.com

CCP:+14086003600x640231272#

IMPORTANT NOTICE: This WebEx servic= e includes a feature that allows audio and any documents and other material= s exchanged or viewed during the session to be recorded. By joining this se= ssion, 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 suc= h recordings may be subject to discovery in the event of litigation.


--bcaec5015d238c02ef04b9fb2316-- From marshall.eubanks@gmail.com Mon Feb 27 16:33: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 9B7CB21F869D for ; Mon, 27 Feb 2012 16:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.514 X-Spam-Level: X-Spam-Status: No, score=-104.514 tagged_above=-999 required=5 tests=[AWL=1.085, 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 2HXh2PeBRx4R for ; Mon, 27 Feb 2012 16:33:22 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47BCE21F867C for ; Mon, 27 Feb 2012 16:32:55 -0800 (PST) Received: by lagj5 with SMTP id j5so2890655lag.31 for ; Mon, 27 Feb 2012 16:32:54 -0800 (PST) Received-SPF: pass (google.com: domain of marshall.eubanks@gmail.com designates 10.152.112.132 as permitted sender) client-ip=10.152.112.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of marshall.eubanks@gmail.com designates 10.152.112.132 as permitted sender) smtp.mail=marshall.eubanks@gmail.com; dkim=pass header.i=marshall.eubanks@gmail.com Received: from mr.google.com ([10.152.112.132]) by 10.152.112.132 with SMTP id iq4mr13224903lab.28.1330389174191 (num_hops = 1); Mon, 27 Feb 2012 16:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W5kOr2ZlviHWb542oGwVVqClXVR8us8BeDve7PwnP3A=; b=FXETkASXY1/LWFFCDGpivheTpD1ztDs55OHYDYIgJB7KIYIjol89ZiwdfiFTVWBxqm sDc1brLpDZIINEgp2hPfWIE1ViMFKVSq22QyDV6PXh8vF1WTOZT6+y49sVvuhM1llv0m XPrhxqLv8agMboZrwHiPy+NoywLm9wt7XPWA4= MIME-Version: 1.0 Received: by 10.152.112.132 with SMTP id iq4mr11061756lab.28.1330389174019; Mon, 27 Feb 2012 16:32:54 -0800 (PST) Received: by 10.112.130.7 with HTTP; Mon, 27 Feb 2012 16:32:54 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Feb 2012 19:32:54 -0500 Message-ID: From: Marshall Eubanks To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] 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: Tue, 28 Feb 2012 00:33:23 -0000 Do we have minutes from the interim ? Notes ? Marshall On Mon, Feb 27, 2012 at 7:16 PM, Mary Barnes wrote: > Let's have a meeting tomorrow and discuss the signaling options that are > being discussed on the mailing list: > http://www.ietf.org/mail-archive/web/clue/current/msg01076.html > > Regards, > Mary. > > > =========================================== > > Topic: CLUE WG Design Team > Date: Tuesday, February 28, 2012 > Time: 9:00 am, Central Standard Time (Chicago, GMT-06:00) > Meeting Number: 640 231 272 > Meeting Password: 1234 > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://ietf.webex.com/ietf/j.php?ED=150507847&UID=0&PW=NYWQ0NzNhYmYy&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=150507847&UID=0&PW=NYWQ0NzNhYmYy&ORT=MiM3 > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > Call-in toll number (US/Canada): +1-408-600-3600 > > Access code:640 231 272 > > ------------------------------------------------------- > 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=150507847&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=9b-045xLdAOgtFE7d/7fifMF2twrRz-mS2mPAmn79Bg=&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:+14086003600x640231272# > > 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. > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Feb 27 17:51: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 D2A5421E8037 for ; Mon, 27 Feb 2012 17:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 Kl5OKc2vzbX6 for ; Mon, 27 Feb 2012 17:51:13 -0800 (PST) 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 CCEE321E8026 for ; Mon, 27 Feb 2012 17:51:12 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta13.westchester.pa.mail.comcast.net with comcast id fB3w1i00827AodY5DDrDnh; Tue, 28 Feb 2012 01:51:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id fDrD1i00W07duvL3fDrDc6; Tue, 28 Feb 2012 01:51:13 +0000 Message-ID: <4F4C330F.1070808@alum.mit.edu> Date: Mon, 27 Feb 2012 20:51:11 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 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] 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: Tue, 28 Feb 2012 01:51:14 -0000 Sorry - I will post the notes shortly. Paul On 2/27/12 7:32 PM, Marshall Eubanks wrote: > Do we have minutes from the interim ? Notes ? > > Marshall > > On Mon, Feb 27, 2012 at 7:16 PM, Mary Barnes wrote: >> Let's have a meeting tomorrow and discuss the signaling options that are >> being discussed on the mailing list: >> http://www.ietf.org/mail-archive/web/clue/current/msg01076.html >> >> Regards, >> Mary. >> >> >> =========================================== >> >> Topic: CLUE WG Design Team >> Date: Tuesday, February 28, 2012 >> Time: 9:00 am, Central Standard Time (Chicago, GMT-06:00) >> Meeting Number: 640 231 272 >> Meeting Password: 1234 >> >> >> ------------------------------------------------------- >> To join the online meeting (Now from mobile devices!) >> ------------------------------------------------------- >> 1. Go to >> https://ietf.webex.com/ietf/j.php?ED=150507847&UID=0&PW=NYWQ0NzNhYmYy&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=150507847&UID=0&PW=NYWQ0NzNhYmYy&ORT=MiM3 >> >> ------------------------------------------------------- >> To join the audio conference only >> ------------------------------------------------------- >> Call-in toll number (US/Canada): +1-408-600-3600 >> >> Access code:640 231 272 >> >> ------------------------------------------------------- >> 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=150507847&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=9b-045xLdAOgtFE7d/7fifMF2twrRz-mS2mPAmn79Bg=&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:+14086003600x640231272# >> >> 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. >> >> >> >> _______________________________________________ >> 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 Feb 27 19:31: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 CFE4021E8015 for ; Mon, 27 Feb 2012 19:31:03 -0800 (PST) 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=[AWL=1.001, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 x6NxbcErdwSY for ; Mon, 27 Feb 2012 19:31:03 -0800 (PST) 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 C4ACE21E800C for ; Mon, 27 Feb 2012 19:31:02 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta14.westchester.pa.mail.comcast.net with comcast id fFSN1i0040xGWP85EFX3bX; Tue, 28 Feb 2012 03:31:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta12.westchester.pa.mail.comcast.net with comcast id fFX21i01r07duvL3YFX3YR; Tue, 28 Feb 2012 03:31:03 +0000 Message-ID: <4F4C4A75.9080207@alum.mit.edu> Date: Mon, 27 Feb 2012 22:31:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 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] 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: Tue, 28 Feb 2012 03:31:03 -0000 On 2/27/12 7:32 PM, Marshall Eubanks wrote: > Do we have minutes from the interim ? Notes ? I just posted raw notes from John and Allyn, at http://www.ietf.org/proceedings/interim/2012/02/15/clue/minutes/minutes-interim-2012-clue-1.pdf (Sorry about using PDF format - it was the path of least resistance to get a .doc file up there.) Will try to get a somewhat cleaned up version with summary and action items, and maybe in some other format - later. Thanks, Paul > Marshall > > On Mon, Feb 27, 2012 at 7:16 PM, Mary Barnes wrote: >> Let's have a meeting tomorrow and discuss the signaling options that are >> being discussed on the mailing list: >> http://www.ietf.org/mail-archive/web/clue/current/msg01076.html >> >> Regards, >> Mary. >> >> >> =========================================== >> >> Topic: CLUE WG Design Team >> Date: Tuesday, February 28, 2012 >> Time: 9:00 am, Central Standard Time (Chicago, GMT-06:00) >> Meeting Number: 640 231 272 >> Meeting Password: 1234 >> >> >> ------------------------------------------------------- >> To join the online meeting (Now from mobile devices!) >> ------------------------------------------------------- >> 1. Go to >> https://ietf.webex.com/ietf/j.php?ED=150507847&UID=0&PW=NYWQ0NzNhYmYy&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=150507847&UID=0&PW=NYWQ0NzNhYmYy&ORT=MiM3 >> >> ------------------------------------------------------- >> To join the audio conference only >> ------------------------------------------------------- >> Call-in toll number (US/Canada): +1-408-600-3600 >> >> Access code:640 231 272 >> >> ------------------------------------------------------- >> 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=150507847&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=9b-045xLdAOgtFE7d/7fifMF2twrRz-mS2mPAmn79Bg=&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:+14086003600x640231272# >> >> 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. >> >> >> >> _______________________________________________ >> 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 gonzalo.camarillo@ericsson.com Tue Feb 28 03:20: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 5DEDF21F8601 for ; Tue, 28 Feb 2012 03:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.247 X-Spam-Level: X-Spam-Status: No, score=-110.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 SZ9zBmKN91Iw for ; Tue, 28 Feb 2012 03:20:40 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D615221F85A7 for ; Tue, 28 Feb 2012 03:20:39 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-59-4f4cb8869d5d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 26.7E.01970.688BC4F4; Tue, 28 Feb 2012 12:20:39 +0100 (CET) Received: from [131.160.36.141] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012 12:20:38 +0100 Message-ID: <4F4CB886.3070404@ericsson.com> Date: Tue, 28 Feb 2012 13:20:38 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <4F4CB861.4090805@ericsson.com> In-Reply-To: <4F4CB861.4090805@ericsson.com> X-Enigmail-Version: 1.3.4 X-Forwarded-Message-Id: <4F4CB861.4090805@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [clue] Fwd: How to exchange metadata about the media streams established with a SIP session 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, 28 Feb 2012 11:20:40 -0000 FYI. -------- Original Message -------- Subject: How to exchange metadata about the media streams established with a SIP session Date: Tue, 28 Feb 2012 13:20:01 +0200 From: Gonzalo Camarillo To: rai@ietf.org Folks, I am sending this email to the RAI list because it is about an architectural issue that affects more than one WG. Both the CLUE and SIPREC WGs have identified the need to exchange metadata about media streams that have been established using SIP. Both groups need to transport such metadata between SIP UAs. In CLUE, they are studying how to transport their metadata, as documented in: http://tools.ietf.org/html/draft-wenger-clue-transport-01 In SIPREC, they are planning to piggyback the metadata in SIP UPDATEs as an XML-encoded body part. When they need to send a request for full state (as opposed to partial state), they use an UPDATE request with a particular body type, as documented in: http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 The best way to exchange metadata within a SIP session depends on the type of metadata and on how the UAs need to interact with each other (e.g., a UA simply pushing information to the other UA or a more complicated protocol). Given that SIPREC and CLUE have different metadata and interactions, it may well be that we decide to use a different mechanism in each group. Nevertheless, I think both groups would benefit from architecturally-inclined RAI people having a look at their work. Please, continue this discussion focusing on their specific requirements on either the CLUE list or the SIPREC list. Somewhat related to this issue, the RTCWeb group discussed the use of SCTP over UDP as a reliable NAT-friendly way to exchange data between endpoints. Cheers, Gonzalo From john@jlc.net Tue Feb 28 07:58:43 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 7FAD821F86B8 for ; Tue, 28 Feb 2012 07:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.425 X-Spam-Level: X-Spam-Status: No, score=-106.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 QZeqlxpE4mj9 for ; Tue, 28 Feb 2012 07:58:42 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 64ABE21F86B6 for ; Tue, 28 Feb 2012 07:58:42 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0A7AC33C7A; Tue, 28 Feb 2012 10:58:42 -0500 (EST) Date: Tue, 28 Feb 2012 10:58:42 -0500 From: John Leslie To: Mary Barnes Message-ID: <20120228155841.GA23561@verdi> References: 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] Notes from 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, 28 Feb 2012 15:58:43 -0000 Attending: John Leslie, Allyn, Paul Kyzivat, Mark Duckworth, Marshall Eubanks, Mary Barnes, Rob Hansen, Roni Even, Spencer Dawkins, Stephan Wenger 1005 CTO Mary: trying to get host role Mary: email thread on signaling options (trying to share) 1008 clue archives up Mary: lost my WebEx screen... (archive showing again) Mary: A1... A2... B... C... (variation on B) Paul: intent to merely capture what we discussed at meeting; did I succeed? just a starting point for the discussion Allyn: I thought it was good Roni: I tried to do a bit of phrasing... we had some drafts in transport from Stephan; we're talking about three ways to convey the full media description; first issue is clue protocol... three options... tied to all of them, what part of the media description is in the SDP; this info relevant to all of them, where you carry the information about the media itself Rob: inaudible... email on the 27th Mary: focus of these, SDP as a tool, you did higher level Paul: I don't disagree with what Roni said, different way of looking, we were talking essentially use-cases, Roni talking signaling, both are useful to talk about; my thought was we're trying to see how it plays out Roni: on whiteboard... how do you end up setting all the channels eventually, do you offer 1 audio, 1 video, and later negotiate the rest? I tried to say what topics need to be discussed; missing in A) clue as part of the SDP, A1 in Paul's description Rob: (hard to hear) that was the one we agreed we should avoid if possible Mary: are we agreed we want to avoid that Roni: that's OK Mary: A1 is off the table Mary: Roni, yours is more complete Roni: break into topics... analyze what topics being discussed Paul: we need both to express pieces of mechanism and call flow; offer-answer, symmetric pair... at end this has to impact offer-answer, one, two, or more... if you give up capability exchange you can probably make it work in one; your vanilla SIP device might have trouble with one offer-answer Roni: may have problems sending grouping Paul: whether we use bundle or not, one part might be more complex, we don't know yet Roni: depends how you want to negotiate all the media channels... proposal using RTCP, (looking up draft) draft-lennox-clue-rtpusage Allyn: which document that Roni wrote is he talking about? Roni: similar to what bundle is doing... need to try to extend all those options, and code using those options... how to carry clue info, what does initial offer-answer carry, orthogonal; how many messages you need to set up a call, minimum everything in invite, 3264 response; each side has to describe what it can offer; for three modes of negotiation, work out number of messages Paul: maybe we can figure out the worst case... initial invite, exchange 3 messages from each end, followed by another offer-answer, 12 messages; lots of optimizations possible; is 12 messages too many? Roni: it's not 12 messages Paul: possible it could be more... if you use info to do clue messages Marshall: how long would it take, perhaps 800 msec Roni: assumption after first exchange you have at least one audio; user experience, once you get an answer you expect to be able to talk (otherwise you hang up), important for the user experience Marshall: how long it takes is more important than the number of messages Paul: initial media offer structured to be benign (not what you really want to use), will two ends have something useful to exchange while they work on longer negotiation Roni: you start out not knowing the other side talks CLUE... an application issue Marshall: you don't need to receive media to have receiver display "wait for CLUE negotiation" Paul: are we doing anything here that forces a bad user experience? Stephan: one key problem, which screen is left vs. right; I don't call it a good user experience if things flicker up on the wrong screen; sufficient to bring up audio; shouldn't put up any video before the CLUE negotiation, it's normal to come up in mono audio Roni: doesn't cause any problems, receiver will receive only one audio stream, it's normal for the quality of it to change Paul: is the number of messages going to lead to excluding one or more alternatives? do we have to pick one now? Stephan: I'd rather one RT more than limit future capabilities; IMHO it would be foolish not to allow capability messages; we're not talking about cell-phone, these things today take 10-20 seconds to come up Paul: I'm hearing any of these techniques is potentially acceptable Roni: preference for optimized if everything else equal Marshall: RTT is useful to optimize, #messages is not Paul: certain amount of piggybacking... at least two RTTs, may or may not be able to multiplex offer-answers on those, probably talking 3 to 4 RTTs minimum, need to work out the details; you can multiplex CLUE on offer-answer for some but not others; I'm hearing all these options are within an acceptable range Roni: all of them can work, if all work, I prefer less RTTs; we strike out CLUE running in RTP, we need to describe all of them, how many RTTs, then make a decision; another issue is whether all negotiation should be on the signaling channel Paul: I don't think we've gotten far enough to decide that -- can you get all your messages in one PDU Roni: we're talking about end-to-end, not through an intermediary; we have problems opening TCP in those use-cases because of NAT traversal Rob: RTCWEB considering that Paul: we may be forced into ?? over UDP... hand-waving over fragmentation Spencer: that's not the only scenario Paul: convince yourself messages are small enough Mary: let's try to close on this -- work out details of the options -- draft deadline for -00 is Monday Roni: Stephan has transport draft, we'll try to update that to include all three options Stephan: this draft intended to provide an analysis of available options, reasonable to discard not-usable options and provide details on the useful ones 1052 Marshall: I posted XML for Stephan's transport draft Mary: we have two sessions; we may not need another call next Tuesday Marshall: I'm co-chairing a BoF which conflicts with one of them Mary: think we're done 1055 adjourn -- John Leslie From Mark.Duckworth@polycom.com Tue Feb 28 12:50: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 C319321E8060 for ; Tue, 28 Feb 2012 12:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, 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 iI+cFiMVHS6k for ; Tue, 28 Feb 2012 12:50:37 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7698E21E805F for ; Tue, 28 Feb 2012 12:50:36 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 28 Feb 2012 12:50:35 -0800 From: "Duckworth, Mark" To: Roni Even , "'Brian Baldino (bbaldino)'" , "clue@ietf.org" Date: Tue, 28 Feb 2012 12:50:33 -0800 Thread-Topic: [clue] Spatial information - Review of draft-ietf-clue-framework-03 Thread-Index: AczqflaBKakYMuZXS4ChqE3TJmyEiQAvlJaQAsdeNqA= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB5DFEF9@CRPMBOXPRD01.polycom.com> References: <4f3a98ed.06d4e00a.5730.3bbf@mx.google.com> In-Reply-To: <4f3a98ed.06d4e00a.5730.3bbf@mx.google.com> 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_44C6B6B2D0CF424AA90B6055548D7A6102FB5DFEF9CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-framework-03 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, 28 Feb 2012 20:50:39 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB5DFEF9CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Roni, About your suggestion to have a "no spatial order" value for the scale attr= ibute - are you saying there is a need in some cases for a media provider t= o include coordinate numbers for the area of capture or point of capture at= tributes, but also specify "no spatial order" for the scale of these number= s? If so, then what would the numbers mean? Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Tuesday, February 14, 2012 12:25 PM To: 'Brian Baldino (bbaldino)'; clue@ietf.org Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-framewo= rk-03 Hi Brian, Sorry if I was not clear, I meant adding to the current three. The no scale still provide spatial order as seen by the provider. I propose= a "no spatial order" which will tell the consumer to render as it wishes. As for priority, I agree that it can be a separate attribute. Roni From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] Sent: Monday, February 13, 2012 8:36 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Spatial information - Review of draft-ietf-clue-framewo= rk-03 Hey Roni, Was wondering if you could clarify what you mean here: The coordinate units are first discussed in section 4. The currents units w= hich I am OK with are the mm and no unknown. The no scale as far as I under= stand provide units in the coordinates system that allows the provider to d= efine a spatial order that the consumer will use to render, this option can= be used for example by a MCU. I think that we can add two more units. The = first is "no spatial information" this will allow the provider to leave it = to the consumer to decide what order to use. The second is "priority" this = is still no spatial relation between the media captures but the provider ca= n use it to specify which media captures are more important allowing the co= nsumer to select between media captures. You mention two scales but the framework currently allows for three scales:= mm, unknown and no scale...would having these 3 options address your first= point? I'm not sure what you're looking for when you describe allowing th= e consumer to decide what order to use. Also, as far as priority, that seems like something that should be separate= from the spatial information...do you think it belongs with the spatial st= uff or perhaps we can address it somewhere else? -Brian From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, February 08, 2012 5:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 The coordinate units are first discussed in section 4. The currents units w= hich I am OK with are the mm and no unknown. The no scale as far as I under= stand provide units in the coordinates system that allows the provider to d= efine a spatial order that the consumer will use to render, this option can= be used for example by a MCU. I think that we can add two more units. The = first is "no spatial information" this will allow the provider to leave it = to the consumer to decide what order to use. The second is "priority" this = is still no spatial relation between the media captures but the provider ca= n use it to specify which media captures are more important allowing the co= nsumer to select between media captures. Thanks Roni Even --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB5DFEF9CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roni,

About your suggestion to have a “no spatial order&= #8221; value for the scale attribute – are you saying there is a need= in some cases for a media provider to include coordinate numbers for the a= rea of capture or point of capture attributes, but also specify “no s= patial order” for the scale of these numbers?  If so, then what = would the numbers mean?

Mark

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Beha= lf Of Roni Even
Sent: Tuesday, February 14, 2012 12:25 PM
= To: 'Brian Baldino (bbaldino)'; clue@ietf.org
Subject: Re:= [clue] Spatial information - Review of draft-ietf-clue-framework-03

 

Hi Brian,

Sorry if I was not clea= r, I meant adding to the current three.

The no scale still provide spatial ord= er as seen by the provider. I propose a "no spatial order" which = will tell the consumer to render as it wishes.

As for priority, I agree that = it can be a separate attribute.

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

Roni

 

From: Brian Baldino (bbaldino) [mailto:bbaldino@cis= co.com]
Sent: Monday, February 13, 2012 8:36 PM
To: Ro= ni Even; clue@ietf.org
Subject: RE: [clue] Spatial information - = Review of draft-ietf-clue-framework-03

 

= Hey Roni,

Was wond= ering if you could clarify what you mean here:

The coordinate units are first discus= sed in section 4. The currents units which I am OK with are the mm and no u= nknown. The no scale as far as I understand provide units in the coordinate= s system that allows the provider to define a spatial order that the consum= er will use to render, this option can be used for example by a MCU. I thin= k that we can add two more units. The first is “no spatial informatio= n” this will allow the provider to leave it to the consumer to decide= what order to use. The second is “priority” this is still no s= patial relation between the media captures but the provider can use it to s= pecify which media captures are more important allowing the consumer to sel= ect between media captures.

 

Y= ou mention two scales but the framework currently allows for three scales: = mm, unknown and no scale...would having these 3 options address your first = point?  I’m not sure what you’re looking for when you desc= ribe allowing the consumer to decide what order to use.

Also, as far as priority, that seems = like something that should be separate from the spatial information...do yo= u think it belongs with the spatial stuff or perhaps we can address it some= where else?

-Brian=

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni = Even
Sent: Wednesday, February 08, 2012 5:49 AM
To: clue@ietf.org
Subject: [clue] R= eview of draft-ietf-clue-framework-03

 

The coordinate units are first discus= sed in section 4. The currents units which I am OK with are the mm and no u= nknown. The no scale as far as I understand provide units in the coordinate= s system that allows the provider to define a spatial order that the consum= er will use to render, this option can be used for example by a MCU. I thin= k that we can add two more units. The first is “no spatial informatio= n” this will allow the provider to leave it to the consumer to decide= what order to use. The second is “priority” this is still no s= patial relation between the media captures but the provider can use it to s= pecify which media captures are more important allowing the consumer to sel= ect between media captures.

&nbs= p;

Thanks

Roni Even

 

 

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB5DFEF9CRPMBOXPRD01p_-- From Even.roni@huawei.com Tue Feb 28 15:18: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 C698021E802D for ; Tue, 28 Feb 2012 15:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4mYsmEmft4x5 for ; Tue, 28 Feb 2012 15:18:21 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3D74D21E802A for ; Tue, 28 Feb 2012 15:18:21 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M04002A7M2EVV@szxga03-in.huawei.com> for clue@ietf.org; Wed, 29 Feb 2012 07:18:14 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M04004ASM2EZN@szxga03-in.huawei.com> for clue@ietf.org; Wed, 29 Feb 2012 07:18:14 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHM07110; Wed, 29 Feb 2012 07:18:13 +0800 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Feb 2012 07:17:51 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.220]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Wed, 29 Feb 2012 07:18:13 +0800 Date: Tue, 28 Feb 2012 23:18:12 +0000 From: Roni even In-reply-to: <44C6B6B2D0CF424AA90B6055548D7A6102FB5DFEF9@CRPMBOXPRD01.polycom.com> X-Originating-IP: [172.24.1.68] To: "Duckworth, Mark" , Roni Even , "'Brian Baldino (bbaldino)'" , "clue@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_P2A86dLvXT1O4xEYwldigQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [clue] Spatial information - Review of draft-ietf-clue-framework-03 Thread-index: AQHM9lq+58D6zOdAQkyo+i8OnqR/+ZZS42hA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4f3a98ed.06d4e00a.5730.3bbf@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5DFEF9@CRPMBOXPRD01.polycom.com> Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-framework-03 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, 28 Feb 2012 23:18:23 -0000 --Boundary_(ID_P2A86dLvXT1O4xEYwldigQ) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Hi Mark, Maybe I am not clear. The no scale value allows the provider to provide inf= ormation about the rendering order using some non related coordinate where = the use case is the MCU that sends captures from different sources and will= need to update the coordinate information when switching sources. I assume= that this value is to say this are non related sources but please render t= hem using the coordinates as a spatial order. I think that a value of no spatial order with no co-ordinates is needed to = say that the provider does not want to enforce any order. This value is not= needed if you explain what a consumer will do if there is no area of scene= , area of capture and point of capture as part of the CLUE information or i= f there is only subset of these values. My personal view is for the MCU case when all the captures are not related = spatially and are coming from different sources there is no need to provide= information at all. Roni Even ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Duckworth,= Mark [Mark.Duckworth@polycom.com] Sent: Tuesday, February 28, 2012 22:50 To: Roni Even; 'Brian Baldino (bbaldino)'; clue@ietf.org Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-framewo= rk-03 Roni, About your suggestion to have a =93no spatial order=94 value for the scale = attribute =96 are you saying there is a need in some cases for a media prov= ider to include coordinate numbers for the area of capture or point of capt= ure attributes, but also specify =93no spatial order=94 for the scale of th= ese numbers? If so, then what would the numbers mean? Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Tuesday, February 14, 2012 12:25 PM To: 'Brian Baldino (bbaldino)'; clue@ietf.org Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-framewo= rk-03 Hi Brian, Sorry if I was not clear, I meant adding to the current three. The no scale still provide spatial order as seen by the provider. I propose= a "no spatial order" which will tell the consumer to render as it wishes. As for priority, I agree that it can be a separate attribute. Roni From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] Sent: Monday, February 13, 2012 8:36 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Spatial information - Review of draft-ietf-clue-framewo= rk-03 Hey Roni, Was wondering if you could clarify what you mean here: The coordinate units are first discussed in section 4. The currents units w= hich I am OK with are the mm and no unknown. The no scale as far as I under= stand provide units in the coordinates system that allows the provider to d= efine a spatial order that the consumer will use to render, this option can= be used for example by a MCU. I think that we can add two more units. The = first is =93no spatial information=94 this will allow the provider to leave= it to the consumer to decide what order to use. The second is =93priority= =94 this is still no spatial relation between the media captures but the pr= ovider can use it to specify which media captures are more important allowi= ng the consumer to select between media captures. You mention two scales but the framework currently allows for three scales:= mm, unknown and no scale...would having these 3 options address your first= point? I=92m not sure what you=92re looking for when you describe allowin= g the consumer to decide what order to use. Also, as far as priority, that seems like something that should be separate= from the spatial information...do you think it belongs with the spatial st= uff or perhaps we can address it somewhere else? -Brian From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, February 08, 2012 5:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 The coordinate units are first discussed in section 4. The currents units w= hich I am OK with are the mm and no unknown. The no scale as far as I under= stand provide units in the coordinates system that allows the provider to d= efine a spatial order that the consumer will use to render, this option can= be used for example by a MCU. I think that we can add two more units. The = first is =93no spatial information=94 this will allow the provider to leave= it to the consumer to decide what order to use. The second is =93priority= =94 this is still no spatial relation between the media captures but the pr= ovider can use it to specify which media captures are more important allowi= ng the consumer to select between media captures. Thanks Roni Even --Boundary_(ID_P2A86dLvXT1O4xEYwldigQ) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable

Hi Mark,

Maybe I am not clear. The no scale value allows the provider to provide = information about the rendering order using some non related coordinate whe= re the use case is the MCU that sends captures from different sources and w= ill need to update the coordinate information when switching sources. I assume that this value is to say thi= s are non related sources but please render them using the coordinates as a= spatial order.

I think that a value of no spatial order with no co-ordinates is needed = to say that the provider does not want to enforce any order. This value is = not needed if you explain what a consumer will do if there is no area of sc= ene, area of capture and point of capture as part of the CLUE information or if there is only subset of thes= e values.

My personal view is for the MCU case when all the captures are not relat= ed spatially and are coming from different sources there is no need to= provide information at all.

 

Roni Even

From: clue-bounces@ietf.org [clue-bounces@i= etf.org] on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com]
Sent: Tuesday, February 28, 2012 22:50
To: Roni Even; 'Brian Baldino (bbaldino)'; clue@ietf.org
Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-= framework-03

Roni,

About your suggestion= to have a =93no spatial order=94 value for the scale attribute =96 are you= saying there is a need in some cases for a media provider to include coord= inate numbers for the area of capture or point of capture attributes, but also specify =93no spatial order=94 for the sca= le of these numbers?  If so, then what would the numbers mean?<= /p>

Mark

From:<= /span> clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: Tuesday, February 14, 2012 12:25 PM
To: 'Brian Baldino (bbaldino)'; clue@ietf.org
Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-= framework-03

 

Hi Brian,

Sorry if I was not cl= ear, I meant adding to the current three.

The no scale still pr= ovide spatial order as seen by the provider. I propose a "no spatial o= rder" which will tell the consumer to render as it wishes.

As for priority, I ag= ree that it can be a separate attribute.

 

Roni

 

From:<= /span> Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]
Sent: Monday, February 13, 2012 8:36 PM
To: Roni Even; clue@ietf.org
Subject: RE: [clue] Spatial information - Review of draft-ietf-clue-= framework-03

 

Hey Roni,

Was wondering if you could clari= fy what you mean here:

The coordinate units are = first discussed in section 4. The currents units which I am OK with are the= mm and no unknown. The no scale as far as I understand provide units in the coordinates system that allows the pr= ovider to define a spatial order that the consumer will use to render, this= option can be used for example by a MCU. I think that we can add two more = units. The first is =93no spatial information=94 this will allow the provider to leave it to the consumer to= decide what order to use. The second is =93priority=94 this is still no sp= atial relation between the media captures but the provider can use it to sp= ecify which media captures are more important allowing the consumer to select between media captures.

 

You mention two scales but the f= ramework currently allows for three scales: mm, unknown and no scale...woul= d having these 3 options address your first point?  I=92m not sure what you=92re looking for when you descr= ibe allowing the consumer to decide what order to use.

Also, as far as priority, that s= eems like something that should be separate from the spatial information...= do you think it belongs with the spatial stuff or perhaps we can address it somewhere else?

-Brian

From:<= /span> clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, February 08, 2012 5:49 AM
To: clue@ietf.org=
Subject: [clue] Review of draft-ietf-clue-framework-03

 

The coordinate units are = first discussed in section 4. The currents units which I am OK with are the= mm and no unknown. The no scale as far as I understand provide units in the coordinates system that allows the pr= ovider to define a spatial order that the consumer will use to render, this= option can be used for example by a MCU. I think that we can add two more = units. The first is =93no spatial information=94 this will allow the provider to leave it to the consumer to= decide what order to use. The second is =93priority=94 this is still no sp= atial relation between the media captures but the provider can use it to sp= ecify which media captures are more important allowing the consumer to select between media captures.

[mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, February 08, 2012 5:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 The coordinate units are first discussed in section 4. The currents units w= hich I am OK with are the mm and no unknown. The no scale as far as I under= stand provide units in the coordinates system that allows the provider to d= efine a spatial order that the consumer will use to render, this option can= be used for example by a MCU. I think that we can add two more units. The = first is "no spatial information" this will allow the provider to leave it = to the consumer to decide what order to use. The second is "priority" this = is still no spatial relation between the media captures but the provider ca= n use it to specify which media captures are more important allowing the co= nsumer to select between media captures. Thanks Roni Even --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB5E0160CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

Thanks for the clarification.  Let’s see if = I understand your point.  The document should specify that if the prov= ider advertisement does not include area of capture information for a media= capture, then it means that media capture is not spatially related to any = other media capture.  If we specify this, then there is no need to int= roduce a “no spatial order” value for the scale attribute. = ; This seems reasonable to me.

Mark

=

From: Roni even [mailto:Even.roni@huawei.com]
Sent:= Tuesday, February 28, 2012 6:18 PM
To: Duckworth, Mark; Roni Eve= n; 'Brian Baldino (bbaldino)'; clue@ietf.org
Subject: RE: [clue] = Spatial information - Review of draft-ietf-clue-framework-03

 

Hi= Mark,

Maybe I am not clear. The no scale value= allows the provider to provide information about the rendering order using= some non related coordinate where the use case is the MCU that sends captu= res from different sources and will need to update the coordinate informati= on when switching sources. I assume that this value is to say this are non = related sources but please render them using the coordinates as a spatial o= rder.

I think that a value of no spatial order = with no co-ordinates is needed to say that the provider does not want to en= force any order. This value is not needed if you explain what a consumer wi= ll do if there is no area of scene, area of capture and point of capture as= part of the CLUE information or if there is only subset of these values.

My personal view is for the MCU case when all th= e captures are not related spatially and are coming from different sou= rces there is no need to provide information at all.

<= p> 

Roni Even

Fr= om: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf = of Duckworth, Mark [Mark.Duckworth@polycom.com]
Sent: Tuesday, Fe= bruary 28, 2012 22:50
To: Roni Even; 'Brian Baldino (bbaldino)'; = clue@ietf.org
Subject: Re: [clue] Spatial information - Review of= draft-ietf-clue-framework-03

Roni,

About your suggestion to have a “no spatial orde= r” value for the scale attribute – are you saying there is a ne= ed in some cases for a media provider to include coordinate numbers for the= area of capture or point of capture attributes, but also specify “no= spatial order” for the scale of these numbers?  If so, then wha= t would the numbers mean?

Mark

From: clue-bounces@ietf.org [mailto:clue-bounc= es@ietf.org] On Behalf Of Roni Even
Sent: Tuesday, Februar= y 14, 2012 12:25 PM
To: 'Brian Baldino (bbaldino)'; clue@ietf.org=
Subject: Re: [clue] Spatial information - Review of draft-ietf-c= lue-framework-03

 

Hi Brian,

= Sorry if I was not clear, I meant adding to t= he current three.

<= p class=3DMsoNormal>The no scale still provid= e spatial order as seen by the provider. I propose a "no spatial order= " which will tell the consumer to render as it wishes.

As for priority, I agree that it can be a separate attri= bute.

 

Roni

 

Fro= m: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com]
= Sent: Monday, February 13, 2012 8:36 PM
To: Roni Even; clu= e@ietf.org
Subject: RE: [clue] Spatial information - Review of dr= aft-ietf-clue-framework-03

 =

Hey Roni,<= span style=3D'color:black'>

Was wondering if you could clarify what you mean here:

The coordinate units are first discussed in sec= tion 4. The currents units which I am OK with are the mm and no unknown. Th= e no scale as far as I understand provide units in the coordinates system t= hat allows the provider to define a spatial order that the consumer will us= e to render, this option can be used for example by a MCU. I think that we = can add two more units. The first is “no spatial information” t= his will allow the provider to leave it to the consumer to decide what orde= r to use. The second is “priority” this is still no spatial rel= ation between the media captures but the provider can use it to specify whi= ch media captures are more important allowing the consumer to select betwee= n media captures.

<= p class=3DMsoNormal> 

You mention two scales but the framewo= rk currently allows for three scales: mm, unknown and no scale...would havi= ng these 3 options address your first point?  I’m not sure what = you’re looking for when you describe allowing the consumer to decide = what order to use.

=

Also, as far as priority, that seems li= ke something that should be separate from the spatial information...do you = think it belongs with the spatial stuff or perhaps we can address it somewh= ere else?

-Brian<= /o:p>

From: clue-bounces@ietf.= org [mailto:= clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: We= dnesday, February 08, 2012 5:49 AM
To: clue@ietf.org
Subject: [clue] Review= of draft-ietf-clue-framework-03

 

The coordinate units are first disc= ussed in section 4. The currents units which I am OK with are the mm and no= unknown. The no scale as far as I understand provide units in the coordina= tes system that allows the provider to define a spatial order that the cons= umer will use to render, this option can be used for example by a MCU. I th= ink that we can add two more units. The first is “no spatial informat= ion” this will allow the provider to leave it to the consumer to deci= de what order to use. The second is “priority” this is still no= spatial relation between the media captures but the provider can use it to= specify which media captures are more important allowing the consumer to s= elect between media captures.=

 <= /o:p>

Thanks

Roni Even

 

 

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB5E0160CRPMBOXPRD01p_-- From Mark.Duckworth@polycom.com Wed Feb 29 06:53: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 2CA1421F86EF for ; Wed, 29 Feb 2012 06:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 9Pf45Wbil+1u for ; Wed, 29 Feb 2012 06:53:31 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id AA5CC21F8685 for ; Wed, 29 Feb 2012 06:53:31 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 29 Feb 2012 06:53:31 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 29 Feb 2012 06:53:30 -0800 Thread-Topic: [clue] purpose attribute - Review of framework-03 Thread-Index: AczqZdor6Y4oJ5G+QCy1B+TG8u15kwMi7GxA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] purpose attribute - Review of framework-03 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, 29 Feb 2012 14:53:32 -0000 Does anybody have a comment or suggestion about this idea? For the framework document, I'm proposing that instead of defining our own = values for the media capture purpose attribute, instead we refer to RFC4796= and use those values that are already defined. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Duckworth, Mark > Sent: Monday, February 13, 2012 10:47 AM > To: Roni Even; clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 >=20 > Hi Roni, >=20 > Thanks for all the comments. We'll start addressing different topics in > different email threads. >=20 > I was thinking the media capture purpose attribute really should mean the > same thing as the SDP content attribute in RFC4796. Can CLUE just refer = to > RFC4796 for the definition of the purpose attribute values? RFC4796 alre= ady > has an extension mechanism, so we can add new values when needed. >=20 > Mark >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni Even > Sent: Wednesday, February 08, 2012 8:49 AM > To: clue@ietf.org > Subject: [clue] Review of draft-ietf-clue-framework-03 >=20 > 6. In section 6.1.1 I suggest adding one more purpose "SL" for sign lang= uage > indicating that this is the sign language representation of the audio str= eam, > see RFC4796. >=20 > Thanks > Roni Even >=20 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Wed Feb 29 07:01: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 09FEC21F8639 for ; Wed, 29 Feb 2012 07:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.174, 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 W3h6V1ut163H for ; Wed, 29 Feb 2012 07:01:08 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDB321F861C for ; Wed, 29 Feb 2012 07:01:07 -0800 (PST) Received: by eaal12 with SMTP id l12so2855142eaa.31 for ; Wed, 29 Feb 2012 07:01:06 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.31.67 as permitted sender) client-ip=10.213.31.67; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.31.67 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.213.31.67]) by 10.213.31.67 with SMTP id x3mr771570ebc.73.1330527666811 (num_hops = 1); Wed, 29 Feb 2012 07:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=hsLjhZu+luf7SJq05xuowQ4Lkg6va6GleG+JCneW6HA=; b=HmF3y0iAwR+JsDi2fYN2C+s9dgWr7WRJiangIyxjL6bstddeuDoDQdnNolbhbwsgpg sO4Hw5Ph/ZFmo7SSsDpZhQNEemL5P2+t/qqUVPRGRBTUdfBV/6O5MixNAB8ZGfLycAg6 0NVf/SGJlOR6neGT1tk1vpbmGVQT4Oc5eoKxU= Received: by 10.213.31.67 with SMTP id x3mr625027ebc.73.1330527665193; Wed, 29 Feb 2012 07:01:05 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id i10sm43655255eea.8.2012.02.29.07.01.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 07:01:03 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , "'Roni even'" , References: <4f3a98ed.06d4e00a.5730.3bbf@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5DFEF9@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0160@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0160@CRPMBOXPRD01.polycom.com> Date: Wed, 29 Feb 2012 17:00:15 +0200 Message-ID: <4f4e3daf.8a1d0e0a.3db9.05cb@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0481_01CCF703.9D6C8840" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHM9lq+58D6zOdAQkyo+i8OnqR/+ZZS42hAgAEQxzCAAAOcUA== Content-Language: en-us Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-framework-03 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, 29 Feb 2012 15:01:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0481_01CCF703.9D6C8840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mark, This is just a part of the issue. We have three attributes that specify spatial information. Area of scene, area of capture and point of capture. So if what is the cross relation between them. For example if a media capture has an area of capture it MUST have a point of capture. What about if there is an area of scene, is it mandatory to have area of capture for all media captures in the scene, if not what does it mean if there is a media capture without. The framework should address all the possible options. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Wednesday, February 29, 2012 4:48 PM To: Roni even; clue@ietf.org Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-framework-03 Hi Roni, Thanks for the clarification. Let's see if I understand your point. The document should specify that if the provider advertisement does not include area of capture information for a media capture, then it means that media capture is not spatially related to any other media capture. If we specify this, then there is no need to introduce a "no spatial order" value for the scale attribute. This seems reasonable to me. Mark From: Roni even [mailto:Even.roni@huawei.com] Sent: Tuesday, February 28, 2012 6:18 PM To: Duckworth, Mark; Roni Even; 'Brian Baldino (bbaldino)'; clue@ietf.org Subject: RE: [clue] Spatial information - Review of draft-ietf-clue-framework-03 Hi Mark, Maybe I am not clear. The no scale value allows the provider to provide information about the rendering order using some non related coordinate where the use case is the MCU that sends captures from different sources and will need to update the coordinate information when switching sources. I assume that this value is to say this are non related sources but please render them using the coordinates as a spatial order. I think that a value of no spatial order with no co-ordinates is needed to say that the provider does not want to enforce any order. This value is not needed if you explain what a consumer will do if there is no area of scene, area of capture and point of capture as part of the CLUE information or if there is only subset of these values. My personal view is for the MCU case when all the captures are not related spatially and are coming from different sources there is no need to provide information at all. Roni Even _____ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com] Sent: Tuesday, February 28, 2012 22:50 To: Roni Even; 'Brian Baldino (bbaldino)'; clue@ietf.org Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-framework-03 Roni, About your suggestion to have a "no spatial order" value for the scale attribute - are you saying there is a need in some cases for a media provider to include coordinate numbers for the area of capture or point of capture attributes, but also specify "no spatial order" for the scale of these numbers? If so, then what would the numbers mean? Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, February 14, 2012 12:25 PM To: 'Brian Baldino (bbaldino)'; clue@ietf.org Subject: Re: [clue] Spatial information - Review of draft-ietf-clue-framework-03 Hi Brian, Sorry if I was not clear, I meant adding to the current three. The no scale still provide spatial order as seen by the provider. I propose a "no spatial order" which will tell the consumer to render as it wishes. As for priority, I agree that it can be a separate attribute. Roni From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] Sent: Monday, February 13, 2012 8:36 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Spatial information - Review of draft-ietf-clue-framework-03 Hey Roni, Was wondering if you could clarify what you mean here: The coordinate units are first discussed in section 4. The currents units which I am OK with are the mm and no unknown. The no scale as far as I understand provide units in the coordinates system that allows the provider to define a spatial order that the consumer will use to render, this option can be used for example by a MCU. I think that we can add two more units. The first is "no spatial information" this will allow the provider to leave it to the consumer to decide what order to use. The second is "priority" this is still no spatial relation between the media captures but the provider can use it to specify which media captures are more important allowing the consumer to select between media captures. You mention two scales but the framework currently allows for three scales: mm, unknown and no scale...would having these 3 options address your first point? I'm not sure what you're looking for when you describe allowing the consumer to decide what order to use. Also, as far as priority, that seems like something that should be separate from the spatial information...do you think it belongs with the spatial stuff or perhaps we can address it somewhere else? -Brian From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, February 08, 2012 5:49 AM To: clue@ietf.org Subject: [clue] Review of draft-ietf-clue-framework-03 The coordinate units are first discussed in section 4. The currents units which I am OK with are the mm and no unknown. The no scale as far as I understand provide units in the coordinates system that allows the provider to define a spatial order that the consumer will use to render, this option can be used for example by a MCU. I think that we can add two more units. The first is "no spatial information" this will allow the provider to leave it to the consumer to decide what order to use. The second is "priority" this is still no spatial relation between the media captures but the provider can use it to specify which media captures are more important allowing the consumer to select between media captures. Thanks Roni Even ------=_NextPart_000_0481_01CCF703.9D6C8840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mark,

This is just a part of = the issue. We have three attributes that specify spatial = information.

Area of scene, area of capture and point of = capture.

So if what is the cross relation between them. = For example if a media capture has an area of capture it MUST have a = point of capture.

What about if there is an area of scene, is it = mandatory to have area of capture for all media captures in the scene, = if not what does it mean if there is a media capture = without.

The framework should address all the possible = options.

 

Roni

 

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Wednesday, February 29, 2012 4:48 = PM
To: Roni even; clue@ietf.org
Subject: Re: [clue] = Spatial information - Review of = draft-ietf-clue-framework-03

 

Hi Roni,

Thanks for the = clarification.  Let’s see if I understand your point.  = The document should specify that if the provider advertisement does not = include area of capture information for a media capture, then it means = that media capture is not spatially related to any other media = capture.  If we specify this, then there is no need to introduce a = “no spatial order” value for the scale attribute.  This = seems reasonable to me.

Mark

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= = Roni even [mailto:Even.roni@huawei.com] =
Sent: Tuesday, February 28, 2012 6:18 PM
To: = Duckworth, Mark; Roni Even; 'Brian Baldino (bbaldino)'; clue@ietf.org
Subject: RE: = [clue] Spatial information - Review of = draft-ietf-clue-framework-03

 

= Hi Mark,

= Maybe I am not clear. The no scale value allows the provider to provide = information about the rendering order using some non related coordinate = where the use case is the MCU that sends captures from different sources = and will need to update the coordinate information when switching = sources. I assume that this value is to say this are non related sources = but please render them using the coordinates as a spatial = order.

= I think that a value of no spatial order with no co-ordinates is needed = to say that the provider does not want to enforce any order. This value = is not needed if you explain what a consumer will do if there is no area = of scene, area of capture and point of capture as part of the CLUE = information or if there is only subset of these = values.

= My personal view is for the MCU case when all the captures are not = related spatially and are coming from different sources there is no = need to provide information at all.

=  

= Roni Even

= From:= clue-bounces@ietf.org = [clue-bounces@ietf.org] on behalf of Duckworth, Mark = [Mark.Duckworth@polycom.com]
Sent: Tuesday, February 28, 2012 = 22:50
To: Roni Even; 'Brian Baldino (bbaldino)'; clue@ietf.org
Subject: Re: = [clue] Spatial information - Review of = draft-ietf-clue-framework-03

Roni,

About your suggestion to have a “no = spatial order” value for the scale attribute – are you = saying there is a need in some cases for a media provider to include = coordinate numbers for the area of capture or point of capture = attributes, but also specify “no spatial order” for the = scale of these numbers?  If so, then what would the numbers = mean?

Mark

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Roni Even
Sent: Tuesday, February 14, 2012 = 12:25 PM
To: 'Brian Baldino (bbaldino)'; clue@ietf.org
Subject: Re: = [clue] Spatial information - Review of = draft-ietf-clue-framework-03

 

Hi Brian,

Sorry if I was not clear, I meant adding to the = current three.

The no scale still provide spatial order as seen = by the provider. I propose a "no spatial order" which will = tell the consumer to render as it wishes.

As for priority, I agree that it can be a = separate attribute.

 

Roni

 

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>= From:= Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] =
Sent: Monday, February 13, 2012 8:36 PM
To: Roni = Even; clue@ietf.org
Subject: RE: = [clue] Spatial information - Review of = draft-ietf-clue-framework-03

 

Hey Roni,

Was wondering if you could clarify what you mean = here:

The coordinate units are first discussed in section 4. The currents = units which I am OK with are the mm and no unknown. The no scale as far = as I understand provide units in the coordinates system that allows the = provider to define a spatial order that the consumer will use to render, = this option can be used for example by a MCU. I think that we can add = two more units. The first is “no spatial information” this = will allow the provider to leave it to the consumer to decide what order = to use. The second is “priority” this is still no spatial = relation between the media captures but the provider can use it to = specify which media captures are more important allowing the consumer to = select between media captures.

 

You mention two scales but the framework currently = allows for three scales: mm, unknown and no scale...would having these 3 = options address your first point?  I’m not sure what = you’re looking for when you describe allowing the consumer to = decide what order to use.

Also, as far as priority, that seems like something = that should be separate from the spatial information...do you think it = belongs with the spatial stuff or perhaps we can address it somewhere = else?

-Brian

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black'>= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Wednesday, February 08, 2012 5:49 = AM
To: clue@ietf.org
Subject: [clue] Review of = draft-ietf-clue-framework-03

 

The coordinate units are first discussed in section 4. The currents = units which I am OK with are the mm and no unknown. The no scale as far = as I understand provide units in the coordinates system that allows the = provider to define a spatial order that the consumer will use to render, = this option can be used for example by a MCU. I think that we can add = two more units. The first is “no spatial information” this = will allow the provider to leave it to the consumer to decide what order = to use. The second is “priority” this is still no spatial = relation between the media captures but the provider can use it to = specify which media captures are more important allowing the consumer to = select between media captures.

 

Thanks

Roni Even

 

 

 

------=_NextPart_000_0481_01CCF703.9D6C8840-- From ron.even.tlv@gmail.com Wed Feb 29 07:02: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 761A821F86F0 for ; Wed, 29 Feb 2012 07:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 RfNRuilXKBJG for ; Wed, 29 Feb 2012 07:01:59 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 56D5721F86EF for ; Wed, 29 Feb 2012 07:01:59 -0800 (PST) Received: by eeke51 with SMTP id e51so1694572eek.31 for ; Wed, 29 Feb 2012 07:01:58 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.17.203 as permitted sender) client-ip=10.213.17.203; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.17.203 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.213.17.203]) by 10.213.17.203 with SMTP id t11mr771827eba.127.1330527718646 (num_hops = 1); Wed, 29 Feb 2012 07:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=Ou+N7ZZ8IVhohOhXj2FJUm50IMTq9FhWMoQFxQtvPuM=; b=ujooI1q58/zt1kVzC0oDJWYoxtjEoPX0jQsBQrQBbM7fTr8i5sCGSDw7eMK1S4OX7z idI1jOSf1WmQlZGdHZM1qpK5gyxEW7g+lkBTt4lHQnDjVFdsf2tIyJbgnEc/JiZJpvmw kMoPEmAX23awvRKLY58vOmcH7dyP6VtIU5Zxk= Received: by 10.213.17.203 with SMTP id t11mr623382eba.127.1330527718555; Wed, 29 Feb 2012 07:01:58 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id w60sm83698623eeb.4.2012.02.29.07.01.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 07:01:57 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com> Date: Wed, 29 Feb 2012 17:01:10 +0200 Message-ID: <4f4e3de5.54310e0a.531a.5753@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: AczqZdor6Y4oJ5G+QCy1B+TG8u15kwMi7GxAAABXriA= Content-Language: en-us Subject: Re: [clue] purpose attribute - Review of framework-03 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, 29 Feb 2012 15:02:00 -0000 Mark, I am OK with this. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Duckworth, Mark > Sent: Wednesday, February 29, 2012 4:54 PM > To: clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 > > Does anybody have a comment or suggestion about this idea? > For the framework document, I'm proposing that instead of defining our > own values for the media capture purpose attribute, instead we refer to > RFC4796 and use those values that are already defined. > > Mark > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Duckworth, Mark > > Sent: Monday, February 13, 2012 10:47 AM > > To: Roni Even; clue@ietf.org > > Subject: Re: [clue] purpose attribute - Review of framework-03 > > > > Hi Roni, > > > > Thanks for all the comments. We'll start addressing different topics > > in different email threads. > > > > I was thinking the media capture purpose attribute really should mean > > the same thing as the SDP content attribute in RFC4796. Can CLUE > just > > refer to > > RFC4796 for the definition of the purpose attribute values? RFC4796 > > already has an extension mechanism, so we can add new values when > needed. > > > > Mark > > > > =================================== > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Roni Even > > Sent: Wednesday, February 08, 2012 8:49 AM > > To: clue@ietf.org > > Subject: [clue] Review of draft-ietf-clue-framework-03 > > > > 6. In section 6.1.1 I suggest adding one more purpose "SL" for sign > > language indicating that this is the sign language representation of > > the audio stream, see RFC4796. > > > > Thanks > > Roni Even > > > > > > > > _______________________________________________ > > 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 Mark.Duckworth@polycom.com Wed Feb 29 07:10: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 16D8E21F863F for ; Wed, 29 Feb 2012 07:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, 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 SPMGezXEip6t for ; Wed, 29 Feb 2012 07:10:35 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A80E521F8603 for ; Wed, 29 Feb 2012 07:10:35 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 29 Feb 2012 07:10:35 -0800 From: "Duckworth, Mark" To: Stephan Wenger , "clue@ietf.org" Date: Wed, 29 Feb 2012 07:10:33 -0800 Thread-Topic: Language re capture axis Thread-Index: AQHM6/tnLytIKH/OzUOAFdCyR7eqWJZUDShA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185@CRPMBOXPRD01.polycom.com> 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_44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] Language re capture axis 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, 29 Feb 2012 15:10:37 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephan, I agree in principle with your suggestion, but I think your suggested text = is not mathematically accurate. I think the axis of capture doesn't go to = the center of the area of capture. For example, if the camera is pointed a= t the area of capture at an angle, the center point of the area would not l= ine up with the center point of the camera's field of view (which defines t= he axis). So rather than try to get into the mathematical details, how about this: "Note that, for the purpose of receiver-side geometric correction, it can b= e assumed that the axis of capture of directional capture devices (cameras,= directional microphones etc.) can be calculated from the coordinates of th= e point of capture and area of capture." Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phan Wenger Sent: Wednesday, February 15, 2012 11:04 AM To: clue@ietf.org Subject: [clue] Language re capture axis Hi, The issue I mentioned in the meeting is that nowhere in the framework (as f= ar as I recall) the axis of capture of a video capture (or directional audi= o capture-anything that is not omnidirectional) is undefined. Without that= axis being defined, receiver-side geometric correction is not possible. The issue could be solved in two ways: include attributes, per capture, ind= icating angle of capture in 3D space (relative to what???), or by making th= e bold assumption that the coordinates defining area of capture plus captur= e point define the axis of capture. I suggest the latter as it is easy to = implement and (I believe) practical. The language could be something like: " Note that, for the purpose of receiver-side geometric correction, it can be= assumed that the axis of capture of directional capture devices (cameras, = directional microphones etc.) is the line from the capture point to the cen= ter of the plane of capture. " Stephan --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stepha= n,

I agree in principle wi= th your suggestion, but I think your suggested text is not mathematically a= ccurate.  I think the axis of capture doesn’t go to the center o= f the area of capture.  For example, if the camera is pointed at the a= rea of capture at an angle, the center point of the area would not line up = with the center point of the camera’s field of view (which defines th= e axis).

 =

So rather than try to get into the m= athematical details, how about this:

= 220;Note that, for the purpose of receiver-side geometric correction, it ca= n be assumed that the axis of capture of directional capture devices (camer= as, directional microphones etc.) can be calculated from the coordinates of= the point of capture and area of capture.“

 

Mark

 

From: clue-bounces@ietf= .org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
<= b>Sent: Wednesday, February 15, 2012 11:04 AM
To: clue@ietf.o= rg
Subject: [clue] Language re capture axis

=

 

Hi,

 

The issue I m= entioned in the meeting is that nowhere in the framework (as far as I recal= l) the axis of capture of a video capture (or directional audio captureR= 12;anything that is not omnidirectional) is undefined.  Without that a= xis being defined, receiver-side geometric correction is not possible.=

 

The issue could be solved in tw= o ways: include attributes, per capture, indicating angle of capture in 3D = space (relative to what???), or by making the bold assumption that the coor= dinates defining area of capture plus capture point define the axis of capt= ure.  I suggest the latter as it is easy to implement and (I believe) = practical.

&= nbsp;

The language cou= ld be something like:

=  

"= ;

Note that, for = the purpose of receiver-side geometric correction, it can be assumed that t= he axis of capture of directional capture devices (cameras, directional mic= rophones etc.) is the line from the capture point to the center of the plan= e of capture. 

"

&= nbsp;

Stephan

 <= /p>

 

<= /div>
= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185CRPMBOXPRD01p_-- From stewe@stewe.org Wed Feb 29 07:26: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 21EC521F867A for ; Wed, 29 Feb 2012 07:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.973 X-Spam-Level: X-Spam-Status: No, score=-3.973 tagged_above=-999 required=5 tests=[AWL=-0.375, 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 eOD48fCVLry3 for ; Wed, 29 Feb 2012 07:26:32 -0800 (PST) Received: from DB3EHSOBE006.bigfish.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF2021F8679 for ; Wed, 29 Feb 2012 07:26:31 -0800 (PST) Received: from mail32-db3-R.bigfish.com (10.3.81.236) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Feb 2012 15:26:30 +0000 Received: from mail32-db3 (localhost [127.0.0.1]) by mail32-db3-R.bigfish.com (Postfix) with ESMTP id 6232D24058D; Wed, 29 Feb 2012 15:26:30 +0000 (UTC) X-SpamScore: -15 X-BigFish: PS-15(zz9371Ic85ehzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839hbe3k) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT005.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail32-db3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT005.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail32-db3 (localhost.localdomain [127.0.0.1]) by mail32-db3 (MessageSwitch) id 133052918830990_20976; Wed, 29 Feb 2012 15:26:28 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.249]) by mail32-db3.bigfish.com (Postfix) with ESMTP id 018703A0608; Wed, 29 Feb 2012 15:26:28 +0000 (UTC) Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Feb 2012 15:26:27 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.239]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0123.000; Wed, 29 Feb 2012 15:26:25 +0000 From: Stephan Wenger To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: Language re capture axis Thread-Index: AQHM6/tnLytIKH/OzUOAFdCyR7eqWJZUDShA//+BvIA= Date: Wed, 29 Feb 2012 15:26:23 +0000 Message-ID: In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: multipart/alternative; boundary="_000_CB73837C83B24stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [clue] Language re capture axis 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, 29 Feb 2012 15:26:33 -0000 --_000_CB73837C83B24stewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You analysis of the math appears to be correct. Your proposal is Ok with m= e. Stephan From: "Duckworth, Mark" > Date: Wed, 29 Feb 2012 07:10:33 -0800 To: Stephan Wenger >, "clue@ietf.or= g" > Subject: RE: Language re capture axis Hi Stephan, I agree in principle with your suggestion, but I think your suggested text = is not mathematically accurate. I think the axis of capture doesn=92t go t= o the center of the area of capture. For example, if the camera is pointed= at the area of capture at an angle, the center point of the area would not= line up with the center point of the camera=92s field of view (which defin= es the axis). So rather than try to get into the mathematical details, how about this: =93Note that, for the purpose of receiver-side geometric correction, it can= be assumed that the axis of capture of directional capture devices (camera= s, directional microphones etc.) can be calculated from the coordinates of = the point of capture and area of capture.=93 Mark From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Stephan Wenger Sent: Wednesday, February 15, 2012 11:04 AM To: clue@ietf.org Subject: [clue] Language re capture axis Hi, The issue I mentioned in the meeting is that nowhere in the framework (as f= ar as I recall) the axis of capture of a video capture (or directional audi= o capture=97anything that is not omnidirectional) is undefined. Without th= at axis being defined, receiver-side geometric correction is not possible. The issue could be solved in two ways: include attributes, per capture, ind= icating angle of capture in 3D space (relative to what???), or by making th= e bold assumption that the coordinates defining area of capture plus captur= e point define the axis of capture. I suggest the latter as it is easy to = implement and (I believe) practical. The language could be something like: " Note that, for the purpose of receiver-side geometric correction, it can be= assumed that the axis of capture of directional capture devices (cameras, = directional microphones etc.) is the line from the capture point to the cen= ter of the plane of capture. " Stephan --_000_CB73837C83B24stewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
You analysis of the math appears to be correct.  Your proposal is= Ok with me.
Stephan


From: "Duckworth, Mark" &= lt;Mark.Duckworth@polycom.com= >
Date: Wed, 29 Feb 2012 07:10:33 -08= 00
To: Stephan Wenger <stewe@stewe.org>, "clue@ietf.org" <cl= ue@ietf.org>
Subject: RE: Language re capture ax= is

Hi Stephan,

I agree in principle with your sug= gestion, but I think your suggested text is not mathematically accurate.&nb= sp; I think the axis of capture doesn=92t go to the center of the area of capture.  For example, if the camera is = pointed at the area of capture at an angle, the center point of the area wo= uld not line up with the center point of the camera=92s field of view (whic= h defines the axis).

 

So rather than try to get into the= mathematical details, how about this:

=93Note that, for the purpose of receiver-side geometric co= rrection, it can be assumed that the axis of capture of directional capture= devices (cameras, directional microphones etc.) can be calculated from the coordinates of the point of capture and a= rea of capture.=93

 

Mark

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Wednesday, February 15, 2012 11:04 AM
To: clue@ietf.org
Subject: [clue] Language re capture axis

 

Hi,

 

The issue I mentioned in the meeting is tha= t nowhere in the framework (as far as I recall) the axis of capture of a vi= deo capture (or directional audio capture=97anything that is not omnidirectional) is undefined.  Without that axis being d= efined, receiver-side geometric correction is not possible.

 

The issue could be solved in two ways: incl= ude attributes, per capture, indicating angle of capture in 3D space (relat= ive to what???), or by making the bold assumption that the coordinates defining area of capture plus capture poin= t define the axis of capture.  I suggest the latter as it is easy to i= mplement and (I believe) practical.

 

The language could be something like:<= /o:p>

 

"

Note that, for the purpose of receiver-side= geometric correction, it can be assumed that the axis of capture of direct= ional capture devices (cameras, directional microphones etc.) is the line from the capture point to the center of the = plane of capture. 

"

 

Stephan

 

 

 --_000_CB73837C83B24stewesteweorg_-- From pkyzivat@alum.mit.edu Wed Feb 29 07:48: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 6FB4621F872D for ; Wed, 29 Feb 2012 07:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 6ql1Fkzx7XR9 for ; Wed, 29 Feb 2012 07:48:20 -0800 (PST) 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 B075121F8723 for ; Wed, 29 Feb 2012 07:48:20 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id frVn1i0070EZKEL53roMMq; Wed, 29 Feb 2012 15:48:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta01.westchester.pa.mail.comcast.net with comcast id froL1i00k07duvL3MroLcJ; Wed, 29 Feb 2012 15:48:21 +0000 Message-ID: <4F4E48C3.4020502@alum.mit.edu> Date: Wed, 29 Feb 2012 10:48:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] purpose attribute - Review of framework-03 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, 29 Feb 2012 15:48:21 -0000 On 2/29/12 9:53 AM, Duckworth, Mark wrote: > Does anybody have a comment or suggestion about this idea? > For the framework document, I'm proposing that instead of defining our own values for the media capture purpose attribute, instead we refer to RFC4796 and use those values that are already defined. It appears 4796 is no less vague about the semantics of the values as we have been so far. And 4796 has an IANA registry and provision to add new values via another RFC, so we can add new ones if we need them. But its not enough if we want individual implementations and/or deployments to be able to specify their own values. Note that 4795 allows multiple instances of mediacnt-tag to be attached to a single stream. (E.g. "a=content: main, speaker") This could help when more than one apply to the stream. So clue might need to also allow this. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Duckworth, Mark >> Sent: Monday, February 13, 2012 10:47 AM >> To: Roni Even; clue@ietf.org >> Subject: Re: [clue] purpose attribute - Review of framework-03 >> >> Hi Roni, >> >> Thanks for all the comments. We'll start addressing different topics in >> different email threads. >> >> I was thinking the media capture purpose attribute really should mean the >> same thing as the SDP content attribute in RFC4796. Can CLUE just refer to >> RFC4796 for the definition of the purpose attribute values? RFC4796 already >> has an extension mechanism, so we can add new values when needed. >> >> Mark >> >> =================================== >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Roni Even >> Sent: Wednesday, February 08, 2012 8:49 AM >> To: clue@ietf.org >> Subject: [clue] Review of draft-ietf-clue-framework-03 >> >> 6. In section 6.1.1 I suggest adding one more purpose "SL" for sign language >> indicating that this is the sign language representation of the audio stream, >> see RFC4796. >> >> Thanks >> Roni Even >> >> >> >> _______________________________________________ >> 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 Wed Feb 29 07:55: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 2387921F86C7 for ; Wed, 29 Feb 2012 07:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 9sil4EPZ+iB4 for ; Wed, 29 Feb 2012 07:55:47 -0800 (PST) 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 150BE21F86C6 for ; Wed, 29 Feb 2012 07:55:46 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA11.westchester.pa.mail.comcast.net with comcast id fr9j1i0041uE5Es5BrvnzL; Wed, 29 Feb 2012 15:55:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id frvn1i01V07duvL3crvnwH; Wed, 29 Feb 2012 15:55:47 +0000 Message-ID: <4F4E4A81.6070006@alum.mit.edu> Date: Wed, 29 Feb 2012 10:55:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Language re capture axis 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, 29 Feb 2012 15:55:48 -0000 On 2/29/12 10:10 AM, Duckworth, Mark wrote: > Hi Stephan, > > I agree in principle with your suggestion, but I think your suggested > text is not mathematically accurate. I think the axis of capture doesn’t > go to the center of the area of capture. For example, if the camera is > pointed at the area of capture at an angle, the center point of the area > would not line up with the center point of the camera’s field of view > (which defines the axis). > > So rather than try to get into the mathematical details, how about this: > > “Note that, for the purpose of receiver-side geometric correction, it > can be assumed that the axis of capture of directional capture devices > (cameras, directional microphones etc.) can be calculated from the > coordinates of the point of capture and area of capture.“ IMO this is dangerously vague. Presumably there is a real axis of capture. Hopefully there is a well defined algorithm for deriving the axis from the available data, so that the recipient will determine the actual axis. If so, then it should be specified or referenced from some source. Otherwise we run the risk that not all will correctly derive the axis. Thanks, Paul > Mark > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Stephan Wenger > *Sent:* Wednesday, February 15, 2012 11:04 AM > *To:* clue@ietf.org > *Subject:* [clue] Language re capture axis > > Hi, > > The issue I mentioned in the meeting is that nowhere in the framework > (as far as I recall) the axis of capture of a video capture (or > directional audio capture—anything that is not omnidirectional) is > undefined. Without that axis being defined, receiver-side geometric > correction is not possible. > > The issue could be solved in two ways: include attributes, per capture, > indicating angle of capture in 3D space (relative to what???), or by > making the bold assumption that the coordinates defining area of capture > plus capture point define the axis of capture. I suggest the latter as > it is easy to implement and (I believe) practical. > > The language could be something like: > > " > > Note that, for the purpose of receiver-side geometric correction, it can > be assumed that the axis of capture of directional capture devices > (cameras, directional microphones etc.) is the line from the capture > point to the center of the plane of capture. > > " > > Stephan > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Feb 29 08:14: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 B325B21F8780 for ; Wed, 29 Feb 2012 08:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 aoXOAHdeZ8wD for ; Wed, 29 Feb 2012 08:14:07 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1165321F8793 for ; Wed, 29 Feb 2012 08:14:06 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 29 Feb 2012 08:14:06 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Wed, 29 Feb 2012 08:14:05 -0800 Thread-Topic: [clue] Language re capture axis Thread-Index: Acz2+qCowZhVgl0hQbiGejDzo5yfgQAAhN/Q Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E021D@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185@CRPMBOXPRD01.polycom.com> <4F4E4A81.6070006@alum.mit.edu> In-Reply-To: <4F4E4A81.6070006@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] Language re capture axis 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, 29 Feb 2012 16:14:07 -0000 Paul and Stephan, Personally, I'd rather just leave it out altogether because I think it does= n't add anything that needs to be standardized. But Stephan thought it was= important, so I was trying to find a way to say it in an "accurate enough"= way. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Wednesday, February 29, 2012 10:56 AM > To: clue@ietf.org > Subject: Re: [clue] Language re capture axis >=20 > On 2/29/12 10:10 AM, Duckworth, Mark wrote: > > Hi Stephan, > > > > I agree in principle with your suggestion, but I think your suggested > > text is not mathematically accurate. I think the axis of capture > > doesn't go to the center of the area of capture. For example, if the > > camera is pointed at the area of capture at an angle, the center point > > of the area would not line up with the center point of the camera's > > field of view (which defines the axis). > > > > So rather than try to get into the mathematical details, how about this= : > > > > "Note that, for the purpose of receiver-side geometric correction, it > > can be assumed that the axis of capture of directional capture devices > > (cameras, directional microphones etc.) can be calculated from the > > coordinates of the point of capture and area of capture." >=20 > IMO this is dangerously vague. Presumably there is a real axis of capture= . > Hopefully there is a well defined algorithm for deriving the axis from th= e > available data, so that the recipient will determine the actual axis. If = so, then > it should be specified or referenced from some source. Otherwise we run > the risk that not all will correctly derive the axis. >=20 > Thanks, > Paul >=20 > > Mark > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > > Of *Stephan Wenger > > *Sent:* Wednesday, February 15, 2012 11:04 AM > > *To:* clue@ietf.org > > *Subject:* [clue] Language re capture axis > > > > Hi, > > > > The issue I mentioned in the meeting is that nowhere in the framework > > (as far as I recall) the axis of capture of a video capture (or > > directional audio capture-anything that is not omnidirectional) is > > undefined. Without that axis being defined, receiver-side geometric > > correction is not possible. > > > > The issue could be solved in two ways: include attributes, per > > capture, indicating angle of capture in 3D space (relative to > > what???), or by making the bold assumption that the coordinates > > defining area of capture plus capture point define the axis of > > capture. I suggest the latter as it is easy to implement and (I believe= ) > practical. > > > > The language could be something like: > > > > " > > > > Note that, for the purpose of receiver-side geometric correction, it > > can be assumed that the axis of capture of directional capture devices > > (cameras, directional microphones etc.) is the line from the capture > > point to the center of the plane of capture. > > > > " > > > > Stephan > > > > > > > > _______________________________________________ > > 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 Wed Feb 29 08:39: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 F0C0D21F8716 for ; Wed, 29 Feb 2012 08:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 YGWckgdCSUrb for ; Wed, 29 Feb 2012 08:39:37 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2742421F86C8 for ; Wed, 29 Feb 2012 08:39:36 -0800 (PST) Received: by eeke51 with SMTP id e51so1754656eek.31 for ; Wed, 29 Feb 2012 08:39:36 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.28.194 as permitted sender) client-ip=10.14.28.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.28.194 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.28.194]) by 10.14.28.194 with SMTP id g42mr621602eea.44.1330533576365 (num_hops = 1); Wed, 29 Feb 2012 08:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=ZYMMaiuIOho8PczXQ7jafpDbjhY3KOO2cYGZ0nZGkUU=; b=KjJz5tfpzFNCn6eWBTGezLfuzHtBAL+wIpPDAPo44M+fkJ2Gx7/CWUFVyl+t23kf82 VvObO/Los2+R7yfy+1KovjUnJ9qCTuW0MWEfuDEOrTVddTmIVBV2OWbwMnvp7AcIZvEG cax1zc/QoJB3hPYd+7sb8fgBAQEQxVD8kVaZQ= Received: by 10.14.28.194 with SMTP id g42mr489959eea.44.1330533576238; Wed, 29 Feb 2012 08:39:36 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id v51sm84589337eef.2.2012.02.29.08.39.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 08:39:35 -0800 (PST) From: "Roni Even" To: "'Paul Kyzivat'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com> <4F4E48C3.4020502@alum.mit.edu> In-Reply-To: <4F4E48C3.4020502@alum.mit.edu> Date: Wed, 29 Feb 2012 18:38:47 +0200 Message-ID: <4f4e54c7.cb620e0a.7f4c.ffff8599@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: Acz2+ZL5AGLXB0/YQaKOpV27EUsb0AABqLmw Content-Language: en-us Subject: Re: [clue] purpose attribute - Review of framework-03 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, 29 Feb 2012 16:39:45 -0000 Hi, RFC 4795 defines an attribute that can be used to specify the semantics of the stream. The usage is left for application specific document that will provide the interoperability specification. It will be good to use the defined values and the IANA registry since we are also talking in CLUE about multiple streams with different content. The framework should explain how to use the values from RFC 4795 Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Wednesday, February 29, 2012 5:48 PM > To: clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 > > On 2/29/12 9:53 AM, Duckworth, Mark wrote: > > Does anybody have a comment or suggestion about this idea? > > For the framework document, I'm proposing that instead of defining > our own values for the media capture purpose attribute, instead we > refer to RFC4796 and use those values that are already defined. > > It appears 4796 is no less vague about the semantics of the values as > we have been so far. And 4796 has an IANA registry and provision to add > new values via another RFC, so we can add new ones if we need them. > > But its not enough if we want individual implementations and/or > deployments to be able to specify their own values. > > Note that 4795 allows multiple instances of mediacnt-tag to be attached > to a single stream. (E.g. "a=content: main, speaker") This could help > when more than one apply to the stream. So clue might need to also > allow this. > > Thanks, > Paul > > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Duckworth, Mark > >> Sent: Monday, February 13, 2012 10:47 AM > >> To: Roni Even; clue@ietf.org > >> Subject: Re: [clue] purpose attribute - Review of framework-03 > >> > >> Hi Roni, > >> > >> Thanks for all the comments. We'll start addressing different > topics > >> in different email threads. > >> > >> I was thinking the media capture purpose attribute really should > mean > >> the same thing as the SDP content attribute in RFC4796. Can CLUE > >> just refer to > >> RFC4796 for the definition of the purpose attribute values? RFC4796 > >> already has an extension mechanism, so we can add new values when > needed. > >> > >> Mark > >> > >> =================================== > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Roni Even > >> Sent: Wednesday, February 08, 2012 8:49 AM > >> To: clue@ietf.org > >> Subject: [clue] Review of draft-ietf-clue-framework-03 > >> > >> 6. In section 6.1.1 I suggest adding one more purpose "SL" for sign > >> language indicating that this is the sign language representation of > >> the audio stream, see RFC4796. > >> > >> Thanks > >> Roni Even > >> > >> > >> > >> _______________________________________________ > >> 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 Wed Feb 29 08:53: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 A377921F8661 for ; Wed, 29 Feb 2012 08:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 55G9-l-9g6wX for ; Wed, 29 Feb 2012 08:53:06 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 900A121F8684 for ; Wed, 29 Feb 2012 08:53:05 -0800 (PST) Received: by eaal12 with SMTP id l12so2922775eaa.31 for ; Wed, 29 Feb 2012 08:53:04 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.28.4 as permitted sender) client-ip=10.14.28.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.28.4 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.28.4]) by 10.14.28.4 with SMTP id f4mr638495eea.52.1330534384888 (num_hops = 1); Wed, 29 Feb 2012 08:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=VNC61v1Em4nOjYmF69lPIwZD+2AMqhQRzX5eCDx929M=; b=avijS5li6K/PPIHLD1Va45WUNg3AYlhwrg+80a9UPZZbaBqCZcEXbaJpX0fgCLgPmu bSV/CkxFXHGmy0Oj8vVoO9ypujyEWvX7fLxbMy2rz3YKN7g4KxiTUocNCRitzjMUwNFe XdcMb1hTIOXpd6SbgodFLD/WC19RkadTpkT6I= Received: by 10.14.28.4 with SMTP id f4mr500917eea.52.1330534384755; Wed, 29 Feb 2012 08:53:04 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id i10sm44661477eea.8.2012.02.29.08.53.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 08:53:03 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , "'Paul Kyzivat'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185@CRPMBOXPRD01.polycom.com> <4F4E4A81.6070006@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E021D@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E021D@CRPMBOXPRD01.polycom.com> Date: Wed, 29 Feb 2012 18:52:16 +0200 Message-ID: <4f4e57ef.8a1d0e0a.3db9.364c@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: Acz2+qCowZhVgl0hQbiGejDzo5yfgQAAhN/QAAFDR+A= Content-Language: en-us Subject: Re: [clue] Language re capture axis 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, 29 Feb 2012 16:53:06 -0000 Hi, My view is that we should either point out that the axis of capture is not specified or add a value for it. My preference is that since in most cases the area of capture and point of capture will provide the axis of capture we can add a flag that will say whether the axis of capture can be calculated based on the information or not. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Duckworth, Mark > Sent: Wednesday, February 29, 2012 6:14 PM > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] Language re capture axis > > Paul and Stephan, > > Personally, I'd rather just leave it out altogether because I think it > doesn't add anything that needs to be standardized. But Stephan > thought it was important, so I was trying to find a way to say it in an > "accurate enough" way. > > Mark > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Paul Kyzivat > > Sent: Wednesday, February 29, 2012 10:56 AM > > To: clue@ietf.org > > Subject: Re: [clue] Language re capture axis > > > > On 2/29/12 10:10 AM, Duckworth, Mark wrote: > > > Hi Stephan, > > > > > > I agree in principle with your suggestion, but I think your > > > suggested text is not mathematically accurate. I think the axis of > > > capture doesn't go to the center of the area of capture. For > > > example, if the camera is pointed at the area of capture at an > > > angle, the center point of the area would not line up with the > > > center point of the camera's field of view (which defines the > axis). > > > > > > So rather than try to get into the mathematical details, how about > this: > > > > > > "Note that, for the purpose of receiver-side geometric correction, > > > it can be assumed that the axis of capture of directional capture > > > devices (cameras, directional microphones etc.) can be calculated > > > from the coordinates of the point of capture and area of capture." > > > > IMO this is dangerously vague. Presumably there is a real axis of > capture. > > Hopefully there is a well defined algorithm for deriving the axis > from > > the available data, so that the recipient will determine the actual > > axis. If so, then it should be specified or referenced from some > > source. Otherwise we run the risk that not all will correctly derive > the axis. > > > > Thanks, > > Paul > > > > > Mark > > > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > > > Behalf Of *Stephan Wenger > > > *Sent:* Wednesday, February 15, 2012 11:04 AM > > > *To:* clue@ietf.org > > > *Subject:* [clue] Language re capture axis > > > > > > Hi, > > > > > > The issue I mentioned in the meeting is that nowhere in the > > > framework (as far as I recall) the axis of capture of a video > > > capture (or directional audio capture-anything that is not > > > omnidirectional) is undefined. Without that axis being defined, > > > receiver-side geometric correction is not possible. > > > > > > The issue could be solved in two ways: include attributes, per > > > capture, indicating angle of capture in 3D space (relative to > > > what???), or by making the bold assumption that the coordinates > > > defining area of capture plus capture point define the axis of > > > capture. I suggest the latter as it is easy to implement and (I > > > believe) > > practical. > > > > > > The language could be something like: > > > > > > " > > > > > > Note that, for the purpose of receiver-side geometric correction, > it > > > can be assumed that the axis of capture of directional capture > > > devices (cameras, directional microphones etc.) is the line from > the > > > capture point to the center of the plane of capture. > > > > > > " > > > > > > Stephan > > > > > > > > > > > > _______________________________________________ > > > 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 espeberg@cisco.com Wed Feb 29 10:42: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 A429A21F868A for ; Wed, 29 Feb 2012 10:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.135 X-Spam-Level: X-Spam-Status: No, score=-10.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 vXQBAr5s61Au for ; Wed, 29 Feb 2012 10:42:49 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6F01621F8678 for ; Wed, 29 Feb 2012 10:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=4084; q=dns/txt; s=iport; t=1330540969; x=1331750569; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=mabWqfmqDSgRzDSMmVch7LljMz6lnkZexGz6Ke8wizY=; b=h7vYdivUiW5EmyYYwQNwuaw1TLzN/CZp4NgLXQ9ffZacTE+EHOKCwAn2 dQCUZHq+wu1XJag64txI3Q0nQJvJ2uvmTk8FDnWpkGmA8/Fzffk60S46Z ZX5ImzF0c+EmplY8VSwtb2eJR9mGtAOK8io0NpdNl8n8cDyY7EQSKe6Lv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPNwTk+Q/khL/2dsb2JhbABEDrNPgQeBegEBAQQBAQEPAR0KNBcEAgEIDgMEAQEBCgYXAQYBJh8JCAEBBAESCBqHZwuaSwGfFASMehQECwEBDgJBFAuFQwEYBhqCSWMEp3k4gVs X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="67386602" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 29 Feb 2012 18:42: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 q1TIgm8h010994; Wed, 29 Feb 2012 18:42: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); Wed, 29 Feb 2012 19:42:48 +0100 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, 29 Feb 2012 19:42:47 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EFC3367@XMB-AMS-214.cisco.com> In-Reply-To: <4f4e54c7.cb620e0a.7f4c.ffff8599@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] purpose attribute - Review of framework-03 Thread-Index: Acz2+ZL5AGLXB0/YQaKOpV27EUsb0AABqLmwAANM3CA= References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com><4F4E48C3.4020502@alum.mit.edu> <4f4e54c7.cb620e0a.7f4c.ffff8599@mx.google.com> From: "Espen Berger (espeberg)" To: "Roni Even" , "Paul Kyzivat" , X-OriginalArrivalTime: 29 Feb 2012 18:42:48.0581 (UTC) FILETIME=[EF286B50:01CCF711] Subject: Re: [clue] purpose attribute - Review of framework-03 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, 29 Feb 2012 18:42:50 -0000 I agree that we should reuse the definition from RFC4796.=20 Maybe CLUE should change the name of the purpose attribute to content to follow RFC4796. Avoiding confusion is important.=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 29. februar 2012 17:39 To: 'Paul Kyzivat'; clue@ietf.org Subject: Re: [clue] purpose attribute - Review of framework-03 Hi, RFC 4795 defines an attribute that can be used to specify the semantics of the stream. The usage is left for application specific document that will provide the interoperability specification. It will be good to use the defined values and the IANA registry since we are also talking in CLUE about multiple streams with different content. The framework should explain how to use the values from RFC 4795 Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: Wednesday, February 29, 2012 5:48 PM > To: clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 >=20 > On 2/29/12 9:53 AM, Duckworth, Mark wrote: > > Does anybody have a comment or suggestion about this idea? > > For the framework document, I'm proposing that instead of defining > our own values for the media capture purpose attribute, instead we=20 > refer to RFC4796 and use those values that are already defined. >=20 > It appears 4796 is no less vague about the semantics of the values as=20 > we have been so far. And 4796 has an IANA registry and provision to=20 > add new values via another RFC, so we can add new ones if we need them. >=20 > But its not enough if we want individual implementations and/or=20 > deployments to be able to specify their own values. >=20 > Note that 4795 allows multiple instances of mediacnt-tag to be=20 > attached to a single stream. (E.g. "a=3Dcontent: main, speaker") This=20 > could help when more than one apply to the stream. So clue might need=20 > to also allow this. >=20 > Thanks, > Paul >=20 > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > >> Behalf Of Duckworth, Mark > >> Sent: Monday, February 13, 2012 10:47 AM > >> To: Roni Even; clue@ietf.org > >> Subject: Re: [clue] purpose attribute - Review of framework-03 > >> > >> Hi Roni, > >> > >> Thanks for all the comments. We'll start addressing different > topics > >> in different email threads. > >> > >> I was thinking the media capture purpose attribute really should > mean > >> the same thing as the SDP content attribute in RFC4796. Can CLUE=20 > >> just refer to > >> RFC4796 for the definition of the purpose attribute values? =20 > >> RFC4796 already has an extension mechanism, so we can add new=20 > >> values when > needed. > >> > >> Mark > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > >> Behalf Of Roni Even > >> Sent: Wednesday, February 08, 2012 8:49 AM > >> To: clue@ietf.org > >> Subject: [clue] Review of draft-ietf-clue-framework-03 > >> > >> 6. In section 6.1.1 I suggest adding one more purpose "SL" for=20 > >> sign language indicating that this is the sign language=20 > >> representation of the audio stream, see RFC4796. > >> > >> Thanks > >> Roni Even > >> > >> > >> > >> _______________________________________________ > >> 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 Mark.Duckworth@polycom.com Wed Feb 29 14:43: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 9D27121E801F for ; Wed, 29 Feb 2012 14:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, 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 oRRIrqIk1IUz for ; Wed, 29 Feb 2012 14:43:11 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE2121E800E for ; Wed, 29 Feb 2012 14:43:10 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 29 Feb 2012 14:43:10 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 29 Feb 2012 14:43:09 -0800 Thread-Topic: propose "mutually exclusive" attribute to replace simutaneous sets Thread-Index: Acz3MQwPAsai6Sr5R62dhdvpm7sRIg== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com> 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_44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] propose "mutually exclusive" attribute to replace simutaneous sets 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, 29 Feb 2012 22:43:12 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a proposal from all the framework authors. Please review. We propose removing the concept of "simultaneous sets" and replacing it wit= h a new media capture attribute called "mutually exclusive". The purpose i= s to have a more concise way to indicate which media captures cannot be use= d at the same time, which we believe scales better than the simultaneous se= t idea when there are multiple mutually exclusive constraints. This is in = response to concerns discussed at the interim meeting about scalability of = simultaneous sets, and confusion between simultaneous sets and capture set = entries. New Media Capture attribute: Mutually-exclusive: {list of MCs that cannot be used at same time as this M= C} Consider the example of a room system where there are 3 cameras each of which can send a separate capture covering 2 persons each- VC0, VC1, VC2. The middle camera can also zoom out and show all 6 persons, VC3. But the middle camera cannot be used in both modes at the same time - it has to either show the space where 2 participants sit or the whole 6 seats, but not both at the same time. The provider specifies this with the following video capture attribute valu= es: VC1 - mutually-exclusive=3D{VC3} VC3 - mutually-exclusive=3D{VC1} A provider must advertise mutually exclusive attributes that allow all the = media captures in a capture set entry to be used at the same time. Section 6.3 "Simultaneous Transmission Set Constraints" can be removed. We will update the example in section 11.1 to show the new attribute rather= than the simultaneous sets. Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a propos= al from all the framework authors.  Please review.

 

We propose removi= ng the concept of “simultaneous sets” and replacing it with a n= ew media capture attribute called “mutually exclusive”.  T= he purpose is to have a more concise way to indicate which media captures c= annot be used at the same time, which we believe scales better than the sim= ultaneous set idea when there are multiple mutually exclusive constraints.&= nbsp; This is in response to concerns discussed at the interim meeting abou= t scalability of simultaneous sets, and confusion between simultaneous sets= and capture set entries.

 

New Media Capture attribute:

 

Mutually-exclusi= ve: {list of MCs that cannot be used at same time as this MC}

 

Consider th= e example of a room system where there are 3 cameras each

of which can send a separate capture covering 2 persons e= ach- VC0,

VC1, VC2. The middle camera ca= n also zoom out and show all 6

persons, = VC3. But the middle camera cannot be used in both modes at

the same time - it has to either show the space where 2 = participants

sit or the whole 6 seats, b= ut not both at the same time.

 = ;

The provider specifies this with the follow= ing video capture attribute values:

VC1 = – mutually-exclusive=3D{VC3}

VC3 &= #8211; mutually-exclusive=3D{VC1}

&= nbsp;

A provider must advertise mutually excl= usive attributes that allow all the media captures in a capture set entry t= o be used at the same time.

 <= /o:p>

Section 6.3 “Simultaneous Transmission = Set Constraints” can be removed.

W= e will update the example in section 11.1 to show the new attribute rather = than the simultaneous sets.

 <= /o:p>

Mark

=  

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375CRPMBOXPRD01p_-- From ron.even.tlv@gmail.com Wed Feb 29 15:08: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 D277F21E804C for ; Wed, 29 Feb 2012 15:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.154, 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 LXf7HudIAHmr for ; Wed, 29 Feb 2012 15:08:58 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E55421E8035 for ; Wed, 29 Feb 2012 15:08:57 -0800 (PST) Received: by eeke51 with SMTP id e51so1886151eek.31 for ; Wed, 29 Feb 2012 15:08:56 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.28.133 as permitted sender) client-ip=10.213.28.133; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.28.133 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.213.28.133]) by 10.213.28.133 with SMTP id m5mr1285699ebc.62.1330556936810 (num_hops = 1); Wed, 29 Feb 2012 15:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=zidMgB2ybdFR0APvjvx3HDCXT42lRceG10n6KVeeJBY=; b=sSw5qCZI7ep+dowQ/pTAYGPToXCC5D2CGxWjKC/M43w9wAUu3eMk1AC6zpPoMulzum u0Efo3xmt9oUnrewzMuT9yDbuq7gzzouXkQ+bEMcwZPsiCj9aBUE8TKl5a7tY8O+bELE DZ3EDaJaMAv97EFcnV6AjnTm3VGOfe4+TfdGM= Received: by 10.213.28.133 with SMTP id m5mr1025491ebc.62.1330556936638; Wed, 29 Feb 2012 15:08:56 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id r5sm75850434eef.6.2012.02.29.15.08.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 15:08:55 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com> Date: Thu, 1 Mar 2012 01:08:03 +0200 Message-ID: <4f4eb007.85600e0a.1d16.74b8@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04D1_01CCF747.C2ADCAD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz3MQwPAsai6Sr5R62dhdvpm7sRIgABIgOg Content-Language: en-us Subject: Re: [clue] propose "mutually exclusive" attribute to replace simutaneous sets 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, 29 Feb 2012 23:09:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04D1_01CCF747.C2ADCAD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I do not think that changes anything since this is the complement of the simultaneous set and will be less condensed. For example taking the example from the framework in section 11.1 The physical simultaneity information is: {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Your proposal will require VC1 - mutually-exclusive={VC5} VC5- mutually-exclusive={VC1} VC3 - mutually-exclusive={VC5} VC5- mutually-exclusive={VC3} VC4 - mutually-exclusive={VC5} VC5- mutually-exclusive={VC4} And the result is the same since it can be translated to the current description. My proposal was to clarify in the framework that the capture set entries are the preferred mode as proposed by the provider. Also to say that a consumer can select part of a capture set entry or simultaneous set. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Thursday, March 01, 2012 12:43 AM To: clue@ietf.org Subject: [clue] propose "mutually exclusive" attribute to replace simutaneous sets This is a proposal from all the framework authors. Please review. We propose removing the concept of "simultaneous sets" and replacing it with a new media capture attribute called "mutually exclusive". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. This is in response to concerns discussed at the interim meeting about scalability of simultaneous sets, and confusion between simultaneous sets and capture set entries. New Media Capture attribute: Mutually-exclusive: {list of MCs that cannot be used at same time as this MC} Consider the example of a room system where there are 3 cameras each of which can send a separate capture covering 2 persons each- VC0, VC1, VC2. The middle camera can also zoom out and show all 6 persons, VC3. But the middle camera cannot be used in both modes at the same time - it has to either show the space where 2 participants sit or the whole 6 seats, but not both at the same time. The provider specifies this with the following video capture attribute values: VC1 - mutually-exclusive={VC3} VC3 - mutually-exclusive={VC1} A provider must advertise mutually exclusive attributes that allow all the media captures in a capture set entry to be used at the same time. Section 6.3 "Simultaneous Transmission Set Constraints" can be removed. We will update the example in section 11.1 to show the new attribute rather than the simultaneous sets. Mark ------=_NextPart_000_04D1_01CCF747.C2ADCAD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I do not think = that changes anything since this is the complement of the simultaneous = set and will be less condensed.

For = example taking the example from the framework in section = 11.1

 

  = ; The physical simultaneity information is:

 =

  = ;    {VC0, VC1, VC2, VC3, VC4, = VC6}

 =

  = ;    {VC0, VC2, VC5, VC6}

 =

Your = proposal will require

VC1 = – mutually-exclusive=3D{VC5}

VC5– mutually-exclusive=3D{VC1}

VC3 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC3}

VC4 = – mutually-exclusive=3D{VC5}

VC5– mutually-exclusive=3D{VC4}

And the result is the same since it can be translated = to the current description.

 

My proposal = was to clarify in the framework that  the capture set entries are = the preferred mode as proposed by the provider. Also to say that a = consumer can select part of a capture set entry or simultaneous = set.

 

Roni

 

 

 =

 =

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Thursday, March 01, 2012 12:43 = AM
To: clue@ietf.org
Subject: [clue] propose = "mutually exclusive" attribute to replace simutaneous = sets

 

This is a = proposal from all the framework authors.  Please = review.

 

We propose removing the concept of “simultaneous = sets” and replacing it with a new media capture attribute called = “mutually exclusive”.  The purpose is to have a more = concise way to indicate which media captures cannot be used at the same = time, which we believe scales better than the simultaneous set idea when = there are multiple mutually exclusive constraints.  This is in = response to concerns discussed at the interim meeting about scalability = of simultaneous sets, and confusion between simultaneous sets and = capture set entries.

 

New Media = Capture attribute:

 

Mutually-exclusive: {list of MCs that cannot be used = at same time as this MC}

 

Consider the = example of a room system where there are 3 cameras each

of which can send a separate capture covering 2 = persons each- VC0,

VC1, VC2. The = middle camera can also zoom out and show all 6

persons, VC3. But the middle camera cannot be used in = both modes at

the same time - it has = to either show the space where 2 participants

sit or the whole 6 seats, but not both at the same = time.

 

The provider specifies this with the following video = capture attribute values:

VC1 – = mutually-exclusive=3D{VC3}

VC3 = – mutually-exclusive=3D{VC1}

 

A provider = must advertise mutually exclusive attributes that allow all the media = captures in a capture set entry to be used at the same = time.

 

Section 6.3 “Simultaneous Transmission Set = Constraints” can be removed.

We = will update the example in section 11.1 to show the new attribute rather = than the simultaneous sets.

 

Mark

 

------=_NextPart_000_04D1_01CCF747.C2ADCAD0-- From Mark.Duckworth@polycom.com Wed Feb 29 15:48: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 B1A8921F8781 for ; Wed, 29 Feb 2012 15:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, 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 Qo9Wy-ZY-3EO for ; Wed, 29 Feb 2012 15:48:05 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABBB21F8722 for ; Wed, 29 Feb 2012 15:48:04 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 29 Feb 2012 15:48:04 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Wed, 29 Feb 2012 15:48:02 -0800 Thread-Topic: [clue] propose "mutually exclusive" attribute to replace simutaneous sets Thread-Index: Acz3MQwPAsai6Sr5R62dhdvpm7sRIgABIgOgAAFYB3A= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com> <4f4eb007.85600e0a.1d16.74b8@mx.google.com> In-Reply-To: <4f4eb007.85600e0a.1d16.74b8@mx.google.com> 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_44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] propose "mutually exclusive" attribute to replace simutaneous sets 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, 29 Feb 2012 23:48:07 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, For this example it would be a little simpler like this: VC1 - mutually-exclusive=3D{VC5} VC3 - mutually-exclusive=3D{VC5} VC4 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC1,VC3,VC4} The point for scalability was to simplify a case like this: VC1 - mutually-exclusive=3D{VC2} VC2 - mutually-exclusive=3D{VC1} VC3 - mutually-exclusive=3D{VC4} VC4 - mutually-exclusive=3D{VC3} VC5 - mutually-exclusive=3D{VC6} VC6 - mutually-exclusive=3D{VC5} In simultaneous sets it would have been: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} Adding another mutually exclusive pair would expand the simultaneous sets t= o 16 sets of 4 VCs each. I agree the framework should clarify that capture set entries are the provi= der's suggestion to the consumer about which media captures would be most u= seful to receive together. I agree the framework should clarify that the consumer can choose just part= of a capture set entry. The consumer can also pick and choose media captures from different capture= set entries, and for this case the mutually exclusive information becomes = important. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Wednesday, February 29, 2012 6:08 PM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute to replace simut= aneous sets Hi, I do not think that changes anything since this is the complement of the si= multaneous set and will be less condensed. For example taking the example from the framework in section 11.1 The physical simultaneity information is: {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Your proposal will require VC1 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC1} VC3 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC3} VC4 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC4} And the result is the same since it can be translated to the current descri= ption. My proposal was to clarify in the framework that the capture set entries a= re the preferred mode as proposed by the provider. Also to say that a consu= mer can select part of a capture set entry or simultaneous set. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: Thursday, March 01, 2012 12:43 AM To: clue@ietf.org Subject: [clue] propose "mutually exclusive" attribute to replace simutaneo= us sets This is a proposal from all the framework authors. Please review. We propose removing the concept of "simultaneous sets" and replacing it wit= h a new media capture attribute called "mutually exclusive". The purpose i= s to have a more concise way to indicate which media captures cannot be use= d at the same time, which we believe scales better than the simultaneous se= t idea when there are multiple mutually exclusive constraints. This is in = response to concerns discussed at the interim meeting about scalability of = simultaneous sets, and confusion between simultaneous sets and capture set = entries. New Media Capture attribute: Mutually-exclusive: {list of MCs that cannot be used at same time as this M= C} Consider the example of a room system where there are 3 cameras each of which can send a separate capture covering 2 persons each- VC0, VC1, VC2. The middle camera can also zoom out and show all 6 persons, VC3. But the middle camera cannot be used in both modes at the same time - it has to either show the space where 2 participants sit or the whole 6 seats, but not both at the same time. The provider specifies this with the following video capture attribute valu= es: VC1 - mutually-exclusive=3D{VC3} VC3 - mutually-exclusive=3D{VC1} A provider must advertise mutually exclusive attributes that allow all the = media captures in a capture set entry to be used at the same time. Section 6.3 "Simultaneous Transmission Set Constraints" can be removed. We will update the example in section 11.1 to show the new attribute rather= than the simultaneous sets. Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

For this example it would be a little simpler like this:

VC1 – mutually-exclusive=3D{VC= 5}

VC3 – mutually-exclusive=3D{VC5= }

VC4 – mutually-exclusive=3D{VC5}=

VC5– mutually-exclusive=3D{VC1,VC= 3,VC4}

 

The point for scalability was to simplify a case like this:

VC1 – mutually-exclusive=3D{VC2}

VC2 – mutually-exclusive=3D{VC1}

VC3 – mutually-exclusive=3D{VC4}=

VC4 – mutually-exclusive=3D{VC3}<= /p>

VC5 – mutually-exclusive=3D{VC6}

VC6 – mutually-exclusive=3D{VC5}

 

In simultaneous set= s it would have been:

{VC1, VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2= , VC3, VC5}

{VC2, VC4, VC5}

{VC2, VC3, VC6}

{VC2, VC4, VC6}

 

Adding another mutually= exclusive pair would expand the simultaneous sets to 16 sets of 4 VCs each= .

<= o:p> 

I agree the framework should clarify that capture set entries are the pr= ovider’s suggestion to the consumer about which media captures would = be most useful to receive together.

 

I agree the framework should clarify t= hat the consumer can choose just part of a capture set entry.

 

The consumer= can also pick and choose media captures from different capture set entries= , and for this case the mutually exclusive information becomes important.

 

= Mark

 

 

 

= From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Wednesd= ay, February 29, 2012 6:08 PM
To: Duckworth, Mark; clue@ietf.org<= br>Subject: RE: [clue] propose "mutually exclusive" attrib= ute to replace simutaneous sets

 

Hi,

I do not think that changes anything since this is the c= omplement of the simultaneous set and will be less condensed.

For example taking the example from the framework in = section 11.1

 

   The physical simultaneity information is:

 

&= nbsp;     {VC0, VC1, VC2, VC3, VC4, VC6}

 

 =      {VC0, VC2, VC5, VC6}

 

Your proposal will re= quire

VC1 – mutually-exclus= ive=3D{VC5}

VC5– mutually-exclusiv= e=3D{VC1}

VC3 – mutually-exclusive= =3D{VC5}

VC5– mutually-exclusive= =3D{VC3}

VC4 – mutually-exclusive= =3D{VC5}

VC5– mutually-exclusive= =3D{VC4}

And the result is the same sinc= e it can be translated to the current description.

 

My proposal was to c= larify in the framework that  the capture set entries are the preferre= d mode as proposed by the provider. Also to say that a consumer can select = part of a capture set entry or simultaneous set.

 

Roni

 

 =

 

&nbs= p;

 

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] O= n Behalf Of Duckworth, Mark
Sent: Thursday, March 01, 2012 12= :43 AM
To: clue@ietf.org
Subject: [clue] propose "= mutually exclusive" attribute to replace simutaneous sets

 

This is a proposal from all the framework authors.  Please re= view.

 

We propose removing the concept of “simultaneous sets” = and replacing it with a new media capture attribute called “mutually = exclusive”.  The purpose is to have a more concise way to indica= te which media captures cannot be used at the same time, which we believe s= cales better than the simultaneous set idea when there are multiple mutuall= y exclusive constraints.  This is in response to concerns discussed at= the interim meeting about scalability of simultaneous sets, and confusion = between simultaneous sets and capture set entries.

 

New Media Capture at= tribute:

 

Mutually-exclusive: {list of MCs that cannot be used at same t= ime as this MC}

 

Consider the example of a room system where there are 3 c= ameras each

of which can send a separate= capture covering 2 persons each- VC0,

V= C1, VC2. The middle camera can also zoom out and show all 6

<= p class=3DMsoNormal>persons, VC3. But the middle camera cannot be used in b= oth modes at

the same time - it has to e= ither show the space where 2 participants

sit or the whole 6 seats, but not both at the same time.

 

The provider s= pecifies this with the following video capture attribute values:=

VC1 – mutually-exclusive=3D{VC3}<= /p>

VC3 – mutually-exclusive=3D{VC1}

 

A provider= must advertise mutually exclusive attributes that allow all the media capt= ures in a capture set entry to be used at the same time.

 

Section 6.3 R= 20;Simultaneous Transmission Set Constraints” can be removed.

We will update the example in section 11.1 to s= how the new attribute rather than the simultaneous sets.

 

Mark<= /p>

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5CRPMBOXPRD01p_-- From ron.even.tlv@gmail.com Wed Feb 29 16:12: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 DAD9B21E801A for ; Wed, 29 Feb 2012 16:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 nnhW9GEit7tO for ; Wed, 29 Feb 2012 16:12:42 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11A0B21E8019 for ; Wed, 29 Feb 2012 16:12:41 -0800 (PST) Received: by eaaq11 with SMTP id q11so3157eaa.31 for ; Wed, 29 Feb 2012 16:12:41 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.20.212 as permitted sender) client-ip=10.213.20.212; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.20.212 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.213.20.212]) by 10.213.20.212 with SMTP id g20mr1328616ebb.148.1330560761008 (num_hops = 1); Wed, 29 Feb 2012 16:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=vniYWE0RkLdap4seo4oRTYm8EKwS6OGmbbQjKNHC100=; b=SiKcPnF9s5IaZ+1uyw8hGBXEpvXzyIp8B20wlNRPpCTXYKf1mXkWtMR40rUtqPQkPF zMHc45T9kkvhPhtxy+HaFUkt+L13LVkcBDzyLCYzGhvpxGxgeycT8mIs+PRfaOrMlwC5 TG9KcNLF3AejU2j1sJ8TfT1WcZHBYgoQRnayA= Received: by 10.213.20.212 with SMTP id g20mr1046122ebb.148.1330560760895; Wed, 29 Feb 2012 16:12:40 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id r5sm356495eef.6.2012.02.29.16.12.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 16:12:39 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com> <4f4eb007.85600e0a.1d16.74b8@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5@CRPMBOXPRD01.polycom.com> Date: Thu, 1 Mar 2012 02:11:48 +0200 Message-ID: <4f4ebef7.85600e0a.5242.0772@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04DC_01CCF750.A9B57E70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz3MQwPAsai6Sr5R62dhdvpm7sRIgABIgOgAAFYB3AAALjf0A== Content-Language: en-us Subject: Re: [clue] propose "mutually exclusive" attribute to replace simutaneous sets 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, 01 Mar 2012 00:12:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04DC_01CCF750.A9B57E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mark, The simultaneous case in the example that I listed are in the document and are built on a use case, this example has two lines for simultaneous sets and 4 using the mutually exclusive description . I am not sure what use case you are describing. Anyhow, like I said before these two option are complements to one another and my view is that simultaneous sets make more sense in term of readability and I see no reason to change the current description. You did not address the point I made about clarifying that a consumer can select part of the capture set entry or request one that is not defined as long as it does not contradict the simultaneously regardless of which presentation we select. If this is correct is simpler to construct the allowed sets from the current presentations since you just select a simultaneous set or part of it Roni From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] Sent: Thursday, March 01, 2012 1:48 AM To: Roni Even; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute to replace simutaneous sets Hi, For this example it would be a little simpler like this: VC1 - mutually-exclusive={VC5} VC3 - mutually-exclusive={VC5} VC4 - mutually-exclusive={VC5} VC5- mutually-exclusive={VC1,VC3,VC4} The point for scalability was to simplify a case like this: VC1 - mutually-exclusive={VC2} VC2 - mutually-exclusive={VC1} VC3 - mutually-exclusive={VC4} VC4 - mutually-exclusive={VC3} VC5 - mutually-exclusive={VC6} VC6 - mutually-exclusive={VC5} In simultaneous sets it would have been: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} Adding another mutually exclusive pair would expand the simultaneous sets to 16 sets of 4 VCs each. I agree the framework should clarify that capture set entries are the provider's suggestion to the consumer about which media captures would be most useful to receive together. I agree the framework should clarify that the consumer can choose just part of a capture set entry. The consumer can also pick and choose media captures from different capture set entries, and for this case the mutually exclusive information becomes important. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Wednesday, February 29, 2012 6:08 PM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute to replace simutaneous sets Hi, I do not think that changes anything since this is the complement of the simultaneous set and will be less condensed. For example taking the example from the framework in section 11.1 The physical simultaneity information is: {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Your proposal will require VC1 - mutually-exclusive={VC5} VC5- mutually-exclusive={VC1} VC3 - mutually-exclusive={VC5} VC5- mutually-exclusive={VC3} VC4 - mutually-exclusive={VC5} VC5- mutually-exclusive={VC4} And the result is the same since it can be translated to the current description. My proposal was to clarify in the framework that the capture set entries are the preferred mode as proposed by the provider. Also to say that a consumer can select part of a capture set entry or simultaneous set. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Thursday, March 01, 2012 12:43 AM To: clue@ietf.org Subject: [clue] propose "mutually exclusive" attribute to replace simutaneous sets This is a proposal from all the framework authors. Please review. We propose removing the concept of "simultaneous sets" and replacing it with a new media capture attribute called "mutually exclusive". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. This is in response to concerns discussed at the interim meeting about scalability of simultaneous sets, and confusion between simultaneous sets and capture set entries. New Media Capture attribute: Mutually-exclusive: {list of MCs that cannot be used at same time as this MC} Consider the example of a room system where there are 3 cameras each of which can send a separate capture covering 2 persons each- VC0, VC1, VC2. The middle camera can also zoom out and show all 6 persons, VC3. But the middle camera cannot be used in both modes at the same time - it has to either show the space where 2 participants sit or the whole 6 seats, but not both at the same time. The provider specifies this with the following video capture attribute values: VC1 - mutually-exclusive={VC3} VC3 - mutually-exclusive={VC1} A provider must advertise mutually exclusive attributes that allow all the media captures in a capture set entry to be used at the same time. Section 6.3 "Simultaneous Transmission Set Constraints" can be removed. We will update the example in section 11.1 to show the new attribute rather than the simultaneous sets. Mark ------=_NextPart_000_04DC_01CCF750.A9B57E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mark,

The simultaneous case in = the example that I listed are in the document and are built on a use = case, this example has two lines for simultaneous sets and 4 using the = mutually exclusive description .

I am not sure what use = case you are describing.

Anyhow, like I said before these two option are = complements to one another and my view is that simultaneous sets make = more sense in term of readability and I see no reason to change the = current description.

 

You did not address the = point I made about clarifying that a consumer can select part of the = capture set entry or request one that is not defined as long as it does = not contradict the simultaneously regardless of which presentation we = select.  If this is correct is simpler to construct the allowed = sets from the current presentations since you just select a simultaneous = set or part of it

Roni

 

From:= = Duckworth, Mark [mailto:Mark.Duckworth@polycom.com]
Sent: = Thursday, March 01, 2012 1:48 AM
To: Roni Even; = clue@ietf.org
Subject: RE: [clue] propose "mutually = exclusive" attribute to replace simutaneous = sets

 

Hi,

For this example it = would be a little simpler like this:

VC1 – = mutually-exclusive=3D{VC5}

VC3 = – mutually-exclusive=3D{VC5}

VC4 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC1,VC3,VC4}

 

The point for = scalability was to simplify a case like this:

VC1 – = mutually-exclusive=3D{VC2}

VC2 = – mutually-exclusive=3D{VC1}

VC3 – = mutually-exclusive=3D{VC4}

VC4 = – mutually-exclusive=3D{VC3}

VC5 – = mutually-exclusive=3D{VC6}

VC6 = – mutually-exclusive=3D{VC5}

 

In simultaneous sets it = would have been:

{VC1, VC3, VC5}

{VC1, VC4, = VC5}

{VC1, VC3, VC6}

{VC1, VC4, = VC6}

{VC2, VC3, VC5}

{VC2, VC4, = VC5}

{VC2, VC3, VC6}

{VC2, VC4, = VC6}

 

Adding another mutually = exclusive pair would expand the simultaneous sets to 16 sets of 4 VCs = each.

 

I agree the framework = should clarify that capture set entries are the provider’s = suggestion to the consumer about which media captures would be most = useful to receive together.

 

I agree the framework = should clarify that the consumer can choose just part of a capture set = entry.

 

The consumer can also = pick and choose media captures from different capture set entries, and = for this case the mutually exclusive information becomes = important.

 

Mark

 

 

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]=
Sent: Wednesday, February 29, 2012 6:08 PM
To: = Duckworth, Mark; clue@ietf.org
Subject: RE: = [clue] propose "mutually exclusive" attribute to replace = simutaneous sets

 

Hi,

I do not think = that changes anything since this is the complement of the simultaneous = set and will be less condensed.

For = example taking the example from the framework in section = 11.1

 

  = ; The physical simultaneity information is:

 =

  = ;    {VC0, VC1, VC2, VC3, VC4, = VC6}

 =

  = ;    {VC0, VC2, VC5, VC6}

 =

Your = proposal will require

VC1 = – mutually-exclusive=3D{VC5}

VC5– mutually-exclusive=3D{VC1}

VC3 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC3}

VC4 = – mutually-exclusive=3D{VC5}

VC5– mutually-exclusive=3D{VC4}

And the result is the same since it can be translated = to the current description.

 

My proposal = was to clarify in the framework that  the capture set entries are = the preferred mode as proposed by the provider. Also to say that a = consumer can select part of a capture set entry or simultaneous = set.

 

Roni

 

 

 =

 =

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Thursday, March 01, = 2012 12:43 AM
To: clue@ietf.org
Subject: = [clue] propose "mutually exclusive" attribute to replace = simutaneous sets

 

This is a = proposal from all the framework authors.  Please = review.

 

We propose removing the concept of “simultaneous = sets” and replacing it with a new media capture attribute called = “mutually exclusive”.  The purpose is to have a more = concise way to indicate which media captures cannot be used at the same = time, which we believe scales better than the simultaneous set idea when = there are multiple mutually exclusive constraints.  This is in = response to concerns discussed at the interim meeting about scalability = of simultaneous sets, and confusion between simultaneous sets and = capture set entries.

 

New Media = Capture attribute:

 

Mutually-exclusive: {list of MCs that cannot be used = at same time as this MC}

 

Consider the = example of a room system where there are 3 cameras each

of which can send a separate capture covering 2 = persons each- VC0,

VC1, VC2. The = middle camera can also zoom out and show all 6

persons, VC3. But the middle camera cannot be used in = both modes at

the same time - it has = to either show the space where 2 participants

sit or the whole 6 seats, but not both at the same = time.

 

The provider specifies this with the following video = capture attribute values:

VC1 – = mutually-exclusive=3D{VC3}

VC3 = – mutually-exclusive=3D{VC1}

 

A provider = must advertise mutually exclusive attributes that allow all the media = captures in a capture set entry to be used at the same = time.

 

Section 6.3 “Simultaneous Transmission Set = Constraints” can be removed.

We = will update the example in section 11.1 to show the new attribute rather = than the simultaneous sets.

 

Mark

 

------=_NextPart_000_04DC_01CCF750.A9B57E70-- From ron.even.tlv@gmail.com Wed Feb 29 16:42: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 4CE8D21E8044 for ; Wed, 29 Feb 2012 16:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.146, 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 VfwaSMxMqIyc for ; Wed, 29 Feb 2012 16:42:24 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8445C21E8034 for ; Wed, 29 Feb 2012 16:42:23 -0800 (PST) Received: by eeke51 with SMTP id e51so10216eek.31 for ; Wed, 29 Feb 2012 16:42:22 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.29.1 as permitted sender) client-ip=10.14.29.1; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.29.1 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.29.1]) by 10.14.29.1 with SMTP id h1mr1594860eea.25.1330562542835 (num_hops = 1); Wed, 29 Feb 2012 16:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=gamzAJJDC8pYzxao1jcYLab+y3iJsXnJ1YA1IHoVFJ8=; b=Fie19tGNrgFyfc9WmxwgdDzFD6rBqRmfwjT9N23V9Qr4QNZxaiF0/lM8Onjeu1VxTK morshcQpVFe0i0wtGr3VdySEGfPVuKu/K05Iydw+u1WWfv2qqN+vW2PZ6AMpc7LAvITm 5J/SVqgiymOiTCLWhrv7eeTB4sCAT6GBRK9W8= Received: by 10.14.29.1 with SMTP id h1mr1235913eea.25.1330562542748; Wed, 29 Feb 2012 16:42:22 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id u9sm557105eem.11.2012.02.29.16.42.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 16:42:21 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com> Date: Thu, 1 Mar 2012 02:41:29 +0200 Message-ID: <4f4ec5ed.89b90e0a.25f9.0b74@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04E4_01CCF754.CFAD5AE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz3MQwPAsai6Sr5R62dhdvpm7sRIgAEujsw Content-Language: en-us Subject: Re: [clue] propose "mutually exclusive" attribute to replace simutaneous sets 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, 01 Mar 2012 00:42:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04E4_01CCF754.CFAD5AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mark, Just to be precise you are the editors not the authors, this is a WG draft. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Thursday, March 01, 2012 12:43 AM To: clue@ietf.org Subject: [clue] propose "mutually exclusive" attribute to replace simutaneous sets This is a proposal from all the framework authors. Please review. We propose removing the concept of "simultaneous sets" and replacing it with a new media capture attribute called "mutually exclusive". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. This is in response to concerns discussed at the interim meeting about scalability of simultaneous sets, and confusion between simultaneous sets and capture set entries. New Media Capture attribute: Mutually-exclusive: {list of MCs that cannot be used at same time as this MC} Consider the example of a room system where there are 3 cameras each of which can send a separate capture covering 2 persons each- VC0, VC1, VC2. The middle camera can also zoom out and show all 6 persons, VC3. But the middle camera cannot be used in both modes at the same time - it has to either show the space where 2 participants sit or the whole 6 seats, but not both at the same time. The provider specifies this with the following video capture attribute values: VC1 - mutually-exclusive={VC3} VC3 - mutually-exclusive={VC1} A provider must advertise mutually exclusive attributes that allow all the media captures in a capture set entry to be used at the same time. Section 6.3 "Simultaneous Transmission Set Constraints" can be removed. We will update the example in section 11.1 to show the new attribute rather than the simultaneous sets. Mark ------=_NextPart_000_04E4_01CCF754.CFAD5AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mark,

Just to be precise you = are the editors not the authors, this is a WG = draft.

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Thursday, March 01, 2012 12:43 = AM
To: clue@ietf.org
Subject: [clue] propose = "mutually exclusive" attribute to replace simutaneous = sets

 

This is a = proposal from all the framework authors.  Please = review.

 

We propose removing the concept of “simultaneous = sets” and replacing it with a new media capture attribute called = “mutually exclusive”.  The purpose is to have a more = concise way to indicate which media captures cannot be used at the same = time, which we believe scales better than the simultaneous set idea when = there are multiple mutually exclusive constraints.  This is in = response to concerns discussed at the interim meeting about scalability = of simultaneous sets, and confusion between simultaneous sets and = capture set entries.

 

New Media = Capture attribute:

 

Mutually-exclusive: {list of MCs that cannot be used = at same time as this MC}

 

Consider the = example of a room system where there are 3 cameras each

of which can send a separate capture covering 2 = persons each- VC0,

VC1, VC2. The = middle camera can also zoom out and show all 6

persons, VC3. But the middle camera cannot be used in = both modes at

the same time - it has = to either show the space where 2 participants

sit or the whole 6 seats, but not both at the same = time.

 

The provider specifies this with the following video = capture attribute values:

VC1 – = mutually-exclusive=3D{VC3}

VC3 = – mutually-exclusive=3D{VC1}

 

A provider = must advertise mutually exclusive attributes that allow all the media = captures in a capture set entry to be used at the same = time.

 

Section 6.3 “Simultaneous Transmission Set = Constraints” can be removed.

We = will update the example in section 11.1 to show the new attribute rather = than the simultaneous sets.

 

Mark

 

------=_NextPart_000_04E4_01CCF754.CFAD5AE0-- From Christian.Groves@nteczone.com Wed Feb 29 18:48: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 2B66421E8014 for ; Wed, 29 Feb 2012 18:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoqU696ScJeK for ; Wed, 29 Feb 2012 18:47:59 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 2009E21E807A for ; Wed, 29 Feb 2012 18:47:58 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAFziTk920fmS/2dsb2JhbAAMOLZ3AQEBBAEBATUbGwoNBAsRBAEBAQkWCAcJAwIBAgEVHwkIEwYCAQGIELlcBI0CEAsBEAICBwYEAwQDCAQKIQuFAg8yARgGGoMsBKhE Received: from ppp118-209-249-146.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.249.146]) by ipmail07.adl2.internode.on.net with ESMTP; 01 Mar 2012 13:17:55 +1030 Message-ID: <4F4EE356.9030501@nteczone.com> Date: Thu, 01 Mar 2012 13:47:50 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185@CRPMBOXPRD01.polycom.com> <4F4E4A81.6070006@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E021D@CRPMBOXPRD01.polycom.com> <4f4e57ef.8a1d0e0a.3db9.364c@mx.google.com> In-Reply-To: <4f4e57ef.8a1d0e0a.3db9.364c@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Language re capture axis 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, 01 Mar 2012 02:48:00 -0000 Hello Roni, I'm not sure I follow. Why would the provider add a flag to say whether the axis of capture can be calculated? Wouldn't the consumer know this from the information delivered to it? Regards, Christian On 1/03/2012 3:52 AM, Roni Even wrote: > Hi, > My view is that we should either point out that the axis of capture is not > specified or add a value for it. My preference is that since in most cases > the area of capture and point of capture will provide the axis of capture we > can add a flag that will say whether the axis of capture can be calculated > based on the information or not. > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Duckworth, Mark >> Sent: Wednesday, February 29, 2012 6:14 PM >> To: Paul Kyzivat; clue@ietf.org >> Subject: Re: [clue] Language re capture axis >> >> Paul and Stephan, >> >> Personally, I'd rather just leave it out altogether because I think it >> doesn't add anything that needs to be standardized. But Stephan >> thought it was important, so I was trying to find a way to say it in an >> "accurate enough" way. >> >> Mark >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Wednesday, February 29, 2012 10:56 AM >>> To: clue@ietf.org >>> Subject: Re: [clue] Language re capture axis >>> >>> On 2/29/12 10:10 AM, Duckworth, Mark wrote: >>>> Hi Stephan, >>>> >>>> I agree in principle with your suggestion, but I think your >>>> suggested text is not mathematically accurate. I think the axis of >>>> capture doesn't go to the center of the area of capture. For >>>> example, if the camera is pointed at the area of capture at an >>>> angle, the center point of the area would not line up with the >>>> center point of the camera's field of view (which defines the >> axis). >>>> So rather than try to get into the mathematical details, how about >> this: >>>> "Note that, for the purpose of receiver-side geometric correction, >>>> it can be assumed that the axis of capture of directional capture >>>> devices (cameras, directional microphones etc.) can be calculated >>>> from the coordinates of the point of capture and area of capture." >>> IMO this is dangerously vague. Presumably there is a real axis of >> capture. >>> Hopefully there is a well defined algorithm for deriving the axis >> from >>> the available data, so that the recipient will determine the actual >>> axis. If so, then it should be specified or referenced from some >>> source. Otherwise we run the risk that not all will correctly derive >> the axis. >>> Thanks, >>> Paul >>> >>>> Mark >>>> >>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >>>> Behalf Of *Stephan Wenger >>>> *Sent:* Wednesday, February 15, 2012 11:04 AM >>>> *To:* clue@ietf.org >>>> *Subject:* [clue] Language re capture axis >>>> >>>> Hi, >>>> >>>> The issue I mentioned in the meeting is that nowhere in the >>>> framework (as far as I recall) the axis of capture of a video >>>> capture (or directional audio capture-anything that is not >>>> omnidirectional) is undefined. Without that axis being defined, >>>> receiver-side geometric correction is not possible. >>>> >>>> The issue could be solved in two ways: include attributes, per >>>> capture, indicating angle of capture in 3D space (relative to >>>> what???), or by making the bold assumption that the coordinates >>>> defining area of capture plus capture point define the axis of >>>> capture. I suggest the latter as it is easy to implement and (I >>>> believe) >>> practical. >>>> The language could be something like: >>>> >>>> " >>>> >>>> Note that, for the purpose of receiver-side geometric correction, >> it >>>> can be assumed that the axis of capture of directional capture >>>> devices (cameras, directional microphones etc.) is the line from >> the >>>> capture point to the center of the plane of capture. >>>> >>>> " >>>> >>>> Stephan >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Christian.Groves@nteczone.com Wed Feb 29 19:04: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 7110B21E8081 for ; Wed, 29 Feb 2012 19:04:18 -0800 (PST) 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 uvrfPcHbUfHT for ; Wed, 29 Feb 2012 19:04:18 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 9C53021E807E for ; Wed, 29 Feb 2012 19:04:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBANzlTk920fmS/2dsb2JhbAAMOLZ3AQEBBAEBAS8BBRsbChELGAkWDwkDAgECARUwEwYCAQGIELlYBIx6GAsCDwkCCgEGCwIGByAJAoUCDzIBGAYaDoMeBKhE Received: from ppp118-209-249-146.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.249.146]) by ipmail07.adl2.internode.on.net with ESMTP; 01 Mar 2012 13:34:16 +1030 Message-ID: <4F4EE72B.1050903@nteczone.com> Date: Thu, 01 Mar 2012 14:04:11 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] propose "mutually exclusive" attribute to replace simutaneous sets 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, 01 Mar 2012 03:04:18 -0000 Hello Mark, From a readability point of view I do find simultaneous sets easier to understand. I think that from an interop point of view it may be better the capturer to say "here's the combinations I support" rather than "I support everything except these combinations". The capturer and provider may not have the same view of "everything". From the mutually exclusive examples there does seem to be some duplication. The mutually exclusive pairs seem to be listed twice i.e. VC1,{VC3} and VC3,{VC1}. Could it not be deduced from a single pair that they can't be used at the same time? Regards, Christian On 1/03/2012 9:43 AM, Duckworth, Mark wrote: > > This is a proposal from all the framework authors. Please review. > > We propose removing the concept of “simultaneous sets” and replacing > it with a new media capture attribute called “mutually exclusive”. The > purpose is to have a more concise way to indicate which media captures > cannot be used at the same time, which we believe scales better than > the simultaneous set idea when there are multiple mutually exclusive > constraints. This is in response to concerns discussed at the interim > meeting about scalability of simultaneous sets, and confusion between > simultaneous sets and capture set entries. > > New Media Capture attribute: > > Mutually-exclusive: {list of MCs that cannot be used at same time as > this MC} > > Consider the example of a room system where there are 3 cameras each > > of which can send a separate capture covering 2 persons each- VC0, > > VC1, VC2. The middle camera can also zoom out and show all 6 > > persons, VC3. But the middle camera cannot be used in both modes at > > the same time - it has to either show the space where 2 participants > > sit or the whole 6 seats, but not both at the same time. > > The provider specifies this with the following video capture attribute > values: > > VC1 – mutually-exclusive={VC3} > > VC3 – mutually-exclusive={VC1} > > A provider must advertise mutually exclusive attributes that allow all > the media captures in a capture set entry to be used at the same time. > > Section 6.3 “Simultaneous Transmission Set Constraints” can be removed. > > We will update the example in section 11.1 to show the new attribute > rather than the simultaneous sets. > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue