From Mark.Duckworth@polycom.com Sat Dec 1 07:19:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBEB1F0C5C for ; Sat, 1 Dec 2012 07:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WBcJy2eWYYs for ; Sat, 1 Dec 2012 07:19:03 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 794D71F0C4A for ; Sat, 1 Dec 2012 07:19:02 -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; Sat, 1 Dec 2012 07:19:02 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Sat, 1 Dec 2012 07:18:58 -0800 Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3JLnoSrFDEIZK1TO6IMgd/D6FDaQGoy/AQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> References: <50AEF3CB.7020904@nteczone.com> In-Reply-To: <50AEF3CB.7020904@nteczone.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] Capture scene clarifications X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 15:19:04 -0000 Points a) and b) are consistent with the intent of the current framework. = Point d) starts to change the intent. The framework allows for a media con= sumer to receive multiple capture scene entries (regardless of media type) = at the same time. I think point d) is proposing we not allow this. I thin= k saying "A consumer shall choose a capture scene entry rather than choosin= g individual captures from multiple entries" is equivalent to saying "A con= sumer shall choose at most one capture scene entry (of a particular media t= ype) from any particular capture scene". Such a restriction probably reduces the scenarios in which the provider nee= ds to express simultaneous transmission sets, because some of the simultane= ity constraints are now included in the capture scene entries. As others h= ave pointed out, there is still the possibility of simultaneous constraints= that apply across multiple capture scenes. Adding this restriction, to not allow multiple capture scene entries (of sa= me media type, in the same scene) to be used simultaneously is okay with me= , but I don't think it really simplifies much. As others have said, allowing a consumer to choose a subset of captures fro= m a capture scene entry makes sense to me too. I have a few more comments about the proposals inline below. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Thursday, November 22, 2012 10:56 PM > To: clue@ietf.org > Subject: [clue] Capture scene clarifications >=20 >=20 > Hello, >=20 > Paul K reminded me that I have an action point from the interim meeting > regarding my draft . At the meeti= ng it > seems that there was general agreement with the intent of the > proposals: > a) A scene represents an area where the capture devices are > spatially related, i.e. a presentation that shares no spatial > relation with a video is a separate scene. >=20 > b) A capture scene entry thus represents alternate > representations of a complete scene. The provider is the one > that determines what a complete scene is. A consumer choses > a capture scene entry from the scene in the knowledge that it > represents the entire scene. >=20 > d) A consumer shall chose a capture scene entry rather than > choosing individual captures from multiple entries. This > does not mean that an consuming endpoint must render all the > captures. What is locally rendered and how is a local > decision. >=20 > I think the framework draft could be enhanced in a few places to make the > intent of CLUE clearer. Below are some suggested updates. >=20 > 1) Introduce a new definition for "Scene". The capture scene definition a= nd > several places mention "scene" but there's no explanation. I propose the > following definition to be added to section 3 of the draft: > Scene: Represents an area where the capture devices are spatially related= . > Non-spatially related devices exist in different scenes. [Duckworth, Mark] Sounds good. > 2) Update the definition of "Capture scene entry" to make it clearer that= it > represents an entire scene. Proposed text is: > *Capture Scene Entry: a list of media captures of the same media type > that together form one representation of an entire capture scene. [Duckworth, Mark] Sounds good. > 3) Update section 6.2 on Capture scenes to reflect the above intents. > Changes proposals are: > - Section 6.2 2nd paragraph: > "A capture scene is a structure representing the <> scene that is > captured by a collection of<>capture devices. A c= apture > scene..." [Duckworth, Mark] Sounds good.=20 > - Section 6.2 3rd paragraph: > "A provider may advertise multiple capture scenes or just a single > capture scene.<> > A media provider might typically use one capture > scene for main participant media and another capture scene for a > computer generated presentation...." [Duckworth, Mark] sounds good > - Section 6.2 4th paragraph: > "A media provider arranges media captures in a capture scene to help > the media consumer choose which captures it wants. The capture scene > entries in a capture scene are different alternatives the provider is > suggesting for representing the entire capture scene. paragraph>". >=20 > - Section 6.2 5th paragraph: > "Media captures within the same capture scene entry must be of the > same media type - it is not possible to mix audio and video captures > in the same capture scene entry, for instance. The provider must be > capable of encoding and sending all media captures in a single entry > simultaneously." >=20 > - section 6.2 New paragraph dealing with consumer behaviour after the 7th > paragraph. > "A consumer may receive an advertisement with multiple capture scenes. > A consumer may choose to receive any number of capture scenes. An > advertised capture scene it may contain one of more capture scene entries > that may contain one of more media captures. A consumer may choose an > capture scene entry in the knowledge that it is a complete representation= of > the scene for a particular media type and that all media captures are spa= tially > related. For a particular media type the consumer shall choose one captur= e > scene entry rather than choosing individual captures from multiple captur= e > scene entries. However this does not mean that a consuming endpoint must > render all the media captures. What is locally rendered and how is a loca= l > decision." [Duckworth, Mark] These three proposed changes above are related to not all= owing multiple capture scene entries, of the same media type, in the same s= cene, from being used simultaneously. I could go either way on this change= , whatever the group decides. > 4) The framework uses the terms "media provider" and "provider". We > probably should be consistent in the use of the term throughout the > framework. [Duckworth, Mark] sounds good. > 5) Related to the "capture group" concept that didn't seem to get support= is > the ordering in the Capture scene, Capture scene entry, Media captures. > There was some discussion that people had assumed some sort of > prioritisation / ordering related to these structures. i.e. If I have a c= apture > scene entry VC0, VC1, VC2 do I assume they should be rendered left to rig= ht > or is there nothing to be assumed? I take it is the later understanding p= ut I > didn't see anything in the framework regarding what should be assumed. We > probably should also add something for that. [Duckworth, Mark] From the framework: "Determination of the order of these = captures (VC0, VC1 and VC2) for rendering purposes is accomplished through = use of their Area of Capture attributes." I don't know what other type or = order or prioritization you might be talking about here. > Thoughts? >=20 > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Sat Dec 1 07:33: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 0CE7E1F0C5C for ; Sat, 1 Dec 2012 07:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crGLvgqc6lZp for ; Sat, 1 Dec 2012 07:33:16 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2E83B1F0C4A for ; Sat, 1 Dec 2012 07:33:16 -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; Sat, 1 Dec 2012 07:33:15 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Sat, 1 Dec 2012 07:33:13 -0800 Thread-Topic: [clue] CLUE Design team meetings through end of 2012, plans for 2013 Thread-Index: Ac3EQ5rKAyu0q7VXRI6HNQQN66UCzALlLqxg Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610391863B3C@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_44C6B6B2D0CF424AA90B6055548D7A610391863B3CCRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] CLUE Design team meetings through end of 2012, plans for 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 15:33:17 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A610391863B3CCRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see the logistics information for the design team meetings here: http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team I want to make sure I have the correct time. It says 10:00 CDT (GMT-5). S= o is the meeting at 9:00 CST, or is the meeting really at 10:00 CST (GMT-6)= ? Thanks. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: Friday, November 16, 2012 4:45 PM To: CLUE Subject: [clue] CLUE Design team meetings through end of 2012, plans for 20= 13 Hi all, We would like to propose the following schedule for the calls through the e= nd of 2012. As noted at the meeting, the plan is to focus on the WG delive= rables (those will be summarized in a separate email). We plan to skip the = call next week as it's a US holiday at the end of the week and I'll be out = the whole week. I have jury duty on the 10th, so we'll skip that unless so= meone has something compelling they think needs discussion. November 26th: Update on RTP convergence (Roni, Jonathan) December 3rd: Framework refactoring (Stephan, Andy, Mark) December 17th: Signaling update (Rob, Roni, Simon, Roberta, Christer) Note: the first name is the prime for pulling together any materials - i.e.= , drafty drafts, email proposals, etc ;) If you do not believe you are re= ady, let the chairs know ASAP, so we can find another topic to discuss and = let us know when you anticipate to have something to discuss with the group= . For 2013, we should start back with the calls on January 14th. We would also like to plan a virtual interim sometime mid-late Jan - early-= mid Feb. The proposal is for a 2 hr/day 2 day meeting. The chairs do not = believe we need a f2f interim before the next IETF meeting. If you think w= e do and are willing to host, let us know ASAP as time is extremely limited= for planning a meeting given the winter/Christmas holiday and the fact tha= t the time between IETF-85 and IETF-86 is quite short (registration and sch= eduling for IETF-86 opens on Dec. 10th). Also, RTCWEB is also planning an = interim - we have no intention of trying to coordinate with them since it w= as not effective the last time, we just can't overlap. Regards, Mary and Paul CLUE WG co-chairs --_000_44C6B6B2D0CF424AA90B6055548D7A610391863B3CCRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see the= logistics information for the design team meetings here:=

http://trac.tools.ietf.org/wg/clue/trac/wiki/Desi= gn-Team

 

I want to make sure I have the co= rrect time.  It says 10:00 CDT (GMT-5).  So is the meeting at 9:0= 0 CST, or is the meeting really at 10:00 CST (GMT-6)?

=

 

Thanks.

Mark=

 

From: clue-bounces@ietf.org [mailto:c= lue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Frida= y, November 16, 2012 4:45 PM
To: CLUE
Subject: [clue] C= LUE Design team meetings through end of 2012, plans for 2013

 

Hi all,

 

We would like to propose the following sch= edule for the calls through the end of 2012.  As noted at the meeting,= the plan is to focus on the WG deliverables (those will be summarized in a= separate email). We plan to skip the call next week as it's a US holiday a= t the end of the week and I'll be out the whole week.  I have jury dut= y on the 10th, so we'll skip that unless someone has something compelling t= hey think needs discussion.

<= o:p> 

November 26th:  Up= date on RTP convergence (Roni, Jonathan)

December 3rd:  Framework refactoring  (Stephan, Andy= , Mark)

December 17th:  = Signaling update (Rob, Roni, Simon, Roberta, Christer)

=

 

Note: the first name is the prime for pulling together any materials - = i.e., drafty drafts, email proposals, etc ;)   If you do not believe y= ou are ready, let the chairs know ASAP, so we can find another topic to dis= cuss and let us know when you anticipate to have something to discuss with = the group. 

 <= /o:p>

For 2013, we should start back wit= h the calls on January 14th.  

 

We would also l= ike to plan a virtual interim sometime mid-late Jan - early-mid Feb.  = The proposal is for a 2 hr/day 2 day meeting.  The chairs do not belie= ve we need a f2f interim before the next IETF meeting.  If you think w= e do and are willing to host, let us know ASAP as time is extremely limited= for planning a meeting given the winter/Christmas holiday and the fact tha= t the time between IETF-85 and IETF-86 is quite short (registration and sch= eduling for IETF-86 opens on Dec. 10th).  Also, RTCWEB is also plannin= g an interim - we have no intention of trying to coordinate with them since= it was not effective the last time, we just can't overlap. 

 

Regards,

Mary = and Paul

CLUE WG co-chairs

= --_000_44C6B6B2D0CF424AA90B6055548D7A610391863B3CCRPMBOXPRD01p_-- From stewe@stewe.org Sat Dec 1 08:56: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 A021921F8C80 for ; Sat, 1 Dec 2012 08:56:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MqsFH-GcVv3 for ; Sat, 1 Dec 2012 08:56:25 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 783BF21F8C0F for ; Sat, 1 Dec 2012 08:56:25 -0800 (PST) Received: from mail70-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Sat, 1 Dec 2012 16:56:24 +0000 Received: from mail70-va3 (localhost [127.0.0.1]) by mail70-va3-R.bigfish.com (Postfix) with ESMTP id 862EC4A01D6 for ; Sat, 1 Dec 2012 16:56:24 +0000 (UTC) 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 X-SpamScore: -18 X-BigFish: PS-18(zzc85eh14ffIzz1de0h1202h1d1ah1d2ah1082kzz1033IL8275bh8275dh18c673hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1155h) Received-SPF: pass (mail70-va3: 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 mail70-va3 (localhost.localdomain [127.0.0.1]) by mail70-va3 (MessageSwitch) id 135438098113789_7123; Sat, 1 Dec 2012 16:56:21 +0000 (UTC) Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.249]) by mail70-va3.bigfish.com (Postfix) with ESMTP id F15BF34006D for ; Sat, 1 Dec 2012 16:56:20 +0000 (UTC) Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 1 Dec 2012 16:56:20 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.9]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0239.002; Sat, 1 Dec 2012 16:56:20 +0000 From: Stephan Wenger To: "clue@ietf.org" Thread-Topic: Subject matter for Monday's call Thread-Index: AQHNz+TJKeMbGzPb7kq5dxCz2/S00g== Date: Sat, 1 Dec 2012 16:56:19 +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.4] Content-Type: multipart/alternative; boundary="_000_FDBFA77C7400C74F87BC297393B53E352BAF2B62BL2PRD0710MB349_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: [clue] Subject matter for Monday's call X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 16:56:26 -0000 --_000_FDBFA77C7400C74F87BC297393B53E352BAF2B62BL2PRD0710MB349_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, Mark, Andy, and myself had a bit of brainstorming how to most productively = use our time during the Monday morning call. Due to travel and vacation sc= hedule, our coordination was finalized call only late Friday. Which may se= rve as an explanation, if not as an excuse, for the late timing of this ema= il. In our opinion, the most pressing issue we have with the framework document= is it being agnostic to the protocol elements used to convey the various m= essages that are part of the framework. Clearly, the framework was written= from a perspective where a CLUE protocol channel would be established, and= (all?) further signaling would be dealt with over that channel. So is, mo= re or less, the call flow doc. We believe that there was sufficient pushba= ck against that idea to make rapid progress based on this assumption unlike= ly. Accordingly, we believe that we probably best spend most of our time b= y discussing a strawman for a split-up between SDP-represented, SIP-ish, Of= fer-Answer, =85, that type of traditional messages, and (XML-coded) message= s sent over the CLUE. The focus of our Monday call would be on the initial= exchange, rather than any updates that may happen during a call. With reference to the call flow 02 doc (https://datatracker.ietf.org/doc/dr= aft-romanow-clue-call-flow/?include_text=3D1) that exchange could look as f= ollows: 1. Invite from Alice, just like A.1 in call-flow-02 2. 200 OK from Bob, A.2 3. CLUE Advertisement Alice A.3, covering geometry stuff, encoding group= s, etc. 4. CLUE Advertisement Bob A.4; note that 3 and 4 would in practice overl= ap in time 5. CLUE Response from Alice A.5, with the difference that these reposes = DO NOT have the side effect of initiating any media channel related activit= y; they are pure signaling 6. CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in t= ime. 7. Re-invite from Alice and Bob, respectively, with media channels as CL= UE-"negotiated" 8. 200 OK from Bob, Alice. As the endpoints have already established th= eir operation points through CLUE, this step will not fail except if an ent= ity not involved in the CLUE negotiation intervenes=97i.e. a middle box doe= sn't like that call. The reason for the existence of step 7, rather than setting up media channe= ls as side effect of steps 3 through 6 (as assumed in call flow and in the = current framework doc) is twofold: easier integration into the source base = of media codecs that currently use SDP for the selection of their parameter= s, and making middlebox people happy. The reason for the existence of steps 3 through 6 is our agreement that not= all useful protocol elements envisioned in the framework can be reasonably= and meaningfully implemented in SDP extensions. This is certainly true fo= r the geometry stuff. The reason for keeping an encoding group concept in CLUE is that a represen= tation of the information that can be conveyed through individual encoding = descriptions, encoding groups, and the association of media captures with e= ncoding groups (section 7 and 8 of the framework) purely through grouped m-= lines would lead to bloated (if not exploded :-) SDP, quite possibly well b= eyond a reasonable size (i.e. MTU size); the high level of abstraction offe= red by concepts such as encoding groups, simultaneous transmission sets, an= d so on, makes for a very compact representation compared to listing all po= ssible permutations of alternative choices in grouped m-lines. Does such a mechanism make at least initial sense? Should it be fleshed ou= t and put into the framework? Stephan --_000_FDBFA77C7400C74F87BC297393B53E352BAF2B62BL2PRD0710MB349_ Content-Type: text/html; charset="Windows-1252" Content-ID: <674165290E898B4A819D99E81C9C1D89@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi all,

Mark, Andy, and myself had a bit of brainstorming how to most producti= vely use our time during the Monday morning call.  Due to travel and v= acation schedule, our coordination was finalized call only late Friday. &nb= sp;Which may serve as an explanation, if not as an excuse, for the late timing of this email.

In our opinion, the most pressing issue we have with the framework doc= ument is it being agnostic to the protocol elements used to convey the vari= ous messages that are part of the framework.  Clearly, the framework w= as written from a perspective where a CLUE protocol channel would be established, and (all?) further signaling w= ould be dealt with over that channel.  So is, more or less, the call f= low doc.  We believe that there was sufficient pushback against that i= dea to make rapid progress based on this assumption unlikely.  Accordingly, we believe that we probably best spend most o= f our time by discussing a strawman for a split-up between SDP-represented,= SIP-ish, Offer-Answer, =85, that type of traditional messages, and (XML-co= ded) messages sent over the CLUE.  The focus of our Monday call would be on the initial exchange, rather than any= updates that may happen during a call.

With reference to the call flow 02 doc (https://datat= racker.ietf.org/doc/draft-romanow-clue-call-flow/?include_text=3D1) tha= t exchange could look as follows:
  1. Invite from Alice, just like A.1 in call-flow-02
  2. 200 OK from Bo= b, A.2
  3. CLUE Advertisement Alice A.3, covering geometry stuff, encod= ing groups, etc.
  4. CLUE Advertisement Bob A.4; note that 3 and 4 woul= d in practice overlap in time
  5. CLUE Response from Alice A.5, with th= e difference that these reposes DO NOT have the side effect of initiating a= ny media channel related activity; they are pure signaling
  6. CLUE Res= ponse from Bob, A.6, same remark.. 5 and 6 could overlap in time.
  7. R= e-invite from Alice and Bob, respectively, with media channels as CLUE-&quo= t;negotiated"
  8. 200 OK from Bob, Alice.  As the endpoints h= ave already established their operation points through CLUE, this step will= not fail except if an entity not involved in the CLUE negotiation interven= es=97i.e. a middle box doesn't like that call.
The reason for the existence of step 7, rather than setting up media c= hannels as side effect of steps 3 through 6 (as assumed in call flow and in= the current framework doc) is twofold: easier integration into the source = base of media codecs that currently use SDP for the selection of their parameters, and making middlebox people= happy. 

The reason for the existence of steps 3 through 6 is our agreement tha= t not all useful protocol elements envisioned in the framework can be reaso= nably and meaningfully implemented in SDP extensions.  This is certain= ly true for the geometry stuff.

The reason for keeping an encoding group concept in CLUE is that a rep= resentation of the information that can be conveyed through individual enco= ding descriptions, encoding groups, and the association of media captures w= ith encoding groups (section 7 and 8 of the framework) purely through grouped m-lines would lead to bloated (= if not exploded :-) SDP, quite possibly well beyond a reasonable size (i.e.= MTU size); the high level of abstraction offered by concepts such as encod= ing groups, simultaneous transmission sets, and so on, makes for a very compact representation compared to listi= ng all possible permutations of alternative choices in grouped m-lines.&nbs= p;

Does such a mechanism make at least initial sense?  Should it be = fleshed out and put into the framework?

Stephan
--_000_FDBFA77C7400C74F87BC297393B53E352BAF2B62BL2PRD0710MB349_-- From spromano@unina.it Sat Dec 1 09:58: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 2D05011E80A3 for ; Sat, 1 Dec 2012 09:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-n6eXA1qYPZ for ; Sat, 1 Dec 2012 09:58:56 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id C845F11E8099 for ; Sat, 1 Dec 2012 09:58:55 -0800 (PST) Received: from [192.168.1.102] ([151.77.226.39]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id qB1HwpR0029388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Dec 2012 18:58:52 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_64FA6479-32CC-4533-BA55-5165B965242C" From: Simon Pietro Romano In-Reply-To: Date: Sat, 1 Dec 2012 18:59:07 +0100 Message-Id: References: To: Stephan Wenger X-Mailer: Apple Mail (2.1283) Cc: "clue@ietf.org" Subject: Re: [clue] Subject matter for Monday's call X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 17:58:57 -0000 --Apple-Mail=_64FA6479-32CC-4533-BA55-5165B965242C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Stephan, this flow sounds reasonable to me. Just to make sure that I am not = misunderstanding something, let me ask you whether steps 3 through 6 are = in your mind carried out over an ad hoc created CLUE channel between = Alice and Bob. I keep on thinking that a CLUE channel needs to be established, at least = for exchanging spatial information that cannot be straightforwardly = inserted into SDP. As I said at the meeting in Atlanta, I would envisage the following = high-level sequence of interactions: a. SIP-based COMEDIA negotiation between Alice and Bob, aimed at = establishing the CLUE channel (which would be done through steps 1. and = 2. of the flow you sketched); b. CLUE channel used to exchange XML documents containing CLUE-realted = information for which no direct mapping onto SDP has been identified = (steps 3 through 6 in your flow); c. SIP/SDP used to establish the needed media channel(s), as well as to = transport CLUE-related information for which a mapping onto SDP has been = identified (steps 7. and 8. in your flow). Obviously, phases b. and c. above are in some way coupled, since they = are both needed in order to provide CLUE entities with the whole picture = associated with a telepresence scenario. Is this interpretation correct? Cheers, Simon Il giorno 01/dic/2012, alle ore 17:56, Stephan Wenger ha scritto: > Hi all, >=20 > Mark, Andy, and myself had a bit of brainstorming how to most = productively use our time during the Monday morning call. Due to travel = and vacation schedule, our coordination was finalized call only late = Friday. Which may serve as an explanation, if not as an excuse, for the = late timing of this email. >=20 > In our opinion, the most pressing issue we have with the framework = document is it being agnostic to the protocol elements used to convey = the various messages that are part of the framework. Clearly, the = framework was written from a perspective where a CLUE protocol channel = would be established, and (all?) further signaling would be dealt with = over that channel. So is, more or less, the call flow doc. We believe = that there was sufficient pushback against that idea to make rapid = progress based on this assumption unlikely. Accordingly, we believe = that we probably best spend most of our time by discussing a strawman = for a split-up between SDP-represented, SIP-ish, Offer-Answer, =85, that = type of traditional messages, and (XML-coded) messages sent over the = CLUE. The focus of our Monday call would be on the initial exchange, = rather than any updates that may happen during a call. >=20 > With reference to the call flow 02 doc = (https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include_te= xt=3D1) that exchange could look as follows: > Invite from Alice, just like A.1 in call-flow-02 > 200 OK from Bob, A.2 > CLUE Advertisement Alice A.3, covering geometry stuff, encoding = groups, etc. > CLUE Advertisement Bob A.4; note that 3 and 4 would in practice = overlap in time > CLUE Response from Alice A.5, with the difference that these reposes = DO NOT have the side effect of initiating any media channel related = activity; they are pure signaling > CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in = time. > Re-invite from Alice and Bob, respectively, with media channels as = CLUE-"negotiated" > 200 OK from Bob, Alice. As the endpoints have already established = their operation points through CLUE, this step will not fail except if = an entity not involved in the CLUE negotiation intervenes=97i.e. a = middle box doesn't like that call. > The reason for the existence of step 7, rather than setting up media = channels as side effect of steps 3 through 6 (as assumed in call flow = and in the current framework doc) is twofold: easier integration into = the source base of media codecs that currently use SDP for the selection = of their parameters, and making middlebox people happy.=20 >=20 > The reason for the existence of steps 3 through 6 is our agreement = that not all useful protocol elements envisioned in the framework can be = reasonably and meaningfully implemented in SDP extensions. This is = certainly true for the geometry stuff. >=20 > The reason for keeping an encoding group concept in CLUE is that a = representation of the information that can be conveyed through = individual encoding descriptions, encoding groups, and the association = of media captures with encoding groups (section 7 and 8 of the = framework) purely through grouped m-lines would lead to bloated (if not = exploded :-) SDP, quite possibly well beyond a reasonable size (i.e. MTU = size); the high level of abstraction offered by concepts such as = encoding groups, simultaneous transmission sets, and so on, makes for a = very compact representation compared to listing all possible = permutations of alternative choices in grouped m-lines.=20 >=20 > Does such a mechanism make at least initial sense? Should it be = fleshed out and put into the framework? >=20 > Stephan > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_64FA6479-32CC-4533-BA55-5165B965242C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi all,

Mark, Andy, and myself had a bit of brainstorming how to most = productively use our time during the Monday morning call.  Due to = travel and vacation schedule, our coordination was finalized call only = late Friday.  Which may serve as an explanation, if not as an excuse, for the late timing of this email.

In our opinion, the most pressing issue we have with the framework = document is it being agnostic to the protocol elements used to convey = the various messages that are part of the framework.  Clearly, the = framework was written from a perspective where a CLUE protocol channel would be established, and (all?) further = signaling would be dealt with over that channel.  So is, more or = less, the call flow doc.  We believe that there was sufficient = pushback against that idea to make rapid progress based on this = assumption unlikely.  Accordingly, we believe that we probably best spend = most of our time by discussing a strawman for a split-up between = SDP-represented, SIP-ish, Offer-Answer, =85, that type of traditional = messages, and (XML-coded) messages sent over the CLUE.  The focus of our Monday call would be on the initial exchange, rather than = any updates that may happen during a call.

With reference to the call flow 02 doc (https://datatracker.ietf.org/doc/draft-romanow-clue-call-fl= ow/?include_text=3D1) that exchange could look as follows:
  1. Invite from Alice, just like A.1 in call-flow-02
  2. 200 OK from = Bob, A.2
  3. CLUE Advertisement Alice A.3, covering geometry stuff, = encoding groups, etc.
  4. CLUE Advertisement Bob A.4; note that 3 = and 4 would in practice overlap in time
  5. CLUE Response from Alice = A.5, with the difference that these reposes DO NOT have the side effect = of initiating any media channel related activity; they are pure = signaling
  6. CLUE Response from Bob, A.6, same remark.. 5 and 6 = could overlap in time.
  7. Re-invite from Alice and Bob, = respectively, with media channels as CLUE-"negotiated"
  8. 200 OK = from Bob, Alice.  As the endpoints have already established their = operation points through CLUE, this step will not fail except if an = entity not involved in the CLUE negotiation intervenes=97i.e. a middle = box doesn't like that call.
The reason for the existence of step 7, rather than setting up = media channels as side effect of steps 3 through 6 (as assumed in call = flow and in the current framework doc) is twofold: easier integration = into the source base of media codecs that currently use SDP for the selection of their parameters, and making middlebox = people happy. 

The reason for the existence of steps 3 through 6 is our agreement = that not all useful protocol elements envisioned in the framework can be = reasonably and meaningfully implemented in SDP extensions.  This is = certainly true for the geometry stuff.

The reason for keeping an encoding group concept in CLUE is that a = representation of the information that can be conveyed through = individual encoding descriptions, encoding groups, and the association = of media captures with encoding groups (section 7 and 8 of the framework) purely through grouped m-lines would lead to = bloated (if not exploded :-) SDP, quite possibly well beyond a = reasonable size (i.e. MTU size); the high level of abstraction offered = by concepts such as encoding groups, simultaneous transmission sets, and so on, makes for a very compact representation compared to = listing all possible permutations of alternative choices in grouped = m-lines. 

Does such a mechanism make at least initial sense?  Should it = be fleshed out and put into the framework?

Stephan
_______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/ma= ilman/listinfo/clue

      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_64FA6479-32CC-4533-BA55-5165B965242C-- From stewe@stewe.org Sat Dec 1 10:06:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBDA21E803A for ; Sat, 1 Dec 2012 10:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-a4uMatYie7 for ; Sat, 1 Dec 2012 10:06:28 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6E34011E8099 for ; Sat, 1 Dec 2012 10:06:27 -0800 (PST) Received: from mail188-co9-R.bigfish.com (10.236.132.236) by CO9EHSOBE032.bigfish.com (10.236.130.95) with Microsoft SMTP Server id 14.1.225.23; Sat, 1 Dec 2012 18:06:15 +0000 Received: from mail188-co9 (localhost [127.0.0.1]) by mail188-co9-R.bigfish.com (Postfix) with ESMTP id 3A495360140; Sat, 1 Dec 2012 18:06:15 +0000 (UTC) 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 X-SpamScore: -19 X-BigFish: PS-19(zzc89bhc85eh62a3I14ffIzz1de0h1202h1d1ah1d2ah1082kzz1033IL8275bh8275dh18c673hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1155h) Received-SPF: pass (mail188-co9: 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 mail188-co9 (localhost.localdomain [127.0.0.1]) by mail188-co9 (MessageSwitch) id 1354385172542588_8315; Sat, 1 Dec 2012 18:06:12 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.242]) by mail188-co9.bigfish.com (Postfix) with ESMTP id 829E3AE004A; Sat, 1 Dec 2012 18:06:12 +0000 (UTC) Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 1 Dec 2012 18:06:12 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.9]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0239.002; Sat, 1 Dec 2012 18:06:00 +0000 From: Stephan Wenger To: Simon Pietro Romano Thread-Topic: [clue] Subject matter for Monday's call Thread-Index: AQHNz+TJKeMbGzPb7kq5dxCz2/S00pgEO1OA//97ywA= Date: Sat, 1 Dec 2012 18:06:00 +0000 Message-ID: In-Reply-To: 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_FDBFA77C7400C74F87BC297393B53E352BAF2C15BL2PRD0710MB349_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "clue@ietf.org" Subject: Re: [clue] Subject matter for Monday's call X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 18:06:29 -0000 --_000_FDBFA77C7400C74F87BC297393B53E352BAF2C15BL2PRD0710MB349_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes, this is what we thought as a reasonable starting point for a discussio= n. S. From: Simon Pietro Romano > Date: Saturday, 1 December, 2012 09:59 To: Stephan Wenger > Cc: "clue@ietf.org" > Subject: Re: [clue] Subject matter for Monday's call Hi Stephan, this flow sounds reasonable to me. Just to make sure that I am not misunder= standing something, let me ask you whether steps 3 through 6 are in your mi= nd carried out over an ad hoc created CLUE channel between Alice and Bob. I keep on thinking that a CLUE channel needs to be established, at least fo= r exchanging spatial information that cannot be straightforwardly inserted = into SDP. As I said at the meeting in Atlanta, I would envisage the following high-le= vel sequence of interactions: a. SIP-based COMEDIA negotiation between Alice and Bob, aimed at establishi= ng the CLUE channel (which would be done through steps 1. and 2. of the flo= w you sketched); b. CLUE channel used to exchange XML documents containing CLUE-realted info= rmation for which no direct mapping onto SDP has been identified (steps 3 t= hrough 6 in your flow); c. SIP/SDP used to establish the needed media channel(s), as well as to tra= nsport CLUE-related information for which a mapping onto SDP has been ident= ified (steps 7. and 8. in your flow). Obviously, phases b. and c. above are in some way coupled, since they are b= oth needed in order to provide CLUE entities with the whole picture associa= ted with a telepresence scenario. Is this interpretation correct? Cheers, Simon Il giorno 01/dic/2012, alle ore 17:56, Stephan Wenger ha scritto: Hi all, Mark, Andy, and myself had a bit of brainstorming how to most productively = use our time during the Monday morning call. Due to travel and vacation sc= hedule, our coordination was finalized call only late Friday. Which may se= rve as an explanation, if not as an excuse, for the late timing of this ema= il. In our opinion, the most pressing issue we have with the framework document= is it being agnostic to the protocol elements used to convey the various m= essages that are part of the framework. Clearly, the framework was written= from a perspective where a CLUE protocol channel would be established, and= (all?) further signaling would be dealt with over that channel. So is, mo= re or less, the call flow doc. We believe that there was sufficient pushba= ck against that idea to make rapid progress based on this assumption unlike= ly. Accordingly, we believe that we probably best spend most of our time b= y discussing a strawman for a split-up between SDP-represented, SIP-ish, Of= fer-Answer, =85, that type of traditional messages, and (XML-coded) message= s sent over the CLUE. The focus of our Monday call would be on the initial= exchange, rather than any updates that may happen during a call. With reference to the call flow 02 doc (https://datatracker.ietf.org/doc/dr= aft-romanow-clue-call-flow/?include_text=3D1) that exchange could look as f= ollows: 1. Invite from Alice, just like A.1 in call-flow-02 2. 200 OK from Bob, A.2 3. CLUE Advertisement Alice A.3, covering geometry stuff, encoding group= s, etc. 4. CLUE Advertisement Bob A.4; note that 3 and 4 would in practice overl= ap in time 5. CLUE Response from Alice A.5, with the difference that these reposes = DO NOT have the side effect of initiating any media channel related activit= y; they are pure signaling 6. CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in t= ime. 7. Re-invite from Alice and Bob, respectively, with media channels as CL= UE-"negotiated" 8. 200 OK from Bob, Alice. As the endpoints have already established th= eir operation points through CLUE, this step will not fail except if an ent= ity not involved in the CLUE negotiation intervenes=97i.e. a middle box doe= sn't like that call. The reason for the existence of step 7, rather than setting up media channe= ls as side effect of steps 3 through 6 (as assumed in call flow and in the = current framework doc) is twofold: easier integration into the source base = of media codecs that currently use SDP for the selection of their parameter= s, and making middlebox people happy. The reason for the existence of steps 3 through 6 is our agreement that not= all useful protocol elements envisioned in the framework can be reasonably= and meaningfully implemented in SDP extensions. This is certainly true fo= r the geometry stuff. The reason for keeping an encoding group concept in CLUE is that a represen= tation of the information that can be conveyed through individual encoding = descriptions, encoding groups, and the association of media captures with e= ncoding groups (section 7 and 8 of the framework) purely through grouped m-= lines would lead to bloated (if not exploded :-) SDP, quite possibly well b= eyond a reasonable size (i.e. MTU size); the high level of abstraction offe= red by concepts such as encoding groups, simultaneous transmission sets, an= d so on, makes for a very compact representation compared to listing all po= ssible permutations of alternative choices in grouped m-lines. Does such a mechanism make at least initial sense? Should it be fleshed ou= t and put into the framework? Stephan _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --_000_FDBFA77C7400C74F87BC297393B53E352BAF2C15BL2PRD0710MB349_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3E415DA70494FA41A8DC968706DB4670@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Yes, this is what we thought as a reasonable starting point for a disc= ussion.
S.


From: Simon Pietro Romano <spromano@unina.it>
Date: Saturday, 1 December, 2012 09= :59
To: Stephan Wenger <stewe@stewe.org>
Cc: "clue@ietf.org" <clue@i= etf.org>
Subject: Re: [clue] Subject matter = for Monday's call

Hi Stephan,

this flow sounds reasonable to me. Just to make sure that I am not mis= understanding something, let me ask you whether steps 3 through 6 are in yo= ur mind carried out over an ad hoc created CLUE channel between Alice and B= ob.

I keep on thinking that a CLUE channel needs to be established, at least fo= r exchanging spatial information that cannot be straightforwardly inserted = into SDP.
As I said at the meeting in Atlanta, I would envisage the following hi= gh-level sequence of interactions:

a. SIP-based COMEDIA negotiation between Alice and Bob, aimed at estab= lishing the CLUE channel (which would be done through steps 1. and 2. of th= e flow you sketched);
b. CLUE channel used to exchange XML documents containing CLUE-realted= information for which no direct mapping onto SDP has been identified (step= s 3 through 6 in your flow);
c. SIP/SDP used to establish the needed media channel(s), as well as t= o transport CLUE-related information for which a mapping onto SDP has been = identified  (steps 7. and 8. in your flow).

Obviously, phases b. and c. above are in some way coupled, since they = are both needed in order to provide CLUE entities with the whole picture as= sociated with a telepresence scenario.

Is this interpretation correct?

Cheers,

Simon


Il giorno 01/dic/2012, alle ore 17:56, Stephan Wenger ha scritto:
Hi all,

Mark, Andy, and myself had a bit of brainstorming how to most producti= vely use our time during the Monday morning call.  Due to travel and v= acation schedule, our coordination was finalized call only late Friday. &nb= sp;Which may serve as an explanation, if not as an excuse, for the late timing of this email.

In our opinion, the most pressing issue we have with the framework doc= ument is it being agnostic to the protocol elements used to convey the vari= ous messages that are part of the framework.  Clearly, the framework w= as written from a perspective where a CLUE protocol channel would be established, and (all?) further signaling w= ould be dealt with over that channel.  So is, more or less, the call f= low doc.  We believe that there was sufficient pushback against that i= dea to make rapid progress based on this assumption unlikely.  Accordingly, we believe that we probably best spend most o= f our time by discussing a strawman for a split-up between SDP-represented,= SIP-ish, Offer-Answer, =85, that type of traditional messages, and (XML-co= ded) messages sent over the CLUE.  The focus of our Monday call would be on the initial exchange, rather than any= updates that may happen during a call.

With reference to the call flow 02 doc (https://datat= racker.ietf.org/doc/draft-romanow-clue-call-flow/?include_text=3D1) tha= t exchange could look as follows:
  1. Invite from Alice, just like A.1 in call-flow-02
  2. 200 OK from Bo= b, A.2
  3. CLUE Advertisement Alice A.3, covering geometry stuff, encod= ing groups, etc.
  4. CLUE Advertisement Bob A.4; note that 3 and 4 woul= d in practice overlap in time
  5. CLUE Response from Alice A.5, with th= e difference that these reposes DO NOT have the side effect of initiating a= ny media channel related activity; they are pure signaling
  6. CLUE Res= ponse from Bob, A.6, same remark.. 5 and 6 could overlap in time.
  7. R= e-invite from Alice and Bob, respectively, with media channels as CLUE-&quo= t;negotiated"
  8. 200 OK from Bob, Alice.  As the endpoints h= ave already established their operation points through CLUE, this step will= not fail except if an entity not involved in the CLUE negotiation interven= es=97i.e. a middle box doesn't like that call.
The reason for the existence of step 7, rather than setting up media c= hannels as side effect of steps 3 through 6 (as assumed in call flow and in= the current framework doc) is twofold: easier integration into the source = base of media codecs that currently use SDP for the selection of their parameters, and making middlebox people= happy. 

The reason for the existence of steps 3 through 6 is our agreement tha= t not all useful protocol elements envisioned in the framework can be reaso= nably and meaningfully implemented in SDP extensions.  This is certain= ly true for the geometry stuff.

The reason for keeping an encoding group concept in CLUE is that a rep= resentation of the information that can be conveyed through individual enco= ding descriptions, encoding groups, and the association of media captures w= ith encoding groups (section 7 and 8 of the framework) purely through grouped m-lines would lead to bloated (= if not exploded :-) SDP, quite possibly well beyond a reasonable size (i.e.= MTU size); the high level of abstraction offered by concepts such as encod= ing groups, simultaneous transmission sets, and so on, makes for a very compact representation compared to listi= ng all possible permutations of alternative choices in grouped m-lines.&nbs= p;

Does such a mechanism make at least initial sense?  Should it be = fleshed out and put into the framework?

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

                    =         _\\|/= /_
                    =              ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~= ~~
                   <= span class=3D"Apple-converted-space"> Simon Pietro Romano
               Universita' di Napoli Fe= derico II
                      Computer Engineering Department 
&nb= sp;            Phone: +39 081 7683823 -- = Fax: +39 081 7683816
                    =                      = ;  e-mail: spromano@unina.it

&nb= sp;   <<Molti mi dicono che lo scoraggiamento =CB l'alibi degli&= nbsp;
&nb= sp;   idioti. Ci rifletto un istante; e mi scoraggio>>. Mag= ritte.
                            =        oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~= ~~~~~~~~
&nb= sp;                \ (    = ;        (   )
&nb= sp;                     &= nbsp;           \_)         &n= bsp;) /
                    =                      = ;                     &nb= sp;        (_/





--_000_FDBFA77C7400C74F87BC297393B53E352BAF2C15BL2PRD0710MB349_-- From mary.ietf.barnes@gmail.com Sat Dec 1 11:14: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 9F5E821E80A4 for ; Sat, 1 Dec 2012 11:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIpY8U2tiPP7 for ; Sat, 1 Dec 2012 11:14:21 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0A121E809F for ; Sat, 1 Dec 2012 11:14:20 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1295178lah.31 for ; Sat, 01 Dec 2012 11:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JdQoSzvecjUle5s7JvmzRkpFIN24C1RWlooZ/cYfHn0=; b=sHCSK3UWV6gUVETP7R8AUBjs/0k2cdLkw55oyGXqiUKNFLOsYyB2Wtnis/lPodtoDp C6T+2cpekkf48M+Vm0o/6R53E+tWb4xMsdgrYMZQ7MdCmaRJpfCKlE5DypczkXSnKScs L0Oyy4wqp5ySos4w7msSl+eFSonYp01TmwR8l8eLAikNxFTgQrZ6eUiTPvYyIhe2lthR mOKgj8/hvHQJ9tEteR40QgX0/Ln9TlXKicoYIMZLMYR8Ceh6GeeF2FHE22kJ8kIYPR1K A0X8tX7bWMRsr0+k9v7VGIOAYRgspR9QR9VT7i0KCrSTFTQXxLIisR1tVIM+x2abskr/ weaQ== MIME-Version: 1.0 Received: by 10.152.104.148 with SMTP id ge20mr4809404lab.51.1354389259771; Sat, 01 Dec 2012 11:14:19 -0800 (PST) Received: by 10.114.62.73 with HTTP; Sat, 1 Dec 2012 11:14:19 -0800 (PST) In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A610391863B3C@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A610391863B3C@CRPMBOXPRD01.polycom.com> Date: Sat, 1 Dec 2012 13:14:19 -0600 Message-ID: From: Mary Barnes To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=f46d04071169b75dbc04cfcf524e Cc: "clue@ietf.org" Subject: Re: [clue] CLUE Design team meetings through end of 2012, plans for 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 19:14:22 -0000 --f46d04071169b75dbc04cfcf524e Content-Type: text/plain; charset=ISO-8859-1 It is at 10am Central. I guess because the meeting was scheduled before the time change, it still shows the -5 for GDT. I'll fix the wiki to avoid confusion. Thanks, Mary. On Sat, Dec 1, 2012 at 9:33 AM, Duckworth, Mark wrote: > I see the logistics information for the design team meetings here:**** > > http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team**** > > ** ** > > I want to make sure I have the correct time. It says 10:00 CDT (GMT-5). > So is the meeting at 9:00 CST, or is the meeting really at 10:00 CST > (GMT-6)?**** > > ** ** > > Thanks.**** > > Mark**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* Friday, November 16, 2012 4:45 PM > *To:* CLUE > *Subject:* [clue] CLUE Design team meetings through end of 2012, plans > for 2013**** > > ** ** > > Hi all,**** > > ** ** > > We would like to propose the following schedule for the calls through the > end of 2012. As noted at the meeting, the plan is to focus on the WG > deliverables (those will be summarized in a separate email). We plan to > skip the call next week as it's a US holiday at the end of the week and > I'll be out the whole week. I have jury duty on the 10th, so we'll skip > that unless someone has something compelling they think needs discussion.* > *** > > ** ** > > November 26th: Update on RTP convergence (Roni, Jonathan)**** > > December 3rd: Framework refactoring (Stephan, Andy, Mark)**** > > December 17th: Signaling update (Rob, Roni, Simon, Roberta, Christer)**** > > ** ** > > Note: the first name is the prime for pulling together any materials - > i.e., drafty drafts, email proposals, etc ;) If you do not believe you > are ready, let the chairs know ASAP, so we can find another topic to > discuss and let us know when you anticipate to have something to discuss > with the group. **** > > ** ** > > For 2013, we should start back with the calls on January 14th. **** > > ** ** > > We would also like to plan a virtual interim sometime mid-late Jan - > early-mid Feb. The proposal is for a 2 hr/day 2 day meeting. The chairs > do not believe we need a f2f interim before the next IETF meeting. If you > think we do and are willing to host, let us know ASAP as time is extremely > limited for planning a meeting given the winter/Christmas holiday and the > fact that the time between IETF-85 and IETF-86 is quite short (registration > and scheduling for IETF-86 opens on Dec. 10th). Also, RTCWEB is also > planning an interim - we have no intention of trying to coordinate with > them since it was not effective the last time, we just can't overlap. **** > > ** ** > > Regards,**** > > Mary and Paul**** > > CLUE WG co-chairs**** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --f46d04071169b75dbc04cfcf524e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is at 10am Central. =A0I guess because the meeting was scheduled before = the time change, it still shows the -5 for GDT. =A0 I'll fix the wiki t= o avoid confusion.

Thanks,
Mary.


On Sat, Dec 1, 2012 at 9:33 AM, Duckwort= h, Mark <Mark.Duckworth@polycom.com> wrote:

I see the logistics information for the desi= gn team meetings here:

http://trac.t= ools.ietf.org/wg/clue/trac/wiki/Design-Team

=A0<= /p>

I want to make sure I = have the correct time.=A0 It says 10:00 CDT (GMT-5).=A0 So is the meeting a= t 9:00 CST, or is the meeting really at 10:00 CST (GMT-6)?

=A0<= /p>

Thanks.<= /span>

Mark=

=A0

From:= clu= e-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Friday, November 16, 2012 4:45 PM
To: CLUE
Sub= ject: [clue] CLUE Design team meetings through end of 2012, plans for 2= 013

=A0

Hi all,

<= p class=3D"MsoNormal">=A0

We would like to propose the following schedule for the calls through the= end of 2012. =A0As noted at the meeting, the plan is to focus on the WG de= liverables (those will be summarized in a separate email). We plan to skip = the call next week as it's a US holiday at the end of the week and I= 9;ll be out the whole week. =A0I have jury duty on the 10th, so we'll s= kip that unless someone has something compelling they think needs discussio= n.

=A0

November 26th: =A0Update on RTP convergence (Roni, Jonathan)=

December 3rd: =A0Framew= ork refactoring =A0(Stephan, Andy, Mark)

December 17th: =A0Signaling update (Rob, = Roni, Simon, Roberta, Christer)

=A0

Note: the fi= rst name is the prime for pulling together any materials - i.e., drafty dra= fts, email proposals, etc ;) =A0 If you do not believe you are ready, let t= he chairs know ASAP, so we can find another topic to discuss and let us kno= w when you anticipate to have something to discuss with the group.=A0

=A0

For 2013, we should start back with the calls on January 14t= h. =A0

=A0=

We would also like to plan a virtual interim so= metime mid-late Jan - early-mid Feb. =A0The proposal is for a 2 hr/day 2 da= y meeting. =A0The chairs do not believe we need a f2f interim before the ne= xt IETF meeting. =A0If you think we do and are willing to host, let us know= ASAP as time is extremely limited for planning a meeting given the winter/= Christmas holiday and the fact that the time between IETF-85 and IETF-86 is= quite short (registration and scheduling for IETF-86 opens on Dec. 10th). = =A0Also, RTCWEB is also planning an interim - we have no intention of tryin= g to coordinate with them since it was not effective the last time, we just= can't overlap.=A0

=A0

Regards,

= Mary and Paul

CLUE WG co= -chairs


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


--f46d04071169b75dbc04cfcf524e-- From ron.even.tlv@gmail.com Sun Dec 2 09:40: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 CAA2A21F8590 for ; Sun, 2 Dec 2012 09:40: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt96iDhWnz1d for ; Sun, 2 Dec 2012 09:39:59 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F52621F8592 for ; Sun, 2 Dec 2012 09:39:59 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so1970813obc.31 for ; Sun, 02 Dec 2012 09:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g0p4z+ocMnDMkWljPV29FJISL7yblhRK0uvVbVOL2u4=; b=gF3XXjFF0+gX99X3bjNiDzgdL3VwRA05xmNH2buu4G7CdlxITsV5CacxvQke8LZEyg d+9XrJ34XzYBS92mBJBAzfG1utgbiRtmvwaGlxKhd5Ps4yqar4uoSZwHqh2MtgfzTuUc pWZs/fypC75USBGQjbI+qjiQe3s1vdsHi03tk+DHdQa+Vihc+wIEahEacFzDkcqx320P U9XL3AV2AwPHMzQnluy3ANPp/7EZ9MCLTM3n+p8EsC1sOM9Kb15J9ewnDFP2dr2/+xGf aPj1sYaR2voVvkYAXpSt+qZWOuXZ/PL2uhXB+OFnM6jI/4HFirlKs1riZFIYjXtFn1IZ Z8mQ== MIME-Version: 1.0 Received: by 10.60.168.199 with SMTP id zy7mr6179483oeb.97.1354469998969; Sun, 02 Dec 2012 09:39:58 -0800 (PST) Received: by 10.76.171.103 with HTTP; Sun, 2 Dec 2012 09:39:58 -0800 (PST) In-Reply-To: References: Date: Sun, 2 Dec 2012 19:39:58 +0200 Message-ID: From: Ron Even To: Stephan Wenger Content-Type: multipart/alternative; boundary=bcaec54a38f825c50604cfe21f6f Cc: "clue@ietf.org" Subject: Re: [clue] Subject matter for Monday's call 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, 02 Dec 2012 17:40:00 -0000 --bcaec54a38f825c50604cfe21f6f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, The general flow is ok and the new point here is that after the advertise config there will always be a new offer answer that will establish the media and can be used for defining the SSRCs of all streams. This is important for static mapping and will also be used to support simulcast which is not supported in CLUE. I also assume that step 1 and 2 will include m-lines for allowing initial audio and video this will allow ICE negotiation and having audio and video early in the process. This is required also for interoperability with non CLUE systems As for step 3 and 4 overlap, this may not always be the case, example is an endpoint calling to the MCU who may want to see the advertisement first. Roni On Saturday, December 1, 2012, Stephan Wenger wrote: > Hi all, > > Mark, Andy, and myself had a bit of brainstorming how to most > productively use our time during the Monday morning call. Due to travel > and vacation schedule, our coordination was finalized call only late > Friday. Which may serve as an explanation, if not as an excuse, for the > late timing of this email. > > In our opinion, the most pressing issue we have with the framework > document is it being agnostic to the protocol elements used to convey the > various messages that are part of the framework. Clearly, the framework > was written from a perspective where a CLUE protocol channel would be > established, and (all?) further signaling would be dealt with over that > channel. So is, more or less, the call flow doc. We believe that there > was sufficient pushback against that idea to make rapid progress based on > this assumption unlikely. Accordingly, we believe that we probably best > spend most of our time by discussing a strawman for a split-up between > SDP-represented, SIP-ish, Offer-Answer, =85, that type of traditional > messages, and (XML-coded) messages sent over the CLUE. The focus of our > Monday call would be on the initial exchange, rather than any updates tha= t > may happen during a call. > > With reference to the call flow 02 doc ( > https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include_te= xt=3D1) > that exchange could look as follows: > > 1. Invite from Alice, just like A.1 in call-flow-02 > 2. 200 OK from Bob, A.2 > 3. CLUE Advertisement Alice A.3, covering geometry stuff, encoding > groups, etc. > 4. CLUE Advertisement Bob A.4; note that 3 and 4 would in practice > overlap in time > 5. CLUE Response from Alice A.5, with the difference that these > reposes DO NOT have the side effect of initiating any media channel re= lated > activity; they are pure signaling > 6. CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in > time. > 7. Re-invite from Alice and Bob, respectively, with media channels as > CLUE-"negotiated" > 8. 200 OK from Bob, Alice. As the endpoints have already established > their operation points through CLUE, this step will not fail except if= an > entity not involved in the CLUE negotiation intervenes=97i.e. a middle= box > doesn't like that call. > > The reason for the existence of step 7, rather than setting up media > channels as side effect of steps 3 through 6 (as assumed in call flow and > in the current framework doc) is twofold: easier integration into the > source base of media codecs that currently use SDP for the selection of > their parameters, and making middlebox people happy. > > The reason for the existence of steps 3 through 6 is our agreement that > not all useful protocol elements envisioned in the framework can be > reasonably and meaningfully implemented in SDP extensions. This is > certainly true for the geometry stuff. > > The reason for keeping an encoding group concept in CLUE is that a > representation of the information that can be conveyed through individual > encoding descriptions, encoding groups, and the association of media > captures with encoding groups (section 7 and 8 of the framework) purely > through grouped m-lines would lead to bloated (if not exploded :-) SDP, > quite possibly well beyond a reasonable size (i.e. MTU size); the high > level of abstraction offered by concepts such as encoding groups, > simultaneous transmission sets, and so on, makes for a very compact > representation compared to listing all possible permutations of alternati= ve > choices in grouped m-lines. > > Does such a mechanism make at least initial sense? Should it be fleshed > out and put into the framework? > > Stephan > --bcaec54a38f825c50604cfe21f6f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,
The general flow is ok and the new point here is that after the adv= ertise config there will always be a new offer answer that will establish t= he media and can be used for defining the SSRCs of all streams. This is imp= ortant for static mapping and will also be used to support simulcast which = is not supported in CLUE.
I also assume that step 1 and 2 will include m-lines for allowing init= ial audio=A0and video this will allow=A0ICE negotiation and having audio an= d video early in the process. This is required also for interoperability wi= th non CLUE systems
As for step 3 and 4 overlap, this may not always be the case, example = is an endpoint calling to the MCU who may want to see the advertisement fir= st.

Roni

On Saturday, December= 1, 2012, Stephan Wenger wrote:
Hi all,

Mark, Andy, and myself had a bit of brainstorming how to most producti= vely use our time during the Monday morning call. =A0Due to travel and vaca= tion schedule, our coordination was finalized call only late Friday. =A0Whi= ch may serve as an explanation, if not as an excuse, for the late timing of this email.

In our opinion, the most pressing issue we have with the framework doc= ument is it being agnostic to the protocol elements used to convey the vari= ous messages that are part of the framework. =A0Clearly, the framework was = written from a perspective where a CLUE protocol channel would be established, and (all?) further signaling w= ould be dealt with over that channel. =A0So is, more or less, the call flow= doc. =A0We believe that there was sufficient pushback against that idea to= make rapid progress based on this assumption unlikely. =A0Accordingly, we believe that we probably best spend most of o= ur time by discussing a strawman for a split-up between SDP-represented, SI= P-ish, Offer-Answer, =85, that type of traditional messages, and (XML-coded= ) messages sent over the CLUE. =A0The focus of our Monday call would be on the initial exchange, rather than any= updates that may happen during a call.

With reference to the call flow 02 doc (https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include= _text=3D1) that exchange could look as follows:
  1. Invite from Alice, just like A.1 in call-flow-02
  2. 200 OK from Bo= b, A.2
  3. CLUE Advertisement Alice A.3, covering geometry stuff, encod= ing groups, etc.
  4. CLUE Advertisement Bob A.4; note that 3 and 4 woul= d in practice overlap in time
  5. CLUE Response from Alice A.5, with the difference that these reposes DO= NOT have the side effect of initiating any media channel related activity;= they are pure signaling
  6. CLUE Response from Bob, A.6, same remark..= 5 and 6 could overlap in time.
  7. Re-invite from Alice and Bob, respectively, with media channels as CLUE= -"negotiated"
  8. 200 OK from Bob, Alice. =A0As the endpoints= have already established their operation points through CLUE, this step wi= ll not fail except if an entity not involved in the CLUE negotiation interv= enes=97i.e. a middle box doesn't like that call.
The reason for the existence of step 7, rather than setting up media c= hannels as side effect of steps 3 through 6 (as assumed in call flow and in= the current framework doc) is twofold: easier integration into the source = base of media codecs that currently use SDP for the selection of their parameters, and making middlebox people= happy.=A0

The reason for the existence of steps 3 through 6 is our agreement tha= t not all useful protocol elements envisioned in the framework can be reaso= nably and meaningfully implemented in SDP extensions. =A0This is certainly = true for the geometry stuff.

The reason for keeping an encoding group concept in CLUE is that a rep= resentation of the information that can be conveyed through individual enco= ding descriptions, encoding groups, and the association of media captures w= ith encoding groups (section 7 and 8 of the framework) purely through grouped m-lines would lead to bloated (= if not exploded :-) SDP, quite possibly well beyond a reasonable size (i.e.= MTU size); the high level of abstraction offered by concepts such as encod= ing groups, simultaneous transmission sets, and so on, makes for a very compact representation compared to listi= ng all possible permutations of alternative choices in grouped m-lines.=A0<= /div>

Does such a mechanism make at least initial sense? =A0Should it be fle= shed out and put into the framework?

Stephan
--bcaec54a38f825c50604cfe21f6f-- From christer.holmberg@ericsson.com Sun Dec 2 10:27: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 C2A7C21F8E31 for ; Sun, 2 Dec 2012 10:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.171 X-Spam-Level: X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WVcHp60gkBn for ; Sun, 2 Dec 2012 10:27:19 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6207821F8C65 for ; Sun, 2 Dec 2012 10:27:18 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-a7-50bb9d81248e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D5.DA.26143.18D9BB05; Sun, 2 Dec 2012 19:27:14 +0100 (CET) Received: from ESESSHC023.ericsson.se (153.88.183.87) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 2 Dec 2012 19:27:13 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0318.001; Sun, 2 Dec 2012 19:27:13 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Scene for non-CLUE/single stream devices Thread-Index: Ac3O/cBOqjJfJqi7TtKPPA0WZP9uYQAHrlOAAANVpR0= Date: Sun, 2 Dec 2012 18:27:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04BA08@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B04A64C@ESESSMB209.ericsson.se>, <50B8F4B3.6010206@alum.mit.edu> In-Reply-To: <50B8F4B3.6010206@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW7T3N0BBv/mclvsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldG95te1oIJUhV3W7cwNzC+Euli5OSQEDCR mLttAxuELSZx4d56IJuLQ0jgJKPEjdsTWCCcHYwSc9eeZYdwFjNKvF31lKmLkYODTcBCovuf Nki3iICnxI6PU5hBbGEBG4lT3xezQcRtJdp+3GYHKRcRsJK49jUVJMwioCKxcddvsDCvgLfE ku/8IGEhgWyJt9+Wg3VyCuhI9K3YwwRiMwLd9v3UGjCbWUBc4taT+UwQNwtILNlznhnCFpV4 +fgfK8hICQFFieX9chDlBhLvz81nhrC1JZYtfA1m8woISpyc+YQFYq22RMviCewTGMVnIdkw C0n7LCTts5C0L2BkWcXInpuYmZNebrSJERg3B7f8Vt3BeOecyCFGaQ4WJXFe6617/IUE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwZn3J/fy1lUPbMT/s8JSMy9tzXwXr6oTPSr12dCefycL+ 1cvj06doZQfWOVfvu98xi5NXUyEgOkbvlJRZkv81q9YwgX3z6m77F/3szQ+aJbvsTPD0fJ7C naW6pzYGO9oIWtbKz+niZuhMC19ceTygOKNQKoCvTN5Z6MG7NWdObd/Xv5tN0E2JpTgj0VCL uag4EQDeuWczaQIAAA== Subject: Re: [clue] Scene for non-CLUE/single stream devices 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, 02 Dec 2012 18:27:20 -0000 Hi, >> As we know, we have use-case and requirement to interwork with >> non-CLUE/=94single stream=94 entities. >> >> When such entity sends an SDP offer to a CLUE entity, we can of course >> not specify how it will look like. >> >> But, we can provide guidance on how an SDP offer from a CLUE entity >> shall look like, when communicating with a non-CLUE entity. > > There are a couple of cases here: > > - The CLUE entity doing an initial dialog establishing INVITE, where the > CLUE support of the callee is unknown. > >- Offers to a peer that is known to not support CLUE. This will >typically be subsequent offers within a dialog after an initial dialog >establishing INVITE with o/a that discovers the peer doesn't support >clue. It could also cover the initial invite/offer in cases where the >caller knows (via config or whatever) that the peer doesn't support CLUE. > >We have discussed the first of the above quite a bit, and IIUC we have >agreed not to specify much about this. Some may choose to make a full >CLUE offer and count on non-clue endpoints ignoring what they don't >understand. > >So I think you are talking about the other case. Is that right? >I'll assume that for now. Basically, yes. However, I wasn't talking so much about the signalling, or = what one entity knows about the remote entity. I was more talking about the= structure of scene/SDP when communicating with a non-CLUE entity. >> That also ensures that every CLUE entity is able to generate scenes base= d on those >> requirements. >> >> So, the SDP offer could e.g. look like this: >> >> -1 audio stream (single ssrc) >> >> -1 video stream (single ssrc) >> >> -1 presentation (video?) stream (single ssrc) >> >> This does not require spatial information, the receiver does not need to >> understand multiple streams per m- line, and the need for understanding >> the stream content is minimal. >> >> The provider of course have to be prepared that the non-CLUE entity may >> reject one or more of the offered streams. For example, an audio-only >> device would reject the video streams. >> >> And, the SDP offer may of course not always contain all above, if there >> e.g. is a session without a presentation. > > While I think what you suggest seems to be a reasonably wise choice, I > don't see any reason to specify it. I disagree. I think it would be very useful to specify it :) It will make life easier when operators of non-CLUE networks introduce CLUE= services. They will know what to assume/require from existing entities (ne= twork and endpoints) in order to be able to communicate with the CLUE entit= ies, it will allow them to specify test and conformance specifications. > What I think might be more interesting is to talk about how a clue > endpoint should interpret an incoming offer from a non-clue endpoint. In > particular, how do various sorts of non-clue usages of SDP correspond to > an implied advertisement from that endpoint? Well, we could basically say that a CLUE entity should reply with a similar= response as the offer above: -1 audio stream (single ssrc) -1 video stream (single ssrc) -1 presentation (video?) stream (single ssrc) ...assuming, of course, that the offer contains the associated streams. Regards, Christer From christer.holmberg@ericsson.com Sun Dec 2 10:29: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 A3ED821F85A8 for ; Sun, 2 Dec 2012 10:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quJcGzx4sCjR for ; Sun, 2 Dec 2012 10:29:14 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C616F21F890D for ; Sun, 2 Dec 2012 10:29:13 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-0d-50bb9df80f7c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3B.D7.11564.8FD9BB05; Sun, 2 Dec 2012 19:29:12 +0100 (CET) Received: from ESESSHC001.ericsson.se (153.88.183.21) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 2 Dec 2012 19:29:12 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0318.001; Sun, 2 Dec 2012 19:29:12 +0100 From: Christer Holmberg To: Ron Even , Stephan Wenger Thread-Topic: [clue] Subject matter for Monday's call Thread-Index: AQHNz+TJKeMbGzPb7kq5dxCz2/S00pgFt4sAgAAeFVk= Date: Sun, 2 Dec 2012 18:29:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04C8E9@ESESSMB209.ericsson.se> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje6PubsDDGa2GFrsP3WZ2eJvO7PF 9cZN7A7MHjtn3WX3WLLkJ5PH4vXvGQOYo7hsUlJzMstSi/TtErgyTn14z1awTLli465jrA2M C2W6GDk5JARMJPbPuMYMYYtJXLi3nq2LkYtDSOAko8T8c6uZIJwdjBKzl55khnAWM0pcvfKT tYuRg4NNwEKi+582SLeIgLvEo4WXGEFsZgFlia8Nm5hAbGGgDVdXHWGFqDGVmL7yI5RtJdF4 5A87yBgWARWJi5PcQcK8At4Sj5tWsEKsWsoo0bDvNyNIDadAoMSdpTEgNYxAh34/tYYJYpW4 xK0n85kgHhCQWLLnPNQzohIvH/8Du1JCQFFieb8cRLmBxPtz85khbG2JZQtfM0OsFZQ4OfMJ C4gtBBRvWTyBfQKjxCwkG2YhaZ+FpH0WkvYFjCyrGNlzEzNz0ssNNzECY+zglt+6OxhPnRM5 xCjNwaIkzsuVtN9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6PToo+TqyzdropNEF1VMamy +mH/6ht8M2fqCpcolazwfs61UbjibMdtxkMBj4MYb6jvS1YIW/90qwNH66IDnIXnV2xpUM4t KHdXW92+RfBz43TNO1p8z5vXn0919Z29hGVm8C6mhPP7g/7mnF5rbdHN4u6s3qJ31dSd8X/z prnPTt3iZm3gtFBiKc5INNRiLipOBABpQplwfwIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Subject matter for Monday's call 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, 02 Dec 2012 18:29:18 -0000 Hi, >The general flow is ok and the new point here is that after the advertise = config there will always be a new offer answer that will establish the medi= a and can be used for defining the > SSRCs of all streams. This is important for static mapping and will also = be used to support simulcast which is not supported in CLUE. > I also assume that step 1 and 2 will include m-lines for allowing initial= audio and video this will allow ICE negotiation and having audio and video= early in the process. This is required also for interoperability with non = CLUE systems I guess step 1 and 2 are related to the discussion in the "Scene for non-CL= UE/single stream devices" thread. Regards, Christer On Saturday, December 1, 2012, Stephan Wenger wrote: Hi all, Mark, Andy, and myself had a bit of brainstorming how to most productively = use our time during the Monday morning call. Due to travel and vacation sc= hedule, our coordination was finalized call only late Friday. Which may se= rve as an explanation, if not as an excuse, for the late timing of this ema= il. In our opinion, the most pressing issue we have with the framework document= is it being agnostic to the protocol elements used to convey the various m= essages that are part of the framework. Clearly, the framework was written= from a perspective where a CLUE protocol channel would be established, and= (all?) further signaling would be dealt with over that channel. So is, mo= re or less, the call flow doc. We believe that there was sufficient pushba= ck against that idea to make rapid progress based on this assumption unlike= ly. Accordingly, we believe that we probably best spend most of our time b= y discussing a strawman for a split-up between SDP-represented, SIP-ish, Of= fer-Answer, =85, that type of traditional messages, and (XML-coded) message= s sent over the CLUE. The focus of our Monday call would be on the initial= exchange, rather than any updates that may happen during a call. With reference to the call flow 02 doc (https://datatracker.ietf.org/doc/dr= aft-romanow-clue-call-flow/?include_text=3D1) that exchange could look as f= ollows: 1. Invite from Alice, just like A.1 in call-flow-02 2. 200 OK from Bob, A.2 3. CLUE Advertisement Alice A.3, covering geometry stuff, encoding group= s, etc. 4. CLUE Advertisement Bob A.4; note that 3 and 4 would in practice overl= ap in time 5. CLUE Response from Alice A.5, with the difference that these reposes = DO NOT have the side effect of initiating any media channel related activit= y; they are pure signaling 6. CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in t= ime. 7. Re-invite from Alice and Bob, respectively, with media channels as CL= UE-"negotiated" 8. 200 OK from Bob, Alice. As the endpoints have already established th= eir operation points through CLUE, this step will not fail except if an ent= ity not involved in the CLUE negotiation intervenes=97i.e. a middle box doe= sn't like that call. The reason for the existence of step 7, rather than setting up media channe= ls as side effect of steps 3 through 6 (as assumed in call flow and in the = current framework doc) is twofold: easier integration into the source base = of media codecs that currently use SDP for the selection of their parameter= s, and making middlebox people happy. The reason for the existence of steps 3 through 6 is our agreement that not= all useful protocol elements envisioned in the framework can be reasonably= and meaningfully implemented in SDP extensions. This is certainly true fo= r the geometry stuff. The reason for keeping an encoding group concept in CLUE is that a represen= tation of the information that can be conveyed through individual encoding = descriptions, encoding groups, and the association of media captures with e= ncoding groups (section 7 and 8 of the framework) purely through grouped m-= lines would lead to bloated (if not exploded :-) SDP, quite possibly well b= eyond a reasonable size (i.e. MTU size); the high level of abstraction offe= red by concepts such as encoding groups, simultaneous transmission sets, an= d so on, makes for a very compact representation compared to listing all po= ssible permutations of alternative choices in grouped m-lines. Does such a mechanism make at least initial sense? Should it be fleshed ou= t and put into the framework? Stephan From stewe@stewe.org Sun Dec 2 10:35: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 6605D21F85B3 for ; Sun, 2 Dec 2012 10:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDHI0tv+0c2H for ; Sun, 2 Dec 2012 10:35:49 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 86A7B21F86A2 for ; Sun, 2 Dec 2012 10:35:49 -0800 (PST) Received: from mail58-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE031.bigfish.com (10.236.130.94) with Microsoft SMTP Server id 14.1.225.23; Sun, 2 Dec 2012 18:35:43 +0000 Received: from mail58-co9 (localhost [127.0.0.1]) by mail58-co9-R.bigfish.com (Postfix) with ESMTP id 5253B380102; Sun, 2 Dec 2012 18:35:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zz98dI1432I14ffIzz1de0h1202h1d1ah1d2ah1082kzz1033IL8275bh8275dhz2fh2a8h668h839h946hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h) Received-SPF: pass (mail58-co9: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail58-co9 (localhost.localdomain [127.0.0.1]) by mail58-co9 (MessageSwitch) id 1354473340210015_18613; Sun, 2 Dec 2012 18:35:40 +0000 (UTC) Received: from CO9EHSMHS007.bigfish.com (unknown [10.236.132.243]) by mail58-co9.bigfish.com (Postfix) with ESMTP id 305175C0049; Sun, 2 Dec 2012 18:35:40 +0000 (UTC) Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by CO9EHSMHS007.bigfish.com (10.236.130.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 2 Dec 2012 18:35:40 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.9]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0245.002; Sun, 2 Dec 2012 18:35:34 +0000 From: Stephan Wenger To: Christer Holmberg , Ron Even Thread-Topic: [clue] Subject matter for Monday's call Thread-Index: AQHNz+TJKeMbGzPb7kq5dxCz2/S00pgFyE4AgAANwID//3uoAA== Date: Sun, 2 Dec 2012 18:35:34 +0000 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04C8E9@ESESSMB209.ericsson.se> 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: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "clue@ietf.org" Subject: Re: [clue] Subject matter for Monday's call 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, 02 Dec 2012 18:35:50 -0000 On 12.2.2012 10:29 , "Christer Holmberg" wrote: > >Hi, > >>The general flow is ok and the new point here is that after the >>advertise config there will always be a new offer answer that will >>establish the media and can be used for defining the >> SSRCs of all streams. This is important for static mapping and will >>also be used to support simulcast which is not supported in CLUE. >> I also assume that step 1 and 2 will include m-lines for allowing >>initial audio and video this will allow ICE negotiation and having audio >>and video early in the process. This is required also for >>interoperability with non CLUE systems > >I guess step 1 and 2 are related to the discussion in the "Scene for >non-CLUE/single stream devices" thread. Yes, in the sense that if the negotiation of the CLUE channel fails, then all you have to work with is the non-CLUE aspects of the OA exchange. Please see also my reply to Roni's email. Stephan > >Regards, > >Christer > > > > > >On Saturday, December 1, 2012, Stephan Wenger wrote: >Hi all, > >Mark, Andy, and myself had a bit of brainstorming how to most >productively use our time during the Monday morning call. Due to travel >and vacation schedule, our coordination was finalized call only late >Friday. Which may serve as an explanation, if not as an excuse, for the >late timing of this email. > >In our opinion, the most pressing issue we have with the framework >document is it being agnostic to the protocol elements used to convey the >various messages that are part of the framework. Clearly, the framework >was written from a perspective where a CLUE protocol channel would be >established, and (all?) further signaling would be dealt with over that >channel. So is, more or less, the call flow doc. We believe that there >was sufficient pushback against that idea to make rapid progress based on >this assumption unlikely. Accordingly, we believe that we probably best >spend most of our time by discussing a strawman for a split-up between >SDP-represented, SIP-ish, Offer-Answer, =8A, that type of traditional >messages, and (XML-coded) messages sent over the CLUE. The focus of our >Monday call would be on the initial exchange, rather than any updates >that may happen during a call. > >With reference to the call flow 02 doc >(https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include_te >xt=3D1) that exchange could look as follows: > > 1. Invite from Alice, just like A.1 in call-flow-02 > 2. 200 OK from Bob, A.2 > 3. CLUE Advertisement Alice A.3, covering geometry stuff, encoding >groups, etc. > 4. CLUE Advertisement Bob A.4; note that 3 and 4 would in practice >overlap in time > 5. CLUE Response from Alice A.5, with the difference that these >reposes DO NOT have the side effect of initiating any media channel >related activity; they are pure signaling > 6. CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in >time. > 7. Re-invite from Alice and Bob, respectively, with media channels as >CLUE-"negotiated" > 8. 200 OK from Bob, Alice. As the endpoints have already established >their operation points through CLUE, this step will not fail except if an >entity not involved in the CLUE negotiation intervenes=8Bi.e. a middle box >doesn't like that call. > >The reason for the existence of step 7, rather than setting up media >channels as side effect of steps 3 through 6 (as assumed in call flow and >in the current framework doc) is twofold: easier integration into the >source base of media codecs that currently use SDP for the selection of >their parameters, and making middlebox people happy. > >The reason for the existence of steps 3 through 6 is our agreement that >not all useful protocol elements envisioned in the framework can be >reasonably and meaningfully implemented in SDP extensions. This is >certainly true for the geometry stuff. > >The reason for keeping an encoding group concept in CLUE is that a >representation of the information that can be conveyed through individual >encoding descriptions, encoding groups, and the association of media >captures with encoding groups (section 7 and 8 of the framework) purely >through grouped m-lines would lead to bloated (if not exploded :-) SDP, >quite possibly well beyond a reasonable size (i.e. MTU size); the high >level of abstraction offered by concepts such as encoding groups, >simultaneous transmission sets, and so on, makes for a very compact >representation compared to listing all possible permutations of >alternative choices in grouped m-lines. > >Does such a mechanism make at least initial sense? Should it be fleshed >out and put into the framework? > >Stephan > From stewe@stewe.org Sun Dec 2 10:45: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 27BA421F86E5 for ; Sun, 2 Dec 2012 10:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9p3WEnHtI4Q for ; Sun, 2 Dec 2012 10:45:34 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id A10AE21F86D2 for ; Sun, 2 Dec 2012 10:45:33 -0800 (PST) Received: from mail96-ch1-R.bigfish.com (10.43.68.226) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Sun, 2 Dec 2012 18:45:32 +0000 Received: from mail96-ch1 (localhost [127.0.0.1]) by mail96-ch1-R.bigfish.com (Postfix) with ESMTP id 5FD453802CE; Sun, 2 Dec 2012 18:45:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz98dIc85eh14ffIzz1de0h1202h1d1ah1d2ah1082kzz1033IL8275bh8275dh18c673hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1155h) Received-SPF: pass (mail96-ch1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail96-ch1 (localhost.localdomain [127.0.0.1]) by mail96-ch1 (MessageSwitch) id 1354473929654951_21991; Sun, 2 Dec 2012 18:45:29 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail96-ch1.bigfish.com (Postfix) with ESMTP id 9E11C8004A; Sun, 2 Dec 2012 18:45:29 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 2 Dec 2012 18:45:28 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.9]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0245.002; Sun, 2 Dec 2012 18:45:28 +0000 From: Stephan Wenger To: Ron Even Thread-Topic: [clue] Subject matter for Monday's call Thread-Index: AQHNz+TJKeMbGzPb7kq5dxCz2/S00pgFyE4A//+MKYA= Date: Sun, 2 Dec 2012 18:45:27 +0000 Message-ID: In-Reply-To: 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_FDBFA77C7400C74F87BC297393B53E352BAF3E97BL2PRD0710MB349_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "clue@ietf.org" Subject: Re: [clue] Subject matter for Monday's call 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, 02 Dec 2012 18:45:35 -0000 --_000_FDBFA77C7400C74F87BC297393B53E352BAF3E97BL2PRD0710MB349_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Roni, Inline. S. From: Ron Even > Date: Sunday, 2 December, 2012 09:39 To: Stephan Wenger > Cc: "clue@ietf.org" > Subject: Re: [clue] Subject matter for Monday's call Hi, The general flow is ok and the new point here is that after the advertise c= onfig there will always be a new offer answer that will establish the media= and can be used for defining the SSRCs of all streams. This is important f= or static mapping and will also be used to support simulcast which is not s= upported in CLUE. I also assume that step 1 and 2 will include m-lines for allowing initial a= udio and video this will allow ICE negotiation and having audio and video e= arly in the process. This is required also for interoperability with non CL= UE systems SW: yes and no. As you wrote, steps 1 and 2 can negotiate media using m-lin= es for initial media for fast startup, legacy support, and similar purposes= . However, the use of those I consider an optimization that CLUEful system= s may or may not implement. In other words, I think it MUST be possible th= at only a CLUE channel is established early, but the CLUEful systems reject= the initial media channels. In this case, all the ICE for the "real" medi= a channels is being done in those new steps 7 and 8. (the likelihood of su= ccess for dealing with ICE at that stage rather than early on appears to me= to be the same=97we are just talking about timing here)) Also, it MUST be= possible that , after the CLUE negotiation is done, the initial channels b= e torn down in favor of those new channels, for example in such cases where= certain codecs is only made available to CLUEful applications and not else= where, and the originally negotiated channels not using those codecs would = be redundant. It MAY be possible to "overload" the negotiated channels wit= h the new media as negotiated in CLUE, but again, that is an optimization p= roblem. As for step 3 and 4 overlap, this may not always be the case, example is an= endpoint calling to the MCU who may want to see the advertisement first. True. Roni On Saturday, December 1, 2012, Stephan Wenger wrote: Hi all, Mark, Andy, and myself had a bit of brainstorming how to most productively = use our time during the Monday morning call. Due to travel and vacation sc= hedule, our coordination was finalized call only late Friday. Which may se= rve as an explanation, if not as an excuse, for the late timing of this ema= il. In our opinion, the most pressing issue we have with the framework document= is it being agnostic to the protocol elements used to convey the various m= essages that are part of the framework. Clearly, the framework was written= from a perspective where a CLUE protocol channel would be established, and= (all?) further signaling would be dealt with over that channel. So is, mo= re or less, the call flow doc. We believe that there was sufficient pushba= ck against that idea to make rapid progress based on this assumption unlike= ly. Accordingly, we believe that we probably best spend most of our time b= y discussing a strawman for a split-up between SDP-represented, SIP-ish, Of= fer-Answer, =85, that type of traditional messages, and (XML-coded) message= s sent over the CLUE. The focus of our Monday call would be on the initial= exchange, rather than any updates that may happen during a call. With reference to the call flow 02 doc (https://datatracker.ietf.org/doc/dr= aft-romanow-clue-call-flow/?include_text=3D1) that exchange could look as f= ollows: 1. Invite from Alice, just like A.1 in call-flow-02 2. 200 OK from Bob, A.2 3. CLUE Advertisement Alice A.3, covering geometry stuff, encoding group= s, etc. 4. CLUE Advertisement Bob A.4; note that 3 and 4 would in practice overl= ap in time 5. CLUE Response from Alice A.5, with the difference that these reposes = DO NOT have the side effect of initiating any media channel related activit= y; they are pure signaling 6. CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in t= ime. 7. Re-invite from Alice and Bob, respectively, with media channels as CL= UE-"negotiated" 8. 200 OK from Bob, Alice. As the endpoints have already established th= eir operation points through CLUE, this step will not fail except if an ent= ity not involved in the CLUE negotiation intervenes=97i.e. a middle box doe= sn't like that call. The reason for the existence of step 7, rather than setting up media channe= ls as side effect of steps 3 through 6 (as assumed in call flow and in the = current framework doc) is twofold: easier integration into the source base = of media codecs that currently use SDP for the selection of their parameter= s, and making middlebox people happy. The reason for the existence of steps 3 through 6 is our agreement that not= all useful protocol elements envisioned in the framework can be reasonably= and meaningfully implemented in SDP extensions. This is certainly true fo= r the geometry stuff. The reason for keeping an encoding group concept in CLUE is that a represen= tation of the information that can be conveyed through individual encoding = descriptions, encoding groups, and the association of media captures with e= ncoding groups (section 7 and 8 of the framework) purely through grouped m-= lines would lead to bloated (if not exploded :-) SDP, quite possibly well b= eyond a reasonable size (i.e. MTU size); the high level of abstraction offe= red by concepts such as encoding groups, simultaneous transmission sets, an= d so on, makes for a very compact representation compared to listing all po= ssible permutations of alternative choices in grouped m-lines. Does such a mechanism make at least initial sense? Should it be fleshed ou= t and put into the framework? Stephan --_000_FDBFA77C7400C74F87BC297393B53E352BAF3E97BL2PRD0710MB349_ Content-Type: text/html; charset="Windows-1252" Content-ID: <08BF078E0B5C43468E88BD3188343214@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Roni,
Inline.
S.


From: Ron Even <ron.even.tlv@gmail.com>
Date: Sunday, 2 December, 2012 09:3= 9
To: Stephan Wenger <stewe@stewe.org>
Cc: "clue@ietf.org" <clue@i= etf.org>
Subject: Re: [clue] Subject matter = for Monday's call

Hi,
The general flow is ok and the new point here is that after the advert= ise config there will always be a new offer answer that will establish the = media and can be used for defining the SSRCs of all streams. This is import= ant for static mapping and will also be used to support simulcast which is not supported in CLUE.
I also assume that step 1 and 2 will include m-lines for allowing init= ial audio and video this will allow ICE negotiation and having au= dio and video early in the process. This is required also for interoperabil= ity with non CLUE systems

SW: yes and = no. As you wrote, steps 1 and 2 can negotiate media using m-lines for initi= al media for fast startup, legacy support, and similar purposes.  Howe= ver, the use of those I consider an optimization that CLUEful systems may or may not implement.  In other words, I thi= nk it MUST be possible that only a CLUE channel is established early, but t= he CLUEful systems reject the initial media channels.  In this case, a= ll the ICE for the "real" media channels is being done in those new steps 7 and 8.  (the likelihood of = success for dealing with ICE at that stage rather than early on a= ppears to me to be the same=97we are just talking about timing here))  Also, it MUST be possible that<= /span> , after the CLUE negotiation is done, the initial channels be torn down in f= avor of those new channels, for example in such cases where certain codecs = is only made available to CLUEful applications and not elsewhere, and the o= riginally negotiated channels not using those codecs would be redundant.  It MAY be possible to "o= verload" the negotiated channels with the new media as negotiated in C= LUE, but again, that is an optimization problem.

As for step 3 and 4 overlap, this may not always be the case, example = is an endpoint calling to the MCU who may want to see the advertisement fir= st.

True.

Roni

On Saturday, December 1, 2012, Stephan Wenger wrote:
Hi all,

Mark, Andy, and myself had a bit of brainstorming how to most producti= vely use our time during the Monday morning call.  Due to travel and v= acation schedule, our coordination was finalized call only late Friday. &nb= sp;Which may serve as an explanation, if not as an excuse, for the late timing of this email.

In our opinion, the most pressing issue we have with the framework doc= ument is it being agnostic to the protocol elements used to convey the vari= ous messages that are part of the framework.  Clearly, the framework w= as written from a perspective where a CLUE protocol channel would be established, and (all?) further signaling w= ould be dealt with over that channel.  So is, more or less, the call f= low doc.  We believe that there was sufficient pushback against that i= dea to make rapid progress based on this assumption unlikely.  Accordingly, we believe that we probably best spend most o= f our time by discussing a strawman for a split-up between SDP-represented,= SIP-ish, Offer-Answer, =85, that type of traditional messages, and (XML-co= ded) messages sent over the CLUE.  The focus of our Monday call would be on the initial exchange, rather than any= updates that may happen during a call.

With reference to the call flow 02 doc (https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include= _text=3D1) that exchange could look as follows:
  1. Invite from Alice, just like A.1 in call-flow-02
  2. 200 OK from Bo= b, A.2
  3. CLUE Advertisement Alice A.3, covering geometry stuff, encod= ing groups, etc.
  4. CLUE Advertisement Bob A.4; note that 3 and 4 woul= d in practice overlap in time
  5. CLUE Response from Alice A.5, with the difference that these repos= es DO NOT have the side effect of initiating any media channel related acti= vity; they are pure signaling
  6. CLUE Response from Bob, A.6, same rem= ark.. 5 and 6 could overlap in time.
  7. Re-invite from Alice and Bob,= respectively, with media channels as CLUE-"negotiated"
  8. 2= 00 OK from Bob, Alice.  As the endpoints have already established thei= r operation points through CLUE, this step will not fail except if an entit= y not involved in the CLUE negotiation intervenes=97i.e. a middle box doesn= 't like that call.
The reason for the existence of step 7, rather than setting up media c= hannels as side effect of steps 3 through 6 (as assumed in call flow and in= the current framework doc) is twofold: easier integration into the source = base of media codecs that currently use SDP for the selection of their parameters, and making middlebox people= happy. 

The reason for the existence of steps 3 through 6 is our agreement tha= t not all useful protocol elements envisioned in the framework can be reaso= nably and meaningfully implemented in SDP extensions.  This is certain= ly true for the geometry stuff.

The reason for keeping an encoding group concept in CLUE is that a rep= resentation of the information that can be conveyed through individual enco= ding descriptions, encoding groups, and the association of media captures w= ith encoding groups (section 7 and 8 of the framework) purely through grouped m-lines would lead to bloated (= if not exploded :-) SDP, quite possibly well beyond a reasonable size (i.e.= MTU size); the high level of abstraction offered by concepts such as encod= ing groups, simultaneous transmission sets, and so on, makes for a very compact representation compared to listi= ng all possible permutations of alternative choices in grouped m-lines.&nbs= p;

Does such a mechanism make at least initial sense?  Should it be = fleshed out and put into the framework?

Stephan
 --_000_FDBFA77C7400C74F87BC297393B53E352BAF3E97BL2PRD0710MB349_-- From Christian.Groves@nteczone.com Sun Dec 2 20:04:59 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8B721F89A9 for ; Sun, 2 Dec 2012 20:04:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15mdG-io8DtJ for ; Sun, 2 Dec 2012 20:04:58 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 0393C21F8993 for ; Sun, 2 Dec 2012 20:04:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgDAPYjvFB20agx/2dsb2JhbAANN75yBAOBGoMRAQEBBAEBATUbGwQGDQQLEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBiBirPZJPBIxAhEEDkk+Wfw Received: from ppp118-209-168-49.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.168.49]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Dec 2012 14:34:50 +1030 Message-ID: <50BC24E0.8080402@nteczone.com> Date: Mon, 03 Dec 2012 15:04:48 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Capture scene clarifications 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, 03 Dec 2012 04:04:59 -0000 Hello Mark, I'm no strongly against being able to select individual captures however it seems to me to add complications and I think that if we were to continue to go in that direction could benefit from further discussion in the framework. What isn't clear to me in the current framework is whether the sending of simultaneous transmission sets is mandatory and if not what omitting this part of an advertisement means? Please see some further replies below. Regards, Christian On 2/12/2012 2:18 AM, Duckworth, Mark wrote: > Points a) and b) are consistent with the intent of the current framework. Point d) starts to change the intent. The framework allows for a media consumer to receive multiple capture scene entries (regardless of media type) at the same time. I think point d) is proposing we not allow this. I think saying "A consumer shall choose a capture scene entry rather than choosing individual captures from multiple entries" is equivalent to saying "A consumer shall choose at most one capture scene entry (of a particular media type) from any particular capture scene". > > Such a restriction probably reduces the scenarios in which the provider needs to express simultaneous transmission sets, because some of the simultaneity constraints are now included in the capture scene entries. As others have pointed out, there is still the possibility of simultaneous constraints that apply across multiple capture scenes. [CNG] I don't think point d) changes this. The current description of capture scene entry says that a provider must be able to send all the media associated with the individual captures within a capture scene entry concurrently. This would also need to be reflected in any simultaneous set entries. This seems to be a place for possible inconsistencies because the data would effectively be duplicated. > > Adding this restriction, to not allow multiple capture scene entries (of same media type, in the same scene) to be used simultaneously is okay with me, but I don't think it really simplifies much. > > As others have said, allowing a consumer to choose a subset of captures from a capture scene entry makes sense to me too. > > I have a few more comments about the proposals inline below. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Thursday, November 22, 2012 10:56 PM >> To: clue@ietf.org >> Subject: [clue] Capture scene clarifications >> >> >> Hello, >> >> Paul K reminded me that I have an action point from the interim meeting >> regarding my draft . At the meeting it >> seems that there was general agreement with the intent of the >> proposals: >> a) A scene represents an area where the capture devices are >> spatially related, i.e. a presentation that shares no spatial >> relation with a video is a separate scene. >> >> b) A capture scene entry thus represents alternate >> representations of a complete scene. The provider is the one >> that determines what a complete scene is. A consumer choses >> a capture scene entry from the scene in the knowledge that it >> represents the entire scene. >> >> d) A consumer shall chose a capture scene entry rather than >> choosing individual captures from multiple entries. This >> does not mean that an consuming endpoint must render all the >> captures. What is locally rendered and how is a local >> decision. >> >> I think the framework draft could be enhanced in a few places to make the >> intent of CLUE clearer. Below are some suggested updates. >> >> 1) Introduce a new definition for "Scene". The capture scene definition and >> several places mention "scene" but there's no explanation. I propose the >> following definition to be added to section 3 of the draft: >> Scene: Represents an area where the capture devices are spatially related. >> Non-spatially related devices exist in different scenes. > [Duckworth, Mark] Sounds good. > >> 2) Update the definition of "Capture scene entry" to make it clearer that it >> represents an entire scene. Proposed text is: >> *Capture Scene Entry: a list of media captures of the same media type >> that together form one representation of an entire capture scene. > [Duckworth, Mark] Sounds good. > >> 3) Update section 6.2 on Capture scenes to reflect the above intents. >> Changes proposals are: >> - Section 6.2 2nd paragraph: >> "A capture scene is a structure representing the <> scene that is >> captured by a collection of<>capture devices. A capture >> scene..." > [Duckworth, Mark] Sounds good. > >> - Section 6.2 3rd paragraph: >> "A provider may advertise multiple capture scenes or just a single >> capture scene.<> >> A media provider might typically use one capture >> scene for main participant media and another capture scene for a >> computer generated presentation...." > [Duckworth, Mark] sounds good > >> - Section 6.2 4th paragraph: >> "A media provider arranges media captures in a capture scene to help >> the media consumer choose which captures it wants. The capture scene >> entries in a capture scene are different alternatives the provider is >> suggesting for representing the entire capture scene.> paragraph>". >> >> - Section 6.2 5th paragraph: >> "Media captures within the same capture scene entry must be of the >> same media type - it is not possible to mix audio and video captures >> in the same capture scene entry, for instance. The provider must be >> capable of encoding and sending all media captures in a single entry >> simultaneously." >> >> - section 6.2 New paragraph dealing with consumer behaviour after the 7th >> paragraph. >> "A consumer may receive an advertisement with multiple capture scenes. >> A consumer may choose to receive any number of capture scenes. An >> advertised capture scene it may contain one of more capture scene entries >> that may contain one of more media captures. A consumer may choose an >> capture scene entry in the knowledge that it is a complete representation of >> the scene for a particular media type and that all media captures are spatially >> related. For a particular media type the consumer shall choose one capture >> scene entry rather than choosing individual captures from multiple capture >> scene entries. However this does not mean that a consuming endpoint must >> render all the media captures. What is locally rendered and how is a local >> decision." > [Duckworth, Mark] These three proposed changes above are related to not allowing multiple capture scene entries, of the same media type, in the same scene, from being used simultaneously. I could go either way on this change, whatever the group decides. > >> 4) The framework uses the terms "media provider" and "provider". We >> probably should be consistent in the use of the term throughout the >> framework. > [Duckworth, Mark] sounds good. > >> 5) Related to the "capture group" concept that didn't seem to get support is >> the ordering in the Capture scene, Capture scene entry, Media captures. >> There was some discussion that people had assumed some sort of >> prioritisation / ordering related to these structures. i.e. If I have a capture >> scene entry VC0, VC1, VC2 do I assume they should be rendered left to right >> or is there nothing to be assumed? I take it is the later understanding put I >> didn't see anything in the framework regarding what should be assumed. We >> probably should also add something for that. > [Duckworth, Mark] From the framework: "Determination of the order of these captures (VC0, VC1 and VC2) for rendering purposes is accomplished through use of their Area of Capture attributes." I don't know what other type or order or prioritization you might be talking about here. [CNG] One aspect is the "spatial ordering" i.e. how something is rendered the other aspect is regarding how the consumer interprets the order of scene/capture scene entry/capture within the message. i.e. Is the first capture scene entry more important than the last entry? There has been some discussion previously that some people that the provider of the advertisement could provide some prioritisation hint to the consumer by ordering the list of capture scene entries. From the text you mentioned aspect is there a general conclusion that there is no prioritisation implied from the ordering of elements in the advertisement? > >> Thoughts? >> >> Regards, Christian >> _______________________________________________ >> 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 Sun Dec 2 20:12: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 43B0B21F8991 for ; Sun, 2 Dec 2012 20:12:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5B7I6oOjM1oI for ; Sun, 2 Dec 2012 20:12:12 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 57DD021F8990 for ; Sun, 2 Dec 2012 20:12:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAD4lvFB20agx/2dsb2JhbAANN8AUgxEBAQEEAQEBLwEFGxsKEQsYCRYPCQMCAQIBFTATBgIBARWIA6s9klAEjECEQQOST5Z/ Received: from ppp118-209-168-49.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.168.49]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Dec 2012 14:42:11 +1030 Message-ID: <50BC2699.1060508@nteczone.com> Date: Mon, 03 Dec 2012 15:12:09 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B04A64C@ESESSMB209.ericsson.se>, <50B8F4B3.6010206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04BA08@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04BA08@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Scene for non-CLUE/single stream devices 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, 03 Dec 2012 04:12:13 -0000 Hello Christer, Given the recent discussion on restructuring the documentation for CLUE where do you see such guidelines being documented? Perhaps the call flows can document the case of an initial invite to a CLUEfull and a CLUEless endpoint? In some cases the provider may know that the peer supports CLUE in some cases not. Regards, Christian On 3/12/2012 5:27 AM, Christer Holmberg wrote: > Hi, > >>> As we know, we have use-case and requirement to interwork with >>> non-CLUE/”single stream” entities. >>> >>> When such entity sends an SDP offer to a CLUE entity, we can of course >>> not specify how it will look like. >>> >>> But, we can provide guidance on how an SDP offer from a CLUE entity >>> shall look like, when communicating with a non-CLUE entity. >> There are a couple of cases here: >> >> - The CLUE entity doing an initial dialog establishing INVITE, where the >> CLUE support of the callee is unknown. >> >> - Offers to a peer that is known to not support CLUE. This will >> typically be subsequent offers within a dialog after an initial dialog >> establishing INVITE with o/a that discovers the peer doesn't support >> clue. It could also cover the initial invite/offer in cases where the >> caller knows (via config or whatever) that the peer doesn't support CLUE. >> >> We have discussed the first of the above quite a bit, and IIUC we have >> agreed not to specify much about this. Some may choose to make a full >> CLUE offer and count on non-clue endpoints ignoring what they don't >> understand. >> >> So I think you are talking about the other case. Is that right? >> I'll assume that for now. > Basically, yes. However, I wasn't talking so much about the signalling, or what one entity knows about the remote entity. I was more talking about the structure of scene/SDP when communicating with a non-CLUE entity. > >>> That also ensures that every CLUE entity is able to generate scenes based on those >>> requirements. >>> >>> So, the SDP offer could e.g. look like this: >>> >>> -1 audio stream (single ssrc) >>> >>> -1 video stream (single ssrc) >>> >>> -1 presentation (video?) stream (single ssrc) >>> >>> This does not require spatial information, the receiver does not need to >>> understand multiple streams per m- line, and the need for understanding >>> the stream content is minimal. >>> >>> The provider of course have to be prepared that the non-CLUE entity may >>> reject one or more of the offered streams. For example, an audio-only >>> device would reject the video streams. >>> >>> And, the SDP offer may of course not always contain all above, if there >>> e.g. is a session without a presentation. >> While I think what you suggest seems to be a reasonably wise choice, I >> don't see any reason to specify it. > I disagree. I think it would be very useful to specify it :) > > It will make life easier when operators of non-CLUE networks introduce CLUE services. They will know what to assume/require from existing entities (network and endpoints) in order to be able to communicate with the CLUE entities, it will allow them to specify test and conformance specifications. > >> What I think might be more interesting is to talk about how a clue >> endpoint should interpret an incoming offer from a non-clue endpoint. In >> particular, how do various sorts of non-clue usages of SDP correspond to >> an implied advertisement from that endpoint? > Well, we could basically say that a CLUE entity should reply with a similar response as the offer above: > > -1 audio stream (single ssrc) > -1 video stream (single ssrc) > -1 presentation (video?) stream (single ssrc) > > ...assuming, of course, that the offer contains the associated streams. > > Regards, > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Sun Dec 2 20:18: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 14D6721F8998 for ; Sun, 2 Dec 2012 20:18:49 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AvNvjvXEUx2 for ; Sun, 2 Dec 2012 20:18:48 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 573AF21F8992 for ; Sun, 2 Dec 2012 20:18:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAConvFB20agx/2dsb2JhbAANN8AUgxEBAQEEAQEBLwEFGxQHCg8CCxEDAQIBCRYIBwkDAgECAQkMHwkIEwYCAQGIGKs5klAEBIw8CxCEJgOST5Z/gVg Received: from ppp118-209-168-49.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.168.49]) by ipmail04.adl6.internode.on.net with ESMTP; 03 Dec 2012 14:48:46 +1030 Message-ID: <50BC2824.6010100@nteczone.com> Date: Mon, 03 Dec 2012 15:18:44 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Subject matter for Monday's call 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, 03 Dec 2012 04:18:49 -0000 Hello Stephan and Simon, Thanks for the clarification/confirmation. This sounds reasonable to me. I was a bit thrown by "We believe that there was sufficient pushback against that idea to make rapid progress based on this assumption unlikely" from your original email. Regards, Christian On 2/12/2012 5:06 AM, Stephan Wenger wrote: > Yes, this is what we thought as a reasonable starting point for a > discussion. > S. > > > From: Simon Pietro Romano > > Date: Saturday, 1 December, 2012 09:59 > To: Stephan Wenger > > Cc: "clue@ietf.org " > > Subject: Re: [clue] Subject matter for Monday's call > > Hi Stephan, > > this flow sounds reasonable to me. Just to make sure that I am not > misunderstanding something, let me ask you whether steps 3 through 6 > are in your mind carried out over an ad hoc created CLUE channel > between Alice and Bob. > > I keep on thinking that a CLUE channel needs to be established, at > least for exchanging spatial information that cannot be > straightforwardly inserted into SDP. > As I said at the meeting in Atlanta, I would envisage the following > high-level sequence of interactions: > > a. SIP-based COMEDIA negotiation between Alice and Bob, aimed at > establishing the CLUE channel (which would be done through steps 1. > and 2. of the flow you sketched); > b. CLUE channel used to exchange XML documents containing CLUE-realted > information for which no direct mapping onto SDP has been identified > (steps 3 through 6 in your flow); > c. SIP/SDP used to establish the needed media channel(s), as well as > to transport CLUE-related information for which a mapping onto SDP has > been identified (steps 7. and 8. in your flow). > > Obviously, phases b. and c. above are in some way coupled, since they > are both needed in order to provide CLUE entities with the whole > picture associated with a telepresence scenario. > > Is this interpretation correct? > > Cheers, > > Simon > > > Il giorno 01/dic/2012, alle ore 17:56, Stephan Wenger ha scritto: > >> Hi all, >> >> Mark, Andy, and myself had a bit of brainstorming how to most >> productively use our time during the Monday morning call. Due to >> travel and vacation schedule, our coordination was finalized call >> only late Friday. Which may serve as an explanation, if not as an >> excuse, for the late timing of this email. >> >> In our opinion, the most pressing issue we have with the framework >> document is it being agnostic to the protocol elements used to convey >> the various messages that are part of the framework. Clearly, the >> framework was written from a perspective where a CLUE protocol >> channel would be established, and (all?) further signaling would be >> dealt with over that channel. So is, more or less, the call flow doc. >> We believe that there was sufficient pushback against that idea to >> make rapid progress based on this assumption unlikely. Accordingly, >> we believe that we probably best spend most of our time by discussing >> a strawman for a split-up between SDP-represented, SIP-ish, >> Offer-Answer, …, that type of traditional messages, and (XML-coded) >> messages sent over the CLUE. The focus of our Monday call would be on >> the initial exchange, rather than any updates that may happen during >> a call. >> >> With reference to the call flow 02 doc >> (https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include_text=1) >> that exchange could look as follows: >> >> 1. Invite from Alice, just like A.1 in call-flow-02 >> 2. 200 OK from Bob, A.2 >> 3. CLUE Advertisement Alice A.3, covering geometry stuff, encoding >> groups, etc. >> 4. CLUE Advertisement Bob A.4; note that 3 and 4 would in practice >> overlap in time >> 5. CLUE Response from Alice A.5, with the difference that these >> reposes DO NOT have the side effect of initiating any media >> channel related activity; they are pure signaling >> 6. CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap >> in time. >> 7. Re-invite from Alice and Bob, respectively, with media channels >> as CLUE-"negotiated" >> 8. 200 OK from Bob, Alice. As the endpoints have already established >> their operation points through CLUE, this step will not fail >> except if an entity not involved in the CLUE negotiation >> intervenes—i.e. a middle box doesn't like that call. >> >> The reason for the existence of step 7, rather than setting up media >> channels as side effect of steps 3 through 6 (as assumed in call flow >> and in the current framework doc) is twofold: easier integration into >> the source base of media codecs that currently use SDP for the >> selection of their parameters, and making middlebox people happy. >> >> The reason for the existence of steps 3 through 6 is our agreement >> that not all useful protocol elements envisioned in the framework can >> be reasonably and meaningfully implemented in SDP extensions. This is >> certainly true for the geometry stuff. >> >> The reason for keeping an encoding group concept in CLUE is that a >> representation of the information that can be conveyed through >> individual encoding descriptions, encoding groups, and the >> association of media captures with encoding groups (section 7 and 8 >> of the framework) purely through grouped m-lines would lead to >> bloated (if not exploded :-) SDP, quite possibly well beyond a >> reasonable size (i.e. MTU size); the high level of abstraction >> offered by concepts such as encoding groups, simultaneous >> transmission sets, and so on, makes for a very compact representation >> compared to listing all possible permutations of alternative choices >> in grouped m-lines. >> >> Does such a mechanism make at least initial sense? Should it be >> fleshed out and put into the framework? >> >> Stephan >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Sun Dec 2 23:33: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 9245721F8AE5 for ; Sun, 2 Dec 2012 23:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwezwXtofqUB for ; Sun, 2 Dec 2012 23:33:52 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3E18721F8AE1 for ; Sun, 2 Dec 2012 23:33:52 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-3d-50bc55dd2278 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4C.4E.11564.DD55CB05; Mon, 3 Dec 2012 08:33:49 +0100 (CET) Received: from ESESSHC022.ericsson.se (153.88.183.84) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 08:33:49 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 08:33:49 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Scene for non-CLUE/single stream devices Thread-Index: Ac3O/cBOqjJfJqi7TtKPPA0WZP9uYQAHrlOAAANVpR0Adoq1gAAJD/Ng Date: Mon, 3 Dec 2012 07:33:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04CBC1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B04A64C@ESESSMB209.ericsson.se>, <50B8F4B3.6010206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04BA08@ESESSMB209.ericsson.se> <50BC2699.1060508@nteczone.com> In-Reply-To: <50BC2699.1060508@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvje7d0D0BBjcem1h8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugSvj3eJjTAWLlCrm9KxnbGA8L93FyMEhIWAi cearSBcjJ5ApJnHh3nq2LkYuDiGBk4wSt9+/gnJ2MEp87L4F5SxmlDiz5AELSDebgIVE9z9t kG4RgXCJjm1XGEFsYQEbiVPfF7NBxG0l2n7cZoew3SSOHpsJZrMIqEj8vn0FzOYV8JaYdreR BWL+JUaJ59e2gA3iFNCROLirF2wQI9B530+tYQKxmQXEJW49mc8EcbaAxJI955khbFGJl4// sULYihI7z7YzQ9TrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsIDYQkDxlsUT2Ccwis9CsmIWkvZZ SNpnIWlfwMiyipE9NzEzJ73ccBMjMHoObvmtu4Px1DmRQ4zSHCxK4rxcSfv9hQTSE0tSs1NT C1KL4otKc1KLDzEycXBKNTBy3V33Nt8z5t8i6wvTc9SfnXmelsrfxFyx1Gvtjj02MRccjp48 nVfae2Xfgpklxn8WXTrw1lbS335C/gVPK9mmbWVrxCItM9n9Nmv99XDg8P9SJVB+49S8+Pqf N+7xvFpv8uP7niomAYFqoZitNp5tz7rK+q+cf7PAm9kgsL3xp9f20ohHKcJKLMUZiYZazEXF iQCo4+hVbAIAAA== Subject: Re: [clue] Scene for non-CLUE/single stream devices 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, 03 Dec 2012 07:33:53 -0000 Hi, >Given the recent discussion on restructuring the documentation for CLUE wh= ere do you see such guidelines being documented? > >Perhaps the call flows can document the case of an initial invite to a CLU= Efull and a CLUEless endpoint? In some cases the provider may know that the= peer supports CLUE in some cases not. Call flow is good, but I would also like to have it normatively documented. We are anyway going to need to have some normative procedures regarding SDP= and offer/answer (which SDP extensions are used etc), so... Regards, Christer On 3/12/2012 5:27 AM, Christer Holmberg wrote: > Hi, > >>> As we know, we have use-case and requirement to interwork with=20 >>> non-CLUE/"single stream" entities. >>> >>> When such entity sends an SDP offer to a CLUE entity, we can of=20 >>> course not specify how it will look like. >>> >>> But, we can provide guidance on how an SDP offer from a CLUE entity=20 >>> shall look like, when communicating with a non-CLUE entity. >> There are a couple of cases here: >> >> - The CLUE entity doing an initial dialog establishing INVITE, where=20 >> the CLUE support of the callee is unknown. >> >> - Offers to a peer that is known to not support CLUE. This will=20 >> typically be subsequent offers within a dialog after an initial=20 >> dialog establishing INVITE with o/a that discovers the peer doesn't=20 >> support clue. It could also cover the initial invite/offer in cases=20 >> where the caller knows (via config or whatever) that the peer doesn't su= pport CLUE. >> >> We have discussed the first of the above quite a bit, and IIUC we=20 >> have agreed not to specify much about this. Some may choose to make a=20 >> full CLUE offer and count on non-clue endpoints ignoring what they=20 >> don't understand. >> >> So I think you are talking about the other case. Is that right? >> I'll assume that for now. > Basically, yes. However, I wasn't talking so much about the signalling, o= r what one entity knows about the remote entity. I was more talking about t= he structure of scene/SDP when communicating with a non-CLUE entity. > >>> That also ensures that every CLUE entity is able to generate scenes=20 >>> based on those requirements. >>> >>> So, the SDP offer could e.g. look like this: >>> >>> -1 audio stream (single ssrc) >>> >>> -1 video stream (single ssrc) >>> >>> -1 presentation (video?) stream (single ssrc) >>> >>> This does not require spatial information, the receiver does not=20 >>> need to understand multiple streams per m- line, and the need for=20 >>> understanding the stream content is minimal. >>> >>> The provider of course have to be prepared that the non-CLUE entity=20 >>> may reject one or more of the offered streams. For example, an=20 >>> audio-only device would reject the video streams. >>> >>> And, the SDP offer may of course not always contain all above, if=20 >>> there e.g. is a session without a presentation. >> While I think what you suggest seems to be a reasonably wise choice,=20 >> I don't see any reason to specify it. > I disagree. I think it would be very useful to specify it :) > > It will make life easier when operators of non-CLUE networks introduce CL= UE services. They will know what to assume/require from existing entities (= network and endpoints) in order to be able to communicate with the CLUE ent= ities, it will allow them to specify test and conformance specifications. > >> What I think might be more interesting is to talk about how a clue=20 >> endpoint should interpret an incoming offer from a non-clue endpoint.=20 >> In particular, how do various sorts of non-clue usages of SDP=20 >> correspond to an implied advertisement from that endpoint? > Well, we could basically say that a CLUE entity should reply with a simil= ar response as the offer above: > > -1 audio stream (single ssrc) > -1 video stream (single ssrc) > -1 presentation (video?) stream (single ssrc) > > ...assuming, of course, that the offer contains the associated streams. > > Regards, > > Christer > > _______________________________________________ > 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 christer.holmberg@ericsson.com Sun Dec 2 23:53: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 57C5F21F857E for ; Sun, 2 Dec 2012 23:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaPq78DSfiSj for ; Sun, 2 Dec 2012 23:53:22 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5378B21F8538 for ; Sun, 2 Dec 2012 23:53:21 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-12-50bc5a6f6c92 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 47.74.26143.F6A5CB05; Mon, 3 Dec 2012 08:53:20 +0100 (CET) Received: from ESESSHC010.ericsson.se (153.88.183.48) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 08:53:18 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 08:53:18 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3JLnoSzk8+n3np90eOVjDiWPg3KwGoy/AQAExSlQAACbjyIA== Date: Mon, 3 Dec 2012 07:53:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04CBFE@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> In-Reply-To: <50BC24E0.8080402@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+JvjW5B1J4Ag65Aiy/vG1ks9p+6zOzA 5LFkyU8mjxXnZ7IEMEVx2aSk5mSWpRbp2yVwZZw80MhUcC+44mfDWpYGxtNOXYycHBICJhLn Pl1nhrDFJC7cW8/WxcjFISRwklHi1aM2FghnB6PEgksLoDKLGSX2t8xh6mLk4GATsJDo/qcN 0i0iEC7Rse0KI4gtLGAgcfLjDXaIuKHE1iVzWCFsJ4mFLTPBtrEIqEicOXMSzOYV8JbY+a0H av5URonLRyEGcQroSLRsPgpmMwKd9/3UGiYQm1lAXOLWk/lMEGcLSCzZcx7qBVGJl4//sULY ihI7z7YzQ9TrSCzY/YkNwtaWWLbwNdRiQYmTM5+wgNhCQPGWxRPYJzCKz0KyYhaS9llI2mch aV/AyLKKkT03MTMnvdxoEyMweg5u+a26g/HOOZFDjNIcLErivNZb9/gLCaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYNwtIMZ6X9P7arPuk19aEkFhiR+uty84vmA1f3hi4EH17ZonpeZlzgxJ 4J176r22qni8VLNPnvNtJ9b4LypZeV/ffe/beP5Bqu2PdA/l9NxgtkVt/6fe+W9yKi3JsSs8 ytw1/8Ua10tPMipmN8/SPOfccK3EKD5g4o5dMTrHzgXdlXB8/e5JmhJLcUaioRZzUXEiAI4t 5CFsAgAA Subject: Re: [clue] Capture scene clarifications 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, 03 Dec 2012 07:53:23 -0000 Hi, I think there are two questions here: 1) Is it allowed to choose multiple capture scene entries (associated with = the same scene)? 2) Is it allowed to choose, from a given capture scene entry, a subset of c= aptures? Regarding 1), I see very little reasons for allowing it. Of course, it shal= l be possible to receive multiple capture scene entries, associated with *d= ifferent* scenes. A typical example is one entry associated with the "room"= , and one associated with a "presentation". Regarding 2), during the SDP offer/answer, nothing can prevent the answerer= from rejecting streams associated with specific captures. But, I am not su= re we need to cover it in the CLUE signaling. In the CLUE signaling the ans= werer indicates which capture scene entry it wants - including all captures= associated with it. Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= istian Groves Sent: 3. joulukuuta 2012 6:05 To: clue@ietf.org Subject: Re: [clue] Capture scene clarifications Hello Mark, I'm no strongly against being able to select individual captures however it= seems to me to add complications and I think that if we were to continue t= o go in that direction could benefit from further discussion in the framewo= rk. What isn't clear to me in the current framework is whether the sending of s= imultaneous transmission sets is mandatory and if not what omitting this pa= rt of an advertisement means? Please see some further replies below. Regards, Christian On 2/12/2012 2:18 AM, Duckworth, Mark wrote: > Points a) and b) are consistent with the intent of the current framework.= Point d) starts to change the intent. The framework allows for a media c= onsumer to receive multiple capture scene entries (regardless of media type= ) at the same time. I think point d) is proposing we not allow this. I th= ink saying "A consumer shall choose a capture scene entry rather than choos= ing individual captures from multiple entries" is equivalent to saying "A c= onsumer shall choose at most one capture scene entry (of a particular media= type) from any particular capture scene". > > Such a restriction probably reduces the scenarios in which the provider n= eeds to express simultaneous transmission sets, because some of the simulta= neity constraints are now included in the capture scene entries. As others= have pointed out, there is still the possibility of simultaneous constrain= ts that apply across multiple capture scenes. [CNG] I don't think point d) changes this. The current description of captu= re scene entry says that a provider must be able to send all the media asso= ciated with the individual captures within a capture scene entry concurrent= ly. This would also need to be reflected in any simultaneous set entries. T= his seems to be a place for possible inconsistencies because the data would= effectively be duplicated. > > Adding this restriction, to not allow multiple capture scene entries (of = same media type, in the same scene) to be used simultaneously is okay with = me, but I don't think it really simplifies much. > > As others have said, allowing a consumer to choose a subset of captures f= rom a capture scene entry makes sense to me too. > > I have a few more comments about the proposals inline below. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 >> Of Christian Groves >> Sent: Thursday, November 22, 2012 10:56 PM >> To: clue@ietf.org >> Subject: [clue] Capture scene clarifications >> >> >> Hello, >> >> Paul K reminded me that I have an action point from the interim=20 >> meeting regarding my draft .=20 >> At the meeting it seems that there was general agreement with the=20 >> intent of the >> proposals: >> a) A scene represents an area where the capture devices are >> spatially related, i.e. a presentation that shares no spati= al >> relation with a video is a separate scene. >> >> b) A capture scene entry thus represents alternate >> representations of a complete scene. The provider is the o= ne >> that determines what a complete scene is. A consumer chose= s >> a capture scene entry from the scene in the knowledge that = it >> represents the entire scene. >> >> d) A consumer shall chose a capture scene entry rather than >> choosing individual captures from multiple entries. This >> does not mean that an consuming endpoint must render all th= e >> captures. What is locally rendered and how is a local >> decision. >> >> I think the framework draft could be enhanced in a few places to make=20 >> the intent of CLUE clearer. Below are some suggested updates. >> >> 1) Introduce a new definition for "Scene". The capture scene=20 >> definition and several places mention "scene" but there's no=20 >> explanation. I propose the following definition to be added to section 3= of the draft: >> Scene: Represents an area where the capture devices are spatially relate= d. >> Non-spatially related devices exist in different scenes. > [Duckworth, Mark] Sounds good. > >> 2) Update the definition of "Capture scene entry" to make it clearer=20 >> that it represents an entire scene. Proposed text is: >> *Capture Scene Entry: a list of media captures of the same media type >> that together form one representation of an entire capture scene. > [Duckworth, Mark] Sounds good. > >> 3) Update section 6.2 on Capture scenes to reflect the above intents. >> Changes proposals are: >> - Section 6.2 2nd paragraph: >> "A capture scene is a structure representing the <> scene that i= s >> captured by a collection of<>capture devices. =20 >> A capture scene..." > [Duckworth, Mark] Sounds good. > >> - Section 6.2 3rd paragraph: >> "A provider may advertise multiple capture scenes or just a single >> capture scene.<> provider.>> A media provider might typically use one capture >> scene for main participant media and another capture scene for a >> computer generated presentation...." > [Duckworth, Mark] sounds good > >> - Section 6.2 4th paragraph: >> "A media provider arranges media captures in a capture scene to help >> the media consumer choose which captures it wants. The capture sce= ne >> entries in a capture scene are different alternatives the provider = is >> suggesting for representing the entire capture scene.> rest of >> paragraph>". >> >> - Section 6.2 5th paragraph: >> "Media captures within the same capture scene entry must be of the >> same media type - it is not possible to mix audio and video capture= s >> in the same capture scene entry, for instance. The provider must b= e >> capable of encoding and sending all media captures in a single entr= y >> simultaneously." >> >> - section 6.2 New paragraph dealing with consumer behaviour after the=20 >> 7th paragraph. >> "A consumer may receive an advertisement with multiple capture scenes= . >> A consumer may choose to receive any number of capture scenes. An=20 >> advertised capture scene it may contain one of more capture scene=20 >> entries that may contain one of more media captures. A consumer may=20 >> choose an capture scene entry in the knowledge that it is a complete=20 >> representation of the scene for a particular media type and that all=20 >> media captures are spatially related. For a particular media type the=20 >> consumer shall choose one capture scene entry rather than choosing=20 >> individual captures from multiple capture scene entries. However this=20 >> does not mean that a consuming endpoint must render all the media=20 >> captures. What is locally rendered and how is a local decision." > [Duckworth, Mark] These three proposed changes above are related to not a= llowing multiple capture scene entries, of the same media type, in the same= scene, from being used simultaneously. I could go either way on this chan= ge, whatever the group decides. > >> 4) The framework uses the terms "media provider" and "provider". We=20 >> probably should be consistent in the use of the term throughout the=20 >> framework. > [Duckworth, Mark] sounds good. > >> 5) Related to the "capture group" concept that didn't seem to get=20 >> support is the ordering in the Capture scene, Capture scene entry, Media= captures. >> There was some discussion that people had assumed some sort of=20 >> prioritisation / ordering related to these structures. i.e. If I have=20 >> a capture scene entry VC0, VC1, VC2 do I assume they should be=20 >> rendered left to right or is there nothing to be assumed? I take it=20 >> is the later understanding put I didn't see anything in the framework=20 >> regarding what should be assumed. We probably should also add something = for that. > [Duckworth, Mark] From the framework: "Determination of the order of thes= e captures (VC0, VC1 and VC2) for rendering purposes is accomplished throug= h use of their Area of Capture attributes." I don't know what other type o= r order or prioritization you might be talking about here. [CNG] One aspect is the "spatial ordering" i.e. how something is rendered t= he other aspect is regarding how the consumer interprets the order of scene= /capture scene entry/capture within the message. i.e. Is the first capture = scene entry more important than the last entry? There has been some discuss= ion previously that some people that the provider of the advertisement coul= d provide some prioritisation hint to the consumer by ordering the list of = capture scene entries. From the text you mentioned aspect is there a genera= l conclusion that there is no prioritisation implied from the ordering of e= lements in the advertisement? > >> Thoughts? >> >> Regards, Christian >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Dec 3 07:35:31 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C8321F85B1 for ; Mon, 3 Dec 2012 07:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AJeWpU7JnAT for ; Mon, 3 Dec 2012 07:35:30 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id CB44A21F84E6 for ; Mon, 3 Dec 2012 07:35:29 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id X0Yf1k0091c6gX8533bR9s; Mon, 03 Dec 2012 15:35:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id X3bR1k00e3ZTu2S3j3bRAv; Mon, 03 Dec 2012 15:35:25 +0000 Message-ID: <50BCC6BD.8080904@alum.mit.edu> Date: Mon, 03 Dec 2012 10:35:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <7594FB04B1934943A5C02806D1A2204B04CBFE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04CBFE@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354548925; bh=v0NBTwBt0NsjZosU1V4bqd5uiaP+mIQuDrmJED7X6f4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EgChGV7uUgbmzA78VJySK/2559ekzXRWq4rc5vKI52BAPmYDuVaJrhu3Qpd9Q/jKe gM0fXSzZM6cfgJ91nolmgqF11cvSFi6sUzOF3+hPgGUft1C2oXhSDpwwYy3a2cjjM4 ribnriYEba/1vMEAtFkfpy81ip1EG2fZp1WhdeL/ql4H90yIZHAyMOf1QjWyXy13JM b+PRY9ohPn6pKh39raC9DluzHA7sUTtb8Zr+gKzgrilJ4wZ+skGLCaQH7OpAkAicdn V4Y3NiRvR321/PTykuUXdMsLeqLUCs/O3B0s9CF02Ha+dFHyS+BKz1S3XUw8qk2Jhp wehSHo+NUIbNg== Subject: Re: [clue] Capture scene clarifications 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, 03 Dec 2012 15:35:31 -0000 On 12/3/12 2:53 AM, Christer Holmberg wrote: > Hi, > > I think there are two questions here: > > 1) Is it allowed to choose multiple capture scene entries (associated with the same scene)? > 2) Is it allowed to choose, from a given capture scene entry, a subset of captures? > > Regarding 1), I see very little reasons for allowing it. Of course, it shall be possible to receive multiple capture scene entries, associated with *different* scenes. A typical example is one entry associated with the "room", and one associated with a "presentation". I can see how it could be useful for a MCU to do this. This would give it the flexibility to offer a wider range of choices in its own advertisements. Thanks, Paul > Regarding 2), during the SDP offer/answer, nothing can prevent the answerer from rejecting streams associated with specific captures. But, I am not sure we need to cover it in the CLUE signaling. In the CLUE signaling the answerer indicates which capture scene entry it wants - including all captures associated with it. > Regards, > > Christer > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 3. joulukuuta 2012 6:05 > To: clue@ietf.org > Subject: Re: [clue] Capture scene clarifications > > Hello Mark, > > I'm no strongly against being able to select individual captures however it seems to me to add complications and I think that if we were to continue to go in that direction could benefit from further discussion in the framework. > > What isn't clear to me in the current framework is whether the sending of simultaneous transmission sets is mandatory and if not what omitting this part of an advertisement means? > > Please see some further replies below. > > Regards, Christian > > On 2/12/2012 2:18 AM, Duckworth, Mark wrote: >> Points a) and b) are consistent with the intent of the current framework. Point d) starts to change the intent. The framework allows for a media consumer to receive multiple capture scene entries (regardless of media type) at the same time. I think point d) is proposing we not allow this. I think saying "A consumer shall choose a capture scene entry rather than choosing individual captures from multiple entries" is equivalent to saying "A consumer shall choose at most one capture scene entry (of a particular media type) from any particular capture scene". >> >> Such a restriction probably reduces the scenarios in which the provider needs to express simultaneous transmission sets, because some of the simultaneity constraints are now included in the capture scene entries. As others have pointed out, there is still the possibility of simultaneous constraints that apply across multiple capture scenes. > [CNG] I don't think point d) changes this. The current description of capture scene entry says that a provider must be able to send all the media associated with the individual captures within a capture scene entry concurrently. This would also need to be reflected in any simultaneous set entries. This seems to be a place for possible inconsistencies because the data would effectively be duplicated. >> >> Adding this restriction, to not allow multiple capture scene entries (of same media type, in the same scene) to be used simultaneously is okay with me, but I don't think it really simplifies much. >> >> As others have said, allowing a consumer to choose a subset of captures from a capture scene entry makes sense to me too. >> >> I have a few more comments about the proposals inline below. >> >> Mark >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Christian Groves >>> Sent: Thursday, November 22, 2012 10:56 PM >>> To: clue@ietf.org >>> Subject: [clue] Capture scene clarifications >>> >>> >>> Hello, >>> >>> Paul K reminded me that I have an action point from the interim >>> meeting regarding my draft . >>> At the meeting it seems that there was general agreement with the >>> intent of the >>> proposals: >>> a) A scene represents an area where the capture devices are >>> spatially related, i.e. a presentation that shares no spatial >>> relation with a video is a separate scene. >>> >>> b) A capture scene entry thus represents alternate >>> representations of a complete scene. The provider is the one >>> that determines what a complete scene is. A consumer choses >>> a capture scene entry from the scene in the knowledge that it >>> represents the entire scene. >>> >>> d) A consumer shall chose a capture scene entry rather than >>> choosing individual captures from multiple entries. This >>> does not mean that an consuming endpoint must render all the >>> captures. What is locally rendered and how is a local >>> decision. >>> >>> I think the framework draft could be enhanced in a few places to make >>> the intent of CLUE clearer. Below are some suggested updates. >>> >>> 1) Introduce a new definition for "Scene". The capture scene >>> definition and several places mention "scene" but there's no >>> explanation. I propose the following definition to be added to section 3 of the draft: >>> Scene: Represents an area where the capture devices are spatially related. >>> Non-spatially related devices exist in different scenes. >> [Duckworth, Mark] Sounds good. >> >>> 2) Update the definition of "Capture scene entry" to make it clearer >>> that it represents an entire scene. Proposed text is: >>> *Capture Scene Entry: a list of media captures of the same media type >>> that together form one representation of an entire capture scene. >> [Duckworth, Mark] Sounds good. >> >>> 3) Update section 6.2 on Capture scenes to reflect the above intents. >>> Changes proposals are: >>> - Section 6.2 2nd paragraph: >>> "A capture scene is a structure representing the <> scene that is >>> captured by a collection of<>capture devices. >>> A capture scene..." >> [Duckworth, Mark] Sounds good. >> >>> - Section 6.2 3rd paragraph: >>> "A provider may advertise multiple capture scenes or just a single >>> capture scene.<>> provider.>> A media provider might typically use one capture >>> scene for main participant media and another capture scene for a >>> computer generated presentation...." >> [Duckworth, Mark] sounds good >> >>> - Section 6.2 4th paragraph: >>> "A media provider arranges media captures in a capture scene to help >>> the media consumer choose which captures it wants. The capture scene >>> entries in a capture scene are different alternatives the provider is >>> suggesting for representing the entire capture scene.>> rest of >>> paragraph>". >>> >>> - Section 6.2 5th paragraph: >>> "Media captures within the same capture scene entry must be of the >>> same media type - it is not possible to mix audio and video captures >>> in the same capture scene entry, for instance. The provider must be >>> capable of encoding and sending all media captures in a single entry >>> simultaneously." >>> >>> - section 6.2 New paragraph dealing with consumer behaviour after the >>> 7th paragraph. >>> "A consumer may receive an advertisement with multiple capture scenes. >>> A consumer may choose to receive any number of capture scenes. An >>> advertised capture scene it may contain one of more capture scene >>> entries that may contain one of more media captures. A consumer may >>> choose an capture scene entry in the knowledge that it is a complete >>> representation of the scene for a particular media type and that all >>> media captures are spatially related. For a particular media type the >>> consumer shall choose one capture scene entry rather than choosing >>> individual captures from multiple capture scene entries. However this >>> does not mean that a consuming endpoint must render all the media >>> captures. What is locally rendered and how is a local decision." >> [Duckworth, Mark] These three proposed changes above are related to not allowing multiple capture scene entries, of the same media type, in the same scene, from being used simultaneously. I could go either way on this change, whatever the group decides. >> >>> 4) The framework uses the terms "media provider" and "provider". We >>> probably should be consistent in the use of the term throughout the >>> framework. >> [Duckworth, Mark] sounds good. >> >>> 5) Related to the "capture group" concept that didn't seem to get >>> support is the ordering in the Capture scene, Capture scene entry, Media captures. >>> There was some discussion that people had assumed some sort of >>> prioritisation / ordering related to these structures. i.e. If I have >>> a capture scene entry VC0, VC1, VC2 do I assume they should be >>> rendered left to right or is there nothing to be assumed? I take it >>> is the later understanding put I didn't see anything in the framework >>> regarding what should be assumed. We probably should also add something for that. >> [Duckworth, Mark] From the framework: "Determination of the order of these captures (VC0, VC1 and VC2) for rendering purposes is accomplished through use of their Area of Capture attributes." I don't know what other type or order or prioritization you might be talking about here. > [CNG] One aspect is the "spatial ordering" i.e. how something is rendered the other aspect is regarding how the consumer interprets the order of scene/capture scene entry/capture within the message. i.e. Is the first capture scene entry more important than the last entry? There has been some discussion previously that some people that the provider of the advertisement could provide some prioritisation hint to the consumer by ordering the list of capture scene entries. From the text you mentioned aspect is there a general conclusion that there is no prioritisation implied from the ordering of elements in the advertisement? >> >>> Thoughts? >>> >>> Regards, Christian >>> _______________________________________________ >>> 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 Mark.Duckworth@polycom.com Mon Dec 3 09:27: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 524B821F890C for ; Mon, 3 Dec 2012 09:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8lttr83ZRoH for ; Mon, 3 Dec 2012 09:27:57 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 02E8021F881D for ; Mon, 3 Dec 2012 09:27:56 -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, 3 Dec 2012 09:27:55 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 3 Dec 2012 09:27:52 -0800 Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3RC2vgD+ujA/kXQOO9Zlwp04C8AgAbjl5Q Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> In-Reply-To: <50BC24E0.8080402@nteczone.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] Capture scene clarifications 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, 03 Dec 2012 17:27:58 -0000 Hello Christian, I agree the framework (or other document, after refactoring) needs to be cl= ear about whether expressing simultaneous transmission sets is mandatory or= not. Maybe it should be mandatory for the media provider to express a sim= ultaneous transmission set that includes all the media captures, even if it= has no restrictions. About the order of capture scenes, entries within a scene, and captures wit= hin an entry - the framework intent was that this order had no significance= . But it does seem it might be useful to use the ordering as a prioritizat= ion hint from provider to consumer. If we decide we want to do this, we ne= ed to make it clear in the framework (or possibly lower level document, if = that is where it ends up after refactoring). Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Sunday, December 02, 2012 11:05 PM > To: clue@ietf.org > Subject: Re: [clue] Capture scene clarifications >=20 > Hello Mark, >=20 > I'm no strongly against being able to select individual captures however = it > seems to me to add complications and I think that if we were to continue = to > go in that direction could benefit from further discussion in the framewo= rk. >=20 > What isn't clear to me in the current framework is whether the sending of > simultaneous transmission sets is mandatory and if not what omitting this > part of an advertisement means? >=20 > Please see some further replies below. >=20 > Regards, Christian >=20 > On 2/12/2012 2:18 AM, Duckworth, Mark wrote: > > Points a) and b) are consistent with the intent of the current framewor= k. > Point d) starts to change the intent. The framework allows for a media > consumer to receive multiple capture scene entries (regardless of media > type) at the same time. I think point d) is proposing we not allow this.= I think > saying "A consumer shall choose a capture scene entry rather than choosin= g > individual captures from multiple entries" is equivalent to saying "A > consumer shall choose at most one capture scene entry (of a particular > media type) from any particular capture scene". > > > > Such a restriction probably reduces the scenarios in which the provider > needs to express simultaneous transmission sets, because some of the > simultaneity constraints are now included in the capture scene entries. = As > others have pointed out, there is still the possibility of simultaneous > constraints that apply across multiple capture scenes. > [CNG] I don't think point d) changes this. The current description of cap= ture > scene entry says that a provider must be able to send all the media > associated with the individual captures within a capture scene entry > concurrently. This would also need to be reflected in any simultaneous se= t > entries. This seems to be a place for possible inconsistencies because th= e > data would effectively be duplicated. > > > > Adding this restriction, to not allow multiple capture scene entries (o= f same > media type, in the same scene) to be used simultaneously is okay with me, > but I don't think it really simplifies much. > > > > As others have said, allowing a consumer to choose a subset of captures > from a capture scene entry makes sense to me too. > > > > I have a few more comments about the proposals inline below. > > > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Christian Groves > >> Sent: Thursday, November 22, 2012 10:56 PM > >> To: clue@ietf.org > >> Subject: [clue] Capture scene clarifications > >> > >> > >> Hello, > >> > >> Paul K reminded me that I have an action point from the interim > >> meeting regarding my draft . > >> At the meeting it seems that there was general agreement with the > >> intent of the > >> proposals: > >> a) A scene represents an area where the capture devices are > >> spatially related, i.e. a presentation that shares no spa= tial > >> relation with a video is a separate scene. > >> > >> b) A capture scene entry thus represents alternate > >> representations of a complete scene. The provider is the= one > >> that determines what a complete scene is. A consumer cho= ses > >> a capture scene entry from the scene in the knowledge tha= t it > >> represents the entire scene. > >> > >> d) A consumer shall chose a capture scene entry rather than > >> choosing individual captures from multiple entries. This > >> does not mean that an consuming endpoint must render all = the > >> captures. What is locally rendered and how is a local > >> decision. > >> > >> I think the framework draft could be enhanced in a few places to make > >> the intent of CLUE clearer. Below are some suggested updates. > >> > >> 1) Introduce a new definition for "Scene". The capture scene > >> definition and several places mention "scene" but there's no > >> explanation. I propose the following definition to be added to section= 3 of > the draft: > >> Scene: Represents an area where the capture devices are spatially > related. > >> Non-spatially related devices exist in different scenes. > > [Duckworth, Mark] Sounds good. > > > >> 2) Update the definition of "Capture scene entry" to make it clearer > >> that it represents an entire scene. Proposed text is: > >> *Capture Scene Entry: a list of media captures of the same media type > >> that together form one representation of an entire capture scene. > > [Duckworth, Mark] Sounds good. > > > >> 3) Update section 6.2 on Capture scenes to reflect the above intents. > >> Changes proposals are: > >> - Section 6.2 2nd paragraph: > >> "A capture scene is a structure representing the <> scene that= is > >> captured by a collection of<>capture devices. > >> A capture scene..." > > [Duckworth, Mark] Sounds good. > > > >> - Section 6.2 3rd paragraph: > >> "A provider may advertise multiple capture scenes or just a single > >> capture scene.< >> provider.>> A media provider might typically use one capture > >> scene for main participant media and another capture scene for a > >> computer generated presentation...." > > [Duckworth, Mark] sounds good > > > >> - Section 6.2 4th paragraph: > >> "A media provider arranges media captures in a capture scene to help > >> the media consumer choose which captures it wants. The capture > scene > >> entries in a capture scene are different alternatives the provide= r is > >> suggesting for representing the entire capture scene. >> rest of > >> paragraph>". > >> > >> - Section 6.2 5th paragraph: > >> "Media captures within the same capture scene entry must be of the > >> same media type - it is not possible to mix audio and video captu= res > >> in the same capture scene entry, for instance. The provider must= be > >> capable of encoding and sending all media captures in a single en= try > >> simultaneously." > >> > >> - section 6.2 New paragraph dealing with consumer behaviour after the > >> 7th paragraph. > >> "A consumer may receive an advertisement with multiple capture > scenes. > >> A consumer may choose to receive any number of capture scenes. An > >> advertised capture scene it may contain one of more capture scene > >> entries that may contain one of more media captures. A consumer may > >> choose an capture scene entry in the knowledge that it is a complete > >> representation of the scene for a particular media type and that all > >> media captures are spatially related. For a particular media type the > >> consumer shall choose one capture scene entry rather than choosing > >> individual captures from multiple capture scene entries. However this > >> does not mean that a consuming endpoint must render all the media > >> captures. What is locally rendered and how is a local decision." > > [Duckworth, Mark] These three proposed changes above are related to not > allowing multiple capture scene entries, of the same media type, in the s= ame > scene, from being used simultaneously. I could go either way on this cha= nge, > whatever the group decides. > > > >> 4) The framework uses the terms "media provider" and "provider". We > >> probably should be consistent in the use of the term throughout the > >> framework. > > [Duckworth, Mark] sounds good. > > > >> 5) Related to the "capture group" concept that didn't seem to get > >> support is the ordering in the Capture scene, Capture scene entry, Med= ia > captures. > >> There was some discussion that people had assumed some sort of > >> prioritisation / ordering related to these structures. i.e. If I have > >> a capture scene entry VC0, VC1, VC2 do I assume they should be > >> rendered left to right or is there nothing to be assumed? I take it > >> is the later understanding put I didn't see anything in the framework > >> regarding what should be assumed. We probably should also add > something for that. > > [Duckworth, Mark] From the framework: "Determination of the order of > these captures (VC0, VC1 and VC2) for rendering purposes is accomplished > through use of their Area of Capture attributes." I don't know what othe= r > type or order or prioritization you might be talking about here. > [CNG] One aspect is the "spatial ordering" i.e. how something is rendered > the other aspect is regarding how the consumer interprets the order of > scene/capture scene entry/capture within the message. i.e. Is the first > capture scene entry more important than the last entry? There has been > some discussion previously that some people that the provider of the > advertisement could provide some prioritisation hint to the consumer by > ordering the list of capture scene entries. From the text you mentioned > aspect is there a general conclusion that there is no prioritisation impl= ied > from the ordering of elements in the advertisement? > > > >> Thoughts? > >> > >> Regards, Christian > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From roberta.presta@unina.it Mon Dec 3 10:58:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67ED721F885B for ; Mon, 3 Dec 2012 10:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxUt5fL9hMvk for ; Mon, 3 Dec 2012 10:58:24 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9F61521F8891 for ; Mon, 3 Dec 2012 10:58:23 -0800 (PST) Received: from [127.0.0.1] ([143.225.229.193]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id qB3IwJZP017515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Dec 2012 19:58:20 +0100 Message-ID: <50BCF64B.9020909@unina.it> Date: Mon, 03 Dec 2012 19:58:19 +0100 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121203-0, 03/12/2012), Outbound message X-Antivirus-Status: Clean Subject: [clue] simultaneous 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: Mon, 03 Dec 2012 18:58:24 -0000 Hi all, I have a couple of questions about the use of simultaneous sets. I have a camera that can be used to capture (i) a zoomed-out view of the telepresence room (say VC1) and a (ii) moving zoomed-in view of the current speaker (say VC2). VC1 and VC2 can not clearly be sent simultaneously, then they never appear in the same simultaneous set. Question nr1: If I listed all the possible simultaneous sets, should I have to provide all the possible combinations of captures without having together VC1 and VC2? Question nr2: What I understand is that simultaneity constraints that would be expressed by using simultaneous sets are mainly related to the impossibility of sending simultaneously different captures that are captured by the same device. Is it the only motivation because of which the simultaneous sets have been designed? Indeed, other constraints related to the simultaneous sending of multiple captures can be deduced using the encodings bandwidth information. If the answer to Question nr2 is "no", can you please provide other cases in which simultaneous sets are needed (Question nr3)? They are not reported in the framework document. Otherwise, If the answer to Question nr2 is "yes", maybe there is an easier way to handle the issue. We can think of providing a description of capture devices in a scene, and then link the captures to their capture device. It goes straightforward that two captures of the same media type taken from the same capture device can not be sent simultaneously. In other words, we can convey information about which captures are mutually exclusive rather than provide possible alternatives of simultaneous captures. Cheers, Roberta Il 03/12/2012 18:27, Duckworth, Mark ha scritto: > Hello Christian, > > I agree the framework (or other document, after refactoring) needs to be clear about whether expressing simultaneous transmission sets is mandatory or not. Maybe it should be mandatory for the media provider to express a simultaneous transmission set that includes all the media captures, even if it has no restrictions. > > From mary.ietf.barnes@gmail.com Tue Dec 4 09:20: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 04D0621F8C74 for ; Tue, 4 Dec 2012 09:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+dWK8gHX9XL for ; Tue, 4 Dec 2012 09:20:07 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A17BC21F8C72 for ; Tue, 4 Dec 2012 09:20:06 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so3701157lbk.31 for ; Tue, 04 Dec 2012 09:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=pWdLyKz16BIOjsaOw3T4fqBxYuV75ZMc0JSPsLSY9Ss=; b=jkbO8Ul+2TB/yy2LwmyUjwXgBeEdYUC3k2Lg/hMaT6XdL2GA8Gc6PsS/Bl1Oe1hI8a j7V2+v+vhz7gbScqAQHARgQi2iXmxHGXEUH8q9GJr+VLaVP6idWGLoMzfPm1QTqCEspc y3J4QD4idYwKqHHhG11POCtFCk01pmHCgXtAC+flHoRfSrxJZ3QurOzbZIwh7D4jmgwQ YL8LOW3Y+oOw9QOy/BmvZQf61tF3YVwjBuxW72zJyEsurZyM/jwlfXLVN5ix4nMKXoId wpEni29CpdAOATtgv96nOopiBZzRp/R7p6As5o2YjR3wx5TwpqW7oZHKRDN1nfDkHFXy N6XQ== MIME-Version: 1.0 Received: by 10.152.132.3 with SMTP id oq3mr13599094lab.18.1354641605498; Tue, 04 Dec 2012 09:20:05 -0800 (PST) Received: by 10.114.20.41 with HTTP; Tue, 4 Dec 2012 09:20:05 -0800 (PST) Date: Tue, 4 Dec 2012 11:20:05 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Minutes: CLUE Design team Call - Dec 3, 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: Tue, 04 Dec 2012 17:20:08 -0000 Hi all, I have uploaded the minutes for yesterday's design team call: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-121203.txt Mary. From mary.ietf.barnes@gmail.com Tue Dec 4 09:26: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 68FB121F8C7F for ; Tue, 4 Dec 2012 09:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.561 X-Spam-Level: X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl+-EoGaB5en for ; Tue, 4 Dec 2012 09:26:05 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46DA221F8C75 for ; Tue, 4 Dec 2012 09:26:05 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3582832lah.31 for ; Tue, 04 Dec 2012 09:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oFs2+i/B65wVQjtn8jJ7ZXzNr387PTYHC2ycHcZyLt8=; b=XXKKB0iCk2YTaBPw09R6H7PS9WJBgq6XdYtnmatelSqhExg/H5bSLNh2Lin48fJ/oS BTGP7aQv8qecnFkl02FOH/pCBJucSvK9OuPqQUAP9IftxzBsj8RYwvaJXk6TuZAqgjm0 yWbmt1kBaNeIaBl3jx3yFVPDMlgVM2XQjv5xKhOlD+BCWFRMzv21AMQi09uDojVD7EDW 8QIdT3YE3vZ8uHY/yBcZVtPAgZzv662TODH9/SQj6K0gcT3yRfCLdfMckIWwrFfIiHMZ k88MzwpMjSwXWNadj5DhgPZgTLpojoirJ3psUV1jcrs5Bc3bt4u4bf1Ankunt9BKQLy7 TmRA== MIME-Version: 1.0 Received: by 10.112.44.225 with SMTP id h1mr6313433lbm.63.1354641964209; Tue, 04 Dec 2012 09:26:04 -0800 (PST) Received: by 10.114.20.41 with HTTP; Tue, 4 Dec 2012 09:26:04 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Dec 2012 11:26:04 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [clue] Subject matter for Monday's call 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, 04 Dec 2012 17:26:06 -0000 Hi all, Per the meeting notes that were just posted, this proposal and concepts will be incorporated into the WG framework document. So, we will revisit this topic in the context of the framework document updates which will hopefully be out within the next couple weeks. Regards, Mary CLUE WG co-chair On Sat, Dec 1, 2012 at 10:56 AM, Stephan Wenger wrote: > Hi all, > > Mark, Andy, and myself had a bit of brainstorming how to most productivel= y > use our time during the Monday morning call. Due to travel and vacation > schedule, our coordination was finalized call only late Friday. Which ma= y > serve as an explanation, if not as an excuse, for the late timing of this > email. > > In our opinion, the most pressing issue we have with the framework docume= nt > is it being agnostic to the protocol elements used to convey the various > messages that are part of the framework. Clearly, the framework was writ= ten > from a perspective where a CLUE protocol channel would be established, an= d > (all?) further signaling would be dealt with over that channel. So is, m= ore > or less, the call flow doc. We believe that there was sufficient pushbac= k > against that idea to make rapid progress based on this assumption unlikel= y. > Accordingly, we believe that we probably best spend most of our time by > discussing a strawman for a split-up between SDP-represented, SIP-ish, > Offer-Answer, =85, that type of traditional messages, and (XML-coded) mes= sages > sent over the CLUE. The focus of our Monday call would be on the initial > exchange, rather than any updates that may happen during a call. > > With reference to the call flow 02 doc > (https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include_t= ext=3D1) > that exchange could look as follows: > > Invite from Alice, just like A.1 in call-flow-02 > 200 OK from Bob, A.2 > CLUE Advertisement Alice A.3, covering geometry stuff, encoding groups, e= tc. > CLUE Advertisement Bob A.4; note that 3 and 4 would in practice overlap i= n > time > CLUE Response from Alice A.5, with the difference that these reposes DO N= OT > have the side effect of initiating any media channel related activity; th= ey > are pure signaling > CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in time. > Re-invite from Alice and Bob, respectively, with media channels as > CLUE-"negotiated" > 200 OK from Bob, Alice. As the endpoints have already established their > operation points through CLUE, this step will not fail except if an entit= y > not involved in the CLUE negotiation intervenes=97i.e. a middle box doesn= 't > like that call. > > The reason for the existence of step 7, rather than setting up media > channels as side effect of steps 3 through 6 (as assumed in call flow and= in > the current framework doc) is twofold: easier integration into the source > base of media codecs that currently use SDP for the selection of their > parameters, and making middlebox people happy. > > The reason for the existence of steps 3 through 6 is our agreement that n= ot > all useful protocol elements envisioned in the framework can be reasonabl= y > and meaningfully implemented in SDP extensions. This is certainly true f= or > the geometry stuff. > > The reason for keeping an encoding group concept in CLUE is that a > representation of the information that can be conveyed through individual > encoding descriptions, encoding groups, and the association of media > captures with encoding groups (section 7 and 8 of the framework) purely > through grouped m-lines would lead to bloated (if not exploded :-) SDP, > quite possibly well beyond a reasonable size (i.e. MTU size); the high le= vel > of abstraction offered by concepts such as encoding groups, simultaneous > transmission sets, and so on, makes for a very compact representation > compared to listing all possible permutations of alternative choices in > grouped m-lines. > > Does such a mechanism make at least initial sense? Should it be fleshed = out > and put into the framework? > > Stephan > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From apeppere@gmail.com Tue Dec 4 09:32: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 809D321F8C56 for ; Tue, 4 Dec 2012 09:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eC12yEWhMYlL for ; Tue, 4 Dec 2012 09:32:10 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7212621F8C60 for ; Tue, 4 Dec 2012 09:32:10 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so1090213qan.10 for ; Tue, 04 Dec 2012 09:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=32RUXjXGJg9XbNLgwf4oJCoK1nBRp0WMmqqR46dLAjM=; b=lpCaJ4QBH/KU3Rh5tmCw8vx+gLiKHR/R61XFqmD8H09ueUrc050GTYS1CZMjKbGtEQ CONyoMzV530BQeBTwudeK78ypmSlDAQKTgX+DLeVBRuwWrI/pKzmPnZ9EPgxm3vSINGN vPcOm2p8wvYXjSedMe0nFkxrtSRTsjFHqv/fKB4VlfeJjsnPMbiN9UwrXWBAMt51+sjB k5vvbmdjF3Lybad6SQaFlT1r90ikFaSe3NvA+AphXSV76NlH2ndK3sXTnruJfJW3g7dq JHV78apSDSlrzp34YqZvKx02ltYADdE6raxH9jcGKOfU+OZcfRfdEZHljW4AYFzouGC3 2zqw== MIME-Version: 1.0 Received: by 10.49.132.199 with SMTP id ow7mr9566732qeb.56.1354642329919; Tue, 04 Dec 2012 09:32:09 -0800 (PST) Received: by 10.49.62.131 with HTTP; Tue, 4 Dec 2012 09:32:09 -0800 (PST) In-Reply-To: <50BCF64B.9020909@unina.it> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50BCF64B.9020909@unina.it> Date: Tue, 4 Dec 2012 17:32:09 +0000 Message-ID: From: Andy Pepperell To: Roberta Presta Content-Type: multipart/alternative; boundary=047d7bf164aedf622404d00a3e47 Cc: clue@ietf.org Subject: Re: [clue] simultaneous 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: Tue, 04 Dec 2012 17:32:11 -0000 --047d7bf164aedf622404d00a3e47 Content-Type: text/plain; charset=ISO-8859-1 Hi Roberta, We had 2 main use cases in mind when thinking about the simultaneity restrictions of media captures. - the first is the one you mention, multiple media captures that use the same physical device with, say, different P/T/Z values, which cannot be provided at the same time - the second case was for something like a switched or transcoded MCU which might provide 1, 2, 3 and 4 capture alternate views of a conference, but might not want to be obliged to provide, say, the leftmost capture of 2 and the centre capture of 3 simultaneously. As part of the framework, we thought a little about the best way to express these restrictions; the first case lends itself well to a small number of small simultaneous transmission sets, which each set listing just the captures that cannot be provided together. Our feeling was that listing all of the sets which *could* be provided together could lead to a combinatorial explosion as every pair of captures which had a restriction would essentially double the number of possible sets that would need listing out - we also felt that this would make consumer-side behavior potentially more complex as the consumer would have to look through a large number of sets and couldn't assume that those sets were just a long hand version of a few [typically] binary choices. >Roberta: We can think of providing a description of capture devices in a scene, and then link the captures to their capture device. >Roberta: In other words, we can convey information about which captures are mutually exclusive rather than provide possible alternatives of simultaneous captures. Yes, I think all of the above is basically agreeing with your points, though we thought it useful to not introduce the notion of physical devices and the mapping of the more abstract capture devices onto them, as there are lots of cases where there might not be such physical devices (e.g. an MCU, or playing back from a recording). To my thinking, all of the benefit of this approach is achieved by having the abstract sets of captures which cannot be provided together, with the additional benefit that systems sufficiently simple to have no such restrictions could just omit these sets completely. The hypothesised MCU case above where 1, 2, 3 and 4 capture versions of the same scene were desired not to be provided together is more problematic with this idea though, and that case would seem to work better in an environment where the sets of captures that *could* be provided together were listed, instead of sets of captures that could not. However, we felt that this was likely to be less common... Hope this helps, Andy On Mon, Dec 3, 2012 at 6:58 PM, Roberta Presta wrote: > Hi all, > > I have a couple of questions about the use of simultaneous sets. > I have a camera that can be used to capture (i) a zoomed-out view of the > telepresence room (say VC1) and a (ii) moving zoomed-in view of the > current speaker (say VC2). > VC1 and VC2 can not clearly be sent simultaneously, then they never appear > in the same simultaneous set. > > Question nr1: If I listed all the possible simultaneous sets, should I > have to provide all the possible combinations of captures without having > together VC1 and VC2? > > Question nr2: What I understand is that simultaneity constraints that > would be expressed by using simultaneous sets are mainly related to the > impossibility of sending simultaneously different captures that are > captured by the same device. > Is it the only motivation because of which the simultaneous sets have been > designed? > Indeed, other constraints related to the simultaneous sending of multiple > captures can be deduced using the encodings bandwidth information. > > If the answer to Question nr2 is "no", can you please provide other cases > in which simultaneous sets are needed (Question nr3)? They are not reported > in the framework document. > Otherwise, If the answer to Question nr2 is "yes", maybe there is an > easier way to handle the issue. > We can think of providing a description of capture devices in a scene, and > then link the captures to their capture device. > It goes straightforward that two captures of the same media type taken > from the same capture device can not be sent simultaneously. > In other words, we can convey information about which captures are > mutually exclusive rather than provide possible alternatives of > simultaneous captures. > > Cheers, > Roberta > > > Il 03/12/2012 18:27, Duckworth, Mark ha scritto: > >> Hello Christian, >> >> I agree the framework (or other document, after refactoring) needs to be >> clear about whether expressing simultaneous transmission sets is mandatory >> or not. Maybe it should be mandatory for the media provider to express a >> simultaneous transmission set that includes all the media captures, even if >> it has no restrictions. >> >> >> > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --047d7bf164aedf622404d00a3e47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roberta,

We had 2 main use cases in mind when thinkin= g about the simultaneity restrictions of media captures.
- the fi= rst is the one you mention, multiple media captures that use the same physi= cal device with, say, different P/T/Z values, which cannot be provided at t= he same time
- the second case was for something like a switched or transcoded MCU = which might provide 1, 2, 3 and 4 capture alternate views of a conference, = but might not want to be obliged to provide, say, the leftmost capture of 2= and the centre capture of 3 simultaneously.

As part of the framework, we thought a little about the= best way to express these restrictions; the first case lends itself well t= o a small number of small simultaneous transmission sets, which each set li= sting just the captures that cannot be provided together. Our feeling was t= hat listing all of the sets which *could* be provided together could lead t= o a combinatorial explosion as every pair of captures which had a restricti= on would essentially double the number of possible sets that would need lis= ting out - we also felt that this would make consumer-side behavior potenti= ally more complex as the consumer would have to look through a large number= of sets and couldn't assume that those sets were just a long hand vers= ion of a few [typically] binary choices.

>Roberta:=A0We can think of providing a description = of capture devices in a scene, and then link the captures to their capture = device.
>Roberta: In other words, we can =A0convey inform= ation about which captures are mutually exclusive rather than provide possi= ble alternatives of simultaneous captures.

Yes, I think all of the above is basically agreei= ng with your points, though we thought it useful to not introduce the notio= n of physical devices and the mapping of the more abstract capture devices = onto them, as there are lots of cases where there might not be such physica= l devices (e.g. an MCU, or playing back from a recording). To my thinking, = all of the benefit of this approach is achieved by having the abstract sets= of captures which cannot be provided together, with the additional benefit= that systems sufficiently simple to have no such restrictions could just o= mit these sets completely.

The hypothesised MCU case above where 1, 2, 3 and 4 cap= ture versions of the same scene were desired not to be provided together is= more problematic with this idea though, and that case would seem to work b= etter in an environment where the sets of captures that *could* be provided= together were listed, instead of sets of captures that could not. However,= we felt that this was likely to be less common...

Hope this helps,

Andy


On Mon, Dec 3, 2012 at 6:58 PM, Robert= a Presta <roberta.presta@unina.it> wrote:
Hi all,

I have a couple of questions about the use of simultaneous sets.
I have a camera that can be used to capture (i) a zoomed-out view of the te= lepresence room (say VC1) =A0and a (ii) moving zoomed-in view of the curren= t speaker (say VC2).
VC1 and VC2 can not clearly be sent simultaneously, then they never appear = in the same simultaneous set.

Question nr1: If I listed all the possible simultaneous sets, should I have= to provide all the possible combinations of captures without having togeth= er VC1 and VC2?

Question nr2: What I understand is that simultaneity constraints that would= be expressed by using simultaneous sets are mainly related to the impossib= ility of sending simultaneously different captures that are captured by the= same device.
Is it the only motivation because of which the simultaneous sets have been = designed?
Indeed, other constraints related to the simultaneous sending of multiple c= aptures can be deduced using the encodings bandwidth information.

If the answer to Question nr2 is "no", can you please provide oth= er cases in which simultaneous sets are needed (Question nr3)? They are not= reported in the framework document.
Otherwise, If the answer to Question nr2 is "yes", maybe there is= an easier way to handle the issue.
We can think of providing a description of capture devices in a scene, and = then link the captures to their capture device.
It goes straightforward that two captures of the same media type taken from= the same capture device can not be sent simultaneously.
In other words, we can =A0convey information about which captures are mutua= lly exclusive rather than provide possible alternatives of simultaneous cap= tures.

Cheers,
Roberta


Il 03/12/2012 18:27, Duckworth, Mark ha scritto:
Hello Christian,

I agree the framework (or other document, after refactoring) needs to be cl= ear about whether expressing simultaneous transmission sets is mandatory or= not. =A0Maybe it should be mandatory for the media provider to express a s= imultaneous transmission set that includes all the media captures, even if = it has no restrictions.



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

--047d7bf164aedf622404d00a3e47-- From Mark.Duckworth@polycom.com Tue Dec 4 10:42: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 8541921F8CA2 for ; Tue, 4 Dec 2012 10:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-b+E1vy3BuS for ; Tue, 4 Dec 2012 10:41:57 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2093421F8BE1 for ; Tue, 4 Dec 2012 10:41:56 -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, 4 Dec 2012 10:41:52 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 4 Dec 2012 10:41:49 -0800 Thread-Topic: [clue] simultaneous sets Thread-Index: Ac3SRVgYJ68Rd4FpQI6KCqbkRAxtnQACR10w Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61039186416E@CRPMBOXPRD01.polycom.com> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50BCF64B.9020909@unina.it> 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_44C6B6B2D0CF424AA90B6055548D7A61039186416ECRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] simultaneous 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: Tue, 04 Dec 2012 18:42:00 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A61039186416ECRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We discussed at IETF83 the different ways of representing the simultaneous = sets - either by what can be used simultaneously, or by what is mutually ex= clusive. According to the minutes, we didn't come to any consensus to change what = was already in the framework (which is to use sets of what can be provided = simultaneously). This is the same as the current framework. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of And= y Pepperell Sent: Tuesday, December 04, 2012 12:32 PM To: Roberta Presta Cc: clue@ietf.org Subject: Re: [clue] simultaneous sets Hi Roberta, We had 2 main use cases in mind when thinking about the simultaneity restri= ctions of media captures. - the first is the one you mention, multiple media captures that use the sa= me physical device with, say, different P/T/Z values, which cannot be provi= ded at the same time - the second case was for something like a switched or transcoded MCU which= might provide 1, 2, 3 and 4 capture alternate views of a conference, but m= ight not want to be obliged to provide, say, the leftmost capture of 2 and = the centre capture of 3 simultaneously. As part of the framework, we thought a little about the best way to express= these restrictions; the first case lends itself well to a small number of = small simultaneous transmission sets, which each set listing just the captu= res that cannot be provided together. Our feeling was that listing all of t= he sets which *could* be provided together could lead to a combinatorial ex= plosion as every pair of captures which had a restriction would essentially= double the number of possible sets that would need listing out - we also f= elt that this would make consumer-side behavior potentially more complex as= the consumer would have to look through a large number of sets and couldn'= t assume that those sets were just a long hand version of a few [typically]= binary choices. >Roberta: We can think of providing a description of capture devices in a s= cene, and then link the captures to their capture device. >Roberta: In other words, we can convey information about which captures a= re mutually exclusive rather than provide possible alternatives of simultan= eous captures. Yes, I think all of the above is basically agreeing with your points, thoug= h we thought it useful to not introduce the notion of physical devices and = the mapping of the more abstract capture devices onto them, as there are lo= ts of cases where there might not be such physical devices (e.g. an MCU, or= playing back from a recording). To my thinking, all of the benefit of this= approach is achieved by having the abstract sets of captures which cannot = be provided together, with the additional benefit that systems sufficiently= simple to have no such restrictions could just omit these sets completely. The hypothesised MCU case above where 1, 2, 3 and 4 capture versions of the= same scene were desired not to be provided together is more problematic wi= th this idea though, and that case would seem to work better in an environm= ent where the sets of captures that *could* be provided together were liste= d, instead of sets of captures that could not. However, we felt that this w= as likely to be less common... Hope this helps, Andy On Mon, Dec 3, 2012 at 6:58 PM, Roberta Presta > wrote: Hi all, I have a couple of questions about the use of simultaneous sets. I have a camera that can be used to capture (i) a zoomed-out view of the te= lepresence room (say VC1) and a (ii) moving zoomed-in view of the current = speaker (say VC2). VC1 and VC2 can not clearly be sent simultaneously, then they never appear = in the same simultaneous set. Question nr1: If I listed all the possible simultaneous sets, should I have= to provide all the possible combinations of captures without having togeth= er VC1 and VC2? Question nr2: What I understand is that simultaneity constraints that would= be expressed by using simultaneous sets are mainly related to the impossib= ility of sending simultaneously different captures that are captured by the= same device. Is it the only motivation because of which the simultaneous sets have been = designed? Indeed, other constraints related to the simultaneous sending of multiple c= aptures can be deduced using the encodings bandwidth information. If the answer to Question nr2 is "no", can you please provide other cases i= n which simultaneous sets are needed (Question nr3)? They are not reported = in the framework document. Otherwise, If the answer to Question nr2 is "yes", maybe there is an easier= way to handle the issue. We can think of providing a description of capture devices in a scene, and = then link the captures to their capture device. It goes straightforward that two captures of the same media type taken from= the same capture device can not be sent simultaneously. In other words, we can convey information about which captures are mutuall= y exclusive rather than provide possible alternatives of simultaneous captu= res. Cheers, Roberta Il 03/12/2012 18:27, Duckworth, Mark ha scritto: Hello Christian, I agree the framework (or other document, after refactoring) needs to be cl= ear about whether expressing simultaneous transmission sets is mandatory or= not. Maybe it should be mandatory for the media provider to express a sim= ultaneous transmission set that includes all the media captures, even if it= has no restrictions. _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_44C6B6B2D0CF424AA90B6055548D7A61039186416ECRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We discus= sed at IETF83 the different ways of representing the simultaneous sets R= 11; either by what can be used simultaneously, or by what is mutually exclu= sive.  According to the minutes, we didn’t come to any co= nsensus to change what was already in the framework (which is to use sets o= f what can be provided simultaneously).  This is the same as the curre= nt framework.

 <= /o:p>

Mark

 

<= p class=3DMsoNormal>From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org= ] On Behalf Of Andy Pepperell
Sent: Tuesday, December 04, = 2012 12:32 PM
To: Roberta Presta
Cc: clue@ietf.org
<= b>Subject: Re: [clue] simultaneous sets

 

Hi Roberta= ,

 

<= p class=3DMsoNormal>We had 2 main use cases in mind when thinking about the= simultaneity restrictions of media captures.

- the first is the one you mention, multiple media capture= s that use the same physical device with, say, different P/T/Z values, whic= h cannot be provided at the same time

- the second case was for something like a switched or transcoded = MCU which might provide 1, 2, 3 and 4 capture alternate views of a conferen= ce, but might not want to be obliged to provide, say, the leftmost capture = of 2 and the centre capture of 3 simultaneously.

<= p class=3DMsoNormal> 

As= part of the framework, we thought a little about the best way to express t= hese restrictions; the first case lends itself well to a small number of sm= all simultaneous transmission sets, which each set listing just the capture= s that cannot be provided together. Our feeling was that listing all of the= sets which *could* be provided together could lead to a combinatorial expl= osion as every pair of captures which had a restriction would essentially d= ouble the number of possible sets that would need listing out - we also fel= t that this would make consumer-side behavior potentially more complex as t= he consumer would have to look through a large number of sets and couldn't = assume that those sets were just a long hand version of a few [typically] b= inary choices.

 

>Roberta: We can think of pr= oviding a description of capture devices in a scene, and then link the capt= ures to their capture device.

>Roberta: In other words, we can  convey information about wh= ich captures are mutually exclusive rather than provide possible alternativ= es of simultaneous captures.

 

Yes, I think all= of the above is basically agreeing with your points, though we thought it = useful to not introduce the notion of physical devices and the mapping of t= he more abstract capture devices onto them, as there are lots of cases wher= e there might not be such physical devices (e.g. an MCU, or playing back fr= om a recording). To my thinking, all of the benefit of this approach is ach= ieved by having the abstract sets of captures which cannot be provided toge= ther, with the additional benefit that systems sufficiently simple to have = no such restrictions could just omit these sets completely.

<= /div>

 

The hypothesised MCU case above where 1, 2, 3 and 4 capture versio= ns of the same scene were desired not to be provided together is more probl= ematic with this idea though, and that case would seem to work better in an= environment where the sets of captures that *could* be provided together w= ere listed, instead of sets of captures that could not. However, we felt th= at this was likely to be less common...

 

Hope this= helps,

 

=

Andy

 

On Mon, Dec 3, 2012 at 6:58 PM, Roberta Presta <roberta.presta@unina.it> wrote:

Hi all,

I have a co= uple of questions about the use of simultaneous sets.
I have a camera th= at can be used to capture (i) a zoomed-out view of the telepresence room (s= ay VC1)  and a (ii) moving zoomed-in view of the current speaker (say = VC2).
VC1 and VC2 can not clearly be sent simultaneously, then they neve= r appear in the same simultaneous set.

Question nr1: If I listed all= the possible simultaneous sets, should I have to provide all the possible = combinations of captures without having together VC1 and VC2?

Questi= on nr2: What I understand is that simultaneity constraints that would be ex= pressed by using simultaneous sets are mainly related to the impossibility = of sending simultaneously different captures that are captured by the same = device.
Is it the only motivation because of which the simultaneous sets= have been designed?
Indeed, other constraints related to the simultaneo= us sending of multiple captures can be deduced using the encodings bandwidt= h information.

If the answer to Question nr2 is "no", can = you please provide other cases in which simultaneous sets are needed (Quest= ion nr3)? They are not reported in the framework document.
Otherwise, If= the answer to Question nr2 is "yes", maybe there is an easier wa= y to handle the issue.
We can think of providing a description of captur= e devices in a scene, and then link the captures to their capture device.It goes straightforward that two captures of the same media type taken fr= om the same capture device can not be sent simultaneously.
In other word= s, we can  convey information about which captures are mutually exclus= ive rather than provide possible alternatives of simultaneous captures.
=
Cheers,
Roberta


Il 03/12/2012 18:27, Duckworth, Mark ha s= critto:

H= ello Christian,

I agree the framework (or other document, after refa= ctoring) needs to be clear about whether expressing simultaneous transmissi= on sets is mandatory or not.  Maybe it should be mandatory for the med= ia provider to express a simultaneous transmission set that includes all th= e media captures, even if it has no restrictions.


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

=

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A61039186416ECRPMBOXPRD01p_-- From Christian.Groves@nteczone.com Thu Dec 6 16:28: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 483D621F862C for ; Thu, 6 Dec 2012 16:28:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFvTyWoYpc3X for ; Thu, 6 Dec 2012 16:28:44 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF7221F8624 for ; Thu, 6 Dec 2012 16:28:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkACAMw2wVB20ZFJ/2dsb2JhbAANN4NHuwqDEQEBAQQBAQE1GxUGCgEQCw4KCRYIBwkDAgECARUfEQYNAQUCAQGIGK8Tk1MEjDmEQwOpUQ Received: from ppp118-209-145-73.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.145.73]) by ipmail06.adl6.internode.on.net with ESMTP; 07 Dec 2012 10:58:41 +1030 Message-ID: <50C13832.7060700@nteczone.com> Date: Fri, 07 Dec 2012 11:28:34 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andy Pepperell References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50BCF64B.9020909@unina.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] simultaneous 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: Fri, 07 Dec 2012 00:28:45 -0000 Hello, Please see my replies below. Regards, Christian On 5/12/2012 4:32 AM, Andy Pepperell wrote: > Hi Roberta, > > We had 2 main use cases in mind when thinking about the simultaneity > restrictions of media captures. > - the first is the one you mention, multiple media captures that use > the same physical device with, say, different P/T/Z values, which > cannot be provided at the same time > - the second case was for something like a switched or transcoded MCU > which might provide 1, 2, 3 and 4 capture alternate views of a > conference, but might not want to be obliged to provide, say, the > leftmost capture of 2 and the centre capture of 3 simultaneously. > > As part of the framework, we thought a little about the best way to > express these restrictions; the first case lends itself well to a > small number of small simultaneous transmission sets, which each set > listing just the captures that cannot be provided together. Our > feeling was that listing all of the sets which *could* be provided > together could lead to a combinatorial explosion as every pair of > captures which had a restriction would essentially double the number > of possible sets that would need listing out - we also felt that this > would make consumer-side behavior potentially more complex as the > consumer would have to look through a large number of sets and > couldn't assume that those sets were just a long hand version of a few > [typically] binary choices. [CNG] But doesn't the framework specify which captures CAN be sent together? i.e. from sect 6.3 "Simultaneous transmission sets are expressed as sets of the MCs that could physically be transmitted at the same time, (though it may not make sense to do so). > > >Roberta: We can think of providing a description of capture devices > in a scene, and then link the captures to their capture device. > >Roberta: In other words, we can convey information about which > captures are mutually exclusive rather than provide possible > alternatives of simultaneous captures. > > Yes, I think all of the above is basically agreeing with your points, > though we thought it useful to not introduce the notion of physical > devices and the mapping of the more abstract capture devices onto > them, as there are lots of cases where there might not be such > physical devices (e.g. an MCU, or playing back from a recording). To > my thinking, all of the benefit of this approach is achieved by having > the abstract sets of captures which cannot be provided together, with > the additional benefit that systems sufficiently simple to have no > such restrictions could just omit these sets completely. [CNG] I agree I think its better to use an abstract concept. > > The hypothesised MCU case above where 1, 2, 3 and 4 capture versions > of the same scene were desired not to be provided together is more > problematic with this idea though, and that case would seem to work > better in an environment where the sets of captures that *could* be > provided together were listed, instead of sets of captures that could > not. However, we felt that this was likely to be less common... > > Hope this helps, > > Andy > > > On Mon, Dec 3, 2012 at 6:58 PM, Roberta Presta > > wrote: > > Hi all, > > I have a couple of questions about the use of simultaneous sets. > I have a camera that can be used to capture (i) a zoomed-out view > of the telepresence room (say VC1) and a (ii) moving zoomed-in > view of the current speaker (say VC2). > VC1 and VC2 can not clearly be sent simultaneously, then they > never appear in the same simultaneous set. > > Question nr1: If I listed all the possible simultaneous sets, > should I have to provide all the possible combinations of captures > without having together VC1 and VC2? > > Question nr2: What I understand is that simultaneity constraints > that would be expressed by using simultaneous sets are mainly > related to the impossibility of sending simultaneously different > captures that are captured by the same device. > Is it the only motivation because of which the simultaneous sets > have been designed? > Indeed, other constraints related to the simultaneous sending of > multiple captures can be deduced using the encodings bandwidth > information. > > If the answer to Question nr2 is "no", can you please provide > other cases in which simultaneous sets are needed (Question nr3)? > They are not reported in the framework document. > Otherwise, If the answer to Question nr2 is "yes", maybe there is > an easier way to handle the issue. > We can think of providing a description of capture devices in a > scene, and then link the captures to their capture device. > It goes straightforward that two captures of the same media type > taken from the same capture device can not be sent simultaneously. > In other words, we can convey information about which captures > are mutually exclusive rather than provide possible alternatives > of simultaneous captures. > > Cheers, > Roberta > > > Il 03/12/2012 18:27, Duckworth, Mark ha scritto: > > Hello Christian, > > I agree the framework (or other document, after refactoring) > needs to be clear about whether expressing simultaneous > transmission sets is mandatory or not. Maybe it should be > mandatory for the media provider to express a simultaneous > transmission set that includes all the media captures, even if > it has no restrictions. > > > > _______________________________________________ > 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 Thu Dec 6 16:43: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 5139B21F8742 for ; Thu, 6 Dec 2012 16:43:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jamxNLiETuHo for ; Thu, 6 Dec 2012 16:43:19 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 14F4D21F8734 for ; Thu, 6 Dec 2012 16:43:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYEAIo6wVB20ZFJ/2dsb2JhbAANNw6DOblvBAOBFIMRAQEBBAEBATUbGwQGAQwECw4DBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBAYgYrxaTUwSMOYRDA5JQli9S Received: from ppp118-209-145-73.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.145.73]) by ipmail06.adl6.internode.on.net with ESMTP; 07 Dec 2012 11:13:16 +1030 Message-ID: <50C13B9E.1070807@nteczone.com> Date: Fri, 07 Dec 2012 11:43:10 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Paul Kyzivat References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <7594FB04B1934943A5C02806D1A2204B04CBFE@ESESSMB209.ericsson.se> <50BCC6BD.8080904@alum.mit.edu> In-Reply-To: <50BCC6BD.8080904@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Capture scene clarifications 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, 07 Dec 2012 00:43:20 -0000 Hello Paul, It would offer flexibility but is this added flexibility needed? In order to choose multiple capture scene entries the original provider must provide a simultaneous transmission so the MCU knows what it can get (we still don't know if its intended that STSs are mandatory or optional in an advertisement). If there's multiple parties involved with the MCU then the combinations of captures in going to quickly increase I don't know if allowing yet more alternatives is beneficial. Did you have a concrete case in mind? Regards, Christian On 4/12/2012 2:35 AM, Paul Kyzivat wrote: > On 12/3/12 2:53 AM, Christer Holmberg wrote: >> Hi, >> >> I think there are two questions here: >> >> 1) Is it allowed to choose multiple capture scene entries (associated >> with the same scene)? >> 2) Is it allowed to choose, from a given capture scene entry, a >> subset of captures? >> >> Regarding 1), I see very little reasons for allowing it. Of course, >> it shall be possible to receive multiple capture scene entries, >> associated with *different* scenes. A typical example is one entry >> associated with the "room", and one associated with a "presentation". > > I can see how it could be useful for a MCU to do this. > This would give it the flexibility to offer a wider range of choices > in its own advertisements. > > Thanks, > Paul > >> Regarding 2), during the SDP offer/answer, nothing can prevent the >> answerer from rejecting streams associated with specific captures. >> But, I am not sure we need to cover it in the CLUE signaling. In the >> CLUE signaling the answerer indicates which capture scene entry it >> wants - including all captures associated with it. > >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Christian Groves >> Sent: 3. joulukuuta 2012 6:05 >> To: clue@ietf.org >> Subject: Re: [clue] Capture scene clarifications >> >> Hello Mark, >> >> I'm no strongly against being able to select individual captures >> however it seems to me to add complications and I think that if we >> were to continue to go in that direction could benefit from further >> discussion in the framework. >> >> What isn't clear to me in the current framework is whether the >> sending of simultaneous transmission sets is mandatory and if not >> what omitting this part of an advertisement means? >> >> Please see some further replies below. >> >> Regards, Christian >> >> On 2/12/2012 2:18 AM, Duckworth, Mark wrote: >>> Points a) and b) are consistent with the intent of the current >>> framework. Point d) starts to change the intent. The framework >>> allows for a media consumer to receive multiple capture scene >>> entries (regardless of media type) at the same time. I think point >>> d) is proposing we not allow this. I think saying "A consumer shall >>> choose a capture scene entry rather than choosing individual >>> captures from multiple entries" is equivalent to saying "A consumer >>> shall choose at most one capture scene entry (of a particular media >>> type) from any particular capture scene". >>> >>> Such a restriction probably reduces the scenarios in which the >>> provider needs to express simultaneous transmission sets, because >>> some of the simultaneity constraints are now included in the capture >>> scene entries. As others have pointed out, there is still the >>> possibility of simultaneous constraints that apply across multiple >>> capture scenes. >> [CNG] I don't think point d) changes this. The current description of >> capture scene entry says that a provider must be able to send all the >> media associated with the individual captures within a capture scene >> entry concurrently. This would also need to be reflected in any >> simultaneous set entries. This seems to be a place for possible >> inconsistencies because the data would effectively be duplicated. >>> >>> Adding this restriction, to not allow multiple capture scene entries >>> (of same media type, in the same scene) to be used simultaneously is >>> okay with me, but I don't think it really simplifies much. >>> >>> As others have said, allowing a consumer to choose a subset of >>> captures from a capture scene entry makes sense to me too. >>> >>> I have a few more comments about the proposals inline below. >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Christian Groves >>>> Sent: Thursday, November 22, 2012 10:56 PM >>>> To: clue@ietf.org >>>> Subject: [clue] Capture scene clarifications >>>> >>>> >>>> Hello, >>>> >>>> Paul K reminded me that I have an action point from the interim >>>> meeting regarding my draft . >>>> At the meeting it seems that there was general agreement with the >>>> intent of the >>>> proposals: >>>> a) A scene represents an area where the capture devices are >>>> spatially related, i.e. a presentation that shares no >>>> spatial >>>> relation with a video is a separate scene. >>>> >>>> b) A capture scene entry thus represents alternate >>>> representations of a complete scene. The provider is >>>> the one >>>> that determines what a complete scene is. A consumer >>>> choses >>>> a capture scene entry from the scene in the knowledge >>>> that it >>>> represents the entire scene. >>>> >>>> d) A consumer shall chose a capture scene entry rather than >>>> choosing individual captures from multiple entries. >>>> This >>>> does not mean that an consuming endpoint must render >>>> all the >>>> captures. What is locally rendered and how is a local >>>> decision. >>>> >>>> I think the framework draft could be enhanced in a few places to make >>>> the intent of CLUE clearer. Below are some suggested updates. >>>> >>>> 1) Introduce a new definition for "Scene". The capture scene >>>> definition and several places mention "scene" but there's no >>>> explanation. I propose the following definition to be added to >>>> section 3 of the draft: >>>> Scene: Represents an area where the capture devices are spatially >>>> related. >>>> Non-spatially related devices exist in different scenes. >>> [Duckworth, Mark] Sounds good. >>> >>>> 2) Update the definition of "Capture scene entry" to make it clearer >>>> that it represents an entire scene. Proposed text is: >>>> *Capture Scene Entry: a list of media captures of the same media type >>>> that together form one representation of an entire capture >>>> scene. >>> [Duckworth, Mark] Sounds good. >>> >>>> 3) Update section 6.2 on Capture scenes to reflect the above intents. >>>> Changes proposals are: >>>> - Section 6.2 2nd paragraph: >>>> "A capture scene is a structure representing the <> scene >>>> that is >>>> captured by a collection of<>capture devices. >>>> A capture scene..." >>> [Duckworth, Mark] Sounds good. >>> >>>> - Section 6.2 3rd paragraph: >>>> "A provider may advertise multiple capture scenes or just a single >>>> capture scene.<>>> provider.>> A media provider might typically use one capture >>>> scene for main participant media and another capture scene for a >>>> computer generated presentation...." >>> [Duckworth, Mark] sounds good >>> >>>> - Section 6.2 4th paragraph: >>>> "A media provider arranges media captures in a capture scene to help >>>> the media consumer choose which captures it wants. The >>>> capture scene >>>> entries in a capture scene are different alternatives the >>>> provider is >>>> suggesting for representing the entire capture scene.>>> rest of >>>> paragraph>". >>>> >>>> - Section 6.2 5th paragraph: >>>> "Media captures within the same capture scene entry must be of the >>>> same media type - it is not possible to mix audio and video >>>> captures >>>> in the same capture scene entry, for instance. The provider >>>> must be >>>> capable of encoding and sending all media captures in a >>>> single entry >>>> simultaneously." >>>> >>>> - section 6.2 New paragraph dealing with consumer behaviour after the >>>> 7th paragraph. >>>> "A consumer may receive an advertisement with multiple capture >>>> scenes. >>>> A consumer may choose to receive any number of capture scenes. An >>>> advertised capture scene it may contain one of more capture scene >>>> entries that may contain one of more media captures. A consumer may >>>> choose an capture scene entry in the knowledge that it is a complete >>>> representation of the scene for a particular media type and that all >>>> media captures are spatially related. For a particular media type the >>>> consumer shall choose one capture scene entry rather than choosing >>>> individual captures from multiple capture scene entries. However this >>>> does not mean that a consuming endpoint must render all the media >>>> captures. What is locally rendered and how is a local decision." >>> [Duckworth, Mark] These three proposed changes above are related to >>> not allowing multiple capture scene entries, of the same media type, >>> in the same scene, from being used simultaneously. I could go >>> either way on this change, whatever the group decides. >>> >>>> 4) The framework uses the terms "media provider" and "provider". We >>>> probably should be consistent in the use of the term throughout the >>>> framework. >>> [Duckworth, Mark] sounds good. >>> >>>> 5) Related to the "capture group" concept that didn't seem to get >>>> support is the ordering in the Capture scene, Capture scene entry, >>>> Media captures. >>>> There was some discussion that people had assumed some sort of >>>> prioritisation / ordering related to these structures. i.e. If I have >>>> a capture scene entry VC0, VC1, VC2 do I assume they should be >>>> rendered left to right or is there nothing to be assumed? I take it >>>> is the later understanding put I didn't see anything in the framework >>>> regarding what should be assumed. We probably should also add >>>> something for that. >>> [Duckworth, Mark] From the framework: "Determination of the order of >>> these captures (VC0, VC1 and VC2) for rendering purposes is >>> accomplished through use of their Area of Capture attributes." I >>> don't know what other type or order or prioritization you might be >>> talking about here. >> [CNG] One aspect is the "spatial ordering" i.e. how something is >> rendered the other aspect is regarding how the consumer interprets >> the order of scene/capture scene entry/capture within the message. >> i.e. Is the first capture scene entry more important than the last >> entry? There has been some discussion previously that some people >> that the provider of the advertisement could provide some >> prioritisation hint to the consumer by ordering the list of capture >> scene entries. From the text you mentioned aspect is there a general >> conclusion that there is no prioritisation implied from the ordering >> of elements in the advertisement? >>> >>>> Thoughts? >>>> >>>> Regards, Christian >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Thu Dec 6 17:21: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 97DEA21F86CE for ; Thu, 6 Dec 2012 17:21:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zd7nQ2bFSdt for ; Thu, 6 Dec 2012 17:21:25 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 835E621F86B3 for ; Thu, 6 Dec 2012 17:21:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYEALNDwVB20ZFJ/2dsb2JhbAANN4NHuWkEA4EUgxEBAQEEAQEBNRsbBAYBDAQLEQQBAQEJFggHCQMCAQIBFR8JCAYNAQUCAQGIGK8Zk08EjDmEQwOSUJcB Received: from ppp118-209-145-73.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.145.73]) by ipmail06.adl6.internode.on.net with ESMTP; 07 Dec 2012 11:51:22 +1030 Message-ID: <50C1448C.7030000@nteczone.com> Date: Fri, 07 Dec 2012 12:21:16 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Duckworth, Mark" References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 07 Dec 2012 01:21:26 -0000 Hello Mark, With regards to simultaneous sets I think we need to resolve what capture scene entries represent. Currently the framework says that it must be possible to send all captures in a Capture Scene Entry simultaneously. To me logically speaking a capture scene entry is effectively a simultaneous transmission set. To send effectively the same information twice seems to me to be abit of a waste. Related to the above point can different captures types i.e. audio/video/presentation be in one simultaneous transmission set ? I.e. I can send this video with this audio but not with a presentation. This doesn't appear to be addressed in the text. With regards to prioritisation I'm OK with having the framework not imply ordering or prioritisation. After going through the exercise at looking at the capture attributes I think that prioritisation maybe better as a specific attribute if its needed. I think that if you can provide sufficient description of the characteristics of the capture then priority may not be needed. Either way I think we agree that it needs to be made clear in the framework. Regards, Christian On 4/12/2012 4:27 AM, Duckworth, Mark wrote: > Hello Christian, > > I agree the framework (or other document, after refactoring) needs to be clear about whether expressing simultaneous transmission sets is mandatory or not. Maybe it should be mandatory for the media provider to express a simultaneous transmission set that includes all the media captures, even if it has no restrictions. > > About the order of capture scenes, entries within a scene, and captures within an entry - the framework intent was that this order had no significance. But it does seem it might be useful to use the ordering as a prioritization hint from provider to consumer. If we decide we want to do this, we need to make it clear in the framework (or possibly lower level document, if that is where it ends up after refactoring). > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Sunday, December 02, 2012 11:05 PM >> To: clue@ietf.org >> Subject: Re: [clue] Capture scene clarifications >> >> Hello Mark, >> >> I'm no strongly against being able to select individual captures however it >> seems to me to add complications and I think that if we were to continue to >> go in that direction could benefit from further discussion in the framework. >> >> What isn't clear to me in the current framework is whether the sending of >> simultaneous transmission sets is mandatory and if not what omitting this >> part of an advertisement means? >> >> Please see some further replies below. >> >> Regards, Christian >> >> On 2/12/2012 2:18 AM, Duckworth, Mark wrote: >>> Points a) and b) are consistent with the intent of the current framework. >> Point d) starts to change the intent. The framework allows for a media >> consumer to receive multiple capture scene entries (regardless of media >> type) at the same time. I think point d) is proposing we not allow this. I think >> saying "A consumer shall choose a capture scene entry rather than choosing >> individual captures from multiple entries" is equivalent to saying "A >> consumer shall choose at most one capture scene entry (of a particular >> media type) from any particular capture scene". >>> Such a restriction probably reduces the scenarios in which the provider >> needs to express simultaneous transmission sets, because some of the >> simultaneity constraints are now included in the capture scene entries. As >> others have pointed out, there is still the possibility of simultaneous >> constraints that apply across multiple capture scenes. >> [CNG] I don't think point d) changes this. The current description of capture >> scene entry says that a provider must be able to send all the media >> associated with the individual captures within a capture scene entry >> concurrently. This would also need to be reflected in any simultaneous set >> entries. This seems to be a place for possible inconsistencies because the >> data would effectively be duplicated. >>> Adding this restriction, to not allow multiple capture scene entries (of same >> media type, in the same scene) to be used simultaneously is okay with me, >> but I don't think it really simplifies much. >>> As others have said, allowing a consumer to choose a subset of captures >> from a capture scene entry makes sense to me too. >>> I have a few more comments about the proposals inline below. >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Christian Groves >>>> Sent: Thursday, November 22, 2012 10:56 PM >>>> To: clue@ietf.org >>>> Subject: [clue] Capture scene clarifications >>>> >>>> >>>> Hello, >>>> >>>> Paul K reminded me that I have an action point from the interim >>>> meeting regarding my draft . >>>> At the meeting it seems that there was general agreement with the >>>> intent of the >>>> proposals: >>>> a) A scene represents an area where the capture devices are >>>> spatially related, i.e. a presentation that shares no spatial >>>> relation with a video is a separate scene. >>>> >>>> b) A capture scene entry thus represents alternate >>>> representations of a complete scene. The provider is the one >>>> that determines what a complete scene is. A consumer choses >>>> a capture scene entry from the scene in the knowledge that it >>>> represents the entire scene. >>>> >>>> d) A consumer shall chose a capture scene entry rather than >>>> choosing individual captures from multiple entries. This >>>> does not mean that an consuming endpoint must render all the >>>> captures. What is locally rendered and how is a local >>>> decision. >>>> >>>> I think the framework draft could be enhanced in a few places to make >>>> the intent of CLUE clearer. Below are some suggested updates. >>>> >>>> 1) Introduce a new definition for "Scene". The capture scene >>>> definition and several places mention "scene" but there's no >>>> explanation. I propose the following definition to be added to section 3 of >> the draft: >>>> Scene: Represents an area where the capture devices are spatially >> related. >>>> Non-spatially related devices exist in different scenes. >>> [Duckworth, Mark] Sounds good. >>> >>>> 2) Update the definition of "Capture scene entry" to make it clearer >>>> that it represents an entire scene. Proposed text is: >>>> *Capture Scene Entry: a list of media captures of the same media type >>>> that together form one representation of an entire capture scene. >>> [Duckworth, Mark] Sounds good. >>> >>>> 3) Update section 6.2 on Capture scenes to reflect the above intents. >>>> Changes proposals are: >>>> - Section 6.2 2nd paragraph: >>>> "A capture scene is a structure representing the <> scene that is >>>> captured by a collection of<>capture devices. >>>> A capture scene..." >>> [Duckworth, Mark] Sounds good. >>> >>>> - Section 6.2 3rd paragraph: >>>> "A provider may advertise multiple capture scenes or just a single >>>> capture scene.<>>> provider.>> A media provider might typically use one capture >>>> scene for main participant media and another capture scene for a >>>> computer generated presentation...." >>> [Duckworth, Mark] sounds good >>> >>>> - Section 6.2 4th paragraph: >>>> "A media provider arranges media captures in a capture scene to help >>>> the media consumer choose which captures it wants. The capture >> scene >>>> entries in a capture scene are different alternatives the provider is >>>> suggesting for representing the entire capture scene.>>> rest of >>>> paragraph>". >>>> >>>> - Section 6.2 5th paragraph: >>>> "Media captures within the same capture scene entry must be of the >>>> same media type - it is not possible to mix audio and video captures >>>> in the same capture scene entry, for instance. The provider must be >>>> capable of encoding and sending all media captures in a single entry >>>> simultaneously." >>>> >>>> - section 6.2 New paragraph dealing with consumer behaviour after the >>>> 7th paragraph. >>>> "A consumer may receive an advertisement with multiple capture >> scenes. >>>> A consumer may choose to receive any number of capture scenes. An >>>> advertised capture scene it may contain one of more capture scene >>>> entries that may contain one of more media captures. A consumer may >>>> choose an capture scene entry in the knowledge that it is a complete >>>> representation of the scene for a particular media type and that all >>>> media captures are spatially related. For a particular media type the >>>> consumer shall choose one capture scene entry rather than choosing >>>> individual captures from multiple capture scene entries. However this >>>> does not mean that a consuming endpoint must render all the media >>>> captures. What is locally rendered and how is a local decision." >>> [Duckworth, Mark] These three proposed changes above are related to not >> allowing multiple capture scene entries, of the same media type, in the same >> scene, from being used simultaneously. I could go either way on this change, >> whatever the group decides. >>>> 4) The framework uses the terms "media provider" and "provider". We >>>> probably should be consistent in the use of the term throughout the >>>> framework. >>> [Duckworth, Mark] sounds good. >>> >>>> 5) Related to the "capture group" concept that didn't seem to get >>>> support is the ordering in the Capture scene, Capture scene entry, Media >> captures. >>>> There was some discussion that people had assumed some sort of >>>> prioritisation / ordering related to these structures. i.e. If I have >>>> a capture scene entry VC0, VC1, VC2 do I assume they should be >>>> rendered left to right or is there nothing to be assumed? I take it >>>> is the later understanding put I didn't see anything in the framework >>>> regarding what should be assumed. We probably should also add >> something for that. >>> [Duckworth, Mark] From the framework: "Determination of the order of >> these captures (VC0, VC1 and VC2) for rendering purposes is accomplished >> through use of their Area of Capture attributes." I don't know what other >> type or order or prioritization you might be talking about here. >> [CNG] One aspect is the "spatial ordering" i.e. how something is rendered >> the other aspect is regarding how the consumer interprets the order of >> scene/capture scene entry/capture within the message. i.e. Is the first >> capture scene entry more important than the last entry? There has been >> some discussion previously that some people that the provider of the >> advertisement could provide some prioritisation hint to the consumer by >> ordering the list of capture scene entries. From the text you mentioned >> aspect is there a general conclusion that there is no prioritisation implied >> from the ordering of elements in the advertisement? >>>> Thoughts? >>>> >>>> Regards, Christian >>>> _______________________________________________ >>>> 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 Mark.Duckworth@polycom.com Fri Dec 7 12:33: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 842D521F8803 for ; Fri, 7 Dec 2012 12:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQwLFJpmGeLq for ; Fri, 7 Dec 2012 12:33:10 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 04F2921F85F5 for ; Fri, 7 Dec 2012 12:33:09 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 7 Dec 2012 12:33:09 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 7 Dec 2012 12:33:06 -0800 Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3UGS5m2xAdTEm6Q0+wMwdv7yn+4AAn0d9Q Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> In-Reply-To: <50C1448C.7030000@nteczone.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] Capture scene clarifications 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, 07 Dec 2012 20:33:11 -0000 Hi Christian, Responses below. Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Thursday, December 06, 2012 8:21 PM > To: Duckworth, Mark > Cc: clue@ietf.org > Subject: Re: [clue] Capture scene clarifications >=20 > Hello Mark, >=20 > With regards to simultaneous sets I think we need to resolve what capture > scene entries represent. Currently the framework says that it must be > possible to send all captures in a Capture Scene Entry simultaneously. To= me > logically speaking a capture scene entry is effectively a simultaneous > transmission set. To send effectively the same information twice seems to > me to be abit of a waste. [Duckworth, Mark] It isn't supposed to be the same information. The framew= ork says "The simultaneous transmission sets MUST allow all the media captu= res in a particular capture scene entry to be used simultaneously." So all= the media captures from a particular capture scene entry must also appear = together in a simultaneous transmission set. But that simultaneous transmi= ssion set could also include more media captures, not just media captures t= hat appear in the same capture scene entry. > Related to the above point can different captures types i.e. > audio/video/presentation be in one simultaneous transmission set ? I.e. > I can send this video with this audio but not with a presentation. This d= oesn't > appear to be addressed in the text. [Duckworth, Mark] I think the framework intent was that different media typ= es (audio, video, text, ...) have different simultaneous transmission sets.= In other words, the framework doesn't support expressing media provider l= imitations regarding mutual exclusion between media captures of different m= edia types. "Presentation" is not a media type in this sense. > With regards to prioritisation I'm OK with having the framework not imply > ordering or prioritisation. After going through the exercise at looking a= t the > capture attributes I think that prioritisation maybe better as a specific > attribute if its needed. I think that if you can provide sufficient descr= iption of > the characteristics of the capture then priority may not be needed. Eithe= r > way I think we agree that it needs to be made clear in the framework. [Duckworth, Mark] Sounds good to me. It wouldn't hurt to add text that say= s the order capture scenes and the order of capture scene entries has no si= gnificance, either in the framework or a protocol document, depending on ho= w we refactor it. > Regards, Christian >=20 > On 4/12/2012 4:27 AM, Duckworth, Mark wrote: > > Hello Christian, > > > > I agree the framework (or other document, after refactoring) needs to b= e > clear about whether expressing simultaneous transmission sets is mandator= y > or not. Maybe it should be mandatory for the media provider to express a > simultaneous transmission set that includes all the media captures, even = if it > has no restrictions. > > > > About the order of capture scenes, entries within a scene, and captures > within an entry - the framework intent was that this order had no > significance. But it does seem it might be useful to use the ordering as= a > prioritization hint from provider to consumer. If we decide we want to d= o > this, we need to make it clear in the framework (or possibly lower level > document, if that is where it ends up after refactoring). > > > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Christian Groves > >> Sent: Sunday, December 02, 2012 11:05 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] Capture scene clarifications > >> > >> Hello Mark, > >> > >> I'm no strongly against being able to select individual captures > >> however it seems to me to add complications and I think that if we > >> were to continue to go in that direction could benefit from further > discussion in the framework. > >> > >> What isn't clear to me in the current framework is whether the > >> sending of simultaneous transmission sets is mandatory and if not > >> what omitting this part of an advertisement means? > >> > >> Please see some further replies below. > >> > >> Regards, Christian > >> > >> On 2/12/2012 2:18 AM, Duckworth, Mark wrote: > >>> Points a) and b) are consistent with the intent of the current framew= ork. > >> Point d) starts to change the intent. The framework allows for a > >> media consumer to receive multiple capture scene entries (regardless > >> of media > >> type) at the same time. I think point d) is proposing we not allow > >> this. I think saying "A consumer shall choose a capture scene entry > >> rather than choosing individual captures from multiple entries" is > >> equivalent to saying "A consumer shall choose at most one capture > >> scene entry (of a particular media type) from any particular capture > scene". > >>> Such a restriction probably reduces the scenarios in which the > >>> provider > >> needs to express simultaneous transmission sets, because some of the > >> simultaneity constraints are now included in the capture scene > >> entries. As others have pointed out, there is still the possibility > >> of simultaneous constraints that apply across multiple capture scenes. > >> [CNG] I don't think point d) changes this. The current description of > >> capture scene entry says that a provider must be able to send all the > >> media associated with the individual captures within a capture scene > >> entry concurrently. This would also need to be reflected in any > >> simultaneous set entries. This seems to be a place for possible > >> inconsistencies because the data would effectively be duplicated. > >>> Adding this restriction, to not allow multiple capture scene entries > >>> (of same > >> media type, in the same scene) to be used simultaneously is okay with > >> me, but I don't think it really simplifies much. > >>> As others have said, allowing a consumer to choose a subset of > >>> captures > >> from a capture scene entry makes sense to me too. > >>> I have a few more comments about the proposals inline below. > >>> > >>> Mark > >>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>> Behalf Of Christian Groves > >>>> Sent: Thursday, November 22, 2012 10:56 PM > >>>> To: clue@ietf.org > >>>> Subject: [clue] Capture scene clarifications > >>>> > >>>> > >>>> Hello, > >>>> > >>>> Paul K reminded me that I have an action point from the interim > >>>> meeting regarding my draft . > >>>> At the meeting it seems that there was general agreement with the > >>>> intent of the > >>>> proposals: > >>>> a) A scene represents an area where the capture devices a= re > >>>> spatially related, i.e. a presentation that shares no = spatial > >>>> relation with a video is a separate scene. > >>>> > >>>> b) A capture scene entry thus represents alternate > >>>> representations of a complete scene. The provider is = the one > >>>> that determines what a complete scene is. A consumer = choses > >>>> a capture scene entry from the scene in the knowledge = that it > >>>> represents the entire scene. > >>>> > >>>> d) A consumer shall chose a capture scene entry rather th= an > >>>> choosing individual captures from multiple entries. T= his > >>>> does not mean that an consuming endpoint must render a= ll the > >>>> captures. What is locally rendered and how is a local > >>>> decision. > >>>> > >>>> I think the framework draft could be enhanced in a few places to > >>>> make the intent of CLUE clearer. Below are some suggested updates. > >>>> > >>>> 1) Introduce a new definition for "Scene". The capture scene > >>>> definition and several places mention "scene" but there's no > >>>> explanation. I propose the following definition to be added to > >>>> section 3 of > >> the draft: > >>>> Scene: Represents an area where the capture devices are spatially > >> related. > >>>> Non-spatially related devices exist in different scenes. > >>> [Duckworth, Mark] Sounds good. > >>> > >>>> 2) Update the definition of "Capture scene entry" to make it > >>>> clearer that it represents an entire scene. Proposed text is: > >>>> *Capture Scene Entry: a list of media captures of the same media typ= e > >>>> that together form one representation of an entire capture sce= ne. > >>> [Duckworth, Mark] Sounds good. > >>> > >>>> 3) Update section 6.2 on Capture scenes to reflect the above intents= . > >>>> Changes proposals are: > >>>> - Section 6.2 2nd paragraph: > >>>> "A capture scene is a structure representing the <> scene th= at > is > >>>> captured by a collection of<>capture device= s. > >>>> A capture scene..." > >>> [Duckworth, Mark] Sounds good. > >>> > >>>> - Section 6.2 3rd paragraph: > >>>> "A provider may advertise multiple capture scenes or just a sing= le > >>>> capture scene.< >>>> provider.>> A media provider might typically use one capture > >>>> scene for main participant media and another capture scene for= a > >>>> computer generated presentation...." > >>> [Duckworth, Mark] sounds good > >>> > >>>> - Section 6.2 4th paragraph: > >>>> "A media provider arranges media captures in a capture scene to help > >>>> the media consumer choose which captures it wants. The > >>>> capture > >> scene > >>>> entries in a capture scene are different alternatives the prov= ider is > >>>> suggesting for representing the entire capture scene. >>>> rest of > >>>> paragraph>". > >>>> > >>>> - Section 6.2 5th paragraph: > >>>> "Media captures within the same capture scene entry must be of t= he > >>>> same media type - it is not possible to mix audio and video ca= ptures > >>>> in the same capture scene entry, for instance. The provider m= ust be > >>>> capable of encoding and sending all media captures in a single= entry > >>>> simultaneously." > >>>> > >>>> - section 6.2 New paragraph dealing with consumer behaviour after > >>>> the 7th paragraph. > >>>> "A consumer may receive an advertisement with multiple capture > >> scenes. > >>>> A consumer may choose to receive any number of capture scenes. An > >>>> advertised capture scene it may contain one of more capture scene > >>>> entries that may contain one of more media captures. A consumer may > >>>> choose an capture scene entry in the knowledge that it is a > >>>> complete representation of the scene for a particular media type > >>>> and that all media captures are spatially related. For a particular > >>>> media type the consumer shall choose one capture scene entry rather > >>>> than choosing individual captures from multiple capture scene > >>>> entries. However this does not mean that a consuming endpoint must > >>>> render all the media captures. What is locally rendered and how is a > local decision." > >>> [Duckworth, Mark] These three proposed changes above are related to > >>> not > >> allowing multiple capture scene entries, of the same media type, in > >> the same scene, from being used simultaneously. I could go either > >> way on this change, whatever the group decides. > >>>> 4) The framework uses the terms "media provider" and "provider". We > >>>> probably should be consistent in the use of the term throughout the > >>>> framework. > >>> [Duckworth, Mark] sounds good. > >>> > >>>> 5) Related to the "capture group" concept that didn't seem to get > >>>> support is the ordering in the Capture scene, Capture scene entry, > >>>> Media > >> captures. > >>>> There was some discussion that people had assumed some sort of > >>>> prioritisation / ordering related to these structures. i.e. If I > >>>> have a capture scene entry VC0, VC1, VC2 do I assume they should be > >>>> rendered left to right or is there nothing to be assumed? I take it > >>>> is the later understanding put I didn't see anything in the > >>>> framework regarding what should be assumed. We probably should > also > >>>> add > >> something for that. > >>> [Duckworth, Mark] From the framework: "Determination of the order of > >> these captures (VC0, VC1 and VC2) for rendering purposes is > >> accomplished through use of their Area of Capture attributes." I > >> don't know what other type or order or prioritization you might be tal= king > about here. > >> [CNG] One aspect is the "spatial ordering" i.e. how something is > >> rendered the other aspect is regarding how the consumer interprets > >> the order of scene/capture scene entry/capture within the message. > >> i.e. Is the first capture scene entry more important than the last > >> entry? There has been some discussion previously that some people > >> that the provider of the advertisement could provide some > >> prioritisation hint to the consumer by ordering the list of capture > >> scene entries. From the text you mentioned aspect is there a general > >> conclusion that there is no prioritisation implied from the ordering o= f > elements in the advertisement? > >>>> Thoughts? > >>>> > >>>> Regards, Christian > >>>> _______________________________________________ > >>>> 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 christer.holmberg@ericsson.com Mon Dec 10 00: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 7BAE321F86D9 for ; Mon, 10 Dec 2012 00:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FfIIIGQWYvb for ; Mon, 10 Dec 2012 00:32:49 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6F24921F8645 for ; Mon, 10 Dec 2012 00:32:49 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-b9-50c59e2fe330 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 89.FB.24873.F2E95C05; Mon, 10 Dec 2012 09:32:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 09:32:46 +0100 From: Christer Holmberg To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3JLnoSzk8+n3np90eOVjDiWPg3KwGoy/AQAExSlQAAHAv6AACnaFYAACg6MQAAf6TcoA== Date: Mon, 10 Dec 2012 08:32:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvja7BvKMBBlvmMFrsP3WZ2WLdkafM DkweS5b8ZPJ48UApgCmKyyYlNSezLLVI3y6BK2NmZxNTwQ+OipZV/1kaGGexdzFyckgImEjs 276dBcIWk7hwbz1bFyMXh5DAIUaJfTeeMkM4SxglVnc/Ye1i5OBgE7CQ6P6nDdIgIhAqsXrm JrBmYQEDiZMfb7BDxA0lti6Zwwphh0kc27ORDcRmEVCVOPL+PzPIGF4Bb4mmm7YgYSGB40wS 2+aKgticAkESm4+eBBvJCHTP91NrmEBsZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/YJdJCChK LO+XgyjXkViw+xMbhK0tsWzha7ByXgFBiZMzn7BMYBSdhWTqLCQts5C0zELSsoCRZRUje25i Zk56udEmRmAUHNzyW3UH451zIocYpTlYlMR5rbfu8RcSSE8sSc1OTS1ILYovKs1JLT7EyMTB KdXA2LRbTb34zQlH26XGt+v5pj26/9S9ZOXkFS2SFzraXlyufG5m6bTIvYJTSe7Vu40r+Zaa uM3hzX/p8LGuzCFU4oDev7j4D6oh+XVPM8ISjCLY5/5+o+eU+Nyg4FRRzMvlPyJslB809QpZ ORmKh0/9kvXAJji0S/yJ7bIXK/m21p/hac7oeB2rxFKckWioxVxUnAgA5y+xT1ACAAA= Subject: Re: [clue] Capture scene clarifications 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, 10 Dec 2012 08:32:50 -0000 Hi, >> With regards to simultaneous sets I think we need to resolve what=20 >> capture scene entries represent. Currently the framework says that it=20 >> must be possible to send all captures in a Capture Scene Entry=20 >> simultaneously. To me logically speaking a capture scene entry is=20 >> effectively a simultaneous transmission set. To send effectively the=20 >> same information twice seems to me to be abit of a waste. > > [Duckworth, Mark] It isn't supposed to be the same information. The fram= ework says "The simultaneous transmission sets MUST allow all the media cap= tures in a=20 > particular capture scene entry to be used simultaneously." So all the me= dia captures from a particular capture scene entry must also appear togethe= r in a simultaneous=20 > transmission set. But that simultaneous transmission set could also incl= ude more media captures, not just media captures that appear in the same ca= pture scene entry. I agree to the understanding, but I still question the need. Why can't the "additional captures" be part of a dedicated capture scene en= try? Regards, Christer From Christian.Groves@nteczone.com Mon Dec 10 03:11:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8D221F86C3 for ; Mon, 10 Dec 2012 03:11:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3AYOV0uGHED for ; Mon, 10 Dec 2012 03:11:55 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id DE49421F869F for ; Mon, 10 Dec 2012 03:11:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAN7CxVB20cUy/2dsb2JhbAANN4NIuiUEA4ETgxEBAQEDAQEBATUbGwQGAQwECxEEAQEBCRYIBwkDAgECARUfCQgGDQEFAgEBiAcSowySdASMP4FnglwDklOWYSE Received: from ppp118-209-197-50.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.197.50]) by ipmail06.adl2.internode.on.net with ESMTP; 10 Dec 2012 21:41:51 +1030 Message-ID: <50C5C375.9060302@nteczone.com> Date: Mon, 10 Dec 2012 22:11:49 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Duckworth, Mark" References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 10 Dec 2012 11:11:56 -0000 Hello Mark, Please see my response below. Regards, Christian On 8/12/2012 7:33 AM, Duckworth, Mark wrote: > Hi Christian, > > Responses below. > Mark > >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Thursday, December 06, 2012 8:21 PM >> To: Duckworth, Mark >> Cc: clue@ietf.org >> Subject: Re: [clue] Capture scene clarifications >> >> Hello Mark, >> >> With regards to simultaneous sets I think we need to resolve what capture >> scene entries represent. Currently the framework says that it must be >> possible to send all captures in a Capture Scene Entry simultaneously. To me >> logically speaking a capture scene entry is effectively a simultaneous >> transmission set. To send effectively the same information twice seems to >> me to be abit of a waste. > [Duckworth, Mark] It isn't supposed to be the same information. The framework says "The simultaneous transmission sets MUST allow all the media captures in a particular capture scene entry to be used simultaneously." So all the media captures from a particular capture scene entry must also appear together in a simultaneous transmission set. But that simultaneous transmission set could also include more media captures, not just media captures that appear in the same capture scene entry. [CNG] I know its not meant to be the same but it does seem like a large overlap. Particular if the STS doesn't contain additional media captures. This would be likely if the receiver could only choose one entry from a list of capture scene entries. > >> Related to the above point can different captures types i.e. >> audio/video/presentation be in one simultaneous transmission set ? I.e. >> I can send this video with this audio but not with a presentation. This doesn't >> appear to be addressed in the text. > [Duckworth, Mark] I think the framework intent was that different media types (audio, video, text, ...) have different simultaneous transmission sets. In other words, the framework doesn't support expressing media provider limitations regarding mutual exclusion between media captures of different media types. "Presentation" is not a media type in this sense. [CNG] If that is the intent then it should be explicitly captured in the framework text. With regards to the "presentation" not being a media type. I guess this means that when the Content attribute indicates "Slides" this is only valid when the slides are a video stream? i.e. CLUE has no mechanism to indicate a data stream related to a presentation. > >> With regards to prioritisation I'm OK with having the framework not imply >> ordering or prioritisation. After going through the exercise at looking at the >> capture attributes I think that prioritisation maybe better as a specific >> attribute if its needed. I think that if you can provide sufficient description of >> the characteristics of the capture then priority may not be needed. Either >> way I think we agree that it needs to be made clear in the framework. > [Duckworth, Mark] Sounds good to me. It wouldn't hurt to add text that says the order capture scenes and the order of capture scene entries has no significance, either in the framework or a protocol document, depending on how we refactor it. [CNG] Agreed. > >> Regards, Christian >> >> On 4/12/2012 4:27 AM, Duckworth, Mark wrote: >>> Hello Christian, >>> >>> I agree the framework (or other document, after refactoring) needs to be >> clear about whether expressing simultaneous transmission sets is mandatory >> or not. Maybe it should be mandatory for the media provider to express a >> simultaneous transmission set that includes all the media captures, even if it >> has no restrictions. >>> About the order of capture scenes, entries within a scene, and captures >> within an entry - the framework intent was that this order had no >> significance. But it does seem it might be useful to use the ordering as a >> prioritization hint from provider to consumer. If we decide we want to do >> this, we need to make it clear in the framework (or possibly lower level >> document, if that is where it ends up after refactoring). >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Christian Groves >>>> Sent: Sunday, December 02, 2012 11:05 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Capture scene clarifications >>>> >>>> Hello Mark, >>>> >>>> I'm no strongly against being able to select individual captures >>>> however it seems to me to add complications and I think that if we >>>> were to continue to go in that direction could benefit from further >> discussion in the framework. >>>> What isn't clear to me in the current framework is whether the >>>> sending of simultaneous transmission sets is mandatory and if not >>>> what omitting this part of an advertisement means? >>>> >>>> Please see some further replies below. >>>> >>>> Regards, Christian >>>> >>>> On 2/12/2012 2:18 AM, Duckworth, Mark wrote: >>>>> Points a) and b) are consistent with the intent of the current framework. >>>> Point d) starts to change the intent. The framework allows for a >>>> media consumer to receive multiple capture scene entries (regardless >>>> of media >>>> type) at the same time. I think point d) is proposing we not allow >>>> this. I think saying "A consumer shall choose a capture scene entry >>>> rather than choosing individual captures from multiple entries" is >>>> equivalent to saying "A consumer shall choose at most one capture >>>> scene entry (of a particular media type) from any particular capture >> scene". >>>>> Such a restriction probably reduces the scenarios in which the >>>>> provider >>>> needs to express simultaneous transmission sets, because some of the >>>> simultaneity constraints are now included in the capture scene >>>> entries. As others have pointed out, there is still the possibility >>>> of simultaneous constraints that apply across multiple capture scenes. >>>> [CNG] I don't think point d) changes this. The current description of >>>> capture scene entry says that a provider must be able to send all the >>>> media associated with the individual captures within a capture scene >>>> entry concurrently. This would also need to be reflected in any >>>> simultaneous set entries. This seems to be a place for possible >>>> inconsistencies because the data would effectively be duplicated. >>>>> Adding this restriction, to not allow multiple capture scene entries >>>>> (of same >>>> media type, in the same scene) to be used simultaneously is okay with >>>> me, but I don't think it really simplifies much. >>>>> As others have said, allowing a consumer to choose a subset of >>>>> captures >>>> from a capture scene entry makes sense to me too. >>>>> I have a few more comments about the proposals inline below. >>>>> >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>> Behalf Of Christian Groves >>>>>> Sent: Thursday, November 22, 2012 10:56 PM >>>>>> To: clue@ietf.org >>>>>> Subject: [clue] Capture scene clarifications >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> Paul K reminded me that I have an action point from the interim >>>>>> meeting regarding my draft . >>>>>> At the meeting it seems that there was general agreement with the >>>>>> intent of the >>>>>> proposals: >>>>>> a) A scene represents an area where the capture devices are >>>>>> spatially related, i.e. a presentation that shares no spatial >>>>>> relation with a video is a separate scene. >>>>>> >>>>>> b) A capture scene entry thus represents alternate >>>>>> representations of a complete scene. The provider is the one >>>>>> that determines what a complete scene is. A consumer choses >>>>>> a capture scene entry from the scene in the knowledge that it >>>>>> represents the entire scene. >>>>>> >>>>>> d) A consumer shall chose a capture scene entry rather than >>>>>> choosing individual captures from multiple entries. This >>>>>> does not mean that an consuming endpoint must render all the >>>>>> captures. What is locally rendered and how is a local >>>>>> decision. >>>>>> >>>>>> I think the framework draft could be enhanced in a few places to >>>>>> make the intent of CLUE clearer. Below are some suggested updates. >>>>>> >>>>>> 1) Introduce a new definition for "Scene". The capture scene >>>>>> definition and several places mention "scene" but there's no >>>>>> explanation. I propose the following definition to be added to >>>>>> section 3 of >>>> the draft: >>>>>> Scene: Represents an area where the capture devices are spatially >>>> related. >>>>>> Non-spatially related devices exist in different scenes. >>>>> [Duckworth, Mark] Sounds good. >>>>> >>>>>> 2) Update the definition of "Capture scene entry" to make it >>>>>> clearer that it represents an entire scene. Proposed text is: >>>>>> *Capture Scene Entry: a list of media captures of the same media type >>>>>> that together form one representation of an entire capture scene. >>>>> [Duckworth, Mark] Sounds good. >>>>> >>>>>> 3) Update section 6.2 on Capture scenes to reflect the above intents. >>>>>> Changes proposals are: >>>>>> - Section 6.2 2nd paragraph: >>>>>> "A capture scene is a structure representing the <> scene that >> is >>>>>> captured by a collection of<>capture devices. >>>>>> A capture scene..." >>>>> [Duckworth, Mark] Sounds good. >>>>> >>>>>> - Section 6.2 3rd paragraph: >>>>>> "A provider may advertise multiple capture scenes or just a single >>>>>> capture scene.<>>>>> provider.>> A media provider might typically use one capture >>>>>> scene for main participant media and another capture scene for a >>>>>> computer generated presentation...." >>>>> [Duckworth, Mark] sounds good >>>>> >>>>>> - Section 6.2 4th paragraph: >>>>>> "A media provider arranges media captures in a capture scene to help >>>>>> the media consumer choose which captures it wants. The >>>>>> capture >>>> scene >>>>>> entries in a capture scene are different alternatives the provider is >>>>>> suggesting for representing the entire capture scene.>>>>> rest of >>>>>> paragraph>". >>>>>> >>>>>> - Section 6.2 5th paragraph: >>>>>> "Media captures within the same capture scene entry must be of the >>>>>> same media type - it is not possible to mix audio and video captures >>>>>> in the same capture scene entry, for instance. The provider must be >>>>>> capable of encoding and sending all media captures in a single entry >>>>>> simultaneously." >>>>>> >>>>>> - section 6.2 New paragraph dealing with consumer behaviour after >>>>>> the 7th paragraph. >>>>>> "A consumer may receive an advertisement with multiple capture >>>> scenes. >>>>>> A consumer may choose to receive any number of capture scenes. An >>>>>> advertised capture scene it may contain one of more capture scene >>>>>> entries that may contain one of more media captures. A consumer may >>>>>> choose an capture scene entry in the knowledge that it is a >>>>>> complete representation of the scene for a particular media type >>>>>> and that all media captures are spatially related. For a particular >>>>>> media type the consumer shall choose one capture scene entry rather >>>>>> than choosing individual captures from multiple capture scene >>>>>> entries. However this does not mean that a consuming endpoint must >>>>>> render all the media captures. What is locally rendered and how is a >> local decision." >>>>> [Duckworth, Mark] These three proposed changes above are related to >>>>> not >>>> allowing multiple capture scene entries, of the same media type, in >>>> the same scene, from being used simultaneously. I could go either >>>> way on this change, whatever the group decides. >>>>>> 4) The framework uses the terms "media provider" and "provider". We >>>>>> probably should be consistent in the use of the term throughout the >>>>>> framework. >>>>> [Duckworth, Mark] sounds good. >>>>> >>>>>> 5) Related to the "capture group" concept that didn't seem to get >>>>>> support is the ordering in the Capture scene, Capture scene entry, >>>>>> Media >>>> captures. >>>>>> There was some discussion that people had assumed some sort of >>>>>> prioritisation / ordering related to these structures. i.e. If I >>>>>> have a capture scene entry VC0, VC1, VC2 do I assume they should be >>>>>> rendered left to right or is there nothing to be assumed? I take it >>>>>> is the later understanding put I didn't see anything in the >>>>>> framework regarding what should be assumed. We probably should >> also >>>>>> add >>>> something for that. >>>>> [Duckworth, Mark] From the framework: "Determination of the order of >>>> these captures (VC0, VC1 and VC2) for rendering purposes is >>>> accomplished through use of their Area of Capture attributes." I >>>> don't know what other type or order or prioritization you might be talking >> about here. >>>> [CNG] One aspect is the "spatial ordering" i.e. how something is >>>> rendered the other aspect is regarding how the consumer interprets >>>> the order of scene/capture scene entry/capture within the message. >>>> i.e. Is the first capture scene entry more important than the last >>>> entry? There has been some discussion previously that some people >>>> that the provider of the advertisement could provide some >>>> prioritisation hint to the consumer by ordering the list of capture >>>> scene entries. From the text you mentioned aspect is there a general >>>> conclusion that there is no prioritisation implied from the ordering of >> elements in the advertisement? >>>>>> Thoughts? >>>>>> >>>>>> Regards, Christian >>>>>> _______________________________________________ >>>>>> 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 >>> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Mon Dec 10 05:08:02 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648F621F8E7E for ; Mon, 10 Dec 2012 05:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LuR6lOwZTLT for ; Mon, 10 Dec 2012 05:08:02 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7572321F8E32 for ; Mon, 10 Dec 2012 05:08:01 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-37-50c5deb09c72 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E1.DB.10459.0BED5C05; Mon, 10 Dec 2012 14:08:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 14:08:00 +0100 From: Christer Holmberg To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3JLnoSzk8+n3np90eOVjDiWPg3KwGoy/AQAExSlQAAHAv6AACnaFYAACg6MQAAf6TcoAAJtyXA Date: Mon, 10 Dec 2012 13:07:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B051EC1@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje6Ge0cDDPqvKVrsP3WZ2WLdkafM DkweS5b8ZPJ48UApgCmKyyYlNSezLLVI3y6BK2PC7jfMBa3cFW03d7I0MP7i6GLk5JAQMJH4 0LeQDcIWk7hwbz2QzcUhJHCIUaLtRzMLhLOEUWLn/cmMXYwcHGwCFhLd/7RBGkQEQiVWz9zE AmILCxhInPx4gx0ibiixdckcVgg7SuLYvhNgcRYBVYn5zRPA4rwC3hJLzv6EWtbJLLH1yBKw QZwCPhLrrjxhBLEZgS76fmoNE4jNLCAucevJfCaISwUkluw5zwxhi0q8fPyPFeQ2CQFFieX9 chDlOhILdn9ig7C1JZYtfM0MsVdQ4uTMJywTGEVnIZk6C0nLLCQts5C0LGBkWcXInpuYmZNe briJERgJB7f81t3BeOqcyCFGaQ4WJXFerqT9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY y1eoCLfstqlm6I3VjVt6fb9fs7/OEu1eC3OXQwXe9Xtj5j513aB9Lu2pa8l9aUHNTxzGsXMZ dC3mv7sXuPwL/9Ep5xSOZS5aenD2NP/t+V/Z64t8Hp8W3RF7fKGWo36u4bzaHYXH9p33jcvw YnmzfcY7vpQTsgp5nvufXY9q/lYfOP1K/KVXSizFGYmGWsxFxYkAhFUyqFICAAA= Subject: Re: [clue] Capture scene clarifications 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, 10 Dec 2012 13:08:02 -0000 Hi, >>> With regards to simultaneous sets I think we need to resolve what=20 >>> capture scene entries represent. Currently the framework says that it=20 >>> must be possible to send all captures in a Capture Scene Entry=20 >>> simultaneously. To me logically speaking a capture scene entry is=20 >>> effectively a simultaneous transmission set. To send effectively the=20 >>> same information twice seems to me to be abit of a waste. >> >> [Duckworth, Mark] It isn't supposed to be the same information. The=20 >> framework says "The simultaneous transmission sets MUST allow all the=20 >> media captures in a particular capture scene entry to be used simultaneo= usly." So all the media captures from a particular capture scene=20 >> entry must also appear together in a simultaneous transmission set. But= that simultaneous transmission set could also include more media captures,= not just media captures that appear in the same capture scene entry. > > I agree to the understanding, but I still question the need. > > Why can't the "additional captures" be part of a dedicated capture scene = entry? ...and, if the additional captures can not be part of the capture scene ent= ry, because they don't have spatial relationships with the other captures w= ithin the capture scene entry, why not advertise the additional captures as= separate scenes? Regards, Christer From pkyzivat@alum.mit.edu Mon Dec 10 07:02: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 53DA321F842E for ; Mon, 10 Dec 2012 07:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MV+DiYaCIhKZ for ; Mon, 10 Dec 2012 07:02:06 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 489CC21F841D for ; Mon, 10 Dec 2012 07:01:56 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id ZoGy1k0070Fqzac53r1vQU; Mon, 10 Dec 2012 15:01:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id Zr1v1k00n3ZTu2S3Ur1vJQ; Mon, 10 Dec 2012 15:01:55 +0000 Message-ID: <50C5F963.2000209@alum.mit.edu> Date: Mon, 10 Dec 2012 10:01:55 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355151715; bh=VZVW2xZ460bdKND5+jeeYgFmpAwfmxfNo3XipsGHGiQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=l59XmKa64De7Z/UC3Hjuq0DvJTRiLYi0o3q/HCPaXrA0DhP+U0ZA9ifCZRxv6tQjZ Mf8qMMDdKnrkzC98ZbjAahxe9gfBVcu/EWaBn4fnHQKhKQKQJEHF/eVEYKnRTg5ivo U5LqxLxec1sGG6zVjhEgcwcicBcNTdvpquR+ABangUWF2XdqawpiFQa6qsP6fLGvF8 3zqkwb/CY9AIWaPkGVF271aPUSrCQzVdSgWtS04QKxsht6sMnmaHtypE7RHVhcPCQp ou6QN4qDu7OFP2qJJi07SHNyLCcAq5EgQrCAjsmobeuQqzdh9dHHFQyfZdPgUAlIbo JUkM2Xl5J2VzA== Subject: Re: [clue] Capture scene clarifications 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, 10 Dec 2012 15:02:07 -0000 On 12/10/12 3:32 AM, Christer Holmberg wrote: > Hi, > >>> With regards to simultaneous sets I think we need to resolve what >>> capture scene entries represent. Currently the framework says that it >>> must be possible to send all captures in a Capture Scene Entry >>> simultaneously. To me logically speaking a capture scene entry is >>> effectively a simultaneous transmission set. To send effectively the >>> same information twice seems to me to be abit of a waste. >> >> [Duckworth, Mark] It isn't supposed to be the same information. The framework says "The simultaneous transmission sets MUST allow all the media captures in a >> particular capture scene entry to be used simultaneously." So all the media captures from a particular capture scene entry must also appear together in a simultaneous >> transmission set. But that simultaneous transmission set could also include more media captures, not just media captures that appear in the same capture scene entry. > > I agree to the understanding, but I still question the need. > > Why can't the "additional captures" be part of a dedicated capture scene entry? I guess the question is whether you think the provider can anticipate and advertise every possible combination that a receiver might desire. An example that has been given various times is a recipient that wants to always receive the capture that includes his boss, even when the boss isn't speaking. And he wants this in combination with some other captures that might be some conventional scene entry. So this might mean one full scene entry plus one capture from some other scene entry. Or it might mean *parts* of two scene entries to assemble something useful that always includes the boss. (Note: I don't have a strong opinion here. I'm replaying what I've heard.) Thanks, Paul From pkyzivat@alum.mit.edu Mon Dec 10 07:24: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 9CE6121F8528 for ; Mon, 10 Dec 2012 07:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kS1OkP7jFTs for ; Mon, 10 Dec 2012 07:24:37 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id ED7B021F8527 for ; Mon, 10 Dec 2012 07:24:36 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta08.westchester.pa.mail.comcast.net with comcast id Zpc01k00117dt5G58rQcgX; Mon, 10 Dec 2012 15:24:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id ZrQb1k00d3ZTu2S3ZrQbk6; Mon, 10 Dec 2012 15:24:36 +0000 Message-ID: <50C5FEB3.8090405@alum.mit.edu> Date: Mon, 10 Dec 2012 10:24:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christian Groves References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <7594FB04B1934943A5C02806D1A2204B04CBFE@ESESSMB209.ericsson.se> <50BCC6BD.8080904@alum.mit.edu> <50C13B9E.1070807@nteczone.com> In-Reply-To: <50C13B9E.1070807@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355153076; bh=N4azaR6wClEA0riXLJWxRl6rDwQfHiL+vJ9bnfDzIfE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AnRHSDrQO7aDachoP91AlBx803YJ1iCgU4xjAQVt2d9a7Ill8775NcfOwsmIGJ4P2 LPYJZoBio5xyL494IPIf2RnJa5hfOQqaTEga8kSfEA0bjRUM3SwuRLSkRV+5snnxMw QaJ2Id4J1JlfNGZadC+ZqeW9Nmf1G+O0p/sQrHakOySQDOaOBwJX4Ov+Ez6GwDDSGG /HQQcNX7tldyJXr5fpLtfj8BSTTJuoFMOIHbjOtyoRjkKJmkFgTi46V/0RuePyylbk dBJLxrqJcHbXtQ870uYv7dKpJCifY6ctuAAUM/LhRRHUnwCJ7ALZbwmv9TzgNa9tHA zqmSzpHTkbvaQ== Cc: clue@ietf.org Subject: Re: [clue] Capture scene clarifications 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, 10 Dec 2012 15:24:37 -0000 On 12/6/12 7:43 PM, Christian Groves wrote: > Hello Paul, > > It would offer flexibility but is this added flexibility needed? In > order to choose multiple capture scene entries the original provider > must provide a simultaneous transmission so the MCU knows what it can > get (we still don't know if its intended that STSs are mandatory or > optional in an advertisement). If there's multiple parties involved with > the MCU then the combinations of captures in going to quickly increase I > don't know if allowing yet more alternatives is beneficial. > > Did you have a concrete case in mind? I think I forgot to respond to this. I'm leaving part of the earlier conversation for context, and then I'll give one example. >>> I think there are two questions here: >>> >>> 1) Is it allowed to choose multiple capture scene entries (associated >>> with the same scene)? >>> 2) Is it allowed to choose, from a given capture scene entry, a >>> subset of captures? >>> >>> Regarding 1), I see very little reasons for allowing it. Of course, >>> it shall be possible to receive multiple capture scene entries, >>> associated with *different* scenes. A typical example is one entry >>> associated with the "room", and one associated with a "presentation". >> >> I can see how it could be useful for a MCU to do this. >> This would give it the flexibility to offer a wider range of choices >> in its own advertisements. Consider a room (room-1) that has seating for six, and six cameras. Among the capture scenes it advertises, it might include one entry with two captures each including three people. And another entry with three captures each including two people. And it can provide these simultaneously. (It can't send six individual captures.) It then connects to an MCU for a conference with two other rooms. Room-2 has one particpant, one camera, and three screens. Room-3 has one participant, one camera, and four screens. Room-2 could see both other rooms if the MCU would advertise a scene entry with two captures from Room-1 and the one capture from Room-3. Room-3 would be happier if the MCU would advertise a scene entry with three captures from Room-1 and the one capture from Room-2. (Admittedly this is a bit artificial. There may be some more plausible cases.) Thanks, Paul From christer.holmberg@ericsson.com Mon Dec 10 08:33: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 A6D7621F84FC for ; Mon, 10 Dec 2012 08:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw0q1h3J0UXh for ; Mon, 10 Dec 2012 08:33:31 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E9A7521F8523 for ; Mon, 10 Dec 2012 08:33:30 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-f6-50c60ed999fd Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F2.53.04318.9DE06C05; Mon, 10 Dec 2012 17:33:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 17:33:29 +0100 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] Minutes: CLUE Design team Call - Dec 3, 2012 Thread-Index: AQHN0kOgANHDWWJWQkuwDkBf13yOOJgSQ1h/ Date: Mon, 10 Dec 2012 16:33:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B05224F@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje4tvmMBBvu3cVjsP3WZ2eLz/v3M DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGs/1n2Au2slXc3neXqYFxNWsXIyeHhICJ xNpfHUwQtpjEhXvr2boYuTiEBA4xSmx42cgK4SxhlFj29SlLFyMHB5uAhUT3P22QBhEBJ4kL L9+zgNjCAg4Skx5tZ4OIO0rsmLOZEcI2knjTcgksziKgKjHh0yywOK+At8SbN2+ZQWwhgQCJ Fyu+gc3hFAiUaPnaBXYQI9BB30+tAbOZBcQlbj2ZD3WogMSSPeeZIWxRiZeP/0E9oyix82w7 M0S9jsSC3Z/YIGxtiWULXzND7BWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSX m29iBMbCwS2/DXYwbrovdohRmoNFSZxXT3W/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG tnynm9/3i+6XCg0/WjHP1ziX2b5WWk5l1oVwu9mvjwue7ZlVqr/E0bRd3eFU3eZOtYQZ/isf +jXO7XH41+5clrLz7oa4o07Hvxy68n7pP7eYB5Zmqvahy5N41Bz/GzUKTv7qunuGvP+5n0XG 3bdXnOKX3J65M+pGgKDqAkPjROP3YXwiue5KLMUZiYZazEXFiQAM5HLIUwIAAA== Subject: Re: [clue] Minutes: CLUE Design team Call - Dec 3, 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, 10 Dec 2012 16:33:31 -0000 Hi, I've been sitting for 20 minutes listening to silence, so I assume there is= no design team call today? I was about 10 minutes late, though, so my appologies if you had a very sho= rt meeting and I missed it :) Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Tuesday, 04 December 2012 7:20 PM To: CLUE Subject: [clue] Minutes: CLUE Design team Call - Dec 3, 2012 Hi all, I have uploaded the minutes for yesterday's design team call: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes= -121203.txt Mary. _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Mon Dec 10 08:48: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 A873A21F850C for ; Mon, 10 Dec 2012 08:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.171 X-Spam-Level: X-Spam-Status: No, score=-7.171 tagged_above=-999 required=5 tests=[AWL=1.078, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj2J5oLJf0cp for ; Mon, 10 Dec 2012 08:48:49 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id ADBA421F8507 for ; Mon, 10 Dec 2012 08:48:48 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-b9-50c6126f3167 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 4C.15.04318.F6216C05; Mon, 10 Dec 2012 17:48:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 17:48:47 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3JLnoSzk8+n3np90eOVjDiWPg3KwGoy/AQAExSlQAAHAv6AACnaFYAACg6MQAAf6TcoAALqfGAAAVRHN8= Date: Mon, 10 Dec 2012 16:48:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> In-Reply-To: <50C5F963.2000209@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvjW6+0LEAg9XHzSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj4b5FLAVnRSp+PnrG0sB4VKCLkZNDQsBE Yu/UZhYIW0ziwr31bF2MXBxCAocYJT43fWYFSQgJLGGUaN4R2cXIwcEmYCHR/U8bJCwi4Cmx 4+MUZhBbWMBA4uTHG+wQcUOJrUvmsELYSRLvJxxlBLFZBFQlbk74AbaLV8Bb4uic/awQu1Yy Sxy8/wGsiFNAR+LnhnY2EJsR6KDvp9YwgdjMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWxF iZ1n25kh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkT03 MTMnvdx8EyMwFg5u+W2wg3HTfbFDjNIcLErivHqq+/2FBNITS1KzU1MLUovii0pzUosPMTJx cEo1MBqlzamNvLex6tEjx9wsZ/HQY+mmdcffBv+7v69wuX6oofzq6GCbb5P9cxb1Lnsu+tjv ZU9d66Pzsd8tZX9s8xfimjrrq+vihisp+zVCTQ0Puv88wyAhJcd/8v4f1saXj54a2J+4Mf29 dOvdRulmuf0ZpxSfzU7/1Xi7oXf2U/sV898GGEco/ldiKc5INNRiLipOBAA2vPxXUwIAAA== Subject: Re: [clue] Capture scene clarifications 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, 10 Dec 2012 16:48:49 -0000 Hi, >>>> With regards to simultaneous sets I think we need to resolve what >>>> capture scene entries represent. Currently the framework says that it >>>> must be possible to send all captures in a Capture Scene Entry >>>> simultaneously. To me logically speaking a capture scene entry is >>>> effectively a simultaneous transmission set. To send effectively the >>>> same information twice seems to me to be abit of a waste. >>> >>> [Duckworth, Mark] It isn't supposed to be the same information. The fr= amework says "The simultaneous transmission sets MUST allow all the media c= aptures in a >>> particular capture scene entry to be used simultaneously." So all the = media captures from a particular capture scene entry must also appear toget= her in a simultaneous >>> transmission set. But that simultaneous transmission set could also in= clude more media captures, not just media captures that appear in the same = capture scene entry. >> >> I agree to the understanding, but I still question the need. >> >> Why can't the "additional captures" be part of a dedicated capture scene= entry? > > I guess the question is whether you think the provider can anticipate > and advertise every possible combination that a receiver might desire. > > An example that has been given various times is a recipient that wants > to always receive the capture that includes his boss, even when the boss > isn't speaking. > > And he wants this in combination with some other captures that might be s= ome conventional scene entry. So this might mean > one full scene entry plus one capture from some other scene entry. Or it = might mean *parts* of two scene entries to assemble something useful > that always includes the boss. You can achieve this e.g. using two separate SCENES: one SCENE with a captu= re scene entry that contains the full scene capture, and another SCENE with= a capture scene entry that contains the boss capture. ...or, if possible (due to spatial relationship etc), you can put both the = full scene captures and the boss capture in a single capture scene entry. For any given SCENE, I think a consumer shall only be allowed to select a s= ingle capture scene entry. The consumer may, though, choose multiple SCENES= (but, again, only a single capture scene entry from any given SCENE). (NOTE: I use captial letters for SCENE, to clearly separate between scene a= nd capture scene entry :) >(Note: I don't have a strong opinion here. I'm replaying what I've heard.) I just think we should start by trying to keep things simple. Regards, Christer= From mary.ietf.barnes@gmail.com Mon Dec 10 09:04: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 283AE21F8201 for ; Mon, 10 Dec 2012 09:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.56 X-Spam-Level: X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw5QI6gfxpZ6 for ; Mon, 10 Dec 2012 09:04:20 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13B4021F8235 for ; Mon, 10 Dec 2012 09:04:13 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2356786lah.31 for ; Mon, 10 Dec 2012 09:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=is9UnM0ER1flyh3X7QlYijPumoajGn1J46pfv5gCw78=; b=OrNiV1wHgEzavOKOE3vmoUratNRMz6cyNybNKva+o6L+zO0bJTntesvcbhH9KL82hB jU2V3EKtT5iYe/jghFK4zpuA0sR2fSGwBJQil8TqnlDgBEQt6EHjcI8RaS4d8w+0fRSg dHd5lG+rsYn1MectiEM+ss3DTK2ocHGGzJ3VA6azV2CjeJAuR7qjdUPxv1MyS4NsR7EW IQvF3WIXK5HjTQylHK3gTdMaAw1nm1XVCXEKzscyImI+lc32rlN8GYzQP9Zh0i809GA6 XItOKnpVsf79gTqjwsN8DidcDxSX5v1oIreF2s20g/KJvZJVI1QCWw9ENRZyyZNua9E1 4b8Q== MIME-Version: 1.0 Received: by 10.112.38.103 with SMTP id f7mr6033848lbk.120.1355159052972; Mon, 10 Dec 2012 09:04:12 -0800 (PST) Received: by 10.114.20.41 with HTTP; Mon, 10 Dec 2012 09:04:12 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B05224F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B05224F@ESESSMB209.ericsson.se> Date: Mon, 10 Dec 2012 11:04:12 -0600 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] Minutes: CLUE Design team Call - Dec 3, 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, 10 Dec 2012 17:04:21 -0000 Correct - no meeting today as was announced previously: http://www.ietf.org/mail-archive/web/clue/current/msg02128.html Our next meeting and the last one for the year is next Monday, 17th. I tried to send a reminder earlier but I am in jury duty and I couldn't get to my email for a while. Mary. On Mon, Dec 10, 2012 at 10:33 AM, Christer Holmberg wrote: > > Hi, > > I've been sitting for 20 minutes listening to silence, so I assume there is no design team call today? > > I was about 10 minutes late, though, so my appologies if you had a very short meeting and I missed it :) > > Regards, > > Christer > > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com] > Sent: Tuesday, 04 December 2012 7:20 PM > To: CLUE > Subject: [clue] Minutes: CLUE Design team Call - Dec 3, 2012 > > Hi all, > > I have uploaded the minutes for yesterday's design team call: > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-121203.txt > > Mary. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Mon Dec 10 09:07: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 3B50F21F84E0 for ; Mon, 10 Dec 2012 09:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pXrihYcHmM7 for ; Mon, 10 Dec 2012 09:07:35 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1BE21F84E6 for ; Mon, 10 Dec 2012 09:07:35 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-9f-50c616d66fd5 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D7.DC.10459.6D616C05; Mon, 10 Dec 2012 18:07:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 18:07:33 +0100 From: Christer Holmberg To: Paul Kyzivat , Christian Groves Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3JLnoSzk8+n3np90eOVjDiWPg3KwGoy/AQAExSlQAACbjyIAAOZaaAAKoBFAAAtahKgAAFRvmf Date: Mon, 10 Dec 2012 17:07:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0522C0@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <7594FB04B1934943A5C02806D1A2204B04CBFE@ESESSMB209.ericsson.se> <50BCC6BD.8080904@alum.mit.edu> <50C13B9E.1070807@nteczone.com>,<50C5FEB3.8090405@alum.mit.edu> In-Reply-To: <50C5FEB3.8090405@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje41sWMBBnvfSFp8ed/IYrH/1GVm ixUbDrA6MHv8ff+ByWPJkp9MHivOz2QJYI7isklJzcksSy3St0vgyvj9awFjwTThigWHt7A3 MC7k72Lk5JAQMJF482orO4QtJnHh3nq2LkYuDiGBQ4wSvbcOMkM4Sxglfn3bytLFyMHBJmAh 0f1PG6RBRCBGYsmUXiYQm1lAWeJrwyYwW1jAQOLkxxvsEDWGEluXzGEFaRURiJJYctIWJMwi oCqxfOUKFhCbV8Bb4snENkaIVbuZJNpbZ4AlOAV0JF6cvscMYjMCHff91BqoXeISt57MZ4I4 WkBiyZ7zzBC2qMTLx/9YIWxFiZ1n25kh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzUIy dhaSlllIWmYhaVnAyLKKkT03MTMnvdxwEyMwbg5u+a27g/HUOZFDjNIcLErivFxJ+/2FBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MObHH360LbRndfb1u8L9d7an2/7JjaktsMr980nfXKS/ TC7bjHW2Q9o0taS5TcE9JvKnJ3SeXPbu0ebYmDucz8XspDbecP3S7XlC3zX0zb6gcj/PCRuL FP2ad3/t+e02yWt/a+GE/39y9i2fkHSipTN3k9aRvcfuWdf8mz3Xd8eDJN4DTz3XeimxFGck GmoxFxUnAgAuvmpyaQIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 10 Dec 2012 17:07:36 -0000 Hi, >> It would offer flexibility but is this added flexibility needed? In >> order to choose multiple capture scene entries the original provider >> must provide a simultaneous transmission so the MCU knows what it can >> get (we still don't know if its intended that STSs are mandatory or >> optional in an advertisement). If there's multiple parties involved with >> the MCU then the combinations of captures in going to quickly increase I >> don't know if allowing yet more alternatives is beneficial. >> >> Did you have a concrete case in mind? > > I think I forgot to respond to this. > I'm leaving part of the earlier conversation for context, and then I'll > give one example. > >>> I think there are two questions here: >>> >>> 1) Is it allowed to choose multiple capture scene entries (associated >>> with the same scene)? >>> 2) Is it allowed to choose, from a given capture scene entry, a >>> subset of captures? >>> >>> Regarding 1), I see very little reasons for allowing it. Of course, >>> it shall be possible to receive multiple capture scene entries, >>> associated with *different* scenes. A typical example is one entry >>> associated with the "room", and one associated with a "presentation". >> >> I can see how it could be useful for a MCU to do this. >> This would give it the flexibility to offer a wider range of choices >> in its own advertisements. > > Consider a room (room-1) that has seating for six, and six cameras. > Among the capture scenes it advertises, it might include one entry with > two captures each including three people. And another entry with three > captures each including two people. And it can provide these > simultaneously. (It can't send six individual captures.) > > It then connects to an MCU for a conference with two other rooms. Room-2 > has one particpant, one camera, and three screens. Room-3 has one > participant, one camera, and four screens. > > Room-2 could see both other rooms if the MCU would advertise a scene > entry with two captures from Room-1 and the one capture from Room-3. > > Room-3 would be happier if the MCU would advertise a scene entry with > three captures from Room-1 and the one capture from Room-2. The MCU can advertise different scene entries (or, different scenes) to Roo= m-2 and Room-3. Regards, Christer > (Admittedly this is a bit artificial. There may be some more plausible > cases.) From christer.holmberg@ericsson.com Mon Dec 10 09:08: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 CAB8321F84E4 for ; Mon, 10 Dec 2012 09:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ4teQqdL16S for ; Mon, 10 Dec 2012 09:08:48 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7A05C21F84E0 for ; Mon, 10 Dec 2012 09:08:47 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-65-50c61716a418 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 65.07.04318.61716C05; Mon, 10 Dec 2012 18:08:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.001; Mon, 10 Dec 2012 18:08:37 +0100 From: Christer Holmberg To: Mary Barnes Thread-Topic: [clue] Minutes: CLUE Design team Call - Dec 3, 2012 Thread-Index: AQHN0kOgANHDWWJWQkuwDkBf13yOOJgSQ1h////4HQCAABHfHw== Date: Mon, 10 Dec 2012 17:08:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0522D9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B05224F@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvja6Y+LEAg8fvxS32n7rMbPF5/35m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjzZIJrAX/OSp6d0xgbWBcz97FyMkhIWAi 0XTpJSuELSZx4d56ti5GLg4hgUOMEv83r2eCcJYwSrxrPg+U4eBgE7CQ6P6nDdIgIqAj8e3z WzYQm1lAQmLVxQ+MILawgIPEpEfb2SBqHCV2zNnMCGE7SZy818cCYrMIqEoc+jSPFWQkr4C3 RP/rWohV1xklNv3YAVbDKRAocWTVaiYQmxHouO+n1jBB7BKXuPVkPhPE0QISS/acZ4awRSVe Pv4H9YyixM6z7cwQ9ToSC3Z/grpTW2LZwtdgcV4BQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKA kWUVI3tuYmZOern5JkZgjBzc8ttgB+Om+2KHGKU5WJTEefVU9/sLCaQnlqRmp6YWpBbFF5Xm pBYfYmTi4JRqYDTimVWW/5aPO/jTu8KTwf4HDwTdyEwXv5B3ayEHVxBT0pfzC9ZYHp5/UHEl 5+4dK+0ZF9WuUTdeveWhwqblabGOK02FmssvrvyokHnfZs6NRodf3Dv2vC1Q+3L69KRdLS+e RxR98S7bkVVy0elwNPde9gMcJeebFRd+4hSUqZnI8iLoVO7dbg0lluKMREMt5qLiRAC8R4NG XwIAAA== Cc: CLUE Subject: Re: [clue] Minutes: CLUE Design team Call - Dec 3, 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, 10 Dec 2012 17:08:48 -0000 Hi, >Correct - no meeting today as was announced previously: >http://www.ietf.org/mail-archive/web/clue/current/msg02128.html Ok, sorry, I missed that. Regards, Christer On Mon, Dec 10, 2012 at 10:33 AM, Christer Holmberg wrote: > > Hi, > > I've been sitting for 20 minutes listening to silence, so I assume there = is no design team call today? > > I was about 10 minutes late, though, so my appologies if you had a very s= hort meeting and I missed it :) > > Regards, > > Christer > > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Bar= nes [mary.ietf.barnes@gmail.com] > Sent: Tuesday, 04 December 2012 7:20 PM > To: CLUE > Subject: [clue] Minutes: CLUE Design team Call - Dec 3, 2012 > > Hi all, > > I have uploaded the minutes for yesterday's design team call: > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minut= es-121203.txt > > Mary. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Dec 10 09:20: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 1F84721F8562 for ; Mon, 10 Dec 2012 09:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UemqfpY8L8UC for ; Mon, 10 Dec 2012 09:20:57 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4E27021F8561 for ; Mon, 10 Dec 2012 09:20:57 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id ZoKo1k0081GhbT851tLvAL; Mon, 10 Dec 2012 17:20:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id ZtLv1k0093ZTu2S3TtLv87; Mon, 10 Dec 2012 17:20:55 +0000 Message-ID: <50C619F6.4090402@alum.mit.edu> Date: Mon, 10 Dec 2012 12:20:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B05224F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B05224F@ESESSMB209.ericsson.se> Content-Type: multipart/mixed; boundary="------------000707010701090807030401" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355160055; bh=eyBpWy26HRK0uwcHOQWttb3li+49+4oDV1mWLjyyqEw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Cagut+3BOW9pc+g8/Ypobi4tzE8hBvHonllp+sPws13IHSPxB8Fz44uP2Hetxq5ZP NK3QwhUHdlvil4Q0Uj5e0/ymVMTT8/bVh7iM/Jq5wy8aTqEy7FhLTB24PvtUhyAlA4 syM0MtE+Ua3/y8u9z8nuuObg2QppeVynISpAg/TW5Q51bMFDYlpXl4ikiZKZNWCK8N Fz6sOwDlbnI2yxgKpkyzzN5yIxjKtIcorP0cdiVektGw9SST+Cebv0WMAHyUXk/Qlq qo3MuhOF39sfnp+cRujBaMTwUciBtRz5by3OnsqGf3qgIA8IQtbgnzR1cJ5QRTaU2n 269MSmHkdoZYg== Subject: Re: [clue] Minutes: CLUE Design team Call - Dec 3, 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, 10 Dec 2012 17:20:58 -0000 This is a multi-part message in MIME format. --------------000707010701090807030401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sorry Christer, A few weeks ago Mary sent out an agenda for calls for December, and explicitly left out today. Thanks, Paul On 12/10/12 11:33 AM, Christer Holmberg wrote: > > Hi, > > I've been sitting for 20 minutes listening to silence, so I assume there is no design team call today? > > I was about 10 minutes late, though, so my appologies if you had a very short meeting and I missed it :) > > Regards, > > Christer > > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com] > Sent: Tuesday, 04 December 2012 7:20 PM > To: CLUE > Subject: [clue] Minutes: CLUE Design team Call - Dec 3, 2012 > > Hi all, > > I have uploaded the minutes for yesterday's design team call: > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-121203.txt > > Mary. > _______________________________________________ > 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 > --------------000707010701090807030401 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: mary.ietf.barnes@gmail.com Received: from imta28.westchester.pa.mail.comcast.net (LHLO imta28.westchester.pa.mail.comcast.net) (76.96.60.168) by sz0055.wc.mail.comcast.net with LMTP; Fri, 16 Nov 2012 21:44:42 +0000 (UTC) Received: from alum-mailsec-relay-9.mit.edu ([18.7.68.29]) by imta28.westchester.pa.mail.comcast.net with comcast id QMki1k0270dt8C20UMkilz; Fri, 16 Nov 2012 21:44:42 +0000 X-CAA-SPAM: 00000 X-Authority-Analysis: v=2.1 cv=AJ2w/97g c=1 sm=1 tr=0 a=MRj2BPNAhLswQ1TjTjGTrQ==:117 a=C_IRinGWAAAA:8 a=kbd7zLJt4NoA:10 a=nDghuxUhq_wA:10 a=pGLkceISAAAA:8 a=1XWaLZrsAAAA:8 a=S-dY-eAU4r8A:10 a=qnkU1UQEe6Q4mHgvnkkA:9 a=wPNLvfGTeEIA:10 a=-Ygk632i_w2IqHEMnpIA:9 a=qXeE1zmkyy7njVeN:21 Received: from alum-mailsec-scanner-4.mit.edu (ALUM-MAILSEC-SCANNER-4.MIT.EDU [18.7.68.15]) by alum-mailsec-relay-9.mit.edu (8.13.8/8.12.8) with ESMTP id qAGLhoQk024046 for ; Fri, 16 Nov 2012 16:44:42 -0500 X-AuditID: 1207440f-b7fde6d00000095c-41-50a6b3c9f445 Authentication-Results: symauth.service.identifier Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 89.7E.02396.9C3B6A05; Fri, 16 Nov 2012 16:44:42 -0500 (EST) Received: by mail-la0-f53.google.com with SMTP id w12so2570079lag.26 for ; Fri, 16 Nov 2012 13:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=68ZJIc97BiNmfqo5OB7IJ4FDYLCFQ1ZIjGBfM0aUSsU=; b=U22YZMF+BQgM8iIxcFrZuIjNfAMklJ06KioXNAMjrxSsyCTdX2LhQFyTcDWf06TLy+ 6Fyeeo4lYhTnP2eQ5uAZ+G6+O3IYex37fMfvs1LEzQpsEHBtMOMbrEiwnIOwKE7joPXg z836+mEOMhtsTlu7wZ53HN4ihZ5DqnIAF48peIwLnwQASNmZyAgDUoqFPdTLIo7QRg4j VktKRSYj3hu1KBb+glyp8HVUW/BLy721Lb+u1v5s4RXkx33flIscA1pybW67Q8aeAKsq Ewa+aSE20DibRwteIz1fUYHxBtOYJm9hyBj0qrFb4aACSLJ8nc1QFVsVBoVwgA/8yxW+ HMZQ== MIME-Version: 1.0 Received: by 10.152.105.68 with SMTP id gk4mr5361036lab.48.1353102281081; Fri, 16 Nov 2012 13:44:41 -0800 (PST) Received: by 10.114.69.139 with HTTP; Fri, 16 Nov 2012 13:44:41 -0800 (PST) Date: Fri, 16 Nov 2012 15:44:41 -0600 Message-ID: Subject: CLUE Design team meetings through end of 2012, plans for 2013 From: Mary Barnes To: CLUE Cc: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d040714afcf023904cea3ac8c X-Brightmail-Tracker: H4sIAAAAAAAAA01SbUhTURj23N3N69i141XbcU6DgSjWNM0gokzKShJqEEb0o7pup224Tdvd 1PXHlX2x8os0bAWWmKkFhhmWJeWIyJVjBhWJhuWKMjAzijJs3bvhx5/Dc97neZ/34eWlRMxz sYLClTZstbAmlURKjhS9Wa/23mnXrB3ol2zouP1YnAcK5r/NEBpwQLpJh03GcmzNzD0sNdSe +0OWNa2q7HW+EjtBX4ILUBSCOehvJ+sCURSA2eiBb0osYARXIv+7bokLSCkGjgL00HVcHP7U A9Qx5iaEDwl/kujWSAMQWmgYg4YuBUgBM/AoGg26iDAuRM86L4dsSZiC5l3TRFivQWMTjaHe WLgDBZoHQ3UJzED9rc5QPQ4i5PWOh7AIpqH3rZPiMN6FGifnyXoA3ctGu5dRYbwGTddOiMJ4 NeqqGSYWcPu1r6KrQNwFklmT3aw2s0YTh7VqTstaLNiqzskwG20ZWGfvAfyOmcj8FfeAq1vp AZACKhmdWNmuYcRsOecwe0ACRaji6a03+VJ0canOYWA5wyGr3YQ5D0CUSBVH62t4jtaxjmPY WrpAJVKkSk6ntqXuZqCeteESjMuwdYElqEgPUFKUCtEtPXx3jBXrceURo8m2XBMlPFJhjIwf 80gQ0lwZa+aM+rDIC9ZRb91nAoD67HUFAENaSi1YIafvC1IoSA12y6KlcE9VwWDwJUhSxNIg IiKCkfGZ+FUs8cK9fQAx1JdIRiIlsAVuVIRMp4CcX00sHRCcZUaLbTHDFB+P4OP1KtuEeDZ2 iVI4wakkaKpzvPAHwCCYTm/YV42y5nLP32jxNmU2/9jSwvbNxO8cF41rm3PrelnlyYFWvz2t 5HX09zkiQVpYvnn7tqfVGcUXgO/ljPy6Dxws90Xsb7o4VDFS9+TuUGLcaY22IiW/oCbv19m9 c3s+Dhfh5Cv+qtkeoyf794nqT7P/ylQkZ2Cz0kVWjv0PPfqT/F4DAAA= --f46d040714afcf023904cea3ac8c Content-Type: text/plain; charset=ISO-8859-1 Hi all, We would like to propose the following schedule for the calls through the end of 2012. As noted at the meeting, the plan is to focus on the WG deliverables (those will be summarized in a separate email). We plan to skip the call next week as it's a US holiday at the end of the week and I'll be out the whole week. I have jury duty on the 10th, so we'll skip that unless someone has something compelling they think needs discussion. November 26th: Update on RTP convergence (Roni, Jonathan) December 3rd: Framework refactoring (Stephan, Andy, Mark) December 17th: Signaling update (Rob, Roni, Simon, Roberta, Christer) Note: the first name is the prime for pulling together any materials - i.e., drafty drafts, email proposals, etc ;) If you do not believe you are ready, let the chairs know ASAP, so we can find another topic to discuss and let us know when you anticipate to have something to discuss with the group. For 2013, we should start back with the calls on January 14th. We would also like to plan a virtual interim sometime mid-late Jan - early-mid Feb. The proposal is for a 2 hr/day 2 day meeting. The chairs do not believe we need a f2f interim before the next IETF meeting. If you think we do and are willing to host, let us know ASAP as time is extremely limited for planning a meeting given the winter/Christmas holiday and the fact that the time between IETF-85 and IETF-86 is quite short (registration and scheduling for IETF-86 opens on Dec. 10th). Also, RTCWEB is also planning an interim - we have no intention of trying to coordinate with them since it was not effective the last time, we just can't overlap. Regards, Mary and Paul CLUE WG co-chairs --f46d040714afcf023904cea3ac8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

We would like to propose the following schedule = for the calls through the end of 2012. =A0As noted at the meeting, the plan= is to focus on the WG deliverables (those will be summarized in a separate= email). We plan to skip the call next week as it's a US holiday at the= end of the week and I'll be out the whole week. =A0I have jury duty on= the 10th, so we'll skip that unless someone has something compelling t= hey think needs discussion.

November 26th: =A0Update on RTP convergence (Roni, Jona= than)
December 3rd: =A0Framework refactoring =A0(Stephan, Andy, M= ark)
December 17th: =A0Signaling update (Rob, Roni, Simon, Robert= a, Christer)

Note: the first name is the prime for pulling together = any materials - i.e., drafty drafts, email proposals, etc ;) =A0 If you do = not believe you are ready, let the chairs know ASAP, so we can find another= topic to discuss and let us know when you anticipate to have something to = discuss with the group.=A0

For 2013, we should start back with the calls on Januar= y 14th. =A0

We would also like to plan a virtual i= nterim sometime mid-late Jan - early-mid Feb. =A0The proposal is for a 2 hr= /day 2 day meeting. =A0The chairs do not believe we need a f2f interim befo= re the next IETF meeting. =A0If you think we do and are willing to host, le= t us know ASAP as time is extremely limited for planning a meeting given th= e winter/Christmas holiday and the fact that the time between IETF-85 and I= ETF-86 is quite short (registration and scheduling for IETF-86 opens on Dec= . 10th). =A0Also, RTCWEB is also planning an interim - we have no intention= of trying to coordinate with them since it was not effective the last time= , we just can't overlap.=A0

Regards,
Mary and Paul
CLUE WG co-c= hairs
--f46d040714afcf023904cea3ac8c-- --------------000707010701090807030401-- From pkyzivat@alum.mit.edu Mon Dec 10 09:40: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 61A3621F8504 for ; Mon, 10 Dec 2012 09:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=1.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGpr8DFZ6rw0 for ; Mon, 10 Dec 2012 09:40:32 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id A229821F84F3 for ; Mon, 10 Dec 2012 09:40:32 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta02.westchester.pa.mail.comcast.net with comcast id Zn4j1k0040ldTLk51tgX1u; Mon, 10 Dec 2012 17:40:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id ZtgX1k00f3ZTu2S3QtgXBg; Mon, 10 Dec 2012 17:40:31 +0000 Message-ID: <50C61E8E.1090805@alum.mit.edu> Date: Mon, 10 Dec 2012 12:40:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355161231; bh=758fYiXiCZOJwfyvpJhj5WJ2E9YK9tpSUBtaoLlDqlA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ammb3xq9+nJ7Bw2gC6lhTVcIr/JHCZp/XNpPuVL/wteYlwwKkWx5NOjZjdjo+uBHh lmrcXpG+PJ7HDEP1icxDwdeDppLAcpmSEwH6Xi2GUTOMSC6iPIsJpfDjv3SyAvryf+ MP/UMXDwIpCdTdnveQhTX1ezAK9yuQSsNy2muaqvGHoA0bS5yFERVtmyupttrqFhKo CLEmSUVKtvl85RzlR9zfK3D9QfFJiZsGcFu5F/p5YFBtUmcE0CUZ+m5UJTC61aZ2Xp i3hi87n1gXazc8ry34WB4Gsg0Tg/eVqk4dFIY9wPzpSqY9FVaiXmaIuKWwDPTGlzt7 XqzIEq/ycS2jg== Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 10 Dec 2012 17:40:33 -0000 On 12/10/12 11:48 AM, Christer Holmberg wrote: > > Hi, > >>>>> With regards to simultaneous sets I think we need to resolve what >>>>> capture scene entries represent. Currently the framework says that it >>>>> must be possible to send all captures in a Capture Scene Entry >>>>> simultaneously. To me logically speaking a capture scene entry is >>>>> effectively a simultaneous transmission set. To send effectively the >>>>> same information twice seems to me to be abit of a waste. >>>> >>>> [Duckworth, Mark] It isn't supposed to be the same information. The framework says "The simultaneous transmission sets MUST allow all the media captures in a >>>> particular capture scene entry to be used simultaneously." So all the media captures from a particular capture scene entry must also appear together in a simultaneous >>>> transmission set. But that simultaneous transmission set could also include more media captures, not just media captures that appear in the same capture scene entry. >>> >>> I agree to the understanding, but I still question the need. >>> >>> Why can't the "additional captures" be part of a dedicated capture scene entry? >> >> I guess the question is whether you think the provider can anticipate >> and advertise every possible combination that a receiver might desire. >> >> An example that has been given various times is a recipient that wants >> to always receive the capture that includes his boss, even when the boss >> isn't speaking. >> >> And he wants this in combination with some other captures that might be some conventional scene entry. So this might mean >> one full scene entry plus one capture from some other scene entry. Or it might mean *parts* of two scene entries to assemble something useful >> that always includes the boss. > > You can achieve this e.g. using two separate SCENES: one SCENE with a capture scene entry that contains the full scene capture, and another SCENE with a capture scene entry that contains the boss capture. My assumption was that the boss is not everyone's boss, or known to be special in any way to the providing site. Rather he is important only to the recipient(s) in one of the other rooms. Stated more abstractly, the receiver has special interest in one of the provider's captures that the provider does not realize is of more interest than any of its other captures. > ...or, if possible (due to spatial relationship etc), you can put both the full scene captures and the boss capture in a single capture scene entry. > > For any given SCENE, I think a consumer shall only be allowed to select a single capture scene entry. I'm fine with this simplification if we have consensus that it is sufficient. > The consumer may, though, choose multiple SCENES (but, again, only a single capture scene entry from any given SCENE). I'm concerned about your use of "may" here, and what that implies about the significance of scenes. While we can't and shouldn't force the consumer to request more than it wants, IMO it had better be clear to the consumer what it needs to do to get a "complete" or "sufficient" rendition of the call. Creating extra scenes for the purpose of advertising "optional/extra" stuff (such as the extra scene for the boss) is very different from creating extra scenes for stuff that is equally important but spatially unrelated. > (NOTE: I use captial letters for SCENE, to clearly separate between scene and capture scene entry :) > >> (Note: I don't have a strong opinion here. I'm replaying what I've heard.) > > I just think we should start by trying to keep things simple. As simple as it can be while satisfying all the requirements, and no simpler. :-) Thanks, Paul From pkyzivat@alum.mit.edu Mon Dec 10 09:48: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 F1F8621F8528 for ; Mon, 10 Dec 2012 09:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04esbpT5IMH4 for ; Mon, 10 Dec 2012 09:48:24 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 37DDF21F8519 for ; Mon, 10 Dec 2012 09:48:23 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id Znii1k00M1ei1Bg53toPl5; Mon, 10 Dec 2012 17:48:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id ZtoP1k0073ZTu2S3ktoPAU; Mon, 10 Dec 2012 17:48:23 +0000 Message-ID: <50C62065.50101@alum.mit.edu> Date: Mon, 10 Dec 2012 12:48:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <7594FB04B1934943A5C02806D1A2204B04CBFE@ESESSMB209.ericsson.se> <50BCC6BD.8080904@alum.mit.edu> <50C13B9E.1070807@nteczone.com>, <50C5FEB3.8090405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0522C0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0522C0@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355161703; bh=PkVk2Sim2DP9xRwg18GzTUb59oIzGkOcavm+Jt2lZRo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=p8mIl7tUJr00VQlCqUmSg3ky1BXI+x/1jz8gCpC8dL5udnuhJP0U5aTvwZfYrBGMk P03O7SWa7rFc87awEO9BH9ZQa5PMomYb22nTiRVz2LoqkD2a6xuTXnz6GOLVgzZUCC ym2wekSv4G7bsT8+5qZeCVjZEgx8AJGU2TcA5IhYOBXISBYLbB/lCwWsebbmvY1ut8 spEfvx68ClOJN4LXwrucELwnopv+OSJrbtBTZeUJZEm38SBy4/q6igGrVXEelZQbvQ KEGd5GBEun3pjAAn29Yk6ZcSKts3oeyzkS87A1DbGAUoUds93uLpnG5oVyvEg44JQo 1T0bg/krSFv3g== Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 10 Dec 2012 17:48:25 -0000 On 12/10/12 12:07 PM, Christer Holmberg wrote: > > Hi, > >>> It would offer flexibility but is this added flexibility needed? In >>> order to choose multiple capture scene entries the original provider >>> must provide a simultaneous transmission so the MCU knows what it can >>> get (we still don't know if its intended that STSs are mandatory or >>> optional in an advertisement). If there's multiple parties involved with >>> the MCU then the combinations of captures in going to quickly increase I >>> don't know if allowing yet more alternatives is beneficial. >>> >>> Did you have a concrete case in mind? >> >> I think I forgot to respond to this. >> I'm leaving part of the earlier conversation for context, and then I'll >> give one example. >> >>>> I think there are two questions here: >>>> >>>> 1) Is it allowed to choose multiple capture scene entries (associated >>>> with the same scene)? >>>> 2) Is it allowed to choose, from a given capture scene entry, a >>>> subset of captures? >>>> >>>> Regarding 1), I see very little reasons for allowing it. Of course, >>>> it shall be possible to receive multiple capture scene entries, >>>> associated with *different* scenes. A typical example is one entry >>>> associated with the "room", and one associated with a "presentation". >>> >>> I can see how it could be useful for a MCU to do this. >>> This would give it the flexibility to offer a wider range of choices >>> in its own advertisements. >> >> Consider a room (room-1) that has seating for six, and six cameras. >> Among the capture scenes it advertises, it might include one entry with >> two captures each including three people. And another entry with three >> captures each including two people. And it can provide these >> simultaneously. (It can't send six individual captures.) >> >> It then connects to an MCU for a conference with two other rooms. Room-2 >> has one particpant, one camera, and three screens. Room-3 has one >> participant, one camera, and four screens. >> >> Room-2 could see both other rooms if the MCU would advertise a scene >> entry with two captures from Room-1 and the one capture from Room-3. >> >> Room-3 would be happier if the MCU would advertise a scene entry with >> three captures from Room-1 and the one capture from Room-2. > > The MCU can advertise different scene entries (or, different scenes) to Room-2 and Room-3. Certainly it can. If fact it typically will, since it probably won't want the advertisement to Room-N to include captures received from Room-N. But I don't think that has any bearing on this discussion, for a couple of reasons: - To customize the advertisements to include different things from Room-1, it would need to know something about what Room-2 and Room-3 want or can use. But the point is to advertise what is possible and let the recipient decide what it wants to receive. - In any case, if the result is that Room-2 can request two 3-person captures of Room-1 and Room-3 can request three 2-person captures of Room-1, then the MCU will need to request all of those from Room-1. Thanks, Paul From john@jlc.net Mon Dec 10 11:55: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 3DCBC21F8623 for ; Mon, 10 Dec 2012 11:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.403 X-Spam-Level: X-Spam-Status: No, score=-106.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqhAV56I0CUK for ; Mon, 10 Dec 2012 11:55:46 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A0FB821F861B for ; Mon, 10 Dec 2012 11:55:46 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id C69B133C8E; Mon, 10 Dec 2012 14:55:46 -0500 (EST) Date: Mon, 10 Dec 2012 14:55:46 -0500 From: John Leslie To: Christer Holmberg Message-ID: <20121210195546.GF66595@verdi> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] Capture scene clarifications 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, 10 Dec 2012 19:55:47 -0000 Christer Holmberg wrote: > > For any given SCENE, I think a consumer shall only be allowed to select > a single capture scene entry. The consumer may, though, choose multiple > SCENES (but, again, only a single capture scene entry from any given > SCENE). Not meaning to speak for or against this, it seems a bit confusing to impose this limitation on a person. Could you clarify what benefit this restriction brings us? -- John Leslie From christer.holmberg@ericsson.com Wed Dec 12 03:27: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 1F8D521F89E3 for ; Wed, 12 Dec 2012 03:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHYJNhBh45Kn for ; Wed, 12 Dec 2012 03:27:09 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 39E9921F89E1 for ; Wed, 12 Dec 2012 03:27:09 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-4c-50c86a0cf3a2 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D4.C4.10459.C0A68C05; Wed, 12 Dec 2012 12:27:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 12:27:07 +0100 From: Christer Holmberg To: John Leslie Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3JLnoSzk8+n3np90eOVjDiWPg3KwGoy/AQAExSlQAAHAv6AACnaFYAACg6MQAAf6TcoAALqfGAAAVRHN8ABPIdAABUqLeQ Date: Wed, 12 Dec 2012 11:27:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B053E6F@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <20121210195546.GF66595@verdi> In-Reply-To: <20121210195546.GF66595@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvjS5P1okAg4U3xSz2n7rMbPH+wnlG ByaPJUt+Mnkcm3uYOYApissmJTUnsyy1SN8ugStj1RGDgussFacnb2RvYLzK3MXIySEhYCLR 3HSUDcIWk7hwbz2QzcUhJHCIUeL85kXMEM4SRomvfYuBHA4ONgELie5/2iANIgJyEr/OPmAE sZkFlCW+NmxiArGFBQwkTn68wQ5RYyixdckcVgg7T6Lhyj6wOIuAqsTfvpOMICN5BbwlGtdk QKw6wyzx78dHsJmcAtoSKx50g9UzAh33/dQaJohd4hK3nsxngjhaQGLJnvNQz4hKvHz8jxVk poSAosTyfjmIch2JBbs/sUHY2hLLFr4GK+cVEJQ4OfMJywRGsVlIps5C0jILScssJC0LGFlW MbLnJmbmpJcbbmIExsfBLb91dzCeOidyiFGag0VJnJcrab+/kEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBsaS19JnljDdjnDc3WcSJfS0dPkciWkr+iR3Jap0XQiuOXw8Oamwv0F0ko7ZhY88 eSqXr3949k/HI/GHZtvO7h4RNv2Ei0/ZT8tJXLsWx7xhq/3qBZEJ5T92bbVdknvsXe8mG8cX P01SC5ju/F3P4eAcate759APrZa7Mw+IBv/8tnvK8V/Mjy4osRRnJBpqMRcVJwIAvp7JbF0C AAA= Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 12 Dec 2012 11:27:10 -0000 Hi, >> For any given SCENE, I think a consumer shall only be allowed to=20 >> select a single capture scene entry. The consumer may, though, choose=20 >> multiple SCENES (but, again, only a single capture scene entry from=20 >> any given SCENE). > > Not meaning to speak for or against this, it seems a bit confusing to i= mpose this limitation on a person. > > Could you clarify what benefit this restriction brings us? Simplicity. Capture scene entries provide alternatives for a given SCENE, and I think t= he receiver will chose one alternative. Regards, Christer From christer.holmberg@ericsson.com Wed Dec 12 03:40: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 3CCB421F89D1 for ; Wed, 12 Dec 2012 03:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YixC0Jjj5jOk for ; Wed, 12 Dec 2012 03:40:36 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F2F9121F89CA for ; Wed, 12 Dec 2012 03:40:35 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-f4-50c86d2da32f Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 57.67.04318.D2D68C05; Wed, 12 Dec 2012 12:40:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 12:40:28 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3JLnoSzk8+n3np90eOVjDiWPg3KwGoy/AQAExSlQAAHAv6AACnaFYAACg6MQAAf6TcoAALqfGAAAVRHN8AADi8AABZpj/Q Date: Wed, 12 Dec 2012 11:40:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B053E9D@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <50C61E8E.1090805@alum.mit.edu> In-Reply-To: <50C61E8E.1090805@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvja5u7okAg0lbxSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj1g/ugiblir23m9gaGFfIdDFyckgImEj8 uHqXGcIWk7hwbz1bFyMXh5DAIUaJhZf6WCCcJYwSm8//Yu1i5OBgE7CQ6P6nDWKKCGhITNqq BtLLLKAs8bVhExOILSxgIHHy4w12EFtEwFBi65I5rBB2nsTF84sYQWwWAVWJ6+ffgtXwCnhL TP6+jRliVS+LxL2+ZSwgCU4BHYkpK2aDDWUEOu77qTVMEMvEJW49mc8EcbSAxJI956EeEJV4 +fgf2JkSAooSy/vlIMp1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis1CMnUWkpZZSFpmIWlZ wMiyipE9NzEzJ73cfBMjMD4ObvltsINx032xQ4zSHCxK4rx6qvv9hQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTAmxPtddS1zF5f4Fn58en5z/OyNf/fKeBzjDSjtP2D+5/ZU9YPLD2/S4/Z+ 8svIbrfxRZc1/f0TLk7S4br1a53Y1UXCKo8mpya/6PBco6FaMflYa9nSTo2QzGNWgkx9rcFb 3RemTT7q7yHJxG6l4iT6bvNMoYCPU1fyZm1YEfU9dr04R0nxXwclluKMREMt5qLiRACtiy06 XQIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 12 Dec 2012 11:40:37 -0000 Hi, >>>>>> With regards to simultaneous sets I think we need to resolve what=20 >>>>>> capture scene entries represent. Currently the framework says that=20 >>>>>> it must be possible to send all captures in a Capture Scene Entry=20 >>>>>> simultaneously. To me logically speaking a capture scene entry is=20 >>>>>> effectively a simultaneous transmission set. To send effectively=20 >>>>>> the same information twice seems to me to be abit of a waste. >>>>> >>>>> [Duckworth, Mark] It isn't supposed to be the same information. =20 >>>>> The framework says "The simultaneous transmission sets MUST allow=20 >>>>> all the media captures in a particular capture scene entry to be used= simultaneously." So all the media captures from a particular capture=20 >>>>> scene entry must also appear together in a simultaneous transmission = set. But that >>>>>simultaneous transmission set could also include more m= edia captures, not just media captures that appear in the same capture scen= e entry. >>>> >>>> I agree to the understanding, but I still question the need. >>>> >>>> Why can't the "additional captures" be part of a dedicated capture sce= ne entry? >>> >>> I guess the question is whether you think the provider can anticipate=20 >>> and advertise every possible combination that a receiver might desire. >>> >>> An example that has been given various times is a recipient that=20 >>> wants to always receive the capture that includes his boss, even when=20 >>> the boss isn't speaking. >>> >>> And he wants this in combination with some other captures that might=20 >>> be some conventional scene entry. So this might mean one full scene=20 >>> entry plus one capture from some other scene entry. Or it might mean *p= arts* of two scene entries to assemble something useful that always include= s the boss. >> >> You can achieve this e.g. using two separate SCENES: one SCENE with a ca= pture scene entry that contains the full scene capture, and another SCENE w= ith a capture scene entry that contains the boss capture. > > My assumption was that the boss is not everyone's boss, or known to be sp= ecial in any way to the providing site. Rather he is important only to the = recipient(s) in one of the other rooms. > > Stated more abstractly, the receiver has special interest in one of the p= rovider's captures that the provider does not realize is of more interest t= han any of its other captures. So, if I understand you correctly, the provider could e.g: 1) Provide a single SCENE with a capture scene entry that contains the "ful= l room", and individual captures of each participant. Of the individual par= ticipant captures, the receiver will then only choose the capture associate= d with the important participant - ie the receiver is not mandated to recei= ve everything in the chosen capture scene entry; 2) Provide a SCENE with a capture scene entry that contains the "full room"= , and in addition individual SCENEs for each individual participant. The re= ceiver will then choose the "full room" SCENE, and the SCENE representing t= he important participant; 3) Similar to 1), but provide a single SCENE with multiple capture scene en= tries, where each entry contains the "full room", and the capture of ONE pa= rticipant. The receiver will then choose the capture scene entry which cont= ains the capture associated with the important participant.=20 Etc. I am not claiming that the 3 alternatives above are equally smart, but my p= oint is that I think we can solve use-cases by using SCENEs and capture sce= ne entries. >> The consumer may, though, choose multiple SCENES (but, again, only a sin= gle capture scene entry from any given SCENE). > > I'm concerned about your use of "may" here, and what that implies about t= he significance of scenes. > > While we can't and shouldn't force the consumer to request more than it w= ants, IMO it had better be clear to the consumer what it needs to do to get= a "complete" or "sufficient" rendition of the call. Creating extra scenes = for the=20 > purpose of advertising "optional/extra" stuff (such as the extra scene fo= r the boss) is very different from creating extra scenes for stuff that is = equally important but spatially unrelated. Fair enough - then, assuming the boss capture is considered spatially relat= ed to the "full room", choose alternative 1) above :) Regards, Christer From christer.holmberg@ericsson.com Wed Dec 12 03:50: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 5993D21F8907 for ; Wed, 12 Dec 2012 03:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUF4HSzmCcFr for ; Wed, 12 Dec 2012 03:50:04 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 34BFC21F8901 for ; Wed, 12 Dec 2012 03:50:04 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-f9-50c86f6b2e7e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CB.68.10459.B6F68C05; Wed, 12 Dec 2012 12:50:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 12:50:02 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3JLnoSzk8+n3np90eOVjDiWPg3KwGoy/AQAExSlQAACbjyIAAOZaaAAKoBFAAAtahKgAAFRvmf///984D//TFPsA== Date: Wed, 12 Dec 2012 11:50:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B053EBF@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <7594FB04B1934943A5C02806D1A2204B04CBFE@ESESSMB209.ericsson.se> <50BCC6BD.8080904@alum.mit.edu> <50C13B9E.1070807@nteczone.com>,<50C5FEB3.8090405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0522C0@ESESSMB209.ericsson.se> <50C62065.50101@alum.mit.edu> In-Reply-To: <50C62065.50101@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjW52/okAg3d/xCy+vG9ksdh/6jKz xYoNB1gdmD3+vv/A5LFkyU8mjxXnZ7IEMEdx2aSk5mSWpRbp2yVwZTyfuompoEmhovnsZ6YG xvOSXYycHBICJhIfW9tZIWwxiQv31rN1MXJxCAkcYpRY9W4JC4SzhFHi89NZzF2MHBxsAhYS 3f+0QUwRAQ2JSVvVQHqZBcIlLjyeyQZiCwsYSJz8eIMdxBYRMJTYumQOK4SdJbF6zyV2kFYW AVWJh5tUQcK8At4SR7dcY4LYNJdZ4u/qj8wgCU4BLYmFf6awgNiMQLd9P7WGCWKXuMStJ/OZ IG4WkFiy5zwzhC0q8fLxP1aQ+RICihLL++UgynUkFuz+xAZha0ssW/iaGWKvoMTJmU9YJjCK zUIydRaSlllIWmYhaVnAyLKKkT03MTMnvdxwEyMwZg5u+a27g/HUOZFDjNIcLErivFxJ+/2F BNITS1KzU1MLUovii0pzUosPMTJxcEo1MKbej2mO3NCeYe2TfOK1yPXEXd8bt/Mct+APmvF+ i/G73O33PAXYHqwROntjR5noG6ePbYfrdM4oX3LTjU5JULR+vLijcdGqaTWHVhxaWTpRU2Kr X+mRXIPgJ1Jfdfv3sD37u0xQbNY1vSMbDH7aq9iuv6/Wsjrm68ryaNGlwX7Va+7Oatf5tE6J pTgj0VCLuag4EQAcSu2oZwIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 12 Dec 2012 11:50:05 -0000 Hi, >>>> It would offer flexibility but is this added flexibility needed? In=20 >>>> order to choose multiple capture scene entries the original provider=20 >>>> must provide a simultaneous transmission so the MCU knows what it=20 >>>> can get (we still don't know if its intended that STSs are mandatory=20 >>>> or optional in an advertisement). If there's multiple parties=20 >>>> involved with the MCU then the combinations of captures in going to=20 >>>> quickly increase I don't know if allowing yet more alternatives is ben= eficial. >>>> >>>> Did you have a concrete case in mind? >>> >>> I think I forgot to respond to this. >>> I'm leaving part of the earlier conversation for context, and then=20 >>> I'll give one example. >>> >>>>> I think there are two questions here: >>>>> >>>>> 1) Is it allowed to choose multiple capture scene entries=20 >>>>> (associated with the same scene)? >>>>> 2) Is it allowed to choose, from a given capture scene entry, a=20 >>>>> subset of captures? >>>>> >>>>> Regarding 1), I see very little reasons for allowing it. Of course,=20 >>>>> it shall be possible to receive multiple capture scene entries,=20 >>>>> associated with *different* scenes. A typical example is one entry=20 >>>>> associated with the "room", and one associated with a "presentation". >>>> >>>> I can see how it could be useful for a MCU to do this. >>>> This would give it the flexibility to offer a wider range of choices=20 >>>> in its own advertisements. >>> >>> Consider a room (room-1) that has seating for six, and six cameras. >>> Among the capture scenes it advertises, it might include one entry=20 >>> with two captures each including three people. And another entry with=20 >>> three captures each including two people. And it can provide these=20 >>> simultaneously. (It can't send six individual captures.) >>> >>> It then connects to an MCU for a conference with two other rooms.=20 >>> Room-2 has one particpant, one camera, and three screens. Room-3 has=20 >>> one participant, one camera, and four screens. >>> >>> Room-2 could see both other rooms if the MCU would advertise a scene=20 >>> entry with two captures from Room-1 and the one capture from Room-3. >>> >>> Room-3 would be happier if the MCU would advertise a scene entry with=20 >>> three captures from Room-1 and the one capture from Room-2. >> >> The MCU can advertise different scene entries (or, different scenes) to = Room-2 and Room-3. > > Certainly it can. If fact it typically will, since it probably won't want= the advertisement to Room-N to include captures received from Room-N. Yes. > But I don't think that has any bearing on this discussion, for a couple o= f reasons: > > - To customize the advertisements to include different things from > Room-1, it would need to know something about what Room-2 and Room-3 > want or can use. But the point is to advertise what is possible and > let the recipient decide what it wants to receive. I think Room-1 should advertise what it can do, and Room-2 and Room-3 then = chooses. Again, if we assume that Room-2 and Room-3 can choose not to receive certai= n parts of a capture scene entry, I am pretty sure Room-2 and Room-3 will f= ind something that fits. > - In any case, if the result is that Room-2 can request two 3-person > captures of Room-1 and Room-3 can request three 2-person captures > of Room-1, then the MCU will need to request all of those from > Room-1. I doubt whether Room-1 will be able to provide both 3-person captures and 2= -person captures at the same time. But, assuming it can, why can't they then be part of the same capture scene= entry provided by Room-1, and the MCU then tells Room-1 what it wants from= that capture scene entry? I think it's much better to allow a receiver to indicate that it does NOT w= ant certain parts from a given capture scene entry, rather than trying to c= ompose a new capture scene entry by picking stuff from different capture sc= ene entries... Regards, Christer From pkyzivat@alum.mit.edu Wed Dec 12 09:19: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 2421021E8047 for ; Wed, 12 Dec 2012 09:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD4+j-jpkeEm for ; Wed, 12 Dec 2012 09:19:36 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA6E21F88F8 for ; Wed, 12 Dec 2012 09:19:36 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta04.westchester.pa.mail.comcast.net with comcast id acFF1k0040ldTLk54hKbfQ; Wed, 12 Dec 2012 17:19:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id ahKb1k00C3ZTu2S3QhKbmw; Wed, 12 Dec 2012 17:19:35 +0000 Message-ID: <50C8BCA5.8020702@alum.mit.edu> Date: Wed, 12 Dec 2012 12:19:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <50C61E8E.1090805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053E9D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B053E9D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355332775; bh=kZe2HMUdp2iDxTggCpsINyUN3a0oBPLCWKsYwScnu9A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eU5KyJQpGHkJnYLubbLn0zZLoE1wwsYAoyZ5g1/SU0sM+cvCxGVoAlOKu/ZkPxC2b gr4RFS2WnsMhUnLn9LNZeE7jZeBGnCelDIOjqKvB4skoATO7xVEItGWjhkHIhovKmg xDH7iiL/TAEI+gCPrgbUzP4bY9HteQSSoGvNdYazbXE9uMwsBBIqLKmx9pJ4nqRjZR kpc11phFvapCcO3ed6VmZuwv4YeEMYayEgFWCLO2Z4sjPzcl0CdRujkRETZYHLt1KV ouUlLSIY3tfpQudzl47hK/dpgYndEuhDkz1cWuPGyE/oT3xHObjyuWmXPoN6niY1Rc xWWI/7G/iq4uw== Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 12 Dec 2012 17:19:37 -0000 More inline On 12/12/12 6:40 AM, Christer Holmberg wrote: > Hi, > >>>>>>> With regards to simultaneous sets I think we need to resolve what >>>>>>> capture scene entries represent. Currently the framework says that >>>>>>> it must be possible to send all captures in a Capture Scene Entry >>>>>>> simultaneously. To me logically speaking a capture scene entry is >>>>>>> effectively a simultaneous transmission set. To send effectively >>>>>>> the same information twice seems to me to be abit of a waste. >>>>>> >>>>>> [Duckworth, Mark] It isn't supposed to be the same information. >>>>>> The framework says "The simultaneous transmission sets MUST allow >>>>>> all the media captures in a particular capture scene entry to be used simultaneously." So all the media captures from a particular capture >>>>>> scene entry must also appear together in a simultaneous transmission set. But that >>>>>simultaneous transmission set could also include more media captures, not just media captures that appear in the same capture scene entry. >>>>> >>>>> I agree to the understanding, but I still question the need. >>>>> >>>>> Why can't the "additional captures" be part of a dedicated capture scene entry? >>>> >>>> I guess the question is whether you think the provider can anticipate >>>> and advertise every possible combination that a receiver might desire. >>>> >>>> An example that has been given various times is a recipient that >>>> wants to always receive the capture that includes his boss, even when >>>> the boss isn't speaking. >>>> >>>> And he wants this in combination with some other captures that might >>>> be some conventional scene entry. So this might mean one full scene >>>> entry plus one capture from some other scene entry. Or it might mean *parts* of two scene entries to assemble something useful that always includes the boss. >>> >>> You can achieve this e.g. using two separate SCENES: one SCENE with a capture scene entry that contains the full scene capture, and another SCENE with a capture scene entry that contains the boss capture. >> >> My assumption was that the boss is not everyone's boss, or known to be special in any way to the providing site. Rather he is important only to the recipient(s) in one of the other rooms. >> >> Stated more abstractly, the receiver has special interest in one of the provider's captures that the provider does not realize is of more interest than any of its other captures. > > So, if I understand you correctly, the provider could e.g: There are many things a provider *could* do. Many of them don't make sense, or IMO are a bad idea. > 1) Provide a single SCENE with a capture scene entry that contains the "full room", and individual captures of each participant. I guess you mean that a single scene *entry* contains both the "full room" capture and the individual captures? IMO that is contrary to the intent of a scene entry. The entry has redundant information, and requires a recipient with no special needs to analyze it and decide it could simply render *either* the "full room" capture, or all the other captures in the entry. This is hard. Rather, I would think this same information would be represented better as two scene entries: - an entry with the single "full room" capture - an entry with individual captures for each participant. Each of these provides a full rendering of the room, in a different way. > Of the individual participant captures, the receiver will then only choose the capture associated with the important participant - ie the receiver is not mandated to receive everything in the chosen capture scene entry; With the alternative I just mentioned, a receiver with no special interests could then choose one of those entries that best meets its needs and capabilities. E.g. if it has enough displays and decoders to receive all the individual captures, then that might be the better choice. If it doesn't have enough resources to do that then it could simply choose the single capture full room entry. A receiver that has special interest in one participant (the boss) might then decide to receive the entry with the full room capture, and also the one capture for the boss from the entry that has all the individual captures. > 2) Provide a SCENE with a capture scene entry that contains the "full room", and in addition individual SCENEs for each individual participant. The receiver will then choose the "full room" SCENE, and the SCENE representing the important participant; This doesn't make sense to be. All of those captures share the same coordinate space, so they ought to be in the same scene. > 3) Similar to 1), but provide a single SCENE with multiple capture scene entries, where each entry contains the "full room", and the capture of ONE participant. The receiver will then choose the capture scene entry which contains the capture associated with the important participant. This also doesn't make much sense to me. It has the same problems as (1). > Etc. > > I am not claiming that the 3 alternatives above are equally smart, but my point is that I think we can solve use-cases by using SCENEs and capture scene entries. This has just moved the complexity. It makes it harder for recipients that have no special needs and just want to find an entry to render that fits their capabilities. And it makes it harder for the provider to anticipate combinations that are only of rare and special interest. Thanks, Paul From pkyzivat@alum.mit.edu Wed Dec 12 09:31: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 6DE381F0CC3 for ; Wed, 12 Dec 2012 09:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVya1jL9Rmo8 for ; Wed, 12 Dec 2012 09:31:04 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0B921F8746 for ; Wed, 12 Dec 2012 09:31:01 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id acZq1k0040EZKEL51hX0xt; Wed, 12 Dec 2012 17:31:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id ahWz1k00k3ZTu2S3MhWzwY; Wed, 12 Dec 2012 17:31:00 +0000 Message-ID: <50C8BF52.4080307@alum.mit.edu> Date: Wed, 12 Dec 2012 12:30:58 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <7594FB04B1934943A5C02806D1A2204B04CBFE@ESESSMB209.ericsson.se> <50BCC6BD.8080904@alum.mit.edu> <50C13B9E.1070807@nteczone.com>, <50C5FEB3.8090405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0522C0@ESESSMB209.ericsson.se> <50C62065.50101@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053EBF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B053EBF@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355333460; bh=KFQlWDwwxyegY5AvEPFO653aL1hxCxJ85BlL3P1wr5Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BmJ28toSdcGoDxtVzpEQ8QQ8y8iQoORpiaAAA8qDlRcqOg1JCPdTE4NgxCIheuaYN D+U8OSSnTW+iqUI9WbtZz55cyR0UOGbfOrW2Z767HjgbVymS5F/oV24fP596GqAv6t DNHJAl1W6aWO4o3nR6hHK8VkmjMJKM7t7zjb/pe2rWHw+C5J8vK8GB9h8kpHWyerB9 amVhubw4qNAoRDpYt49NGDnodsO7MGVINwOHpGaX8HXZs2m6YRWqUlyb2jpty0n9Wp 8pId9OriPc4LZkzd9AmU01eUP/0+MFU7iXStKRr521jBxOOKglJBpQFv8tpRwvskY0 /montGaM+wpzQ== Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 12 Dec 2012 17:31:07 -0000 On 12/12/12 6:50 AM, Christer Holmberg wrote: > Hi, > >>>>> It would offer flexibility but is this added flexibility needed? In >>>>> order to choose multiple capture scene entries the original provider >>>>> must provide a simultaneous transmission so the MCU knows what it >>>>> can get (we still don't know if its intended that STSs are mandatory >>>>> or optional in an advertisement). If there's multiple parties >>>>> involved with the MCU then the combinations of captures in going to >>>>> quickly increase I don't know if allowing yet more alternatives is beneficial. >>>>> >>>>> Did you have a concrete case in mind? >>>> >>>> I think I forgot to respond to this. >>>> I'm leaving part of the earlier conversation for context, and then >>>> I'll give one example. >>>> >>>>>> I think there are two questions here: >>>>>> >>>>>> 1) Is it allowed to choose multiple capture scene entries >>>>>> (associated with the same scene)? >>>>>> 2) Is it allowed to choose, from a given capture scene entry, a >>>>>> subset of captures? >>>>>> >>>>>> Regarding 1), I see very little reasons for allowing it. Of course, >>>>>> it shall be possible to receive multiple capture scene entries, >>>>>> associated with *different* scenes. A typical example is one entry >>>>>> associated with the "room", and one associated with a "presentation". >>>>> >>>>> I can see how it could be useful for a MCU to do this. >>>>> This would give it the flexibility to offer a wider range of choices >>>>> in its own advertisements. >>>> >>>> Consider a room (room-1) that has seating for six, and six cameras. >>>> Among the capture scenes it advertises, it might include one entry >>>> with two captures each including three people. And another entry with >>>> three captures each including two people. And it can provide these >>>> simultaneously. (It can't send six individual captures.) >>>> >>>> It then connects to an MCU for a conference with two other rooms. >>>> Room-2 has one particpant, one camera, and three screens. Room-3 has >>>> one participant, one camera, and four screens. >>>> >>>> Room-2 could see both other rooms if the MCU would advertise a scene >>>> entry with two captures from Room-1 and the one capture from Room-3. >>>> >>>> Room-3 would be happier if the MCU would advertise a scene entry with >>>> three captures from Room-1 and the one capture from Room-2. >>> >>> The MCU can advertise different scene entries (or, different scenes) to Room-2 and Room-3. >> >> Certainly it can. If fact it typically will, since it probably won't want the advertisement to Room-N to include captures received from Room-N. > > Yes. > >> But I don't think that has any bearing on this discussion, for a couple of reasons: >> >> - To customize the advertisements to include different things from >> Room-1, it would need to know something about what Room-2 and Room-3 >> want or can use. But the point is to advertise what is possible and >> let the recipient decide what it wants to receive. > > I think Room-1 should advertise what it can do, and Room-2 and Room-3 then chooses. The problem is that Room-1 advertises what it can do to the *MCU*, not to Room-2 and Room-3. The MCU then must decide what to advertise to Room-2 and Room-3. In the case I described, it happens that it is possible to let everybody see everybody else simultaneously without doing any switching or composing in the MCU. So what I described has the MCU directly "passing through" the captures it receives. In reality it would probably *also* advertise some other entries that are switched or composed in order to accommodate receivers that can only handle fewer (e.g. one) captures. > Again, if we assume that Room-2 and Room-3 can choose not to receive certain parts of a capture scene entry, I am pretty sure Room-2 and Room-3 will find something that fits. My point was that with the MCU passing everything through, both Room-2 and Room-3 *can* find something that works for them. That then results in what I previously said: >> - In any case, if the result is that Room-2 can request two 3-person >> captures of Room-1 and Room-3 can request three 2-person captures >> of Room-1, then the MCU will need to request all of those from >> Room-1. > > I doubt whether Room-1 will be able to provide both 3-person captures and 2-person captures at the same time. I described the scenario such that it could. Perhaps this is unrealistic. If so then it would have indicated that by not including them in the simultaneous sets. > But, assuming it can, why can't they then be part of the same capture scene entry provided by Room-1, and the MCU then tells Room-1 what it wants from that capture scene entry? I explained this in my reply to your prior message. Including them in the same scene entry fills that entry with redundant information and makes it difficult for most receivers to use. > I think it's much better to allow a receiver to indicate that it does NOT want certain parts from a given capture scene entry, rather than trying to compose a new capture scene entry by picking stuff from different capture scene entries... This is just moving complexity around, not reducing it. (And perhaps increasing it.) Thanks, Paul From christer.holmberg@ericsson.com Wed Dec 12 12:37: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 88B1D21E803D for ; Wed, 12 Dec 2012 12:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d13gsoaUDR7z for ; Wed, 12 Dec 2012 12:37:32 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C27C021E803C for ; Wed, 12 Dec 2012 12:37:31 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-ce-50c8eb096982 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 48.28.04318.90BE8C05; Wed, 12 Dec 2012 21:37:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 21:37:28 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3JLnoSzk8+n3np90eOVjDiWPg3KwGoy/AQAExSlQAAHAv6AACnaFYAACg6MQAAf6TcoAALqfGAAAVRHN8AADi8AABZpj/QAAozp4AACBBw4g== Date: Wed, 12 Dec 2012 20:37:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0543CD@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <50C61E8E.1090805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053E9D@ESESSMB209.ericsson.se>, <50C8BCA5.8020702@alum.mit.edu> In-Reply-To: <50C8BCA5.8020702@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvjS7n6xMBBhdfC1rsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGwkczWQr2aVVcXLWJqYGxWamLkZNDQsBE 4tWGnawQtpjEhXvr2boYuTiEBA4xSqybNIUJwlnCKLFszQwgh4ODTcBCovufNogpIqAhMWmr Gkgvs4CyxNeGTUwgtrCAgcTJjzfYQWwRAUOJrUvmsELYdRLLHvaxgNgsAqoS22Z/AKvhFfCW WHlpB9Sq9ywSB6fdA2vgFNCRmPbkLlgDI9Bx30+tYYJYJi5x68l8JoijBSSW7DnPDGGLSrx8 /A/qGUWJj6/2MULU60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSbhWTsLCQts5C0zELSsoCR ZRUje25iZk56ufkmRmCMHNzy22AH46b7YocYpTlYlMR59VT3+wsJpCeWpGanphakFsUXleak Fh9iZOLglGpg5H0ulDWBoW7b72niR77nt3Dc4rdQeHxzmY9P7gnN54s+x9Wp53zWcijr3ugy K+0Rh2QKv7al6F9W71MBc21m8yWGs6a+zymbuc9iVUDqD99z2X/dKk5YGd57n/Iv5ENl5OxY qdWcp/g1dGsknnzu5ngnu9n5jc7NDQYxrA8/b3tz7Y52//N3SizFGYmGWsxFxYkADmY9OV8C AAA= Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 12 Dec 2012 20:37:38 -0000 Hi, I'm putting the other discussion on hold for the moment, because I think we= are starting to find some common ground in this one :) >>>>>>>> With regards to simultaneous sets I think we need to resolve what >>>>>>>> capture scene entries represent. Currently the framework says that >>>>>>>> it must be possible to send all captures in a Capture Scene Entry >>>>>>>> simultaneously. To me logically speaking a capture scene entry is >>>>>>>> effectively a simultaneous transmission set. To send effectively >>>>>>>> the same information twice seems to me to be abit of a waste. >>>>>>> >>>>>>> [Duckworth, Mark] It isn't supposed to be the same information. >>>>>>> The framework says "The simultaneous transmission sets MUST allow >>>>>>> all the media captures in a particular capture scene entry to be us= ed simultaneously." So all the media captures from a particular capture >>>>>>> scene entry must also appear together in a simultaneous transmissio= n set. But that >>>>>simultaneous transmission set could also include more= media captures, not just media captures that appear in the same capture sc= ene entry. >>>>>> >>>>>> I agree to the understanding, but I still question the need. >>>>>> >>>>>> Why can't the "additional captures" be part of a dedicated capture s= cene entry? >>>>> >>>>> I guess the question is whether you think the provider can anticipate >>>>> and advertise every possible combination that a receiver might desire= . >>>>> >>>>> An example that has been given various times is a recipient that >>>>> wants to always receive the capture that includes his boss, even when >>>>> the boss isn't speaking. >>>>> >>>>> And he wants this in combination with some other captures that might >>>>> be some conventional scene entry. So this might mean one full scene >>>>> entry plus one capture from some other scene entry. Or it might mean = *parts* of two scene entries to assemble something useful that always inclu= des the boss. >>>> >>>> You can achieve this e.g. using two separate SCENES: one SCENE with a = capture scene entry that contains the full scene capture, and another SCENE= with a capture scene entry that contains the boss capture. >>> >>> My assumption was that the boss is not everyone's boss, or known to be = special in any way to the providing site. Rather he is important only to th= e recipient(s) in one of the other rooms. >>> >>> Stated more abstractly, the receiver has special interest in one of the= provider's captures that the provider does not realize is of more interest= than any of its other captures. >> >> So, if I understand you correctly, the provider could e.g: > > There are many things a provider *could* do. Many of them don't make sens= e, or IMO are a bad idea. > >> 1) Provide a single SCENE with a capture scene entry that contains the "= full room", and individual captures of each participant. > > I guess you mean that a single scene *entry* contains both the "full room= " capture and the individual captures? > > IMO that is contrary to the intent of a scene entry. The entry has > redundant information, and requires a recipient with no special needs to > analyze it and decide it could simply render *either* the "full room" > capture, or all the other captures in the entry. This is hard. > > Rather, I would think this same information would be represented better > as two scene entries: > > - an entry with the single "full room" capture > - an entry with individual captures for each participant. > > Each of these provides a full rendering of the room, in a different way. Ok, let's go with that for now :) So, we have a single SCENE, which has two associated CSEs (Capture Scene En= tries): - "full room" CSE (capture of full room) - "individual" CSE (captures of each participant) >> Of the individual participant captures, the receiver will then only choo= se the capture associated with the important participant - ie the receiver = is not mandated to receive everything in the chosen capture scene entry; > > With the alternative I just mentioned, a receiver with no special > interests could then choose one of those entries that best meets its > needs and capabilities. E.g. if it has enough displays and decoders to > receive all the individual captures, then that might be the better > choice. If it doesn't have enough resources to do that then it could > simply choose the single capture full room entry. Agree.=20 > A receiver that has special interest in one participant (the boss) might > then decide to receive the entry with the full room capture, and also > the one capture for the boss from the entry that has all the individual > captures. Almost agree :) In my opinion, the receiver would decide two receive both CSEs, but it woul= d indicate that from the individual CSE it only wants to "boss" capture. So, the end result is really the same. The only different is that, in my op= inion, the receiver must always pick a CSE (but it may choose which capture= s it wants). The advantage is that we then only need to advertise simultanous CSE sets -= not simultanous capture sets - as it is assumed that a provider can always= provide all captures associated with a CSE. (This of course means we would need to allow picking multiple CSEs from a s= ingle SCENE.) Regards, Christer From john@jlc.net Wed Dec 12 14:40: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 B973F21E8054 for ; Wed, 12 Dec 2012 14:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.436 X-Spam-Level: X-Spam-Status: No, score=-106.436 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmSVlimMF3KU for ; Wed, 12 Dec 2012 14:40:00 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id DBDE91F0CB2 for ; Wed, 12 Dec 2012 14:39:59 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 04D1133C24; Wed, 12 Dec 2012 17:40:00 -0500 (EST) Date: Wed, 12 Dec 2012 17:39:59 -0500 From: John Leslie To: Christer Holmberg Message-ID: <20121212223959.GG66595@verdi> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <20121210195546.GF66595@verdi> <7594FB04B1934943A5C02806D1A2204B053E6F@ESESSMB209.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7594FB04B1934943A5C02806D1A2204B053E6F@ESESSMB209.ericsson.se> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] Capture scene clarifications 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, 12 Dec 2012 22:40:00 -0000 Christer Holmberg wrote: > [John Leslie wrote:] >> [Christer Holmberg wrote:] > >>> For any given SCENE, I think a consumer shall only be allowed to >>> select a single capture scene entry. The consumer may, though, choose >>> multiple SCENES (but, again, only a single capture scene entry from >>> any given SCENE). (I wonder if we're all reading this the same way...) >> Not meaning to speak for or against this, it seems a bit confusing to >> impose this limitation on a person. (by which I mean, I'd prefer that software not impose such a limit on participants...) >> Could you clarify what benefit this restriction brings us? > > Simplicity. While simplicity is an admirable goal, it's not obvious to me that the restriction simplifies anything important. (YMMV, of course...) > Capture scene entries provide alternatives for a given SCENE, and > I think the receiver will chose one alternative. Indeed, most users might always choose one capture scene entry. But I have experienced _many_ users over the years that viscerally resent being told to choose "only one". I advise against designing capabilites based on what _we_ think "most users" will want. -- John Leslie From Christian.Groves@nteczone.com Wed Dec 12 16:20:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F405421F8A52 for ; Wed, 12 Dec 2012 16:20:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmbeFLljvKzO for ; Wed, 12 Dec 2012 16:20:55 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id A6ECE21F85C0 for ; Wed, 12 Dec 2012 16:20:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqICADgeyVB20Wi+/2dsb2JhbAANOINIuzuDUBslPRYYAwIBAgFLDQgBAbIck2uPYYEtA6lY Received: from ppp118-209-104-190.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.104.190]) by ipmail06.adl6.internode.on.net with ESMTP; 13 Dec 2012 10:50:50 +1030 Message-ID: <50C91F5C.8040206@nteczone.com> Date: Thu, 13 Dec 2012 11:20:44 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Sending a configure 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, 13 Dec 2012 00:20:56 -0000 Hello, Section 9 of the framework states: " The consumer is able to change its configuration of the provider's encodings any number of times during the call, either in response to a new capture advertisement from the provider or autonomously. The consumer need not send a new configure message to the provider when it receives a new capture advertisement from the provider unless the contents of the new capture advertisement cause the consumer's current configure message to become invalid." From the text I don't think its 100% clear what is meant by "or autonomously". Does this relates to the signalling of CLUE i.e. sending a Configure message? Does it relate to sending a new SDP O/A? Changing the what RTP it sends autonomously? If we're only talking about sending a Configure message I would propose that we change the first sentence to say: "Once the consumer has received an advertisement it may change its configuration of the provider's encodings any number of times during the call by sending a new configure message." Regards, Christian From Christian.Groves@nteczone.com Wed Dec 12 16:56: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 2B19F21F8AA3 for ; Wed, 12 Dec 2012 16:56:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOeh5HuzV646 for ; Wed, 12 Dec 2012 16:56:18 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id D4C6721F8AA2 for ; Wed, 12 Dec 2012 16:56:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMCADwlyVB20Wi+/2dsb2JhbAANOA6DOrs7gxIBAQQ4GyUBEAsOExYPCQMCAQIBRQYNAQcBAbImk2qRDgOSVpYwUg Received: from ppp118-209-104-190.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.104.190]) by ipmail06.adl6.internode.on.net with ESMTP; 13 Dec 2012 11:26:15 +1030 Message-ID: <50C927A9.4030905@nteczone.com> Date: Thu, 13 Dec 2012 11:56:09 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Paul Kyzivat References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <7594FB04B1934943A5C02806D1A2204B04CBFE@ESESSMB209.ericsson.se> <50BCC6BD.8080904@alum.mit.edu> <50C13B9E.1070807@nteczone.com>, <50C5FEB3.8090405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0522C0@ESESSMB209.ericsson.se> <50C62065.50101@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053EBF@ESESSMB209.ericsson.se> <50C8BF52.4080307@alum.mit.edu> In-Reply-To: <50C8BF52.4080307@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 13 Dec 2012 00:56:19 -0000 Hello Paul, Please see my response below: ..snip.. >>> But I don't think that has any bearing on this discussion, for a >>> couple of reasons: >>> >>> - To customize the advertisements to include different things from >>> Room-1, it would need to know something about what Room-2 and Room-3 >>> want or can use. But the point is to advertise what is possible and >>> let the recipient decide what it wants to receive. >> >> I think Room-1 should advertise what it can do, and Room-2 and Room-3 >> then chooses. > > The problem is that Room-1 advertises what it can do to the *MCU*, not > to Room-2 and Room-3. The MCU then must decide what to advertise to > Room-2 and Room-3. > > In the case I described, it happens that it is possible to let > everybody see everybody else simultaneously without doing any > switching or composing in the MCU. So what I described has the MCU > directly "passing through" the captures it receives. In reality it > would probably *also* advertise some other entries that are switched > or composed in order to accommodate receivers that can only handle > fewer (e.g. one) captures. [CNG] This is the point I was trying to understand, how you saw the MCU being involved. You see the MCU as simply passing through the CLUE Advertisements. In my mind I see CLUE not as an end-to-end protocol. I.e. the MCU would effectively act as a CLUE endpoint and "re-configures" any advertisements/configures sent to other endpoints. I think this aspect is worth examining further. Do you in CLUE allow a situation for a MCU to effectively "broadcast" advertisements i.e. from room 1 to room 2 & 3 and then allow these rooms to response directly to Room 1? etc. From Christian.Groves@nteczone.com Wed Dec 12 17:06: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 8516421F8B10 for ; Wed, 12 Dec 2012 17:06:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lqte24SRg0I for ; Wed, 12 Dec 2012 17:06:19 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id B3E0321F8B0F for ; Wed, 12 Dec 2012 17:06:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMCAG0nyVB20Wi+/2dsb2JhbAANOINIuzuDEQEBAQQBAQE1GxUGChELGAkWDwkDAgECARUwEwYCAQEXiAKqEpNpBIxLFoEEgykDqViBUQ Received: from ppp118-209-104-190.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.104.190]) by ipmail06.adl6.internode.on.net with ESMTP; 13 Dec 2012 11:36:17 +1030 Message-ID: <50C92A04.1020905@nteczone.com> Date: Thu, 13 Dec 2012 12:06:12 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <20121210195546.GF66595@verdi> <7594FB04B1934943A5C02806D1A2204B053E6F@ESESSMB209.ericsson.se> <20121212223959.GG66595@verdi> In-Reply-To: <20121212223959.GG66595@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Capture scene clarifications 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, 13 Dec 2012 01:06:19 -0000 Hello, I think we need to distinguish that the person sitting in the conference is not the immediate user of CLUE. I wouldn't expect a human to parse the CLUE advertisement. No doubt there will be some GUI presenting lots of different solutions. Regards, Christian On 13/12/2012 9:39 AM, John Leslie wrote: > Christer Holmberg wrote: >> [John Leslie wrote:] >>> [Christer Holmberg wrote:] >>>> For any given SCENE, I think a consumer shall only be allowed to >>>> select a single capture scene entry. The consumer may, though, choose >>>> multiple SCENES (but, again, only a single capture scene entry from >>>> any given SCENE). > (I wonder if we're all reading this the same way...) > >>> Not meaning to speak for or against this, it seems a bit confusing to >>> impose this limitation on a person. > (by which I mean, I'd prefer that software not impose such a limit > on participants...) > >>> Could you clarify what benefit this restriction brings us? >> Simplicity. > While simplicity is an admirable goal, it's not obvious to me that > the restriction simplifies anything important. (YMMV, of course...) > >> Capture scene entries provide alternatives for a given SCENE, and >> I think the receiver will chose one alternative. > Indeed, most users might always choose one capture scene entry. > But I have experienced _many_ users over the years that viscerally > resent being told to choose "only one". > > I advise against designing capabilites based on what _we_ think > "most users" will want. > > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Dec 12 17:53: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 ED65B21F8948 for ; Wed, 12 Dec 2012 17:53:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL7BTZLJX6PF for ; Wed, 12 Dec 2012 17:53:28 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 7227721F8941 for ; Wed, 12 Dec 2012 17:53:27 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAGo0yVB20S1O/2dsb2JhbAANOINIuhoEA4EbgxEBAQEEAQEBCyobEgkKEQsYCRYPCQMCAQIBFTATBgIBAYgZqiCTZgSMS4RDA5JWlwKBUAU Received: from ppp118-209-45-78.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.78]) by ipmail06.adl2.internode.on.net with ESMTP; 13 Dec 2012 12:23:25 +1030 Message-ID: <50C93510.7080502@nteczone.com> Date: Thu, 13 Dec 2012 12:53:20 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <50C61E8E.1090805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053E9D@ESESSMB209.ericsson.se>, <50C8BCA5.8020702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0543CD@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0543CD@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Capture scene clarifications 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, 13 Dec 2012 01:53:29 -0000 Hello I'm not sure about this. Now we are saying that a capture scene entry does not represent an "entire scene" but now represents part of a scene. I think logically it works better if an individual capture is part of the scene and a capture scene entry depicts an "entire" scene from the viewpoint of the provider. If the provider now provides part scenes how does the consumer determine what's a full scene? It seems to me that whilst a Consumer may theoretically want to do all sorts of things with the captures ultimately its the provider that determines what can actually be provided. The consumer may just want to see "the boss" but the provider won't know that it has to provide individual captures when it does the initial advertisement. A provider may be reasonably concise (i.e. I have two capture scene entries choose one) or it may be verbose (i.e. I have several capture scene entries, I can provide all these different captures, here's the dependency between them). I've asked previously if simultaneous transmission sets are a mandatory to send. I don't think this has been determined. After the discussions in order to strike a balance between simple and complex cases i'd like to propose the following: 1. It is optional for a provider to send a simultaneous transmission set. 2. If the provider does not send a simultaneous transmission set: 2a. if multiple scenes are advertised it is assumed that they can be provided simultaneously. 2b. if multiple capture scene entries are sent in a scene then the consumer must chose one capture scene entry. 3. If the provider does sent a simultaneous transmission set: 3a. if multiple scenes are advertised simultaneity constraints are derived from the simultaneous transmission set. 3b. if multiple capture scene entries are sent in a scene then the consumer SHOULD close on capture scene entry but may chose captures based on the simultaneous transmission set. Regards, Christian On 13/12/2012 7:37 AM, Christer Holmberg wrote: > Hi, > > I'm putting the other discussion on hold for the moment, because I think we are starting to find some common ground in this one :) > >>>>>>>>> With regards to simultaneous sets I think we need to resolve what >>>>>>>>> capture scene entries represent. Currently the framework says that >>>>>>>>> it must be possible to send all captures in a Capture Scene Entry >>>>>>>>> simultaneously. To me logically speaking a capture scene entry is >>>>>>>>> effectively a simultaneous transmission set. To send effectively >>>>>>>>> the same information twice seems to me to be abit of a waste. >>>>>>>> [Duckworth, Mark] It isn't supposed to be the same information. >>>>>>>> The framework says "The simultaneous transmission sets MUST allow >>>>>>>> all the media captures in a particular capture scene entry to be used simultaneously." So all the media captures from a particular capture >>>>>>>> scene entry must also appear together in a simultaneous transmission set. But that >>>>>simultaneous transmission set could also include more media captures, not just media captures that appear in the same capture scene entry. >>>>>>> I agree to the understanding, but I still question the need. >>>>>>> >>>>>>> Why can't the "additional captures" be part of a dedicated capture scene entry? >>>>>> I guess the question is whether you think the provider can anticipate >>>>>> and advertise every possible combination that a receiver might desire. >>>>>> >>>>>> An example that has been given various times is a recipient that >>>>>> wants to always receive the capture that includes his boss, even when >>>>>> the boss isn't speaking. >>>>>> >>>>>> And he wants this in combination with some other captures that might >>>>>> be some conventional scene entry. So this might mean one full scene >>>>>> entry plus one capture from some other scene entry. Or it might mean *parts* of two scene entries to assemble something useful that always includes the boss. >>>>> You can achieve this e.g. using two separate SCENES: one SCENE with a capture scene entry that contains the full scene capture, and another SCENE with a capture scene entry that contains the boss capture. >>>> My assumption was that the boss is not everyone's boss, or known to be special in any way to the providing site. Rather he is important only to the recipient(s) in one of the other rooms. >>>> >>>> Stated more abstractly, the receiver has special interest in one of the provider's captures that the provider does not realize is of more interest than any of its other captures. >>> So, if I understand you correctly, the provider could e.g: >> There are many things a provider *could* do. Many of them don't make sense, or IMO are a bad idea. >> >>> 1) Provide a single SCENE with a capture scene entry that contains the "full room", and individual captures of each participant. >> I guess you mean that a single scene *entry* contains both the "full room" capture and the individual captures? >> >> IMO that is contrary to the intent of a scene entry. The entry has >> redundant information, and requires a recipient with no special needs to >> analyze it and decide it could simply render *either* the "full room" >> capture, or all the other captures in the entry. This is hard. >> >> Rather, I would think this same information would be represented better >> as two scene entries: >> >> - an entry with the single "full room" capture >> - an entry with individual captures for each participant. >> >> Each of these provides a full rendering of the room, in a different way. > Ok, let's go with that for now :) > > So, we have a single SCENE, which has two associated CSEs (Capture Scene Entries): > > - "full room" CSE (capture of full room) > - "individual" CSE (captures of each participant) > >>> Of the individual participant captures, the receiver will then only choose the capture associated with the important participant - ie the receiver is not mandated to receive everything in the chosen capture scene entry; >> With the alternative I just mentioned, a receiver with no special >> interests could then choose one of those entries that best meets its >> needs and capabilities. E.g. if it has enough displays and decoders to >> receive all the individual captures, then that might be the better >> choice. If it doesn't have enough resources to do that then it could >> simply choose the single capture full room entry. > Agree. > >> A receiver that has special interest in one participant (the boss) might >> then decide to receive the entry with the full room capture, and also >> the one capture for the boss from the entry that has all the individual >> captures. > Almost agree :) > > In my opinion, the receiver would decide two receive both CSEs, but it would indicate that from the individual CSE it only wants to "boss" capture. > > So, the end result is really the same. The only different is that, in my opinion, the receiver must always pick a CSE (but it may choose which captures it wants). > > The advantage is that we then only need to advertise simultanous CSE sets - not simultanous capture sets - as it is assumed that a provider can always provide all captures associated with a CSE. > > (This of course means we would need to allow picking multiple CSEs from a single SCENE.) > > Regards, > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Dec 12 19:36: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 79CD721F8859 for ; Wed, 12 Dec 2012 19:36:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pgH57PYokFe for ; Wed, 12 Dec 2012 19:36:55 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id BE82121F8858 for ; Wed, 12 Dec 2012 19:36:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMEAFVMyVB20S1O/2dsb2JhbAANOINIuhsEBIEbg1AbJT0WGAMCAQIBSw0IAQGyQJN4kQ4DqVg Received: from ppp118-209-45-78.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.78]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2012 14:06:53 +1030 Message-ID: <50C94D4F.3010308@nteczone.com> Date: Thu, 13 Dec 2012 14:36:47 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Capture Attribute Discussion X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 03:36:55 -0000 Hello, From the notes from the Atlanta IETF meeting it seemed that there was some support for at least some of the attributes in draft-groves-clue-capture-attr-00. From the notes it didn't seem like there was much discussion regarding the individual attributes. So i'd like to start a thread for each of the individual proposed attributes to see people's opinions. The attributes are: 4.1 Presentation 4.2. View 4.3. Language 4.4. Role 4.5. Priority 4.6. Others 4.6.1. Dynamic 4.6.2. Embedded Text 4.6.3. Supplementary Description 4.6.4. Telepresence I think once we get a better view on the scope of these additional parameters we can then discuss whether the existing Content attribute can be removed. Regards, Christian From Christian.Groves@nteczone.com Wed Dec 12 19:37:01 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11CC21F8875 for ; Wed, 12 Dec 2012 19:37:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVmlVyoovmF6 for ; Wed, 12 Dec 2012 19:37:01 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 45F3E21F8870 for ; Wed, 12 Dec 2012 19:37:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqICAFVMyVB20S1O/2dsb2JhbAANOINIuz6DUBsVED0WGAMCAQIBSw0IAQGyQJN4kQ4DqVg Received: from ppp118-209-45-78.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.78]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2012 14:07:00 +1030 Message-ID: <50C94D57.5030405@nteczone.com> Date: Thu, 13 Dec 2012 14:36:55 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Capture Attribute Discussion: 4.1 Presentation 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, 13 Dec 2012 03:37:02 -0000 Hello The presentation attribute is described in draft-groves-clue-capture-attr: "4.1. Presentation This attribute indicates that the capture originates from a presentation device, that is one that provides supplementary information to a conference through slides, video, still images, data etc. Where more information is known about the capture it may be expanded hierarchically to indicate the different types of presentation media, e.g. presentation.slides, presentation.image etc. Note: It is expected that a number of keywords will be defined that provide more detail on the type of presentation." The intention is that this attribute replaces the Content value "slides". Does any one have concerns about adding an attribute for this to the framework? Regards, Christian From Christian.Groves@nteczone.com Wed Dec 12 19:37:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADEE21F8859 for ; Wed, 12 Dec 2012 19:37:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DV3dxTc8kTRC for ; Wed, 12 Dec 2012 19:37:04 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id AEEC821F8865 for ; Wed, 12 Dec 2012 19:37:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqICAFVMyVB20S1O/2dsb2JhbAANOINIuz6DUBsVBgo9FhgDAgECAUsNCAEBskCTeJEOA6lY Received: from ppp118-209-45-78.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.78]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2012 14:07:02 +1030 Message-ID: <50C94D5A.6070308@nteczone.com> Date: Thu, 13 Dec 2012 14:36:58 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Capture Attribute Discussion: 4.2 View 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, 13 Dec 2012 03:37:04 -0000 Hello The view attribute is described in draft-groves-clue-capture-attr: "4.2. View The Area of capture attribute provides a physical indication of a region that the media capture captures. However the consumer does not know what this physical region relates to. In discussions on the IETF mailing list it is apparent that some people propose to use the "Description" attribute to describe a scene. This is a free text field and as such can be used to signal any piece of information. This leads to problems with interoperability if this field is automatically processed. For interoperability purposes it is proposed to introduce a set of keywords that could be used as a basis for the selection of captures. It is envisaged that this list would be extendable to allow for future uses not covered by the initial specification. Therefore it is proposed to introduce a number of keywords (that may be expanded) indicating what the spatial region relates to? I.e. Room, table, etc. this is an initial description of an attribute introducing these keywords. This attribute provides a textual description of the area that a media capture captures. This provides supplementary information in addition to the spatial information (i.e. area of capture) regarding the region that is captured. Room - Captures the entire scene. Table - Captures the conference table with seated participants Individual - Captures an individual participant Lectern - Captures the region of the lectern including the presenter in classroom style conference Audience - Captures a region showing the audience in a classroom style conference. Others - TBD" The intention is to have an standardised set of labels to describe what view the capture relates to. Does any one have concerns over the principle of being able to describe views in a standard manner? If there's in principle agreement then I think we can discuss exactly what values/labels we define and how they are extensible. Regards, Christian From Christian.Groves@nteczone.com Wed Dec 12 19:37: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 AF30321F8870 for ; Wed, 12 Dec 2012 19:37:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKlIu97tafV1 for ; Wed, 12 Dec 2012 19:37:11 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id EBAE221F8858 for ; Wed, 12 Dec 2012 19:37:10 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqICAFVMyVB20S1O/2dsb2JhbAANOINIuz6DUBsVED0WGAMCAQIBSw0IAQGyQJN4kQ4DqVg Received: from ppp118-209-45-78.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.78]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2012 14:07:10 +1030 Message-ID: <50C94D60.9000003@nteczone.com> Date: Thu, 13 Dec 2012 14:37:04 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Capture Attribute Discussion: 4.4. Role 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, 13 Dec 2012 03:37:11 -0000 Hello The role attribute is described in draft-groves-clue-capture-attr: "4.4. Role The original definition of "Content" allows the indication that a particular media stream is related to the speaker. CLUE should also allow this identification for captures. In addition with the advent of XCON there may be other formal roles that may be associated with media/captures. For instance: a remote end may like to always view the floor controller. It is envisaged that a remote end may also chose captures depending on the role of the person/s captured. For example: the people at the remote end may wish to always view the chairmen. This indicates that the capture is associated with an entity that has a particular role in the conference. The values are: Speaker - indicates that the capture relates to the current speaker Floor - indicates that the capture relates to the current floor controller of the conference Chairman- indicates who the chairman of the meeting is. Others - ?" The intention of this attribute is to have a standardised means of indicating the status of a person associated with a capture. As discussed in another thread a consumer might always want to select a capture associated with the "boss". The "role" attribute could be the mechanism to indicate this. It was also noted in discussions this could be extended to apply to presentations to refer to materials e.g. agenda, report, etc. Does anyone have concerns with adding this capability to the framework? Like the view attribute if agree din principle I think we can have a discussion about suitable labels and extension mechanisms. Regards, Christian From Christian.Groves@nteczone.com Wed Dec 12 19:37:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B3721F8865 for ; Wed, 12 Dec 2012 19:37:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfNjWod6wELa for ; Wed, 12 Dec 2012 19:37:24 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id D9C4B21F88A4 for ; Wed, 12 Dec 2012 19:37:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqICAFVMyVB20S1O/2dsb2JhbAANOINIuz6DUBsbCj0WGAMCAQIBSw0IAQGyQJN4jGCELgOSVpcCgVA Received: from ppp118-209-45-78.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.78]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2012 14:07:22 +1030 Message-ID: <50C94D64.1070105@nteczone.com> Date: Thu, 13 Dec 2012 14:37:08 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Capture Attribute Discussion: 4.5. Priority 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, 13 Dec 2012 03:37:24 -0000 Hello The priority attribute is described in draft-groves-clue-capture-attr: "4.5. Priority As has been highlighted in discussions on the CLUE mailing list there appears to be some desire to provide some relative priority between captures when multiple alternatives are supplied. This priority can be used to determine which captures contain the most important information (according to the provider). This may be important in case where the consumer has limited resources and can on render a subset of captures. Priority may also be advantageous in congestion scenarios where media from one capture may be favoured over other captures in any control algorithms. This could be supplied via "ordering" in a CLUE data structure however this may be problematic if people assume some spatial meaning behind ordering, i.e. given three captures VC1, VC2, VC3: it would be natural to send VC1,VC2,VC3 if the images are composed this way. However if your boss sits in the middle view the priority may be VC2,VC1,VC3. Explicit signalling is better. Additionally currently there are no hints to relative priority among captures from different capture scenes. In order to prevent any misunderstanding with implicit ordering a numeric number that may be assigned to each capture. The "priority" attribute indicates a relative priority between captures. For example it is possible to assign a priority between two presentation captures that would allow a remote endpoint to determine which presentation is more important. Priority is assigned at the individual capture level. It represents the provider's view of the relative priority between captures with a priority. The same priority number may be used across multiple captures. It indicates they are equally as important. If no priority is assigned no assumptions regarding relative important of the capture can be assumed." In recent discussions about clarifications for scenes I think it was agreed? that the framework syntax doesn't imply any relative priority. So if a priority mechanism is needed then an attribute would be required. Priority may be needed if the metadata (other attributes) isn't sufficient to describe a capture. This attribute isn't motivated by support for any preference or emergency scheme. Do people have concerns about adding this to the framework? Regards, Christian From Christian.Groves@nteczone.com Wed Dec 12 19:37: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 A8ADC21F8882 for ; Wed, 12 Dec 2012 19:37:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWCt3uIbpLt7 for ; Wed, 12 Dec 2012 19:37:38 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id CCD5321F8867 for ; Wed, 12 Dec 2012 19:37:37 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqICAFVMyVB20S1O/2dsb2JhbAANOINIuz6DUBsVED0WGAMCAQIBSw0IAQESA7Irk3iRDgOSVpcC Received: from ppp118-209-45-78.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.78]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2012 14:07:35 +1030 Message-ID: <50C94D7B.6050300@nteczone.com> Date: Thu, 13 Dec 2012 14:37:31 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Capture Attribute Discussion: 4.6.1 Dynamic 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, 13 Dec 2012 03:37:39 -0000 Hello, The dynamic attribute is described in draft-groves-clue-capture-attr: "4.6.1. Dynamic In the framework it has been assumed that the capture point is a fixed point within a telepresence session. However depending on the conference scenario this may not be the case. In tele-medical or tele-education cases a conference may include cameras that move during the conference. For example: a camera may be placed at different positions in order to provide the best angle to capture a work task, or may include a camera worn by a participant. This would have an effect of changing the capture point, capture axis and area of capture. In order that the remote endpoint can chose to layout/ render the capture appropriately an indication of if the camera is dynamic should be indicated in the initial capture description. This indicates that the spatial information related to the capture may be dynamic and change through the conference. Thus captures may be characterised as static, dynamic or highly dynamic. The capture point of a static capture does not move for the life of the conference. The capture point of dynamic captures is categorised by a change in position followed by a reasonable period of stability. High dynamic captures are categorised by a capture point that is constantly moving. This may assist an endpoint in determining the correct display layout. If the "area of capture", "capture point" and "line of capture" attributes are included with dynamic or highly dynamic captures they indicate spatial information at the time a CLUE message is sent. No information regarding future spatial information should be assumed." Hopefully the above text is sufficient to explain the intention of the attribute. Does anybody have concerns about adding it to the framework? Regards, Christian From Christian.Groves@nteczone.com Wed Dec 12 19:37: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 1683521F8882 for ; Wed, 12 Dec 2012 19:37:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5KLD0oLr9tW for ; Wed, 12 Dec 2012 19:37:39 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 361CB21F8865 for ; Wed, 12 Dec 2012 19:37:38 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqICAFVMyVB20S1O/2dsb2JhbAANOINIuz6DUBsVED0WGAMCAQIBSw0IAQGyQJN4kQ4DqVg Received: from ppp118-209-45-78.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.78]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2012 14:07:38 +1030 Message-ID: <50C94D7E.9080906@nteczone.com> Date: Thu, 13 Dec 2012 14:37:34 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Capture Attribute Discussion: 4.6.2. Embedded Text 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, 13 Dec 2012 03:37:40 -0000 Hello, The embedded text attribute is described in draft-groves-clue-capture-attr: "4.6.2. Embedded Text In accessible conferences textual information may be added to a capture before it is transmitted to the remote end. In the case where multiple video captures are presented the remote end may benefit from the ability to choose a video stream containing text over one that does not. This attribute indicates that a capture provides embedded textual information. For example the video capture may contain speech to text information composed with the video image. This attribute is only applicable to video captures and presentation streams with visual information." Does any one have concerns about adding this to the framework? Regards, Christian From Christian.Groves@nteczone.com Wed Dec 12 19:37: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 C48AC21F88B7 for ; Wed, 12 Dec 2012 19:37:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcAt2sQnzWeh for ; Wed, 12 Dec 2012 19:37:44 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id F225621F88B2 for ; Wed, 12 Dec 2012 19:37:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqICAFVMyVB20S1O/2dsb2JhbAANOINIuz6DUBsVED0WGAMCAQIBSw0IAQGyQJN4kQ4DqVg Received: from ppp118-209-45-78.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.78]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2012 14:07:42 +1030 Message-ID: <50C94D81.2020401@nteczone.com> Date: Thu, 13 Dec 2012 14:37:37 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Capture Attribute Discussion: 4.6.3. Supplementary Description 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, 13 Dec 2012 03:37:44 -0000 Hello, The supplementary description attribute is described in draft-groves-clue-capture-attr: "4.6.3. Supplementary Description Some conferences utilise translators or facilitators that provide an additional audio stream (i.e. a translation or description of the conference). These persons may not be pictured in a video capture. Where multiple audio captures are presented it may be advantageous for an endpoint to select a supplementary stream instead of or additional to an audio feed associated with the participants from a main video capture. Therefore an attribute is proposed for this. Depending on the results of the discussion of the source device this parameter may be another value for the source. This indicates that a capture provides additional description of the conference. For example an additional audio stream that provides a commentary of a conference that provides supplementary information (e.g. a translation) or extra information to participants in accessible conferences." Does any one have concerns about adding this to the framework? Regards, Christian From Christian.Groves@nteczone.com Wed Dec 12 19:37: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 93BF721F85C6 for ; Wed, 12 Dec 2012 19:37:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7k5FhlHRZvS for ; Wed, 12 Dec 2012 19:37:53 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id F012621F8593 for ; Wed, 12 Dec 2012 19:37:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqICAFVMyVB20S1O/2dsb2JhbAANOINIuz6DUBsVED0WGAMCAQIBSw0IAQGyQJN4kQ4DkhyXPA Received: from ppp118-209-45-78.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.78]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2012 14:07:47 +1030 Message-ID: <50C94D86.8050508@nteczone.com> Date: Thu, 13 Dec 2012 14:37:42 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Capture Attribute Discussion: 4.6.4. Telepresence 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, 13 Dec 2012 03:37:53 -0000 Hello, The telepresence attribute is described in draft-groves-clue-capture-attr: "4.6.4. Telepresence In certain use cases scenarios it is important to maintain a feeling of "Telepresence" associated with captures when they are played at the remote end. For example: in medical use cases it is important to maintain the colour of images. It is important to note that CLUE is used to describe multi-stream conferences. These may or may not be "telepresence" conferences. Alternatively it could be assumed that all captures possess this attribute and the only captures not subject to processing to create "telepresence" this are those marked with "presentation". We did discuss the aspect of how an endpoint determines if a capture relates to a computer generated image or a real environment. An endpoint may apply different images processing depending on a source, i.e. it may or not apply image processing to adjust lighting levels for a telepresence experience. This parameter indicates that "telepresence" should be associated with the capture. E.g. real world environmental conditions are associated with this capture. Lighting, spatial and timing information are important aspects of the telepresence session. The remote should apply the appropriate capture processing to maintain integrity of this information. For example: the colour related information associated with the original capture is important and should be replicated when displayed/played." Does any one have concerns about adding this to the framework? Regards, Christian From Christian.Groves@nteczone.com Wed Dec 12 19:42: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 98A1521F88A4 for ; Wed, 12 Dec 2012 19:42:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WhtQoGpIFo0 for ; Wed, 12 Dec 2012 19:42:09 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 1385021F885E for ; Wed, 12 Dec 2012 19:42:08 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAFVMyVB20S1O/2dsb2JhbAANOL8Gg1AwED0WGAMCAQIBSw0IAQGyQJN4iS6HYAOSHJc8 Received: from ppp118-209-45-78.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.45.78]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2012 14:12:07 +1030 Message-ID: <50C94E8B.5070306@nteczone.com> Date: Thu, 13 Dec 2012 14:42:03 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Capture Attribute Discussion: 4.3. Language 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, 13 Dec 2012 03:42:09 -0000 Hello The language attribute is described in draft-groves-clue-capture-attr: "4.3. Language As indicated in the discussion in section 2 captures may be offered in different languages in case of multi-lingual and/or accessible conferences. It is important to allow the remote end to distinguish between them. It is noted that SDP already contains a language attribute however this may not be available at the time that an initial CLUE message is sent. Therefore a language attribute is proposed for CLUE. This indicates which language is associated with the capture. For example: it may provide a language associated with an audio capture or a language associated with a video capture when sign interpretation or text is used. The possible values for a language tag are the values of the 'Subtag' column for the "Type: language" entries in the "Language Subtag Registry" defined in [RFC5646]" Are there any concerns about adding a language attribute to the framework? Regards, Christian From gunnar.hellstrom@omnitor.se Wed Dec 12 23:01: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 E970921F8AAD for ; Wed, 12 Dec 2012 23:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+9pK7sv4ITU for ; Wed, 12 Dec 2012 23:01:37 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 00D8221F8AAC for ; Wed, 12 Dec 2012 23:01:36 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 13 Dec 2012 08:01:29 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id ED2DD3A11A for ; Thu, 13 Dec 2012 08:01:28 +0100 (CET) Message-ID: <50C97D49.7020808@omnitor.se> Date: Thu, 13 Dec 2012 08:01:29 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C94E8B.5070306@nteczone.com> In-Reply-To: <50C94E8B.5070306@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Capture Attribute Discussion: 4.3. Language 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, 13 Dec 2012 07:01:38 -0000 Hi, You will need to have a possibility to have multiple language values to a capture. An example is a video with one sign language, and embedded text in a written language. ( I have not followed the discussion, so I do not know if you can have a language attribute to the text attribute. ) Another example is audio from the main speaker in a physical conference. The speaker may switch, and thereby the audio language in the main audio capture. ( the speech may be made understandable by embedded text translation in the video capture ) Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2012-12-13 04:42, Christian Groves wrote: > Hello > > The language attribute is described in draft-groves-clue-capture-attr: > > "4.3. Language > > As indicated in the discussion in section 2 captures may be offered > in different languages in case of multi-lingual and/or accessible > conferences. It is important to allow the remote end to distinguish > between them. It is noted that SDP already contains a language > attribute however this may not be available at the time that an > initial CLUE message is sent. Therefore a language attribute is > proposed for CLUE. > > This indicates which language is associated with the capture. For > example: it may provide a language associated with an audio capture > or a language associated with a video capture when sign > interpretation or text is used. The possible values for a language > tag are the values of the 'Subtag' column for the "Type: language" > entries in the "Language Subtag Registry" defined in [RFC5646]" > > Are there any concerns about adding a language attribute to the > framework? > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From gunnar.hellstrom@omnitor.se Wed Dec 12 23:13: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 8594721F85E8 for ; Wed, 12 Dec 2012 23:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id octfleswm9Gj for ; Wed, 12 Dec 2012 23:13:41 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 7EF9A21F8AA9 for ; Wed, 12 Dec 2012 23:13:40 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 13 Dec 2012 08:13:33 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id 51B813A1D8 for ; Thu, 13 Dec 2012 08:13:33 +0100 (CET) Message-ID: <50C9801D.6080202@omnitor.se> Date: Thu, 13 Dec 2012 08:13:33 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C94D7E.9080906@nteczone.com> In-Reply-To: <50C94D7E.9080906@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Capture Attribute Discussion: 4.6.2. Embedded Text 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, 13 Dec 2012 07:13:41 -0000 This looks good, I agree. --------------------------------------- But I also strongly suggest that you define text capture as a proper capture in its own right. The method to display text embedded in video is just a historic solution as an afterthought, both destroying part of the video image and sometimes making text hard to read. There are three natural modalities in human communication visual, textual and audible. Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2012-12-13 04:37, Christian Groves wrote: > Hello, > > The embedded text attribute is described in > draft-groves-clue-capture-attr: > > "4.6.2. Embedded Text > > In accessible conferences textual information may be added to a > capture before it is transmitted to the remote end. In the case > where multiple video captures are presented the remote end may > benefit from the ability to choose a video stream containing text > over one that does not. > > This attribute indicates that a capture provides embedded textual > information. For example the video capture may contain speech to > text information composed with the video image. This attribute is > only applicable to video captures and presentation streams with > visual information." > > Does any one have concerns about adding this to the framework? > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Thu Dec 13 01:49: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 11B0A21F885B for ; Thu, 13 Dec 2012 01:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQfLa4Cj1gFM for ; Thu, 13 Dec 2012 01:49:16 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8229A21F8846 for ; Thu, 13 Dec 2012 01:49:15 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-25-50c9a49a853f Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C6.97.04318.A94A9C05; Thu, 13 Dec 2012 10:49:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.001; Thu, 13 Dec 2012 10:49:14 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3JLnoSzk8+n3np90eOVjDiWPg3KwGoy/AQAExSlQAAHAv6AACnaFYAACg6MQAAf6TcoAALqfGAAAVRHN8AADi8AABZpj/QAAozp4AACBBw4gAJ4SUAABJT77A= Date: Thu, 13 Dec 2012 09:49:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B054A9B@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <50C61E8E.1090805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053E9D@ESESSMB209.ericsson.se>, <50C8BCA5.8020702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0543CD@ESESSMB209.ericsson.se> <50C93510.7080502@nteczone.com> In-Reply-To: <50C93510.7080502@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvje6sJScDDBY/0bL48r6RxWL/qcvM DkweS5b8ZPJYcX4mSwBTFJdNSmpOZllqkb5dAldGe+tX5oIW94qFz9eyNzBusOxi5OSQEDCR eN9wjRHCFpO4cG89WxcjF4eQwCFGic1NH5ggnCWMEku7d7N2MXJwsAlYSHT/0wZpEBEIl+jY dgWsWVjAQOLkxxvsEHFDia1L5rCC9IoIdDFKXF/7gAkkwSKgKtH99ikLiM0r4C3x8PlnqG03 WSUm7AdxODk4BXQkLrb8A7MZgU76fmoNWDOzgLjErSfzmSBOFZBYsuc8M4QtKvHy8T+w4yQE FCWW98tBlOtILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk6iwkLbOQtMxC0rKAkWUVI3tu YmZOern5JkZgNBzc8ttgB+Om+2KHGKU5WJTEefVU9/sLCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYDRR3ZwoHP5dp+Nb60KLzvClrVUGdkf0fyqvVj1nHbnc89iTtd71YmvTO3xLrnNdWrKr 6HK0nfPqbPnF9xZwLrb+bsS1oUA897NZSmeJ13KVEF69W4n7ZJ+4i3juDlD7EhU777gcx/bJ 5ys3SwX+O6W0S+ZmFseD9oPZgtNKo857FLHwnZLkVmIpzkg01GIuKk4EANkWeSpUAgAA Subject: Re: [clue] Capture scene clarifications 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, 13 Dec 2012 09:49:17 -0000 Hi, >I'm not sure about this. Now we are saying that a capture scene entry does= not represent an "entire scene" but now represents part of a scene.=20 > > I think logically it works better if an individual capture is part of the= scene and a capture scene entry depicts an "entire" scene from the viewpoi= nt of the provider. If the provider now provides part scenes how does the c= onsumer=20 > determine what's a full scene? I agree, and my understanding that in the example both CSEs DO represent an= entire scene: one CSE contains a single "full room" capture, and the other= CSE contains individual participant captures (all participant captures tog= ether forms the entire scene). > It seems to me that whilst a Consumer may theoretically want to do all so= rts of things with the captures ultimately its the provider that determines= what can actually be provided. The consumer may just want to see "the boss= " but the=20 > provider won't know that it has to provide individual captures when it do= es the initial advertisement. But, if the provider CAN provide individual captures, I think it would adve= rtise them. If it can't, then the receiver cannot request the "boss" captur= e. > A provider may be reasonably concise (i.e. I have two capture scene entri= es choose one) or it may be verbose (i.e. I have several capture scene entr= ies, I can provide all these different captures, here's the dependency betw= een them). Exactly. And, in the example below, the provider would indicate that it can= provide both CSEs simultaneously.=20 > I've asked previously if simultaneous transmission sets are a mandatory t= o send. I don't think this has been determined. In this case we would be talking about simultaneous capture scene entries. >After the discussions in order to strike a balance between simple and comp= lex cases i'd like to propose the following: > >1. It is optional for a provider to send a simultaneous transmission set. >2. If the provider does not send a simultaneous transmission set: >2a. if multiple scenes are advertised it is assumed that they can be provi= ded simultaneously. I think that is ok. >2b. if multiple capture scene entries are sent in a scene then the consume= r must chose one capture scene entry. Well, in order for the example to work, the receiver would have to be able = to choose both the "full scene" CSE and the "individual" CSE (from the "ind= ividual" CSE the receiver would then only take the boss capture". But, again, the provider would have to explicitly indicate that it can prov= ide both CSEs simultaneously. >3. If the provider does sent a simultaneous transmission set: >3a. if multiple scenes are advertised simultaneity constraints are derived= from the simultaneous transmission set. >3b. if multiple capture scene entries are sent in a scene then the consume= r SHOULD close on capture scene entry but may chose captures based on the s= imultaneous transmission set. If the receiver is allowed to choose captures from multiple CSEs (associate= d with the same scene), why can't it then choose multiple CSEs? Regards, Christer On 13/12/2012 7:37 AM, Christer Holmberg wrote: > Hi, > > I'm putting the other discussion on hold for the moment, because I=20 > think we are starting to find some common ground in this one :) > >>>>>>>>> With regards to simultaneous sets I think we need to resolve=20 >>>>>>>>> what capture scene entries represent. Currently the framework=20 >>>>>>>>> says that it must be possible to send all captures in a=20 >>>>>>>>> Capture Scene Entry simultaneously. To me logically speaking a=20 >>>>>>>>> capture scene entry is effectively a simultaneous transmission=20 >>>>>>>>> set. To send effectively the same information twice seems to me t= o be abit of a waste. >>>>>>>> [Duckworth, Mark] It isn't supposed to be the same information. >>>>>>>> The framework says "The simultaneous transmission sets MUST=20 >>>>>>>> allow all the media captures in a particular capture scene=20 >>>>>>>> entry to be used simultaneously." So all the media captures from = a particular capture scene entry must also appear together in a simultaneou= s transmission set. But that >>>>>simultaneous transmission set could also= include more media captures, not just media captures that appear in the sa= me capture scene entry. >>>>>>> I agree to the understanding, but I still question the need. >>>>>>> >>>>>>> Why can't the "additional captures" be part of a dedicated capture = scene entry? >>>>>> I guess the question is whether you think the provider can=20 >>>>>> anticipate and advertise every possible combination that a receiver = might desire. >>>>>> >>>>>> An example that has been given various times is a recipient that=20 >>>>>> wants to always receive the capture that includes his boss, even=20 >>>>>> when the boss isn't speaking. >>>>>> >>>>>> And he wants this in combination with some other captures that=20 >>>>>> might be some conventional scene entry. So this might mean one=20 >>>>>> full scene entry plus one capture from some other scene entry. Or it= might mean *parts* of two scene entries to assemble something useful that = always includes the boss. >>>>> You can achieve this e.g. using two separate SCENES: one SCENE with a= capture scene entry that contains the full scene capture, and another SCEN= E with a capture scene entry that contains the boss capture. >>>> My assumption was that the boss is not everyone's boss, or known to be= special in any way to the providing site. Rather he is important only to t= he recipient(s) in one of the other rooms. >>>> >>>> Stated more abstractly, the receiver has special interest in one of th= e provider's captures that the provider does not realize is of more interes= t than any of its other captures. >>> So, if I understand you correctly, the provider could e.g: >> There are many things a provider *could* do. Many of them don't make sen= se, or IMO are a bad idea. >> >>> 1) Provide a single SCENE with a capture scene entry that contains the = "full room", and individual captures of each participant. >> I guess you mean that a single scene *entry* contains both the "full roo= m" capture and the individual captures? >> >> IMO that is contrary to the intent of a scene entry. The entry has=20 >> redundant information, and requires a recipient with no special needs=20 >> to analyze it and decide it could simply render *either* the "full room" >> capture, or all the other captures in the entry. This is hard. >> >> Rather, I would think this same information would be represented=20 >> better as two scene entries: >> >> - an entry with the single "full room" capture >> - an entry with individual captures for each participant. >> >> Each of these provides a full rendering of the room, in a different way. > Ok, let's go with that for now :) > > So, we have a single SCENE, which has two associated CSEs (Capture Scene = Entries): > > - "full room" CSE (capture of full room) > - "individual" CSE (captures of each participant) > >>> Of the individual participant captures, the receiver will then only=20 >>> choose the capture associated with the important participant - ie=20 >>> the receiver is not mandated to receive everything in the chosen=20 >>> capture scene entry; >> With the alternative I just mentioned, a receiver with no special=20 >> interests could then choose one of those entries that best meets its=20 >> needs and capabilities. E.g. if it has enough displays and decoders=20 >> to receive all the individual captures, then that might be the better=20 >> choice. If it doesn't have enough resources to do that then it could=20 >> simply choose the single capture full room entry. > Agree. > >> A receiver that has special interest in one participant (the boss)=20 >> might then decide to receive the entry with the full room capture,=20 >> and also the one capture for the boss from the entry that has all the=20 >> individual captures. > Almost agree :) > > In my opinion, the receiver would decide two receive both CSEs, but it wo= uld indicate that from the individual CSE it only wants to "boss" capture. > > So, the end result is really the same. The only different is that, in my = opinion, the receiver must always pick a CSE (but it may choose which captu= res it wants). > > The advantage is that we then only need to advertise simultanous CSE sets= - not simultanous capture sets - as it is assumed that a provider can alwa= ys provide all captures associated with a CSE. > > (This of course means we would need to allow picking multiple CSEs=20 > from a single SCENE.) > > Regards, > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From apeppere@gmail.com Thu Dec 13 02:46: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 0CFC321F8910 for ; Thu, 13 Dec 2012 02:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSQoIOuQNQ+9 for ; Thu, 13 Dec 2012 02:46:10 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3509421F8863 for ; Thu, 13 Dec 2012 02:46:10 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so6159124qan.10 for ; Thu, 13 Dec 2012 02:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eDEVQulGb3Xcyb/WYi3ZzuUxt2cxrmHMe2Gz2yvkVNg=; b=SIu2xLDZ6aPVfSbvrsvT31nMuhaxyfg5dW0jbXrL48lNRqwaqFi6uIcdzvdAP5h90v Ufh2LsLrMumsuzXul9hrzsJFDmK/u6V2uacPkOlCegp2n1rgh9htMO6jPrmRH8E4QsYo fU2SRVz8enfL/sAF9uCpYV6SSNwmuNF4ravwwk5YYCEBPVJ62HtRWm6Lmqm5u5ppFtMT R2dHhn85TPhMYs/okg5XR35r/SFetqRs75//Wyo7IzYxnedioOmi/hE0GxW4PjFx0j68 SpMnJpbuo6hyr2oFrJLUPXO0hU3CwmQcZ2sNG2AyL1IxmzpwP+HlOuxInM6QoG7XizA+ ZzDw== MIME-Version: 1.0 Received: by 10.224.70.202 with SMTP id e10mr756401qaj.69.1355395569542; Thu, 13 Dec 2012 02:46:09 -0800 (PST) Received: by 10.49.62.131 with HTTP; Thu, 13 Dec 2012 02:46:09 -0800 (PST) In-Reply-To: <50C91F5C.8040206@nteczone.com> References: <50C91F5C.8040206@nteczone.com> Date: Thu, 13 Dec 2012 10:46:09 +0000 Message-ID: From: Andy Pepperell To: Christian Groves Content-Type: multipart/alternative; boundary=bcaec51b18e773e7e204d0b99f25 Cc: "clue@ietf.org" Subject: Re: [clue] Sending a configure 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, 13 Dec 2012 10:46:11 -0000 --bcaec51b18e773e7e204d0b99f25 Content-Type: text/plain; charset=ISO-8859-1 Hi Christian, The intent behind the use of "autonomously" there was just to re-iterate that this wouldn't be necessarily a consumer's "response" to the provider's advertisement, but more that even in the absence of any changed state on the provider there might be reasons for a new configure message from the consumer. This wasn't intended to refer to any SIP O/A changes, but more for things like the user of the consumer system choosing, say, to no longer want to view a presentation video stream or to receive a set of switched loudest speaker captures rather than pre-composed video streams from the provider (even if the provider offers both throughout). Your wording proposal does sound like a useful clarification I think, though it may also be worth continuing to make clear that the configure isn't strictly a response to the advertisement from the provider. Regards, Andy On Thu, Dec 13, 2012 at 12:20 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello, > > Section 9 of the framework states: > " The consumer is able to change its configuration of the provider's > encodings any number of times during the call, either in response to > a new capture advertisement from the provider or autonomously. The > consumer need not send a new configure message to the provider when > it receives a new capture advertisement from the provider unless the > contents of the new capture advertisement cause the consumer's > current configure message to become invalid." > > From the text I don't think its 100% clear what is meant by "or > autonomously". Does this relates to the signalling of CLUE i.e. sending a > Configure message? Does it relate to sending a new SDP O/A? Changing the > what RTP it sends autonomously? > > If we're only talking about sending a Configure message I would propose > that we change the first sentence to say: > "Once the consumer has received an advertisement it may change its > configuration of the provider's encodings any number of times during the > call by sending a new configure message." > > Regards, Christian > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --bcaec51b18e773e7e204d0b99f25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christian,

The intent behind the use of "a= utonomously" there was just to re-iterate that this wouldn't be ne= cessarily a consumer's "response" to the provider's adver= tisement, but more that even in the absence of any changed state on the pro= vider there might be reasons for a new configure message from the consumer.= This wasn't intended to refer to any SIP O/A changes, but more for thi= ngs like the user of the consumer system choosing, say, to no longer want t= o view a presentation video stream or to receive a set of switched loudest = speaker captures rather than pre-composed video streams from the provider (= even if the provider offers both throughout).

Your wording proposal does sound like a useful clarification= I think, though it may also be worth continuing to make clear that the con= figure isn't strictly a response to the advertisement from the provider= .

Regards,

Andy

On Thu, Dec 13, 2012 at 12:20 AM, Christian Gr= oves <Christian.Groves@nteczone.com> wrote:
Hello,

Section 9 of the framework states:
" The consumer is able to change its configuration of the provider'= ;s
=A0 =A0encodings any number of times during the call, either in response to=
=A0 =A0a new capture advertisement from the provider or autonomously. The =A0 =A0consumer need not send a new configure message to the provider when<= br> =A0 =A0it receives a new capture advertisement from the provider unless the=
=A0 =A0contents of the new capture advertisement cause the consumer's =A0 =A0current configure message to become invalid."

>From the text I don't think its 100% clear what is meant by "or au= tonomously". Does this relates to the signalling of CLUE i.e. sending = a Configure message? Does it relate to sending a new SDP O/A? Changing the = what RTP it sends autonomously?

If we're only talking about sending a Configure message I would propose= that we change the first sentence to say:
"Once the consumer has received an advertisement it may change its con= figuration of the provider's encodings any number of times during the c= all by sending a new configure message."

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

--bcaec51b18e773e7e204d0b99f25-- From stewe@stewe.org Thu Dec 13 08:24: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 98E7221F8AA2 for ; Thu, 13 Dec 2012 08:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEJgmnU1wYSE for ; Thu, 13 Dec 2012 08:24:30 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5F76221F8AF9 for ; Thu, 13 Dec 2012 08:24:29 -0800 (PST) Received: from mail95-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Dec 2012 16:24:25 +0000 Received: from mail95-tx2 (localhost [127.0.0.1]) by mail95-tx2-R.bigfish.com (Postfix) with ESMTP id 61E8234022D; Thu, 13 Dec 2012 16:24:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(z1036lz98dI1432I14ffIzz1de0h1202h1e76h1d1ah1d2ah1082kzz8275bh8275dh1033ILz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: pass (mail95-tx2: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail95-tx2 (localhost.localdomain [127.0.0.1]) by mail95-tx2 (MessageSwitch) id 1355415863386931_15827; Thu, 13 Dec 2012 16:24:23 +0000 (UTC) Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.253]) by mail95-tx2.bigfish.com (Postfix) with ESMTP id 280FB3C007F; Thu, 13 Dec 2012 16:24:23 +0000 (UTC) Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Dec 2012 16:24:17 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.114]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0245.002; Thu, 13 Dec 2012 16:24:16 +0000 From: Stephan Wenger To: "clue@ietf.org" Thread-Topic: MCU terminating CLUE, or passing through? was: Capture scene clarifications Thread-Index: AQHN2U5LIDwjtOUJjkaLndVJcxJw3Q== Date: Thu, 13 Dec 2012 16:24:16 +0000 Message-ID: In-Reply-To: <50C927A9.4030905@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.86.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <66C09DE4119A8145B207B24323A5D803@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: [clue] MCU terminating CLUE, or passing through? was: Capture scene clarifications 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, 13 Dec 2012 16:24:31 -0000 Hi all, On 12.12.2012 16:56 , "Christian Groves" wrote: > > >[...] > >> >> In the case I described, it happens that it is possible to let >> everybody see everybody else simultaneously without doing any >> switching or composing in the MCU. So what I described has the MCU >> directly "passing through" the captures it receives. In reality it >> would probably *also* advertise some other entries that are switched >> or composed in order to accommodate receivers that can only handle >> fewer (e.g. one) captures. > >[CNG] This is the point I was trying to understand, how you saw the MCU >being involved. You see the MCU as simply passing through the CLUE >Advertisements. In my mind I see CLUE not as an end-to-end protocol. >I.e. the MCU would effectively act as a CLUE endpoint and >"re-configures" any advertisements/configures sent to other endpoints. >I think this aspect is worth examining further. Do you in CLUE allow a >situation for a MCU to effectively "broadcast" advertisements i.e. from >room 1 to room 2 & 3 and then allow these rooms to response directly to >Room 1? etc. I don't want to see this important architectural point to be lost in the Capture Scene thread. Obviously, an MCU needs to intercept and (in many cases) interpret many of the CLUE messages.=20 The first question is: does the MCU also manipulate and/or potentially create on its own, CLUE messages. I believe the answer is "yes". We need this, because only the MCU knows whether, and how, it tiles up pictures in a video mixing scenario (there are many more use cases like this). The second question is: does the CLUE protocol suite "allow" an MCU to "effectively broadcast advertisements" (as Christian has put it), without manipulating them? My gut reaction to this is" let's not overshoot in terms of flexibility. I think we should make it clear that it is the responsibility of an MCU to consolidate room information it has received from receiving rooms and provide, based on its unified view, sensible choices for things like the selection of Capture scenes. (This is a bit of a departure from what I suggested in one of the early Andover meetings, where I suggested that everyone in the conference should have a full understanding of what's going on, so to be able to make sensible choices. The issue with this approach is that every vendor will have a different view what a "sensible" choice may be, and the result could well be a reduced user experience--and no one to blame for it. If the control lives in the MCU, then the MCU vendor is to blame, and no one else). Stephan =20 > > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue > From keith.drage@alcatel-lucent.com Thu Dec 13 09:04: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 EEB3E21F8B1A for ; Thu, 13 Dec 2012 09:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.129 X-Spam-Level: X-Spam-Status: No, score=-110.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id appBBbXNSzoU for ; Thu, 13 Dec 2012 09:04:25 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1E58821F89AE for ; Thu, 13 Dec 2012 09:04:24 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBDH3fH3025399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Dec 2012 18:04:21 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 13 Dec 2012 18:04:04 +0100 From: "DRAGE, Keith (Keith)" To: Christian Groves , "clue@ietf.org" Date: Thu, 13 Dec 2012 18:04:03 +0100 Thread-Topic: [clue] Capture Attribute Discussion: 4.6.4. Telepresence Thread-Index: Ac3Y41d7Dt3ObPdtS8CIZssHCz1Y3AAb7cGA Message-ID: References: <50C94D86.8050508@nteczone.com> In-Reply-To: <50C94D86.8050508@nteczone.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-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [clue] Capture Attribute Discussion: 4.6.4. Telepresence 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, 13 Dec 2012 17:04:26 -0000 This one seems so unspecific in its definition that I have no idea whether = it is useful.=20 There is nothing here that guarantees two devices will either set this or n= ot set this when an identical set of conditions and usages exist at the two= devices.=20 In other words, there is too much hand waving involved in deciding whether = it should be sent, and whether I can trust it if I receive it, to be useful= . I'd also question whether this is the right name for this concept, as I sus= pect many people have a view of telepresence that is wider than this, and w= ill assume that definition rather than the one provided (unspecific though = it is), with even more problems for interoperability. As a suggestion, is it not possible to list a set of capabilities, and assi= gn a precedence value to them, e.g. colour - apply a weighting of 90% in de= ciding the best capture. Regards Keith > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: 13 December 2012 03:38 > To: clue@ietf.org > Subject: [clue] Capture Attribute Discussion: 4.6.4. Telepresence >=20 > Hello, >=20 > The telepresence attribute is described in draft-groves-clue-capture-attr= : >=20 > "4.6.4. Telepresence >=20 > In certain use cases scenarios it is important to maintain a feeling > of "Telepresence" associated with captures when they are played at > the remote end. For example: in medical use cases it is important to > maintain the colour of images. It is important to note that CLUE is > used to describe multi-stream conferences. These may or may not be > "telepresence" conferences. Alternatively it could be assumed that > all captures possess this attribute and the only captures not subject > to processing to create "telepresence" this are those marked with > "presentation". We did discuss the aspect of how an endpoint > determines if a capture relates to a computer generated image or a > real environment. An endpoint may apply different images processing > depending on a source, i.e. it may or not apply image processing to > adjust lighting levels for a telepresence experience. >=20 > This parameter indicates that "telepresence" should be associated > with the capture. E.g. real world environmental conditions are > associated with this capture. Lighting, spatial and timing > information are important aspects of the telepresence session. The > remote should apply the appropriate capture processing to maintain > integrity of this information. For example: the colour related > information associated with the original capture is important and > should be replicated when displayed/played." >=20 >=20 > Does any one have concerns about adding this to the framework? >=20 > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From keith.drage@alcatel-lucent.com Thu Dec 13 09:10: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 8894B21F8A12 for ; Thu, 13 Dec 2012 09:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.99 X-Spam-Level: X-Spam-Status: No, score=-109.99 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt0dq9IMBAje for ; Thu, 13 Dec 2012 09:10:22 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 94BD821F8A0F for ; Thu, 13 Dec 2012 09:10:22 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBDH85H4012241 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Dec 2012 18:10:17 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 13 Dec 2012 18:09:56 +0100 From: "DRAGE, Keith (Keith)" To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "clue@ietf.org" Date: Thu, 13 Dec 2012 18:09:54 +0100 Thread-Topic: [clue] Capture Attribute Discussion: 4.6.2. Embedded Text Thread-Index: Ac3ZAWRh8b4oon1nSiejLQtxaS+ZhAAUylvA Message-ID: References: <50C94D7E.9080906@nteczone.com> <50C9801D.6080202@omnitor.se> In-Reply-To: <50C9801D.6080202@omnitor.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [clue] Capture Attribute Discussion: 4.6.2. Embedded Text 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, 13 Dec 2012 17:10:24 -0000 What are the language and alphabet restrictions that will exist here? Keith > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Gunnar Hellstr=F6m > Sent: 13 December 2012 07:14 > To: clue@ietf.org > Subject: Re: [clue] Capture Attribute Discussion: 4.6.2. Embedded Text >=20 > This looks good, I agree. >=20 > --------------------------------------- >=20 > But I also strongly suggest that you define text capture as a proper > capture in its own right. >=20 > The method to display text embedded in video is just a historic solution > as an afterthought, both destroying part of the video image and > sometimes making text hard to read. >=20 > There are three natural modalities in human communication visual, > textual and audible. >=20 >=20 >=20 > Gunnar >=20 > ___________________________________________________ > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46708204288 >=20 > On 2012-12-13 04:37, Christian Groves wrote: > > Hello, > > > > The embedded text attribute is described in > > draft-groves-clue-capture-attr: > > > > "4.6.2. Embedded Text > > > > In accessible conferences textual information may be added to a > > capture before it is transmitted to the remote end. In the case > > where multiple video captures are presented the remote end may > > benefit from the ability to choose a video stream containing text > > over one that does not. > > > > This attribute indicates that a capture provides embedded textual > > information. For example the video capture may contain speech to > > text information composed with the video image. This attribute is > > only applicable to video captures and presentation streams with > > visual information." > > > > Does any one have concerns about adding this to the framework? > > > > Regards, Christian > > _______________________________________________ > > 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 keith.drage@alcatel-lucent.com Thu Dec 13 09:12: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 E129D21F8AC9 for ; Thu, 13 Dec 2012 09:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.136 X-Spam-Level: X-Spam-Status: No, score=-110.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8zPVye9DcML for ; Thu, 13 Dec 2012 09:12:35 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1A91321F8A03 for ; Thu, 13 Dec 2012 09:12:34 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBDH6qSV026822 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Dec 2012 18:07:00 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 13 Dec 2012 18:06:56 +0100 From: "DRAGE, Keith (Keith)" To: Christian Groves , "clue@ietf.org" Date: Thu, 13 Dec 2012 18:06:55 +0100 Thread-Topic: [clue] Capture Attribute Discussion: 4.3. Language Thread-Index: Ac3Y4+KuNRF2r85/TTS3EFe6gXj9iQAcAtkw Message-ID: References: <50C94E8B.5070306@nteczone.com> In-Reply-To: <50C94E8B.5070306@nteczone.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-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [clue] Capture Attribute Discussion: 4.3. Language 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, 13 Dec 2012 17:12:36 -0000 There have been discussions elsewhere about the difference between supporte= d language and preferred language. The text here should at least be clear a= s to which is meant. I assume multiple values of this can be associated with any capture. I'll have to think some more about duplicate usage with SDP. Keith > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: 13 December 2012 03:42 > To: clue@ietf.org > Subject: [clue] Capture Attribute Discussion: 4.3. Language >=20 > Hello >=20 > The language attribute is described in draft-groves-clue-capture-attr: >=20 > "4.3. Language >=20 > As indicated in the discussion in section 2 captures may be offered > in different languages in case of multi-lingual and/or accessible > conferences. It is important to allow the remote end to distinguish > between them. It is noted that SDP already contains a language > attribute however this may not be available at the time that an > initial CLUE message is sent. Therefore a language attribute is > proposed for CLUE. >=20 > This indicates which language is associated with the capture. For > example: it may provide a language associated with an audio capture > or a language associated with a video capture when sign > interpretation or text is used. The possible values for a language > tag are the values of the 'Subtag' column for the "Type: language" > entries in the "Language Subtag Registry" defined in [RFC5646]" >=20 > Are there any concerns about adding a language attribute to the framework= ? >=20 > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Dec 13 11:01: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 0CC1821F8A21 for ; Thu, 13 Dec 2012 11:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUi9AmsHiDT4 for ; Thu, 13 Dec 2012 11:01:13 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 4434721F8A10 for ; Thu, 13 Dec 2012 11:01:13 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta14.westchester.pa.mail.comcast.net with comcast id b65t1k0030QuhwU5E71CY4; Thu, 13 Dec 2012 19:01:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id b71C1k00H3ZTu2S3N71C7m; Thu, 13 Dec 2012 19:01:12 +0000 Message-ID: <50CA25F6.2080105@alum.mit.edu> Date: Thu, 13 Dec 2012 14:01:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C94D86.8050508@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355425272; bh=f4fD2Rw6rEZsQvUZxJ7KCExqeJxUPGYEVvSIROTGxd0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=htuaXafotL6BNGQwlQbZwkU3dhyPqy4eYNT+Rfi/pTHPXrO0maDK1mlAblsM9ZOS1 KOfVjTVJ80tI6yC7VM0Bv1a+1074JPmdaToZdNAkxkohaT3c+nN3fq23kWdmFgH69V d9JIxGFtURmYrkiTAgFh2/I862vIfknnTGP6xC/6FFxobbB0HEUIhVmmRXfwAP0id0 Pn+uQILoFEMS3z7sshXUg/5ErSDGP+Onc3If3dZmPkctkkst6hoS1x7KsPcbA+Oq4Y UuVjua+dRaPlSk0PBTLX3zHhllD/PVFU5aKrCNy4RWSl90TclSYQpmiQ9sDOGEV4gz Oo0bzI4uq8obA== Subject: Re: [clue] Capture Attribute Discussion: 4.6.4. Telepresence 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, 13 Dec 2012 19:01:14 -0000 I agree with Keith, that there is *something* here but it needs significant refinement to make it tangible, and make it possible for an independent party to verify whether an implementation has conformed to it. (Or perhaps, how close the implementation comes to meeting it.) For instance: - are captures rendered at the indicated size? - are multiple captures rendered in the appropriate spatial relationship to one another? And this attribute suggests that some captures are more deserving of faithful rendering than others. Obviously putting things in separate scenes is already an indication that rendering them in a particular spatial relationship to one another isn't important. I don't really understand about color. I agree that it color faithful rendition might be more important for some captures than others. But I don't understand what the receiver would do differently if it knows this. Would it choose "better" monitors for the captures that need faithful color? Wouldn't that conflict with getting spatial relationships correct? Thanks, Paul On 12/13/12 12:04 PM, DRAGE, Keith (Keith) wrote: > This one seems so unspecific in its definition that I have no idea whether it is useful. > > There is nothing here that guarantees two devices will either set this or not set this when an identical set of conditions and usages exist at the two devices. > > In other words, there is too much hand waving involved in deciding whether it should be sent, and whether I can trust it if I receive it, to be useful. > > I'd also question whether this is the right name for this concept, as I suspect many people have a view of telepresence that is wider than this, and will assume that definition rather than the one provided (unspecific though it is), with even more problems for interoperability. > > As a suggestion, is it not possible to list a set of capabilities, and assign a precedence value to them, e.g. colour - apply a weighting of 90% in deciding the best capture. > > Regards > > Keith > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: 13 December 2012 03:38 >> To: clue@ietf.org >> Subject: [clue] Capture Attribute Discussion: 4.6.4. Telepresence >> >> Hello, >> >> The telepresence attribute is described in draft-groves-clue-capture-attr: >> >> "4.6.4. Telepresence >> >> In certain use cases scenarios it is important to maintain a feeling >> of "Telepresence" associated with captures when they are played at >> the remote end. For example: in medical use cases it is important to >> maintain the colour of images. It is important to note that CLUE is >> used to describe multi-stream conferences. These may or may not be >> "telepresence" conferences. Alternatively it could be assumed that >> all captures possess this attribute and the only captures not subject >> to processing to create "telepresence" this are those marked with >> "presentation". We did discuss the aspect of how an endpoint >> determines if a capture relates to a computer generated image or a >> real environment. An endpoint may apply different images processing >> depending on a source, i.e. it may or not apply image processing to >> adjust lighting levels for a telepresence experience. >> >> This parameter indicates that "telepresence" should be associated >> with the capture. E.g. real world environmental conditions are >> associated with this capture. Lighting, spatial and timing >> information are important aspects of the telepresence session. The >> remote should apply the appropriate capture processing to maintain >> integrity of this information. For example: the colour related >> information associated with the original capture is important and >> should be replicated when displayed/played." >> >> >> Does any one have concerns about adding this to the framework? >> >> Regards, Christian >> _______________________________________________ >> 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 Thu Dec 13 12:43: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 92BBF21F87C5 for ; Thu, 13 Dec 2012 12:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.2 X-Spam-Level: X-Spam-Status: No, score=-106.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC90wGUdFMjK for ; Thu, 13 Dec 2012 12:43:17 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D922521F879F for ; Thu, 13 Dec 2012 12:43:16 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5466133D10; Thu, 13 Dec 2012 15:43:16 -0500 (EST) Date: Thu, 13 Dec 2012 15:43:16 -0500 From: John Leslie To: Stephan Wenger Message-ID: <20121213204316.GF37893@verdi> References: <50C927A9.4030905@nteczone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "clue@ietf.org" Subject: Re: [clue] MCU terminating CLUE, or passing through? was: Capture scene clarifications 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, 13 Dec 2012 20:43:17 -0000 Stephan Wenger wrote: > > The first question is: does the MCU also manipulate and/or potentially > create on its own, CLUE messages. I believe the answer is "yes". We need > this, because only the MCU knows whether, and how, it tiles up pictures in > a video mixing scenario (there are many more use cases like this). I believe an MCU needs to create its own CLUE messages when it pieces together something not produced (in the same form) at an endpoint. I recommend a lot of leeway in what an MCU may stamp as its own. I'm less clear on whether a MCU should ever relay CLUE messages, with or without modification. I'm outright uncomfortable with a MCU pretending to be the producer instead of an aggregator. > The second question is: does the CLUE protocol suite "allow" an MCU to > "effectively broadcast advertisements" (as Christian has put it), without > manipulating them? My gut reaction to this is" let's not overshoot in > terms of flexibility. I think we should make it clear that it is the > responsibility of an MCU to consolidate room information it has received > from receiving rooms and provide, based on its unified view, sensible > choices for things like the selection of Capture scenes. "Broadcast" sounds scary. It's one thing to advertise its aggregated scenes/whatever, but I'd be very hesitant to "broadcast" something to be provided by a different node. (I envision cases where the connectivity changes so that the path from receiver to source no longer passes through the same MCU.) > (This is a bit of a departure from what I suggested in one of the early > Andover meetings, where I suggested that everyone in the conference should > have a full understanding of what's going on, so to be able to make > sensible choices. The issue with this approach is that every vendor will > have a different view what a "sensible" choice may be, and the result > could well be a reduced user experience--and no one to blame for it. If > the control lives in the MCU, then the MCU vendor is to blame, and no one > else). I'm not sure that placing blame "exactly" is all that helpful. (I also suspect that _intentional_ configuration will lead to "reduced user experienct" regardless of what we specify.) -- John Leslie From pkyzivat@alum.mit.edu Thu Dec 13 13:14: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 E2ECA21F8A96 for ; Thu, 13 Dec 2012 13:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umiZ3fW9iCdk for ; Thu, 13 Dec 2012 13:14:35 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7D721F8A4D for ; Thu, 13 Dec 2012 13:14:33 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id b0Gx1k00216LCl0559EYVj; Thu, 13 Dec 2012 21:14:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id b9EY1k00u3ZTu2S3S9EYMM; Thu, 13 Dec 2012 21:14:32 +0000 Message-ID: <50CA4537.80907@alum.mit.edu> Date: Thu, 13 Dec 2012 16:14:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355433272; bh=9zRZnhK7KqJIgaRcapsTIp43RVoZGW+1eOdRv/rBItY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LSa9dsynrsoZaPYmvPdwudCK6G+rQZz9p50nDzZEzQ49KfLbf0FJwtyhs31wy0Box KfdsAx3J1XtroQah/YgRpMU+cx7n75Sp1T8hwmzl9qmb0beq++XleoeUP9zIjDmZmb RmkxB1go802R0FhtZSJBdCd0Xx8Y44GDi5DB/tUcVsv+D+nIvvPJP3JrjNVLx5Jw9C 70apmRZJ2gBsIbc5cTYZoibWm764u5a5/VWphsQaA9jTA6lSn3cC+kcqsKHY/YYLGv dMAtL8eLNbt4HX/k50DY0T8QGbH9BgCvZL7g2dKEgm5Jr7g5f9Lh5+WjQUOLeJQ+6N GPRT78OZ+MRPA== Subject: [clue] Can receiver select captures from more than one capture scene entry? 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, 13 Dec 2012 21:14:36 -0000 The "Capture scene clarifications" topic has been *very* popular, and is getting confusing. Here I've changed the subject line to focus on one point - a change that was been proposed by Christer. The latest description of it was from Christian Groves: >> "A consumer may receive an advertisement with multiple capture scenes. >> A consumer may choose to receive any number of capture scenes. An >> advertised capture scene it may contain one of more capture scene entries >> that may contain one of more media captures. A consumer may choose an >> capture scene entry in the knowledge that it is a complete representation of >> the scene for a particular media type and that all media captures are spatially >> related. For a particular media type the consumer shall choose one capture >> scene entry rather than choosing individual captures from multiple capture >> scene entries. However this does not mean that a consuming endpoint must >> render all the media captures. What is locally rendered and how is a local >> decision." There have been some suggestions that this could also eliminate the need for simultaneous sets, because the scene entries would *be* the simultaneous sets. I'm not sure if that is an integral part of this proposal or not. (If it is, then it provides part of the justification. Without this part I'm not sure what the benefit is.) I am inclined to agree that a new definition of advertisement and configuration could be built around such a concept. But to do so I think somebody will need to work out all the details. For instance: - can the same capture be in more than one capture scene entry? - how does the configure message specify which entries it wants, and which captures from those entries? IMO the existing (prior?) model was at least clearer, and arguably simpler. The way I have been thinking of it: - an advertisement advertises a bunch of captures, and information about those captures to help the receiver decide which ones it wants and how it should render them. - scenes, scene entries, simultaneous sets, are all just pieces of that descriptive info. - a configuration is simple - it only needs to enumerate the captures that it wants. It need not mention scenes or scene entries. (It might need to identify scenes if the capture ids are scoped to a scene.) The proposed changes would make the configuration message more complex. The receiver would need to enumerate the desired scene entries. And for each selected scene entry, identify those captures that are (or are not) desired. So, IMO, if some people are interested in this new approach, I suggest they work on a detailed proposal for how it would work, and then do a full assessment of the pros/cons relative to the existing proposal. Thanks, Paul From pkyzivat@alum.mit.edu Thu Dec 13 14:00: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 830BA21F8B96 for ; Thu, 13 Dec 2012 14:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcRJKJY0wWfA for ; Thu, 13 Dec 2012 14:00:43 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id BEABA21F8B95 for ; Thu, 13 Dec 2012 14:00:42 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta13.westchester.pa.mail.comcast.net with comcast id b1ab1k00316LCl05DA0igx; Thu, 13 Dec 2012 22:00:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id bA0h1k00a3ZTu2S3SA0h4Y; Thu, 13 Dec 2012 22:00:42 +0000 Message-ID: <50CA5009.80605@alum.mit.edu> Date: Thu, 13 Dec 2012 17:00:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355436042; bh=e2WAxE0kvfgKDFrxbLGdsvtHdLzQLZ0h9kAskYvXXxI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HrApCCSlvwW2LrZCGhJe7yhVNTsnict0pDq7vh1/ujnjcn5wjGbZQMI7j7OE57578 Q+fiB+GVUMXkAHFRPsT57/3hXlsd2sR+j5QilWbWi/Dp9hAf7AqNBBivoKK8PZzyQ0 2kyEI2V5CwAFwztMXHzKkvxod18EIet8FO6elILmZL0l9QZHcNGjHOf+JBQ2kpqm5b 0NTqjJNPDcIkG3RxDdyxPcrcX/mr2fsfyC73TvH4Sh/9lwP9gSJkpKRLJFPm0EuepB wzRKRAjSp3vemH3Y6gCzf9KT3U8XLB13mxqy1u+j9xCtniCifdRPbBFas4fYN/J26h bLHJPmr7xmIBQ== Cc: "clue@ietf.org" Subject: Re: [clue] MCU terminating CLUE, or passing through? was: Capture scene clarifications 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, 13 Dec 2012 22:00:43 -0000 On 12/13/12 11:24 AM, Stephan Wenger wrote: > Hi all, > > > On 12.12.2012 16:56 , "Christian Groves" > wrote: > >> >> >> [...] > >> >>> >>> In the case I described, it happens that it is possible to let >>> everybody see everybody else simultaneously without doing any >>> switching or composing in the MCU. So what I described has the MCU >>> directly "passing through" the captures it receives. In reality it >>> would probably *also* advertise some other entries that are switched >>> or composed in order to accommodate receivers that can only handle >>> fewer (e.g. one) captures. >> >> [CNG] This is the point I was trying to understand, how you saw the MCU >> being involved. You see the MCU as simply passing through the CLUE >> Advertisements. In my mind I see CLUE not as an end-to-end protocol. >> I.e. the MCU would effectively act as a CLUE endpoint and >> "re-configures" any advertisements/configures sent to other endpoints. >> I think this aspect is worth examining further. Do you in CLUE allow a >> situation for a MCU to effectively "broadcast" advertisements i.e. from >> room 1 to room 2 & 3 and then allow these rooms to response directly to >> Room 1? etc. In the particular case I constructed here the MCU is, more or less, "passing through" the advertisements. I did not intend that to be viewed as the "normal" or "only" behavior of an MCU. I didn't even mean to imply that the MCU in this case included *only* passed through captures. I was trying to construct a case to make a point. In practice there would probably be other entries that had switched and/or composed captures. When an MCU has only two attached endpoints I would expect that it would be quite likely to pass through captures, and perhaps whole scenes. When you step up to three endpoints its unlikely that whole scenes will be passed through, but it may make sense to expose all the captures. The more endpoints there are, the more important switched and/or composed captures are, and the less likely that it makes sense to pass through individual captures. > I don't want to see this important architectural point to be lost in the > Capture Scene thread. > > Obviously, an MCU needs to intercept and (in many cases) interpret many of > the CLUE messages. > > The first question is: does the MCU also manipulate and/or potentially > create on its own, CLUE messages. I believe the answer is "yes". We need > this, because only the MCU knows whether, and how, it tiles up pictures in > a video mixing scenario (there are many more use cases like this). Yes, I agree. > The second question is: does the CLUE protocol suite "allow" an MCU to > "effectively broadcast advertisements" (as Christian has put it), without > manipulating them? My gut reaction to this is" let's not overshoot in > terms of flexibility. I think we should make it clear that it is the > responsibility of an MCU to consolidate room information it has received > from receiving rooms and provide, based on its unified view, sensible > choices for things like the selection of Capture scenes. Yes. IMO it should be *valid* for a MCU to "pass through" whole scenes, or selected captures from scenes, of the endpoints, or do switching or composition, or any combination of those things. > (This is a bit of a departure from what I suggested in one of the early > Andover meetings, where I suggested that everyone in the conference should > have a full understanding of what's going on, so to be able to make > sensible choices. The issue with this approach is that every vendor will > have a different view what a "sensible" choice may be, and the result > could well be a reduced user experience--and no one to blame for it. If > the control lives in the MCU, then the MCU vendor is to blame, and no one > else). Agreed. Thanks, paul From Christian.Groves@nteczone.com Thu Dec 13 14:13: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 F2A9621F87F5 for ; Thu, 13 Dec 2012 14:13:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+D6RcqLtNen for ; Thu, 13 Dec 2012 14:13:52 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id D4CBF21F8703 for ; Thu, 13 Dec 2012 14:13:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAFhSylB20R/m/2dsb2JhbAANOINIuhoEA4EdgxEBAQEEAQEBNRsbCgEQCw4KCRYIBwkDAgECARUfEQYNAQUCAQGIG6h2lAkEjFeDFoEtA6lY Received: from ppp118-209-31-230.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.31.230]) by ipmail04.adl6.internode.on.net with ESMTP; 14 Dec 2012 08:43:49 +1030 Message-ID: <50CA5316.2010209@nteczone.com> Date: Fri, 14 Dec 2012 09:13:42 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andy Pepperell References: <50C91F5C.8040206@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Sending a configure 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, 13 Dec 2012 22:13:53 -0000 Hello Andy, How does the following sound? "Once the consumer has received an advertisement it may change its configuration of the provider's encodings any number of times during the call independent of subsequent advertisements by sending a new configure message." Regards, Christian On 13/12/2012 9:46 PM, Andy Pepperell wrote: > Hi Christian, > > The intent behind the use of "autonomously" there was just to > re-iterate that this wouldn't be necessarily a consumer's "response" > to the provider's advertisement, but more that even in the absence of > any changed state on the provider there might be reasons for a new > configure message from the consumer. This wasn't intended to refer to > any SIP O/A changes, but more for things like the user of the consumer > system choosing, say, to no longer want to view a presentation video > stream or to receive a set of switched loudest speaker captures rather > than pre-composed video streams from the provider (even if the > provider offers both throughout). > > Your wording proposal does sound like a useful clarification I think, > though it may also be worth continuing to make clear that the > configure isn't strictly a response to the advertisement from the > provider. > > Regards, > > Andy > > > On Thu, Dec 13, 2012 at 12:20 AM, Christian Groves > > > wrote: > > Hello, > > Section 9 of the framework states: > " The consumer is able to change its configuration of the provider's > encodings any number of times during the call, either in > response to > a new capture advertisement from the provider or autonomously. The > consumer need not send a new configure message to the provider when > it receives a new capture advertisement from the provider > unless the > contents of the new capture advertisement cause the consumer's > current configure message to become invalid." > > >From the text I don't think its 100% clear what is meant by "or > autonomously". Does this relates to the signalling of CLUE i.e. > sending a Configure message? Does it relate to sending a new SDP > O/A? Changing the what RTP it sends autonomously? > > If we're only talking about sending a Configure message I would > propose that we change the first sentence to say: > "Once the consumer has received an advertisement it may change its > configuration of the provider's encodings any number of times > during the call by sending a new configure message." > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From Christian.Groves@nteczone.com Thu Dec 13 14:23:42 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDE221F8B1D for ; Thu, 13 Dec 2012 14:23:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Veg4upm8+1jd for ; Thu, 13 Dec 2012 14:23:42 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 91C5221F8689 for ; Thu, 13 Dec 2012 14:23:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUCAIVTylB20R/m/2dsb2JhbAANOINIuz6DEQEBAQQBAQE1GxUGCgEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBgoDAQUCAQGIG6h4lAYEjFcchCcDqVg Received: from ppp118-209-31-230.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.31.230]) by ipmail04.adl6.internode.on.net with ESMTP; 14 Dec 2012 08:53:10 +1030 Message-ID: <50CA5547.1050507@nteczone.com> Date: Fri, 14 Dec 2012 09:23:03 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Hammer References: <50C94D60.9000003@nteczone.com> <00C069FD01E0324C9FFCADF539701DB332703C74@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB332703C74@EX2K10MB1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Capture Attribute Discussion: 4.4. Role 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, 13 Dec 2012 22:23:42 -0000 Hello Mike, I agree we'll have to be careful to define the tokens. No doubt many of these common terms mean different things to different people. For example: A chairman and controller could be different people. A Chairman could be an official position "i.e. WG Chair" but it may be someone else managing the IT system "i.e. controller". It may be that they are two groups related to roles? One group related to the titles of the person: i.e. Boss, Chairman, Secretary, Lecturer, Audience and another group related to conference functions: i.e. Conference initiator, controller, speaker. Regards, Christian On 14/12/2012 1:21 AM, Michael Hammer wrote: > No issues with having roles defined. > > However, someone who has the FLOOR is the speaker. > A CONTROLLER or CHAIRMAN is someone who decides who may have the floor and > can take the floor back from the current speaker. > > I think you should be careful about how you define these "tokens" or > "powers" and how they are transferred to one party or another. > Another potentially separate token is the power to start or end the meeting. > > Define what the mutually exclusive powers are, then choose names. > But, keeping the names consistent with tradition will avoid much confusion. > > Mike > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Wednesday, December 12, 2012 10:37 PM > To: clue@ietf.org > Subject: [clue] Capture Attribute Discussion: 4.4. Role > > Hello > > The role attribute is described in draft-groves-clue-capture-attr: > > "4.4. Role > > The original definition of "Content" allows the indication that a > particular media stream is related to the speaker. CLUE should also > allow this identification for captures. In addition with the advent > of XCON there may be other formal roles that may be associated with > media/captures. For instance: a remote end may like to always view > the floor controller. It is envisaged that a remote end may also > chose captures depending on the role of the person/s captured. For > example: the people at the remote end may wish to always view the > chairmen. This indicates that the capture is associated with an > entity that has a particular role in the conference. The values are: > > Speaker - indicates that the capture relates to the current speaker > > Floor - indicates that the capture relates to the current floor > controller of the conference > > Chairman- indicates who the chairman of the meeting is. > > Others - ?" > > The intention of this attribute is to have a standardised means of > indicating the status of a person associated with a capture. As discussed in > another thread a consumer might always want to select a capture associated > with the "boss". The "role" attribute could be the mechanism to indicate > this. It was also noted in discussions this could be extended to apply to > presentations to refer to materials e.g. agenda, report, etc. > > Does anyone have concerns with adding this capability to the framework? > Like the view attribute if agree din principle I think we can have a > discussion about suitable labels and extension mechanisms. > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Dec 13 14:23: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 E820921F891C for ; Thu, 13 Dec 2012 14:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7-RC9-0ReDH for ; Thu, 13 Dec 2012 14:23:54 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 12A1E21F8689 for ; Thu, 13 Dec 2012 14:23:53 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta09.westchester.pa.mail.comcast.net with comcast id b07w1k0040EZKEL59APttX; Thu, 13 Dec 2012 22:23:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id bAPt1k00P3ZTu2S3MAPtQY; Thu, 13 Dec 2012 22:23:53 +0000 Message-ID: <50CA5578.7060805@alum.mit.edu> Date: Thu, 13 Dec 2012 17:23:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <50C61E8E.1090805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053E9D@ESESSMB209.ericsson.se>, <50C8BCA5.8020702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0543CD@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0543CD@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355437433; bh=jXN66Q1cISUh0pYpmut0YbQoQSfA9grdUR+CMHvaGq8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JEFQKEYPz/NGWc5TdJ9WmL45KbhYeGg1DvuXkvLHeNjiguNnApWCeiyEvA/LACWdA IIjOANJp3JYg6JDB1VxJdVtcIkPsZC4y7/6FvF+5vYawgm0S8kkOKBxqK+i3sPecvg uzRgNgCpRf0MJfVRm6QLuaERPSRLOn739YTom6Ngh0ANsAdAfNgU9LZToFlq/NuD9h bbUYDDJ/9lfYiAooh7vsx0+SM/eCGzy7uEC4YzVuu4kbtD4oqWYbnrsXjwb1jcDx39 WwpeJUB+HIJQdtoLdfoYywHlyt8z3unrETdOKNK69eoU7+mR7VWfkpkHhgJQFPt5OX vCqjlyODu5eDA== Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene clarifications 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, 13 Dec 2012 22:23:55 -0000 On 12/12/12 3:37 PM, Christer Holmberg wrote: > > Hi, > > I'm putting the other discussion on hold for the moment, because I think we are starting to find some common ground in this one :) > >>>>>>>>> With regards to simultaneous sets I think we need to resolve what >>>>>>>>> capture scene entries represent. Currently the framework says that >>>>>>>>> it must be possible to send all captures in a Capture Scene Entry >>>>>>>>> simultaneously. To me logically speaking a capture scene entry is >>>>>>>>> effectively a simultaneous transmission set. To send effectively >>>>>>>>> the same information twice seems to me to be abit of a waste. >>>>>>>> >>>>>>>> [Duckworth, Mark] It isn't supposed to be the same information. >>>>>>>> The framework says "The simultaneous transmission sets MUST allow >>>>>>>> all the media captures in a particular capture scene entry to be used simultaneously." So all the media captures from a particular capture >>>>>>>> scene entry must also appear together in a simultaneous transmission set. But that >>>>>simultaneous transmission set could also include more media captures, not just media captures that appear in the same capture scene entry. >>>>>>> >>>>>>> I agree to the understanding, but I still question the need. >>>>>>> >>>>>>> Why can't the "additional captures" be part of a dedicated capture scene entry? >>>>>> >>>>>> I guess the question is whether you think the provider can anticipate >>>>>> and advertise every possible combination that a receiver might desire. >>>>>> >>>>>> An example that has been given various times is a recipient that >>>>>> wants to always receive the capture that includes his boss, even when >>>>>> the boss isn't speaking. >>>>>> >>>>>> And he wants this in combination with some other captures that might >>>>>> be some conventional scene entry. So this might mean one full scene >>>>>> entry plus one capture from some other scene entry. Or it might mean *parts* of two scene entries to assemble something useful that always includes the boss. >>>>> >>>>> You can achieve this e.g. using two separate SCENES: one SCENE with a capture scene entry that contains the full scene capture, and another SCENE with a capture scene entry that contains the boss capture. >>>> >>>> My assumption was that the boss is not everyone's boss, or known to be special in any way to the providing site. Rather he is important only to the recipient(s) in one of the other rooms. >>>> >>>> Stated more abstractly, the receiver has special interest in one of the provider's captures that the provider does not realize is of more interest than any of its other captures. >>> >>> So, if I understand you correctly, the provider could e.g: >> >> There are many things a provider *could* do. Many of them don't make sense, or IMO are a bad idea. >> >>> 1) Provide a single SCENE with a capture scene entry that contains the "full room", and individual captures of each participant. >> >> I guess you mean that a single scene *entry* contains both the "full room" capture and the individual captures? >> >> IMO that is contrary to the intent of a scene entry. The entry has >> redundant information, and requires a recipient with no special needs to >> analyze it and decide it could simply render *either* the "full room" >> capture, or all the other captures in the entry. This is hard. >> >> Rather, I would think this same information would be represented better >> as two scene entries: >> >> - an entry with the single "full room" capture >> - an entry with individual captures for each participant. >> >> Each of these provides a full rendering of the room, in a different way. > > Ok, let's go with that for now :) > > So, we have a single SCENE, which has two associated CSEs (Capture Scene Entries): > > - "full room" CSE (capture of full room) > - "individual" CSE (captures of each participant) Yes. >>> Of the individual participant captures, the receiver will then only choose the capture associated with the important participant - ie the receiver is not mandated to receive everything in the chosen capture scene entry; A receiver can choose what it wants. If it has enough screens, it might choose all the captures from the "individual CSE" and display them on separate screens. Or it might choose all of those captures and compose them itself to fit on some lesser number of screens, in an arrangement that suits it. Or, in the case at hand, it might chose the "full room" CSE, and in addition choose one of the individual captures that is of special interest to it. The advertiser doesn't need to anticipate that the receiver might want to do this. It probably didn't construct its advertisement specifically for this case. It is more a matter that the receiver can exploit the advertisement to accomplish a goal unanticipated by the advertiser. >> With the alternative I just mentioned, a receiver with no special >> interests could then choose one of those entries that best meets its >> needs and capabilities. E.g. if it has enough displays and decoders to >> receive all the individual captures, then that might be the better >> choice. If it doesn't have enough resources to do that then it could >> simply choose the single capture full room entry. > > Agree. > >> A receiver that has special interest in one participant (the boss) might >> then decide to receive the entry with the full room capture, and also >> the one capture for the boss from the entry that has all the individual >> captures. > > Almost agree :) > > In my opinion, the receiver would decide two receive both CSEs, but it would indicate that from the individual CSE it only wants to "boss" capture. We should try to separate considerations of what is possible from how advertisements and configurations are represented. And from how the choices might be exposed to end users. (I doubt that an end user will be examining the XML representation of the advertisements.) > So, the end result is really the same. The only different is that, in my opinion, the receiver must always pick a CSE (but it may choose which captures it wants). > > The advantage is that we then only need to advertise simultanous CSE sets - not simultanous capture sets - as it is assumed that a provider can always provide all captures associated with a CSE. > > (This of course means we would need to allow picking multiple CSEs from a single SCENE.) I started a subthread with a separate subject line to talk about this. Can we move the discussion of that there? Thanks, Paul From Christian.Groves@nteczone.com Thu Dec 13 14:29: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 DA06D21F8B9F for ; Thu, 13 Dec 2012 14:29:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n07QgikxI9+4 for ; Thu, 13 Dec 2012 14:29:25 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAEA21F8B42 for ; Thu, 13 Dec 2012 14:29:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUCACtVylB20R/m/2dsb2JhbAANOINIuz6DEQEBAQQBAQE1GxUGCgEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBAYgbqHyUBgSMV4RDA6lY Received: from ppp118-209-31-230.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.31.230]) by ipmail04.adl6.internode.on.net with ESMTP; 14 Dec 2012 08:59:23 +1030 Message-ID: <50CA56BD.8080407@nteczone.com> Date: Fri, 14 Dec 2012 09:29:17 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Hammer References: <50C94D81.2020401@nteczone.com> <00C069FD01E0324C9FFCADF539701DB332703C9D@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB332703C9D@EX2K10MB1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Capture Attribute Discussion: 4.6.3. Supplementary Description 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, 13 Dec 2012 22:29:26 -0000 Hello Mike, "Supplementary Description" probably isn't the best name for this. The idea is not to provide a free text field given more information about the capture. The attribute is meant to be a flag to say that the capture provides additional information to the "main" conference. So in the translator case a capture could be indicated by something like the following. AC1 Language=English AC2 Supplementary Description = TRUE, Language=Chinese This would indicate that there's an english audio stream and a supplementary capture providing a Chinese language audio stream. Regards, Christian On 14/12/2012 1:27 AM, Michael Hammer wrote: > I am wondering if the "Translator" feed is sufficiently important that it > should be its own attribute. > It might be better to search for a well-structured element than to hunt for > such clue in unstructured text. > > Mike > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Wednesday, December 12, 2012 10:38 PM > To: clue@ietf.org > Subject: [clue] Capture Attribute Discussion: 4.6.3. Supplementary > Description > > Hello, > > The supplementary description attribute is described in > draft-groves-clue-capture-attr: > > "4.6.3. Supplementary Description > > Some conferences utilise translators or facilitators that provide an > additional audio stream (i.e. a translation or description of the > conference). These persons may not be pictured in a video capture. > Where multiple audio captures are presented it may be advantageous > for an endpoint to select a supplementary stream instead of or > additional to an audio feed associated with the participants from a > main video capture. Therefore an attribute is proposed for this. > Depending on the results of the discussion of the source device this > parameter may be another value for the source. > > This indicates that a capture provides additional description of the > conference. For example an additional audio stream that provides a > commentary of a conference that provides supplementary information > (e.g. a translation) or extra information to participants in > accessible conferences." > > Does any one have concerns about adding this to the framework? > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From gunnar.hellstrom@omnitor.se Thu Dec 13 14:49: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 103EC21F8855 for ; Thu, 13 Dec 2012 14:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bXOMOpww8mV for ; Thu, 13 Dec 2012 14:49:14 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id B582421F87F5 for ; Thu, 13 Dec 2012 14:49:12 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 13 Dec 2012 23:49:04 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 33F0B3A160 for ; Thu, 13 Dec 2012 23:49:04 +0100 (CET) Message-ID: <50CA5B61.5020604@omnitor.se> Date: Thu, 13 Dec 2012 23:49:05 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C94E8B.5070306@nteczone.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010105020506010401050808" Subject: Re: [clue] Capture Attribute Discussion: 4.3. Language 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, 13 Dec 2012 22:49:15 -0000 This is a multi-part message in MIME format. --------------010105020506010401050808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-12-13 18:06, DRAGE, Keith (Keith) wrote: > There have been discussions elsewhere about the difference between supported language and preferred language. The text here should at least be clear as to which is meant. My first thoughts on an answer to yur question was this: Since the attribute is linked to a capture, I would think that it means a possible content language in the capture. That is neither preferred nor supported. Such concept are for a receiver. If multiple values appear, it means that the contents can vary between the specified alternatives. But second thought: That simple description does not always match what the participants want to know. One case can be that the language is negotiable, and can be decided between the participants during the meeting among a set of supported languages. Some language could then also be a preferred production language because of the competence of the participants. Another case can be that different persons will take turn to be represented in the main speakers capture, and each will use one language. Some other capture may contain interpretation to one specific language all the time. ------ This is different than the SDP specification of language that I guess rather should be preferred language of reception, at least for a sendrcv media. > > I assume multiple values of this can be associated with any capture. I agree that that sounds most useful. But I did not see anything about that in the draft, and there are some words indicating single values, e.g. " indicates *which* language ". I agree that multiple languages should be supported. I do not know if it is then best with multiple language tags within one language attributes, or multiple language attributes with one language tag each. > > I'll have to think some more about duplicate usage with SDP. Language tags are also allowed on the SIP header level. Does this start to be too complex compared to what will be asked for in reality. /Gunnar > > Keith > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: 13 December 2012 03:42 >> To: clue@ietf.org >> Subject: [clue] Capture Attribute Discussion: 4.3. Language >> >> Hello >> >> The language attribute is described in draft-groves-clue-capture-attr: >> >> "4.3. Language >> >> As indicated in the discussion in section 2 captures may be offered >> in different languages in case of multi-lingual and/or accessible >> conferences. It is important to allow the remote end to distinguish >> between them. It is noted that SDP already contains a language >> attribute however this may not be available at the time that an >> initial CLUE message is sent. Therefore a language attribute is >> proposed for CLUE. >> >> This indicates which language is associated with the capture. For >> example: it may provide a language associated with an audio capture >> or a language associated with a video capture when sign >> interpretation or text is used. The possible values for a language >> tag are the values of the 'Subtag' column for the "Type: language" >> entries in the "Language Subtag Registry" defined in [RFC5646]" >> >> Are there any concerns about adding a language attribute to the framework? >> >> Regards, Christian >> _______________________________________________ >> 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 --------------010105020506010401050808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2012-12-13 18:06, DRAGE, Keith (Keith) wrote:
There have been discussions elsewhere about the difference between supported language and preferred language. The text here should at least be clear as to which is meant.
My first thoughts on an answer to yur question was this:
Since the attribute is linked to a capture, I would think that it means a possible content language in the capture.
That is neither preferred nor supported. Such concept are for a receiver.
If multiple values appear, it means that the contents can vary between the specified alternatives.

But second thought:
That simple description does not always match what the participants want to know.

One case can be that the language is negotiable, and can be decided between the participants during the meeting among a set of supported languages. Some language could then also be a preferred production language  because of the competence of the participants.

Another case can be that different persons will take turn to be represented in the main speakers capture, and each will use one language. Some other capture may contain interpretation to one specific language all the time.

  
------
This is different than the SDP specification of language that I guess rather should be preferred language of reception, at least for a sendrcv media.

I assume multiple values of this can be associated with any capture.
I agree that that sounds most useful. But I did not see anything about that in the draft, and there are some words indicating single values, e.g.  " indicates which language ".
I agree that multiple languages should be supported. I do not know if it is then best with multiple language tags within one language attributes, or multiple language attributes with one language tag each.

I'll have to think some more about duplicate usage with SDP.
Language tags are also allowed on the SIP header level.

Does this start to be too complex compared to what will be asked for in reality.

/Gunnar

Keith


-----Original Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
Christian Groves
Sent: 13 December 2012 03:42
To: clue@ietf.org
Subject: [clue] Capture Attribute Discussion: 4.3. Language

Hello

The language attribute is described in draft-groves-clue-capture-attr:

"4.3.   Language

    As indicated in the discussion in section 2 captures may be offered
    in different languages in case of multi-lingual and/or accessible
    conferences.  It is important to allow the remote end to distinguish
    between them.  It is noted that SDP already contains a language
    attribute however this may not be available at the time that an
    initial CLUE message is sent.  Therefore a language attribute is
    proposed for CLUE.

    This indicates which language is associated with the capture. For
    example: it may provide a language associated with an audio capture
    or a language associated with a video capture when sign
    interpretation or text is used.  The possible values for a language
    tag are the values of the 'Subtag' column for the "Type: language"
    entries in the "Language Subtag Registry" defined in [RFC5646]"

Are there any concerns about adding a language attribute to the framework?

Regards, Christian
_______________________________________________
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

--------------010105020506010401050808-- From pkyzivat@alum.mit.edu Thu Dec 13 15:05: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 683A721F8B95 for ; Thu, 13 Dec 2012 15:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuuwvVnYXrtI for ; Thu, 13 Dec 2012 15:05:28 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 4729921F8BB0 for ; Thu, 13 Dec 2012 15:05:28 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta02.westchester.pa.mail.comcast.net with comcast id b1eG1k0051GhbT851B5TJs; Thu, 13 Dec 2012 23:05:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id bB5T1k00X3ZTu2S3TB5TAU; Thu, 13 Dec 2012 23:05:27 +0000 Message-ID: <50CA5F36.8030504@alum.mit.edu> Date: Thu, 13 Dec 2012 18:05:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C927A9.4030905@nteczone.com> <20121213204316.GF37893@verdi> In-Reply-To: <20121213204316.GF37893@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355439927; bh=tL1gFmXji0OdD2+j2vltiAWLIIJvmE/XH9vxZAbmCl4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rrWut8e0vkT6blHq3qzVabCLTMnVqEDnb6Ipk6G9YZvDsuXmumnMzE5ypkux4nA4f cMUCEcVuFihRjHDz6O54VebhsklIB/luzYhDErJtMjcvMxsiecSQsttX9LxqXt+wAy TZUkdDtMS93lM1MrjXEahG1gjeXiU0Y6m4R8hz2qugfvrSd4qnqDI2bR9iFaIhmkLH uz2a/YwV4IK0c5p6c2ZmIolZ+AxRzrvfzidYnjVCU6lcuFFjt1G2gOdClbvVql3G8O SJnmzsa53a/rALEbnOsz83jUY1nXLZVvphuTKuZrvgqV6RNBL/kFsWFrcxtI/PIGHR 8C9unk10Wr9wQ== Subject: Re: [clue] MCU terminating CLUE, or passing through? was: Capture scene clarifications 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, 13 Dec 2012 23:05:32 -0000 On 12/13/12 3:43 PM, John Leslie wrote: > I'm less clear on whether a MCU should ever relay CLUE messages, > with or without modification. I'm outright uncomfortable with a MCU > pretending to be the producer instead of an aggregator. I can see how it *might* be reasonable to do this when the MCU has only two connected endpoints. In this case it can in effect act as a proxy for CLUE messages. But I suspect when we get all the details worked out it won't be that simple. It might be able to pass through an advertisement that is very similar to the one it receives, but probably not identical. Partly that will be due to coupling between the CLUE messages and the SDP. >> The second question is: does the CLUE protocol suite "allow" an MCU to >> "effectively broadcast advertisements" (as Christian has put it), without >> manipulating them? My gut reaction to this is" let's not overshoot in >> terms of flexibility. I think we should make it clear that it is the >> responsibility of an MCU to consolidate room information it has received >> from receiving rooms and provide, based on its unified view, sensible >> choices for things like the selection of Capture scenes. > > "Broadcast" sounds scary. It's one thing to advertise its aggregated > scenes/whatever, but I'd be very hesitant to "broadcast" something to > be provided by a different node. (I envision cases where the connectivity > changes so that the path from receiver to source no longer passes through > the same MCU.) I doubt "broadcast" is a suitable word for any valid behavior. The closest that I can see to this is for the MCU to send out advertisements that includes a number of scenes, each corresponding to one of the scenes it received from the "other" endpoints. As noted above, that seems plausible for two endpoints. It gets progressively less plausible for increasing numbers of endpoints. Thanks, Paul >> (This is a bit of a departure from what I suggested in one of the early >> Andover meetings, where I suggested that everyone in the conference should >> have a full understanding of what's going on, so to be able to make >> sensible choices. The issue with this approach is that every vendor will >> have a different view what a "sensible" choice may be, and the result >> could well be a reduced user experience--and no one to blame for it. If >> the control lives in the MCU, then the MCU vendor is to blame, and no one >> else). > > I'm not sure that placing blame "exactly" is all that helpful. > > (I also suspect that _intentional_ configuration will lead to "reduced > user experienct" regardless of what we specify.) > > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From gunnar.hellstrom@omnitor.se Thu Dec 13 15:06: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 94CCA21F8BE4 for ; Thu, 13 Dec 2012 15:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQa+e3mKeUMg for ; Thu, 13 Dec 2012 15:06:48 -0800 (PST) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 3F15D21F8BBD for ; Thu, 13 Dec 2012 15:06:47 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP; Fri, 14 Dec 2012 00:06:09 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id 8A00E3A0F7; Fri, 14 Dec 2012 00:06:09 +0100 (CET) Message-ID: <50CA5F5E.5070402@omnitor.se> Date: Fri, 14 Dec 2012 00:06:06 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <50C94D7E.9080906@nteczone.com> <50C9801D.6080202@omnitor.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "clue@ietf.org" Subject: Re: [clue] Capture Attribute Discussion: 4.6.2. Embedded Text 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, 13 Dec 2012 23:06:52 -0000 On 2012-12-13 18:09, DRAGE, Keith (Keith) wrote: > What are the language and alphabet restrictions that will exist here? First a structure needs to be defined. Will the embedded text attribute have its own laguage attribute(s)? Or will the video capture have both the embedded text attribute and a number of language attributes, some valid for the video itself and some valid for the embedded text? Someone told me that spoken language tags can be different from written language tags. I do not remember how. If that was true, then the value(s) should only be language tags for written languages. There are extra language sub-tags about what script the language is expressed in, but I am not sure that sub-tag exists for all languages. So I do not think it was the script sub-tag that was intended to be used for indication of written language. /Gunnar > Keith >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Gunnar Hellström >> Sent: 13 December 2012 07:14 >> To: clue@ietf.org >> Subject: Re: [clue] Capture Attribute Discussion: 4.6.2. Embedded Text >> >> This looks good, I agree. >> >> --------------------------------------- >> >> But I also strongly suggest that you define text capture as a proper >> capture in its own right. >> >> The method to display text embedded in video is just a historic solution >> as an afterthought, both destroying part of the video image and >> sometimes making text hard to read. >> >> There are three natural modalities in human communication visual, >> textual and audible. >> >> >> >> Gunnar >> >> ___________________________________________________ >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46708204288 >> >> On 2012-12-13 04:37, Christian Groves wrote: >>> Hello, >>> >>> The embedded text attribute is described in >>> draft-groves-clue-capture-attr: >>> >>> "4.6.2. Embedded Text >>> >>> In accessible conferences textual information may be added to a >>> capture before it is transmitted to the remote end. In the case >>> where multiple video captures are presented the remote end may >>> benefit from the ability to choose a video stream containing text >>> over one that does not. >>> >>> This attribute indicates that a capture provides embedded textual >>> information. For example the video capture may contain speech to >>> text information composed with the video image. This attribute is >>> only applicable to video captures and presentation streams with >>> visual information." >>> >>> Does any one have concerns about adding this to the framework? >>> >>> Regards, Christian >>> _______________________________________________ >>> 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 Dec 13 15:10: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 B9C6721F8BEB for ; Thu, 13 Dec 2012 15:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJrxZEm-Udnr for ; Thu, 13 Dec 2012 15:10:42 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 99CBE21F8BE7 for ; Thu, 13 Dec 2012 15:10:42 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta13.westchester.pa.mail.comcast.net with comcast id b0Us1k0070vyq2s5DBAisz; Thu, 13 Dec 2012 23:10:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id bBAh1k00s3ZTu2S3RBAhHw; Thu, 13 Dec 2012 23:10:42 +0000 Message-ID: <50CA6071.6080700@alum.mit.edu> Date: Thu, 13 Dec 2012 18:10:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C91F5C.8040206@nteczone.com> <50CA5316.2010209@nteczone.com> In-Reply-To: <50CA5316.2010209@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355440242; bh=CpysAWKqGVK37gs1lrE/36daPYbRWtERv9d1qnz3wN0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BBQxe+AfeUNvJmGlK+CpcfxDyU/tm7U7XCvTQJn3RECYGDxz83mGyqx0GXeWofOuB KTQXHx8Nxw37C3DSQMamzLGziYrdfE5m9Fzqpuh9LbDIKoNrk8ESywS+Ne0tZQMgFf BtBSpEmiHpnODuEeuMdvWDKcZG5Z3v5Oa+mG2PsQPghSnmiboKzX2aKj8TXI9zQCqu eUH2VyLnVKxRW36a+YY0VNrXBn5nxgRW8jCdYmypJ6N+CC43nlozJljAxyEiMmNQPc jFsAu9avZwZFAv9YOis4MjCcsVedA0vw25umschunTNU6uQpM6ZyylwSLdejYH3vQN IRiN4PIxQu6jw== Subject: Re: [clue] Sending a configure 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, 13 Dec 2012 23:10:46 -0000 On 12/13/12 5:13 PM, Christian Groves wrote: > Hello Andy, > > How does the following sound? > "Once the consumer has received an advertisement it may change its > configuration of the provider's encodings any number of times during the > call independent of subsequent advertisements by sending a new configure > message." I find "independent of subsequent advertisements" a bit confusing. It might imply that it is appropriate to keep ordering from an old menu after a new menu has been published. As we discussed at the interim in SJ, that *may* work, but probably isn't guaranteed. So how about: "Once the consumer has received an advertisement it may change its configuration of the provider's encodings any number of times while the advertisement remains current by sending a new configure message." Thanks, Paul > Regards, Christian > > On 13/12/2012 9:46 PM, Andy Pepperell wrote: >> Hi Christian, >> >> The intent behind the use of "autonomously" there was just to >> re-iterate that this wouldn't be necessarily a consumer's "response" >> to the provider's advertisement, but more that even in the absence of >> any changed state on the provider there might be reasons for a new >> configure message from the consumer. This wasn't intended to refer to >> any SIP O/A changes, but more for things like the user of the consumer >> system choosing, say, to no longer want to view a presentation video >> stream or to receive a set of switched loudest speaker captures rather >> than pre-composed video streams from the provider (even if the >> provider offers both throughout). >> >> Your wording proposal does sound like a useful clarification I think, >> though it may also be worth continuing to make clear that the >> configure isn't strictly a response to the advertisement from the >> provider. >> >> Regards, >> >> Andy >> >> >> On Thu, Dec 13, 2012 at 12:20 AM, Christian Groves >> > >> wrote: >> >> Hello, >> >> Section 9 of the framework states: >> " The consumer is able to change its configuration of the provider's >> encodings any number of times during the call, either in >> response to >> a new capture advertisement from the provider or autonomously. The >> consumer need not send a new configure message to the provider >> when >> it receives a new capture advertisement from the provider >> unless the >> contents of the new capture advertisement cause the consumer's >> current configure message to become invalid." >> >> >From the text I don't think its 100% clear what is meant by "or >> autonomously". Does this relates to the signalling of CLUE i.e. >> sending a Configure message? Does it relate to sending a new SDP >> O/A? Changing the what RTP it sends autonomously? >> >> If we're only talking about sending a Configure message I would >> propose that we change the first sentence to say: >> "Once the consumer has received an advertisement it may change its >> configuration of the provider's encodings any number of times >> during the call by sending a new configure message." >> >> Regards, Christian >> _______________________________________________ >> 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 Thu Dec 13 15:14: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 724F421F8BE2 for ; Thu, 13 Dec 2012 15:14:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaUvVhyS+8zG for ; Thu, 13 Dec 2012 15:14:50 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id E8A1F21F8B7D for ; Thu, 13 Dec 2012 15:14:49 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUCAPVgylB20R/m/2dsb2JhbAANOINIuz2DEQEBAQQBAQE1GxUGBAYNBAsRBAEBAQkWCAcJAwIBAgEVHwkIEwYCAQGIG6kOlASMV4RDA5IchQmKFYge Received: from ppp118-209-31-230.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.31.230]) by ipmail04.adl6.internode.on.net with ESMTP; 14 Dec 2012 09:44:40 +1030 Message-ID: <50CA615A.4000400@nteczone.com> Date: Fri, 14 Dec 2012 10:14:34 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C94D86.8050508@nteczone.com> <50CA25F6.2080105@alum.mit.edu> In-Reply-To: <50CA25F6.2080105@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Capture Attribute Discussion: 4.6.4. Telepresence 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, 13 Dec 2012 23:14:55 -0000 Hello Keith and Paul, I agree the way its defined is pretty loose. That's because I'm not sure exactly what form this should take. My feeling is also there's something there but it will need thrashing out. I guess the initial trigger for this was the question "is CLUE only used for telepresence systems?". My assumption is that no it could be used by any system with multiple streams. The next question is that if an endpoint knew it was interacting with an endpoint seeking/offering a telepresence experience whether it would do anything different? We've defined a number of information element that are explicitly signalled between endpoints. However are there implicit assumptions that telepresence endpoints make today based on whether they connect to a telepresence endpoint or whether to simpler video conferencing equipment? Q5/16 has done some work (H.TPS-AV) on defining parameters associated with telepresence systems. Much of it references the CLUE work however there are others that aren't signalled. It might be relevant for discussions. http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-39.zip Please see my comments below. Regards, Christian On 14/12/2012 6:01 AM, Paul Kyzivat wrote: > I agree with Keith, that there is *something* here but it needs > significant refinement to make it tangible, and make it possible for > an independent party to verify whether an implementation has conformed > to it. (Or perhaps, how close the implementation comes to meeting it.) [CNG] I agree. > > For instance: > - are captures rendered at the indicated size? > - are multiple captures rendered in the appropriate spatial > relationship to one another? [CNG] Yes these are the sort of assumptions I was thinking of. > > > And this attribute suggests that some captures are more deserving of > faithful rendering than others. > > Obviously putting things in separate scenes is already an indication > that rendering them in a particular spatial relationship to one > another isn't important. > > I don't really understand about color. I agree that it color faithful > rendition might be more important for some captures than others. But I > don't understand what the receiver would do differently if it knows > this. Would it choose "better" monitors for the captures that need > faithful color? Wouldn't that conflict with getting spatial > relationships correct? [CNG] I was thinking more about what image processing it would do for colour balancing rather than choosing better monitors. Sect 7.3.1 of H.TPS-AV has some discussion of lighting for telepresence systems. > > > Thanks, > Paul > > On 12/13/12 12:04 PM, DRAGE, Keith (Keith) wrote: >> This one seems so unspecific in its definition that I have no idea >> whether it is useful. >> >> There is nothing here that guarantees two devices will either set >> this or not set this when an identical set of conditions and usages >> exist at the two devices. >> >> In other words, there is too much hand waving involved in deciding >> whether it should be sent, and whether I can trust it if I receive >> it, to be useful. >> >> I'd also question whether this is the right name for this concept, as >> I suspect many people have a view of telepresence that is wider than >> this, and will assume that definition rather than the one provided >> (unspecific though it is), with even more problems for interoperability. >> >> As a suggestion, is it not possible to list a set of capabilities, >> and assign a precedence value to them, e.g. colour - apply a >> weighting of 90% in deciding the best capture. >> >> Regards >> >> Keith >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>> Christian Groves >>> Sent: 13 December 2012 03:38 >>> To: clue@ietf.org >>> Subject: [clue] Capture Attribute Discussion: 4.6.4. Telepresence >>> >>> Hello, >>> >>> The telepresence attribute is described in >>> draft-groves-clue-capture-attr: >>> >>> "4.6.4. Telepresence >>> >>> In certain use cases scenarios it is important to maintain a >>> feeling >>> of "Telepresence" associated with captures when they are played at >>> the remote end. For example: in medical use cases it is >>> important to >>> maintain the colour of images. It is important to note that >>> CLUE is >>> used to describe multi-stream conferences. These may or may >>> not be >>> "telepresence" conferences. Alternatively it could be assumed >>> that >>> all captures possess this attribute and the only captures not >>> subject >>> to processing to create "telepresence" this are those marked with >>> "presentation". We did discuss the aspect of how an endpoint >>> determines if a capture relates to a computer generated image or a >>> real environment. An endpoint may apply different images >>> processing >>> depending on a source, i.e. it may or not apply image >>> processing to >>> adjust lighting levels for a telepresence experience. >>> >>> This parameter indicates that "telepresence" should be associated >>> with the capture. E.g. real world environmental conditions are >>> associated with this capture. Lighting, spatial and timing >>> information are important aspects of the telepresence session. The >>> remote should apply the appropriate capture processing to maintain >>> integrity of this information. For example: the colour related >>> information associated with the original capture is important and >>> should be replicated when displayed/played." >>> >>> >>> Does any one have concerns about adding this to the framework? >>> >>> Regards, Christian >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Dec 13 15:17: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 EADD421F8B7D for ; Thu, 13 Dec 2012 15:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJcwLSV-WeV8 for ; Thu, 13 Dec 2012 15:17:08 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id CCF3621F8BD0 for ; Thu, 13 Dec 2012 15:17:07 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta04.westchester.pa.mail.comcast.net with comcast id b9wK1k0041HzFnQ54BH7JV; Thu, 13 Dec 2012 23:17:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id bBH61k00u3ZTu2S3aBH6EA; Thu, 13 Dec 2012 23:17:07 +0000 Message-ID: <50CA61F2.3000809@alum.mit.edu> Date: Thu, 13 Dec 2012 18:17:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C94D60.9000003@nteczone.com> <00C069FD01E0324C9FFCADF539701DB332703C74@EX2K10MB1.corp.yaanatech.com> <50CA5547.1050507@nteczone.com> In-Reply-To: <50CA5547.1050507@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355440627; bh=EURKuoE9Zto/ExV9DX0FSuWEiP8n79PkhiEVRMR+THo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=P0YrYuez3jImG4PCcAC4JHfAROrWPcpdVRdn7wwe+H4xEoj/1BXnJHfsdEaQx+5lQ oagBgCQZY50c9Vunh+jBqHr+oiZgXDAWTvRwnZiBasGXE02Qch7HCpp7XpmOn+tzrK 9t1RHVX1dF53FdoeXyBQ2R/smQAnd0X04ONwnC2aA6vAEY6b6Kn6zzkUHVscl07Nmp A+t/0NCkBPa8rMxvVdmQ/njQgIiFSiyOiENTjpy7VnDzf02qd/EgtUbe4IcN4r14V9 DBH/StUvxPD8o3jbdy6pumCBkjmrG52SzJu02fpe4yMHBvBbvhN0beS8yvH/QtvN/p jqnn5BrtriGmw== Subject: Re: [clue] Capture Attribute Discussion: 4.4. Role 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, 13 Dec 2012 23:17:12 -0000 [[ Mike has been having trouble with email to various mailing lists, including CLUE. I think his message went to Christian, but not to the list.]] Paul (as clue moderator) On 12/13/12 5:23 PM, Christian Groves wrote: > Hello Mike, > > I agree we'll have to be careful to define the tokens. No doubt many of > these common terms mean different things to different people. For > example: A chairman and controller could be different people. A Chairman > could be an official position "i.e. WG Chair" but it may be someone else > managing the IT system "i.e. controller". > > It may be that they are two groups related to roles? > One group related to the titles of the person: i.e. Boss, Chairman, > Secretary, Lecturer, Audience and another group related to conference > functions: i.e. Conference initiator, controller, speaker. > > Regards, Christian > > On 14/12/2012 1:21 AM, Michael Hammer wrote: >> No issues with having roles defined. >> >> However, someone who has the FLOOR is the speaker. >> A CONTROLLER or CHAIRMAN is someone who decides who may have the floor >> and >> can take the floor back from the current speaker. >> >> I think you should be careful about how you define these "tokens" or >> "powers" and how they are transferred to one party or another. >> Another potentially separate token is the power to start or end the >> meeting. >> >> Define what the mutually exclusive powers are, then choose names. >> But, keeping the names consistent with tradition will avoid much >> confusion. >> >> Mike >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Wednesday, December 12, 2012 10:37 PM >> To: clue@ietf.org >> Subject: [clue] Capture Attribute Discussion: 4.4. Role >> >> Hello >> >> The role attribute is described in draft-groves-clue-capture-attr: >> >> "4.4. Role >> >> The original definition of "Content" allows the indication that a >> particular media stream is related to the speaker. CLUE should also >> allow this identification for captures. In addition with the advent >> of XCON there may be other formal roles that may be associated with >> media/captures. For instance: a remote end may like to always view >> the floor controller. It is envisaged that a remote end may also >> chose captures depending on the role of the person/s captured. For >> example: the people at the remote end may wish to always view the >> chairmen. This indicates that the capture is associated with an >> entity that has a particular role in the conference. The values >> are: >> >> Speaker - indicates that the capture relates to the current speaker >> >> Floor - indicates that the capture relates to the current floor >> controller of the conference >> >> Chairman- indicates who the chairman of the meeting is. >> >> Others - ?" >> >> The intention of this attribute is to have a standardised means of >> indicating the status of a person associated with a capture. As >> discussed in >> another thread a consumer might always want to select a capture >> associated >> with the "boss". The "role" attribute could be the mechanism to indicate >> this. It was also noted in discussions this could be extended to apply to >> presentations to refer to materials e.g. agenda, report, etc. >> >> Does anyone have concerns with adding this capability to the framework? >> Like the view attribute if agree din principle I think we can have a >> discussion about suitable labels and extension mechanisms. >> >> Regards, Christian >> _______________________________________________ >> 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 Dec 13 15:31: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 9707321F8BE1 for ; Thu, 13 Dec 2012 15:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyc1roiGEw+t for ; Thu, 13 Dec 2012 15:31:07 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id E0C3C21F8B67 for ; Thu, 13 Dec 2012 15:31:06 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta05.westchester.pa.mail.comcast.net with comcast id azdw1k0020QuhwU55BX6K6; Thu, 13 Dec 2012 23:31:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id bBX51k00t3ZTu2S3NBX6sr; Thu, 13 Dec 2012 23:31:06 +0000 Message-ID: <50CA6538.2020900@alum.mit.edu> Date: Thu, 13 Dec 2012 18:31:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C94D60.9000003@nteczone.com> In-Reply-To: <50C94D60.9000003@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355441466; bh=xk5rvNEMjp5/CVU48CQ+ffAJfYQucSsbNJNydYi4aBM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CJ3xKpYtnARsD7WfKwNZtieUt6zNcr2PJt/LmF3M1VXlSGAkVNWBsPTLZeEoXDs5u 8aFkG6rCs3pDNAoN0m7t7sQq4NT0jsOoMBPi2hOFlvdSKkN1Szv23dkoraUtpi0Bmb ZBldIx23QIR4x2W1wVRpgHpgWdTGsyhKuSkzgjTIkjEpjFZ1DWketu4Y6yKdHhRWDf v8wZw4WRYNZ4eHtijTHJ04IlTUW2nbILvyh6NuJZU2omvARZ7blZueth1GczwXVIEO ognW5dyUKdymnKDfyXa/lGNwP69jjQokDta/eMDgKSfbmvfn5cbeDH6R9RtgwswdRa wDwBFINx7xSwA== Subject: Re: [clue] Capture Attribute Discussion: 4.4. Role 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, 13 Dec 2012 23:31:07 -0000 On 12/12/12 10:37 PM, Christian Groves wrote: > Hello > > The role attribute is described in draft-groves-clue-capture-attr: > > "4.4. Role > > The original definition of "Content" allows the indication that a > particular media stream is related to the speaker. CLUE should also > allow this identification for captures. In addition with the advent > of XCON there may be other formal roles that may be associated with > media/captures. For instance: a remote end may like to always view > the floor controller. It is envisaged that a remote end may also > chose captures depending on the role of the person/s captured. For > example: the people at the remote end may wish to always view the > chairmen. This indicates that the capture is associated with an > entity that has a particular role in the conference. The values are: > > Speaker - indicates that the capture relates to the current speaker > > Floor - indicates that the capture relates to the current floor > controller of the conference > > Chairman- indicates who the chairman of the meeting is. > > Others - ?" > > The intention of this attribute is to have a standardised means of > indicating the status of a person associated with a capture. I agree with this, in the abstract. But roles aren't absolute. They are wrt some context. I think the context here must be "this clue session". > As > discussed in another thread a consumer might always want to select a > capture associated with the "boss". The "role" attribute could be the > mechanism to indicate this. Based on the above, I don't think this attribute is useful for that use case. I didn't mean "the boss of this call". I meant "the boss of some participant in one of the rooms attached to this conference". It is likely that different participants will have different bosses, and in any case the MCU or system in each of the rooms won't know who are bosses. Most likely someone in a room will have to use a GUI that shows the advertisement in some human friendly way to pick a capture that he wants to have locked to a display. Perhaps, while viewing the full room capture he can note that his boss is on the far left. Then looking at the advertisement he can see that there is a capture that covers just the far left, and so choose that one. Or possibly xcon (with some extensions) might provide enough info to tag captures with names of participants. (By facial recognition?) > It was also noted in discussions this could > be extended to apply to presentations to refer to materials e.g. agenda, > report, etc. > > Does anyone have concerns with adding this capability to the framework? > Like the view attribute if agree din principle I think we can have a > discussion about suitable labels and extension mechanisms. I'm in favor, as long as the definition is clear. Thanks, Paul From Christian.Groves@nteczone.com Thu Dec 13 15:32:01 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3951E21F8BBD for ; Thu, 13 Dec 2012 15:32:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bh1PapY9EblW for ; Thu, 13 Dec 2012 15:31:48 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 6759021F8B67 for ; Thu, 13 Dec 2012 15:31:48 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAHFiylB20R/m/2dsb2JhbAANOINIuhkEA4EdgxEBAQEEAQEBNRsbChELGAkWCAcJAwIBAgEVHxETBgIBAYgbqQ6UAQSMV4MWgS0DqViBUAc Received: from ppp118-209-31-230.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.31.230]) by ipmail04.adl6.internode.on.net with ESMTP; 14 Dec 2012 10:01:46 +1030 Message-ID: <50CA655B.2050408@nteczone.com> Date: Fri, 14 Dec 2012 10:31:39 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C91F5C.8040206@nteczone.com> <50CA5316.2010209@nteczone.com> <50CA6071.6080700@alum.mit.edu> In-Reply-To: <50CA6071.6080700@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Sending a configure 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, 13 Dec 2012 23:32:01 -0000 Hello Paul, Adding "remains current" may imply that an Advertisement may expire which I don't think they do? It also may cause confusion with the subsequent sentence indicating that even after receiving a new advertisement the consumer doesn't have to send a configure. Perhaps my original wording proposal is enough? Regards, Christian On 14/12/2012 10:10 AM, Paul Kyzivat wrote: > On 12/13/12 5:13 PM, Christian Groves wrote: >> Hello Andy, >> >> How does the following sound? >> "Once the consumer has received an advertisement it may change its >> configuration of the provider's encodings any number of times during the >> call independent of subsequent advertisements by sending a new configure >> message." > > I find "independent of subsequent advertisements" a bit confusing. It > might imply that it is appropriate to keep ordering from an old menu > after a new menu has been published. As we discussed at the interim in > SJ, that *may* work, but probably isn't guaranteed. So how about: > > "Once the consumer has received an advertisement it may change its > configuration of the provider's encodings any number of times while > the advertisement remains current by sending a new configure message." > > Thanks, > Paul > >> Regards, Christian >> >> On 13/12/2012 9:46 PM, Andy Pepperell wrote: >>> Hi Christian, >>> >>> The intent behind the use of "autonomously" there was just to >>> re-iterate that this wouldn't be necessarily a consumer's "response" >>> to the provider's advertisement, but more that even in the absence of >>> any changed state on the provider there might be reasons for a new >>> configure message from the consumer. This wasn't intended to refer to >>> any SIP O/A changes, but more for things like the user of the consumer >>> system choosing, say, to no longer want to view a presentation video >>> stream or to receive a set of switched loudest speaker captures rather >>> than pre-composed video streams from the provider (even if the >>> provider offers both throughout). >>> >>> Your wording proposal does sound like a useful clarification I think, >>> though it may also be worth continuing to make clear that the >>> configure isn't strictly a response to the advertisement from the >>> provider. >>> >>> Regards, >>> >>> Andy >>> >>> >>> On Thu, Dec 13, 2012 at 12:20 AM, Christian Groves >>> > >>> wrote: >>> >>> Hello, >>> >>> Section 9 of the framework states: >>> " The consumer is able to change its configuration of the >>> provider's >>> encodings any number of times during the call, either in >>> response to >>> a new capture advertisement from the provider or >>> autonomously. The >>> consumer need not send a new configure message to the provider >>> when >>> it receives a new capture advertisement from the provider >>> unless the >>> contents of the new capture advertisement cause the consumer's >>> current configure message to become invalid." >>> >>> >From the text I don't think its 100% clear what is meant by "or >>> autonomously". Does this relates to the signalling of CLUE i.e. >>> sending a Configure message? Does it relate to sending a new SDP >>> O/A? Changing the what RTP it sends autonomously? >>> >>> If we're only talking about sending a Configure message I would >>> propose that we change the first sentence to say: >>> "Once the consumer has received an advertisement it may change its >>> configuration of the provider's encodings any number of times >>> during the call by sending a new configure message." >>> >>> Regards, Christian >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Dec 13 15:40:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E825F21F8527 for ; Thu, 13 Dec 2012 15:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhwpVpmafgIu for ; Thu, 13 Dec 2012 15:40:26 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 252BE21F8BDB for ; Thu, 13 Dec 2012 15:40:22 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id b7qx1k00B1GhbT853BgN45; Thu, 13 Dec 2012 23:40:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id bBgN1k00E3ZTu2S3TBgNvE; Thu, 13 Dec 2012 23:40:22 +0000 Message-ID: <50CA6765.1060507@alum.mit.edu> Date: Thu, 13 Dec 2012 18:40:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C94D86.8050508@nteczone.com> <50CA25F6.2080105@alum.mit.edu> <50CA615A.4000400@nteczone.com> In-Reply-To: <50CA615A.4000400@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355442022; bh=P9UW+wzn7r4UYgkMu9DNe6HbHLauDJU8y3yOmPhuqHs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pPCUhpKWDovfbqSn8r+Tm0TG9/0CUjgre8Bfod8m8LQ8cZh86MaWbP/005+HyThDi K7P0PgBqjQobY6LbDewxukYUAFeEL/g8ldYKkE+I6tON6lDmIgRVwMC48VY/qbo1p5 4HjcGPXxNjyNDbioVsGG92+toGrszmgTFtgFiTt/E9IasItFGPNO8mspA7rx9yY080 fHcbvHLmCpxHoZ8jn4JoEAl3UWoSXnKassALB2OoqV++kOZYxE6dTL1+jEQYAk8Vu0 kXvKSR3rqcn0p+X9SkWaUydUBFvd/X2UyHTL9MxNouM+fdhyza9VwWpxW4PJFyRCAf YKn6U3Vqre+Ow== Subject: Re: [clue] Capture Attribute Discussion: 4.6.4. Telepresence 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, 13 Dec 2012 23:40:30 -0000 Christian, While I am sympathetic to this, it seems like it could be controversial and a lot of work to get defined in a sufficient way. And I don't think it is *necessary* to do this to satisfy our current goals. So I would prefer to see you take this one off the table *for now*. If you want to come back later with a more fully fleshed out proposal then we can consider it. We have a lot of other things that we must get done that we should focus on for now. Thanks, Paul On 12/13/12 6:14 PM, Christian Groves wrote: > Hello Keith and Paul, > > I agree the way its defined is pretty loose. That's because I'm not sure > exactly what form this should take. My feeling is also there's something > there but it will need thrashing out. > > I guess the initial trigger for this was the question "is CLUE only used > for telepresence systems?". My assumption is that no it could be used by > any system with multiple streams. The next question is that if an > endpoint knew it was interacting with an endpoint seeking/offering a > telepresence experience whether it would do anything different? We've > defined a number of information element that are explicitly signalled > between endpoints. However are there implicit assumptions that > telepresence endpoints make today based on whether they connect to a > telepresence endpoint or whether to simpler video conferencing equipment? > > Q5/16 has done some work (H.TPS-AV) on defining parameters associated > with telepresence systems. Much of it references the CLUE work however > there are others that aren't signalled. It might be relevant for > discussions. > http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-39.zip > > Please see my comments below. > > Regards, Christian > > On 14/12/2012 6:01 AM, Paul Kyzivat wrote: >> I agree with Keith, that there is *something* here but it needs >> significant refinement to make it tangible, and make it possible for >> an independent party to verify whether an implementation has conformed >> to it. (Or perhaps, how close the implementation comes to meeting it.) > [CNG] I agree. >> >> For instance: >> - are captures rendered at the indicated size? >> - are multiple captures rendered in the appropriate spatial >> relationship to one another? > [CNG] Yes these are the sort of assumptions I was thinking of. >> >> >> And this attribute suggests that some captures are more deserving of >> faithful rendering than others. >> >> Obviously putting things in separate scenes is already an indication >> that rendering them in a particular spatial relationship to one >> another isn't important. >> >> I don't really understand about color. I agree that it color faithful >> rendition might be more important for some captures than others. But I >> don't understand what the receiver would do differently if it knows >> this. Would it choose "better" monitors for the captures that need >> faithful color? Wouldn't that conflict with getting spatial >> relationships correct? > [CNG] I was thinking more about what image processing it would do for > colour balancing rather than choosing better monitors. Sect 7.3.1 of > H.TPS-AV has some discussion of lighting for telepresence systems. >> >> >> Thanks, >> Paul >> >> On 12/13/12 12:04 PM, DRAGE, Keith (Keith) wrote: >>> This one seems so unspecific in its definition that I have no idea >>> whether it is useful. >>> >>> There is nothing here that guarantees two devices will either set >>> this or not set this when an identical set of conditions and usages >>> exist at the two devices. >>> >>> In other words, there is too much hand waving involved in deciding >>> whether it should be sent, and whether I can trust it if I receive >>> it, to be useful. >>> >>> I'd also question whether this is the right name for this concept, as >>> I suspect many people have a view of telepresence that is wider than >>> this, and will assume that definition rather than the one provided >>> (unspecific though it is), with even more problems for interoperability. >>> >>> As a suggestion, is it not possible to list a set of capabilities, >>> and assign a precedence value to them, e.g. colour - apply a >>> weighting of 90% in deciding the best capture. >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>>> Christian Groves >>>> Sent: 13 December 2012 03:38 >>>> To: clue@ietf.org >>>> Subject: [clue] Capture Attribute Discussion: 4.6.4. Telepresence >>>> >>>> Hello, >>>> >>>> The telepresence attribute is described in >>>> draft-groves-clue-capture-attr: >>>> >>>> "4.6.4. Telepresence >>>> >>>> In certain use cases scenarios it is important to maintain a >>>> feeling >>>> of "Telepresence" associated with captures when they are played at >>>> the remote end. For example: in medical use cases it is >>>> important to >>>> maintain the colour of images. It is important to note that >>>> CLUE is >>>> used to describe multi-stream conferences. These may or may >>>> not be >>>> "telepresence" conferences. Alternatively it could be assumed >>>> that >>>> all captures possess this attribute and the only captures not >>>> subject >>>> to processing to create "telepresence" this are those marked with >>>> "presentation". We did discuss the aspect of how an endpoint >>>> determines if a capture relates to a computer generated image or a >>>> real environment. An endpoint may apply different images >>>> processing >>>> depending on a source, i.e. it may or not apply image >>>> processing to >>>> adjust lighting levels for a telepresence experience. >>>> >>>> This parameter indicates that "telepresence" should be associated >>>> with the capture. E.g. real world environmental conditions are >>>> associated with this capture. Lighting, spatial and timing >>>> information are important aspects of the telepresence session. The >>>> remote should apply the appropriate capture processing to maintain >>>> integrity of this information. For example: the colour related >>>> information associated with the original capture is important and >>>> should be replicated when displayed/played." >>>> >>>> >>>> Does any one have concerns about adding this to the framework? >>>> >>>> Regards, Christian >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Dec 13 15:53: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 EBBA421F89A0 for ; Thu, 13 Dec 2012 15:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1zUl+69kWmh for ; Thu, 13 Dec 2012 15:53:43 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id CF9A721F88E6 for ; Thu, 13 Dec 2012 15:53:40 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id b7qN1k0031YDfWL53BtgTe; Thu, 13 Dec 2012 23:53:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id bBtg1k0053ZTu2S3gBtgLK; Thu, 13 Dec 2012 23:53:40 +0000 Message-ID: <50CA6A82.1080400@alum.mit.edu> Date: Thu, 13 Dec 2012 18:53:38 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C91F5C.8040206@nteczone.com> <50CA5316.2010209@nteczone.com> <50CA6071.6080700@alum.mit.edu> <50CA655B.2050408@nteczone.com> In-Reply-To: <50CA655B.2050408@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355442820; bh=RtA7+MVDr1CkTE8HRA5IqI3vCh6ZKaYOe2cg29hTOvA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y+F3ADlOK1YIeIYHm4cVMdmDL03HXiSkWfiJCoB5pmoIMBZZ0xWQAAAyVsL36OaEN LQAY276hzSjj4zDo1Cn2XLeClh6er8tLknpJXcPRaihDhQNwgnDgEyoGFEukuCZrT7 TAsHJTCz61jRXfme0cao/9uVPoaJ9NITkeT65uA4S3lku+oT4h+Z30+sodii/71fUU 6YNoRRk7o83oV/KzAOUrzZyTJ4LqcePunaQRfvwKJKl3cZkFRKEAbaa4KP3KvqhY9h J3QUzjIffsZRyYjxFAzrd8FIYurY6hZeMY4QDWERQDWl344O+5KucMzm00VyTb0QsO 349v2dPnNesjw== Subject: Re: [clue] Sending a configure 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, 13 Dec 2012 23:53:48 -0000 On 12/13/12 6:31 PM, Christian Groves wrote: > Hello Paul, > > Adding "remains current" may imply that an Advertisement may expire > which I don't think they do? They can be superseded, after which they are no longer current. But I make up that terminology, and will be happy if you have something better. > It also may cause confusion with the > subsequent sentence indicating that even after receiving a new > advertisement the consumer doesn't have to send a configure. You weren't at the interim. There was a lot of discussion of this. *My* understanding of this is that: - each advertisement will be uniquely identified (e.g. version#) - a config must identify the advertisement it responds to - a config *may* be rejected if the advertisement it references is not the most recent one. (But it need not be if the advertiser remembers enough to process it.) - a new advertisement may imply that some previously advertised captures are no longer available, or have differing properties. If the most recently received config references captures that are no longer available, then they may no longer be transmitted. So it may be expedient to send a new config after receiving a new advertisement that impacts some previously configured captures. But one is not *obligated* to do this. Making a rule that you MUST send a new config after receiving a new advertisement doesn't really help, because there will still be a window when the old config might be invalid. Thanks, Paul From Christian.Groves@nteczone.com Thu Dec 13 15:55:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AA521F8991 for ; Thu, 13 Dec 2012 15:55:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uk86Y0Z7MzYE for ; Thu, 13 Dec 2012 15:55:51 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 90B9621F863B for ; Thu, 13 Dec 2012 15:55:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUCAKpqylB20R/m/2dsb2JhbAANOINIuz6DCgcBAQEEAQEBLwEFGxUGCg0ECxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAQUShS6CVqkUlAKMV4RDA6lY Received: from ppp118-209-31-230.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.31.230]) by ipmail04.adl6.internode.on.net with ESMTP; 14 Dec 2012 10:25:23 +1030 Message-ID: <50CA6AE4.2020807@nteczone.com> Date: Fri, 14 Dec 2012 10:55:16 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C94D7E.9080906@nteczone.com> <50C9801D.6080202@omnitor.se> <50CA5F5E.5070402@omnitor.se> In-Reply-To: <50CA5F5E.5070402@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Capture Attribute Discussion: 4.6.2. Embedded Text 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, 13 Dec 2012 23:55:56 -0000 Hello Gunnar and Keith, With regards to text being its own capture type I would tend to agree. The embedded text attribute could have the form "EmbeddedText=[Language]". In general I hadn't thought that the language attribute would be used with video captures in general. However if the video contained sign language the language attribute could be used. Embedded text could have its own language. E.g. VC1 (Language=ase,EmbeddedText=en) This would indicate that the video contains American Sign Language and embedded text in English. With respect to language and scripts it appears that RFC5646 allows the use of language plus script sub-tag. i.e. zh-Hans (Chinese written using the Simplified Chinese script) It may be that we want to use this form for the EmbeddedText tag? With respect to the subtags not being complete I think the IANA registry is fairly complete. http://www.iana.org/assignments/language-subtag-registry . If there's something missing then it could be added. Regards, Christian On 14/12/2012 10:06 AM, Gunnar Hellström wrote: > On 2012-12-13 18:09, DRAGE, Keith (Keith) wrote: >> What are the language and alphabet restrictions that will exist here? > First a structure needs to be defined. Will the embedded text > attribute have its own laguage attribute(s)? > > Or will the video capture have both the embedded text attribute and a > number of language attributes, some valid for the video itself and > some valid for the embedded text? > > Someone told me that spoken language tags can be different from > written language tags. I do not remember how. If that was true, then > the value(s) should only be language tags for written languages. > > There are extra language sub-tags about what script the language is > expressed in, but I am not sure that sub-tag exists for all languages. > So I do not think it was the script sub-tag that was intended to be > used for indication of written language. > > /Gunnar >> Keith > >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>> Gunnar Hellström >>> Sent: 13 December 2012 07:14 >>> To: clue@ietf.org >>> Subject: Re: [clue] Capture Attribute Discussion: 4.6.2. Embedded Text >>> >>> This looks good, I agree. >>> >>> --------------------------------------- >>> >>> But I also strongly suggest that you define text capture as a proper >>> capture in its own right. >>> >>> The method to display text embedded in video is just a historic >>> solution >>> as an afterthought, both destroying part of the video image and >>> sometimes making text hard to read. >>> >>> There are three natural modalities in human communication visual, >>> textual and audible. >>> >>> >>> >>> Gunnar >>> >>> ___________________________________________________ >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46708204288 >>> >>> On 2012-12-13 04:37, Christian Groves wrote: >>>> Hello, >>>> >>>> The embedded text attribute is described in >>>> draft-groves-clue-capture-attr: >>>> >>>> "4.6.2. Embedded Text >>>> >>>> In accessible conferences textual information may be added to a >>>> capture before it is transmitted to the remote end. In the case >>>> where multiple video captures are presented the remote end may >>>> benefit from the ability to choose a video stream containing text >>>> over one that does not. >>>> >>>> This attribute indicates that a capture provides embedded textual >>>> information. For example the video capture may contain speech to >>>> text information composed with the video image. This attribute is >>>> only applicable to video captures and presentation streams with >>>> visual information." >>>> >>>> Does any one have concerns about adding this to the framework? >>>> >>>> Regards, Christian >>>> _______________________________________________ >>>> 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 Thu Dec 13 16:12: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 00FDF21F8BF2 for ; Thu, 13 Dec 2012 16:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSlyWYLoJnnj for ; Thu, 13 Dec 2012 16:12:08 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 0850521F8BEC for ; Thu, 13 Dec 2012 16:12:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUCADVuylB20R/m/2dsb2JhbAANOINIu0GDEQEBAQMBAQEBLwEFGxUGCgEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBAYgJEqkWk3sEiTiDH4RDA5Iclzw Received: from ppp118-209-31-230.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.31.230]) by ipmail04.adl6.internode.on.net with ESMTP; 14 Dec 2012 10:41:21 +1030 Message-ID: <50CA6EA2.5010103@nteczone.com> Date: Fri, 14 Dec 2012 11:11:14 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= References: <50C94E8B.5070306@nteczone.com> <50CA5B61.5020604@omnitor.se> In-Reply-To: <50CA5B61.5020604@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Capture Attribute Discussion: 4.3. Language 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, 14 Dec 2012 00:12:14 -0000 Hello Gunnar and Keith, Please see my responses below. Regards, Christian On 14/12/2012 9:49 AM, Gunnar Hellström wrote: > On 2012-12-13 18:06, DRAGE, Keith (Keith) wrote: >> There have been discussions elsewhere about the difference between supported language and preferred language. The text here should at least be clear as to which is meant. > My first thoughts on an answer to yur question was this: > Since the attribute is linked to a capture, I would think that it > means a possible content language in the capture. > That is neither preferred nor supported. Such concept are for a receiver. > If multiple values appear, it means that the contents can vary between > the specified alternatives. [CNG] Yes this is what I had envisaged when proposing the attribute. > > But second thought: > That simple description does not always match what the participants > want to know. > > One case can be that the language is negotiable, and can be decided > between the participants during the meeting among a set of supported > languages. Some language could then also be a preferred production > language because of the competence of the participants. [CNG] This is a difficult one. The participants can always agree to use another language once communications are established. i.e. the participants here that they both have Swedish accents so they speak Swedish to each other. It must be remembered that CLUE is used before any substantive SDP is exchanged about the media streams. Once the participants decide to speak Swedish is there any point in sending a updated Advertisement or Configure? > > Another case can be that different persons will take turn to be > represented in the main speakers capture, and each will use one > language. Some other capture may contain interpretation to one > specific language all the time. [CNG] OK, this one I think justifies having the language tag being a list. > > > ------ > This is different than the SDP specification of language that I guess > rather should be preferred language of reception, at least for a > sendrcv media. >> I assume multiple values of this can be associated with any capture. > I agree that that sounds most useful. But I did not see anything about > that in the draft, and there are some words indicating single values, > e.g. " indicates *which* language ". > I agree that multiple languages should be supported. I do not know if > it is then best with multiple language tags within one language > attributes, or multiple language attributes with one language tag each. [CNG] It can probably be done as multiple values to a single tag. >> I'll have to think some more about duplicate usage with SDP. > Language tags are also allowed on the SIP header level. > > Does this start to be too complex compared to what will be asked for > in reality. [CNG] As the draft indicates the need for additional attributes to describe captures relates to how/where CLUE is used in a call flow. Currently its assumed that a CLUE channel is created. A provider sends an Advertisement. The consumer chooses the captures it wants and it sends a Configure. Media is then established through CLUE. If we rely on only SDP having the language tag then the wrong captures may have been chosen in the initial CLUE exchange. > > /Gunnar >> Keith >> >>> -----Original Message----- >>> From:clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>> Christian Groves >>> Sent: 13 December 2012 03:42 >>> To:clue@ietf.org >>> Subject: [clue] Capture Attribute Discussion: 4.3. Language >>> >>> Hello >>> >>> The language attribute is described in draft-groves-clue-capture-attr: >>> >>> "4.3. Language >>> >>> As indicated in the discussion in section 2 captures may be offered >>> in different languages in case of multi-lingual and/or accessible >>> conferences. It is important to allow the remote end to distinguish >>> between them. It is noted that SDP already contains a language >>> attribute however this may not be available at the time that an >>> initial CLUE message is sent. Therefore a language attribute is >>> proposed for CLUE. >>> >>> This indicates which language is associated with the capture. For >>> example: it may provide a language associated with an audio capture >>> or a language associated with a video capture when sign >>> interpretation or text is used. The possible values for a language >>> tag are the values of the 'Subtag' column for the "Type: language" >>> entries in the "Language Subtag Registry" defined in [RFC5646]" >>> >>> Are there any concerns about adding a language attribute to the framework? >>> >>> Regards, Christian >>> _______________________________________________ >>> 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 Thu Dec 13 16:19: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 57AF621F8A0C for ; Thu, 13 Dec 2012 16:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz1REZt50zLh for ; Thu, 13 Dec 2012 16:19:10 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 89B2F21F8A09 for ; Thu, 13 Dec 2012 16:19:10 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUCAGVvylB20R/m/2dsb2JhbAANLgqDSLtBgxEBAQEDAQEBATUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBiAkSqR2TewSMVxGBCYMpA6lYgVAH Received: from ppp118-209-31-230.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.31.230]) by ipmail04.adl6.internode.on.net with ESMTP; 14 Dec 2012 10:49:09 +1030 Message-ID: <50CA7076.4080700@nteczone.com> Date: Fri, 14 Dec 2012 11:19:02 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C91F5C.8040206@nteczone.com> <50CA5316.2010209@nteczone.com> <50CA6071.6080700@alum.mit.edu> <50CA655B.2050408@nteczone.com> <50CA6A82.1080400@alum.mit.edu> In-Reply-To: <50CA6A82.1080400@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Sending a configure 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, 14 Dec 2012 00:19:15 -0000 Hello Paul, Please see my response below. Regards, Christian On 14/12/2012 10:53 AM, Paul Kyzivat wrote: > On 12/13/12 6:31 PM, Christian Groves wrote: >> Hello Paul, >> >> Adding "remains current" may imply that an Advertisement may expire >> which I don't think they do? > > They can be superseded, after which they are no longer current. > But I make up that terminology, and will be happy if you have > something better. [CNG] Yes I agree. Sending a new Advertisement replaces the old one. > >> It also may cause confusion with the >> subsequent sentence indicating that even after receiving a new >> advertisement the consumer doesn't have to send a configure. > > You weren't at the interim. There was a lot of discussion of this. > > *My* understanding of this is that: > > - each advertisement will be uniquely identified (e.g. version#) > > - a config must identify the advertisement it responds to > > - a config *may* be rejected if the advertisement it references > is not the most recent one. (But it need not be if the advertiser > remembers enough to process it.) > > - a new advertisement may imply that some previously advertised > captures are no longer available, or have differing properties. > If the most recently received config references captures that > are no longer available, then they may no longer be transmitted. > So it may be expedient to send a new config after receiving a > new advertisement that impacts some previously configured captures. > But one is not *obligated* to do this. > > Making a rule that you MUST send a new config after receiving a new > advertisement doesn't really help, because there will still be a > window when the old config might be invalid. [CNG] Er, I wasn't proposing that you MUST send a new config. I was just pointing out that we were discussing the first sentence of a paragraph. There was a second sentence also to consider. I wasn't at the interim and I take it many people on the list also weren't there. I'm trying to work through the framework clarify potential issues. It would be good these sorts of discussions found there way into the document. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From gunnar.hellstrom@omnitor.se Thu Dec 13 22:18: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 4CA0521F88F5 for ; Thu, 13 Dec 2012 22:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1nPRlpi9YX6 for ; Thu, 13 Dec 2012 22:18:47 -0800 (PST) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id B6FBD21F84FF for ; Thu, 13 Dec 2012 22:18:44 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 14 Dec 2012 07:17:41 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id DEA0D3A1BC for ; Fri, 14 Dec 2012 07:17:40 +0100 (CET) Message-ID: <50CAC481.8070407@omnitor.se> Date: Fri, 14 Dec 2012 07:17:37 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50C94D7E.9080906@nteczone.com> <50C9801D.6080202@omnitor.se> <50CA5F5E.5070402@omnitor.se> <50CA6AE4.2020807@nteczone.com> In-Reply-To: <50CA6AE4.2020807@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Capture Attribute Discussion: 4.6.2. Embedded Text 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, 14 Dec 2012 06:18:48 -0000 Conclusion 1: Have a language tag or a list of language tags as parameter on the Embedded text attribute. The script subtag will in most cases not be needed and not be used. RFC 5646 says: " The script subtag SHOULD NOT be used to form language tags unless the script adds some distinguishing information to the tag." So, when used here within the embedded text attribute it is already implied that the contents will be written, then the script subtag shall only be used when a script other than the dominating for the language is used. Multiple languages in the embedded text attribute may be useful if the embedded text follows the language of the speaker, and the speakers can switch in the same video capture. How do you want to code the possibility for the user to select what language appears as embedded text? As is commonly done on DVDs. Maybe that is not coded as embedded text, it could be seen as a text capture with the receiving user selecting presentation placement in part of the video display. Conclusion 2: Text capture should be added to Clue. Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2012-12-14 00:55, Christian Groves wrote: > Hello Gunnar and Keith, > > With regards to text being its own capture type I would tend to agree. > > The embedded text attribute could have the form > "EmbeddedText=[Language]". > > In general I hadn't thought that the language attribute would be used > with video captures in general. However if the video contained sign > language the language attribute could be used. Embedded text could > have its own language. > > E.g. VC1 (Language=ase,EmbeddedText=en) > > This would indicate that the video contains American Sign Language and > embedded text in English. > > With respect to language and scripts it appears that RFC5646 allows > the use of language plus script sub-tag. i.e. > zh-Hans (Chinese written using the Simplified Chinese script) > > It may be that we want to use this form for the EmbeddedText tag? > > With respect to the subtags not being complete I think the IANA > registry is fairly complete. > http://www.iana.org/assignments/language-subtag-registry . If there's > something missing then it could be added. > > > Regards, Christian > > On 14/12/2012 10:06 AM, Gunnar Hellström wrote: >> On 2012-12-13 18:09, DRAGE, Keith (Keith) wrote: >>> What are the language and alphabet restrictions that will exist here? >> First a structure needs to be defined. Will the embedded text >> attribute have its own laguage attribute(s)? >> >> Or will the video capture have both the embedded text attribute and a >> number of language attributes, some valid for the video itself and >> some valid for the embedded text? >> >> Someone told me that spoken language tags can be different from >> written language tags. I do not remember how. If that was true, then >> the value(s) should only be language tags for written languages. >> >> There are extra language sub-tags about what script the language is >> expressed in, but I am not sure that sub-tag exists for all >> languages. So I do not think it was the script sub-tag that was >> intended to be used for indication of written language. >> >> /Gunnar >>> Keith >> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of >>>> Gunnar Hellström >>>> Sent: 13 December 2012 07:14 >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Capture Attribute Discussion: 4.6.2. Embedded Text >>>> >>>> This looks good, I agree. >>>> >>>> --------------------------------------- >>>> >>>> But I also strongly suggest that you define text capture as a proper >>>> capture in its own right. >>>> >>>> The method to display text embedded in video is just a historic >>>> solution >>>> as an afterthought, both destroying part of the video image and >>>> sometimes making text hard to read. >>>> >>>> There are three natural modalities in human communication visual, >>>> textual and audible. >>>> >>>> >>>> >>>> Gunnar >>>> >>>> ___________________________________________________ >>>> Gunnar Hellström >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46708204288 >>>> >>>> On 2012-12-13 04:37, Christian Groves wrote: >>>>> Hello, >>>>> >>>>> The embedded text attribute is described in >>>>> draft-groves-clue-capture-attr: >>>>> >>>>> "4.6.2. Embedded Text >>>>> >>>>> In accessible conferences textual information may be added to a >>>>> capture before it is transmitted to the remote end. In the case >>>>> where multiple video captures are presented the remote end may >>>>> benefit from the ability to choose a video stream containing text >>>>> over one that does not. >>>>> >>>>> This attribute indicates that a capture provides embedded textual >>>>> information. For example the video capture may contain speech to >>>>> text information composed with the video image. This >>>>> attribute is >>>>> only applicable to video captures and presentation streams with >>>>> visual information." >>>>> >>>>> Does any one have concerns about adding this to the framework? >>>>> >>>>> Regards, Christian >>>>> _______________________________________________ >>>>> 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 gunnar.hellstrom@omnitor.se Thu Dec 13 23:06: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 15A1621F88E6 for ; Thu, 13 Dec 2012 23:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiZPF+k9HOcI for ; Thu, 13 Dec 2012 23:06:51 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id C7FDD21F88D0 for ; Thu, 13 Dec 2012 23:06:50 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP; Fri, 14 Dec 2012 08:06:42 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id B975F3A0DF; Fri, 14 Dec 2012 08:06:42 +0100 (CET) Message-ID: <50CAD003.5050303@omnitor.se> Date: Fri, 14 Dec 2012 08:06:43 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christian Groves References: <50C94E8B.5070306@nteczone.com> <50CA5B61.5020604@omnitor.se> <50CA6EA2.5010103@nteczone.com> In-Reply-To: <50CA6EA2.5010103@nteczone.com> Content-Type: multipart/alternative; boundary="------------020006060200090504060109" Cc: clue@ietf.org Subject: Re: [clue] Capture Attribute Discussion: 4.3. Language 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, 14 Dec 2012 07:06:52 -0000 This is a multi-part message in MIME format. --------------020006060200090504060109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-12-14 01:11, Christian Groves wrote: >> Does this start to be too complex compared to what will be asked for >> in reality. > [CNG] As the draft indicates the need for additional attributes to > describe captures relates to how/where CLUE is used in a call flow. > Currently its assumed that a CLUE channel is created. A provider sends > an Advertisement. The consumer chooses the captures it wants and it > sends a Configure. Media is then established through CLUE. If we rely > on only SDP having the language tag then the wrong captures may have > been chosen in the initial CLUE exchange. Yes, I see the need for language attribute, and for multiple languages. What I meant was that we identified different reasons to have multiple languages specified and wondered if we would need to distinguish between them. Two examples: 1. A possibility to call customer support is offered. One offer is a conference call with staff that are able to handle Spanish, French and Italian , another with staff who handle Chinese, Japanese and Korean. You select which call to initiate, and then agree the language to use during the call by human discussion among the ones offered in the call and stick to that language for the call duration. Note that this is not about selecting between two captures in the same CLUE, it is about selecting what call to make and having the CLUE description as a clue to select the call to make. 2. A transmission from a live physical conference, where speakers switch and they speak their own languages. A main audio capture contains the original sound. That capture would need a list of languages, but there is no chance for the receiver to control what language there is at any moment. They will take turns. (Another capture may contain spoken translation to one single language.) *Question:* Do we need to differentiate between these two reasons to have lists of languages? One for a menue of selectable languages, and another for a list of languages that will appear taking turns in the capture. Or should that difference be left to be made clear by the announcement of the conference in some other form. Gunnar --------------020006060200090504060109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2012-12-14 01:11, Christian Groves wrote:
Does this start to be too complex compared to what will be asked for in reality.
[CNG] As the draft indicates the need for additional attributes to describe captures relates to how/where CLUE is used in a call flow. Currently its assumed that a CLUE channel is created. A provider sends an Advertisement. The consumer chooses the captures it wants and it sends a Configure. Media is then established through CLUE. If we rely on only SDP having the language tag then the wrong captures may have been chosen in the initial CLUE exchange.
Yes, I see the need for language attribute, and for multiple languages.

What I meant was that we identified different reasons to have multiple languages specified and wondered if we would need to distinguish between them.

Two examples:

1. A possibility to call customer support is offered. One offer is a conference call with staff that are able to handle Spanish, French and Italian , another with staff who handle Chinese, Japanese and Korean. You select which call to initiate, and then agree the language to use during the call by human discussion among the ones offered in the call and stick to that language for the call duration.  Note that this is not about selecting between two captures in the same CLUE, it is about selecting what call to make and having the CLUE description as a clue to select the call to make.

2. A transmission from a live physical conference, where speakers switch and they speak their own languages. A main audio capture contains the original sound. That capture would need a list of languages, but there is no chance for the receiver to control what language there is at any moment. They will take turns. (Another capture may contain spoken translation to one single language.)

Question: Do we need to differentiate between these two reasons to have lists of languages? One for a menue of selectable languages, and another for a list of languages that will appear taking turns in the capture.
Or should that difference be left to be made clear by the announcement of the conference in some other form.
 

Gunnar

--------------020006060200090504060109-- From gunnar.hellstrom@omnitor.se Fri Dec 14 07:46: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 3822A21F863C for ; Fri, 14 Dec 2012 07:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWUCFJ884hX1 for ; Fri, 14 Dec 2012 07:46:32 -0800 (PST) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id CC9A121F861B for ; Fri, 14 Dec 2012 07:46:31 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP; Fri, 14 Dec 2012 16:45:52 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id 3AC3A3A10F; Fri, 14 Dec 2012 16:45:52 +0100 (CET) Message-ID: <50CB49B1.6030902@omnitor.se> Date: Fri, 14 Dec 2012 16:45:53 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Hammer References: <50C94E8B.5070306@nteczone.com> <50CA5B61.5020604@omnitor.se> <50CA6EA2.5010103@nteczone.com> <50CAD003.5050303@omnitor.se> <00C069FD01E0324C9FFCADF539701DB332704967@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB332704967@EX2K10MB1.corp.yaanatech.com> Content-Type: multipart/alternative; boundary="------------030902030008090300080704" Cc: "clue@ietf.org" Subject: Re: [clue] Capture Attribute Discussion: 4.3. Language 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, 14 Dec 2012 15:46:33 -0000 This is a multi-part message in MIME format. --------------030902030008090300080704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 2012-12-14 15:07, Michael Hammer wrote: > > Gunnar, > > The language of the capture should stick to what it advertises itself > to be. > > If the sender offers to have English captioning, and the receive opts > for English captioning, that is what the receiver should get. > Yes, agreed. I am discussing two reasons to offer a list of languages. And it is for any capture, audio, video, video-embedded text, or text, 1. The offerer indicates a list of language capabilities, the participant selects which one to use. 2. The offerer indicates that the language will vary throughout the session by providing a list of languages. And my question was if the difference between these two reasons to have a list of languages causes a need to code the language attribute differently. Gunnar > Mike > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Gunnar Hellström > *Sent:* Friday, December 14, 2012 2:07 AM > *To:* Christian Groves > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Capture Attribute Discussion: 4.3. Language > > On 2012-12-14 01:11, Christian Groves wrote: > > Does this start to be too complex compared to what will be > asked for in reality. > > [CNG] As the draft indicates the need for additional attributes to > describe captures relates to how/where CLUE is used in a call > flow. Currently its assumed that a CLUE channel is created. A > provider sends an Advertisement. The consumer chooses the captures > it wants and it sends a Configure. Media is then established > through CLUE. If we rely on only SDP having the language tag then > the wrong captures may have been chosen in the initial CLUE exchange. > > Yes, I see the need for language attribute, and for multiple languages. > > What I meant was that we identified different reasons to have multiple > languages specified and wondered if we would need to distinguish > between them. > > Two examples: > > 1. A possibility to call customer support is offered. One offer is a > conference call with staff that are able to handle Spanish, French and > Italian , another with staff who handle Chinese, Japanese and Korean. > You select which call to initiate, and then agree the language to use > during the call by human discussion among the ones offered in the call > and stick to that language for the call duration. Note that this is > not about selecting between two captures in the same CLUE, it is about > selecting what call to make and having the CLUE description as a clue > to select the call to make. > > 2. A transmission from a live physical conference, where speakers > switch and they speak their own languages. A main audio capture > contains the original sound. That capture would need a list of > languages, but there is no chance for the receiver to control what > language there is at any moment. They will take turns. (Another > capture may contain spoken translation to one single language.) > > *Question:* Do we need to differentiate between these two reasons to > have lists of languages? One for a menue of selectable languages, and > another for a list of languages that will appear taking turns in the > capture. > Or should that difference be left to be made clear by the announcement > of the conference in some other form. > > > Gunnar > --------------030902030008090300080704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2012-12-14 15:07, Michael Hammer wrote:

Gunnar,

 

The language of the capture should stick to what it advertises itself to be.

If the sender offers to have English captioning, and the receive opts for English captioning, that is what the receiver should get.

Yes, agreed. I am discussing two reasons to offer a list of languages.

And it is for any capture, audio, video, video-embedded text, or text,

1. The offerer indicates a list of language capabilities,  the participant selects which one to use.

2. The offerer indicates that the language will vary throughout the session by providing a list of languages.

And my question was if the difference between these two reasons to have a list of languages causes a need to code the language attribute differently.


Gunnar


 

Mike

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Gunnar Hellström
Sent: Friday, December 14, 2012 2:07 AM
To: Christian Groves
Cc: clue@ietf.org
Subject: Re: [clue] Capture Attribute Discussion: 4.3. Language

 

On 2012-12-14 01:11, Christian Groves wrote:

Does this start to be too complex compared to what will be asked for in reality.

[CNG] As the draft indicates the need for additional attributes to describe captures relates to how/where CLUE is used in a call flow. Currently its assumed that a CLUE channel is created. A provider sends an Advertisement. The consumer chooses the captures it wants and it sends a Configure. Media is then established through CLUE. If we rely on only SDP having the language tag then the wrong captures may have been chosen in the initial CLUE exchange.

Yes, I see the need for language attribute, and for multiple languages.

What I meant was that we identified different reasons to have multiple languages specified and wondered if we would need to distinguish between them.

Two examples:

1. A possibility to call customer support is offered. One offer is a conference call with staff that are able to handle Spanish, French and Italian , another with staff who handle Chinese, Japanese and Korean. You select which call to initiate, and then agree the language to use during the call by human discussion among the ones offered in the call and stick to that language for the call duration.  Note that this is not about selecting between two captures in the same CLUE, it is about selecting what call to make and having the CLUE description as a clue to select the call to make.

2. A transmission from a live physical conference, where speakers switch and they speak their own languages. A main audio capture contains the original sound. That capture would need a list of languages, but there is no chance for the receiver to control what language there is at any moment. They will take turns. (Another capture may contain spoken translation to one single language.)

Question: Do we need to differentiate between these two reasons to have lists of languages? One for a menue of selectable languages, and another for a list of languages that will appear taking turns in the capture.
Or should that difference be left to be made clear by the announcement of the conference in some other form.
 

Gunnar


--------------030902030008090300080704-- From apeppere@gmail.com Fri Dec 14 09:19: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 27C6F21F8A53 for ; Fri, 14 Dec 2012 09:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezeEXGzwDiky for ; Fri, 14 Dec 2012 09:19:09 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0DF121F8A6C for ; Fri, 14 Dec 2012 09:19:06 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so2673712qca.31 for ; Fri, 14 Dec 2012 09:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u5FHKLHNj4OtRlYwh1Y51IDj9rx3iK6cwIJk+4+kX1g=; b=kRA2o96LQN13dcgQB4qe3OfBeyu4YxuYzfGlfmG68jlW2CBjpClBTN3HoU8te73j5S S0lHp9qL5Mar0S1x7miHbW8Cgg8YfNaOqbdDDYQpAK5mr8HwW2+LPrsyEz91008xdLkx QPgVjLPGjVpj1PO2Cz2O4r/tIpGiwGc8hXex3o6gRub5fFoRIcduD3MEWHho5z2umVOW jiegBiu55KJzj1FMlw98f7YksO4c836/pBSvmCyroGch43dso/rTyl+SN5J3NNEHmtWY ihCiOol+U6PZb5XSvSKLpHI8Z75YqLbk/91wMq6im5cuVk+pcnO02Eau7IoOeKzYKn9j q8kQ== MIME-Version: 1.0 Received: by 10.49.132.199 with SMTP id ow7mr3150175qeb.56.1355505546310; Fri, 14 Dec 2012 09:19:06 -0800 (PST) Received: by 10.49.62.131 with HTTP; Fri, 14 Dec 2012 09:19:06 -0800 (PST) In-Reply-To: <50CA4537.80907@alum.mit.edu> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> Date: Fri, 14 Dec 2012 17:19:06 +0000 Message-ID: From: Andy Pepperell To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7bf164ae9432e104d0d33a38 Cc: clue@ietf.org Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 14 Dec 2012 17:19:10 -0000 --047d7bf164ae9432e104d0d33a38 Content-Type: text/plain; charset=ISO-8859-1 >>For a particular media type the consumer shall choose one capture >>scene entry rather than choosing individual captures from multiple capture >>scene entries >There have been some suggestions that this could also eliminate the need for simultaneous sets, >because the scene entries would *be* the simultaneous sets. While I can see the appeal of this approach, I think we shouldn't discount cases where a consumer might want to configure media captures from more than one capture scene entry within a scene. An MCU, for instance, might want to receive a multi-camera view from a room *and* a single roving camera in order to switch both out to different participants depending on those participants' rendering capabilities. Similarly, a recording device might choose to receive from an MCU both a set of switched loudest speaker captures and a more simple pre-composed view to allow later playback by devices whose capabilities similarly differ. (also, we planned for capture scene entries to be restricted to a single media type (e.g. audio or video) and so it should perhaps be clarified whether the "shall choose one capture scene entry" should more precisely be "shall choose one capture scene entry of each media type"). >PaulK: IMO the existing (prior?) model was at least clearer, and arguably simpler. I agree with Paul here! (perhaps unsurprisingly :) ) though I do feel that the simultaneity restrictions could do with a careful re-examination (particularly with regard to inclusivity vs exclusivity). Regards, Andy On Thu, Dec 13, 2012 at 9:14 PM, Paul Kyzivat wrote: > The "Capture scene clarifications" topic has been *very* popular, and is > getting confusing. > > Here I've changed the subject line to focus on one point - a change that > was been proposed by Christer. The latest description of it was from > Christian Groves: > > "A consumer may receive an advertisement with multiple capture scenes. >>> A consumer may choose to receive any number of capture scenes. An >>> advertised capture scene it may contain one of more capture scene entries >>> that may contain one of more media captures. A consumer may choose an >>> capture scene entry in the knowledge that it is a complete >>> representation of >>> the scene for a particular media type and that all media captures are >>> spatially >>> related. For a particular media type the consumer shall choose one >>> capture >>> scene entry rather than choosing individual captures from multiple >>> capture >>> scene entries. However this does not mean that a consuming endpoint must >>> render all the media captures. What is locally rendered and how is a >>> local >>> decision." >>> >> > There have been some suggestions that this could also eliminate the need > for simultaneous sets, because the scene entries would *be* the > simultaneous sets. I'm not sure if that is an integral part of this > proposal or not. (If it is, then it provides part of the justification. > Without this part I'm not sure what the benefit is.) > > I am inclined to agree that a new definition of advertisement and > configuration could be built around such a concept. But to do so I think > somebody will need to work out all the details. For instance: > - can the same capture be in more than one capture scene entry? > - how does the configure message specify which entries it wants, > and which captures from those entries? > > IMO the existing (prior?) model was at least clearer, and arguably > simpler. The way I have been thinking of it: > > - an advertisement advertises a bunch of captures, and information > about those captures to help the receiver decide which ones it > wants and how it should render them. > > - scenes, scene entries, simultaneous sets, are all just pieces of > that descriptive info. > > - a configuration is simple - it only needs to enumerate the > captures that it wants. It need not mention scenes or scene > entries. (It might need to identify scenes if the capture ids > are scoped to a scene.) > > The proposed changes would make the configuration message more complex. > The receiver would need to enumerate the desired scene entries. And for > each selected scene entry, identify those captures that are (or are not) > desired. > > So, IMO, if some people are interested in this new approach, I suggest > they work on a detailed proposal for how it would work, and then do a full > assessment of the pros/cons relative to the existing proposal. > > Thanks, > Paul > > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --047d7bf164ae9432e104d0d33a38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>For a particular media type the consumer shall choose one capture>>scene entry rather than choosing individual captures from multipl= e capture
>>scene entries
>There have been some suggestions= that this could also eliminate the need for simultaneous sets,
>because the scene entries would *be* the simultaneous sets.
While I can see the appeal of this approach, I think we should= n't discount cases where a consumer might want to configure media captu= res from more than one capture scene entry within a scene. An MCU, for inst= ance, might want to receive a multi-camera view from a room *and* a single = roving camera in order to switch both out to different participants dependi= ng on those participants' rendering capabilities. Similarly, a recordin= g device might choose to receive from an MCU both a set of switched loudest= speaker captures and a more simple pre-composed view to allow later playba= ck by devices whose capabilities similarly differ.

(also, we planned for capture scene entries to be restr= icted to a single media type (e.g. audio or video) and so it should perhaps= be clarified whether the "shall choose one capture scene entry" = should more precisely be "shall choose one capture scene entry of each= media type").


>PaulK: IMO the existing (prior?) model was at least cleare= r, and arguably simpler.

I agree with Paul here! (perhaps unsurpris= ingly :) ) though I do feel that the simultaneity restrictions could do wit= h a careful re-examination (particularly with regard to inclusivity vs excl= usivity).


Regards,

Andy


On Thu, Dec 13, 2012 at 9:14 PM, Paul= Kyzivat <pkyzivat@alum.mit.edu> wrote:
The "Capture scene clarifications"= topic has been *very* popular, and is getting confusing.

Here I've changed the subject line to focus on one point - a change tha= t was been proposed by Christer. The latest description of it was from Chri= stian Groves:

=A0 =A0"A consumer may receive an advertisement with multiple capture = scenes.
A consumer may choose to receive any number of capture scenes. An
advertised capture scene it may contain one of more capture scene entries that may contain one of more media captures. A consumer may choose an
capture scene entry in the knowledge that it is a complete representation o= f
the scene for a particular media type and that all media captures are spati= ally
related. For a particular media type the consumer shall choose one capture<= br> scene entry rather than choosing individual captures from multiple capture<= br> scene entries. However this does not mean that a consuming endpoint must render all the media captures. What is locally rendered and how is a local<= br> decision."

There have been some suggestions that this could also eliminate the need fo= r simultaneous sets, because the scene entries would *be* the simultaneous = sets. I'm not sure if that is an integral part of this proposal or not.= (If it is, then it provides part of the justification. Without this part I= 'm not sure what the benefit is.)

I am inclined to agree that a new definition of advertisement and configura= tion could be built around such a concept. But to do so I think somebody wi= ll need to work out all the details. For instance:
- can the same capture be in more than one capture scene entry?
- how does the configure message specify which entries it wants,
=A0 and which captures from those entries?

IMO the existing (prior?) model was at least clearer, and arguably simpler.= The way I have been thinking of it:

- an advertisement advertises a bunch of captures, and information
=A0 about those captures to help the receiver decide which ones it
=A0 wants and how it should render them.

- scenes, scene entries, simultaneous sets, are all just pieces of
=A0 that descriptive info.

- a configuration is simple - it only needs to enumerate the
=A0 captures that it wants. It need not mention scenes or scene
=A0 entries. (It might need to identify scenes if the capture ids
=A0 are scoped to a scene.)

The proposed changes would make the configuration message more complex. The= receiver would need to enumerate the desired scene entries. And for each s= elected scene entry, identify those captures that are (or are not) desired.=

So, IMO, if some people are interested in this new approach, I suggest they= work on a detailed proposal for how it would work, and then do a full asse= ssment of the pros/cons relative to the existing proposal.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

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

--047d7bf164ae9432e104d0d33a38-- From christer.holmberg@ericsson.com Mon Dec 17 00:31:02 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5356F21F89D0 for ; Mon, 17 Dec 2012 00:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+P0iMp6CdrH for ; Mon, 17 Dec 2012 00:30:58 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 21ED621F893D for ; Mon, 17 Dec 2012 00:30:57 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-6c-50ced8408007 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0A.B1.10459.048DEC05; Mon, 17 Dec 2012 09:30:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 09:30:56 +0100 From: Christer Holmberg To: Andy Pepperell , Paul Kyzivat Thread-Topic: [clue] Can receiver select captures from more than one capture scene entry? Thread-Index: AQHN2jcDVPAg9stUo0qY5NTn2rJz5pgcrGiw Date: Mon, 17 Dec 2012 08:30:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B062375@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B062375ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvja7DjXMBBtuWaFlM+t3IYrH/1GVm ixUbDrA6MHv8ff+ByWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyrj20LWgsYWxon3pCbYG xl0FXYycHBICJhI7WxezQthiEhfurWfrYuTiEBI4xCix/fMqRghnMaPEkf3bgKo4ONgELCS6 /2mDNIgI+EosuHofrJlZQFnia8MmJhBbWCBK4tDGv6wQNdESL1deZ4KwjSRanhwEi7MIqErs 7WphAbF5BbwlWo+9Y4HYdYtRYsqy62BFnAKBEh+besGKGIGu+35qDRPEMnGJW0/mM0FcLSCx ZM95ZghbVOLl439gd0oIKEos75eDKM+X+HG1HWqXoMTJmU9YJjCKzkIyaRaSsllIyiDiOhIL dn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRvbcxMyc9HLDTYzAODu45bfuDsZT50QOMUpzsCiJ 83Il7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwKi6cn1zwlOXl76rX3Vl8OgccbzrLtN0 XMW4onXlHDuh5LMXJ+Qdkg/d9T9G2knrftyOl+dnH922/ZnDzc9JjA+SDzxavd3g6IRUlQcN rvpGXfdV962rMb3qV5nAn7cg6d8k97SFKT6L35zc1Fv1mjGqir+E5+Thh0czvfXmLt3uKBRy 6PBy5a1KLMUZiYZazEXFiQB00FTYgQIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 17 Dec 2012 08:31:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B062375ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am not suggesting that a provider can't provide captures from more than o= ne capture scene entry. I am suggesting that the provider, instead of indicating which captures it = simultaneously can provide, indicate which capture scene entries it can sim= ultaneously provide. I'll provide more arguments in my reply to Paul's e-mail. Regards, Christer From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of And= y Pepperell Sent: 14. joulukuuta 2012 19:19 To: Paul Kyzivat Cc: clue@ietf.org Subject: Re: [clue] Can receiver select captures from more than one capture= scene entry? >>For a particular media type the consumer shall choose one capture >>scene entry rather than choosing individual captures from multiple captur= e >>scene entries >There have been some suggestions that this could also eliminate the need f= or simultaneous sets, >because the scene entries would *be* the simultaneous sets. While I can see the appeal of this approach, I think we shouldn't discount = cases where a consumer might want to configure media captures from more tha= n one capture scene entry within a scene. An MCU, for instance, might want = to receive a multi-camera view from a room *and* a single roving camera in = order to switch both out to different participants depending on those parti= cipants' rendering capabilities. Similarly, a recording device might choose= to receive from an MCU both a set of switched loudest speaker captures and= a more simple pre-composed view to allow later playback by devices whose c= apabilities similarly differ. (also, we planned for capture scene entries to be restricted to a single me= dia type (e.g. audio or video) and so it should perhaps be clarified whethe= r the "shall choose one capture scene entry" should more precisely be "shal= l choose one capture scene entry of each media type"). >PaulK: IMO the existing (prior?) model was at least clearer, and arguably = simpler. I agree with Paul here! (perhaps unsurprisingly :) ) though I do feel that = the simultaneity restrictions could do with a careful re-examination (parti= cularly with regard to inclusivity vs exclusivity). Regards, Andy On Thu, Dec 13, 2012 at 9:14 PM, Paul Kyzivat > wrote: The "Capture scene clarifications" topic has been *very* popular, and is ge= tting confusing. Here I've changed the subject line to focus on one point - a change that wa= s been proposed by Christer. The latest description of it was from Christia= n Groves: "A consumer may receive an advertisement with multiple capture scenes. A consumer may choose to receive any number of capture scenes. An advertised capture scene it may contain one of more capture scene entries that may contain one of more media captures. A consumer may choose an capture scene entry in the knowledge that it is a complete representation o= f the scene for a particular media type and that all media captures are spati= ally related. For a particular media type the consumer shall choose one capture scene entry rather than choosing individual captures from multiple capture scene entries. However this does not mean that a consuming endpoint must render all the media captures. What is locally rendered and how is a local decision." There have been some suggestions that this could also eliminate the need fo= r simultaneous sets, because the scene entries would *be* the simultaneous = sets. I'm not sure if that is an integral part of this proposal or not. (If= it is, then it provides part of the justification. Without this part I'm n= ot sure what the benefit is.) I am inclined to agree that a new definition of advertisement and configura= tion could be built around such a concept. But to do so I think somebody wi= ll need to work out all the details. For instance: - can the same capture be in more than one capture scene entry? - how does the configure message specify which entries it wants, and which captures from those entries? IMO the existing (prior?) model was at least clearer, and arguably simpler.= The way I have been thinking of it: - an advertisement advertises a bunch of captures, and information about those captures to help the receiver decide which ones it wants and how it should render them. - scenes, scene entries, simultaneous sets, are all just pieces of that descriptive info. - a configuration is simple - it only needs to enumerate the captures that it wants. It need not mention scenes or scene entries. (It might need to identify scenes if the capture ids are scoped to a scene.) The proposed changes would make the configuration message more complex. The= receiver would need to enumerate the desired scene entries. And for each s= elected scene entry, identify those captures that are (or are not) desired. So, IMO, if some people are interested in this new approach, I suggest they= work on a detailed proposal for how it would work, and then do a full asse= ssment of the pros/cons relative to the existing proposal. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7594FB04B1934943A5C02806D1A2204B062375ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I am not suggesting that = a provider can’t provide captures from more than one capture scene en= try.

 <= /p>

I am suggesting that the = provider, instead of indicating which captures it simultaneously can provid= e, indicate which capture scene entries it can simultaneously provide.

 <= /p>

I’ll provide more a= rguments in my reply to Paul’s e-mail.

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 <= /p>

From: clue-bou= nces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy Pepperell
Sent: 14. joulukuuta 2012 19:19
To: Paul Kyzivat
Cc: clue@ietf.org
Subject: Re: [clue] Can receiver select captures from more than one = capture scene entry?

 

>>For a particular media type the consumer sha= ll choose one capture
>>scene entry rather than choosing individual captures from multiple = capture
>>scene entries

>There have been some suggestions that this could= also eliminate the need for simultaneous sets,

>because the scene entries would *be* the simulta= neous sets.

 

While I can see the appeal of this approach, I think= we shouldn't discount cases where a consumer might want to configure media= captures from more than one capture scene entry within a scene. An MCU, fo= r instance, might want to receive a multi-camera view from a room *and* a single roving camera in order to s= witch both out to different participants depending on those participants' r= endering capabilities. Similarly, a recording device might choose to receiv= e from an MCU both a set of switched loudest speaker captures and a more simple pre-composed view to allow late= r playback by devices whose capabilities similarly differ.

 

(also, we planned for capture scene entries to be re= stricted to a single media type (e.g. audio or video) and so it should perh= aps be clarified whether the "shall choose one capture scene entry&quo= t; should more precisely be "shall choose one capture scene entry of each media type").



>PaulK: IMO the existing (prior?) model was at least clearer, and arguab= ly simpler.


I agree with Paul here! (perhaps unsurprisingly :) ) though I do feel that = the simultaneity restrictions could do with a careful re-examination (parti= cularly with regard to inclusivity vs exclusivity).

 

 

Regards,


Andy

 

 

On Thu, Dec 13, 2012 at 9:14 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:

The "Capture sce= ne clarifications" topic has been *very* popular, and is getting confu= sing.

Here I've changed the subject line to focus on one point - a change that wa= s been proposed by Christer. The latest description of it was from Christia= n Groves:

   "A consumer may receive an adverti= sement with multiple capture scenes.
A consumer may choose to receive any number of capture scenes. An
advertised capture scene it may contain one of more capture scene entries that may contain one of more media captures. A consumer may choose an
capture scene entry in the knowledge that it is a complete representation o= f
the scene for a particular media type and that all media captures are spati= ally
related. For a particular media type the consumer shall choose one capture<= br> scene entry rather than choosing individual captures from multiple capture<= br> scene entries. However this does not mean that a consuming endpoint must render all the media captures. What is locally rendered and how is a local<= br> decision."


There have been some suggestions that this could also eliminate the need fo= r simultaneous sets, because the scene entries would *be* the simultaneous = sets. I'm not sure if that is an integral part of this proposal or not. (If= it is, then it provides part of the justification. Without this part I'm not sure what the benefit is.)
I am inclined to agree that a new definition of advertisement and configura= tion could be built around such a concept. But to do so I think somebody wi= ll need to work out all the details. For instance:
- can the same capture be in more than one capture scene entry?
- how does the configure message specify which entries it wants,
  and which captures from those entries?

IMO the existing (prior?) model was at least clearer, and arguably simpler.= The way I have been thinking of it:

- an advertisement advertises a bunch of captures, and information
  about those captures to help the receiver decide which ones it
  wants and how it should render them.

- scenes, scene entries, simultaneous sets, are all just pieces of
  that descriptive info.

- a configuration is simple - it only needs to enumerate the
  captures that it wants. It need not mention scenes or scene
  entries. (It might need to identify scenes if the capture ids
  are scoped to a scene.)

The proposed changes would make the configuration message more complex. The= receiver would need to enumerate the desired scene entries. And for each s= elected scene entry, identify those captures that are (or are not) desired.=

So, IMO, if some people are interested in this new approach, I suggest they= work on a detailed proposal for how it would work, and then do a full asse= ssment of the pros/cons relative to the existing proposal.

        Thanks,
        Paul

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

 

--_000_7594FB04B1934943A5C02806D1A2204B062375ESESSMB209ericsso_-- From christer.holmberg@ericsson.com Mon Dec 17 00:44: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 431A221F88C9 for ; Mon, 17 Dec 2012 00:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRXS4y73K2hP for ; Mon, 17 Dec 2012 00:44:47 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1221A21F8850 for ; Mon, 17 Dec 2012 00:44:46 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-5c-50cedb7dfc0f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3D.DD.04318.D7BDEC05; Mon, 17 Dec 2012 09:44:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 09:44:45 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Can receiver select captures from more than one capture scene entry? Thread-Index: AQHN2Xbdy91Vj33yzEWP1+DBo9ViMpgcrsFg Date: Mon, 17 Dec 2012 08:44:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> In-Reply-To: <50CA4537.80907@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvjW7t7XMBBlNu2ljsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGyQv32AsOqVesv/aLuYHxmHwXIyeHhICJ xPnGNcwQtpjEhXvr2boYuTiEBA4xShy+/IMJJCEksJhR4lxjZBcjBwebgIVE9z9tkLCIgKfE jo9TwHqFBaIkGp4cYYGIR0tsb3jKCmEbSXSd2wRmswioSry8/5oRxOYV8JY4dR8kDrJrMqPE 8WMQuzgFtCQeL9oBZjMCHfT91Bowm1lAXOLWk/lMEIcKSCzZcx7qaFGJl4//sYLcJiGgKLG8 Xw6iXEdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRTZyFpmYWkZRaSlgWMLKsY2XMTM3PS y803MQIj4eCW3wY7GDfdFzvEKM3BoiTOq6e6319IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD 475Z4m4Prc7uN7z5IoX9HcuBv/9blxlZeP/Lip4Ss27lTu6nNncnLf+147/waYUlvk9XSgnm eOxqE/bxZZsk2bzKVe/Ex+WcEwVbZwa1pXIo9NTy6F3bXrtL8JeHcWd7df7G/dIeav9CfsnK +XEe/u9Q7G7FUDx1vnna7V2eitW5IislhHjilFiKMxINtZiLihMBb2qu5VICAAA= Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 17 Dec 2012 08:44:48 -0000 Hi, First, there are a few things that need to be separated: 1) Whether a capture can be part of one or more CSEs.=20 2) Advertising/configuring 3) Simultaneous sets Regarding 1):=20 I don't think that question is specific to the issues discussed in this thr= ead, so I'll leave it for now (it needs to be clarified, though). Regarding 2): Paul is suggesting: we list captures, and for each capture we indicate whi= ch CSE(s) the capture is associated with. I am suggesting: we list CSEs, and for each CSE we indicate which captures= are associated with the CSE. Si, it's really about how things are structured :) If a provider advertises captures, it means that the receiver needs to scan= through them, to figure out what CSEs the provider is offering.=20 That is not needed if the provider advertises CSEs from the beginning. Of c= ourse, the receiver still needs to scan through the advertised CSEs, and se= e what they contain, but the receiver doesn't need to build the CSE structu= re. Regarding 3): My suggestion is that, instead of indicating which captures can be simultan= eously provide, we indicate which CSEs (and, therefore all captures associa= ted with the CSE) can be simultaneously provided. Something like: (CSE-X AND CSE-Y) OR CSE-Z. This means that the provider can provide CSE-X and CSE Y (and all captures = associated with CSE-X and CSE-Y) simultaneously, or that the provider can p= rovide CSE-Z (and all captures associated with CSE-Z). But, again, just because the receiver e.g. chooses to receive CSE-Y, it sti= ll doesn't have to receive all captures associated with CSE-Y. It can choos= e which ones it wants. Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: 13. joulukuuta 2012 23:15 To: clue@ietf.org Subject: [clue] Can receiver select captures from more than one capture sce= ne entry? The "Capture scene clarifications" topic has been *very* popular, and is ge= tting confusing. Here I've changed the subject line to focus on one point - a change that wa= s been proposed by Christer. The latest description of it was from Christia= n Groves: >> "A consumer may receive an advertisement with multiple capture scenes= . >> A consumer may choose to receive any number of capture scenes. An=20 >> advertised capture scene it may contain one of more capture scene=20 >> entries that may contain one of more media captures. A consumer may=20 >> choose an capture scene entry in the knowledge that it is a complete=20 >> representation of the scene for a particular media type and that all=20 >> media captures are spatially related. For a particular media type the=20 >> consumer shall choose one capture scene entry rather than choosing=20 >> individual captures from multiple capture scene entries. However this=20 >> does not mean that a consuming endpoint must render all the media=20 >> captures. What is locally rendered and how is a local decision." There have been some suggestions that this could also eliminate the need fo= r simultaneous sets, because the scene entries would *be* the simultaneous = sets. I'm not sure if that is an integral part of this proposal or not. (If= it is, then it provides part of the justification.=20 Without this part I'm not sure what the benefit is.) I am inclined to agree that a new definition of advertisement and configura= tion could be built around such a concept. But to do so I think somebody wi= ll need to work out all the details. For instance: - can the same capture be in more than one capture scene entry? - how does the configure message specify which entries it wants, and which captures from those entries? IMO the existing (prior?) model was at least clearer, and arguably simpler.= The way I have been thinking of it: - an advertisement advertises a bunch of captures, and information about those captures to help the receiver decide which ones it wants and how it should render them. - scenes, scene entries, simultaneous sets, are all just pieces of that descriptive info. - a configuration is simple - it only needs to enumerate the captures that it wants. It need not mention scenes or scene entries. (It might need to identify scenes if the capture ids are scoped to a scene.) The proposed changes would make the configuration message more complex.=20 The receiver would need to enumerate the desired scene entries. And for eac= h selected scene entry, identify those captures that are (or are not) desir= ed. So, IMO, if some people are interested in this new approach, I suggest they= work on a detailed proposal for how it would work, and then do a full asse= ssment of the pros/cons relative to the existing proposal. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Mon Dec 17 07:52: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 CF81821F8AB9 for ; Mon, 17 Dec 2012 07:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnSnVRaN8mOi for ; Mon, 17 Dec 2012 07:52:26 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAE4D21F8B0E for ; Mon, 17 Dec 2012 07:52:25 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4794886lah.31 for ; Mon, 17 Dec 2012 07:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=RGIxZBaNbfEVw1qwzDF/8XjOyc2JjO8ajXf6qDIUEys=; b=zgZknae6m/wXtlAxCw0EHOZvi2SFUtSMHHPWWh7WWbHab1iy1eVQgXSWEFVHPgU20D Ojsq54+oSsU6wz43G5VaLCTqc2DQtwJ8Iva2JPh8jeE5GsciTslYiTOHnB5W4aRJSb7L 8Q0PH0pNDoTHB5D0ARYOidoQIbDKKaJUJAWmZfwbVjbiXtLbxmUQobPXBvYYwhF+Aj0O 6/6k2jWDXmM3U+FUTbet6ZDloLjgcSkn3tFWj08rjYSTmZ4J2gz4F9aIdeKIx6WlWorg m1r7DUhq72ZEdGDvviX/llUXA4YP2+IJZrFXR9nRC/pQR41KDdSAxBfqnQl91VsQI8j6 xS8w== MIME-Version: 1.0 Received: by 10.152.162.1 with SMTP id xw1mr11621563lab.3.1355759544284; Mon, 17 Dec 2012 07:52:24 -0800 (PST) Received: by 10.114.20.41 with HTTP; Mon, 17 Dec 2012 07:52:24 -0800 (PST) Date: Mon, 17 Dec 2012 09:52:24 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Cancelled: CLUE Design Team meeting - Dec. 17th 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, 17 Dec 2012 15:52:27 -0000 Hi all, The plan had been to discuss further details on the signaling solution. However, there is no new material related to this at this time. We'll start back with meetings on January 7th (pending of course content for the meetings). Regards, Mary CLUE WG co-chair. From spromano@unina.it Mon Dec 17 07:55: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 23D4721F8B30 for ; Mon, 17 Dec 2012 07:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 510vk+toaFSU for ; Mon, 17 Dec 2012 07:55:08 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 50A8F21F8B12 for ; Mon, 17 Dec 2012 07:55:07 -0800 (PST) Received: from [10.219.39.29] ([10.219.39.29]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id qBHFsska025729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 16:54:55 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_FCFF1A79-34A7-42B8-998B-5C1AC2C68409" From: Simon Pietro Romano In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> Date: Mon, 17 Dec 2012 16:54:54 +0100 Message-Id: <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 17 Dec 2012 15:55:09 -0000 --Apple-Mail=_FCFF1A79-34A7-42B8-998B-5C1AC2C68409 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, > Regarding 3): >=20 > My suggestion is that, instead of indicating which captures can be = simultaneously provide, we indicate which CSEs (and, therefore all = captures associated with the CSE) can be simultaneously provided. >=20 > Something like: >=20 > (CSE-X AND CSE-Y) OR CSE-Z. >=20 > This means that the provider can provide CSE-X and CSE Y (and all = captures associated with CSE-X and CSE-Y) simultaneously, or that the = provider can provide CSE-Z (and all captures associated with CSE-Z). I like this proposal of expressing constraints as a canonicalized = boolean expression. >=20 > But, again, just because the receiver e.g. chooses to receive CSE-Y, = it still doesn't have to receive all captures associated with CSE-Y. It = can choose which ones it wants. With respect to this point, we might state that: 1. if a CONFIGURE contains just a reference to a CSE, then all Capture = Scenes therein contained are to be received; 2. if a client does not want to receive all of the Capture Scenes = contained in a CSE, it has to explicitly indicate the ones it is = interested in. =46rom the data model standpoint, since the same Capture Scene can be = contained in multiple CSEs, we might list all Capture Scenes as = independent elements (uniquely identifiable through their IDs) and make = a reference to them inside each CSE element (through the IDREF = approach). What is your feeling about this? Simon >=20 >=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of Paul Kyzivat > Sent: 13. joulukuuta 2012 23:15 > To: clue@ietf.org > Subject: [clue] Can receiver select captures from more than one = capture scene entry? >=20 > The "Capture scene clarifications" topic has been *very* popular, and = is getting confusing. >=20 > Here I've changed the subject line to focus on one point - a change = that was been proposed by Christer. The latest description of it was = from Christian Groves: >=20 >>> "A consumer may receive an advertisement with multiple capture = scenes. >>> A consumer may choose to receive any number of capture scenes. An=20 >>> advertised capture scene it may contain one of more capture scene=20 >>> entries that may contain one of more media captures. A consumer may=20= >>> choose an capture scene entry in the knowledge that it is a complete=20= >>> representation of the scene for a particular media type and that all=20= >>> media captures are spatially related. For a particular media type = the=20 >>> consumer shall choose one capture scene entry rather than choosing=20= >>> individual captures from multiple capture scene entries. However = this=20 >>> does not mean that a consuming endpoint must render all the media=20 >>> captures. What is locally rendered and how is a local decision." >=20 > There have been some suggestions that this could also eliminate the = need for simultaneous sets, because the scene entries would *be* the = simultaneous sets. I'm not sure if that is an integral part of this = proposal or not. (If it is, then it provides part of the justification.=20= > Without this part I'm not sure what the benefit is.) >=20 > I am inclined to agree that a new definition of advertisement and = configuration could be built around such a concept. But to do so I think = somebody will need to work out all the details. For instance: > - can the same capture be in more than one capture scene entry? > - how does the configure message specify which entries it wants, > and which captures from those entries? >=20 > IMO the existing (prior?) model was at least clearer, and arguably = simpler. The way I have been thinking of it: >=20 > - an advertisement advertises a bunch of captures, and information > about those captures to help the receiver decide which ones it > wants and how it should render them. >=20 > - scenes, scene entries, simultaneous sets, are all just pieces of > that descriptive info. >=20 > - a configuration is simple - it only needs to enumerate the > captures that it wants. It need not mention scenes or scene > entries. (It might need to identify scenes if the capture ids > are scoped to a scene.) >=20 > The proposed changes would make the configuration message more = complex.=20 > The receiver would need to enumerate the desired scene entries. And = for each selected scene entry, identify those captures that are (or are = not) desired. >=20 > So, IMO, if some people are interested in this new approach, I suggest = they work on a detailed proposal for how it would work, and then do a = full assessment of the pros/cons relative to the existing proposal. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_FCFF1A79-34A7-42B8-998B-5C1AC2C68409 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Regarding = 3):

My suggestion is that, instead of indicating which captures = can be simultaneously provide, we indicate which CSEs (and, therefore = all captures associated with the CSE) can be simultaneously = provided.

Something like:

(CSE-X AND CSE-Y) OR = CSE-Z.

This means that the provider can provide CSE-X and CSE Y = (and all captures associated with CSE-X and CSE-Y) simultaneously, or = that the provider can provide CSE-Z (and all captures associated with = CSE-Z).

I like this proposal of = expressing constraints as a canonicalized boolean = expression.


But, again, = just because the receiver e.g. chooses to receive CSE-Y, it still = doesn't have to receive all captures associated with CSE-Y. It can = choose which ones it wants.

With = respect to this point, we might state that:

1. = if a CONFIGURE contains just a reference to a CSE, then all Capture = Scenes therein contained are to be received;
2. if a client = does not want to receive all of the Capture Scenes contained in a CSE, = it has to explicitly indicate the ones it is interested = in.

=46rom the data model standpoint, since the = same Capture Scene can be contained in multiple CSEs, we might list all = Capture Scenes as independent elements (uniquely identifiable through = their IDs) and make a reference to them inside each CSE element (through = the IDREF approach).

What is your feeling about = this?

Simon







Regards,

Christer



-----Original Message-----
From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 13. = joulukuuta 2012 23:15
To: clue@ietf.org
Subject: [clue] Can = receiver select captures from more than one capture scene = entry?

The "Capture scene clarifications" topic has been *very* = popular, and is getting confusing.

Here I've changed the subject = line to focus on one point - a change that was been proposed by = Christer. The latest description of it was from Christian = Groves:

=   "A consumer may receive an advertisement with multiple = capture scenes.
A consumer may choose to receive = any number of capture scenes. An =
advertised capture scene it may contain one of more = capture scene
entries that may contain one of = more media captures. A consumer may =
choose an capture scene entry in the knowledge that it is = a complete
representation of the scene for = a particular media type and that all =
media captures are spatially related. For a particular = media type the
consumer shall choose one = capture scene entry rather than choosing =
individual captures from multiple capture scene entries. = However this
does not mean that a consuming = endpoint must render all the media =
captures. What is locally rendered and how is a local = decision."

There have been some = suggestions that this could also eliminate the need for simultaneous = sets, because the scene entries would *be* the simultaneous sets. I'm = not sure if that is an integral part of this proposal or not. (If it is, = then it provides part of the justification.
Without this part I'm = not sure what the benefit is.)

I am inclined to agree that a new = definition of advertisement and configuration could be built around such = a concept. But to do so I think somebody will need to work out all the = details. For instance:
- can the same capture be in more than one = capture scene entry?
- how does the configure message specify which = entries it wants,
  and which captures from those = entries?

IMO the existing (prior?) model was at least clearer, = and arguably simpler. The way I have been thinking of it:

- an = advertisement advertises a bunch of captures, and information
=   about those captures to help the receiver decide which ones = it
  wants and how it should render them.

- scenes, = scene entries, simultaneous sets, are all just pieces of
=   that descriptive info.

- a configuration is simple - = it only needs to enumerate the
  captures that it wants. = It need not mention scenes or scene
  entries. (It might = need to identify scenes if the capture ids
  are scoped to = a scene.)

The proposed changes would make the configuration = message more complex.
The receiver would need to enumerate the = desired scene entries. And for each selected scene entry, identify those = captures that are (or are not) desired.

So, IMO, if some people = are interested in this new approach, I suggest they work on a detailed = proposal for how it would work, and then do a full assessment of the = pros/cons relative to the existing proposal.

= Thanks,
= Paul

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

      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_FCFF1A79-34A7-42B8-998B-5C1AC2C68409-- From christer.holmberg@ericsson.com Mon Dec 17 08:17: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 0F2A921F8B35 for ; Mon, 17 Dec 2012 08:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-Y-9JpdrabS for ; Mon, 17 Dec 2012 08:17:13 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 94E0C21F8A51 for ; Mon, 17 Dec 2012 08:17:12 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-58-50cf45875052 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1B.5F.24873.7854FC05; Mon, 17 Dec 2012 17:17:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 17:17:11 +0100 From: Christer Holmberg To: Simon Pietro Romano Thread-Topic: [clue] Can receiver select captures from more than one capture scene entry? Thread-Index: AQHN3G7jNhMiX1RGtE6QETHxZNdT+JgdKUsw Date: Mon, 17 Dec 2012 16:17:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B06788A@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se>, <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it> In-Reply-To: <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW676/kAg6nvdS32n7rMbLFiwwFW i21tN5gdmD3+vv/A5LFkyU8mjx9bnjIFMEdx2aSk5mSWpRbp2yVwZVyaeJa14Jphxd1Jd5ka GB+odjFyckgImEjsa1rOCGGLSVy4t56ti5GLQ0jgEKPE7/l3mCCcxYwSq1tvAGU4ONgELCS6 /2mDNIgIaEv8fvqOBcRmFvCU6Dsxmw3EFhaIkmh4coQFoiZaYnvDU1YI20hi2ud9YDUsAqoS tx//BYvzCnhLNM7byAqxq5VJYsnD3cwgCU4BG4nj//aAFTECXff91BomiGXiEreezGeCuFpA Ysme88wQtqjEy8f/WCFsRYmPr/YxQtTrSdyYOoUNwtaWWLbwNTPEYkGJkzOfsExgFJuFZOws JC2zkLTMQtKygJFlFSN7bmJmTnq50SZGYOQc3PJbdQfjnXMihxilOViUxHmtt+7xFxJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cDIfLTuZkvzKxnPrf8SFj5RnzvhU7iITP6L81f/Szz917v/ hFv5Hp34V/MKU6cfbtjC3bQ1+v3rdx8q2j9z8gpcWbEjPXrH4TcvQvayblsl96n6irZYornO AYbba0rFczPVDT8daS87J5Bks+FV9NobPr9ma2wMs9h59raOoN+35X/Z5wS0FHUoK7EUZyQa ajEXFScCAARZalJqAgAA Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 17 Dec 2012 16:17:14 -0000 Hi, >> Regarding 3): >> >> My suggestion is that, instead of indicating which captures can be simul= taneously provide, we indicate which CSEs (and, therefore all captures asso= ciated with the CSE) can be simultaneously provided. >> >> Something like: >> >> (CSE-X AND CSE-Y) OR CSE-Z. >> >> This means that the provider can provide CSE-X and CSE Y (and all captur= es associated with CSE-X and CSE-Y) simultaneously, or that the provider ca= n provide CSE-Z (and all captures associated with CSE-Z). >> > I like this proposal of expressing constraints as a canonicalized boolean= expression. > >> But, again, just because the receiver e.g. chooses to receive CSE-Y, it = still doesn't have to receive all captures associated with CSE-Y. It can ch= oose which ones it wants. >> > With respect to this point, we might state that: > > 1. if a CONFIGURE contains just a reference to a CSE, then all Capture Sc= enes therein contained are to be received; Yes. > 2. if a client does not want to receive all of the Capture Scenes contain= ed in a CSE, it has to explicitly indicate the ones it is interested in. Sure. Then, in addition to the CSE reference, it would have to indicate whi= ch associated captures it does not want to receive (or, which ones it wants= to receive, depending on how we want it). > From the data model standpoint, since the same Capture Scene can be conta= ined in multiple CSEs, we might list all Capture Scenes as independent elem= ents (uniquely identifiable through their IDs) and make a reference to them= inside each CSE element (through the IDREF approach). > > What is your feeling about this? Did you mean to say capture (instead of capture scene), ie that the same ca= pture can be contained in multiple CSEs? If that's the case, I agree that captures could be listed as independend el= ements, and then referenced through their IDs. (If a capture can only be associated with a single CSE, then it can be list= ed within that CSE). Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Paul Kyzivat Sent: 13. joulukuuta 2012 23:15 To: clue@ietf.org Subject: [clue] Can receiver select captures from more than one capture sce= ne entry? The "Capture scene clarifications" topic has been *very* popular, and is ge= tting confusing. Here I've changed the subject line to focus on one point - a change that wa= s been proposed by Christer. The latest description of it was from Christia= n Groves: "A consumer may receive an advertisement with multiple capture scenes. A consumer may choose to receive any number of capture scenes. An advertised capture scene it may contain one of more capture scene entries that may contain one of more media captures. A consumer may choose an capture scene entry in the knowledge that it is a complete representation of the scene for a particular media type and that all media captures are spatially related. For a particular media type the consumer shall choose one capture scene entry rather than choosing individual captures from multiple capture scene entries. However this does not mean that a consuming endpoint must render all the media captures. What is locally rendered and how is a local decision." There have been some suggestions that this could also eliminate the need fo= r simultaneous sets, because the scene entries would *be* the simultaneous = sets. I'm not sure if that is an integral part of this proposal or not. (If= it is, then it provides part of the justification. Without this part I'm not sure what the benefit is.) I am inclined to agree that a new definition of advertisement and configura= tion could be built around such a concept. But to do so I think somebody wi= ll need to work out all the details. For instance: - can the same capture be in more than one capture scene entry? - how does the configure message specify which entries it wants, and which captures from those entries? IMO the existing (prior?) model was at least clearer, and arguably simpler.= The way I have been thinking of it: - an advertisement advertises a bunch of captures, and information about those captures to help the receiver decide which ones it wants and how it should render them. - scenes, scene entries, simultaneous sets, are all just pieces of that descriptive info. - a configuration is simple - it only needs to enumerate the captures that it wants. It need not mention scenes or scene entries. (It might need to identify scenes if the capture ids are scoped to a scene.) The proposed changes would make the configuration message more complex. The receiver would need to enumerate the desired scene entries. And for eac= h selected scene entry, identify those captures that are (or are not) desir= ed. So, IMO, if some people are interested in this new approach, I suggest they= work on a detailed proposal for how it would work, and then do a full asse= ssment of the pros/cons relative to the existing proposal. 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 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From spromano@unina.it Mon Dec 17 08:28: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 F076421F8785 for ; Mon, 17 Dec 2012 08:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqJuS7sNAMKY for ; Mon, 17 Dec 2012 08:28:16 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78421F8773 for ; Mon, 17 Dec 2012 08:28:12 -0800 (PST) Received: from [10.219.39.29] ([10.219.39.29]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id qBHGS7Ec000650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 17:28:07 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D9A5CC7-1136-48D9-8DDF-AA59CE15D099" From: Simon Pietro Romano In-Reply-To: <7594FB04B1934943A5C02806D1A2204B06788A@ESESSMB209.ericsson.se> Date: Mon, 17 Dec 2012 17:28:07 +0100 Message-Id: <202C1A19-42F7-4E38-89D2-E272AB585C45@unina.it> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se>, <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it> <7594FB04B1934943A5C02806D1A2204B06788A@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 17 Dec 2012 16:28:24 -0000 --Apple-Mail=_1D9A5CC7-1136-48D9-8DDF-AA59CE15D099 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Of course I meant Capture (and not Capture Scene). All these names are = driving me nuts! Simon Il giorno 17/dic/2012, alle ore 17:17, Christer Holmberg ha scritto: >=20 > Hi, >=20 >>> Regarding 3): >>>=20 >>> My suggestion is that, instead of indicating which captures can be = simultaneously provide, we indicate which CSEs (and, therefore all = captures associated with the CSE) can be simultaneously provided. >>>=20 >>> Something like: >>>=20 >>> (CSE-X AND CSE-Y) OR CSE-Z. >>>=20 >>> This means that the provider can provide CSE-X and CSE Y (and all = captures associated with CSE-X and CSE-Y) simultaneously, or that the = provider can provide CSE-Z (and all captures associated with CSE-Z). >>>=20 >> I like this proposal of expressing constraints as a canonicalized = boolean expression. >>=20 >>> But, again, just because the receiver e.g. chooses to receive CSE-Y, = it still doesn't have to receive all captures associated with CSE-Y. It = can choose which ones it wants. >>>=20 >> With respect to this point, we might state that: >>=20 >> 1. if a CONFIGURE contains just a reference to a CSE, then all = Capture Scenes therein contained are to be received; >=20 > Yes. >=20 >> 2. if a client does not want to receive all of the Capture Scenes = contained in a CSE, it has to explicitly indicate the ones it is = interested in. >=20 > Sure. Then, in addition to the CSE reference, it would have to = indicate which associated captures it does not want to receive (or, = which ones it wants to receive, depending on how we want it). >=20 >> =46rom the data model standpoint, since the same Capture Scene can be = contained in multiple CSEs, we might list all Capture Scenes as = independent elements (uniquely identifiable through their IDs) and make = a reference to them inside each CSE element (through the IDREF = approach). >>=20 >> What is your feeling about this? >=20 > Did you mean to say capture (instead of capture scene), ie that the = same capture can be contained in multiple CSEs? >=20 > If that's the case, I agree that captures could be listed as = independend elements, and then referenced through their IDs. >=20 > (If a capture can only be associated with a single CSE, then it can be = listed within that CSE). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 13. joulukuuta 2012 23:15 > To: clue@ietf.org > Subject: [clue] Can receiver select captures from more than one = capture scene entry? >=20 > The "Capture scene clarifications" topic has been *very* popular, and = is getting confusing. >=20 > Here I've changed the subject line to focus on one point - a change = that was been proposed by Christer. The latest description of it was = from Christian Groves: >=20 > "A consumer may receive an advertisement with multiple capture = scenes. > A consumer may choose to receive any number of capture scenes. An > advertised capture scene it may contain one of more capture scene > entries that may contain one of more media captures. A consumer may > choose an capture scene entry in the knowledge that it is a complete > representation of the scene for a particular media type and that all > media captures are spatially related. For a particular media type the > consumer shall choose one capture scene entry rather than choosing > individual captures from multiple capture scene entries. However this > does not mean that a consuming endpoint must render all the media > captures. What is locally rendered and how is a local decision." >=20 > There have been some suggestions that this could also eliminate the = need for simultaneous sets, because the scene entries would *be* the = simultaneous sets. I'm not sure if that is an integral part of this = proposal or not. (If it is, then it provides part of the justification. > Without this part I'm not sure what the benefit is.) >=20 > I am inclined to agree that a new definition of advertisement and = configuration could be built around such a concept. But to do so I think = somebody will need to work out all the details. For instance: > - can the same capture be in more than one capture scene entry? > - how does the configure message specify which entries it wants, > and which captures from those entries? >=20 > IMO the existing (prior?) model was at least clearer, and arguably = simpler. The way I have been thinking of it: >=20 > - an advertisement advertises a bunch of captures, and information > about those captures to help the receiver decide which ones it > wants and how it should render them. >=20 > - scenes, scene entries, simultaneous sets, are all just pieces of > that descriptive info. >=20 > - a configuration is simple - it only needs to enumerate the > captures that it wants. It need not mention scenes or scene > entries. (It might need to identify scenes if the capture ids > are scoped to a scene.) >=20 > The proposed changes would make the configuration message more = complex. > The receiver would need to enumerate the desired scene entries. And = for each selected scene entry, identify those captures that are (or are = not) desired. >=20 > So, IMO, if some people are interested in this new approach, I suggest = they work on a detailed proposal for how it would work, and then do a = full assessment of the pros/cons relative to the existing proposal. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: = spromano@unina.it >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > = (_/ >=20 >=20 >=20 >=20 >=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_1D9A5CC7-1136-48D9-8DDF-AA59CE15D099 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Of = course I meant Capture (and not Capture Scene). All these names are = driving me nuts!

Simon

Il = giorno 17/dic/2012, alle ore 17:17, Christer Holmberg ha = scritto:


Hi,

Regarding 3):

My suggestion is that, instead = of indicating which captures can be simultaneously provide, we indicate = which CSEs (and, therefore all captures associated with the CSE) can be = simultaneously provided.

Something = like:

(CSE-X AND CSE-Y) OR = CSE-Z.

This means that the provider can = provide CSE-X and CSE Y (and all captures associated with CSE-X and = CSE-Y) simultaneously, or that the provider can provide CSE-Z (and all = captures associated with = CSE-Z).

I = like this proposal of expressing constraints as a canonicalized boolean = expression.

But, again, just because the receiver e.g. chooses to = receive CSE-Y, it still doesn't have to receive all captures associated = with CSE-Y. It can choose which ones it = wants.

With= respect to this point, we might state that:

1. if a = CONFIGURE contains just a reference to a CSE, then all Capture Scenes = therein contained are to be = received;

Yes.

2. = if a client does not want to receive all of the Capture Scenes contained = in a CSE, it has to explicitly indicate the ones it is interested = in.

Sure. Then, in addition to the CSE reference, it = would have to indicate which associated captures it does not want to = receive (or, which ones it wants to receive, depending on how we want = it).

=46rom the data model standpoint, = since the same Capture Scene can be contained in multiple CSEs, we might = list all Capture Scenes as independent elements (uniquely identifiable = through their IDs) and make a reference to them inside each CSE element = (through the IDREF approach).

What is your = feeling about this?

Did you mean to say capture = (instead of capture scene), ie that the same capture can be contained in = multiple CSEs?

If that's the case, I agree that captures could be = listed as independend elements, and then referenced through their = IDs.

(If a capture can only be associated with a single CSE, then = it can be listed within that = CSE).

Regards,

Christer






-----Orig= inal Message-----
From: clue-bounces@ietf.org<mailto:clue-bounces@ietf.org>= [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 13. = joulukuuta 2012 23:15
To: clue@ietf.org<mailto:clue@ietf.org>
Subject: = [clue] Can receiver select captures from more than one capture scene = entry?

The "Capture scene clarifications" topic has been *very* = popular, and is getting confusing.

Here I've changed the subject = line to focus on one point - a change that was been proposed by = Christer. The latest description of it was from Christian = Groves:

 "A consumer may receive an advertisement with = multiple capture scenes.
A consumer may choose to receive any number = of capture scenes. An
advertised capture scene it may contain one of = more capture scene
entries that may contain one of more media = captures. A consumer may
choose an capture scene entry in the = knowledge that it is a complete
representation of the scene for a = particular media type and that all
media captures are spatially = related. For a particular media type the
consumer shall choose one = capture scene entry rather than choosing
individual captures from = multiple capture scene entries. However this
does not mean that a = consuming endpoint must render all the media
captures. What is = locally rendered and how is a local decision."

There have been = some suggestions that this could also eliminate the need for = simultaneous sets, because the scene entries would *be* the simultaneous = sets. I'm not sure if that is an integral part of this proposal or not. = (If it is, then it provides part of the justification.
Without this = part I'm not sure what the benefit is.)

I am inclined to agree = that a new definition of advertisement and configuration could be built = around such a concept. But to do so I think somebody will need to work = out all the details. For instance:
- can the same capture be in more = than one capture scene entry?
- how does the configure message = specify which entries it wants,
 and which captures from those = entries?

IMO the existing (prior?) model was at least clearer, = and arguably simpler. The way I have been thinking of it:

- an = advertisement advertises a bunch of captures, and information
=  about those captures to help the receiver decide which ones it
=  wants and how it should render them.

- scenes, scene = entries, simultaneous sets, are all just pieces of
 that = descriptive info.

- a configuration is simple - it only needs to = enumerate the
 captures that it wants. It need not mention = scenes or scene
 entries. (It might need to identify scenes if = the capture ids
 are scoped to a scene.)

The proposed = changes would make the configuration message more complex.
The = receiver would need to enumerate the desired scene entries. And for each = selected scene entry, identify those captures that are (or are not) = desired.

So, IMO, if some people are interested in this new = approach, I suggest they work on a detailed proposal for how it would = work, and then do a full assessment of the pros/cons relative to the = existing = proposal.

Thanks,
Paul

__________________________________= _____________
clue mailing list
clue@ietf.org<mailto:clue@ietf.org>
https://www.ietf.org/m= ailman/listinfo/clue
______________________________________________= _
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

=             &n= bsp;           &nbs= p;   _\\|//_
=             &n= bsp;           &nbs= p;        ( O-O )
=   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ =             &n= bsp;       Simon Pietro Romano
=             &n= bsp; Universita' di Napoli Federico II
=             &n= bsp;        Computer Engineering = Department
=             Ph= one: +39 081 7683823 -- Fax: +39 081 7683816
=             &n= bsp;           &nbs= p;            =      e-mail: = spromano@unina.it<mailto:spromano@unina.it>

=    <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli
   idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.
=             &n= bsp;           &nbs= p;           oooO  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ = Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=             &n= bsp;   \ ( =            ( =   )
=             &n= bsp;           &nbs= p;        \_) =          ) /
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;        (_/




<= br>

      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_1D9A5CC7-1136-48D9-8DDF-AA59CE15D099-- From pkyzivat@alum.mit.edu Mon Dec 17 09:14:20 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B4621F8B32 for ; Mon, 17 Dec 2012 09:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOFqPBTDhEpV for ; Mon, 17 Dec 2012 09:14:19 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF0221F8B46 for ; Mon, 17 Dec 2012 09:14:19 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id cdGR1k00616LCl055hEJAM; Mon, 17 Dec 2012 17:14:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id chEJ1k0093ZTu2S3ShEJye; Mon, 17 Dec 2012 17:14:18 +0000 Message-ID: <50CF52E9.8000302@alum.mit.edu> Date: Mon, 17 Dec 2012 12:14:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Simon Pietro Romano References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it> In-Reply-To: <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355764458; bh=zqeT7eCcJioNpvWk151zgAimZlRmnhPf3QTsQUDe4lY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ng26gTNWRNOBjixfoX3H8+D8kMol7TtM41vNw/NqlkTnLnB0UcQIleJO2BkEJvnJk Xli5hscxVQJ/50EBK4dZYLMQrJuEvj0yFAqe6+K8iVOny/7HICxdFyI+DLbm8nblrw gSGyLOsAQBdYCk1S6hYQFvd/D3Vku+nT/gsWwlT2k4JbA4SOLqX8kl6n5iE1HOEFps 6f0L9uuO5Bm3yyrpWGZJCYIKhDz1yvLL8SR2wlg5TmqIYbma/zuXJsSODAX4V2cyKE roKRsdn5foslGjhhzR45n1D3e4hwxp157Vyqf+WrRKKnbb01sD00kKjCT9FkUEOZ7i 4Pz4ZxvfYE/6Q== Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 17 Dec 2012 17:14:20 -0000 On 12/17/12 10:54 AM, Simon Pietro Romano wrote: > Hi, > >> Regarding 3): >> >> My suggestion is that, instead of indicating which captures can be >> simultaneously provide, we indicate which CSEs (and, therefore all >> captures associated with the CSE) can be simultaneously provided. >> >> Something like: >> >> (CSE-X AND CSE-Y) OR CSE-Z. >> >> This means that the provider can provide CSE-X and CSE Y (and all >> captures associated with CSE-X and CSE-Y) simultaneously, or that the >> provider can provide CSE-Z (and all captures associated with CSE-Z). > > I like this proposal of expressing constraints as a canonicalized > boolean expression. This is independent of whether this refers to captures or CSEs. >> But, again, just because the receiver e.g. chooses to receive CSE-Y, >> it still doesn't have to receive all captures associated with CSE-Y. >> It can choose which ones it wants. > > With respect to this point, we might state that: > > 1. if a CONFIGURE contains just a reference to a CSE, then all Capture > Scenes therein contained are to be received; > 2. if a client does not want to receive all of the Capture Scenes > contained in a CSE, it has to explicitly indicate the ones it is > interested in. I still say that this is simply an optimization on the representation of the config message. It is not fundamental. What is fundamental is a decision that we don't need simultaneous sets because CSEs serve the purpose. Can we please leave the syntax optimizations out of the discussion for now? They confuse the discussion of fundamentals. > From the data model standpoint, since the same Capture Scene can be > contained in multiple CSEs, we might list all Capture Scenes as > independent elements (uniquely identifiable through their IDs) and make > a reference to them inside each CSE element (through the IDREF approach). The above makes no sense to me. It would make sense if you replace "Capture Scene" with "Capture". Is that what you meant? And yes, I generally agree with that. (I've previously stated that I think captures are scoped to a scene. The same capture cannot be in two scenes, because the scene defines the coordinate space in which it resides.) That could be handled by actually nesting the specification of the captures within the specification of their Scene. Or it could be handled by declaring the captures separately, but including a reference to the scene in which they reside. The latter seems a bit cleaner to me. I have also been thinking about a bigger change: have a single list of CSEs for the advertisement, rather than one per scene. (CSE is then a misnomer, but for now I'll still use it.) Each entry would contain a list of captures that, taken together, is a recommended rendition of the advertisement as a whole. This would allow tradeoffs between captures in different scenes to offer choices with fewer captures than scenes. There is currently no way to do that. I can't think of any downsides to this change. What do people think of this? Thanks, Paul > What is your feeling about this? > > Simon > > > > >> >> >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 13. joulukuuta 2012 23:15 >> To: clue@ietf.org >> Subject: [clue] Can receiver select captures from more than one >> capture scene entry? >> >> The "Capture scene clarifications" topic has been *very* popular, and >> is getting confusing. >> >> Here I've changed the subject line to focus on one point - a change >> that was been proposed by Christer. The latest description of it was >> from Christian Groves: >> >>>> "A consumer may receive an advertisement with multiple capture scenes. >>>> A consumer may choose to receive any number of capture scenes. An >>>> advertised capture scene it may contain one of more capture scene >>>> entries that may contain one of more media captures. A consumer may >>>> choose an capture scene entry in the knowledge that it is a complete >>>> representation of the scene for a particular media type and that all >>>> media captures are spatially related. For a particular media type the >>>> consumer shall choose one capture scene entry rather than choosing >>>> individual captures from multiple capture scene entries. However this >>>> does not mean that a consuming endpoint must render all the media >>>> captures. What is locally rendered and how is a local decision." >> >> There have been some suggestions that this could also eliminate the >> need for simultaneous sets, because the scene entries would *be* the >> simultaneous sets. I'm not sure if that is an integral part of this >> proposal or not. (If it is, then it provides part of the justification. >> Without this part I'm not sure what the benefit is.) >> >> I am inclined to agree that a new definition of advertisement and >> configuration could be built around such a concept. But to do so I >> think somebody will need to work out all the details. For instance: >> - can the same capture be in more than one capture scene entry? >> - how does the configure message specify which entries it wants, >> and which captures from those entries? >> >> IMO the existing (prior?) model was at least clearer, and arguably >> simpler. The way I have been thinking of it: >> >> - an advertisement advertises a bunch of captures, and information >> about those captures to help the receiver decide which ones it >> wants and how it should render them. >> >> - scenes, scene entries, simultaneous sets, are all just pieces of >> that descriptive info. >> >> - a configuration is simple - it only needs to enumerate the >> captures that it wants. It need not mention scenes or scene >> entries. (It might need to identify scenes if the capture ids >> are scoped to a scene.) >> >> The proposed changes would make the configuration message more complex. >> The receiver would need to enumerate the desired scene entries. And >> for each selected scene entry, identify those captures that are (or >> are not) desired. >> >> So, IMO, if some people are interested in this new approach, I suggest >> they work on a detailed proposal for how it would work, and then do a >> full assessment of the pros/cons relative to the existing proposal. >> >> 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 >> > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > From christer.holmberg@ericsson.com Mon Dec 17 10:44: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 9E8AF21F8BD5 for ; Mon, 17 Dec 2012 10:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TPZTc7dQDgk for ; Mon, 17 Dec 2012 10:44:48 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 342DC21F8BD4 for ; Mon, 17 Dec 2012 10:44:47 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-30-50cf681ef361 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DC.AE.24873.E186FC05; Mon, 17 Dec 2012 19:44:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 19:44:46 +0100 From: Christer Holmberg To: Paul Kyzivat , Simon Pietro Romano Thread-Topic: [clue] Can receiver select captures from more than one capture scene entry? Thread-Index: AQHN3Hn0g7YsKnVso0yin5dQG9gVdZgdUFyK Date: Mon, 17 Dec 2012 18:44:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0689A1@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it>, <50CF52E9.8000302@alum.mit.edu> In-Reply-To: <50CF52E9.8000302@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvja58xvkAgx+bWSz2n7rMbLFiwwFW i21tN5gdmD3+vv/A5LFkyU8mjx9bnjIFMEdx2aSk5mSWpRbp2yVwZZyb2M5UMNOuYm6HRgPj M/0uRk4OCQETiSVfbzJC2GISF+6tZwOxhQQOMUp0N5V2MXIB2YsZJd6eWcPUxcjBwSZgIdH9 TxukRkQgWKJv0g9WEJtZQFnia8MmJhBbWCBK4tDGv6wQNdESL1deZ4KwjSQu9GxnBrFZBFQl tr+awA4yklfAW6LxiBPEquVMEg97HrCA1HAK6EgsXLIM7B5GoNu+n1rDBLFLXOLWk/lMEDcL SCzZc54ZwhaVePn4HyvITAkBRYnl/XIQ5XoSN6ZOYYOwtSWWLXwNVs4rIChxcuYTlgmMYrOQ TJ2FpGUWkpZZSFoWMLKsYmTPTczMSS832sQIjJiDW36r7mC8c07kEKM0B4uSOK/11j3+QgLp iSWp2ampBalF8UWlOanFhxiZODilGhhl1j7f8fjYH3GBh/uunlu6KiDuvPUD2UZTz5XJJWJm rQGL9/9/4uFYV/t8+sypTD9lFLjtPuy9ULa6RJR554+9X0/oekeUbyyb6LPZ0Xn5zPBVmru/ i01bOcnGYsaiyi7Ol2XvJGaqXZm+jrG8Il/lo3hruLtaxhrVU5e9fzQqvzc3SUrZIZuixFKc kWioxVxUnAgAd91DpWYCAAA= Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 17 Dec 2012 18:44:49 -0000 Hi, >>> But, again, just because the receiver e.g. chooses to receive CSE-Y, >>> it still doesn't have to receive all captures associated with CSE-Y. >>> It can choose which ones it wants. >> >> With respect to this point, we might state that: >> >> 1. if a CONFIGURE contains just a reference to a CSE, then all Capture >> Scenes therein contained are to be received; >> 2. if a client does not want to receive all of the Capture Scenes >> contained in a CSE, it has to explicitly indicate the ones it is >> interested in. > > I still say that this is simply an optimization on the representation of > the config message. It is not fundamental. > > What is fundamental is a decision that we don't need simultaneous sets > because CSEs serve the purpose. > > Can we please leave the syntax optimizations out of the discussion for > now? They confuse the discussion of fundamentals. Yes. So, again: My opinion is that we do not need simultaneous capture sets - si= mulataneous CSE sets are enough. >> From the data model standpoint, since the same Capture Scene can be >> contained in multiple CSEs, we might list all Capture Scenes as >> independent elements (uniquely identifiable through their IDs) and make >> a reference to them inside each CSE element (through the IDREF approach)= . > > The above makes no sense to me. It would make sense if you replace > "Capture Scene" with "Capture". Is that what you meant? And yes, I > generally agree with that. He meant "yes" :) > (I've previously stated that I think captures are scoped to a scene. The > same capture cannot be in two scenes, because the scene defines the > coordinate space in which it resides.) I agree with that. I think we should keep scenes "independent" from each ot= her, meaning that inside one scene we don't need to refer to stuff in anoth= er scenes. > That could be handled by actually nesting the specification of the > captures within the specification of their Scene. Or it could be handled > by declaring the captures separately, but including a reference to the > scene in which they reside. The latter seems a bit cleaner to me. I agree. The Scene specification should contain the CSEs and captures assoc= iated with that Scene: List of CSEs, refering to captures in the capture list List of captures > I have also been thinking about a bigger change: have a single list of > CSEs for the advertisement, rather than one per scene. (CSE is then a > misnomer, but for now I'll still use it.) Each entry would contain a > list of captures that, taken together, is a recommended rendition of the > advertisement as a whole. This would allow tradeoffs between captures in > different scenes to offer choices with fewer captures than scenes. There > is currently no way to do that. I can't think of any downsides to this > change. What do people think of this? I am not sure I understand. What do you mean by "rather than one per scene"? You can advertise multiple= CSEs per scene, can't you? I am also not sure I understand what you mean by "rendition of the advertis= ement". And, I am not sure I understand "tradeoffs between captures in different sc= enes". I thougth you suggested that captures can only belong to one scene? Regards, Christer >> >> >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 13. joulukuuta 2012 23:15 >> To: clue@ietf.org >> Subject: [clue] Can receiver select captures from more than one >> capture scene entry? >> >> The "Capture scene clarifications" topic has been *very* popular, and >> is getting confusing. >> >> Here I've changed the subject line to focus on one point - a change >> that was been proposed by Christer. The latest description of it was >> from Christian Groves: >> >>>> "A consumer may receive an advertisement with multiple capture scene= s. >>>> A consumer may choose to receive any number of capture scenes. An >>>> advertised capture scene it may contain one of more capture scene >>>> entries that may contain one of more media captures. A consumer may >>>> choose an capture scene entry in the knowledge that it is a complete >>>> representation of the scene for a particular media type and that all >>>> media captures are spatially related. For a particular media type the >>>> consumer shall choose one capture scene entry rather than choosing >>>> individual captures from multiple capture scene entries. However this >>>> does not mean that a consuming endpoint must render all the media >>>> captures. What is locally rendered and how is a local decision." >> >> There have been some suggestions that this could also eliminate the >> need for simultaneous sets, because the scene entries would *be* the >> simultaneous sets. I'm not sure if that is an integral part of this >> proposal or not. (If it is, then it provides part of the justification. >> Without this part I'm not sure what the benefit is.) >> >> I am inclined to agree that a new definition of advertisement and >> configuration could be built around such a concept. But to do so I >> think somebody will need to work out all the details. For instance: >> - can the same capture be in more than one capture scene entry? >> - how does the configure message specify which entries it wants, >> and which captures from those entries? >> >> IMO the existing (prior?) model was at least clearer, and arguably >> simpler. The way I have been thinking of it: >> >> - an advertisement advertises a bunch of captures, and information >> about those captures to help the receiver decide which ones it >> wants and how it should render them. >> >> - scenes, scene entries, simultaneous sets, are all just pieces of >> that descriptive info. >> >> - a configuration is simple - it only needs to enumerate the >> captures that it wants. It need not mention scenes or scene >> entries. (It might need to identify scenes if the capture ids >> are scoped to a scene.) >> >> The proposed changes would make the configuration message more complex. >> The receiver would need to enumerate the desired scene entries. And >> for each selected scene entry, identify those captures that are (or >> are not) desired. >> >> So, IMO, if some people are interested in this new approach, I suggest >> they work on a detailed proposal for how it would work, and then do a >> full assessment of the pros/cons relative to the existing proposal. >> >> 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 >> > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (= _/ > > > > > From christer.holmberg@ericsson.com Mon Dec 17 11:22:02 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0501821F8653 for ; Mon, 17 Dec 2012 11:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPBVzbUcWnqZ for ; Mon, 17 Dec 2012 11:22:01 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AE38121F85C0 for ; Mon, 17 Dec 2012 11:21:59 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-15-50cf70d66556 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 69.FA.10459.6D07FC05; Mon, 17 Dec 2012 20:21:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 20:21:58 +0100 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] Cancelled: CLUE Design Team meeting - Dec. 17th Thread-Index: AQHN3G6H3p9vfE6R60etXBOmNNnQDpgdW/5q Date: Mon, 17 Dec 2012 19:21:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B068A4C@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje61gvMBBtMPWFrsP3WZ2eLz/v3M DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGlMMdTAX/+Cp2HNnA1sDYzdPFyMkhIWAi cfPFBxYIW0ziwr31bF2MXBxCAocYJTon/WKEcBYzSmx9PQUow8HBJmAh0f1PG6RBRMBJ4sLL 92DNwgLOEmcOTWSDiLtIbN25mhXCNpJY+fImWJxFQFXi6O7pYDavgLfEw0cvwHqFBAIkjm7v BItzCgRK/F/bww5iMwId9P3UGiYQm1lAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyvIaRICihLL ++UgynUkFuz+xAZha0ssW/iaGWKtoMTJmU9YJjCKzkIydRaSlllIWmYhaVnAyLKKkT03MTMn vdxwEyMwEg5u+a27g/HUOZFDjNIcLErivFxJ+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MHrIXeTs+bcxfVbS7h9ut/9uaE8QMsqpWGZ8660sx31vfgcN1da+rV9MAm0nbJ21ROz7deUL Ttt7AuPXi37amcbwN1pD0mn1/qK8/YE3KvadtHIL4zt07brxgVO7936zE58qkWOYy7DJxSHd yetWwGHBt2+OnKtzK8k7+uDwzJyPu9ynntuhyqnEUpyRaKjFXFScCACAKTOtUgIAAA== Subject: Re: [clue] Cancelled: CLUE Design Team meeting - Dec. 17th 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, 17 Dec 2012 19:22:02 -0000 Hi, It is true that there is currently no new material. I'd like to discuss one thing, related to signalling, though. Some time ago, I indicated that I think it would be good to define a "singl= e-stream SDP offer", ie how an SDP offer sent from a CLUE entity to a singl= e-stream device would look like. The reason why I think it is useful is bec= ause it makes it much easier for operators (and other SDOs) to introduce CL= UE into their networks, and to verify that non-CLUE entities can interopera= te with CLUE entities. I am currently working on a short draft, which: - Describes with m- lines (audio, main video, presentation video and "clue = channel") the SDP offer would contain. A non-CLUE entity would of course re= ject the "clue channel" m- line, which would also be an indicator that it i= s a CLUE entity. - Describes the SDP attributes which the SDP offer would contain, in order = to provide a good experience. Of course, we cannot guarantee that the non-C= LUE entity will support all SDP attributes, and the CLUE entity should be p= repared to handle that. But, it will make it easier for operators to put re= quirements on their non-CLUE entity vendors. Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Monday, 17 December 2012 5:52 PM To: CLUE Subject: [clue] Cancelled: CLUE Design Team meeting - Dec. 17th Hi all, The plan had been to discuss further details on the signaling solution. However, there is no new material related to this at this time. We'll start back with meetings on January 7th (pending of course content for the meetings). Regards, Mary CLUE WG co-chair. _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Dec 17 11:35: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 6822721F88A9 for ; Mon, 17 Dec 2012 11:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIRtokYg8IUt for ; Mon, 17 Dec 2012 11:35:46 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 9F67C21F889C for ; Mon, 17 Dec 2012 11:35:46 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id ceve1k0070mv7h05DjbmUL; Mon, 17 Dec 2012 19:35:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id cjbl1k00p3ZTu2S3XjbluD; Mon, 17 Dec 2012 19:35:46 +0000 Message-ID: <50CF7410.8010807@alum.mit.edu> Date: Mon, 17 Dec 2012 14:35:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it>, <50CF52E9.8000302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0689A1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0689A1@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355772946; bh=12GiRFyuBRZsEam2XofSKQKiidvYgaUEJ0eTDoaDpkA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZN63ZZXUmZsKIPYPmnfEXUpcJuaKY7DJsjC1nVk5GncSf9TKhUPi3IcgUFxBhGywu jXPdnIbIs0gGUU7tgcdx0yyEOGwJbUl3ciHvEBa4yaN8MQSvGhNUH7Jaaxa4Kb0Of0 AXkV9R3Uux+8ss9ElgwdiV+itYAjc2Of+pwrfQ8DJDglYsirEaj4vA8K2TBLRnoZQS LS5peGThi4Z2kMUasSSPiXA5FOCxlWyiANSQiuhaOfCXDL26wft34gPhGsqzJrisy8 7AAUR5pK0IeiDOLcXAxcAMoi0u2f6wPAs1yL4pQgo6QkBNCR9DsQARZ3rR42uk0VWd rXt1hKyR4eG2A== Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 17 Dec 2012 19:35:47 -0000 On 12/17/12 1:44 PM, Christer Holmberg wrote: >> I have also been thinking about a bigger change: have a single list of >> CSEs for the advertisement, rather than one per scene. (CSE is then a >> misnomer, but for now I'll still use it.) Each entry would contain a >> list of captures that, taken together, is a recommended rendition of the >> advertisement as a whole. This would allow tradeoffs between captures in >> different scenes to offer choices with fewer captures than scenes. There >> is currently no way to do that. I can't think of any downsides to this >> change. What do people think of this? > > I am not sure I understand. > > What do you mean by "rather than one per scene"? You can advertise multiple CSEs per scene, can't you? > > I am also not sure I understand what you mean by "rendition of the advertisement". > > And, I am not sure I understand "tradeoffs between captures in different scenes". I thougth you suggested that captures can only belong to one scene? OK, obviously I didn't explain myself very well. Let me try again. First, instead of a list of CSEs per scene, I'm proposing a list of (something) per advertisement. Just to have something, for now lets call them Advertisement Entries - ADEs. Like a CSE, each ADE is a list of captures. In this case they can be any capture in the advertisement, regardless of scene. So overall structure is something like: (descriptive info for the scene) (descriptive info for the scene) ... ... ... ... ... ... ... ... f1,f2,b1,b2 f3,b1,b2 f1,f2,b3 f3,b3 b3 Here, you can think that f3 is a composite of f1 & f2, and b3 is a composite of b1 and b2. Perhaps scene foo is a room, and scene bar contains a couple of presentations. This explicitly allows the advertiser to think about and propose tradeoffs between scenes. So a5 makes the decision that if you can only receive one capture you are better off getting the presentation than the room. Does it make sense now? Thanks, Paul From pkyzivat@alum.mit.edu Mon Dec 17 11:50: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 7A93B21F87D8 for ; Mon, 17 Dec 2012 11:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-2mRsboKrto for ; Mon, 17 Dec 2012 11:50:07 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id BB0D121F87D1 for ; Mon, 17 Dec 2012 11:50:06 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id cbrb1k00727AodY53jq6Tl; Mon, 17 Dec 2012 19:50:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id cjq51k0113ZTu2S3fjq5wr; Mon, 17 Dec 2012 19:50:05 +0000 Message-ID: <50CF776C.8080903@alum.mit.edu> Date: Mon, 17 Dec 2012 14:50:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B068A4C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B068A4C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355773806; bh=JBzBk6swfqqVmSre9zinyXsH9LE2DkBHdsULmjllacc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZxJI8WUuJ7AljGdFs3bHLyJs+Cd9gLczO+C7pnwR7ylvCMJSayDqfZD8uh4uHjpjv YKBi5NxCpg2f5zVT89Y5FV6TLi6/RbpMassztHKzJJwwqMQh8GV3N9vHtWPJ9+qhi6 V9qppVGNQvML1bU7nIBSV99/S4qi14t0B9x7ysBlgfjzP99z9fmExstbt1ySD7pDGT rsibWlD+n9c4MnAsB2T4YOenBA8nHiRB5au8yVKXKj/0dA0amaMrjWnT1uK++64Y/X jtsETZYL7a7EmQr0k3rcI44q22AuKfD7fru+KdHXObr8GhXadDMfIabYHRYp40lTFL Mmprp0msW10/w== Subject: [clue] Signaling - single-stream special case 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, 17 Dec 2012 19:50:07 -0000 On 12/17/12 2:21 PM, Christer Holmberg wrote: > > Hi, > > It is true that there is currently no new material. > > I'd like to discuss one thing, related to signalling, though. > > Some time ago, I indicated that I think it would be good to define a "single-stream SDP offer", ie how an SDP offer sent from a CLUE entity to a single-stream device would look like. The reason why I think it is useful is because it makes it much easier for operators (and other SDOs) to introduce CLUE into their networks, and to verify that non-CLUE entities can interoperate with CLUE entities. > > I am currently working on a short draft, which: > > - Describes with m- lines (audio, main video, presentation video and "clue channel") the SDP offer would contain. A non-CLUE entity would of course reject the "clue channel" m- line, which would also be an indicator that it is a CLUE entity. > - Describes the SDP attributes which the SDP offer would contain, in order to provide a good experience. Of course, we cannot guarantee that the non-CLUE entity will support all SDP attributes, and the CLUE entity should be prepared to handle that. But, it will make it easier for operators to put requirements on their non-CLUE entity vendors. While this might eventually be interesting, IMO it puts the cart before the horse. We REALLY REALLY REALLY need to nail down our signaling, and we have hardly any specifics yet. The main cases of interest for that are the multistream cases. When the general mechanism is worked out for multistream, there will be a degenerate case of *that* where only one capture is configured. Ideally that will be just fine for a clue supporting endpoint that is only capable of managing one capture. The SDP for that may also turn out to be fine for non-clue-supporting endpoints. If not, we can then discuss if we want to do something different for non-clue endpoints. But right now I think this is a distraction from getting a good start on the signaling. And you signed up for the team working on signaling. Thanks, Paul (as co-chair) From christer.holmberg@ericsson.com Mon Dec 17 12:03: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 6996521F8536 for ; Mon, 17 Dec 2012 12:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTfPpD2M+oZh for ; Mon, 17 Dec 2012 12:03:17 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEA921F8415 for ; Mon, 17 Dec 2012 12:03:10 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-72-50cf7a7cc59e Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DA.7E.10459.C7A7FC05; Mon, 17 Dec 2012 21:03:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 21:03:08 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Signaling - single-stream special case Thread-Index: AQHN3I+5TgBdDVIL/EWKoRhVi3T43JgdZ5RK Date: Mon, 17 Dec 2012 20:03:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B068C42@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B068A4C@ESESSMB209.ericsson.se>, <50CF776C.8080903@alum.mit.edu> In-Reply-To: <50CF776C.8080903@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjW5t1fkAg1M32Cz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjzOtpLAVvJSte/tzB1sB4V6SLkYNDQsBE 4ugRoS5GTiBTTOLCvfVsXYxcHEIChxglFq47AOUsZpR42dTADNLAJmAh0f1PG6RBRMBTYsfH KcwgtrCAlcTOX7uYIeLWEtemTYGyjSTeP/7PAmKzCKhKrF7UzA4yhlfAW2LJzwiI8ZsYJdpf zASr5xTQkTjychKYzQh00PdTa5hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQvyhKLO+X gyjXkViw+xMbhK0tsWzha7ByXgFBiZMzn7BMYBSdhWTqLCQts5C0zELSsoCRZRUje25iZk56 ueEmRmAcHNzyW3cH46lzIocYpTlYlMR5uZL2+wsJpCeWpGanphakFsUXleakFh9iZOLglGpg rHvR67UhY/qNjlOfNq3IW/L19eqvZwuNV4jU70k7IbraguOS/26VxI0WH6r9b13kjP2gcTie 4d/fBVMOz5U8xeXeGGAfpXdvEtOPd+IyveFeydyqslHNC7ZW+cq9bTu+bZvqkj8CHsaH3m0+ oLKDub6CaRq7/AbrG2rfKj5+3+Bj9c4wT9M5S4mlOCPRUIu5qDgRAJwzrbFRAgAA Subject: Re: [clue] Signaling - single-stream special case 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, 17 Dec 2012 20:03:18 -0000 Hi Paul, I think this IS part of the signalling work. We have been discussing that the first SDP offer should establish some "bas= ic" session. What I'm talking about is how that SDP offer would look lite. (Then, if both endpoints are CLUE, it will also establish the CLUE channel,= and after that the multistream negotiations, CLUE advertisements/configura= tions etc will start). I do agree that the single-stream use-case as such is not our main priority= . But, if we don't even know how the first offer will look like, how can we= define the additional signalling procedures? We need to know whether we ne= ed to add m- lines etc, or whether we can re-use the "basic" session m- lin= es and only add additional SSRC etc. Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Monday, 17 December 2012 9:50 PM To: clue@ietf.org Subject: [clue] Signaling - single-stream special case On 12/17/12 2:21 PM, Christer Holmberg wrote: > > Hi, > > It is true that there is currently no new material. > > I'd like to discuss one thing, related to signalling, though. > > Some time ago, I indicated that I think it would be good to define a "sin= gle-stream SDP offer", ie how an SDP offer sent from a CLUE entity to a sin= gle-stream device would look like. The reason why I think it is useful is b= ecause it makes it much easier for operators (and other SDOs) to introduce = CLUE into their networks, and to verify that non-CLUE entities can interope= rate with CLUE entities. > > I am currently working on a short draft, which: > > - Describes with m- lines (audio, main video, presentation video and "clu= e channel") the SDP offer would contain. A non-CLUE entity would of course = reject the "clue channel" m- line, which would also be an indicator that it= is a CLUE entity. > - Describes the SDP attributes which the SDP offer would contain, in orde= r to provide a good experience. Of course, we cannot guarantee that the non= -CLUE entity will support all SDP attributes, and the CLUE entity should be= prepared to handle that. But, it will make it easier for operators to put = requirements on their non-CLUE entity vendors. While this might eventually be interesting, IMO it puts the cart before the horse. We REALLY REALLY REALLY need to nail down our signaling, and we have hardly any specifics yet. The main cases of interest for that are the multistream cases. When the general mechanism is worked out for multistream, there will be a degenerate case of *that* where only one capture is configured. Ideally that will be just fine for a clue supporting endpoint that is only capable of managing one capture. The SDP for that may also turn out to be fine for non-clue-supporting endpoints. If not, we can then discuss if we want to do something different for non-clue endpoints. But right now I think this is a distraction from getting a good start on the signaling. And you signed up for the team working on signaling. Thanks, Paul (as co-chair) _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Mon Dec 17 12:58:02 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF8F21F8886 for ; Mon, 17 Dec 2012 12:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QtXm-0Tn4xT for ; Mon, 17 Dec 2012 12:58:02 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A173221F8880 for ; Mon, 17 Dec 2012 12:58:01 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-1a-50cf8758ae26 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A1.D9.24873.8578FC05; Mon, 17 Dec 2012 21:58:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 21:57:59 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [clue] Can receiver select captures from more than one capture scene entry? Thread-Index: AQHN3Hn0g7YsKnVso0yin5dQG9gVdZgdUFyKgAABVQCAACDqKg== Date: Mon, 17 Dec 2012 20:57:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0694D5@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it>, <50CF52E9.8000302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0689A1@ESESSMB209.ericsson.se>, <50CF7410.8010807@alum.mit.edu> In-Reply-To: <50CF7410.8010807@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW5E+/kAg49v1Cz2n7rMbLFiwwFW i21tN5gdmD3+vv/A5LFkyU8mjx9bnjIFMEdx2aSk5mSWpRbp2yVwZWx4f5y5YKZExe+uzWwN jF+Euhg5OSQETCTWvGligbDFJC7cW8/WxcjFISRwiFHiSOcvdghnMaPEq/7FQBkODjYBC4nu f9ogpoiAhsSkrWogvcwCPhKPX89iBLGFBaIkDm38ywpiiwhES7xceZ0JwnaSWPTmApjNIqAq MXnpa2YQm1fAW+Ja6z2ovZ3MEmfWdLCBJDgFdCSmHusEG8QIdNz3U2uYIJaJS9x6Mp8J4mgB iSV7zjND2KISLx//YwW5TUJAUWJ5vxxEuY7Egt2f2CBsbYllC2H2CkqcnPmEZQKj2CwkU2ch aZmFpGUWkpYFjCyrGNlzEzNz0suNNjECo+bglt+qOxjvnBM5xCjNwaIkzmu9dY+/kEB6Yklq dmpqQWpRfFFpTmrxIUYmDk6pBsbWpwVKejI8LEvnm6gsuPD4QGrf77RNM2XZ5n5b5NlyMWCJ ebY3v3DscePNleaHF/PIBwRK99+QZppZe03u4ITy3WHb/5z9KCaZznr15fYrkrLc4scrF5by rjud2eh0dM3574dEhaVi7l2ZLnhrScKlpuYE99fHv8hNkJt41ZbF+u+JjEjp2slKLMUZiYZa zEXFiQBz3vrZaAIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 17 Dec 2012 20:58:02 -0000 Hi, >>> I have also been thinking about a bigger change: have a single list of >>> CSEs for the advertisement, rather than one per scene. (CSE is then a >>> misnomer, but for now I'll still use it.) Each entry would contain a >>> list of captures that, taken together, is a recommended rendition of th= e >>> advertisement as a whole. This would allow tradeoffs between captures i= n >>> different scenes to offer choices with fewer captures than scenes. Ther= e >>> is currently no way to do that. I can't think of any downsides to this >>> change. What do people think of this? >> >> I am not sure I understand. >> >> What do you mean by "rather than one per scene"? You can advertise multi= ple CSEs per scene, can't you? >> >> I am also not sure I understand what you mean by "rendition of the adver= tisement". >> >> And, I am not sure I understand "tradeoffs between captures in different= scenes". I thougth you suggested that captures can only belong to one scen= e? > > OK, obviously I didn't explain myself very well. Let me try again. > > First, instead of a list of CSEs per scene, I'm proposing a list of > (something) per advertisement. Just to have something, for now lets call > them Advertisement Entries - ADEs. Like a CSE, each ADE is a list of > captures. In this case they can be any capture in the advertisement, > regardless of scene. > > So overall structure is something like: > > > > (descriptive info for the scene) > (descriptive info for the scene) > ... > > > ... > ... > ... > ... > ... > ... > ... > > > f1,f2,b1,b2 > f3,b1,b2 > f1,f2,b3 > f3,b3 > b3 > > > > > Here, you can think that f3 is a composite of f1 & f2, and b3 is a > composite of b1 and b2. Perhaps scene foo is a room, and scene bar > contains a couple of presentations. > > This explicitly allows the advertiser to think about and propose > tradeoffs between scenes. So a5 makes the decision that if you can only > receive one capture you are better off getting the presentation than the > room. I think it's quite strange if the advertiser starts to advertise "partly sc= enes", trying to figure out what the receiver may want, and trying to figur= e out what the capabilities of the receiver are. My preference is still that we don't need to advertise scene trade-offs. In= stead the advertiser provides full scene alternatives (CSEs), and let the r= eceiver choose which scene(s) (and associated CSEs), it wants to receive. Regards, Christer From pkyzivat@alum.mit.edu Mon Dec 17 13:40: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 DF15121F873F for ; Mon, 17 Dec 2012 13:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZoOaoAkrD9V for ; Mon, 17 Dec 2012 13:40:43 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id DBC1F21F875D for ; Mon, 17 Dec 2012 13:40:42 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta09.westchester.pa.mail.comcast.net with comcast id cc4P1k0010SCNGk59lgihE; Mon, 17 Dec 2012 21:40:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id clgh1k00V3ZTu2S3VlghmW; Mon, 17 Dec 2012 21:40:42 +0000 Message-ID: <50CF9158.7000902@alum.mit.edu> Date: Mon, 17 Dec 2012 16:40:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B068A4C@ESESSMB209.ericsson.se>, <50CF776C.8080903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B068C42@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B068C42@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355780442; bh=OOcy5k6fYPXZwHGZT9WmMA2JjPuPi+ReHBwlDc2mxac=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EHRB9BEKySU/qnjloTxP7KPATQlVnLkkiBmwEDnlOkL20+nHuW/nWyuCA+uShcbeW VYjSg4MJjNTE4ctaIYtk1apjXZUx1U98UJ+tgxtg+2tiv0CY/HaxmPSbUvzc8Ny+Wd wQZhdkxYDpMvrvhIexoGkC0b+xb1TMbJh6BgxQvxH75V5cab8H1H2S/5ZiLR2mAYDA AFWe0D2UMws82PGOw0FtOBMss3ddd/WIkDfRJ5BxX/g4SdUM4zFM+UFWK30ruH9Av/ +K4f6YqRn1pb/KIr2Y557p64KyGwZferJq0La77TE3r0lhn+PFcKD1/QOsVAyRqFdn J7kG37DrqD/kg== Cc: "clue@ietf.org" Subject: Re: [clue] Signaling - single-stream special case 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, 17 Dec 2012 21:40:44 -0000 On 12/17/12 3:03 PM, Christer Holmberg wrote: > > Hi Paul, > > I think this IS part of the signalling work. I agree it is *part* of the signaling work. I just think it is a low priority part of the work. > We have been discussing that the first SDP offer should establish some "basic" session. What I'm talking about is how that SDP offer would look lite. Based on prior discussion, it is my understanding that there are a variety of opinions on how the first O/A should be structured, and agreement that this could in large part be up to individual implementations to decide. (Though it might be good to discuss implications of various choices and recommend something.) I have the impression that some might want to optimize for contacting another telepresence endpoint, perhaps even for another instance of the same implementation, while allowing others to be supported, perhaps with need for more time to negotiate. Others might want to optimize to cause "least distress" for calling even marginal sip implementations, and postpone all the fancy stuff until after its known that there is a clueful peer. Perhaps even these observations of mine are controversial. I just don't want that to distract from the more fundamental stuff. I'll be happy if, and part of the signaling proposal, you make sufficient assumptions about the initial o/a to bootstrap the rest of the signaling. And then circle back to revisit it once the overall mechanism is specified. > (Then, if both endpoints are CLUE, it will also establish the CLUE channel, and after that the multistream negotiations, CLUE advertisements/configurations etc will start). Yes, this is the key part. > I do agree that the single-stream use-case as such is not our main priority. But, if we don't even know how the first offer will look like, how can we define the additional signalling procedures? We need to know whether we need to add m- lines etc, or whether we can re-use the "basic" session m- lines and only add additional SSRC etc. I just don't want to get hung up on this one, and on compatibility with clueless endpoints, and delay getting to the key stuff. In "steady state" advertisements and configurations have been previously exchanged, consistent O/As have been exchanged, and media is flowing consistent with the configurations. THEN: A provider sends an advertisement that is most likely inconsistent with the previously received configuration. The consumer sends a configuration consistent with the newly received advertisement. If the new configuration would be inconsistent with the currently negotiated SDP, then one side or the other sends an offer and the other side answers it. (The O/A may occur in various positions relative to the advertisement/config exchange.) then media starts to flow based on the new configuration rather than the old one. The signaling spec needs to work out all the details of this. The beginning of the session will be more or less the same as the above, but is a special case in that the same thing is most likely going on in both directions concurrently, and there are some optimizations that may be possible. And in this case there was no *prior* advertisement and config to build on. It may or may not be worthwhile to "optimize" this rather than simply establishing some defaults and then employing the "normal" logic do its thing. (And perhaps optimization can be left to individual implementations without standardizing it.) I've been expecting to see a document addressing all this for a long time. I suspect many of us have a general idea of this but have not written it down in detail. (We probably don't have the *same* idea. But we won't know until it is written down.) Thanks, Paul > Regards, > > Christer > > > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Monday, 17 December 2012 9:50 PM > To: clue@ietf.org > Subject: [clue] Signaling - single-stream special case > > On 12/17/12 2:21 PM, Christer Holmberg wrote: >> >> Hi, >> >> It is true that there is currently no new material. >> >> I'd like to discuss one thing, related to signalling, though. >> >> Some time ago, I indicated that I think it would be good to define a "single-stream SDP offer", ie how an SDP offer sent from a CLUE entity to a single-stream device would look like. The reason why I think it is useful is because it makes it much easier for operators (and other SDOs) to introduce CLUE into their networks, and to verify that non-CLUE entities can interoperate with CLUE entities. >> >> I am currently working on a short draft, which: >> >> - Describes with m- lines (audio, main video, presentation video and "clue channel") the SDP offer would contain. A non-CLUE entity would of course reject the "clue channel" m- line, which would also be an indicator that it is a CLUE entity. >> - Describes the SDP attributes which the SDP offer would contain, in order to provide a good experience. Of course, we cannot guarantee that the non-CLUE entity will support all SDP attributes, and the CLUE entity should be prepared to handle that. But, it will make it easier for operators to put requirements on their non-CLUE entity vendors. > > While this might eventually be interesting, IMO it puts the cart before > the horse. > > We REALLY REALLY REALLY need to nail down our signaling, and we have > hardly any specifics yet. The main cases of interest for that are the > multistream cases. When the general mechanism is worked out for > multistream, there will be a degenerate case of *that* where only one > capture is configured. Ideally that will be just fine for a clue > supporting endpoint that is only capable of managing one capture. The > SDP for that may also turn out to be fine for non-clue-supporting > endpoints. If not, we can then discuss if we want to do something > different for non-clue endpoints. > > But right now I think this is a distraction from getting a good start on > the signaling. And you signed up for the team working on signaling. > > Thanks, > Paul (as co-chair) > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Dec 17 14: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 B157C21F89BB for ; Mon, 17 Dec 2012 14:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jsQaU038Tbg for ; Mon, 17 Dec 2012 14:01:12 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id CF63E21F89E5 for ; Mon, 17 Dec 2012 14:01:09 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta03.westchester.pa.mail.comcast.net with comcast id cdYt1k00D0SCNGk53m18Bt; Mon, 17 Dec 2012 22:01:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id cm181k00i3ZTu2S3Vm18om; Mon, 17 Dec 2012 22:01:08 +0000 Message-ID: <50CF9622.6090306@alum.mit.edu> Date: Mon, 17 Dec 2012 17:01:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it>, <50CF52E9.8000302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0689A1@ESESSMB209.ericsson.se>, <50CF7410.8010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0694D5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0694D5@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355781668; bh=eSWeigOHAeoERt/qaTJnaAU1n96S4HFdNwY7lX7jbJY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FrrOhOdICvCEJI68ced87ajFDzdCOMenUlRsn4cDX29HaBuqNona3z+EawYtVoSUF gS0yHYqP1MX7Cw/SZetOzt1L660rxs2zuY9PKJ50J10W8R+IzMbAl+p0CeZUGIPnb8 aXbHcrRILf/r6HOs1LWjGrzRn0jgzxNC+sYkZQCUEMqvUNadbgDpPmuXN13H7Dq3Fs E7d2Ca5ti8uAatwPYA+q1d7dokuODhntALcy74y9UrYrnHeHI6LGJu0REiOXHjvLRC OLm2ReyfMKIv7u/TtPqmOiIMeGTkP6BR4eBtU1AgWVUaw4dRAUw3lWGncljfkXz2O/ ZDl+WGl8np8nw== Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 17 Dec 2012 22:01:12 -0000 On 12/17/12 3:57 PM, Christer Holmberg wrote: > Hi, > >>>> I have also been thinking about a bigger change: have a single list of >>>> CSEs for the advertisement, rather than one per scene. (CSE is then a >>>> misnomer, but for now I'll still use it.) Each entry would contain a >>>> list of captures that, taken together, is a recommended rendition of the >>>> advertisement as a whole. This would allow tradeoffs between captures in >>>> different scenes to offer choices with fewer captures than scenes. There >>>> is currently no way to do that. I can't think of any downsides to this >>>> change. What do people think of this? >>> >>> I am not sure I understand. >>> >>> What do you mean by "rather than one per scene"? You can advertise multiple CSEs per scene, can't you? >>> >>> I am also not sure I understand what you mean by "rendition of the advertisement". >>> >>> And, I am not sure I understand "tradeoffs between captures in different scenes". I thougth you suggested that captures can only belong to one scene? >> >> OK, obviously I didn't explain myself very well. Let me try again. >> >> First, instead of a list of CSEs per scene, I'm proposing a list of >> (something) per advertisement. Just to have something, for now lets call >> them Advertisement Entries - ADEs. Like a CSE, each ADE is a list of >> captures. In this case they can be any capture in the advertisement, >> regardless of scene. >> >> So overall structure is something like: >> >> >> >> (descriptive info for the scene) >> (descriptive info for the scene) >> ... >> >> >> ... >> ... >> ... >> ... >> ... >> ... >> ... >> >> >> f1,f2,b1,b2 >> f3,b1,b2 >> f1,f2,b3 >> f3,b3 >> b3 >> >> >> >> >> Here, you can think that f3 is a composite of f1 & f2, and b3 is a >> composite of b1 and b2. Perhaps scene foo is a room, and scene bar >> contains a couple of presentations. >> >> This explicitly allows the advertiser to think about and propose >> tradeoffs between scenes. So a5 makes the decision that if you can only >> receive one capture you are better off getting the presentation than the >> room. > > I think it's quite strange if the advertiser starts to advertise "partly scenes", trying to figure out what the receiver may want, and trying to figure out what the capabilities of the receiver are. Isn't that what CSEs already do? Isn't it generally expected that CSEs will differ in the number of captures they include, so that they can accommodate consumers that can handle only a limited number of captures? What I have suggested continues that, and extends it to cover multiple scenes. I guess the controversial part in my example is ADE a5, that omits any content from scene foo. It has made a value judgement that omitting all of foo is still a valid representation of the advertisement. (It might be clearer if we had both audio and video, and it retained audio from foo but not video.) And it might be that in some cases this wouldn't be included in the advertisement because it wouldn't be sufficient. > My preference is still that we don't need to advertise scene trade-offs. Instead the advertiser provides full scene alternatives (CSEs), and let the receiver choose which scene(s) (and associated CSEs), it wants to receive. I've been talking about this for months. I agree that ultimately it is the recipient that makes the final decision. But can be very hard - the receiver has limited info to make the decision. This can be partly solved by extensions to capture attributes, such as Christian has proposed. Including a priority attribute, where priorities have significance across scenes, provide another way to accomplish the same thing. Aside from being *different* from what we have assumed for a long time, do you see something that makes my proposal worse than having separate CSEs for each scene? (Answering my own question: if there are many alternatives for each scene, then my proposal would increase the total number of entries - the product of the entries in each. But I doubt this is an issue in practice.) Thanks, Paul From pkyzivat@alum.mit.edu Mon Dec 17 14:13: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 4155B21F8970 for ; Mon, 17 Dec 2012 14:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqllScMShXif for ; Mon, 17 Dec 2012 14:13:32 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 79C7D21F87F2 for ; Mon, 17 Dec 2012 14:13:32 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id cbrb1k00727AodY53mDYRm; Mon, 17 Dec 2012 22:13:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id cmDX1k00z3ZTu2S3fmDXrd; Mon, 17 Dec 2012 22:13:32 +0000 Message-ID: <50CF990B.2030606@alum.mit.edu> Date: Mon, 17 Dec 2012 17:13:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355782412; bh=jIkqdbg2O8VKK/d7Jk/4eCXGCqVSLshIzzFMCmNQP5w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XmZ+xYOF2wWNcvN2msvjWrf26Zk3vKV14SJtPtcRT58lAg7QJGUIqDzPDCbgkGblw iBy5NW4X0efyPlOyZlWAxduRLBSrP1JGNw8NdjyCBPPs+cUY3uHVcevy+so38NX9t3 87X7aMLrgNChJHRxudRQ8dBap0fnKY9NZnAJoI17qFKLnCwM0ZEFH/DnwSnrf71JP/ b+ggijcwaK3YkmrFgppD8yvZjxPHt3PcV1tCU78mL9PoFD76eoaFC8FnjoHVCKVtN8 wob5PbbHdvJMyCKziDqLd7XblZZO7cJkJQc6Dd5/cOyHqLIpnXz7hVnR9PC5Pjn35s nosIBsQa4iDjA== Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 17 Dec 2012 22:13:33 -0000 On 12/17/12 3:44 AM, Christer Holmberg wrote: > Hi, > > First, there are a few things that need to be separated: > > 1) Whether a capture can be part of one or more CSEs. > > 2) Advertising/configuring > > 3) Simultaneous sets > > > Regarding 1): > > I don't think that question is specific to the issues discussed in this thread, so I'll leave it for now (it needs to be clarified, though). OK. > Regarding 2): > > Paul is suggesting: we list captures, and for each capture we indicate which CSE(s) the capture is associated with. > I am suggesting: we list CSEs, and for each CSE we indicate which captures are associated with the CSE. No. I was suggesting we list the captures, and for each capture we indicate with which *Scene* it is associated. I agree that each CSE indicate which captures it contains. > Si, it's really about how things are structured :) > > If a provider advertises captures, it means that the receiver needs to scan through them, to figure out what CSEs the provider is offering. > > That is not needed if the provider advertises CSEs from the beginning. Of course, the receiver still needs to scan through the advertised CSEs, and see what they contain, but the receiver doesn't need to build the CSE structure. In any case lets not get hung up on syntax. (This is one reason I like UML - it divorces the semantics from the syntax.) The receiver needs to parse the advertisement. It will end up with some data structures that may not closely resemble the xml. Regardless of how it is encoded, each CSE will reference a bunch of captures that belong to the same scene. This can be represented many different ways. Thanks, Paul From Christian.Groves@nteczone.com Mon Dec 17 21:05: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 7839B21F8785 for ; Mon, 17 Dec 2012 21:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcEHGJxs2QZr for ; Mon, 17 Dec 2012 21:05:09 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 1172F21F8711 for ; Mon, 17 Dec 2012 21:05:08 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAOP4z1B20U9k/2dsb2JhbAANLgoOgzq5WwQDgR2DEQEBAQMBAQEBNRsbCgEFCwsOCgkMCg8JAwIBAgEVMAYNAQUCAQEXh3ISpnODMJAyBIxRCwZ9gzUDqQdSgVk Received: from ppp118-209-79-100.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.79.100]) by ipmail05.adl6.internode.on.net with ESMTP; 18 Dec 2012 15:35:06 +1030 Message-ID: <50CFF980.5090103@nteczone.com> Date: Tue, 18 Dec 2012 16:05:04 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Paul Kyzivat References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> In-Reply-To: <50CA4537.80907@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 18 Dec 2012 05:05:10 -0000 Hello Paul, Please see my comments below. Regards, Christian On 14/12/2012 8:14 AM, Paul Kyzivat wrote: > The "Capture scene clarifications" topic has been *very* popular, and > is getting confusing. > > Here I've changed the subject line to focus on one point - a change > that was been proposed by Christer. The latest description of it was > from Christian Groves: > >>> "A consumer may receive an advertisement with multiple capture >>> scenes. >>> A consumer may choose to receive any number of capture scenes. An >>> advertised capture scene it may contain one of more capture scene >>> entries >>> that may contain one of more media captures. A consumer may choose an >>> capture scene entry in the knowledge that it is a complete >>> representation of >>> the scene for a particular media type and that all media captures >>> are spatially >>> related. For a particular media type the consumer shall choose one >>> capture >>> scene entry rather than choosing individual captures from multiple >>> capture >>> scene entries. However this does not mean that a consuming endpoint >>> must >>> render all the media captures. What is locally rendered and how is a >>> local >>> decision." [CNG] I take it that people are OK with the first part of the proposal. The only thing in question is "...shall choose one capture scene entry". > > There have been some suggestions that this could also eliminate the > need for simultaneous sets, because the scene entries would *be* the > simultaneous sets. I'm not sure if that is an integral part of this > proposal or not. (If it is, then it provides part of the > justification. Without this part I'm not sure what the benefit is.) [CNG] In a later email I proposed a hybrid solution. That we recommend that a consumer choose one CSE entry but that it may choose a subset if a simultaneous set is included to indicate any dependencies. So instead the sentence in question we replace it with "For a particular media type the consumer should choose one capture scene entry. If the advertiser has provided a simultaneous transmission set, the consumer may choose individual captures taking in account any simultaneity requirements". > > I am inclined to agree that a new definition of advertisement and > configuration could be built around such a concept. [CNG] I don't particularly see this as "new" what I've been trying to do is clarify how what is currently in the draft is going to work. > But to do so I think somebody will need to work out all the details. > For instance: > - can the same capture be in more than one capture scene entry? [CNG] The current framework is unclear on this. The examples show that captures are only in one capture scene entry at a time. So we need to clarify this either way. > - how does the configure message specify which entries it wants, > and which captures from those entries? [CNG] Again the framework is silent on what happens today. Like the scene issue I think people have been making assumptions but these haven't been recorded. > > IMO the existing (prior?) model was at least clearer, and arguably > simpler. [CNG] Perhaps but it was not fully documented. > The way I have been thinking of it: > > - an advertisement advertises a bunch of captures, and information > about those captures to help the receiver decide which ones it > wants and how it should render them. > > - scenes, scene entries, simultaneous sets, are all just pieces of > that descriptive info. [CNG] I agree. The main thing is that the same logic that was used constructing the Advertisement is the same logic that is used "reading" the Advertisement. > > - a configuration is simple - it only needs to enumerate the > captures that it wants. It need not mention scenes or scene > entries. (It might need to identify scenes if the capture ids > are scoped to a scene.) [CNG] Generally yes. However there are attributes associated with a scene. There may be choices where an attribute is sent with a list where a choice could be made. These go beyond just returning an id. > > > The proposed changes would make the configuration message more > complex. The receiver would need to enumerate the desired scene > entries. And for each selected scene entry, identify those captures > that are (or are not) desired. [CNG] It will really depend on the structure of the message. > > So, IMO, if some people are interested in this new approach, I suggest > they work on a detailed proposal for how it would work, and then do a > full assessment of the pros/cons relative to the existing proposal. [CNG] I'd like to nail down how the current framework is meant to work. Then we can evaluate any new approach. I think we came up with several good clarifications in Marks email on the 02/12. In addition I think we agreed to add text indicating that no priority between elements is intended in the current framework. Here's some additional items that need clarifying in the current framework: 1. Simultaneous sets: Are these mandatory for the Advertiser to send? If not what is the default? What is the action of the consumer? 2. Can a capture occur in multiple capture scene entries? 3. Configure message needs to be specified. Regards, Christian > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Dec 17 21:22:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ADC1F0CB2 for ; Mon, 17 Dec 2012 21:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eEhcScUX6Z1 for ; Mon, 17 Dec 2012 21:22:29 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id E8D1621F84FB for ; Mon, 17 Dec 2012 21:22:26 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id co2D1k00B16LCl053tNSkh; Tue, 18 Dec 2012 05:22:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id ctNR1k00k3ZTu2S3StNSGc; Tue, 18 Dec 2012 05:22:26 +0000 Message-ID: <50CFFD91.2000904@alum.mit.edu> Date: Tue, 18 Dec 2012 00:22:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christian Groves References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <50CFF980.5090103@nteczone.com> In-Reply-To: <50CFF980.5090103@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355808146; bh=BgDOHRbGH1V82MUDCx8IZ5DPxbKYLdbR69Em49LNHAM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ElCu+G/llljodn8APrDszuuVqrAzt2d+7dRkhPChD8bvW+JwnARWa62O6g5kI8d4m ihIL9BUCvADD2Q0p71/OIClluWfD2dovNbXhwcH3ixUnBOBWolDRn7tLMUGR1CUBgJ hSUDiV9S9wFxwXcbbv2cdmmQIA0isDMYxfKG5PTQQpblaM0GbX2lL7L0yuutJS38Nx reiUWRvp0WQD0F4Tmy7DuV9EO7o2iaRRquy9nFivtRZKZCkU2w/CNIP08WiT7k0SjG psgfQRwPK8xT75NIR1jGC+K5iZrxHArOxmfQAp4yIM7o0VAGGpOZ4oTtEJz2GUSAKq qNXH5jVtJxvrQ== Cc: clue@ietf.org Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 18 Dec 2012 05:22:29 -0000 Christian, Fair enough - the "existing" model isn't fully defined either. So we need to come up with more specifics on it. And then maybe comparable specification of candidate alternatives. If somebody doesn't beat me to it, tomorrow I'll try to post something with my understanding of what is intended. (It's too late for me to do now and make any sense.) Thanks, Paul On 12/18/12 12:05 AM, Christian Groves wrote: > Hello Paul, > > Please see my comments below. > > Regards, Christian > > On 14/12/2012 8:14 AM, Paul Kyzivat wrote: >> The "Capture scene clarifications" topic has been *very* popular, and >> is getting confusing. >> >> Here I've changed the subject line to focus on one point - a change >> that was been proposed by Christer. The latest description of it was >> from Christian Groves: >> >>>> "A consumer may receive an advertisement with multiple capture >>>> scenes. >>>> A consumer may choose to receive any number of capture scenes. An >>>> advertised capture scene it may contain one of more capture scene >>>> entries >>>> that may contain one of more media captures. A consumer may choose an >>>> capture scene entry in the knowledge that it is a complete >>>> representation of >>>> the scene for a particular media type and that all media captures >>>> are spatially >>>> related. For a particular media type the consumer shall choose one >>>> capture >>>> scene entry rather than choosing individual captures from multiple >>>> capture >>>> scene entries. However this does not mean that a consuming endpoint >>>> must >>>> render all the media captures. What is locally rendered and how is a >>>> local >>>> decision." > [CNG] I take it that people are OK with the first part of the proposal. > The only thing in question is "...shall choose one capture scene entry". >> >> There have been some suggestions that this could also eliminate the >> need for simultaneous sets, because the scene entries would *be* the >> simultaneous sets. I'm not sure if that is an integral part of this >> proposal or not. (If it is, then it provides part of the >> justification. Without this part I'm not sure what the benefit is.) > [CNG] In a later email I proposed a hybrid solution. That we recommend > that a consumer choose one CSE entry but that it may choose a subset if > a simultaneous set is included to indicate any dependencies. So instead > the sentence in question we replace it with > > "For a particular media type the consumer should choose one capture > scene entry. If the advertiser has provided a simultaneous transmission > set, the consumer may choose individual captures taking in account any > simultaneity requirements". > > >> >> I am inclined to agree that a new definition of advertisement and >> configuration could be built around such a concept. > [CNG] I don't particularly see this as "new" what I've been trying to do > is clarify how what is currently in the draft is going to work. > >> But to do so I think somebody will need to work out all the details. >> For instance: >> - can the same capture be in more than one capture scene entry? > [CNG] The current framework is unclear on this. The examples show that > captures are only in one capture scene entry at a time. So we need to > clarify this either way. > >> - how does the configure message specify which entries it wants, >> and which captures from those entries? > [CNG] Again the framework is silent on what happens today. Like the > scene issue I think people have been making assumptions but these > haven't been recorded. > >> >> IMO the existing (prior?) model was at least clearer, and arguably >> simpler. > [CNG] Perhaps but it was not fully documented. > >> The way I have been thinking of it: >> >> - an advertisement advertises a bunch of captures, and information >> about those captures to help the receiver decide which ones it >> wants and how it should render them. >> >> - scenes, scene entries, simultaneous sets, are all just pieces of >> that descriptive info. > [CNG] I agree. The main thing is that the same logic that was used > constructing the Advertisement is the same logic that is used "reading" > the Advertisement. >> >> - a configuration is simple - it only needs to enumerate the >> captures that it wants. It need not mention scenes or scene >> entries. (It might need to identify scenes if the capture ids >> are scoped to a scene.) > [CNG] Generally yes. However there are attributes associated with a > scene. There may be choices where an attribute is sent with a list where > a choice could be made. These go beyond just returning an id. >> >> >> The proposed changes would make the configuration message more >> complex. The receiver would need to enumerate the desired scene >> entries. And for each selected scene entry, identify those captures >> that are (or are not) desired. > [CNG] It will really depend on the structure of the message. >> >> So, IMO, if some people are interested in this new approach, I suggest >> they work on a detailed proposal for how it would work, and then do a >> full assessment of the pros/cons relative to the existing proposal. > [CNG] I'd like to nail down how the current framework is meant to work. > Then we can evaluate any new approach. I think we came up with several > good clarifications in Marks email on the 02/12. > > In addition I think we agreed to add text indicating that no priority > between elements is intended in the current framework. > > Here's some additional items that need clarifying in the current framework: > 1. Simultaneous sets: Are these mandatory for the Advertiser to send? If > not what is the default? What is the action of the consumer? > 2. Can a capture occur in multiple capture scene entries? > 3. Configure message needs to be specified. > > Regards, Christian > > > >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > From mary.ietf.barnes@gmail.com Tue Dec 18 10:57:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520A921F8A80 for ; Tue, 18 Dec 2012 10:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyY8BkGEsf8Z for ; Tue, 18 Dec 2012 10:57:02 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4B21D21F8991 for ; Tue, 18 Dec 2012 10:57:02 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id gm13so1017749lbb.38 for ; Tue, 18 Dec 2012 10:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HH8ymAIuCOHXRnbQG6XBL5Ik5fD2nBC3MJVy0TOXlyE=; b=oNBUWODi2qgzrbi3jCzoptRFTKVZNE2Alzb7VqVjZwrz55HaRI/osLLqMUiAnLxLKk yzAG9tE6bf0rJqdRJm6vvqfhex4tjwS3GlCNvurRkv8OWyw4K0VBAyThPwuCjsroy9z6 TOEsKPG5/jAZ9pKsQaG5hpsUGQPB25VTD4CekF1yHhSCz6NAnejs4qUTaQ2LBD/MNW7d C/jNQQFxNaF83xNia/y918jc4+NnHl9Gv+28PE3vwKcTFGpP9GRIZpWJRds3hbFKXrIs t6lq6x3bRfrA60jSHJK6Kr0ebdspLnGmxCXaWoJaqQK7iVKVGk3RiBIes/dKu8m1wu6e Lu1Q== MIME-Version: 1.0 Received: by 10.152.131.137 with SMTP id om9mr2797255lab.18.1355857020782; Tue, 18 Dec 2012 10:57:00 -0800 (PST) Received: by 10.114.20.41 with HTTP; Tue, 18 Dec 2012 10:57:00 -0800 (PST) Date: Tue, 18 Dec 2012 12:57:00 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Plans for 2013 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, 18 Dec 2012 18:57:04 -0000 Hi all, Paul and I have been discussing how best to make progress in the WG. As discussed at IETF-85 (and per the action items), we would like groups of people to work together on the specific WG deliverables: http://www.ietf.org/proceedings/85/minutes/minutes-85-clue We understand there are inter-dependencies, however, the objective of this work is to get the structure in place for WG deliverables/documents and clearly identify issues requiring resolution for the solution. We believe that some of the work can happen in parallel. Since we have the regular Design Team slots in place, our proposal would be that each of the calls focus on a specific area/deliverable. The idea would be that the document team would be on the call to work through issues. The teams are open, but the expectation is that anyone on the call is willing to take action items to propose text. We would also to schedule more formal Virtual Interim meetings (which require a two week notice on the IETF announcement list). The objective of these meetings would be for a broader group to review the document(s) before the meeting and then discuss issues at the meeting. Considering that the Monday design team slot seemed optimal overall, we have setup a doodle working around that time (for a two hour meeting) for Jan 21st - I'll post a separate note with that link. Depending upon how that goes we would schedule another for Feb. 11th. It's really important to note that the -00 draft deadline for IETF-86 is February 18th, with the final draft deadline being February 25th. Comments on this proposal are welcome - either on the list or please contact the chairs directly. Regards, Mary and Paul CLUE WG co-chairs. From mary.ietf.barnes@gmail.com Tue Dec 18 11:13: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 CEEB021F85A2 for ; Tue, 18 Dec 2012 11:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.557 X-Spam-Level: X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn6i0yIesLsq for ; Tue, 18 Dec 2012 11:13:36 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 92AB321F859D for ; Tue, 18 Dec 2012 11:13:35 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id gf7so1018582lbb.2 for ; Tue, 18 Dec 2012 11:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=AeeG2Hd5ejyE8vgmJhbRWWrlVIOgZ5keViWCr1Kz/GE=; b=k38PSRwLqMf1ez854LTnMIJ4hPjR6ONS0tYfxlqDPWoX5D2F50XRWWJMX1StXJqJ/H H4rMrtGKmQsPeOGt+G8edmHi0qPcToJPQ/c9ge6tkts4ipUxxq1Uz3hAGv4eYk3V3Q2a FoWGA53EWqKOyaBQDcgMQsYp5yOIgvbNO2n//hG86J1qBUm0+1IxMtte3MEPeOL+KB4j xHjyb0r0bGnbygaXAK8wrXWsvuwwK0IKzR/fIm1HMLi9iNnIj5/5y2bbUrYtsPNm8hNa PnpkJMjs2Ht1Ute+NDgqxVv6ePSa4QZCsvCw/HPjr+e8wwwcGFiSJuqrCmDjoNam/2XL DU0Q== MIME-Version: 1.0 Received: by 10.112.37.40 with SMTP id v8mr1281593lbj.112.1355858014383; Tue, 18 Dec 2012 11:13:34 -0800 (PST) Received: by 10.114.20.41 with HTTP; Tue, 18 Dec 2012 11:13:34 -0800 (PST) Date: Tue, 18 Dec 2012 13:13:34 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Doodle Poll: CLUE WG Interim Meeting - Jan 21, 2013 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, 18 Dec 2012 19:13:37 -0000 Hi all, Per the Plans for 2013 email: please respond to this Doodle poll, so we can find the optimal time for a 2 hour virtual interim meeting on Jan. 21st: http://www.doodle.com/rbee8q2ry5prtbba The focus of this virtual interim would be the Framework document (and data model as time allows). We would like to get resolution on the open issues. The expectation is that there would be an updated Framework document, including updated content based on discussion at Dec. 3rd design team meeting as well as the proposed refactoring, no later than Jan 14th to allow the group time to review before the meeting. Thanks, Mary. From mary.ietf.barnes@gmail.com Tue Dec 18 12:12: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 E3B8E21F88E8 for ; Tue, 18 Dec 2012 12:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAxNw7bO-mvE for ; Tue, 18 Dec 2012 12:12:38 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id 93C8D21F88E7 for ; Tue, 18 Dec 2012 12:12:37 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id c1so924572lah.23 for ; Tue, 18 Dec 2012 12:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=F7CQYm37lwdZlCR01uD+HTO2Q1+9VbUKmnoiEWCnDC8=; b=ztusw+MgX/heuAn5weBAEpgiuswJjenC74LdYbn8eX9Phm194YB2/dgl1gwM0Kpo05 cT8yQh9XdTb9BQUNq6gjglLjDszs61jt+scRTppXBc8tkSbpe94/bjqaKi4SLCoOGiyA a2SjmXUouw9299o6bhlAu/mZo8KkraFId8DoNXj0z71qy/H9Xt0iHhSp4mkboriir4Dq JdaUh0VRXKTKNUyc8NfsCUtPT7KdkKJr4SGIMDm2R0j02nwaMj7BGIT/lbuxL89mKwPc L0NjI9XA7HY4+1y/jqy/WJknHYDX40wtktYjPGyoaHgwn2caobCVBYFKivDlWdxEKOhD PJwg== MIME-Version: 1.0 Received: by 10.112.38.103 with SMTP id f7mr1270865lbk.120.1355861556084; Tue, 18 Dec 2012 12:12:36 -0800 (PST) Received: by 10.114.20.41 with HTTP; Tue, 18 Dec 2012 12:12:36 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Dec 2012 14:12:36 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [clue] Plans for 2013 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, 18 Dec 2012 20:12:39 -0000 One further comment is that if folks have in mind dates by which they plan to have something ready, that would be great for the chairs to know. We would like to be able to cover each of the work areas before IETF-86, so that we can make the best use of that face-to-face time. Thanks, Mary. On Tue, Dec 18, 2012 at 12:57 PM, Mary Barnes wrote: > Hi all, > > Paul and I have been discussing how best to make progress in the WG. > As discussed at IETF-85 (and per the action items), we would like > groups of people to work together on the specific WG deliverables: > http://www.ietf.org/proceedings/85/minutes/minutes-85-clue > We understand there are inter-dependencies, however, the objective of > this work is to get the structure in place for WG > deliverables/documents and clearly identify issues requiring > resolution for the solution. We believe that some of the work can > happen in parallel. > > Since we have the regular Design Team slots in place, our proposal > would be that each of the calls focus on a specific area/deliverable. > The idea would be that the document team would be on the call to work > through issues. The teams are open, but the expectation is that > anyone on the call is willing to take action items to propose text. > > We would also to schedule more formal Virtual Interim meetings (which > require a two week notice on the IETF announcement list). The > objective of these meetings would be for a broader group to review the > document(s) before the meeting and then discuss issues at the meeting. > Considering that the Monday design team slot seemed optimal overall, > we have setup a doodle working around that time (for a two hour > meeting) for Jan 21st - I'll post a separate note with that link. > > Depending upon how that goes we would schedule another for Feb. 11th. > It's really important to note that the -00 draft deadline for IETF-86 > is February 18th, with the final draft deadline being February 25th. > > Comments on this proposal are welcome - either on the list or please > contact the chairs directly. > > Regards, > Mary and Paul > CLUE WG co-chairs. From mary.ietf.barnes@gmail.com Tue Dec 18 12:15:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541FD21F86F5 for ; Tue, 18 Dec 2012 12:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxp9KUp1iVN7 for ; Tue, 18 Dec 2012 12:15:23 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 691E021F85D1 for ; Tue, 18 Dec 2012 12:15:23 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id gm13so1092832lbb.10 for ; Tue, 18 Dec 2012 12:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vI1zdXFVQAU9V55RNN437UOCeIfwG9wPDGIzRFcAJZ4=; b=D/pe7Nebjj+XCwMVd/aUkrhqsJ0NiVM76t8QClxpuV2sCeDdkx/ajDMifCDOm/UJTw aSqw3GqgxZROO8RrvoTh8xMn1XjB2/BDi7NmYP04RrlGSZygEPOWrjq1G+mWXpMI7kfA QujLfnUS/5hhQPQw4541t89SnN7ELcUUC5t0vkg6Mjj8dA4Zd4Vby7VbJNfLB1Gq7GhQ YjiRDtJZwR4VTYe+XnoP3zWZj/2wfZFBRQCZp0FVEx6gHjMmGObgUf3x0sfmjVu05swH zKDpeFxeBDnLmi1vfa3V1eMGviXPI6y5bNG8X4lFPgJEhxf0aFFIndeeOrwBha10E0mN yOEA== MIME-Version: 1.0 Received: by 10.152.105.103 with SMTP id gl7mr3018758lab.10.1355861721901; Tue, 18 Dec 2012 12:15:21 -0800 (PST) Received: by 10.114.20.41 with HTTP; Tue, 18 Dec 2012 12:15:21 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B068A4C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B068A4C@ESESSMB209.ericsson.se> Date: Tue, 18 Dec 2012 14:15:21 -0600 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Cancelled: CLUE Design Team meeting - Dec. 17th 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, 18 Dec 2012 20:15:24 -0000 Thanks for your email. This work certainly has merit in that it is something we need to make sure and cover for the complete solution. It might well also help to inform the decision as to how much we can put in SDP. If you can let us know about when you'll have the draft submitted, so we can ensure we have discussion time allocated for it in one of the design team meetings, that would be great. Thanks, Mary. On Mon, Dec 17, 2012 at 1:21 PM, Christer Holmberg wrote: > > Hi, > > It is true that there is currently no new material. > > I'd like to discuss one thing, related to signalling, though. > > Some time ago, I indicated that I think it would be good to define a "sin= gle-stream SDP offer", ie how an SDP offer sent from a CLUE entity to a sin= gle-stream device would look like. The reason why I think it is useful is b= ecause it makes it much easier for operators (and other SDOs) to introduce = CLUE into their networks, and to verify that non-CLUE entities can interope= rate with CLUE entities. > > I am currently working on a short draft, which: > > - Describes with m- lines (audio, main video, presentation video and "clu= e channel") the SDP offer would contain. A non-CLUE entity would of course = reject the "clue channel" m- line, which would also be an indicator that it= is a CLUE entity. > - Describes the SDP attributes which the SDP offer would contain, in orde= r to provide a good experience. Of course, we cannot guarantee that the non= -CLUE entity will support all SDP attributes, and the CLUE entity should be= prepared to handle that. But, it will make it easier for operators to put = requirements on their non-CLUE entity vendors. > > > Regards, > > Christer > > > > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Bar= nes [mary.ietf.barnes@gmail.com] > Sent: Monday, 17 December 2012 5:52 PM > To: CLUE > Subject: [clue] Cancelled: CLUE Design Team meeting - Dec. 17th > > Hi all, > > The plan had been to discuss further details on the signaling > solution. However, there is no new material related to this at this > time. > > We'll start back with meetings on January 7th (pending of course > content for the meetings). > > Regards, > Mary > CLUE WG co-chair. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Dec 18 13:11: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 8F7AA1F0CE3 for ; Tue, 18 Dec 2012 13:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKe1XqsqT1wd for ; Tue, 18 Dec 2012 13:11:58 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id D1C351F0CE1 for ; Tue, 18 Dec 2012 13:11:56 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta09.westchester.pa.mail.comcast.net with comcast id czej1k0011swQuc599Bvqa; Tue, 18 Dec 2012 21:11:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id d9Bv1k00j3ZTu2S3b9BvHy; Tue, 18 Dec 2012 21:11:55 +0000 Message-ID: <50D0DC1B.7060100@alum.mit.edu> Date: Tue, 18 Dec 2012 16:11:55 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355865115; bh=YqCB8pC+QJxaaIv0FVm9RRQvoe2+0rb5Abu+dwrQMms=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cQ/HNlb2PpSVIVX4KExtddCjChF/BE+bE2xFDFqlmrzqGNynHeAWc/9RW7kR8E8Se La3YkZ4kGHw7hwQigpwsB1hEQT50P+AXXoAbVhs01BNRrnP/IlPFpmSM3cd09r73Gl DexJaOeYsY1AklhrG7y9trdqyhiDKM2Ajbi4voLyDG1Eb/pZe+jy92298fXYqdIunG xj/U1dy4aPQ3ZNX0q/1bojexCdaaDyFIRTR/ZW5VRb133birWF4yPV1VdyIUB8+IWP Tow3CagZD7DfsV31PUGI7hB6M4iOqzQdOZNarH6VFdHHEO7aJeIexRMLItIyZaX3vD aEyFTOIupWzhw== Subject: [clue] Some thoughts about CLUE signaling 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, 18 Dec 2012 21:11:58 -0000 In hopes of kickstarting more work on clue signaling, here are some thoughts I have on the subject. I request comments about this, especially from those of you signed up to work on signaling: - Rob Hansen - Roni Even - Simon Pietro-Romano - Roberta Presta - Christer Holmberg First, we need to agree on what is included in the subject "clue signaling". I consider all of the following are aspects/dimensions to the subject: 1) the clue-specific signaling protocol a) the messages: advertisement, configure, ack?, nak? b) the payload of advertisement & configure (from data model) c) sequencing of clue messages, state machines 2) clue use of SDP O/A, including establishment of clue message channel 3) linkage & sequencing of clue-specific messages and SDP O/A 4) sip signaling (this may be unremarkable) 5) interop with legacy SIP devices 6) clue over RTCWEB I expect that the clue signaling document will cover all of these subjects. (Perhaps with the exception of RTCWEB.) I have no strong preference at this time about the document structure to cover these. I have thought some about the sequencing of clue messages. The following are some thoughts on that. These may be entirely obvious to everyone. (If so, hurray!) But I'll have a better idea after everyone concurs, or not. - media for a capture encoding will not be sent unless it has been configured. (Exception: prior to first adv/cfg exchange, which includes compatibility with non-clue endpoints.) - a capture must be advertised before it can be configured. (This is fundamental, the config must reference identifiers from the advertisement for the capture & encoding.) - when a provider wishes to stop sending a capture encoding that has been configured, it *should* *first* send a new advertisement that no longer advertises that capture and/or encoding, and should wait for that advertisement to be acknowledged. - if a provider must stop sending a capture encoding before advertising that it is not available, it *must* still send an advertisement indicating this at the first opportunity. (Until it gets this, the consumer is likely to treat the missing capture encoding as an error, giving a poor user experience.) - when a consumer receives a new advertisement that no longer offers a capture and/or encoding that is currently configured, that is an indication that the capture is no longer available and will most likely no longer be sent. The consumer should not consider it an error when that capture encoding is no longer received. - when a consumer receives a new advertisement, it *should* send a new configuration asap that is consistent with the new advertisement. This means it references the new advertisement and it configures only captures and encodings mentioned in that advertisement. Thanks, Paul From christer.holmberg@ericsson.com Wed Dec 19 03:43: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 523B221F84C1 for ; Wed, 19 Dec 2012 03:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Knr3vpBMI5Bh for ; Wed, 19 Dec 2012 03:43:36 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0D92121F8203 for ; Wed, 19 Dec 2012 03:43:31 -0800 (PST) X-AuditID: c1b4fb25-b7fb26d000006129-f2-50d1a85d146c Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 10.2F.24873.D58A1D05; Wed, 19 Dec 2012 12:43:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 12:43:25 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [clue] Can receiver select captures from more than one capture scene entry? Thread-Index: AQHN3Hn0g7YsKnVso0yin5dQG9gVdZgdUFyKgAABVQCAACDqKoAAB7MAgAJCSMA= Date: Wed, 19 Dec 2012 11:43:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B06C6BC@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it>, <50CF52E9.8000302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0689A1@ESESSMB209.ericsson.se>, <50CF7410.8010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0694D5@ESESSMB209.ericsson.se> <50CF9622.6090306@alum.mit.edu> In-Reply-To: <50CF9622.6090306@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+JvjW7siosBBju7zCz2n7rMbLFiwwFW i21tN5gdmD3+vv/A5LFkyU8mjx9bnjIFMEdx2aSk5mSWpRbp2yVwZbz7OZut4JluRd+mBqYG xmkqXYycHBICJhJLO3ewQthiEhfurWfrYuTiEBI4xCix/eViRghnMaNEZ+smoAwHB5uAhUT3 P20QU0RAQ2LSVjWQXmYBH4nHr2cxgtjCAlEShzb+BZspIhAt8XLldaYuRnYg20+iSxUkyiKg KnHpVgsLyBBeAW+JP5/dIPa8ZZaYs20lG0gNp4COxN7dv9hBbEagy76fWsMEsUlc4taT+UwQ FwtILNlznhnCFpV4+fgfK8hMCQFFieX9chDlOhILdn9ig7C1JZYtfA1WzisgKHFy5hOWCYxi s5BMnYWkZRaSlllIWhYwsqxiZM9NzMxJLzfaxAiMl4NbfqvuYLxzTuQQozQHi5I4b7jrhQAh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjCXZva051ZKdEuKTay6WLzY4J/74/LR1D/cVR/I8 i/bfOKfzhdwpN/ZzLZOzDgW/PKL06/a1J/Uh57caZdVOWvBol6GDvQfztwbzANlDMYqBgUmi KndV7LqteGQ77Fts+YT7Xd79lGy2Fruj8jdWg0W9YuqRyrXvJ9YGeIk8mnQzMyr9bEeQEktx RqKhFnNRcSIAQYz3imUCAAA= Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 19 Dec 2012 11:43:37 -0000 Hi, >>>>> I have also been thinking about a bigger change: have a single list=20 >>>>> of CSEs for the advertisement, rather than one per scene. (CSE is=20 >>>>> then a misnomer, but for now I'll still use it.) Each entry would=20 >>>>> contain a list of captures that, taken together, is a recommended=20 >>>>> rendition of the advertisement as a whole. This would allow=20 >>>>> tradeoffs between captures in different scenes to offer choices=20 >>>>> with fewer captures than scenes. There is currently no way to do=20 >>>>> that. I can't think of any downsides to this change. What do people t= hink of this? >>>> >>>> I am not sure I understand. >>>> >>>> What do you mean by "rather than one per scene"? You can advertise mul= tiple CSEs per scene, can't you? >>>> >>>> I am also not sure I understand what you mean by "rendition of the adv= ertisement". >>>> >>>> And, I am not sure I understand "tradeoffs between captures in differe= nt scenes". I thougth you suggested that captures can only belong to one sc= ene? >>> >>> OK, obviously I didn't explain myself very well. Let me try again. >>> >>> First, instead of a list of CSEs per scene, I'm proposing a list of >>> (something) per advertisement. Just to have something, for now lets=20 >>> call them Advertisement Entries - ADEs. Like a CSE, each ADE is a=20 >>> list of captures. In this case they can be any capture in the=20 >>> advertisement, regardless of scene. >>> >>> So overall structure is something like: >>> >>> >>> >>> (descriptive info for the scene) >>> (descriptive info for the scene) >>> ... >>> >>> >>> ... >>> ... >>> ... >>> ... >>> ... >>> ... >>> ... >>> >>> >>> f1,f2,b1,b2 >>> f3,b1,b2 >>> f1,f2,b3 >>> f3,b3 >>> b3 >>> >>> >>> >>> >>> Here, you can think that f3 is a composite of f1 & f2, and b3 is a=20 >>> composite of b1 and b2. Perhaps scene foo is a room, and scene bar=20 >>> contains a couple of presentations. >>> >>> This explicitly allows the advertiser to think about and propose=20 >>> tradeoffs between scenes. So a5 makes the decision that if you can=20 >>> only receive one capture you are better off getting the presentation=20 >>> than the room. >> >> I think it's quite strange if the advertiser starts to advertise "partly= scenes", trying to figure out what the receiver may want, and trying to fi= gure out what the capabilities of the receiver are. > > Isn't that what CSEs already do? > > Isn't it generally expected that CSEs will differ in the number of captur= es they include, so that they can accommodate consumers that can handle onl= y a limited number of captures? Yes, the number of captures will differ. But, each CSE still represents a c= omplete scene. Or, are you saying that f1 + f2 could be seen as one CSE for foo, and f3 as= another CSE for foo (and, the same for b1 + b2 and b3)? > What I have suggested continues that, and extends it to cover multiple sc= enes. My preference would still be to keep scenes separated from each other. The = receiver will then, for each scene it wants, choose the scene alternative (= CSE) based on its capabilities etc. > I guess the controversial part in my example is ADE a5, that omits any co= ntent from scene foo. It has made a value judgement that omitting=20 > all of foo is still a valid representation of the advertisement. (It migh= t be clearer if we had both audio and video, and it retained audio from=20 > foo but not video.) And it might be that in some cases this wouldn't be i= ncluded in the advertisement because it wouldn't be sufficient. > > > My preference is still that we don't need to advertise scene trade-offs= . Instead the advertiser provides full scene alternatives (CSEs), and=20 >> let the receiver choose which scene(s) (and associated CSEs), it wants t= o receive. > > I've been talking about this for months. I agree that ultimately it is th= e recipient that makes the final decision. But can be very hard - the recei= ver=20 > has limited info to make the decision. This can be partly solved by exten= sions to capture attributes, such as Christian has proposed. Including a=20 > priority attribute, where priorities have significance across scenes, pro= vide another way to accomplish the same thing. Yes. No matter which way we go, I think the attribute is needed. > Aside from being *different* from what we have assumed for a long time, d= o you see something that makes my proposal worse than having separate CSEs = for each scene? One issue is that same as I have had previously: by listing captures, and t= hen having the receiver figure out where they belong (no matter whether we = group according to scene, CSE, ADE or whatever). But, again, that is mainly= a coding issue. Another issue is, as indicated above, I see no need for mixing together sce= nes. > (Answering my own question: if there are many alternatives for each scene= , then my proposal would increase the total number of entries - the product= of the entries in each. But I doubt this is an issue in practice.) I do agree with the fact that the number or alternatives for each scene typ= ically is going to be rather small. Regards, Christer From pkyzivat@alum.mit.edu Wed Dec 19 08:21: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 6CCB421F8439 for ; Wed, 19 Dec 2012 08:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX5M8y0QXgz3 for ; Wed, 19 Dec 2012 08:21:20 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id AE7B021F8B20 for ; Wed, 19 Dec 2012 08:21:20 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta04.westchester.pa.mail.comcast.net with comcast id dPlN1k0031c6gX854UMLyu; Wed, 19 Dec 2012 16:21:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id dUMK1k00V3ZTu2S3jUMKtH; Wed, 19 Dec 2012 16:21:19 +0000 Message-ID: <50D1E97F.7000202@alum.mit.edu> Date: Wed, 19 Dec 2012 11:21:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355934080; bh=fGwLxc634N4hyYj3/tAM79LY/IfuPB1NCcaxgB9iI0g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sL+HEFMtAjteEM+2p/USXayLYiecZohYQUNgOIncv52itBv3L8W+4SgG75ViZdfZy tqXsl4A5OOVETFkbdVmda0Nneew/7IK1WMzvMfjpRSJ1pwlya30KDIWkU0KZZmccFK 7HLV8eQ0p0IvCW2uKbPE/mAelWIYTfjd4NaWYicKve77ZoKlQRAyEZc6LD19ioNgIB xg9KIA2fnJBh4I55quSLTThiC6kewEjssPI29oKgwJxSS8/clgd2kEsyzrdAuwA3aK GY7zqNqLCgU6t/6X1XdBom8plT3WpnSQNnYd/owec5okv8DOsXxp+h61qJFf6NfwN8 9WatES/UrfjOA== Subject: [clue] signaling - how do advertisements and configurations work? 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, 19 Dec 2012 16:21:21 -0000 Lately there have been various proposals for changing some of the details of advertisements and configurations. When trying to compare them to the "current" proposal from the framework people have argued that the current proposal isn't clear either. Looking back at the framework, I agree. I have thought that everyone understood it, whether written down or not, but apparently not all understand it the same way. So here I will attempt to describe how I think advertisements and configurations, as currently described in the framework, are *intended* to work. Of course I may be wrong. I'm happy to entertain corrections. I want to get consensus on what the current proposal intends, and then update the framework as necessary to be unambiguous about this. When we are clear what the current proposal is, we can consider proposals to alter it. Please comment whether you think this is as intended, and if it sufficiently specified for this level of abstraction. I'm going to keep this description as abstract as I can while still capturing essential details. I would prefer not to get hung up on details of syntax. Those can be worked out later. Advertisement message ===================== Content: - a unique version # / identifier, used to refer to this message - a set of Encoding Groups - for each Encoding Group, a set of Encodings, each with a unique identifier, and each with a number of attributes not relevant to this discussion. - a set of Scenes, each with a number of attributes. The ones relevant to this discussion are: . one or more Capture Scene Entries. - a set of Captures, each with a number of attributes. The ones relevant to this discussion are: . a unique identifier for the Capture . a reference to the containing Scene, used to qualify coordinates . a reference to one of the Encoding Groups - each Capture Scene Entry contains references to one or more Captures - a set of Simultaneous Transmission Sets. (set of sets.) - each Simultaneous Transmission Set contains references to one or more Captures. Rules for how the Advertisement message is constructed: - I'm saying nothing about how the message is encoded. References among elements within the message can be via identifiers, or by nesting of xml elements, or whatever. - Each Encoding is associated with exactly one Encoding Group. - Each Capture is associated with exactly one Scene - Each Capture Scene Entry is associated with exactly one Scene - The Captures referenced from a Capture Scene Entry must all be associated with the same Scene that the CSE is associated with. - A Capture may be referenced by more than one CSE. - The Captures in a Simultaneous Transmission Set may be from the same or different Scenes. Configure message ================= Content: - the version # / identifier of a previously received Advertisement message. - a set of Capture Encoding references - for each Capture Encoding reference, . the identifier of a Capture from the Advertisement . the identifier of an Encoding from the Advertisement Rules for how the Configure message is constructed: - I'm saying nothing about how the message is encoded. References among elements within the message can be via identifiers, or by nesting of xml elements, or whatever. - The version # / identifier should identify the most recently received Advertisement. - All of the selected Captures must appear in *one* of the Simultaneous Transmission Sets of the Advertisement. - Each Encoding in the Advertisement may be referenced from at most one Capture Encoding reference in the Configure message. Thanks, Paul From pkyzivat@alum.mit.edu Wed Dec 19 08:42: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 3307121F85DF for ; Wed, 19 Dec 2012 08:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6Cf2ufJZIGu for ; Wed, 19 Dec 2012 08:42:37 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 436DB21F84F6 for ; Wed, 19 Dec 2012 08:42:37 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta04.westchester.pa.mail.comcast.net with comcast id dSmk1k0040mv7h054Uic6b; Wed, 19 Dec 2012 16:42:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id dUic1k00T3ZTu2S3XUicK8; Wed, 19 Dec 2012 16:42:36 +0000 Message-ID: <50D1EE7B.1010002@alum.mit.edu> Date: Wed, 19 Dec 2012 11:42:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it>, <50CF52E9.8000302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0689A1@ESESSMB209.ericsson.se>, <50CF7410.8010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0694D5@ESESSMB209.ericsson.se> <50CF9622.6090306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B06C6BC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B06C6BC@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1355935356; bh=O3dGKEpgPbhkAqfAYNJF3cAMHZcAZG011eAHGKpfh38=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qPwduQXYJakcvMcML5KOIZEAkg4A3KBRUjbJm+J0e78RCa1oV3P6eeK7+BIHK+G/s 7fXxzk0a0aXiQA9F2vbhHOPAmAFgKqId5XCGgMEUxxgo6zTgl/cKjmdhhidtLRu/1c NE9eDTMP3UQ8h35gItJYobxV9QQi+Tc1z0ZGLqo/oY1w2lXckuuAwU4nRM/CWwwsk9 H+AedBUAcjeFcfuyc/e1KAMWxs3PqPWA3He5S+getoROP1bWCpZVUu4iuZDlF7Q4a1 J53IwFbfdS4Biax/nmLDeajap8uOq1pjmy/lt101E9AqG6JXMrq3iXIu0CIngqb3sE kEBYegru8VKAw== Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 19 Dec 2012 16:42:38 -0000 On 12/19/12 6:43 AM, Christer Holmberg wrote: > Hi, > >>>>>> I have also been thinking about a bigger change: have a single list >>>>>> of CSEs for the advertisement, rather than one per scene. (CSE is >>>>>> then a misnomer, but for now I'll still use it.) Each entry would >>>>>> contain a list of captures that, taken together, is a recommended >>>>>> rendition of the advertisement as a whole. This would allow >>>>>> tradeoffs between captures in different scenes to offer choices >>>>>> with fewer captures than scenes. There is currently no way to do >>>>>> that. I can't think of any downsides to this change. What do people think of this? >>>>> >>>>> I am not sure I understand. >>>>> >>>>> What do you mean by "rather than one per scene"? You can advertise multiple CSEs per scene, can't you? >>>>> >>>>> I am also not sure I understand what you mean by "rendition of the advertisement". >>>>> >>>>> And, I am not sure I understand "tradeoffs between captures in different scenes". I thougth you suggested that captures can only belong to one scene? >>>> >>>> OK, obviously I didn't explain myself very well. Let me try again. >>>> >>>> First, instead of a list of CSEs per scene, I'm proposing a list of >>>> (something) per advertisement. Just to have something, for now lets >>>> call them Advertisement Entries - ADEs. Like a CSE, each ADE is a >>>> list of captures. In this case they can be any capture in the >>>> advertisement, regardless of scene. >>>> >>>> So overall structure is something like: >>>> >>>> >>>> >>>> (descriptive info for the scene) >>>> (descriptive info for the scene) >>>> ... >>>> >>>> >>>> ... >>>> ... >>>> ... >>>> ... >>>> ... >>>> ... >>>> ... >>>> >>>> >>>> f1,f2,b1,b2 >>>> f3,b1,b2 >>>> f1,f2,b3 >>>> f3,b3 >>>> b3 >>>> >>>> >>>> >>>> >>>> Here, you can think that f3 is a composite of f1 & f2, and b3 is a >>>> composite of b1 and b2. Perhaps scene foo is a room, and scene bar >>>> contains a couple of presentations. >>>> >>>> This explicitly allows the advertiser to think about and propose >>>> tradeoffs between scenes. So a5 makes the decision that if you can >>>> only receive one capture you are better off getting the presentation >>>> than the room. >>> >>> I think it's quite strange if the advertiser starts to advertise "partly scenes", trying to figure out what the receiver may want, and trying to figure out what the capabilities of the receiver are. >> >> Isn't that what CSEs already do? >> >> Isn't it generally expected that CSEs will differ in the number of captures they include, so that they can accommodate consumers that can handle only a limited number of captures? > > Yes, the number of captures will differ. But, each CSE still represents a complete scene. > > Or, are you saying that f1 + f2 could be seen as one CSE for foo, and f3 as another CSE for foo (and, the same for b1 + b2 and b3)? Yes, that is exactly what I meant. If the same case were done with CSEs it would be that way. >> What I have suggested continues that, and extends it to cover multiple scenes. > > My preference would still be to keep scenes separated from each other. The receiver will then, for each scene it wants, choose the scene alternative (CSE) based on its capabilities etc. I'm trying to discuss the pros/cons on a basis other than mere "preference". >> I guess the controversial part in my example is ADE a5, that omits any content from scene foo. It has made a value judgement that omitting >> all of foo is still a valid representation of the advertisement. (It might be clearer if we had both audio and video, and it retained audio from >> foo but not video.) And it might be that in some cases this wouldn't be included in the advertisement because it wouldn't be sufficient. >> >>> My preference is still that we don't need to advertise scene trade-offs. Instead the advertiser provides full scene alternatives (CSEs), and >>> let the receiver choose which scene(s) (and associated CSEs), it wants to receive. >> >> I've been talking about this for months. I agree that ultimately it is the recipient that makes the final decision. But can be very hard - the receiver >> has limited info to make the decision. This can be partly solved by extensions to capture attributes, such as Christian has proposed. Including a >> priority attribute, where priorities have significance across scenes, provide another way to accomplish the same thing. > > Yes. No matter which way we go, I think the attribute is needed. Yes, I think so too. But in many cases the attributes will only help a human make a manual decision - not sufficient to make an automated decision. The CSEs/ADEs lend themselves better to automated selection. It is particularly hard to make a tradeoff if you can't handle a full CSE from each Scene. >> Aside from being *different* from what we have assumed for a long time, do you see something that makes my proposal worse than having separate CSEs for each scene? > > One issue is that same as I have had previously: by listing captures, and then having the receiver figure out where they belong (no matter whether we group according to scene, CSE, ADE or whatever). But, again, that is mainly a coding issue. There are multiple potential issues, some more severe than others. I'm not sure which you are concerned with. E.g. - the size of the advertisement - the complexity of constructing the advertisement - complexity of *algorithm* for analyzing an advertisement and automatically choosing a configuration - complexity of *algorithm* for analyzing an advertisement and constructing a menu of viable alternative configurations for an end user to choose among But IMO what I'm proposing will simplify the configuration algorithms for automatic selection of config, may increase the size of the advertisement a bit, and is probably neutral for construction of the advertisement. > Another issue is, as indicated above, I see no need for mixing together scenes. The reason is because the rendering of them will be mixed. The resources used to render them can often be used for captures from different scenes. Mixing them gives a convenient way for the advertiser to recommend potential viable tradeoffs and priorities. Thanks, Paul >> (Answering my own question: if there are many alternatives for each scene, then my proposal would increase the total number of entries - the product of the entries in each. But I doubt this is an issue in practice.) > > I do agree with the fact that the number or alternatives for each scene typically is going to be rather small. > > Regards, > > Christer > > From Mark.Duckworth@polycom.com Wed Dec 19 15:01:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A1421F88DB for ; Wed, 19 Dec 2012 15:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDz1XuqBkVp1 for ; Wed, 19 Dec 2012 15:01:03 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 647C721F88CE for ; Wed, 19 Dec 2012 15:01:03 -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, 19 Dec 2012 15:01:02 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 19 Dec 2012 15:01:00 -0800 Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3Y1KiQO8drlauCSEmjXXjlZJ3tLgFZ0E5g Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610391BE7013@CRPMBOXPRD01.polycom.com> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <50C61E8E.1090805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053E9D@ESESSMB209.ericsson.se>, <50C8BCA5.8020702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0543CD@ESESSMB209.ericsson.se> <50C93510.7080502@nteczone.com> In-Reply-To: <50C93510.7080502@nteczone.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] Capture scene clarifications 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, 19 Dec 2012 23:01:04 -0000 Hi Christian, I agree with you that a capture scene entry represents an "entire scene". I like your proposal for optional simultaneous transmission sets. I have a= suggestion for clarifying 2b and 3b. 2b. if multiple capture scene entries are sent in a scene then the consumer= may choose at most one capture scene entry for each media type. 3b. if multiple capture scene entries are sent in a scene then the consumer= SHOULD choose one capture scene entry for each media type, but may choose = captures based on the simultaneous transmission set. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Wednesday, December 12, 2012 8:53 PM > To: clue@ietf.org > Subject: Re: [clue] Capture scene clarifications >=20 > Hello >=20 > I'm not sure about this. Now we are saying that a capture scene entry doe= s > not represent an "entire scene" but now represents part of a scene. > I think logically it works better if an individual capture is part of the= scene and > a capture scene entry depicts an "entire" scene from the viewpoint of the > provider. If the provider now provides part scenes how does the consumer > determine what's a full scene? >=20 > It seems to me that whilst a Consumer may theoretically want to do all so= rts > of things with the captures ultimately its the provider that determines w= hat > can actually be provided. The consumer may just want to see "the boss" bu= t > the provider won't know that it has to provide individual captures when i= t > does the initial advertisement. >=20 > A provider may be reasonably concise (i.e. I have two capture scene entri= es > choose one) or it may be verbose (i.e. I have several capture scene entri= es, I > can provide all these different captures, here's the dependency between > them). >=20 > I've asked previously if simultaneous transmission sets are a mandatory t= o > send. I don't think this has been determined. >=20 > After the discussions in order to strike a balance between simple and > complex cases i'd like to propose the following: >=20 > 1. It is optional for a provider to send a simultaneous transmission set. > 2. If the provider does not send a simultaneous transmission set: > 2a. if multiple scenes are advertised it is assumed that they can be prov= ided > simultaneously. > 2b. if multiple capture scene entries are sent in a scene then the consum= er > must chose one capture scene entry. > 3. If the provider does sent a simultaneous transmission set: > 3a. if multiple scenes are advertised simultaneity constraints are derive= d > from the simultaneous transmission set. > 3b. if multiple capture scene entries are sent in a scene then the consum= er > SHOULD close on capture scene entry but may chose captures based on the > simultaneous transmission set. >=20 > Regards, Christian >=20 > On 13/12/2012 7:37 AM, Christer Holmberg wrote: > > Hi, > > > > I'm putting the other discussion on hold for the moment, because I > > think we are starting to find some common ground in this one :) > > > >>>>>>>>> With regards to simultaneous sets I think we need to resolve > >>>>>>>>> what capture scene entries represent. Currently the framework > >>>>>>>>> says that it must be possible to send all captures in a > >>>>>>>>> Capture Scene Entry simultaneously. To me logically speaking a > >>>>>>>>> capture scene entry is effectively a simultaneous transmission > >>>>>>>>> set. To send effectively the same information twice seems to me > to be abit of a waste. > >>>>>>>> [Duckworth, Mark] It isn't supposed to be the same information. > >>>>>>>> The framework says "The simultaneous transmission sets MUST > >>>>>>>> allow all the media captures in a particular capture scene > >>>>>>>> entry to be used simultaneously." So all the media captures fro= m > a particular capture scene entry must also appear together in a simultane= ous > transmission set. But that >>>>>simultaneous transmission set could also > include more media captures, not just media captures that appear in the > same capture scene entry. > >>>>>>> I agree to the understanding, but I still question the need. > >>>>>>> > >>>>>>> Why can't the "additional captures" be part of a dedicated captur= e > scene entry? > >>>>>> I guess the question is whether you think the provider can > >>>>>> anticipate and advertise every possible combination that a receive= r > might desire. > >>>>>> > >>>>>> An example that has been given various times is a recipient that > >>>>>> wants to always receive the capture that includes his boss, even > >>>>>> when the boss isn't speaking. > >>>>>> > >>>>>> And he wants this in combination with some other captures that > >>>>>> might be some conventional scene entry. So this might mean one > >>>>>> full scene entry plus one capture from some other scene entry. Or = it > might mean *parts* of two scene entries to assemble something useful that > always includes the boss. > >>>>> You can achieve this e.g. using two separate SCENES: one SCENE with > a capture scene entry that contains the full scene capture, and another > SCENE with a capture scene entry that contains the boss capture. > >>>> My assumption was that the boss is not everyone's boss, or known to > be special in any way to the providing site. Rather he is important only = to the > recipient(s) in one of the other rooms. > >>>> > >>>> Stated more abstractly, the receiver has special interest in one of = the > provider's captures that the provider does not realize is of more interes= t than > any of its other captures. > >>> So, if I understand you correctly, the provider could e.g: > >> There are many things a provider *could* do. Many of them don't make > sense, or IMO are a bad idea. > >> > >>> 1) Provide a single SCENE with a capture scene entry that contains th= e > "full room", and individual captures of each participant. > >> I guess you mean that a single scene *entry* contains both the "full > room" capture and the individual captures? > >> > >> IMO that is contrary to the intent of a scene entry. The entry has > >> redundant information, and requires a recipient with no special needs > >> to analyze it and decide it could simply render *either* the "full roo= m" > >> capture, or all the other captures in the entry. This is hard. > >> > >> Rather, I would think this same information would be represented > >> better as two scene entries: > >> > >> - an entry with the single "full room" capture > >> - an entry with individual captures for each participant. > >> > >> Each of these provides a full rendering of the room, in a different wa= y. > > Ok, let's go with that for now :) > > > > So, we have a single SCENE, which has two associated CSEs (Capture Scen= e > Entries): > > > > - "full room" CSE (capture of full room) > > - "individual" CSE (captures of each participant) > > > >>> Of the individual participant captures, the receiver will then only > >>> choose the capture associated with the important participant - ie > >>> the receiver is not mandated to receive everything in the chosen > >>> capture scene entry; > >> With the alternative I just mentioned, a receiver with no special > >> interests could then choose one of those entries that best meets its > >> needs and capabilities. E.g. if it has enough displays and decoders > >> to receive all the individual captures, then that might be the better > >> choice. If it doesn't have enough resources to do that then it could > >> simply choose the single capture full room entry. > > Agree. > > > >> A receiver that has special interest in one participant (the boss) > >> might then decide to receive the entry with the full room capture, > >> and also the one capture for the boss from the entry that has all the > >> individual captures. > > Almost agree :) > > > > In my opinion, the receiver would decide two receive both CSEs, but it > would indicate that from the individual CSE it only wants to "boss" captu= re. > > > > So, the end result is really the same. The only different is that, in m= y > opinion, the receiver must always pick a CSE (but it may choose which > captures it wants). > > > > The advantage is that we then only need to advertise simultanous CSE se= ts > - not simultanous capture sets - as it is assumed that a provider can alw= ays > provide all captures associated with a CSE. > > > > (This of course means we would need to allow picking multiple CSEs > > from a single SCENE.) > > > > Regards, > > > > Christer > > > > _______________________________________________ > > 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 Christian.Groves@nteczone.com Wed Dec 19 15:43: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 ADE6C21F841B for ; Wed, 19 Dec 2012 15:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uha4kjiX2jFc for ; Wed, 19 Dec 2012 15:43:55 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id A8F0421F8417 for ; Wed, 19 Dec 2012 15:43:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcEACBQ0lB20V3h/2dsb2JhbAANNw6DOrknBAOBGoMRAQEBAwEBAQE1GxsKAQULCw4TFg8JAwIBAgEVMAYNAQUCAQGICRKkP5N6BJEQA5IdlmtSgVAH Received: from ppp118-209-93-225.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.93.225]) by ipmail06.adl2.internode.on.net with ESMTP; 20 Dec 2012 10:13:52 +1030 Message-ID: <50D1039A.8090300@nteczone.com> Date: Wed, 19 Dec 2012 11:00:26 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Paul Kyzivat References: <50D0DC1B.7060100@alum.mit.edu> In-Reply-To: <50D0DC1B.7060100@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Some thoughts about CLUE signaling 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, 19 Dec 2012 23:43:55 -0000 Hello Paul, Please see my comments below. Regards, Christian ..snip.. > > First, we need to agree on what is included in the subject "clue > signaling". I consider all of the following are aspects/dimensions to > the subject: > > 1) the clue-specific signaling protocol > a) the messages: advertisement, configure, ack?, nak? > b) the payload of advertisement & configure (from data model) > c) sequencing of clue messages, state machines > 2) clue use of SDP O/A, including establishment of clue message channel [CNG] Need to consider removal of clue channel? > 3) linkage & sequencing of clue-specific messages and SDP O/A > 4) sip signaling (this may be unremarkable) > 5) interop with legacy SIP devices > 6) clue over RTCWEB [CNG] I would also add to the list clue interaction with any call / bearer release/teardown. Also "in session" modification is something also to cover. > > I expect that the clue signaling document will cover all of these > subjects. (Perhaps with the exception of RTCWEB.) I have no strong > preference at this time about the document structure to cover these. > > I have thought some about the sequencing of clue messages. The > following are some thoughts on that. These may be entirely obvious to > everyone. (If so, hurray!) But I'll have a better idea after everyone > concurs, or not. > > - media for a capture encoding will not be sent unless it has > been configured. (Exception: prior to first adv/cfg exchange, > which includes compatibility with non-clue endpoints.) > > - a capture must be advertised before it can be configured. > (This is fundamental, the config must reference identifiers > from the advertisement for the capture & encoding.) > > - when a provider wishes to stop sending a capture encoding that has > been configured, it *should* *first* send a new advertisement > that no longer advertises that capture and/or encoding, and should > wait for that advertisement to be acknowledged. [CNG] How does this relate to any call bearer / release signalling? > > - if a provider must stop sending a capture encoding before advertising > that it is not available, it *must* still send an advertisement > indicating this at the first opportunity. > (Until it gets this, the consumer is likely to treat the > missing capture encoding as an error, giving a poor user experience.) [CNG] Assuming that the CLUE channel is still up? > > - when a consumer receives a new advertisement that no longer > offers a capture and/or encoding that is currently configured, > that is an indication that the capture is no longer available and will > most likely no longer be sent. The consumer should not > consider it an error when that capture encoding is no longer received. [CNG] I guess its important to understand what that then means for SIP/ SDP OA signalling. Its one thing to say not an error but should it trigger some signalling. > > > - when a consumer receives a new advertisement, it *should* > send a new configuration asap that is consistent with the > new advertisement. This means it references the new > advertisement and it configures only captures and encodings > mentioned in that advertisement. [CNG] The current framework says that this is not necessary. A new configuration is only sent if the old configuration is invalid. From a protocol perspective I think its good practise to send an acknowledgement but the transport may give that indication. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Dec 19 18:05: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 33CCA21F8A6E for ; Wed, 19 Dec 2012 18:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zv34C2fOuka5 for ; Wed, 19 Dec 2012 18:05:50 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 9010421F8A69 for ; Wed, 19 Dec 2012 18:05:49 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcEAAdy0lB20c4z/2dsb2JhbAANN4NIuSgEA4EYgxEBAQEEAQEBCyobEgkKDQQLEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBiBukW5N1BIxNhEMDkleXA4FQBQ Received: from ppp118-209-206-51.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.206.51]) by ipmail05.adl6.internode.on.net with ESMTP; 20 Dec 2012 12:35:46 +1030 Message-ID: <50D27275.4000001@nteczone.com> Date: Thu, 20 Dec 2012 13:05:41 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <50C61E8E.1090805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053E9D@ESESSMB209.ericsson.se>, <50C8BCA5.8020702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0543CD@ESESSMB209.ericsson.se> <50C93510.7080502@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391BE7013@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A610391BE7013@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Capture scene clarifications 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, 20 Dec 2012 02:05:52 -0000 Hello Mark, With regards to 2b is that intent of using "may" that the consumer doesn't have to choose any capture? Regards, Christian On 20/12/2012 10:01 AM, Duckworth, Mark wrote: > Hi Christian, > > I agree with you that a capture scene entry represents an "entire scene". > > I like your proposal for optional simultaneous transmission sets. I have a suggestion for clarifying 2b and 3b. > > 2b. if multiple capture scene entries are sent in a scene then the consumer may choose at most one capture scene entry for each media type. > > 3b. if multiple capture scene entries are sent in a scene then the consumer SHOULD choose one capture scene entry for each media type, but may choose captures based on the simultaneous transmission set. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Wednesday, December 12, 2012 8:53 PM >> To: clue@ietf.org >> Subject: Re: [clue] Capture scene clarifications >> >> Hello >> >> I'm not sure about this. Now we are saying that a capture scene entry does >> not represent an "entire scene" but now represents part of a scene. >> I think logically it works better if an individual capture is part of the scene and >> a capture scene entry depicts an "entire" scene from the viewpoint of the >> provider. If the provider now provides part scenes how does the consumer >> determine what's a full scene? >> >> It seems to me that whilst a Consumer may theoretically want to do all sorts >> of things with the captures ultimately its the provider that determines what >> can actually be provided. The consumer may just want to see "the boss" but >> the provider won't know that it has to provide individual captures when it >> does the initial advertisement. >> >> A provider may be reasonably concise (i.e. I have two capture scene entries >> choose one) or it may be verbose (i.e. I have several capture scene entries, I >> can provide all these different captures, here's the dependency between >> them). >> >> I've asked previously if simultaneous transmission sets are a mandatory to >> send. I don't think this has been determined. >> >> After the discussions in order to strike a balance between simple and >> complex cases i'd like to propose the following: >> >> 1. It is optional for a provider to send a simultaneous transmission set. >> 2. If the provider does not send a simultaneous transmission set: >> 2a. if multiple scenes are advertised it is assumed that they can be provided >> simultaneously. >> 2b. if multiple capture scene entries are sent in a scene then the consumer >> must chose one capture scene entry. >> 3. If the provider does sent a simultaneous transmission set: >> 3a. if multiple scenes are advertised simultaneity constraints are derived >> from the simultaneous transmission set. >> 3b. if multiple capture scene entries are sent in a scene then the consumer >> SHOULD close on capture scene entry but may chose captures based on the >> simultaneous transmission set. >> >> Regards, Christian >> >> On 13/12/2012 7:37 AM, Christer Holmberg wrote: >>> Hi, >>> >>> I'm putting the other discussion on hold for the moment, because I >>> think we are starting to find some common ground in this one :) >>> >>>>>>>>>>> With regards to simultaneous sets I think we need to resolve >>>>>>>>>>> what capture scene entries represent. Currently the framework >>>>>>>>>>> says that it must be possible to send all captures in a >>>>>>>>>>> Capture Scene Entry simultaneously. To me logically speaking a >>>>>>>>>>> capture scene entry is effectively a simultaneous transmission >>>>>>>>>>> set. To send effectively the same information twice seems to me >> to be abit of a waste. >>>>>>>>>> [Duckworth, Mark] It isn't supposed to be the same information. >>>>>>>>>> The framework says "The simultaneous transmission sets MUST >>>>>>>>>> allow all the media captures in a particular capture scene >>>>>>>>>> entry to be used simultaneously." So all the media captures from >> a particular capture scene entry must also appear together in a simultaneous >> transmission set. But that >>>>>simultaneous transmission set could also >> include more media captures, not just media captures that appear in the >> same capture scene entry. >>>>>>>>> I agree to the understanding, but I still question the need. >>>>>>>>> >>>>>>>>> Why can't the "additional captures" be part of a dedicated capture >> scene entry? >>>>>>>> I guess the question is whether you think the provider can >>>>>>>> anticipate and advertise every possible combination that a receiver >> might desire. >>>>>>>> An example that has been given various times is a recipient that >>>>>>>> wants to always receive the capture that includes his boss, even >>>>>>>> when the boss isn't speaking. >>>>>>>> >>>>>>>> And he wants this in combination with some other captures that >>>>>>>> might be some conventional scene entry. So this might mean one >>>>>>>> full scene entry plus one capture from some other scene entry. Or it >> might mean *parts* of two scene entries to assemble something useful that >> always includes the boss. >>>>>>> You can achieve this e.g. using two separate SCENES: one SCENE with >> a capture scene entry that contains the full scene capture, and another >> SCENE with a capture scene entry that contains the boss capture. >>>>>> My assumption was that the boss is not everyone's boss, or known to >> be special in any way to the providing site. Rather he is important only to the >> recipient(s) in one of the other rooms. >>>>>> Stated more abstractly, the receiver has special interest in one of the >> provider's captures that the provider does not realize is of more interest than >> any of its other captures. >>>>> So, if I understand you correctly, the provider could e.g: >>>> There are many things a provider *could* do. Many of them don't make >> sense, or IMO are a bad idea. >>>>> 1) Provide a single SCENE with a capture scene entry that contains the >> "full room", and individual captures of each participant. >>>> I guess you mean that a single scene *entry* contains both the "full >> room" capture and the individual captures? >>>> IMO that is contrary to the intent of a scene entry. The entry has >>>> redundant information, and requires a recipient with no special needs >>>> to analyze it and decide it could simply render *either* the "full room" >>>> capture, or all the other captures in the entry. This is hard. >>>> >>>> Rather, I would think this same information would be represented >>>> better as two scene entries: >>>> >>>> - an entry with the single "full room" capture >>>> - an entry with individual captures for each participant. >>>> >>>> Each of these provides a full rendering of the room, in a different way. >>> Ok, let's go with that for now :) >>> >>> So, we have a single SCENE, which has two associated CSEs (Capture Scene >> Entries): >>> - "full room" CSE (capture of full room) >>> - "individual" CSE (captures of each participant) >>> >>>>> Of the individual participant captures, the receiver will then only >>>>> choose the capture associated with the important participant - ie >>>>> the receiver is not mandated to receive everything in the chosen >>>>> capture scene entry; >>>> With the alternative I just mentioned, a receiver with no special >>>> interests could then choose one of those entries that best meets its >>>> needs and capabilities. E.g. if it has enough displays and decoders >>>> to receive all the individual captures, then that might be the better >>>> choice. If it doesn't have enough resources to do that then it could >>>> simply choose the single capture full room entry. >>> Agree. >>> >>>> A receiver that has special interest in one participant (the boss) >>>> might then decide to receive the entry with the full room capture, >>>> and also the one capture for the boss from the entry that has all the >>>> individual captures. >>> Almost agree :) >>> >>> In my opinion, the receiver would decide two receive both CSEs, but it >> would indicate that from the individual CSE it only wants to "boss" capture. >>> So, the end result is really the same. The only different is that, in my >> opinion, the receiver must always pick a CSE (but it may choose which >> captures it wants). >>> The advantage is that we then only need to advertise simultanous CSE sets >> - not simultanous capture sets - as it is assumed that a provider can always >> provide all captures associated with a CSE. >>> (This of course means we would need to allow picking multiple CSEs >>> from a single SCENE.) >>> >>> Regards, >>> >>> Christer >>> >>> _______________________________________________ >>> 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 Dec 19 20:28: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 22FEB21F857A for ; Wed, 19 Dec 2012 20:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n18YP5kvi+yJ for ; Wed, 19 Dec 2012 20:28:48 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8106321F842F for ; Wed, 19 Dec 2012 20:28:44 -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, 19 Dec 2012 20:28:44 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 19 Dec 2012 20:28:40 -0800 Thread-Topic: [clue] Capture scene clarifications Thread-Index: Ac3eVo3jwfS+JcewR1C8yJcGoSalpgAE6+gQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610391BE7077@CRPMBOXPRD01.polycom.com> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <50C61E8E.1090805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053E9D@ESESSMB209.ericsson.se>, <50C8BCA5.8020702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0543CD@ESESSMB209.ericsson.se> <50C93510.7080502@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391BE7013@CRPMBOXPRD01.polycom.com> <50D27275.4000001@nteczone.com> In-Reply-To: <50D27275.4000001@nteczone.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] Capture scene clarifications 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, 20 Dec 2012 04:28:49 -0000 Hello Christian, Yes, that's right. Or the consumer may choose a subset of captures from th= e capture scene entry. Or the consumer could choose just an audio capture scene entry but no video= . Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Wednesday, December 19, 2012 9:06 PM > To: clue@ietf.org > Subject: Re: [clue] Capture scene clarifications >=20 > Hello Mark, >=20 > With regards to 2b is that intent of using "may" that the consumer doesn'= t > have to choose any capture? >=20 > Regards, Christian >=20 > On 20/12/2012 10:01 AM, Duckworth, Mark wrote: > > Hi Christian, > > > > I agree with you that a capture scene entry represents an "entire scen= e". > > > > I like your proposal for optional simultaneous transmission sets. I ha= ve a > suggestion for clarifying 2b and 3b. > > > > 2b. if multiple capture scene entries are sent in a scene then the cons= umer > may choose at most one capture scene entry for each media type. > > > > 3b. if multiple capture scene entries are sent in a scene then the cons= umer > SHOULD choose one capture scene entry for each media type, but may > choose captures based on the simultaneous transmission set. > > > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Christian Groves > >> Sent: Wednesday, December 12, 2012 8:53 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] Capture scene clarifications > >> > >> Hello > >> > >> I'm not sure about this. Now we are saying that a capture scene entry > >> does not represent an "entire scene" but now represents part of a scen= e. > >> I think logically it works better if an individual capture is part of > >> the scene and a capture scene entry depicts an "entire" scene from > >> the viewpoint of the provider. If the provider now provides part > >> scenes how does the consumer determine what's a full scene? > >> > >> It seems to me that whilst a Consumer may theoretically want to do > >> all sorts of things with the captures ultimately its the provider > >> that determines what can actually be provided. The consumer may just > >> want to see "the boss" but the provider won't know that it has to > >> provide individual captures when it does the initial advertisement. > >> > >> A provider may be reasonably concise (i.e. I have two capture scene > >> entries choose one) or it may be verbose (i.e. I have several capture > >> scene entries, I can provide all these different captures, here's the > >> dependency between them). > >> > >> I've asked previously if simultaneous transmission sets are a > >> mandatory to send. I don't think this has been determined. > >> > >> After the discussions in order to strike a balance between simple and > >> complex cases i'd like to propose the following: > >> > >> 1. It is optional for a provider to send a simultaneous transmission s= et. > >> 2. If the provider does not send a simultaneous transmission set: > >> 2a. if multiple scenes are advertised it is assumed that they can be > >> provided simultaneously. > >> 2b. if multiple capture scene entries are sent in a scene then the > >> consumer must chose one capture scene entry. > >> 3. If the provider does sent a simultaneous transmission set: > >> 3a. if multiple scenes are advertised simultaneity constraints are > >> derived from the simultaneous transmission set. > >> 3b. if multiple capture scene entries are sent in a scene then the > >> consumer SHOULD close on capture scene entry but may chose captures > >> based on the simultaneous transmission set. > >> > >> Regards, Christian > >> > >> On 13/12/2012 7:37 AM, Christer Holmberg wrote: > >>> Hi, > >>> > >>> I'm putting the other discussion on hold for the moment, because I > >>> think we are starting to find some common ground in this one :) > >>> > >>>>>>>>>>> With regards to simultaneous sets I think we need to resolve > >>>>>>>>>>> what capture scene entries represent. Currently the > >>>>>>>>>>> framework says that it must be possible to send all captures > >>>>>>>>>>> in a Capture Scene Entry simultaneously. To me logically > >>>>>>>>>>> speaking a capture scene entry is effectively a simultaneous > >>>>>>>>>>> transmission set. To send effectively the same information > >>>>>>>>>>> twice seems to me > >> to be abit of a waste. > >>>>>>>>>> [Duckworth, Mark] It isn't supposed to be the same > information. > >>>>>>>>>> The framework says "The simultaneous transmission sets > MUST > >>>>>>>>>> allow all the media captures in a particular capture scene > >>>>>>>>>> entry to be used simultaneously." So all the media captures > >>>>>>>>>> from > >> a particular capture scene entry must also appear together in a > >> simultaneous transmission set. But that >>>>>simultaneous > >> transmission set could also include more media captures, not just > >> media captures that appear in the same capture scene entry. > >>>>>>>>> I agree to the understanding, but I still question the need. > >>>>>>>>> > >>>>>>>>> Why can't the "additional captures" be part of a dedicated > >>>>>>>>> capture > >> scene entry? > >>>>>>>> I guess the question is whether you think the provider can > >>>>>>>> anticipate and advertise every possible combination that a > >>>>>>>> receiver > >> might desire. > >>>>>>>> An example that has been given various times is a recipient > >>>>>>>> that wants to always receive the capture that includes his > >>>>>>>> boss, even when the boss isn't speaking. > >>>>>>>> > >>>>>>>> And he wants this in combination with some other captures that > >>>>>>>> might be some conventional scene entry. So this might mean one > >>>>>>>> full scene entry plus one capture from some other scene entry. > >>>>>>>> Or it > >> might mean *parts* of two scene entries to assemble something useful > >> that always includes the boss. > >>>>>>> You can achieve this e.g. using two separate SCENES: one SCENE > >>>>>>> with > >> a capture scene entry that contains the full scene capture, and > >> another SCENE with a capture scene entry that contains the boss captur= e. > >>>>>> My assumption was that the boss is not everyone's boss, or known > >>>>>> to > >> be special in any way to the providing site. Rather he is important > >> only to the > >> recipient(s) in one of the other rooms. > >>>>>> Stated more abstractly, the receiver has special interest in one > >>>>>> of the > >> provider's captures that the provider does not realize is of more > >> interest than any of its other captures. > >>>>> So, if I understand you correctly, the provider could e.g: > >>>> There are many things a provider *could* do. Many of them don't > >>>> make > >> sense, or IMO are a bad idea. > >>>>> 1) Provide a single SCENE with a capture scene entry that contains > >>>>> the > >> "full room", and individual captures of each participant. > >>>> I guess you mean that a single scene *entry* contains both the > >>>> "full > >> room" capture and the individual captures? > >>>> IMO that is contrary to the intent of a scene entry. The entry has > >>>> redundant information, and requires a recipient with no special > >>>> needs to analyze it and decide it could simply render *either* the "= full > room" > >>>> capture, or all the other captures in the entry. This is hard. > >>>> > >>>> Rather, I would think this same information would be represented > >>>> better as two scene entries: > >>>> > >>>> - an entry with the single "full room" capture > >>>> - an entry with individual captures for each participant. > >>>> > >>>> Each of these provides a full rendering of the room, in a different = way. > >>> Ok, let's go with that for now :) > >>> > >>> So, we have a single SCENE, which has two associated CSEs (Capture > >>> Scene > >> Entries): > >>> - "full room" CSE (capture of full room) > >>> - "individual" CSE (captures of each participant) > >>> > >>>>> Of the individual participant captures, the receiver will then > >>>>> only choose the capture associated with the important participant > >>>>> - ie the receiver is not mandated to receive everything in the > >>>>> chosen capture scene entry; > >>>> With the alternative I just mentioned, a receiver with no special > >>>> interests could then choose one of those entries that best meets > >>>> its needs and capabilities. E.g. if it has enough displays and > >>>> decoders to receive all the individual captures, then that might be > >>>> the better choice. If it doesn't have enough resources to do that > >>>> then it could simply choose the single capture full room entry. > >>> Agree. > >>> > >>>> A receiver that has special interest in one participant (the boss) > >>>> might then decide to receive the entry with the full room capture, > >>>> and also the one capture for the boss from the entry that has all > >>>> the individual captures. > >>> Almost agree :) > >>> > >>> In my opinion, the receiver would decide two receive both CSEs, but > >>> it > >> would indicate that from the individual CSE it only wants to "boss" > capture. > >>> So, the end result is really the same. The only different is that, > >>> in my > >> opinion, the receiver must always pick a CSE (but it may choose which > >> captures it wants). > >>> The advantage is that we then only need to advertise simultanous CSE > >>> sets > >> - not simultanous capture sets - as it is assumed that a provider can > >> always provide all captures associated with a CSE. > >>> (This of course means we would need to allow picking multiple CSEs > >>> from a single SCENE.) > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Wed Dec 19 21:04: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 5832121F88A3 for ; Wed, 19 Dec 2012 21:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFjZQ9L33gUY for ; Wed, 19 Dec 2012 21:04:05 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 62C4821F88A2 for ; Wed, 19 Dec 2012 21:04:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcEAPOa0lB20c4z/2dsb2JhbAANN4NIuSEEA4EZgxEBAQEEAQEBCyobEgkKDQQLEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBiBukWJN/BIxNhEMDkleXA4FQBQ Received: from ppp118-209-206-51.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.206.51]) by ipmail05.adl6.internode.on.net with ESMTP; 20 Dec 2012 15:34:01 +1030 Message-ID: <50D29C3C.8070001@nteczone.com> Date: Thu, 20 Dec 2012 16:03:56 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50BC24E0.8080402@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863CD7@CRPMBOXPRD01.polycom.com> <50C1448C.7030000@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103919A3B17@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B051BEF@ESESSMB209.ericsson.se>, <50C5F963.2000209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B052267@ESESSMB209.ericsson.se> <50C61E8E.1090805@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B053E9D@ESESSMB209.ericsson.se>, <50C8BCA5.8020702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0543CD@ESESSMB209.ericsson.se> <50C93510.7080502@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391BE7013@CRPMBOXPRD01.polycom.com> <50D27275.4000001@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391BE7077@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A610391BE7077@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Capture scene clarifications 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, 20 Dec 2012 05:04:06 -0000 Hello Mark, OK. Perhaps its worth expanding the text of 2b to explain these different possibilities? Regards, Christian On 20/12/2012 3:28 PM, Duckworth, Mark wrote: > Hello Christian, > Yes, that's right. Or the consumer may choose a subset of captures from the capture scene entry. > Or the consumer could choose just an audio capture scene entry but no video. > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Wednesday, December 19, 2012 9:06 PM >> To: clue@ietf.org >> Subject: Re: [clue] Capture scene clarifications >> >> Hello Mark, >> >> With regards to 2b is that intent of using "may" that the consumer doesn't >> have to choose any capture? >> >> Regards, Christian >> >> On 20/12/2012 10:01 AM, Duckworth, Mark wrote: >>> Hi Christian, >>> >>> I agree with you that a capture scene entry represents an "entire scene". >>> >>> I like your proposal for optional simultaneous transmission sets. I have a >> suggestion for clarifying 2b and 3b. >>> 2b. if multiple capture scene entries are sent in a scene then the consumer >> may choose at most one capture scene entry for each media type. >>> 3b. if multiple capture scene entries are sent in a scene then the consumer >> SHOULD choose one capture scene entry for each media type, but may >> choose captures based on the simultaneous transmission set. >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Christian Groves >>>> Sent: Wednesday, December 12, 2012 8:53 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Capture scene clarifications >>>> >>>> Hello >>>> >>>> I'm not sure about this. Now we are saying that a capture scene entry >>>> does not represent an "entire scene" but now represents part of a scene. >>>> I think logically it works better if an individual capture is part of >>>> the scene and a capture scene entry depicts an "entire" scene from >>>> the viewpoint of the provider. If the provider now provides part >>>> scenes how does the consumer determine what's a full scene? >>>> >>>> It seems to me that whilst a Consumer may theoretically want to do >>>> all sorts of things with the captures ultimately its the provider >>>> that determines what can actually be provided. The consumer may just >>>> want to see "the boss" but the provider won't know that it has to >>>> provide individual captures when it does the initial advertisement. >>>> >>>> A provider may be reasonably concise (i.e. I have two capture scene >>>> entries choose one) or it may be verbose (i.e. I have several capture >>>> scene entries, I can provide all these different captures, here's the >>>> dependency between them). >>>> >>>> I've asked previously if simultaneous transmission sets are a >>>> mandatory to send. I don't think this has been determined. >>>> >>>> After the discussions in order to strike a balance between simple and >>>> complex cases i'd like to propose the following: >>>> >>>> 1. It is optional for a provider to send a simultaneous transmission set. >>>> 2. If the provider does not send a simultaneous transmission set: >>>> 2a. if multiple scenes are advertised it is assumed that they can be >>>> provided simultaneously. >>>> 2b. if multiple capture scene entries are sent in a scene then the >>>> consumer must chose one capture scene entry. >>>> 3. If the provider does sent a simultaneous transmission set: >>>> 3a. if multiple scenes are advertised simultaneity constraints are >>>> derived from the simultaneous transmission set. >>>> 3b. if multiple capture scene entries are sent in a scene then the >>>> consumer SHOULD close on capture scene entry but may chose captures >>>> based on the simultaneous transmission set. >>>> >>>> Regards, Christian >>>> >>>> On 13/12/2012 7:37 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> I'm putting the other discussion on hold for the moment, because I >>>>> think we are starting to find some common ground in this one :) >>>>> >>>>>>>>>>>>> With regards to simultaneous sets I think we need to resolve >>>>>>>>>>>>> what capture scene entries represent. Currently the >>>>>>>>>>>>> framework says that it must be possible to send all captures >>>>>>>>>>>>> in a Capture Scene Entry simultaneously. To me logically >>>>>>>>>>>>> speaking a capture scene entry is effectively a simultaneous >>>>>>>>>>>>> transmission set. To send effectively the same information >>>>>>>>>>>>> twice seems to me >>>> to be abit of a waste. >>>>>>>>>>>> [Duckworth, Mark] It isn't supposed to be the same >> information. >>>>>>>>>>>> The framework says "The simultaneous transmission sets >> MUST >>>>>>>>>>>> allow all the media captures in a particular capture scene >>>>>>>>>>>> entry to be used simultaneously." So all the media captures >>>>>>>>>>>> from >>>> a particular capture scene entry must also appear together in a >>>> simultaneous transmission set. But that >>>>>simultaneous >>>> transmission set could also include more media captures, not just >>>> media captures that appear in the same capture scene entry. >>>>>>>>>>> I agree to the understanding, but I still question the need. >>>>>>>>>>> >>>>>>>>>>> Why can't the "additional captures" be part of a dedicated >>>>>>>>>>> capture >>>> scene entry? >>>>>>>>>> I guess the question is whether you think the provider can >>>>>>>>>> anticipate and advertise every possible combination that a >>>>>>>>>> receiver >>>> might desire. >>>>>>>>>> An example that has been given various times is a recipient >>>>>>>>>> that wants to always receive the capture that includes his >>>>>>>>>> boss, even when the boss isn't speaking. >>>>>>>>>> >>>>>>>>>> And he wants this in combination with some other captures that >>>>>>>>>> might be some conventional scene entry. So this might mean one >>>>>>>>>> full scene entry plus one capture from some other scene entry. >>>>>>>>>> Or it >>>> might mean *parts* of two scene entries to assemble something useful >>>> that always includes the boss. >>>>>>>>> You can achieve this e.g. using two separate SCENES: one SCENE >>>>>>>>> with >>>> a capture scene entry that contains the full scene capture, and >>>> another SCENE with a capture scene entry that contains the boss capture. >>>>>>>> My assumption was that the boss is not everyone's boss, or known >>>>>>>> to >>>> be special in any way to the providing site. Rather he is important >>>> only to the >>>> recipient(s) in one of the other rooms. >>>>>>>> Stated more abstractly, the receiver has special interest in one >>>>>>>> of the >>>> provider's captures that the provider does not realize is of more >>>> interest than any of its other captures. >>>>>>> So, if I understand you correctly, the provider could e.g: >>>>>> There are many things a provider *could* do. Many of them don't >>>>>> make >>>> sense, or IMO are a bad idea. >>>>>>> 1) Provide a single SCENE with a capture scene entry that contains >>>>>>> the >>>> "full room", and individual captures of each participant. >>>>>> I guess you mean that a single scene *entry* contains both the >>>>>> "full >>>> room" capture and the individual captures? >>>>>> IMO that is contrary to the intent of a scene entry. The entry has >>>>>> redundant information, and requires a recipient with no special >>>>>> needs to analyze it and decide it could simply render *either* the "full >> room" >>>>>> capture, or all the other captures in the entry. This is hard. >>>>>> >>>>>> Rather, I would think this same information would be represented >>>>>> better as two scene entries: >>>>>> >>>>>> - an entry with the single "full room" capture >>>>>> - an entry with individual captures for each participant. >>>>>> >>>>>> Each of these provides a full rendering of the room, in a different way. >>>>> Ok, let's go with that for now :) >>>>> >>>>> So, we have a single SCENE, which has two associated CSEs (Capture >>>>> Scene >>>> Entries): >>>>> - "full room" CSE (capture of full room) >>>>> - "individual" CSE (captures of each participant) >>>>> >>>>>>> Of the individual participant captures, the receiver will then >>>>>>> only choose the capture associated with the important participant >>>>>>> - ie the receiver is not mandated to receive everything in the >>>>>>> chosen capture scene entry; >>>>>> With the alternative I just mentioned, a receiver with no special >>>>>> interests could then choose one of those entries that best meets >>>>>> its needs and capabilities. E.g. if it has enough displays and >>>>>> decoders to receive all the individual captures, then that might be >>>>>> the better choice. If it doesn't have enough resources to do that >>>>>> then it could simply choose the single capture full room entry. >>>>> Agree. >>>>> >>>>>> A receiver that has special interest in one participant (the boss) >>>>>> might then decide to receive the entry with the full room capture, >>>>>> and also the one capture for the boss from the entry that has all >>>>>> the individual captures. >>>>> Almost agree :) >>>>> >>>>> In my opinion, the receiver would decide two receive both CSEs, but >>>>> it >>>> would indicate that from the individual CSE it only wants to "boss" >> capture. >>>>> So, the end result is really the same. The only different is that, >>>>> in my >>>> opinion, the receiver must always pick a CSE (but it may choose which >>>> captures it wants). >>>>> The advantage is that we then only need to advertise simultanous CSE >>>>> sets >>>> - not simultanous capture sets - as it is assumed that a provider can >>>> always provide all captures associated with a CSE. >>>>> (This of course means we would need to allow picking multiple CSEs >>>>> from a single SCENE.) >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Dec 19 21:13: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 8C35221F8201 for ; Wed, 19 Dec 2012 21:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9zjgBvMTpMz for ; Wed, 19 Dec 2012 21:13:29 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 7E74021F88A3 for ; Wed, 19 Dec 2012 21:13:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgECADOb0lB20c4z/2dsb2JhbAANLQqDSLpBgxEBAQEEAQEBNRsbChELGAkWDwkDAgECARUwEwYCAQEViAakWJN/BIxNEYQyA6la Received: from ppp118-209-206-51.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.206.51]) by ipmail05.adl6.internode.on.net with ESMTP; 20 Dec 2012 15:43:20 +1030 Message-ID: <50D29E6C.1090603@nteczone.com> Date: Thu, 20 Dec 2012 16:13:16 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: <50D1E97F.7000202@alum.mit.edu> In-Reply-To: <50D1E97F.7000202@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] signaling - how do advertisements and configurations work? 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, 20 Dec 2012 05:13:30 -0000 Hello Paul, Please see my replies below. Regards, Christian On 20/12/2012 3:21 AM, Paul Kyzivat wrote: > Lately there have been various proposals for changing some of the > details of advertisements and configurations. When trying to compare > them to the "current" proposal from the framework people have argued > that the current proposal isn't clear either. Looking back at the > framework, I agree. I have thought that everyone understood it, > whether written down or not, but apparently not all understand it the > same way. > > So here I will attempt to describe how I think advertisements and > configurations, as currently described in the framework, are > *intended* to work. Of course I may be wrong. I'm happy to entertain > corrections. > > I want to get consensus on what the current proposal intends, and then > update the framework as necessary to be unambiguous about this. > > When we are clear what the current proposal is, we can consider > proposals to alter it. > > Please comment whether you think this is as intended, and if it > sufficiently specified for this level of abstraction. > > I'm going to keep this description as abstract as I can while still > capturing essential details. I would prefer not to get hung up on > details of syntax. Those can be worked out later. > > Advertisement message > ===================== > > Content: > > - a unique version # / identifier, used to refer to this message [CNG] Hopefully not a unique "version". A unique identifier. I assume that the scope is unique to a CLUE association? > > - a set of Encoding Groups > > - for each Encoding Group, a set of Encodings, each with a > unique identifier, and each with a number of attributes not relevant > to this discussion. > > - a set of Scenes, each with a number of attributes. > The ones relevant to this discussion are: > . one or more Capture Scene Entries. [CNG] You seem to have missed attributes for "Capture Scene Entries". See section 6.2.2 of the framework. > > - a set of Captures, each with a number of attributes. > The ones relevant to this discussion are: > . a unique identifier for the Capture [CNG] Within what scope is the uniqueness? Unique in an advertisement? Unique of the life of the CLUE association? > . a reference to the containing Scene, used to qualify coordinates > . a reference to one of the Encoding Groups [CNG] From the framework it seems that the "media type" is implied by the identifier. > > - each Capture Scene Entry contains references to one or more > Captures > > - a set of Simultaneous Transmission Sets. (set of sets.) > > - each Simultaneous Transmission Set contains references to one or > more Captures. > > Rules for how the Advertisement message is constructed: > > - I'm saying nothing about how the message is encoded. > References among elements within the message can be via > identifiers, or by nesting of xml elements, or whatever. > > - Each Encoding is associated with exactly one Encoding Group. > > - Each Capture is associated with exactly one Scene > > - Each Capture Scene Entry is associated with exactly one Scene > > - The Captures referenced from a Capture Scene Entry must > all be associated with the same Scene that the CSE is > associated with. > > - A Capture may be referenced by more than one CSE. > > - The Captures in a Simultaneous Transmission Set > may be from the same or different Scenes. [CNG] Do we want to add something about media type restrictions? i.e. can't mix > > Configure message > ================= > > Content: > > - the version # / identifier of a previously received > Advertisement message. [CNG] Isn't the version number related to the Content message? i.e. the advertiser and the consumer may in fact support a different maximum version. > > - a set of Capture Encoding references > > - for each Capture Encoding reference, > . the identifier of a Capture from the Advertisement > . the identifier of an Encoding from the Advertisement > > Rules for how the Configure message is constructed: > > - I'm saying nothing about how the message is encoded. > References among elements within the message can be via > identifiers, or by nesting of xml elements, or whatever. > > - The version # / identifier should identify the most > recently received Advertisement. > > - All of the selected Captures must appear in *one* > of the Simultaneous Transmission Sets of the Advertisement. > > - Each Encoding in the Advertisement may be referenced from > at most one Capture Encoding reference in the Configure > message. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Thu Dec 20 04:30: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 731F921F880A for ; Thu, 20 Dec 2012 04:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFtBvdGuXmhT for ; Thu, 20 Dec 2012 04:30:30 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 002D521F874F for ; Thu, 20 Dec 2012 04:30:29 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-10-50d304e42117 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4B.84.10459.4E403D05; Thu, 20 Dec 2012 13:30:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 13:30:28 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [clue] Can receiver select captures from more than one capture scene entry? Thread-Index: AQHN3Hn0g7YsKnVso0yin5dQG9gVdZgdUFyKgAABVQCAACDqKoAAB7MAgAJCSMCAAIlkgIABPrJQ Date: Thu, 20 Dec 2012 12:30:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B06E79B@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it>, <50CF52E9.8000302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0689A1@ESESSMB209.ericsson.se>, <50CF7410.8010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0694D5@ESESSMB209.ericsson.se> <50CF9622.6090306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B06C6BC@ESESSMB209.ericsson.se> <50D1EE7B.1010002@alum.mit.edu> In-Reply-To: <50D1EE7B.1010002@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje4TlssBBtMPW1vsP3WZ2WLFhgOs FtvabjA7MHv8ff+ByWPJkp9MHj+2PGUKYI7isklJzcksSy3St0vgymjc/ou54IJ5xa53x1gb GPt0uhg5OSQETCQ2NZ1mhbDFJC7cW8/WxcjFISRwiFFi/rRnrBDOYkaJf3s2ADkcHGwCFhLd /7RBTBEBDYlJW9VAepkFfCQev57FCGILC0RJHNr4F2ymiEC0xMuV15kg7CiJPUsOsoDYLAKq Esc3toPV8wp4SxyfN5EdYtVFFolbC2eBFXEK6EhcfNwGVsQIdNz3U2uYIJaJS9x6Mp8J4mgB iSV7zjND2KISLx//AztTQkBRYnm/HES5jsSC3Z/YIGxtiWULXzND7BWUODnzCcsERrFZSKbO QtIyC0nLLCQtCxhZVjGy5yZm5qSXG25iBEbNwS2/dXcwnjoncohRmoNFSZw3zPVCgJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbGCf77j3O+F7YsfbzrQlPI9uTgvOnnuX5H/7pydMHnaWeu bX/0x/LS4ScO5hmfppZPF+/Sbf6sU8crf8fR0SLZ7PmTvN0PJ33W1KlTWH9/+mmL9SUNXul5 d9OCZ0wJNXDQfelm5/XFXWj93Lr7P5rSxYS67hds2fAu79uul/06x1aYLVFeWbL6hRJLcUai oRZzUXEiAPiwG7xoAgAA Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 20 Dec 2012 12:30:31 -0000 Hi, >>>>> >>>>> >>>>> (descriptive info for the scene) >>>>> (descriptive info for the scene) >>>>> ... >>>>> >>>>> >>>>> ... >>>>> ... >>>>> ... >>>>> ... >>>>> ... >>>>> ... >>>>> ... >>>>> >>>>> >>>>> f1,f2,b1,b2 >>>>> f3,b1,b2 >>>>> f1,f2,b3 >>>>> f3,b3 >>>>> b3 >>>>> >>>>> >>>>> >>>>> >>>>> Here, you can think that f3 is a composite of f1 & f2, and b3 is a=20 >>>>> composite of b1 and b2. Perhaps scene foo is a room, and scene bar=20 >>>>> contains a couple of presentations. >>>>> >>>>> This explicitly allows the advertiser to think about and propose=20 >>>>> tradeoffs between scenes. So a5 makes the decision that if you can=20 >>>>> only receive one capture you are better off getting the=20 >>>>> presentation than the room. >>>> >>>> I think it's quite strange if the advertiser starts to advertise "part= ly scenes", trying to figure out what the receiver may want, and trying to = figure out what the capabilities of the receiver are. >>> >>> Isn't that what CSEs already do? >>> >>> Isn't it generally expected that CSEs will differ in the number of capt= ures they include, so that they can accommodate consumers that can handle o= nly a limited number of captures? >> >> Yes, the number of captures will differ. But, each CSE still represents = a complete scene. >> >> Or, are you saying that f1 + f2 could be seen as one CSE for foo, and f3= as another CSE for foo (and, the same for b1 + b2 and b3)? > > Yes, that is exactly what I meant. If the same case were done with CSEs i= t would be that way. In your example, you seem to assume that the receiver wants to receive both= scenes (unless it can only receive one). But, maybe the receiver chooses (= based on whatever logic) to only receive the "b scene", but still using cap= tures b1 and b2 (and not b3). There is no ADE for that alternative. The advertiser needs to provide information on what each scene contains, on= e or more CSEs for each scene, and then let the receiver choose what it wan= ts. >>> What I have suggested continues that, and extends it to cover multiple = scenes. >> >> My preference would still be to keep scenes separated from each other. T= he receiver will then, for each scene it wants, choose the scene alternativ= e (CSE) based on its capabilities etc. > > I'm trying to discuss the pros/cons on a basis other than mere "preferenc= e". I think it's a pro allowing the receiver to choose what it wants to receive= , rather than having the provider trying to figure it out. The provider sho= uld provide good enough information, allowing the receiver to make the deci= sions. >>> I guess the controversial part in my example is ADE a5, that omits=20 >>> any content from scene foo. It has made a value judgement that=20 >>> omitting all of foo is still a valid representation of the advertisemen= t. (It might be clearer if we=20 >>> had both audio and video, and it retained audio from foo but not video.= ) And it might be that in some cases this wouldn't be included in the adver= tisement because it wouldn't be sufficient. >>> >>>> My preference is still that we don't need to advertise scene=20 >>>> trade-offs. Instead the advertiser provides full scene alternatives (C= SEs), and let the receiver choose which scene(s) (and associated CSEs), it = wants to receive. >>> >>> I've been talking about this for months. I agree that ultimately it=20 >>> is the recipient that makes the final decision. But can be very hard=20 >>> - the receiver has limited info to make the decision. This can be partl= y solved by extensions to capture attributes, such as=20 >>>Christian has proposed. Including a priority attribute, where priorities= have significance across scenes, provide another way to accomplish the sam= e thing. >> >> Yes. No matter which way we go, I think the attribute is needed. > > Yes, I think so too. But in many cases the attributes will only help a hu= man make a manual decision - not sufficient to make an=20 >automated decision. The CSEs/ADEs lend themselves better to automated sele= ction. It is particularly hard to make a tradeoff=20 >if you can't handle a full CSE from each Scene. Your "boss" use-case is an example where a manual decision will be needed. But, in case of automated selections, I think the receiver in most cases wi= ll try to get a full scene. The provider will need to provide different alt= ernatives (CSEs) for each scene, and if nothing else works then the receive= r probably chooses a CSE containing a single capture for the whole scene (o= r, it chooses specific captures of a CSE based on e.g. spatial information)= . >>> Aside from being *different* from what we have assumed for a long time,= do you see something that makes my proposal worse than having separate CSE= s for each scene? >> >> One issue is that same as I have had previously: by listing captures, an= d then having the receiver figure out where they=20 >> belong (no matter whether we group according to scene, CSE, ADE or whate= ver). But, again, that is mainly a coding issue. > > There are multiple potential issues, some more severe than others. I'm no= t sure which you are concerned with. E.g. > > - the size of the advertisement > > - the complexity of constructing the advertisement > > - complexity of *algorithm* for analyzing an advertisement > and automatically choosing a configuration > > - complexity of *algorithm* for analyzing an advertisement > and constructing a menu of viable alternative configurations > for an end user to choose among > > But IMO what I'm proposing will simplify the configuration algorithms for= automatic selection of config, may increase the size of the advertisement = a bit, and is probably neutral for construction of the advertisement. > >> Another issue is, as indicated above, I see no need for mixing together = scenes. > > The reason is because the rendering of them will be mixed. The resources = used to render them can often be used for captures from different=20 > scenes. Mixing them gives a convenient way for the advertiser to recommen= d potential viable tradeoffs and priorities. What simplifies the configuration is providing good information (using scen= e/capture attributes etc) about what each scene contains, and what individu= al captures contain, so that the receiver can choose based on its capabilit= ies etc. Regards, Christer From christer.holmberg@ericsson.com Thu Dec 20 04:56: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 EC75A21F87AC for ; Thu, 20 Dec 2012 04:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ag92tx22KnT3 for ; Thu, 20 Dec 2012 04:56:26 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4EB21F8920 for ; Thu, 20 Dec 2012 04:56:25 -0800 (PST) X-AuditID: c1b4fb30-b7f736d0000010de-86-50d30af8fe20 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2D.A1.04318.8FA03D05; Thu, 20 Dec 2012 13:56:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 13:56:24 +0100 From: Christer Holmberg To: Christian Groves , Paul Kyzivat Thread-Topic: [clue] Some thoughts about CLUE signaling Thread-Index: AQHN3WRT2kf/7WyheUGkLxz7xnd8QZgfLCYAgAJ1bIA= Date: Thu, 20 Dec 2012 12:56:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B06E7D5@ESESSMB209.ericsson.se> References: <50D0DC1B.7060100@alum.mit.edu> <50D1039A.8090300@nteczone.com> In-Reply-To: <50D1039A.8090300@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje5PrssBBv8fcll8ed/IYrH/1GVm ixUbDrA6MHv8ff+ByWPJkp9MHivOz2QJYI7isklJzcksSy3St0vgyrhy9TlzwTXdig0XdjI1 MO5V6WLk5JAQMJF4caKVHcIWk7hwbz1bFyMXh5DAIUaJGbOWMkE4ixklpp5bztrFyMHBJmAh 0f1PG6RBRCBGYvmhPkYQm1lAQmLVxQ9gtrCAmcTsvcvYIGrMJb5/vsAEYVtJLH5+DsxmEVCV WHj+EBPISF4Bb4m9P9xAwkJA5uk9T1hAbE4BHYmbUz6AjWEEuu37qTVMEKvEJW49mc8EcbOA xJI955khbFGJl4//gV0pIaAosbxfDqJcR2LB7k9sELa2xLKFr8HKeQUEJU7OfMIygVFsFpKp s5C0zELSMgtJywJGllWM7LmJmTnp5eabGIExc3DLb4MdjJvuix1ilOZgURLnDXe9ECAkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBUeeK+LEnqTlFMfHdnNuzzq7wPfxo68nA2dyf5xpEHlkn 6rlf0uz2E8fU2z+vZHyxc3t+jZ9f1b3jMP+mr39lFt/+OlcpOVkkt/eojbj8rDkHcm+Xxi3g 3fYzb/dO9g1HZXdfv7nsn9c+x4wJoTerp3Ur5xqePSL6surM26OfuZlZU76zM18xs1FiKc5I NNRiLipOBABSfwK/ZwIAAA== Cc: CLUE Subject: Re: [clue] Some thoughts about CLUE signaling 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, 20 Dec 2012 12:56:28 -0000 Hi, Below is an attempt to structure the bullets in Paul's list: Q1: The initial SDP offer/answer and establishment of the CLUE channel: This is bullet 2) in Paul's list, and based on my suggestion to specify how= such SDP offer will look like, that also covers interop with legacy SIP de= vices (bullet 5). (Assuming we will use offer/answer to establish the CLUE channel, I assume = we will also use offer/answer to remove it, by setting the port to zero for= the m- line associated with the CLUE channel). Q2: The advertisements, configurations and additional SDP offer/answers in = order to establish the CLUE session: This covers bullets 1) and 3) in Paul's list. Bullet 4) is perhaps not a standalone task, but will need to be considered = in other bullets. I really don't think we have to think about RTCWEB at this point, because t= here is still lots to do in that area before we can even do something usefu= l. Q3: Mid-session acknowledgements/configurations This covers bullet 1). In general I also think it's good to acknowledge a new advertisement with a= configuration.=20 However, I think mid-session acknowledgements will be EXTREMELY rare, so I = would even suggest to leave that for now and focus on the session establish= ment. Mid-session configurations might be a little more common, e.g. if a receive= r wants to switch from a capture of Paul to a capture of Christian. But, as= suming the original advertisement contained the captures for both Paul and = Christian, no new advertisement is needed for that. A new SDP offer/answer = might also be needed, if the capture switch has impact on the SDP. Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= istian Groves Sent: 19. joulukuuta 2012 2:00 To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] Some thoughts about CLUE signaling Hello Paul, Please see my comments below. Regards, Christian ..snip.. > > First, we need to agree on what is included in the subject "clue=20 > signaling". I consider all of the following are aspects/dimensions to=20 > the subject: > > 1) the clue-specific signaling protocol > a) the messages: advertisement, configure, ack?, nak? > b) the payload of advertisement & configure (from data model) > c) sequencing of clue messages, state machines > 2) clue use of SDP O/A, including establishment of clue message=20 > channel [CNG] Need to consider removal of clue channel? > 3) linkage & sequencing of clue-specific messages and SDP O/A > 4) sip signaling (this may be unremarkable) > 5) interop with legacy SIP devices > 6) clue over RTCWEB [CNG] I would also add to the list clue interaction with any call / bearer = release/teardown. Also "in session" modification is something also to cover= . > > I expect that the clue signaling document will cover all of these=20 > subjects. (Perhaps with the exception of RTCWEB.) I have no strong=20 > preference at this time about the document structure to cover these. > > I have thought some about the sequencing of clue messages. The=20 > following are some thoughts on that. These may be entirely obvious to=20 > everyone. (If so, hurray!) But I'll have a better idea after everyone=20 > concurs, or not. > > - media for a capture encoding will not be sent unless it has > been configured. (Exception: prior to first adv/cfg exchange, > which includes compatibility with non-clue endpoints.) > > - a capture must be advertised before it can be configured. > (This is fundamental, the config must reference identifiers > from the advertisement for the capture & encoding.) > > - when a provider wishes to stop sending a capture encoding that has > been configured, it *should* *first* send a new advertisement > that no longer advertises that capture and/or encoding, and should > wait for that advertisement to be acknowledged. [CNG] How does this relate to any call bearer / release signalling? > > - if a provider must stop sending a capture encoding before advertising > that it is not available, it *must* still send an advertisement > indicating this at the first opportunity. > (Until it gets this, the consumer is likely to treat the > missing capture encoding as an error, giving a poor user=20 > experience.) [CNG] Assuming that the CLUE channel is still up? > > - when a consumer receives a new advertisement that no longer > offers a capture and/or encoding that is currently configured, > that is an indication that the capture is no longer available and will > most likely no longer be sent. The consumer should not > consider it an error when that capture encoding is no longer received. [CNG] I guess its important to understand what that then means for SIP/ SDP= OA signalling. Its one thing to say not an error but should it trigger som= e signalling. > > > - when a consumer receives a new advertisement, it *should* > send a new configuration asap that is consistent with the > new advertisement. This means it references the new > advertisement and it configures only captures and encodings > mentioned in that advertisement. [CNG] The current framework says that this is not necessary. A new=20 configuration is only sent if the old configuration is invalid. From a=20 protocol perspective I think its good practise to send an=20 acknowledgement but the transport may give that indication. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Dec 20 07: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 8300821F895D for ; Thu, 20 Dec 2012 07:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFuFyF+5lta3 for ; Thu, 20 Dec 2012 07:49:25 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 5B64E21F8623 for ; Thu, 20 Dec 2012 07:49:25 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta02.westchester.pa.mail.comcast.net with comcast id dn131k0071ei1Bg51rpQye; Thu, 20 Dec 2012 15:49:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id drpP1k00a3ZTu2S3krpQJ9; Thu, 20 Dec 2012 15:49:24 +0000 Message-ID: <50D33383.30904@alum.mit.edu> Date: Thu, 20 Dec 2012 10:49:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it>, <50CF52E9.8000302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0689A1@ESESSMB209.ericsson.se>, <50CF7410.8010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0694D5@ESESSMB209.ericsson.se> <50CF9622.6090306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B06C6BC@ESESSMB209.ericsson.se> <50D1EE7B.1010002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B06E79B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B06E79B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1356018564; bh=Imm6OTwwcQH0ebh4cLF7IXHl8NUEKCScUHYb3bLM+Gw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MbpHG6pC2qDh9bchkBzL+a9g3QTAECY2OA3xa36oi74uyN3bOnS20OhTGbvfgWLu+ wWwMEwFItXebX2cSLSAYeghRAPKI6tsfEEpNSV7Zc8Isn20Bnlev+uGyoF2tUnlAhn Omj72865/kETSoJTAE5099X7FnbqUrWKS6aLh9vBDTyyIWwzrBaYKUD34+VZQ/iwU3 4N4f/a529pfofurgBvCj1win330/OhHQAk4mZdo26WovROBEhat/89EBJDjILxnhLM GNQ6jK2Cj96J9YqYbjJR6ARsHma9zu2zm2/+WSCHnhXv2QsYZSfMf884C/ZPZMzFQX pFW9UcTCWgYJA== Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 20 Dec 2012 15:49:26 -0000 On 12/20/12 7:30 AM, Christer Holmberg wrote: > Hi, > >>>>>> >>>>>> >>>>>> (descriptive info for the scene) >>>>>> (descriptive info for the scene) >>>>>> ... >>>>>> >>>>>> >>>>>> ... >>>>>> ... >>>>>> ... >>>>>> ... >>>>>> ... >>>>>> ... >>>>>> ... >>>>>> >>>>>> >>>>>> f1,f2,b1,b2 >>>>>> f3,b1,b2 >>>>>> f1,f2,b3 >>>>>> f3,b3 >>>>>> b3 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Here, you can think that f3 is a composite of f1 & f2, and b3 is a >>>>>> composite of b1 and b2. Perhaps scene foo is a room, and scene bar >>>>>> contains a couple of presentations. >>>>>> >>>>>> This explicitly allows the advertiser to think about and propose >>>>>> tradeoffs between scenes. So a5 makes the decision that if you can >>>>>> only receive one capture you are better off getting the >>>>>> presentation than the room. >>>>> >>>>> I think it's quite strange if the advertiser starts to advertise "partly scenes", trying to figure out what the receiver may want, and trying to figure out what the capabilities of the receiver are. >>>> >>>> Isn't that what CSEs already do? >>>> >>>> Isn't it generally expected that CSEs will differ in the number of captures they include, so that they can accommodate consumers that can handle only a limited number of captures? >>> >>> Yes, the number of captures will differ. But, each CSE still represents a complete scene. >>> >>> Or, are you saying that f1 + f2 could be seen as one CSE for foo, and f3 as another CSE for foo (and, the same for b1 + b2 and b3)? >> >> Yes, that is exactly what I meant. If the same case were done with CSEs it would be that way. > > In your example, you seem to assume that the receiver wants to receive both scenes (unless it can only receive one). But, maybe the receiver chooses (based on whatever logic) to only receive the "b scene", but still using captures b1 and b2 (and not b3). There is no ADE for that alternative. > > The advertiser needs to provide information on what each scene contains, one or more CSEs for each scene, and then let the receiver choose what it wants. Either way, IMO the receiver should have the option to request what captures it wants. So if it really wants b1 and b2 it is certainly free to do so. What the CSEs (or ADEs in my proposal here) are *recommendations* from the provider of choices that will provide satisfactory user experience for the resources they consume. >>>> What I have suggested continues that, and extends it to cover multiple scenes. >>> >>> My preference would still be to keep scenes separated from each other. The receiver will then, for each scene it wants, choose the scene alternative (CSE) based on its capabilities etc. >> >> I'm trying to discuss the pros/cons on a basis other than mere "preference". > > I think it's a pro allowing the receiver to choose what it wants to receive, rather than having the provider trying to figure it out. The provider should provide good enough information, allowing the receiver to make the decisions. The two proposals can provide the receiver with an equal amount of choice. It is only the hinting/recommendations that are different. >>>> I guess the controversial part in my example is ADE a5, that omits >>>> any content from scene foo. It has made a value judgement that >>>> omitting all of foo is still a valid representation of the advertisement. (It might be clearer if we >>>> had both audio and video, and it retained audio from foo but not video.) And it might be that in some cases this wouldn't be included in the advertisement because it wouldn't be sufficient. >>>> >>>>> My preference is still that we don't need to advertise scene >>>>> trade-offs. Instead the advertiser provides full scene alternatives (CSEs), and let the receiver choose which scene(s) (and associated CSEs), it wants to receive. >>>> >>>> I've been talking about this for months. I agree that ultimately it >>>> is the recipient that makes the final decision. But can be very hard >>>> - the receiver has limited info to make the decision. This can be partly solved by extensions to capture attributes, such as >>>> Christian has proposed. Including a priority attribute, where priorities have significance across scenes, provide another way to accomplish the same thing. >>> >>> Yes. No matter which way we go, I think the attribute is needed. >> >> Yes, I think so too. But in many cases the attributes will only help a human make a manual decision - not sufficient to make an >> automated decision. The CSEs/ADEs lend themselves better to automated selection. It is particularly hard to make a tradeoff >> if you can't handle a full CSE from each Scene. > > Your "boss" use-case is an example where a manual decision will be needed. > > But, in case of automated selections, I think the receiver in most cases will try to get a full scene. The provider will need to provide different alternatives (CSEs) for each scene, and if nothing else works then the receiver probably chooses a CSE containing a single capture for the whole scene (or, it chooses specific captures of a CSE based on e.g. spatial information). I agree with everything you say in the sentence above. But that only discusses one scene. And in this the provider can help by ensuring that there is at least one CSE for the scene that requires only a single display. But the problem is greater when there is more than one scene. Even if each scene has a CSE that requires a single capture, that means the minimum number of screens needed to render the full advertisement will be equal to the number of screens. (Unless you do local composition or switching.) That presents a problem to a receiver that doesn't have that many screens. It is very hard for an algorithm to decide that one of the scenes is less important than the other, unless the attributes give the provider's assessment of the relative priorities. What my ADE proposal does is give the provider a mechanism to recommend tradeoffs between captures in different scenes in order to offer combinations that require fewer screens. >>>> Aside from being *different* from what we have assumed for a long time, do you see something that makes my proposal worse than having separate CSEs for each scene? >>> >>> One issue is that same as I have had previously: by listing captures, and then having the receiver figure out where they >>> belong (no matter whether we group according to scene, CSE, ADE or whatever). But, again, that is mainly a coding issue. >> >> There are multiple potential issues, some more severe than others. I'm not sure which you are concerned with. E.g. >> >> - the size of the advertisement >> >> - the complexity of constructing the advertisement >> >> - complexity of *algorithm* for analyzing an advertisement >> and automatically choosing a configuration >> >> - complexity of *algorithm* for analyzing an advertisement >> and constructing a menu of viable alternative configurations >> for an end user to choose among >> >> But IMO what I'm proposing will simplify the configuration algorithms for automatic selection of config, may increase the size of the advertisement a bit, and is probably neutral for construction of the advertisement. >> >>> Another issue is, as indicated above, I see no need for mixing together scenes. >> >> The reason is because the rendering of them will be mixed. The resources used to render them can often be used for captures from different >> scenes. Mixing them gives a convenient way for the advertiser to recommend potential viable tradeoffs and priorities. > > What simplifies the configuration is providing good information (using scene/capture attributes etc) about what each scene contains, and what individual captures contain, so that the receiver can choose based on its capabilities etc. We *could* simply advertise the captures and attributes of the captures, without any CSEs. Then let the receiver make its own tradeoffs based on the attributes. I view the CSEs as simply another form of attributes describing the captures - a hint of which combinations might provide a satisfactory user experience. So ultimately we are just discussing what representation of provider knowledge about the captures will best help the receiver make a good choice. And my point is that if the provider has knowledge that can help in making tradeoffs between captures in different scenes, then it is good to have that. Thanks, Paul From ron.even.tlv@gmail.com Thu Dec 20 14:35: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 A391D21F8931 for ; Thu, 20 Dec 2012 14:35:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8hJZIbAqShi for ; Thu, 20 Dec 2012 14:35:32 -0800 (PST) Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE2B21F8A95 for ; Thu, 20 Dec 2012 14:35:31 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id h11so1582153eaa.20 for ; Thu, 20 Dec 2012 14:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=AGAj4yLvBfc1DiNEdBfzLo7V4PefsANtp2j/V8UNknU=; b=j4dJTB19TsLFKUVYT7sDoCo6NFx3c8EwFHQnpnrXT2BT17S6/lN/p4p3vLVIluu+F1 3yCu5YiWwL82T79iRnAySGNJWOyXjDHjinoBdFGDk/IVjGBVXXYkgAycEyTwoog5hA+e KKzLpDZ67Ge+DjoBzS1h6u/V3VQ9spCNwyR8qIlsZWnaHGc82MAQ9aNcIt5FJcjEcxTf KIZrzNgf6xZFReIAu+/+YTJBINOL9VoSpjH67eSsZbShmWbMtytiUEMf6/U+Ugt4z4/u ksmoc0nluyQS8EZ4zM0iPVwT7BZvRh35YSbYVgMsOgc7WqZXN8fbPQ+a940BF+DVXpmo qMWQ== X-Received: by 10.14.221.9 with SMTP id q9mr26912742eep.3.1356042930489; Thu, 20 Dec 2012 14:35:30 -0800 (PST) Received: from RoniE (bzq-79-176-185-176.red.bezeqint.net. [79.176.185.176]) by mx.google.com with ESMTPS id r1sm18022788eeo.2.2012.12.20.14.35.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 14:35:28 -0800 (PST) From: "Roni Even" To: "'Paul Kyzivat'" , References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> In-Reply-To: <50CA4537.80907@alum.mit.edu> Date: Fri, 21 Dec 2012 00:32:42 +0200 Message-ID: <04c301cddf01$ef11e0a0$cd35a1e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEkbjq3U4NnLY/aQKp9c6xQM9CTPwH5kkWAAVzYh/CZWnLRAA== Content-Language: en-us Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 20 Dec 2012 22:35:32 -0000 Hi, We had this discussion from the start. My view is that the capture scene entry advertisement provides the recommended option based on the provider thought about the consumer. Still the consumer may want to have part of a capture scene entry or any allowed set based on the simultaneous sets since the consumer may have a different architecture that is not a good match for any of the proposed capture scene entries. As long as we do not have a way to describe the consumer capabilities this approach will allow him to ask for a better configuration. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 13 December, 2012 11:15 PM To: clue@ietf.org Subject: [clue] Can receiver select captures from more than one capture scene entry? The "Capture scene clarifications" topic has been *very* popular, and is getting confusing. Here I've changed the subject line to focus on one point - a change that was been proposed by Christer. The latest description of it was from Christian Groves: >> "A consumer may receive an advertisement with multiple capture scenes. >> A consumer may choose to receive any number of capture scenes. An >> advertised capture scene it may contain one of more capture scene >> entries that may contain one of more media captures. A consumer may >> choose an capture scene entry in the knowledge that it is a complete >> representation of the scene for a particular media type and that all >> media captures are spatially related. For a particular media type the >> consumer shall choose one capture scene entry rather than choosing >> individual captures from multiple capture scene entries. However this >> does not mean that a consuming endpoint must render all the media >> captures. What is locally rendered and how is a local decision." There have been some suggestions that this could also eliminate the need for simultaneous sets, because the scene entries would *be* the simultaneous sets. I'm not sure if that is an integral part of this proposal or not. (If it is, then it provides part of the justification. Without this part I'm not sure what the benefit is.) I am inclined to agree that a new definition of advertisement and configuration could be built around such a concept. But to do so I think somebody will need to work out all the details. For instance: - can the same capture be in more than one capture scene entry? - how does the configure message specify which entries it wants, and which captures from those entries? IMO the existing (prior?) model was at least clearer, and arguably simpler. The way I have been thinking of it: - an advertisement advertises a bunch of captures, and information about those captures to help the receiver decide which ones it wants and how it should render them. - scenes, scene entries, simultaneous sets, are all just pieces of that descriptive info. - a configuration is simple - it only needs to enumerate the captures that it wants. It need not mention scenes or scene entries. (It might need to identify scenes if the capture ids are scoped to a scene.) The proposed changes would make the configuration message more complex. The receiver would need to enumerate the desired scene entries. And for each selected scene entry, identify those captures that are (or are not) desired. So, IMO, if some people are interested in this new approach, I suggest they work on a detailed proposal for how it would work, and then do a full assessment of the pros/cons relative to the existing proposal. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Thu Dec 20 14:55:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01FD21F8A8F for ; Thu, 20 Dec 2012 14:55:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iN-AWV3iT80 for ; Thu, 20 Dec 2012 14:55:34 -0800 (PST) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by ietfa.amsl.com (Postfix) with ESMTP id 70F5421F8A57 for ; Thu, 20 Dec 2012 14:55:32 -0800 (PST) Received: by mail-ea0-f170.google.com with SMTP id d11so1581294eaa.15 for ; Thu, 20 Dec 2012 14:55:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=pxJZY6sCJ6Dh3PxbHre7A2WJ0cs+MWkqvY0cVqGoKGU=; b=0r3zIg4jiYPiE+5S3kxF0HKWzP+EZSaB6sD5cE+IVDDGnKMJsCvkB/KSkAmDM8idSE 4wdFSiXfNZg6TzNL39RjF719rfkIsKc5tN2hGbhfDCZdqabuCEH/5k+3Il0SxjvWgc5o bGtGUR2b209Pa2vl/Rk3ulY6L30Q/vuK5vvpbgUMV3VZHlM3M+T+PtffUrZfSsc7yGhi /ZM15LO8os8Ie4orXawWeQuKzndx/JdBGTDHGbynFZDzy7wLz0mF+hvQcO9Qego5pvZU p1cVDVHsP0J50ivzpoKjE7a7vOFu253eZErSmoIbw2xFMqkjuVDvtjQV+sVvSXl1qmG5 hB3g== X-Received: by 10.14.173.65 with SMTP id u41mr26663902eel.13.1356044131396; Thu, 20 Dec 2012 14:55:31 -0800 (PST) Received: from RoniE (bzq-79-176-185-176.red.bezeqint.net. [79.176.185.176]) by mx.google.com with ESMTPS id k4sm18097052eep.15.2012.12.20.14.55.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 14:55:30 -0800 (PST) From: "Roni Even" To: "'Paul Kyzivat'" , References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> In-Reply-To: <50CA4537.80907@alum.mit.edu> Date: Fri, 21 Dec 2012 00:52:43 +0200 Message-ID: <04c401cddf04$bb4ef6b0$31ece410$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEkbjq3U4NnLY/aQKp9c6xQM9CTPwH5kkWAAVzYh/CZWncssA== Content-Language: en-us Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 20 Dec 2012 22:55:35 -0000 Hi, Here is an example from the framework that can demonstrate the need for selecting part of capture set entry and captures from multiple capture set entries These are the capture scene entries: 1. (VC0, VC1, VC2) - left, center and right camera video captures 2. (VC3) - video capture associated with loudest room segment 3. (VC4) - video capture zoomed out view of all people in the room The simultaneous sets is (VC0,VC1,VC2,VC3) - since the loudest speaker is one of VC0, VC1 or VC2 (VC0, VC3, VC2) - the middle camera is used for zoom out view. Now an MCU may want to get (VC0, VC1, VC2 , VC3) and switch to one monitor systems VC3 and to the 3 monitor systems (VC0,VC1,VC2) A two monitor system may want to receive (VC4, VC0) since the person using the system would like to have also a view of the left side of the room Again, My claim is that the configuration may be selected by the person/s using the system and the consumer endpoint can provide him with the allowed multiple choices allowing him to build the view he wants. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 13 December, 2012 11:15 PM To: clue@ietf.org Subject: [clue] Can receiver select captures from more than one capture scene entry? The "Capture scene clarifications" topic has been *very* popular, and is getting confusing. Here I've changed the subject line to focus on one point - a change that was been proposed by Christer. The latest description of it was from Christian Groves: >> "A consumer may receive an advertisement with multiple capture scenes. >> A consumer may choose to receive any number of capture scenes. An >> advertised capture scene it may contain one of more capture scene >> entries that may contain one of more media captures. A consumer may >> choose an capture scene entry in the knowledge that it is a complete >> representation of the scene for a particular media type and that all >> media captures are spatially related. For a particular media type the >> consumer shall choose one capture scene entry rather than choosing >> individual captures from multiple capture scene entries. However this >> does not mean that a consuming endpoint must render all the media >> captures. What is locally rendered and how is a local decision." There have been some suggestions that this could also eliminate the need for simultaneous sets, because the scene entries would *be* the simultaneous sets. I'm not sure if that is an integral part of this proposal or not. (If it is, then it provides part of the justification. Without this part I'm not sure what the benefit is.) I am inclined to agree that a new definition of advertisement and configuration could be built around such a concept. But to do so I think somebody will need to work out all the details. For instance: - can the same capture be in more than one capture scene entry? - how does the configure message specify which entries it wants, and which captures from those entries? IMO the existing (prior?) model was at least clearer, and arguably simpler. The way I have been thinking of it: - an advertisement advertises a bunch of captures, and information about those captures to help the receiver decide which ones it wants and how it should render them. - scenes, scene entries, simultaneous sets, are all just pieces of that descriptive info. - a configuration is simple - it only needs to enumerate the captures that it wants. It need not mention scenes or scene entries. (It might need to identify scenes if the capture ids are scoped to a scene.) The proposed changes would make the configuration message more complex. The receiver would need to enumerate the desired scene entries. And for each selected scene entry, identify those captures that are (or are not) desired. So, IMO, if some people are interested in this new approach, I suggest they work on a detailed proposal for how it would work, and then do a full assessment of the pros/cons relative to the existing proposal. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Fri Dec 21 04:36: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 A77B921F889C for ; Fri, 21 Dec 2012 04:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx6+XlNa4h6v for ; Fri, 21 Dec 2012 04:36:08 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D4BA621F8816 for ; Fri, 21 Dec 2012 04:36:07 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-5f-50d457b576eb Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DF.54.10459.5B754D05; Fri, 21 Dec 2012 13:36:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 13:36:04 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [clue] Can receiver select captures from more than one capture scene entry? Thread-Index: AQHN3Hn0g7YsKnVso0yin5dQG9gVdZgdUFyKgAABVQCAACDqKoAAB7MAgAJCSMCAAIlkgIABPrJQgABExoCAAUpH8A== Date: Fri, 21 Dec 2012 12:36:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B06F158@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0633AF@ESESSMB209.ericsson.se> <367B869C-9E87-48F9-AB2E-9C91035A04AB@unina.it>, <50CF52E9.8000302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0689A1@ESESSMB209.ericsson.se>, <50CF7410.8010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0694D5@ESESSMB209.ericsson.se> <50CF9622.6090306@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B06C6BC@ESESSMB209.ericsson.se> <50D1EE7B.1010002@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B06E79B@ESESSMB209.ericsson.se> <50D33383.30904@alum.mit.edu> In-Reply-To: <50D33383.30904@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje7W8CsBBo/2alnsP3WZ2WLFhgOs FtvabjA7MHv8ff+ByWPJkp9MHj+2PGUKYI7isklJzcksSy3St0vgyui7rVdwKLTi2Kpt7A2M LS5djJwcEgImEg3TzrFA2GISF+6tZ+ti5OIQEjjEKNFw8wYLhLOYUWL5n1bGLkYODjYBC4nu f9ogpoiAhsSkrWogvcwCPhKPX89iBLGFBaIkDm38ywpiiwhES7xceZ0Jws6SaLo6FWwXi4Cq xNQzy4Dq2Tl4BbwlfiRBLNrMKrHkRS9YK6eAlsS1S3vAbEag076fWsMEsUpc4taT+UwQJwtI LNlznhnCFpV4+fgfK8hlEgKKEsv75SDKdSQW7P7EBmFrSyxb+BqsnFdAUOLkzCcsExjFZiGZ OgtJyywkLbOQtCxgZFnFyJ6bmJmTXm64iREYLwe3/NbdwXjqnMghRmkOFiVx3jDXCwFCAumJ JanZqakFqUXxRaU5qcWHGJk4OKUaGEWW/poX31n8smwm4yWFlOsfbHYX/yxkUWOc8PNeiYTz tgaF6UH/l+qLxmpVtM/pXtpqtdf2iUlugW6jiod1+0b2phyhmcveTCmpnXd6e2bJOgkJ7zXb u6dLf/p+NYhTJTrwxMsN79niu5L2Zv7LiMhyXxfx/P2klx+0KqMXyG5I+aS7sflinRJLcUai oRZzUXEiACImCaFlAgAA Cc: "clue@ietf.org" Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 21 Dec 2012 12:36:09 -0000 Hi, >>>>>>> >>>>>>> >>>>>>> (descriptive info for the scene) >>>>>>> (descriptive info for the scene) >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> ... >>>>>>> ... >>>>>>> ... >>>>>>> ... >>>>>>> ... >>>>>>> ... >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> f1,f2,b1,b2 >>>>>>> f3,b1,b2 >>>>>>> f1,f2,b3 >>>>>>> f3,b3 >>>>>>> b3 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Here, you can think that f3 is a composite of f1 & f2, and b3 is=20 >>>>>>> a composite of b1 and b2. Perhaps scene foo is a room, and scene=20 >>>>>>> bar contains a couple of presentations. >>>>>>> >>>>>>> This explicitly allows the advertiser to think about and propose=20 >>>>>>> tradeoffs between scenes. So a5 makes the decision that if you=20 >>>>>>> can only receive one capture you are better off getting the=20 >>>>>>> presentation than the room. >>>>>> >>>>>> I think it's quite strange if the advertiser starts to advertise "pa= rtly scenes", trying to figure out what the receiver may want, and trying t= o figure out what the capabilities of the receiver are. >>>>> >>>>> Isn't that what CSEs already do? >>>>> >>>>> Isn't it generally expected that CSEs will differ in the number of ca= ptures they include, so that they can accommodate consumers that can handle= only a limited number of captures? >>>> >>>> Yes, the number of captures will differ. But, each CSE still represent= s a complete scene. >>>> >>>> Or, are you saying that f1 + f2 could be seen as one CSE for foo, and = f3 as another CSE for foo (and, the same for b1 + b2 and b3)? >>> >>> Yes, that is exactly what I meant. If the same case were done with CSEs= it would be that way. >> >> In your example, you seem to assume that the receiver wants to receive b= oth scenes (unless it can only receive one). But, maybe=20 >> the receiver chooses (based on whatever logic) to only receive the "b sc= ene", but still using captures b1 and b2 (and not b3). There=20 >> is no ADE for that alternative. >> >> The advertiser needs to provide information on what each scene contains,= one or more CSEs for each scene, and then let the receiver choose what it = wants. > > Either way, IMO the receiver should have the option to request what captu= res it wants. So if it really wants b1 and b2 it is certainly free to do so= . > > What the CSEs (or ADEs in my proposal here) are *recommendations* from th= e provider of choices that will provide satisfactory user experience for th= e resources they consume. I don't agree that a CSE is a recommendation. A CSE is a technical descript= ion for providing a full scene. >>>>>> What I have suggested continues that, and extends it to cover multip= le scenes. >>>>> >>>>> My preference would still be to keep scenes separated from each other= . The receiver will then, for each scene it wants, choose the scene alterna= tive (CSE) based on its capabilities etc. >>>>> >>>>> I'm trying to discuss the pros/cons on a basis other than mere "prefe= rence". >>>> >>>> I think it's a pro allowing the receiver to choose what it wants to re= ceive, rather than having the provider trying to figure it out. The provide= r should provide good enough information, allowing the receiver to make the= decisions. >>>> >>> The two proposals can provide the receiver with an equal amount of choi= ce. It is only the hinting/recommendations that are different. >> >>>>>> I guess the controversial part in my example is ADE a5, that omits=20 >>>>>> any content from scene foo. It has made a value judgement that=20 >>>>>> omitting all of foo is still a valid representation of the=20 >>>>> advertisement. (It might be clearer if we had both audio and video, a= nd it retained audio from foo but not video.) And it might be that in some = cases this wouldn't be included in the advertisement because it wouldn't be= sufficient. >>>>> >>>>>> My preference is still that we don't need to advertise scene=20 >>>>>> trade-offs. Instead the advertiser provides full scene alternatives = (CSEs), and let the receiver choose which scene(s) (and associated CSEs), i= t wants to receive. >>>>> >>>>> I've been talking about this for months. I agree that ultimately it=20 >>>>> is the recipient that makes the final decision. But can be very=20 >>>>> hard >>>>> - the receiver has limited info to make the decision. This can be=20 >>>>> partly solved by extensions to capture attributes, such as Christian = has proposed. Including a priority attribute, where priorities have signifi= cance across scenes, provide another way to accomplish the same thing. >>>> >>>> Yes. No matter which way we go, I think the attribute is needed. >>> >>> Yes, I think so too. But in many cases the attributes will only help=20 >>> a human make a manual decision - not sufficient to make an automated=20 >>> decision. The CSEs/ADEs lend themselves better to automated selection. = It is particularly hard to make a tradeoff if you can't handle a full CSE f= rom each Scene. >> >> Your "boss" use-case is an example where a manual decision will be neede= d. >> >> But, in case of automated selections, I think the receiver in most cases= will try to get a full scene. The provider will need to provide different= =20 >> alternatives (CSEs) for each scene, and if nothing else works then the r= eceiver probably chooses a CSE containing a single capture for the whole=20 >> scene (or, it chooses specific captures of a CSE based on e.g. spatial i= nformation). > > I agree with everything you say in the sentence above. But that only disc= usses one scene. And in this the provider can help by ensuring that there i= s at least one CSE for the scene that requires only a single display. The provider can do that by providing a CSE with a single capture. > But the problem is greater when there is more than one scene. Even if eac= h scene has a CSE that requires a single capture, that means the=20 > minimum number of screens needed to render the full advertisement will be= equal to the number of screens. (Unless you do local composition or > switching.) That presents a problem to a receiver that doesn't have that = many screens. > > It is very hard for an algorithm to decide that one of the scenes is less= important than the other, unless the attributes give the provider's assess= ment=20 > of the relative priorities. What my ADE proposal does is give the provide= r a mechanism to recommend tradeoffs between captures in different scenes=20 > in order to offer combinations that require fewer screens. CSEs give you the same options, because they can provide the scene with dif= ferent number of captures etc. And, if the receiver can only choose one sce= ne, it chooses the one it thinks is most important. There needs to be some information associated with each scene, what it repr= esents. In typical scenarios there will be two scenes, a "main" scene, and a "prese= ntation" scene, so there is no need for a complex algorithm.=20 >>>>> Aside from being *different* from what we have assumed for a long tim= e, do you see something that makes my proposal worse than having separate C= SEs for each scene? >>>> >>>> One issue is that same as I have had previously: by listing=20 >>>> captures, and then having the receiver figure out where they belong (n= o matter whether we group according to scene, CSE, ADE or whatever). But, a= gain, that is mainly a coding issue. >>> >>> There are multiple potential issues, some more severe than others. I'm = not sure which you are concerned with. E.g. >>> >>> - the size of the advertisement >>> >>> - the complexity of constructing the advertisement >>> >>> - complexity of *algorithm* for analyzing an advertisement >>> and automatically choosing a configuration >>> >>> - complexity of *algorithm* for analyzing an advertisement >>> and constructing a menu of viable alternative configurations >>> for an end user to choose among >>> >>> But IMO what I'm proposing will simplify the configuration algorithms f= or automatic selection of config, may increase the size of the advertisemen= t a bit, and is probably neutral for construction of the advertisement. >>> >>>> Another issue is, as indicated above, I see no need for mixing togethe= r scenes. >>> >>> The reason is because the rendering of them will be mixed. The=20 >>> resources used to render them can often be used for captures from diffe= rent scenes. Mixing them gives a convenient way for the advertiser to recom= mend potential viable tradeoffs and priorities. >> >> What simplifies the configuration is providing good information (using s= cene/capture attributes etc) about what each scene contains, and what indiv= idual captures contain, so that the receiver can choose based on its capabi= lities etc. > > We *could* simply advertise the captures and attributes of the captures, = without any CSEs. Then let the receiver make its own tradeoffs based on the= attributes. The advantage of CSEs is that we don't need simultaneous capture sets. ...and, the receiver does not need to parse and generate the CSEs itself. I= t may not be a problem when there is only one alternative for providing a s= cene, but if there are many alternatives the receiver needs to figure out b= oth which scene each capture belongs to, but also which captures are needed= in order to receive a full scene. > I view the CSEs as simply another form of attributes describing the captu= res - a hint of which combinations might provide a satisfactory user experi= ence. > > So ultimately we are just discussing what representation of provider know= ledge about the captures will best help the receiver make a good=20 > choice. And my point is that if the provider has knowledge that can help = in making tradeoffs between captures in different scenes, then it is good t= o have that. Again, I don't view them as a hint or recommendation. They describe how a f= ull scene can be provided, using a particular number of captures etc. So, we do need some kind of "scene attribute". And, in some cases we also n= eed a "capture attribute", e.g. if a capture is associated with a given ind= ividual. Regards, Christer From christer.holmberg@ericsson.com Fri Dec 21 04:40: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 E8E5A21F8816 for ; Fri, 21 Dec 2012 04:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ssm56tjbCpUx for ; Fri, 21 Dec 2012 04:40:37 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 913B321F8753 for ; Fri, 21 Dec 2012 04:40:36 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-2d-50d458c36b27 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0C.35.10459.3C854D05; Fri, 21 Dec 2012 13:40:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.43]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 13:40:35 +0100 From: Christer Holmberg To: Roni Even , 'Paul Kyzivat' , "clue@ietf.org" Thread-Topic: [clue] Can receiver select captures from more than one capture scene entry? Thread-Index: AQHN3wUheL01/r97mU2e7MNvwqPLGpgjMisQ Date: Fri, 21 Dec 2012 12:40:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B06F193@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <04c401cddf04$bb4ef6b0$31ece410$@gmail.com> In-Reply-To: <04c401cddf04$bb4ef6b0$31ece410$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvje7hiCsBBjsm61vsP3WZ2WLFhgOs Fn/bmR2YPf6+/8DksXPWXXaPJUt+MgUwR3HZpKTmZJalFunbJXBlLOvfx1jQr14x8+9dpgbG NfJdjJwcEgImEi3bm5ghbDGJC/fWs3UxcnEICRxilDg/7zAbSEJIYDGjxPO1VV2MHBxsAhYS 3f+0QcIiAoUSPa8fsYLYwgJREsfOrGeDiEdLHDz6BMo2kpj6p5EJxGYRUJXY/buLEcTmFfCW 2LC3jwli135GiZnbXrKDzOcEmr/8aCZIDSPQPd9PrQHrZRYQl7j1ZD4TxJ0CEkv2nIe6WVTi 5eN/rCCtEgKKEsv75SDKdSQW7P7EBmFrSyxb+JoZYq2gxMmZT1gmMIrOQjJ1FpKWWUhaZiFp WcDIsoqRPTcxMye93HATIzAyDm75rbuD8dQ5kUOM0hwsSuK8Ya4XAoQE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwejZrHW7suHJLO0f5YSjDgVVLnm/f87BliWF9Z5ChxPlTG+6oxkrvyrk1 PS077vZbxRiFPx+uRG2yiOlOk/PO1eEvSWd4olqkL2f6W1SrxdCch2v/WqOUle86E5smbjm5 fZ6RgZmkwKnqtCur4zbLW62fE5ZstE0gpVLe3ad0qkK8SIH6sl4lluKMREMt5qLiRACEWm/h WgIAAA== Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 21 Dec 2012 12:40:38 -0000 Hi, I thought each capture scene entry (CSE) represented the same scene. I gues= s 1) and 3) represents the same scene, but not 2) is only part of the same = scene. Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: 21. joulukuuta 2012 0:53 To: 'Paul Kyzivat'; clue@ietf.org Subject: Re: [clue] Can receiver select captures from more than one capture= scene entry? Hi, Here is an example from the framework that can demonstrate the need for sel= ecting part of capture set entry and captures from multiple capture set ent= ries These are the capture scene entries: 1. (VC0, VC1, VC2) - left, center and right camera video captures 2. (VC3) - video capture associated with loudest room segment 3. (VC4) - video capture zoomed out view of all people in the room The simultaneous sets is (VC0,VC1,VC2,VC3) - since the loudest speaker is one of VC0, VC1 or VC2 (VC= 0, VC3, VC2) - the middle camera is used for zoom out view. Now an MCU may want to get (VC0, VC1, VC2 , VC3) and switch to one monitor = systems VC3 and to the 3 monitor systems (VC0,VC1,VC2) A two monitor system may want to receive (VC4, VC0) since the person using = the system would like to have also a view of the left side of the room Again, My claim is that the configuration may be selected by the person/s u= sing the system and the consumer endpoint can provide him with the allowed = multiple choices allowing him to build the view he wants. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: 13 December, 2012 11:15 PM To: clue@ietf.org Subject: [clue] Can receiver select captures from more than one capture sce= ne entry? The "Capture scene clarifications" topic has been *very* popular, and is ge= tting confusing. Here I've changed the subject line to focus on one point - a change that wa= s been proposed by Christer. The latest description of it was from Christia= n Groves: >> "A consumer may receive an advertisement with multiple capture scenes= . >> A consumer may choose to receive any number of capture scenes. An=20 >> advertised capture scene it may contain one of more capture scene=20 >> entries that may contain one of more media captures. A consumer may=20 >> choose an capture scene entry in the knowledge that it is a complete=20 >> representation of the scene for a particular media type and that all=20 >> media captures are spatially related. For a particular media type the=20 >> consumer shall choose one capture scene entry rather than choosing=20 >> individual captures from multiple capture scene entries. However this=20 >> does not mean that a consuming endpoint must render all the media=20 >> captures. What is locally rendered and how is a local decision." There have been some suggestions that this could also eliminate the need fo= r simultaneous sets, because the scene entries would *be* the simultaneous = sets. I'm not sure if that is an integral part of this proposal or not. (If= it is, then it provides part of the justification.=20 Without this part I'm not sure what the benefit is.) I am inclined to agree that a new definition of advertisement and configura= tion could be built around such a concept. But to do so I think somebody wi= ll need to work out all the details. For instance: - can the same capture be in more than one capture scene entry? - how does the configure message specify which entries it wants, and which captures from those entries? IMO the existing (prior?) model was at least clearer, and arguably simpler. The way I have been thinking of it: - an advertisement advertises a bunch of captures, and information about those captures to help the receiver decide which ones it wants and how it should render them. - scenes, scene entries, simultaneous sets, are all just pieces of that descriptive info. - a configuration is simple - it only needs to enumerate the captures that it wants. It need not mention scenes or scene entries. (It might need to identify scenes if the capture ids are scoped to a scene.) The proposed changes would make the configuration message more complex.=20 The receiver would need to enumerate the desired scene entries. And for eac= h selected scene entry, identify those captures that are (or are not) desir= ed. So, IMO, if some people are interested in this new approach, I suggest they= work on a detailed proposal for how it would work, and then do a full asse= ssment of the pros/cons relative to the existing proposal. 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 Fri Dec 21 05:51:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7F321F8461 for ; Fri, 21 Dec 2012 05:51:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UASladKLGzJF for ; Fri, 21 Dec 2012 05:51:00 -0800 (PST) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by ietfa.amsl.com (Postfix) with ESMTP id CC36B21F8450 for ; Fri, 21 Dec 2012 05:50:59 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id x10so2156375wey.5 for ; Fri, 21 Dec 2012 05:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=/Fx1PJBtgOgTgbiLDoF8SOP22DpEn3b4rZEbkoJOhGc=; b=KJ1OUDrxfmIQBkU/+LPkWARWbFfAUEfMHJheKj6m/meOEnSc6nk8N7e+eF6wSEPogm +z3NjumRvuRNwR8yOhYF78qCMTaBPWowVpKAJA5iflpqk1JcSvZsRGFphJap6z3cgPUA 2GSBsIu3ZtoFeTsCC+zVfkLbeUoDY6gfkVJDQcGPZTDOivcbdcPot58Kdc69FpwxLblc M55Pw+OI7bvkwjedZnhA+7iYEI1fxdUmABQdqUIcG6xyU2VfJbCHfUtbGPpyv9ACh7Ou eKFjAArFoWIfSA6BgtjZD87kS8LEckns2lmr8eEa7lwK/UJy+OnVPW39TocrfsyuNln8 RCkw== X-Received: by 10.194.86.40 with SMTP id m8mr23782673wjz.24.1356097858916; Fri, 21 Dec 2012 05:50:58 -0800 (PST) Received: from RoniE (bzq-79-183-215-175.red.bezeqint.net. [79.183.215.175]) by mx.google.com with ESMTPS id u6sm18388601wif.2.2012.12.21.05.50.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 05:50:57 -0800 (PST) From: "Roni Even" To: "'Christer Holmberg'" , "'Paul Kyzivat'" , References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <04c401cddf04$bb4ef6b0$31ece410$@gmail.com> <7594FB04B1934943A5C02806D1A2204B06F193@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B06F193@ESESSMB209.ericsson.se> Date: Fri, 21 Dec 2012 15:48:04 +0200 Message-ID: <004001cddf81$cfd52500$6f7f6f00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEkbjq3U4NnLY/aQKp9c6xQM9CTPwH5kkWAAVzYh/ABpx7DDQL7XtBXmTZfhyA= Content-Language: en-us Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? 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, 21 Dec 2012 13:51:04 -0000 Hi Christer, 2 represent a switch view of the scene, this is what will be offered from a three camera system to a one decoder/monitor system. This is from the framework Roni -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 21 December, 2012 2:41 PM To: Roni Even; 'Paul Kyzivat'; clue@ietf.org Subject: RE: [clue] Can receiver select captures from more than one capture scene entry? Hi, I thought each capture scene entry (CSE) represented the same scene. I guess 1) and 3) represents the same scene, but not 2) is only part of the same scene. Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 21. joulukuuta 2012 0:53 To: 'Paul Kyzivat'; clue@ietf.org Subject: Re: [clue] Can receiver select captures from more than one capture scene entry? Hi, Here is an example from the framework that can demonstrate the need for selecting part of capture set entry and captures from multiple capture set entries These are the capture scene entries: 1. (VC0, VC1, VC2) - left, center and right camera video captures 2. (VC3) - video capture associated with loudest room segment 3. (VC4) - video capture zoomed out view of all people in the room The simultaneous sets is (VC0,VC1,VC2,VC3) - since the loudest speaker is one of VC0, VC1 or VC2 (VC0, VC3, VC2) - the middle camera is used for zoom out view. Now an MCU may want to get (VC0, VC1, VC2 , VC3) and switch to one monitor systems VC3 and to the 3 monitor systems (VC0,VC1,VC2) A two monitor system may want to receive (VC4, VC0) since the person using the system would like to have also a view of the left side of the room Again, My claim is that the configuration may be selected by the person/s using the system and the consumer endpoint can provide him with the allowed multiple choices allowing him to build the view he wants. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 13 December, 2012 11:15 PM To: clue@ietf.org Subject: [clue] Can receiver select captures from more than one capture scene entry? The "Capture scene clarifications" topic has been *very* popular, and is getting confusing. Here I've changed the subject line to focus on one point - a change that was been proposed by Christer. The latest description of it was from Christian Groves: >> "A consumer may receive an advertisement with multiple capture scenes. >> A consumer may choose to receive any number of capture scenes. An >> advertised capture scene it may contain one of more capture scene >> entries that may contain one of more media captures. A consumer may >> choose an capture scene entry in the knowledge that it is a complete >> representation of the scene for a particular media type and that all >> media captures are spatially related. For a particular media type the >> consumer shall choose one capture scene entry rather than choosing >> individual captures from multiple capture scene entries. However this >> does not mean that a consuming endpoint must render all the media >> captures. What is locally rendered and how is a local decision." There have been some suggestions that this could also eliminate the need for simultaneous sets, because the scene entries would *be* the simultaneous sets. I'm not sure if that is an integral part of this proposal or not. (If it is, then it provides part of the justification. Without this part I'm not sure what the benefit is.) I am inclined to agree that a new definition of advertisement and configuration could be built around such a concept. But to do so I think somebody will need to work out all the details. For instance: - can the same capture be in more than one capture scene entry? - how does the configure message specify which entries it wants, and which captures from those entries? IMO the existing (prior?) model was at least clearer, and arguably simpler. The way I have been thinking of it: - an advertisement advertises a bunch of captures, and information about those captures to help the receiver decide which ones it wants and how it should render them. - scenes, scene entries, simultaneous sets, are all just pieces of that descriptive info. - a configuration is simple - it only needs to enumerate the captures that it wants. It need not mention scenes or scene entries. (It might need to identify scenes if the capture ids are scoped to a scene.) The proposed changes would make the configuration message more complex. The receiver would need to enumerate the desired scene entries. And for each selected scene entry, identify those captures that are (or are not) desired. So, IMO, if some people are interested in this new approach, I suggest they work on a detailed proposal for how it would work, and then do a full assessment of the pros/cons relative to the existing proposal. 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 Mark.Duckworth@polycom.com Fri Dec 21 15:54: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 49E4D21F8A83 for ; Fri, 21 Dec 2012 15:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPILuXJblMDp for ; Fri, 21 Dec 2012 15:54:31 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8615921F8A64 for ; Fri, 21 Dec 2012 15:54: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; Fri, 21 Dec 2012 15:54:30 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 21 Dec 2012 15:54:28 -0800 Thread-Topic: [clue] Can receiver select captures from more than one capture scene entry? Thread-Index: AQEkbjq3U4NnLY/aQKp9c6xQM9CTPwH5kkWAAVzYh/CZWncssIABo9GQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610391BE7727@CRPMBOXPRD01.polycom.com> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <04c401cddf04$bb4ef6b0$31ece410$@gmail.com> In-Reply-To: <04c401cddf04$bb4ef6b0$31ece410$@gmail.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] Can receiver select captures from more than one capture scene entry? 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, 21 Dec 2012 23:54:33 -0000 I agree we should keep the ability for a consumer to select captures from m= ultiple capture scene entries. But I also like Christian's hybrid proposal= , because it enables both providers and consumers to be simple if they want= to be. With Christian's proposal, a simple provider can omit the simultaneous tran= smission sets, and then the capture scene entries become the sole factor th= at defines what the provider can send simultaneously. In this case, a cons= umer cannot select captures from more than one capture scene entry (of same= media type). A provider that wants to offer more choice to the consumer c= an use simultaneous transmission sets to give the consumer more information= , and this enables the consumer to choose captures from more than one captu= re scene entry. A simple consumer can always ignore simultaneous transmission sets, and sim= ply choose captures from only one capture scene entry, typically choosing a= ll the captures in a capture scene entry. A more complicated consumer coul= d take advantage of the additional choices available when simultaneous tran= smission sets are used by the provider. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni Even > Sent: Thursday, December 20, 2012 5:53 PM > To: 'Paul Kyzivat'; clue@ietf.org > Subject: Re: [clue] Can receiver select captures from more than one captu= re > scene entry? >=20 > Hi, > Here is an example from the framework that can demonstrate the need for > selecting part of capture set entry and captures from multiple capture se= t > entries >=20 > These are the capture scene entries: >=20 > 1. (VC0, VC1, VC2) - left, center and right camera video captures >=20 > 2. (VC3) - video capture associated with loudest room segment >=20 > 3. (VC4) - video capture zoomed out view of all people in the room >=20 > The simultaneous sets is >=20 > (VC0,VC1,VC2,VC3) - since the loudest speaker is one of VC0, VC1 or VC2 > (VC0, VC3, VC2) - the middle camera is used for zoom out view. >=20 > Now an MCU may want to get (VC0, VC1, VC2 , VC3) and switch to one > monitor systems VC3 and to the 3 monitor systems (VC0,VC1,VC2) >=20 > A two monitor system may want to receive (VC4, VC0) since the person usin= g > the system would like to have also a view of the left side of the room >=20 > Again, My claim is that the configuration may be selected by the person/s > using the system and the consumer endpoint can provide him with the > allowed multiple choices allowing him to build the view he wants. >=20 > Roni >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 13 December, 2012 11:15 PM > To: clue@ietf.org > Subject: [clue] Can receiver select captures from more than one capture > scene entry? >=20 > The "Capture scene clarifications" topic has been *very* popular, and is > getting confusing. >=20 > Here I've changed the subject line to focus on one point - a change that = was > been proposed by Christer. The latest description of it was from Christia= n > Groves: >=20 > >> "A consumer may receive an advertisement with multiple capture > scenes. > >> A consumer may choose to receive any number of capture scenes. An > >> advertised capture scene it may contain one of more capture scene > >> entries that may contain one of more media captures. A consumer may > >> choose an capture scene entry in the knowledge that it is a complete > >> representation of the scene for a particular media type and that all > >> media captures are spatially related. For a particular media type the > >> consumer shall choose one capture scene entry rather than choosing > >> individual captures from multiple capture scene entries. However this > >> does not mean that a consuming endpoint must render all the media > >> captures. What is locally rendered and how is a local decision." >=20 > There have been some suggestions that this could also eliminate the need > for simultaneous sets, because the scene entries would *be* the > simultaneous sets. I'm not sure if that is an integral part of this propo= sal or > not. (If it is, then it provides part of the justification. > Without this part I'm not sure what the benefit is.) >=20 > I am inclined to agree that a new definition of advertisement and > configuration could be built around such a concept. But to do so I think > somebody will need to work out all the details. For instance: > - can the same capture be in more than one capture scene entry? > - how does the configure message specify which entries it wants, > and which captures from those entries? >=20 > IMO the existing (prior?) model was at least clearer, and arguably simple= r. > The way I have been thinking of it: >=20 > - an advertisement advertises a bunch of captures, and information > about those captures to help the receiver decide which ones it > wants and how it should render them. >=20 > - scenes, scene entries, simultaneous sets, are all just pieces of > that descriptive info. >=20 > - a configuration is simple - it only needs to enumerate the > captures that it wants. It need not mention scenes or scene > entries. (It might need to identify scenes if the capture ids > are scoped to a scene.) >=20 > The proposed changes would make the configuration message more > complex. > The receiver would need to enumerate the desired scene entries. And for > each selected scene entry, identify those captures that are (or are not) > desired. >=20 > So, IMO, if some people are interested in this new approach, I suggest th= ey > work on a detailed proposal for how it would work, and then do a full > assessment of the pros/cons relative to the existing proposal. >=20 > Thanks, > Paul >=20 > _______________________________________________ > 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 Mark.Duckworth@polycom.com Fri Dec 21 16:07: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 06F1A21F8A8A for ; Fri, 21 Dec 2012 16:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu8hWBVMKu4I for ; Fri, 21 Dec 2012 16:07:29 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id C922C21F8A83 for ; Fri, 21 Dec 2012 16:07: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; Fri, 21 Dec 2012 16:07:19 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 21 Dec 2012 16:07:16 -0800 Thread-Topic: [clue] Can receiver select captures from more than one capture scene entry? Thread-Index: Ac3c3URo4udh3VJBRmK8hE5H8fx6cAC+W34Q Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610391BE772A@CRPMBOXPRD01.polycom.com> References: <50AEF3CB.7020904@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A610391863B3A@CRPMBOXPRD01.polycom.com> <50CA4537.80907@alum.mit.edu> <50CFF980.5090103@nteczone.com> In-Reply-To: <50CFF980.5090103@nteczone.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] Can receiver select captures from more than one capture scene entry? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 00:07:30 -0000 Hi Christian, I'll take a few of the issues from below and give my input. > > - can the same capture be in more than one capture scene entry? Yes. We should clarify this in the framework. > - how does the configure message specify which entries it wants, > and which captures from those entries? Section 9 of the framework says "the consumer must choose which media captu= res it wishes to receive, and which individual encodings from the provider = it wants to use to encode the captures." Then there is a bit more detail. = This just means the consumer specifies which media captures it wants to re= ceive, with information about how it is encoded. The consumer does not nee= d to mention capture scene entries in the configure message, it just lists = the media captures it wants. This is simple, and it can be the same whethe= r or not simultaneous transmission sets are involved. I think any further = detail about how all this is represented belongs in a protocol document, no= t the framework. > 1. Simultaneous sets: Are these mandatory for the Advertiser to send? If= =20 > not what is the default? What is the action of the consumer? I think you hybrid proposal is good, as I explained in separate emails. Regards, Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Tuesday, December 18, 2012 12:05 AM > To: Paul Kyzivat > Cc: clue@ietf.org > Subject: Re: [clue] Can receiver select captures from more than one captu= re > scene entry? >=20 > Hello Paul, >=20 > Please see my comments below. >=20 > Regards, Christian >=20 > On 14/12/2012 8:14 AM, Paul Kyzivat wrote: > > The "Capture scene clarifications" topic has been *very* popular, and > > is getting confusing. > > > > Here I've changed the subject line to focus on one point - a change > > that was been proposed by Christer. The latest description of it was > > from Christian Groves: > > > >>> "A consumer may receive an advertisement with multiple capture > >>> scenes. > >>> A consumer may choose to receive any number of capture scenes. An > >>> advertised capture scene it may contain one of more capture scene > >>> entries that may contain one of more media captures. A consumer may > >>> choose an capture scene entry in the knowledge that it is a complete > >>> representation of the scene for a particular media type and that all > >>> media captures are spatially related. For a particular media type > >>> the consumer shall choose one capture scene entry rather than > >>> choosing individual captures from multiple capture scene entries. > >>> However this does not mean that a consuming endpoint must render all > >>> the media captures. What is locally rendered and how is a local > >>> decision." > [CNG] I take it that people are OK with the first part of the proposal. > The only thing in question is "...shall choose one capture scene entry". > > > > There have been some suggestions that this could also eliminate the > > need for simultaneous sets, because the scene entries would *be* the > > simultaneous sets. I'm not sure if that is an integral part of this > > proposal or not. (If it is, then it provides part of the > > justification. Without this part I'm not sure what the benefit is.) > [CNG] In a later email I proposed a hybrid solution. That we recommend th= at > a consumer choose one CSE entry but that it may choose a subset if a > simultaneous set is included to indicate any dependencies. So instead the > sentence in question we replace it with >=20 > "For a particular media type the consumer should choose one capture scene > entry. If the advertiser has provided a simultaneous transmission set, th= e > consumer may choose individual captures taking in account any simultaneit= y > requirements". >=20 >=20 > > > > I am inclined to agree that a new definition of advertisement and > > configuration could be built around such a concept. > [CNG] I don't particularly see this as "new" what I've been trying to do = is > clarify how what is currently in the draft is going to work. >=20 > > But to do so I think somebody will need to work out all the details. > > For instance: > > - can the same capture be in more than one capture scene entry? > [CNG] The current framework is unclear on this. The examples show that > captures are only in one capture scene entry at a time. So we need to cla= rify > this either way. >=20 > > - how does the configure message specify which entries it wants, > > and which captures from those entries? > [CNG] Again the framework is silent on what happens today. Like the scene > issue I think people have been making assumptions but these haven't been > recorded. >=20 > > > > IMO the existing (prior?) model was at least clearer, and arguably > > simpler. > [CNG] Perhaps but it was not fully documented. >=20 > > The way I have been thinking of it: > > > > - an advertisement advertises a bunch of captures, and information > > about those captures to help the receiver decide which ones it > > wants and how it should render them. > > > > - scenes, scene entries, simultaneous sets, are all just pieces of > > that descriptive info. > [CNG] I agree. The main thing is that the same logic that was used > constructing the Advertisement is the same logic that is used "reading" > the Advertisement. > > > > - a configuration is simple - it only needs to enumerate the > > captures that it wants. It need not mention scenes or scene > > entries. (It might need to identify scenes if the capture ids > > are scoped to a scene.) > [CNG] Generally yes. However there are attributes associated with a > scene. There may be choices where an attribute is sent with a list where > a choice could be made. These go beyond just returning an id. > > > > > > The proposed changes would make the configuration message more > > complex. The receiver would need to enumerate the desired scene > > entries. And for each selected scene entry, identify those captures > > that are (or are not) desired. > [CNG] It will really depend on the structure of the message. > > > > So, IMO, if some people are interested in this new approach, I suggest > > they work on a detailed proposal for how it would work, and then do a > > full assessment of the pros/cons relative to the existing proposal. > [CNG] I'd like to nail down how the current framework is meant to work. > Then we can evaluate any new approach. I think we came up with several > good clarifications in Marks email on the 02/12. >=20 > In addition I think we agreed to add text indicating that no priority > between elements is intended in the current framework. >=20 > Here's some additional items that need clarifying in the current framewor= k: > 1. Simultaneous sets: Are these mandatory for the Advertiser to send? If > not what is the default? What is the action of the consumer? > 2. Can a capture occur in multiple capture scene entries? > 3. Configure message needs to be specified. >=20 > Regards, Christian >=20 >=20 >=20 > > > > 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 internet-drafts@ietf.org Mon Dec 24 16:44: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 1F29B21F8B46; Mon, 24 Dec 2012 16:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7laQgsfvK4y; Mon, 24 Dec 2012 16:44:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B64721F88D1; Mon, 24 Dec 2012 16:44:17 -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: 4.37 Message-ID: <20121225004417.26076.2975.idtracker@ietfa.amsl.com> Date: Mon, 24 Dec 2012 16:44:17 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-08.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: Tue, 25 Dec 2012 00:44:18 -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 tElepres= ence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-08.txt Pages : 42 Date : 2012-12-24 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-framework-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stewe@stewe.org Mon Dec 24 16:49: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 75C0121F87D0 for ; Mon, 24 Dec 2012 16:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.584 X-Spam-Level: X-Spam-Status: No, score=-4.584 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkct1q6wc1Mt for ; Mon, 24 Dec 2012 16:49:43 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 889BD21F86DC for ; Mon, 24 Dec 2012 16:49:43 -0800 (PST) Received: from mail10-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Dec 2012 00:49:42 +0000 Received: from mail10-ch1 (localhost [127.0.0.1]) by mail10-ch1-R.bigfish.com (Postfix) with ESMTP id 9B65F22015B for ; Tue, 25 Dec 2012 00:49:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.133; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz936eIc85fh14ffIzz1de0h1202h1e76h1d1ah1d2ah1082kzz8275bh8275dh1033IL18c673h17326ahz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h34h1155h) Received-SPF: pass (mail10-ch1: domain of stewe.org designates 157.56.236.133 as permitted sender) client-ip=157.56.236.133; envelope-from=stewe@stewe.org; helo=BY2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail10-ch1 (localhost.localdomain [127.0.0.1]) by mail10-ch1 (MessageSwitch) id 1356396580732357_20843; Tue, 25 Dec 2012 00:49:40 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail10-ch1.bigfish.com (Postfix) with ESMTP id B0599100061 for ; Tue, 25 Dec 2012 00:49:40 +0000 (UTC) Received: from BY2PRD0710HT002.namprd07.prod.outlook.com (157.56.236.133) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Dec 2012 00:49:40 +0000 Received: from BY2PRD0710MB354.namprd07.prod.outlook.com ([169.254.9.110]) by BY2PRD0710HT002.namprd07.prod.outlook.com ([10.255.86.37]) with mapi id 14.16.0245.002; Tue, 25 Dec 2012 00:49:38 +0000 From: Stephan Wenger To: "clue@ietf.org" Thread-Topic: New framework I-D posted Thread-Index: AQHN4jm36Jyl+27Qq0W/NnI6NKyWhQ== Date: Tue, 25 Dec 2012 00:49:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.255.86.4] Content-Type: multipart/mixed; boundary="_004_FDBFA77C7400C74F87BC297393B53E3532AC62B6BY2PRD0710MB354_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: [clue] New framework I-D posted 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, 25 Dec 2012 00:49:44 -0000 --_004_FDBFA77C7400C74F87BC297393B53E3532AC62B6BY2PRD0710MB354_ Content-Type: multipart/alternative; boundary="_000_FDBFA77C7400C74F87BC297393B53E3532AC62B6BY2PRD0710MB354_" --_000_FDBFA77C7400C74F87BC297393B53E3532AC62B6BY2PRD0710MB354_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I just posted an update to the framework draft. Most of the changes are in= the introduction, covering the basic outline of the CLUE operation as disc= ussed during the design team call. It is our intention to streamline this = section later and to move out some of the information into sections more ap= propriate than the intro. In the spirit of avoiding "misapplying yesterday's technology today", we ar= e using Winword between us editors now, so there is no XML version. This = resulted also in formatting changes which is going to make the diff a bit l= ess useful than usual. It will be better from the next version onwards. I= f you want the word file, please contact me. Stephan --_000_FDBFA77C7400C74F87BC297393B53E3532AC62B6BY2PRD0710MB354_ Content-Type: text/html; charset="us-ascii" Content-ID: <5767C7EC71B5554ABCBABBA1EE7B726D@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi all,
I just posted an update to the framework draft.  Most of the chan= ges are in the introduction, covering the basic outline of the CLUE operati= on as discussed during the design team call.  It is our intention to s= treamline this section later and to move out some of the information into sections more appropriate than the intro.
In the spirit of avoiding "misapplying yesterday's technology tod= ay", we are using Winword between us editors now, so there is no XML v= ersion.   This resulted also in formatting changes which is going to m= ake the diff a bit less useful than usual.  It will be better from the next version onwards.  If you want the word f= ile, please contact me. 
Stephan

--_000_FDBFA77C7400C74F87BC297393B53E3532AC62B6BY2PRD0710MB354_-- --_004_FDBFA77C7400C74F87BC297393B53E3532AC62B6BY2PRD0710MB354_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 25 Dec 2012 00:49:37 GMT"; modification-date="Tue, 25 Dec 2012 00:49:37 GMT" Content-ID: <9B170F1A978A7E49A4F1E7A009DE0ADC@namprd07.prod.outlook.com> Received: from BLUPRD0712HT002.namprd07.prod.outlook.com (10.255.218.163) by BY2PRD0710HT003.namprd07.prod.outlook.com (10.255.86.38) with Microsoft SMTP Server (TLS) id 14.16.245.2; Tue, 25 Dec 2012 00:44:22 +0000 Received: from BLUPRD0712HT001.namprd07.prod.outlook.com (10.255.218.162) by BLUPRD0712HT002.namprd07.prod.outlook.com (10.255.218.163) with Microsoft SMTP Server (TLS) id 14.16.245.2; Tue, 25 Dec 2012 00:44:22 +0000 Received: from mail93-va3-R.bigfish.com (216.32.180.117) by BLUPRD0712HT001.namprd07.prod.outlook.com (10.255.218.162) with Microsoft SMTP Server (TLS) id 14.16.245.2; Tue, 25 Dec 2012 00:44:21 +0000 Received: from mail93-va3 (localhost [127.0.0.1]) by mail93-va3-R.bigfish.com (Postfix) with ESMTP id 9DBFB34010A for ; Tue, 25 Dec 2012 00:44:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:64.170.98.30;KIP:(null);UIP:(null);IPV:NLI;H:mail.ietf.org;RD:mail.ietf.org;EFVD:NLI X-SpamScore: -20 X-BigFish: ps-20(zz936eIzz1de0h1202h1e76h1d1ah1d2ahzz8275dh1033IL17326ahz2fh668h839h93fhd24h1288h12a5h12a9h12bdh137ah13b6h13eah1441h14ddh1504h1537h153bh162dh1631h1758h1664i1155h) Received-SPF: pass (mail93-va3: domain of ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; envelope-from=internet-drafts@ietf.org; helo=mail.ietf.org ;ail.ietf.org ; Received: from mail93-va3 (localhost.localdomain [127.0.0.1]) by mail93-va3 (MessageSwitch) id 135639625940835_29707; Tue, 25 Dec 2012 00:44:19 +0000 (UTC) Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.235]) by mail93-va3.bigfish.com (Postfix) with ESMTP id 05AD04E0074 for ; Tue, 25 Dec 2012 00:44:19 +0000 (UTC) Received: from mail.ietf.org (64.170.98.30) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Dec 2012 00:44:18 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E4E21F8B48; Mon, 24 Dec 2012 16:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbHvtkj4eR4S; Mon, 24 Dec 2012 16:44:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF4B21F8AA3; Mon, 24 Dec 2012 16:44:17 -0800 (PST) From: To: CC: , Subject: New Version Notification for draft-ietf-clue-framework-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121225004417.26076.47735.idtracker@ietfa.amsl.com> Date: Mon, 24 Dec 2012 16:44:17 -0800 Return-Path: internet-drafts@ietf.org X-MS-Exchange-Organization-SCL: 1 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-AuthSource: BLUPRD0712HT001.namprd07.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 A new version of I-D, draft-ietf-clue-framework-08.txt has been successfully submitted by Stephan Wenger and posted to the IETF repository. Filename: draft-ietf-clue-framework Revision: 08 Title: Framework for Telepresence Multi-Streams Creation date: 2012-12-24 WG ID: clue Number of pages: 42 URL: http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-08.txt Status: http://datatracker.ietf.org/doc/draft-ietf-clue-framework Htmlized: http://tools.ietf.org/html/draft-ietf-clue-framework-08 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-08 Abstract: 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. The IETF Secretariat --_004_FDBFA77C7400C74F87BC297393B53E3532AC62B6BY2PRD0710MB354_--