From mary.ietf.barnes@gmail.com Thu Nov 1 06:13: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 8F12621F878C for ; Thu, 1 Nov 2012 06:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEw90zpgeFQ3 for ; Thu, 1 Nov 2012 06:13:16 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55D5121F8C2B for ; Thu, 1 Nov 2012 06:12:55 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2012327lbo.31 for ; Thu, 01 Nov 2012 06:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EwjKvT9tFwxFiSEtFrDsxbHnyiFPTpSqE2w1rwW3UbM=; b=MU8LLemBMIYuVhaihPa9nhigZo4GSFRh7lLDUIUDqn2tkaiVJjzvRDPhh+v3tFrnE1 x7XfRbmKlXOCOkzoze1FL793uxGXExdNdGZQCSovmSZ8qnvZ3WUGASUeMERKOTL5uKKX KwAdJKZoJ9dpEuS+phb9zx/t4myF+UvQWBLZnV7w72IXuux21ENLL2BIxQyv3tVRLyOv Lq9WrLVnK3OMTotS3QC5Uv4UTHs9rvKrpirFWWKnpnLOUFTlvIFpqXOtVSirU4mm7GIj AINiMhA3/3d9Ds9G49hIqt5npyPLuZvoZQYjgnpoMOZVCmtme7APKAqXR3/lffkvn3ZW nG3Q== MIME-Version: 1.0 Received: by 10.152.105.135 with SMTP id gm7mr36945211lab.22.1351775574175; Thu, 01 Nov 2012 06:12:54 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Thu, 1 Nov 2012 06:12:54 -0700 (PDT) In-Reply-To: <5091C644.5070401@nteczone.com> References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <020401cdb76a$16131c60$42395520$@gmail.com> <5091C644.5070401@nteczone.com> Date: Thu, 1 Nov 2012 08:12:54 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=f46d040711c5ea2ff504cd6ec6ba Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:13:18 -0000 --f46d040711c5ea2ff504cd6ec6ba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 7:45 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > I agree the framework document in its current state isn't the easiest or > most precise document so we need to do something to make it easier to > understand. However I agree with Roni that removing sections 1-4 doesn't > leave much. > > I still am not convinced about having a data model document related to a > CLUE instance. What I'm trying to see is the actual benefit for this > approach? [MB] The benefit of the data model is that it takes the data as defined in the framework to a lower level of abstraction that can be thus used as elements in a protocol. [/MB] Is it to help implementers? [MB] The implementers will use it as a reference within the context of the protocol. [/MB] Is it to help us as specifiers? > [MB] Yes. This is an objected oriented design model - you define the data you need for the functionality and then define the mechanisms for creating, updating, etc. [/MB] I know XCON and SIPREC followed this approach but from my view as a casual > observer of the process is that these activities took a long time to > completion. [MB] The data model was the last thing that kept any of these WGs from making good progress. The XCON data model was started well before any of the other aspects of the protocol. SIPREC is moving along about as a good of a piece as many other WGs, so I'm not sure why you have that specific perception of that WG. [/MB] My fear is that Simon will be the only one who actually understands the > data model well. Others will just be put off from looking closely at it > because of the syntax. > [MB] I personally find that quite silly since XML schemas are very, very commonly used in IETF protocol documents these days. You haven't been on the design team calls, but we had some very useful discussions using the schema as a starting point. It helps very much to have something concrete on the table and think most folks are now pretty familiar with ready XML schemas. For folks that aren't, there are quite a few useful books and websites. There are certainly some nuances that you need to be aware of to use properly, but it's pretty easy to learn enough to interpret the schema. We would get the XML gurus to review the schema before progressing anything. [/MB] > > Regards, Christian > > > On 1/11/2012 1:05 AM, Mary Barnes wrote: > >> Simon also suggested that we need to enrich the framework. We have >> gotten feedback in the past that it's difficult to read as I think there= is >> a middle level of detail that is missing. We have had wonderful diagram= s >> in .ppts at the meetings but we have very few diagrams in the FW. I thi= nk >> it could help a lot to add some. >> >> Mary. >> >> >> On Wed, Oct 31, 2012 at 8:17 AM, Roni Even > ron.even.tlv@gmail.com**>> wrote: >> >> Hi Simon, >> This will make the framework empty, section 1-4 do not have any >> information >> that merit a document. >> Roni >> >> -----Original Message----- >> From: clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org **] On >> Behalf Of >> Simon Pietro Romano >> Sent: 30 October, 2012 12:24 PM >> To: Christian Groves >> Cc: clue@ietf.org >> Subject: Re: [clue] Data model - agreement on objective and basic >> approach >> >> Hi Christian, >> >> a rough estimation would be the following: >> >> a) keep sections 1 through 4 inside the framework document; >> b) move sections 5 through 8 to the data model document >> c) move the XML schema to the data model document (final section >> of the data >> model, which provides 'one possible' example of how to formally >> describe the >> things in the document); >> d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the >> protocol document; >> e) move subsection 9.4 to the call flows document; >> f) move section 10 to the data model document; >> g) move section 11 to the call flows document. >> >> Obviously, the resulting framework document should be revised (and >> enriched) in view of the proposed distribution of work inside the >> WG. I >> would like it to represent an orchestration document, providing an >> overview >> of issues, requirements, architecture and protocols. A sort of summa= ry >> reference for all of the related "drill-down" documents, each >> expanding on a >> specific WG item (data model, protocol, call flows, etc.). >> >> I acknowledge the fact that this looks much like a revolution, but I >> nonetheless believe that we already have most of the needed >> material at hand >> and just need to better distribute it across the documents >> produced by the >> WG. >> >> Cheers, >> >> Simon >> >> >> >> >> Il 30/10/2012 10:33, Christian Groves ha scritto: >> > Hello Simon, >> > >> > When you say that you want to remove "all" the data model stuff fr= om >> > the framework can you be a bit more specific as to what parts >> you want >> > removed? >> > >> > Regards, Christian >> > >> > On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: >> >> Hi all, >> >> >> >> just to be clear on the current structure of the data model schem= a: >> >> all the things you find there were 'extracted' (by Roberta and me= ) >> >> from information currently contained inside the framework draft (= as >> >> well as from some side documents, associated with either the data >> >> model or the envisaged call flows). So, unless we have >> misinterpreted >> >> the above document(s) (which is obviously possible), we should >> first >> >> of all focus on the framework in order to try and converge on an >> >> agreed-upon CLUE architecture. Once done with this, we can >> fine-tune >> >> the data model. As I already stated on this list, it is my person= al >> >> opinion that we should remove from the framework document all >> of the >> >> data-model stuff that it currently contains, and rather focus on = a >> >> clear definition of framework components and interfaces. I >> might look >> >> naif, but I would like to arrive at an 'ordinary' set of document= s: >> >> (i) general framework; (ii) data model; (iii) clue protocol (wit= h >> >> advertisement and configuration messages); (iv) call flows (showi= ng >> >> how SDP O/A and CLUE protocol messages concur in effectively >> setting >> >> up a CLUE session). >> >> >> >> As to the 'UML vs XML' querelle, I would suggest that: >> >> >> >> 1. Both UML class diagrams and XML schema can be adopted for the >> >> description of the data model, i.e., the STATIC part of the >> >> framework, associated with the description of what some of you >> >> properly called a 'CLUE instance'; 2. UML sequence diagrams can b= e >> >> adopted to describe CLUE call flows, i.e. the DYNAMIC part of the >> >> framework, which clearly envisages the co-existence of SDP and CL= UE >> >> protocol messages. XML schemas are not suitable for this dynamic >> >> part. >> >> >> >> This said, it is clear that CLUE protocol messages (in particula= r, >> >> CLUE advertisements) will be constructed by leveraging informatio= n >> >> contained inside a CLUE instance. Which parts of a CLUE instance >> >> should go into an advertisement and which should be carried insid= e >> >> SDP can be a matter of discussion. >> >> >> >> My 2 cents, >> >> >> >> Simon >> >> >> >> >> >> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: >> >> >> >>> On 10/29/12 6:23 PM, Roni Even wrote: >> >>>> Paul, >> >>>> This was the statement I answered "no" >> >>>> " The general agreement on the call is that the data model as >> >>>> reflected in draft-presta-clue-data-model-**schema describes >> the data >> >>>> needed by the CLUE application" >> >>>> I disagree that it reflects that data needed by a CLUE >> application >> >>>> and I explained why. >> >>> >> >>> OK, fair enough. >> >>> >> >>> Mary can comment, but my take was that the point of her >> question was >> >>> to distinguish between two alternatives: >> >>> - the data model represents all the data needed by the clue app. >> >>> (which implies to me that it encompasses all the data in the >> >>> framework.) >> >>> - the data model represents the data to be exchanged in clue >> >>> messages. >> >>> >> >>> It is a bigger deal if the framework includes things that are no= t >> >>> needed by the clue application. I was of the impression that, >> except >> >>> for some fine tuning, we were largely in agreement on the >> framework. >> >>> >> >>> If we don't have consensus on *that* then resolving that is of >> >>> higher priority that much of the other stuff we are discussing. >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >>>> Roni >> >>>> >> >>>> -----Original Message----- >> >>>> From: clue-bounces@ietf.org >> **> >> >>>> [mailto:clue-bounces@ietf.org **] >> On Behalf Of Paul Kyzivat >> >>>> Sent: 29 October, 2012 9:46 PM >> >>>> To: clue@ietf.org >> > >> >>>> Subject: Re: [clue] Data model - agreement on objective and bas= ic >> >>>> approach >> >>>> >> >>>> On 10/29/12 3:19 PM, Roni Even wrote: >> >>>>> Hi, >> >>>>> >> >>>>> My view is 'no". I still fail to see the need for the encoding >> >>>>> groups and individual encodes. >> >>>>> >> >>>>> In the current definition of capture scene, I am not sure >> what is >> >>>>> the meaning of different individual encodes and eventually the >> >>>>> receiver can define what it can receive (Typically H.264 is >> >>>>> symmetric in terms of profile but does not need to be in the >> >>>>> level) and can ask for specific resolution with the SDP image >> >>>>> attribute >> >>>> >> >>>> ISTM that you are answering a different question than the one >> Mary >> >>>> asked. >> >>>> You seem to be saying that you disagree with the framework as >> it is >> >>>> - that >> >>>> it can/should be simpler. >> >>>> >> >>>> That is a separate question. If such changes were made it might >> >>>> affect a lot. >> >>>> >> >>>> Thanks, >> >>>> Paul >> >>>> >> >>>>> Roni Even >> >>>>> >> >>>>> *From:*clue-bounces@ietf.org >> **> >> >>>>> [mailto:clue-bounces@ietf.org >> **] *On Behalf Of *Mary Barnes >> >> >>>>> *Sent:* 29 October, 2012 7:52 PM >> >>>>> *To:* CLUE >> >>>>> *Subject:* [clue] Data model - agreement on objective and basi= c >> >>>>> approach >> >>>>> >> >>>>> On the call earlier today, we also discussed the data model. >> The >> >>>>> general agreement on the call is that the data model as >> reflected >> >>>>> in draft-presta-clue-data-model-**schema describes the data >> needed >> >>>>> by the CLUE application - i.e., it's the CLUE instance >> concept. It >> >>>>> does not directly reflect the contents of a CLUE message. The >> >>>>> application data would be used to populate CLUE messages, as >> well >> >>>>> as SDP and would reflect updates based on both the CLUE and SD= P >> >>>>> signaling. >> >>>>> >> >>>>> If we can get agreement on that before the meeting, I >> believe our >> >>>>> discussions can be much more productive. If folks could please >> >>>>> reply "Yes" or "No" reflecting agreement with the above, that >> >>>>> would be helpful. If you reply "No", please explain why. >> >>>>> >> >>>>> Regards, >> >>>>> >> >>>>> Mary >> >>>>> >> >>>>> as CLUE WG co-chair >> >>>>> >> >>>>> >> >>>>> >> >>>>> ______________________________**_________________ >> >>>>> clue mailing list >> >>>>> clue@ietf.org > >> > >> >>>>> https://www.ietf.org/mailman/**listinfo/clue >> >>>>> >> >>>> >> >>>> ______________________________**_________________ >> >>>> clue mailing list >> >>>> clue@ietf.org > >> > >> >>>> https://www.ietf.org/mailman/**listinfo/clue >> >>>> >> >>>> >> >>> >> >>> ______________________________**_________________ >> >>> clue mailing list >> >>> clue@ietf.org > >> > >> >>> https://www.ietf.org/mailman/**listinfo/clue >> >>> >> >> >> >> _\\|//_ >> >> ( 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 >> > >> >> >> >> >> <> >> rifletto un istante; e mi scoraggio>>. Magritte. >> >> oooO >> >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> \ ( ( ) >> >> \_) ) / >> >> (_/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ______________________________**_________________ >> >> 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 Science Department >> Phone: +39 081 7683823 -- >> Fax: +39 081 7684219 >> e-mail: spromano@unina.it >> >> http://www.comics.unina.it/**simonpietro.romano >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> ______________________________**_________________ >> 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 >> >> >> > --f46d040711c5ea2ff504cd6ec6ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2012 at 7:45 PM, Christian Groves <Christian.G= roves@nteczone.com> wrote:
I agree the framework document in its current state isn't the easiest o= r most precise document so we need to do something to make it easier to und= erstand. However I agree with Roni that removing sections 1-4 doesn't l= eave much.

I still am not convinced about having a data model document related to a CL= UE instance. What I'm trying to see is the actual benefit for this appr= oach?
[MB] The benefit of the data model is that it takes = the data as defined in the framework to a lower level of abstraction that c= an be thus used as elements in a protocol. =A0[/MB]

Is it to help implementers?<= /blockquote>
[MB] The implementers will use it as a reference within th= e context of the protocol. [/MB]

Is it to help us as specifier= s?
[MB] Yes. This is an objected oriented design model= - you define the data you need for the functionality and then define the m= echanisms for creating, updating, etc. [/MB]=A0

I know XCON and SIPREC followed this approach but from my view as a casual = observer of the process is that these activities took a long time to comple= tion.
[MB] The data model was the last thing that kept any= of these WGs from making good progress. The XCON data model was started we= ll before any of the other aspects of the protocol. =A0SIPREC is moving alo= ng about as a good of a piece as many other WGs, so I'm not sure why yo= u have that specific perception of that WG. [/MB]=A0

My fear is that Simon will b= e the only one who actually understands the data model well. Others will ju= st be put off from looking closely at it because of the syntax.
[MB] I personally find that quite silly since XML schemas= are very, very commonly used in IETF protocol documents these days. =A0You= haven't been on the design team calls, but we had some very useful dis= cussions using the schema as a starting point. =A0It helps very much to hav= e something concrete on the table and think most folks are now pretty famil= iar with ready XML schemas. =A0For folks that aren't, there are quite a= few useful books and websites. =A0There are certainly some nuances that yo= u need to be aware of to use properly, but it's pretty easy to learn en= ough to interpret the schema. =A0We would get the XML gurus to review the s= chema before progressing anything.=A0
[/MB]

Regards, Christian


On 1/11/2012 1:05 AM, Mary Barnes wrote:
Simon also suggested that we need to enrich the framework. =A0We have gotte= n feedback in the past that it's difficult to read as I think there is = a middle level of detail that is missing. =A0We have had wonderful diagrams= in .ppts at the meetings but we have very few diagrams in the FW. =A0I thi= nk it could help a lot to add some.

Mary.


On Wed, Oct 31, 2012 at 8:17 AM, Roni Even <ron.even.tlv@gmail.com <mailto:ron.even.tlv@gmail.c= om>> wrote:

=A0 =A0 Hi Simon,
=A0 =A0 This will make the framework empty, section 1-4 do not have any
=A0 =A0 information
=A0 =A0 that merit a document.
=A0 =A0 Roni

=A0 =A0 -----Original Message-----
=A0 =A0 From: cl= ue-bounces@ietf.org <mailto:clue-bounces@ietf.org>
=A0 =A0 [mailto:= clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>] On
=A0 =A0 Behalf Of
=A0 =A0 Simon Pietro Romano
=A0 =A0 Sent: 30 October, 2012 12:24 PM
=A0 =A0 To: Christian Groves
=A0 =A0 Cc: clue@ietf.or= g <mailto:clue@ie= tf.org>
=A0 =A0 Subject: Re: [clue] Data model - agreement on objective and basic =A0 =A0 approach

=A0 =A0 Hi Christian,

=A0 =A0 a rough estimation would be the following:

=A0 =A0 a) keep sections 1 through 4 inside the framework document;
=A0 =A0 b) move sections 5 through 8 to the data model document
=A0 =A0 c) move the XML schema to the data model document (final section =A0 =A0 of the data
=A0 =A0 model, which provides 'one possible' example of how to form= ally
=A0 =A0 describe the
=A0 =A0 things in the document);
=A0 =A0 d) move section 9, together with subsections 9.1, 9.2 and 9.3 to th= e
=A0 =A0 protocol document;
=A0 =A0 e) move subsection 9.4 to the call flows document;
=A0 =A0 f) move section 10 to the data model document;
=A0 =A0 g) move section 11 to the call flows document.

=A0 =A0 Obviously, the resulting framework document should be revised (and<= br> =A0 =A0 enriched) in view of the proposed distribution of work inside the =A0 =A0 WG. I
=A0 =A0 would like it to represent an orchestration document, providing an<= br> =A0 =A0 overview
=A0 =A0 of issues, requirements, architecture and protocols. A sort of summ= ary
=A0 =A0 reference for all of the related "drill-down" documents, = each
=A0 =A0 expanding on a
=A0 =A0 specific WG item (data model, protocol, call flows, etc.).

=A0 =A0 I acknowledge the fact that this looks much like a revolution, but = I
=A0 =A0 nonetheless believe that we already have most of the needed
=A0 =A0 material at hand
=A0 =A0 and just need to better distribute it across the documents
=A0 =A0 produced by the
=A0 =A0 WG.

=A0 =A0 Cheers,

=A0 =A0 Simon




=A0 =A0 Il 30/10/2012 10:33, Christian Groves ha scritto:
=A0 =A0 > Hello Simon,
=A0 =A0 >
=A0 =A0 > When you say that you want to remove "all" the data = model stuff from
=A0 =A0 > the framework can you be a bit more specific as to what parts<= br> =A0 =A0 you want
=A0 =A0 > removed?
=A0 =A0 >
=A0 =A0 > Regards, Christian
=A0 =A0 >
=A0 =A0 > On 30/10/2012 7:03 PM, Simon Pietro Romano wrote:
=A0 =A0 >> Hi all,
=A0 =A0 >>
=A0 =A0 >> just to be clear on the current structure of the data mode= l schema:
=A0 =A0 >> all the things you find there were 'extracted' (by= Roberta and me)
=A0 =A0 >> from information currently contained inside the framework = draft (as
=A0 =A0 >> well as from some side documents, associated with either t= he data
=A0 =A0 >> model or the envisaged call flows). So, unless we have
=A0 =A0 misinterpreted
=A0 =A0 >> the above document(s) (which is obviously possible), we sh= ould
=A0 =A0 first
=A0 =A0 >> of all focus on the framework in order to try and converge= on an
=A0 =A0 >> agreed-upon CLUE architecture. Once done with this, we can=
=A0 =A0 fine-tune
=A0 =A0 >> the data model. As I already stated on this list, it is my= personal
=A0 =A0 >> opinion that we should remove from the framework document = all
=A0 =A0 of the
=A0 =A0 >> data-model stuff that it currently contains, and rather fo= cus on a
=A0 =A0 >> clear definition of framework components and interfaces. I=
=A0 =A0 might look
=A0 =A0 >> naif, but I would like to arrive at an 'ordinary' = set of documents:
=A0 =A0 >> (i) =A0general framework; (ii) data model; (iii) clue prot= ocol (with
=A0 =A0 >> advertisement and configuration messages); (iv) call flows= (showing
=A0 =A0 >> how SDP O/A and CLUE protocol messages concur in effective= ly
=A0 =A0 setting
=A0 =A0 >> up a CLUE session).
=A0 =A0 >>
=A0 =A0 >> As to the 'UML vs XML' querelle, I would suggest t= hat:
=A0 =A0 >>
=A0 =A0 >> 1. Both UML class diagrams and XML schema can be adopted f= or the
=A0 =A0 >> description of the data model, i.e., the STATIC part of th= e
=A0 =A0 >> framework, associated with the description of what some of= you
=A0 =A0 >> properly called a 'CLUE instance'; 2. UML sequence= diagrams can be
=A0 =A0 >> adopted to describe CLUE call flows, i.e. the DYNAMIC part= of the
=A0 =A0 >> framework, which clearly envisages the co-existence of SDP= and CLUE
=A0 =A0 >> protocol messages. XML schemas are not suitable for this d= ynamic
=A0 =A0 >> part.
=A0 =A0 >>
=A0 =A0 >> This said, it is clear that CLUE protocol messages =A0(in = particular,
=A0 =A0 >> CLUE advertisements) will be constructed by leveraging inf= ormation
=A0 =A0 >> contained inside a CLUE instance. Which parts of a CLUE in= stance
=A0 =A0 >> should go into an advertisement and which should be carrie= d inside
=A0 =A0 >> SDP can be a matter of discussion.
=A0 =A0 >>
=A0 =A0 >> My 2 cents,
=A0 =A0 >>
=A0 =A0 >> Simon
=A0 =A0 >>
=A0 =A0 >>
=A0 =A0 >> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scr= itto:
=A0 =A0 >>
=A0 =A0 >>> On 10/29/12 6:23 PM, Roni Even wrote:
=A0 =A0 >>>> Paul,
=A0 =A0 >>>> This was the statement I answered "no" =A0 =A0 >>>> " The general agreement on the call is that t= he data model as
=A0 =A0 >>>> reflected in draft-presta-clue-data-model-s= chema describes
=A0 =A0 the data
=A0 =A0 >>>> needed by the CLUE application"
=A0 =A0 >>>> I disagree that it reflects that data needed by a = CLUE
=A0 =A0 application
=A0 =A0 >>>> and I explained why.
=A0 =A0 >>>
=A0 =A0 >>> OK, fair enough.
=A0 =A0 >>>
=A0 =A0 >>> Mary can comment, but my take was that the point of he= r
=A0 =A0 question was
=A0 =A0 >>> to distinguish between two alternatives:
=A0 =A0 >>> - the data model represents all the data needed by the= clue app.
=A0 =A0 >>> =A0(which implies to me that it encompasses all the da= ta in the
=A0 =A0 >>> =A0framework.)
=A0 =A0 >>> - the data model represents the data to be exchanged i= n =A0clue
=A0 =A0 >>> messages.
=A0 =A0 >>>
=A0 =A0 >>> It is a bigger deal if the framework includes things t= hat are not
=A0 =A0 >>> needed by the clue application. I was of the impressio= n that,
=A0 =A0 except
=A0 =A0 >>> for some fine tuning, we were largely in agreement on = the
=A0 =A0 framework.
=A0 =A0 >>>
=A0 =A0 >>> If we don't have consensus on *that* then resolvin= g that is of
=A0 =A0 >>> higher priority that much of the other stuff we are di= scussing.
=A0 =A0 >>>
=A0 =A0 >>> Thanks,
=A0 =A0 >>> Paul
=A0 =A0 >>>
=A0 =A0 >>>> Roni
=A0 =A0 >>>>
=A0 =A0 >>>> -----Original Message-----
=A0 =A0 >>>> From: clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>
=
=A0 =A0 <mailto:clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>>
=A0 =A0 >>>> [mailto:clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>]=
=A0 =A0 On Behalf Of Paul Kyzivat
=A0 =A0 >>>> Sent: 29 October, 2012 9:46 PM
=A0 =A0 >>>> To: clue@ietf.org <mailto:clue@ietf.org>
=A0 =A0 <mailto:clue@= ietf.org <mailto:= clue@ietf.org>>
=A0 =A0 >>>> Subject: Re: [clue] Data model - agreement on obje= ctive and basic
=A0 =A0 >>>> approach
=A0 =A0 >>>>
=A0 =A0 >>>> On 10/29/12 3:19 PM, Roni Even wrote:
=A0 =A0 >>>>> Hi,
=A0 =A0 >>>>>
=A0 =A0 >>>>> My view is 'no". I still fail to see = the need for the encoding
=A0 =A0 >>>>> groups and individual encodes.
=A0 =A0 >>>>>
=A0 =A0 >>>>> In the current definition of capture scene, I = am not sure
=A0 =A0 what is
=A0 =A0 >>>>> the meaning of different individual encodes an= d eventually the
=A0 =A0 >>>>> receiver can define what it can receive (Typic= ally H.264 is
=A0 =A0 >>>>> symmetric in terms of profile but does not nee= d to be in the
=A0 =A0 >>>>> level) and can ask for specific resolution wit= h the SDP image
=A0 =A0 >>>>> attribute
=A0 =A0 >>>>
=A0 =A0 >>>> ISTM that you are answering a different question t= han the one
=A0 =A0 Mary
=A0 =A0 >>>> asked.
=A0 =A0 >>>> You seem to be saying that you disagree with the f= ramework as
=A0 =A0 it is
=A0 =A0 >>>> - that
=A0 =A0 >>>> it can/should be simpler.
=A0 =A0 >>>>
=A0 =A0 >>>> That is a separate question. If such changes were = made it might
=A0 =A0 >>>> affect a lot.
=A0 =A0 >>>>
=A0 =A0 >>>> Thanks,
=A0 =A0 >>>> Paul
=A0 =A0 >>>>
=A0 =A0 >>>>> Roni Even
=A0 =A0 >>>>>
=A0 =A0 >>>>> *From:*clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>
<= /div>
=A0 =A0 <mailto:clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>>
=A0 =A0 >>>>> [mailto:clue-bounces@ietf.org
=A0 =A0 <mailto:clue-bounces@ietf.org>] *On Behalf Of *Mary Barnes

=A0 =A0 >>>>> *Sent:* 29 October, 2012 7:52 PM
=A0 =A0 >>>>> *To:* CLUE
=A0 =A0 >>>>> *Subject:* [clue] Data model - agreement on ob= jective and basic
=A0 =A0 >>>>> approach
=A0 =A0 >>>>>
=A0 =A0 >>>>> On the call earlier today, we also discussed t= he data model.
=A0 =A0 =A0The
=A0 =A0 >>>>> general agreement on the call is that the data= model as
=A0 =A0 reflected
=A0 =A0 >>>>> in draft-presta-clue-data-model-schema = describes the data needed
=A0 =A0 >>>>> by the CLUE application - i.e., it's the C= LUE instance
=A0 =A0 concept. It
=A0 =A0 >>>>> does not directly reflect the contents of a CL= UE message. =A0The
=A0 =A0 >>>>> application data would be used to populate CLU= E messages, as
=A0 =A0 well
=A0 =A0 >>>>> as SDP and would reflect updates based on both= the CLUE and SDP
=A0 =A0 >>>>> signaling.
=A0 =A0 >>>>>
=A0 =A0 >>>>> If we can get agreement on that before the mee= ting, I
=A0 =A0 believe our
=A0 =A0 >>>>> discussions can be much more productive. If fo= lks could please
=A0 =A0 >>>>> reply "Yes" or "No" reflec= ting agreement with the above, that
=A0 =A0 >>>>> would be helpful. =A0If you reply "No&quo= t;, please explain why.
=A0 =A0 >>>>>
=A0 =A0 >>>>> Regards,
=A0 =A0 >>>>>
=A0 =A0 >>>>> Mary
=A0 =A0 >>>>>
=A0 =A0 >>>>> as CLUE WG co-chair
=A0 =A0 >>>>>
=A0 =A0 >>>>>
=A0 =A0 >>>>>
=A0 =A0 >>>>> _______________________________________= ________
=A0 =A0 >>>>> clue mailing list
=A0 =A0 >>>>> clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org

=A0 =A0 <mailto:clue@= ietf.org>>
=A0 =A0 >>>>> https://www.ietf.org/mailman/listinfo/clu= e
=A0 =A0 >>>>>
=A0 =A0 >>>>
=A0 =A0 >>>> ___________________________________________= ____
=A0 =A0 >>>> clue mailing list
=A0 =A0 >>>> clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org

=A0 =A0 <mailto:clue@= ietf.org>>
=A0 =A0 >>>> https://www.ietf.org/mailman/listinfo/clue
=A0 =A0 >>>>
=A0 =A0 >>>>
=A0 =A0 >>>
=A0 =A0 >>> _______________________________________________=
=A0 =A0 >>> clue mailing list
=A0 =A0 >>> clu= e@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org

=A0 =A0 <mailto:clue@= ietf.org>>
=A0 =A0 >>> https://www.ietf.org/mailman/listinfo/clue =A0 =A0 >>>
=A0 =A0 >>
=A0 =A0 >> _\\|//_
=A0 =A0 >> =A0 =A0 =A0 ( O-O )
=A0 =A0 >> =A0~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~= ~~~~~~~~~~~
=A0 =A0 >> Simon Pietro Romano
=A0 =A0 >> Universita' di Napoli Federico II
=A0 =A0 >> =A0Computer Engineering Department
=A0 =A0 >> =A0 Phone: +39 081 7683823 <tel:%2B39%20081%20= 7683823> -- Fax:
=A0 =A0 +39 081 7683816 <tel:%2B39%20081%207683816>
=A0 =A0 >> =A0e-mail: spromano@unina.it <mailto:spromano@unina.it>
=A0 =A0 <mailto:s= promano@unina.it <mailto:spromano@unina.it>>

=A0 =A0 >>
=A0 =A0 >> <<Molti mi dicono che lo scoraggiamento =CB l'al= ibi degli =A0idioti. Ci
=A0 =A0 >> rifletto un istante; e mi scoraggio>>. Magritte.
=A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0oooO
=A0 =A0 >> =A0 ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~= ~~~~~
=A0 =A0 >> =A0 =A0 =A0 =A0\ ( =A0 =A0 =A0 =A0 =A0 =A0( =A0 )
=A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \_) =A0 = =A0 =A0 =A0 =A0) /
=A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(_/
=A0 =A0 >>
=A0 =A0 >>
=A0 =A0 >>
=A0 =A0 >>
=A0 =A0 >>
=A0 =A0 >>
=A0 =A0 >>
=A0 =A0 >> _______________________________________________
=A0 =A0 >> clue mailing list
=A0 =A0 >> clue@ie= tf.org <mailto:cl= ue@ietf.org>
=A0 =A0 >> https://www.ietf.org/mailman/listinfo/clue
=A0 =A0 >
=A0 =A0 > _______________________________________________
=A0 =A0 > clue mailing list
=A0 =A0 > clue@ietf.o= rg <mailto:clue@i= etf.org>
=A0 =A0 > https://www.ietf.org/mailman/listinfo/clue
=A0 =A0 >

=A0 =A0 --
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_\\|//_<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0( O-O )<= br> =A0 =A0 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Simon Pietro Romano
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Universita' di Napoli Federico I= I
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Computer Science Department
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0Phone: +39 081 7683823 <tel:%2B39%20= 081%207683823> --
=A0 =A0 Fax: +39 081 7684219 <tel:%2B39%20081%207684219>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0e-mail: spromano@unina.it <mailto:spromano@unina.it>

=A0 =A0 http://www.comics.unina.it/simonpietro.romano

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

=A0 =A0 _______________________________________________
=A0 =A0 clue mailing list
=A0 =A0 clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/listinfo/clue

=A0 =A0 _______________________________________________
=A0 =A0 clue mailing list
=A0 =A0 clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/listinfo/clue




--f46d040711c5ea2ff504cd6ec6ba-- From mary.ietf.barnes@gmail.com Thu Nov 1 06:56: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 AE33E21F8B6A for ; Thu, 1 Nov 2012 06:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.226 X-Spam-Level: X-Spam-Status: No, score=-103.226 tagged_above=-999 required=5 tests=[AWL=0.372, 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 pOIqv79Hl5f5 for ; Thu, 1 Nov 2012 06:56:35 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 967C321F8B58 for ; Thu, 1 Nov 2012 06:56:34 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2046854lbo.31 for ; Thu, 01 Nov 2012 06:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zuqc+2PRsrxRwxDO0xj+9Hknx7m96hA8X7yTgWsVvas=; b=ozXfC+DEyQd5IVQ4TctAxLyh9E6rDoKA9MHrSFrk3fVb3zVW9djfZzP5dOK9Qwemh+ WOu6UX7yQXwo2EwDZ+WZbr9ZrzXwhXBlEwM59uFp1xGrUcEkWD3d5m/EDVTkeDSBpZb8 NC29lbSZrdXzKy/acu4rqUp0C7WGb/lXXZDCG5C9r1LeCirbdYw6NYUpBrWtp0woW7ZQ MKKn3IfUxLnS6naXPIP8rfxJ468xaRmHBD5a3D49xBc/m39QL1E8YEjG+IqV23JmrzyA tEJIm1LjFJtXPFcYPzQE6drHYMvgOPxvTWrrRMACSMnejRaGSu+yANw46vCMFcrl1csZ CISQ== MIME-Version: 1.0 Received: by 10.152.108.66 with SMTP id hi2mr36634076lab.11.1351778193526; Thu, 01 Nov 2012 06:56:33 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Thu, 1 Nov 2012 06:56:33 -0700 (PDT) Date: Thu, 1 Nov 2012 08:56:33 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec54eecc80a507804cd6f63f4 Subject: [clue] Help the NomCom X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 13:56:35 -0000 --bcaec54eecc80a507804cd6f63f4 Content-Type: text/plain; charset=ISO-8859-1 Per the following, the Nomcom chair would like to remind folks to provide feedback. It really is important for them to get community input to make a conscientious decision. Mary. CLUE WG co-chair ---------- Forwarded message ---------- From: NomCom Chair Date: Thu, Nov 1, 2012 at 7:17 AM Subject: CORRECTION: Help the NomCom To: Working Group Chairs The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org --bcaec54eecc80a507804cd6f63f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Per the following, the Nomcom chair would like to remind folks to provide f= eedback. It really is important for them to get community input to make a c= onscientious decision.

Mary.
CLUE WG co-chair<= br>
---------- Forwarded message ----------
F= rom: NomCom Chair <<= a href=3D"mailto:nomcom-chair@ietf.org">nomcom-chair@ietf.org>
Date: Thu, Nov 1, 2012 at 7:17 AM
Subject: CORRECTION: Help the NomComTo: Working Group Chairs <wgchair= s@ietf.org>

The IETF Nominations Committee (NomCom) continues to seek input from
the IETF Community. The NomCom would greatly appreciate any help you
could provide in making members of your working group aware of ways in
which they can provide valuable feedback to the NomCom.

In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11= .

The final list of candidates (as per RFC 5680) that the NomCom is
considering for open positions can be found at:
https://www.ietf.org/group/nomcom/2012/input/

The NomCom will be holding office hours during IETF 85, Monday-
Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes
comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering.

Note: A list of leadership positions that the NomCom is considering can be<= br> found at: https://www.ietf.org/group/nomcom/2012/

If the NomCom office hours are inconvenient for you or if you cannot
attend IETF 85, the NomCom is happy to take community input via email
to nomcom12 at ietf.org. = Additionally, the NomCom is happy to arrange a
meeting outside of office hours, just send us email and we can set
something up.

Comments on specific candidates can also be provided to the NomCom
via the web feedback tool:
https://www.ietf.org/group/nomcom/2012/input/

Thank you for your help,
- Matt Lepinski
=A0 nomcom-chair at ietf.org<= /a>

--bcaec54eecc80a507804cd6f63f4-- From mary.ietf.barnes@gmail.com Thu Nov 1 07: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 0B16B21F86CE for ; Thu, 1 Nov 2012 07:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1EUD9vgscOX for ; Thu, 1 Nov 2012 07:35:28 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8C221F87FB for ; Thu, 1 Nov 2012 07:35:27 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2048561lam.31 for ; Thu, 01 Nov 2012 07:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CeESuaa9ksLwgPCjTSJvrChI74xecgZ9pdkNTkq3qjM=; b=MHOvMKKFuKrmAM+eNqYXYdeXND2+MuEksWArIPhq9XcBAOEh6IM+T2OqZ/8ZsKhJtc FiLqJERIfQHtGWVbhOJND8k5mqNws7jW9DvJMRzWmpOngRKGIQXdxzwY4E7FIcx4+jzS vxaHIYL8ed2/j9l//bWB0+l5zhHmhr3lE72GbTKoDlGmitZ1EK8Y2/CWKYBpraxQKwU3 +5Q1HwiNqzNMa2l0Z8rKVrX5zXGJ1HXhtu9vSa1kt/n6O3OmkRJxDpOS/T9Ly2IXqOcS RFb+yMtq3u2urF+YcnBty1+3XBzxKxutxkSlxut7IdkF8Y2j/LCWPvKhup/zduTopgdX 8YDQ== MIME-Version: 1.0 Received: by 10.112.9.2 with SMTP id v2mr1833570lba.54.1351780526183; Thu, 01 Nov 2012 07:35:26 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Thu, 1 Nov 2012 07:35:26 -0700 (PDT) In-Reply-To: <5091DEF5.6010608@nteczone.com> References: <5091DEF5.6010608@nteczone.com> Date: Thu, 1 Nov 2012 09:35:26 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=e0cb4efe287a13d44704cd6fee92 Cc: "clue@ietf.org" Subject: Re: [clue] CLUE media capture 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, 01 Nov 2012 14:35:32 -0000 --e0cb4efe287a13d44704cd6fee92 Content-Type: text/plain; charset=ISO-8859-1 I'll let other WG members respond to the details of this proposal. It would be helpful if you could forward the document submitted to Q5 unless it really is as brief as you suggest. I also have one important comment below. [MB] Mary. CLUE WG co-chair On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > > CLUE media capture description > draft-groves-clue-capture-**attr-00 > > I won't be attending the IETF next week so as a pre-cursor to next weeks > CLUE WG meeting I thought i'd put a few words together about > draft-groves-clue-capture-**attr-0 > http://datatracker.ietf.org/**doc/draft-groves-clue-capture-**attr/ > > The main idea behind the draft is that a CLUE advertisement should include > enough information for the receiver to make an educated decision about what > captures it chooses. Having a had a close look at the content attribute I > think (for the reasons outlined in the draft) it is insufficient to fully > describe the multi-stream conferencing environments that CLUE is > addressing/enabling. > > A contribution with essentially the same text as the draft was submitted > to the recent Q.5/16 meeting to solicit feedback from the people at the > meeting about the different parameters presented in the draft. In general I > think people were in agreement that the current Content attribute was not > sufficient. However it was noted that it needs to be considered how CLUE > maps to the existing usages of the content attribute and mapping to H.239. > [MB] While Q.5 might need to do this, it is absolutely out of scope for the CLUE WG. It is not in our charter and the requirements clearly state such: "Non IETF protocol based systems, such as those based on ITU-T Rec. H.323, are out of scope." [/MB] > > Below is a list of attributes and comments. If I've left out anything or > mispoken hopefully Steve Botzko can correct me. > > Presentation > ------------ > People thought it was worthwhile to know if a capture related to a > presentation. There was some questioning if it was worthwhile to know if > the capture was slides, images etc. It was thought it may help where > multiple presentation streams were used. > > View > ---- > It was clarified that the aim of the attribute is to allow a remote end to > make an automatic decision on what region of the scene it wants to see. The > idea is that there is a standard keyword that the remote end could scan for > e.g. lectern. This is a way of providing meaning to a particular spatial > area. > > Language > -------- > There seemed to be general support for a language parameter. > > Role > ---- > It was thought that role could be related to "participants" or "material". > Currently the attribute only discusses role from the aspect of a > participant. It was also noted that the role may change based on meeting > type. For example: in the medical use case there could be "Surgeon", > "Professor", in an accessible conference there could be an "Interpreter" or > "signer". With respect to Materials it was thought presentation could show > something like "Agenda", "Contribution". > > Priority > -------- > There was some discussion as to whether this was needed. It was thought > that if captures were properly described then priority wouldn't be needed > as the remote end could make an educated decision about what it wants. At > the moment with the minimal set of attributes it was thought that priority > at least helped the remote end make a decision. > > Dynamic > ------- > I think people were OK with this being optional. > > > Embedded Text > ------------- > Again I think people thought it was reasonable. It was clarified this > could also be used to indicate captioning was being used with the capture. > > > Supplementary description > ------------------------- > There was some question about how this related to side bar conferences. It > was clarified this was mainly about the case where information (captures) > were provided by people (or devices) who were not captured by the > conference video. > > Telepresence > ------------ > This parameter probably had the least support/understanding. I was noted > that CLUE was to allow multi-stream operation it didn't necessarily > indicate/mandate a telepresence experience. > > Hopefully this provides some further background for the CLUE discussions. > If the group could come to some general agreement about each of the > parameters then I could work on some specific text for the framework (or > whatever document we decide). > > Regards, Christian > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --e0cb4efe287a13d44704cd6fee92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'll let other WG members respond to the details of this proposal. =A0I= t would be helpful if you could forward the document submitted to Q5 unless= it really is as brief as you suggest. =A0I also have one important comment= below. [MB]

Mary.
CLUE WG co-chair

On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves = <Chri= stian.Groves@nteczone.com> wrote:

CLUE media capture description
draft-groves-clue-capture-attr-00

I won't be attending the IETF next week so as a pre-cursor to next week= s CLUE WG meeting =A0I thought i'd put a few words together about draft= -groves-clue-capture-attr-0
http://datatracker.ietf.org/doc/draft-groves-clue= -capture-attr/

The main idea behind the draft is that a CLUE advertisement should include = enough information for the receiver to make an educated decision about what= captures it chooses. Having a had a close look at the content attribute I = think (for the reasons outlined in the draft) it is insufficient to fully d= escribe the multi-stream conferencing environments that CLUE is addressing/= enabling.

A contribution with essentially the same text as the draft was submitted to= the recent Q.5/16 meeting to solicit feedback from the people at the meeti= ng about the different parameters presented in the draft. In general I thin= k people were in agreement that the current Content attribute was not suffi= cient. However it was noted that it needs to be considered how CLUE maps to= the existing usages of the content attribute and mapping to H.239.
[MB] While Q.5 might need to do this, it is absolutely ou= t of scope for the CLUE WG. It is not in our charter and the requirements c= learly state such:
=A0 =A0"Non IETF protocol based systems, = such as
=A0 =A0those based on ITU-T Rec. H.323, are out of scope."
<= div>[/MB]

Below is a list of attributes and comments. If I've left out anything o= r mispoken hopefully Steve Botzko can correct me.

Presentation
------------
People thought it was worthwhile to know if a capture related to a presenta= tion. There was some questioning if it was worthwhile to know if the captur= e was slides, images etc. It was thought it may help where multiple present= ation streams were used.

View
----
It was clarified that the aim of the attribute is to allow a remote end to = make an automatic decision on what region of the scene it wants to see. The= idea is that there is a standard keyword that the remote end could scan fo= r e.g. lectern. This is a way of providing meaning to a particular spatial = area.

Language
--------
There seemed to be general support for a language parameter.

Role
----
It was thought that role could be related to "participants" or &q= uot;material". Currently the attribute only discusses role from the as= pect of a participant. It was also noted that the role may change based on = meeting type. For example: in the medical use case there could be "Sur= geon", "Professor", in an accessible conference there could = be an "Interpreter" or "signer". With respect to Materi= als it was thought presentation could show something like "Agenda"= ;, "Contribution".

Priority
--------
There was some discussion as to whether this was needed. It was thought tha= t if captures were properly described then priority wouldn't be needed = as the remote end could make an educated decision about what it wants. At t= he moment with the minimal set of attributes it was thought that priority a= t least helped the remote end make a decision.

Dynamic
-------
I think people were OK with this being optional.


Embedded Text
-------------
Again I think people thought it was reasonable. It was clarified this could= also be used to indicate captioning was being used with the capture.


Supplementary description
-------------------------
There was some question about how this related to side bar conferences. It = was clarified this was mainly about the case where information (captures) w= ere provided by people (or devices) who were not captured by the conference= video.

Telepresence
------------
This parameter probably had the least support/understanding. I was noted th= at CLUE was to allow multi-stream operation it didn't necessarily indic= ate/mandate a telepresence experience.

Hopefully this provides some further background for the CLUE discussions. I= f the group could come to some general agreement about each of the paramete= rs then I could work on some specific text for the framework (or whatever d= ocument we decide).

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

--e0cb4efe287a13d44704cd6fee92-- From roni.even@mail01.huawei.com Thu Nov 1 07:54: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 5BA7D21F8D8F for ; Thu, 1 Nov 2012 07:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MefUnNs3YD3Q for ; Thu, 1 Nov 2012 07:54:04 -0700 (PDT) Received: from hwsga02-in.huaweimarine.com (hwsga02-in.huaweimarine.com [119.145.15.224]) by ietfa.amsl.com (Postfix) with ESMTP id 7C80721F8D96 for ; Thu, 1 Nov 2012 07:54:03 -0700 (PDT) Received: from szxpml203-edg.exmail.huawei.com ([172.17.1.119]) by hwsga02-in.huaweimarine.com (MOS 4.1.3-GA) with ESMTP id ADY44678; Thu, 1 Nov 2012 22:53:47 +0800 X-Mirapoint-Received-SPF: 172.17.1.119 szxpml203-edg.exmail.huawei.com 5 none X-Mirapoint-Received-SPF: 172.17.1.119 szxpml203-edg.exmail.huawei.com 5 none X-Mirapoint-Received-SPF: 172.17.1.119 szxpml203-edg.exmail.huawei.com 5 none Received: from SZXPML403-HUB.exmail.huawei.com (10.82.67.164) by szxpml203-edg.exmail.huawei.com (172.24.2.14) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Nov 2012 22:53:40 +0800 Received: from SZXPML504-MBS.exmail.huawei.com ([169.254.4.23]) by szxpml403-hub.exmail.huawei.com ([10.82.67.164]) with mapi id 14.01.0323.003; Thu, 1 Nov 2012 22:53:46 +0800 From: Roni Even To: Mary Barnes , Christian Groves Thread-Topic: [clue] CLUE media capture description Thread-Index: AQHNt9kLs0aIbOq9oE2zxmcqifwDWJfUhnUAgACKW78= Date: Thu, 1 Nov 2012 14:53:45 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C205B622BA@szxpml504-mbs.exmail.huawei.com> References: <5091DEF5.6010608@nteczone.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.63] Content-Type: multipart/alternative; boundary="_000_760B7D45D1EFF74988DBF5C2122830C205B622BAszxpml504mbsexm_" MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] CLUE media capture 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, 01 Nov 2012 14:54:05 -0000 --_000_760B7D45D1EFF74988DBF5C2122830C205B622BAszxpml504mbsexm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mary, This draft was submitted more than a month ago and the purpose is to add mo= re content options to allow the consumer to get a better selection and rela= tes to ticket #10 http://trac.tools.ietf.org/wg/clue/trac/ticket/10 Roni Even ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Thursday, November 01, 2012 4:35 PM To: Christian Groves Cc: clue@ietf.org Subject: Re: [clue] CLUE media capture description I'll let other WG members respond to the details of this proposal. It woul= d be helpful if you could forward the document submitted to Q5 unless it re= ally is as brief as you suggest. I also have one important comment below. = [MB] Mary. CLUE WG co-chair On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves > wrote: CLUE media capture description draft-groves-clue-capture-attr-00 I won't be attending the IETF next week so as a pre-cursor to next weeks CL= UE WG meeting I thought i'd put a few words together about draft-groves-cl= ue-capture-attr-0 http://datatracker.ietf.org/doc/draft-groves-clue-capture-attr/ The main idea behind the draft is that a CLUE advertisement should include = enough information for the receiver to make an educated decision about what= captures it chooses. Having a had a close look at the content attribute I = think (for the reasons outlined in the draft) it is insufficient to fully d= escribe the multi-stream conferencing environments that CLUE is addressing/= enabling. A contribution with essentially the same text as the draft was submitted to= the recent Q.5/16 meeting to solicit feedback from the people at the meeti= ng about the different parameters presented in the draft. In general I thin= k people were in agreement that the current Content attribute was not suffi= cient. However it was noted that it needs to be considered how CLUE maps to= the existing usages of the content attribute and mapping to H.239. [MB] While Q.5 might need to do this, it is absolutely out of scope for the= CLUE WG. It is not in our charter and the requirements clearly state such: "Non IETF protocol based systems, such as those based on ITU-T Rec. H.323, are out of scope." [/MB] Below is a list of attributes and comments. If I've left out anything or mi= spoken hopefully Steve Botzko can correct me. Presentation ------------ People thought it was worthwhile to know if a capture related to a presenta= tion. There was some questioning if it was worthwhile to know if the captur= e was slides, images etc. It was thought it may help where multiple present= ation streams were used. View ---- It was clarified that the aim of the attribute is to allow a remote end to = make an automatic decision on what region of the scene it wants to see. The= idea is that there is a standard keyword that the remote end could scan fo= r e.g. lectern. This is a way of providing meaning to a particular spatial = area. Language -------- There seemed to be general support for a language parameter. Role ---- It was thought that role could be related to "participants" or "material". = Currently the attribute only discusses role from the aspect of a participan= t. It was also noted that the role may change based on meeting type. For ex= ample: in the medical use case there could be "Surgeon", "Professor", in an= accessible conference there could be an "Interpreter" or "signer". With re= spect to Materials it was thought presentation could show something like "A= genda", "Contribution". Priority -------- There was some discussion as to whether this was needed. It was thought tha= t if captures were properly described then priority wouldn't be needed as t= he remote end could make an educated decision about what it wants. At the m= oment with the minimal set of attributes it was thought that priority at le= ast helped the remote end make a decision. Dynamic ------- I think people were OK with this being optional. Embedded Text ------------- Again I think people thought it was reasonable. It was clarified this could= also be used to indicate captioning was being used with the capture. Supplementary description ------------------------- There was some question about how this related to side bar conferences. It = was clarified this was mainly about the case where information (captures) w= ere provided by people (or devices) who were not captured by the conference= video. Telepresence ------------ This parameter probably had the least support/understanding. I was noted th= at CLUE was to allow multi-stream operation it didn't necessarily indicate/= mandate a telepresence experience. Hopefully this provides some further background for the CLUE discussions. I= f the group could come to some general agreement about each of the paramete= rs then I could work on some specific text for the framework (or whatever d= ocument we decide). Regards, Christian _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_760B7D45D1EFF74988DBF5C2122830C205B622BAszxpml504mbsexm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mary,

This draft was submitted more than a month ago and the purpose is to add= more content options to allow the consumer to get a better selection and r= elates to ticket #10 http://trac.t= ools.ietf.org/wg/clue/trac/ticket/10

 

Roni Even

From: clue-bounces@ietf.org [clue-bounces@i= etf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Thursday, November 01, 2012 4:35 PM
To: Christian Groves
Cc: clue@ietf.org
Subject: Re: [clue] CLUE media capture description

I'll let other WG members respond to the details of this proposal. &nb= sp;It would be helpful if you could forward the document submitted to Q5 un= less it really is as brief as you suggest.  I also have one important = comment below. [MB]

Mary.
CLUE WG co-chair

On Wed, Oct 31, 2012 at 9:31 PM, Christian Grove= s <Chri= stian.Groves@nteczone.com> wrote:

CLUE media capture description
draft-groves-clue-capture-attr-00

I won't be attending the IETF next week so as a pre-cursor to next weeks CL= UE WG meeting  I thought i'd put a few words together about draft-grov= es-clue-capture-attr-0
http://datatracker.ietf.org/doc/draft-groves-clue= -capture-attr/

The main idea behind the draft is that a CLUE advertisement should include = enough information for the receiver to make an educated decision about what= captures it chooses. Having a had a close look at the content attribute I = think (for the reasons outlined in the draft) it is insufficient to fully describe the multi-stream confer= encing environments that CLUE is addressing/enabling.

A contribution with essentially the same text as the draft was submitted to= the recent Q.5/16 meeting to solicit feedback from the people at the meeti= ng about the different parameters presented in the draft. In general I thin= k people were in agreement that the current Content attribute was not sufficient. However it was noted tha= t it needs to be considered how CLUE maps to the existing usages of the con= tent attribute and mapping to H.239.
[MB] While Q.5 might need to do this, it is absolutely out of scope fo= r the CLUE WG. It is not in our charter and the requirements clearly state = such:
   "Non IETF protocol based systems, such as
   those based on ITU-T Rec. H.323, are out of scope."<= /div>
[/MB]

Below is a list of attributes and comments. If I've left out anything or mi= spoken hopefully Steve Botzko can correct me.

Presentation
------------
People thought it was worthwhile to know if a capture related to a presenta= tion. There was some questioning if it was worthwhile to know if the captur= e was slides, images etc. It was thought it may help where multiple present= ation streams were used.

View
----
It was clarified that the aim of the attribute is to allow a remote end to = make an automatic decision on what region of the scene it wants to see. The= idea is that there is a standard keyword that the remote end could scan fo= r e.g. lectern. This is a way of providing meaning to a particular spatial area.

Language
--------
There seemed to be general support for a language parameter.

Role
----
It was thought that role could be related to "participants" or &q= uot;material". Currently the attribute only discusses role from the as= pect of a participant. It was also noted that the role may change based on = meeting type. For example: in the medical use case there could be "Surgeon", "Professor", in an accessible conf= erence there could be an "Interpreter" or "signer". Wit= h respect to Materials it was thought presentation could show something lik= e "Agenda", "Contribution".

Priority
--------
There was some discussion as to whether this was needed. It was thought tha= t if captures were properly described then priority wouldn't be needed as t= he remote end could make an educated decision about what it wants. At the m= oment with the minimal set of attributes it was thought that priority at least helped the remote end make a decisio= n.

Dynamic
-------
I think people were OK with this being optional.


Embedded Text
-------------
Again I think people thought it was reasonable. It was clarified this could= also be used to indicate captioning was being used with the capture.


Supplementary description
-------------------------
There was some question about how this related to side bar conferences. It = was clarified this was mainly about the case where information (captures) w= ere provided by people (or devices) who were not captured by the conference= video.

Telepresence
------------
This parameter probably had the least support/understanding. I was noted th= at CLUE was to allow multi-stream operation it didn't necessarily indicate/= mandate a telepresence experience.

Hopefully this provides some further background for the CLUE discussions. I= f the group could come to some general agreement about each of the paramete= rs then I could work on some specific text for the framework (or whatever d= ocument we decide).

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

--_000_760B7D45D1EFF74988DBF5C2122830C205B622BAszxpml504mbsexm_-- From pkyzivat@alum.mit.edu Thu Nov 1 08:21:34 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1841621F8B55 for ; Thu, 1 Nov 2012 08:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 K5iN4j1eyHAm for ; Thu, 1 Nov 2012 08:21:33 -0700 (PDT) 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 3967221F8DF2 for ; Thu, 1 Nov 2012 08:21:32 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta14.westchester.pa.mail.comcast.net with comcast id JEPs1k0051swQuc5EFMbfW; Thu, 01 Nov 2012 15:21:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id JFRM1k00P3ZTu2S3bFRMg1; Thu, 01 Nov 2012 15:25:21 +0000 Message-ID: <50929378.3010701@alum.mit.edu> Date: Thu, 01 Nov 2012 11:21:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Simon Pietro Romano References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:21:34 -0000 On 10/30/12 4:03 AM, Simon Pietro Romano wrote: > Hi all, > > just to be clear on the current structure of the data model schema: all > the things you find there were 'extracted' (by Roberta and me) from > information currently contained inside the framework draft (as well as > from some side documents, associated with either the data model or the > envisaged call flows). So, unless we have misinterpreted the above > document(s) (which is obviously possible), we should first of all focus > on the framework in order to try and converge on an agreed-upon CLUE > architecture. Once done with this, we can fine-tune the data model. I agree with the above. > As to the 'UML vs XML' querelle, I would suggest that: I don't want this to become a point of disagreement. I think it is important to formally define the data and data relationships we are talking about. UML and XML both do that, using different approaches and at somewhat different levels of abstraction. *My* preference for UML is that it is at a higher level of abstraction - it is entirely divorced from encodings. But XML can be used as a modeling tool even when it is not intended to be used as an encoding. The most important thing is that the people doing the work all understand the model. More people are comfortable that they can understand an XML model, so I agreed with going that way. But then we need need to be careful that people understand when the XML is intended as a *model*, and when it is intended to be used as an *encoding*. > 1. Both UML class diagrams and XML schema can be adopted for the > description of the data model, i.e., the STATIC part of the framework, > associated with the description of what some of you properly called a > 'CLUE instance'; IMO, regardless of intent, it is currently hard to tell by looking whether the current version of the model is a representation of an *instance* or of an *advertisement*. ISTM that the "clueInfo" element maps almost 1:1 onto an advertisement. An instance will require more state. E.g. - the content of the most recently sent advertisement - the content of the most recently received configuration - the content of the most recently completed SDP O/A exchange - the mapping of the configuration to physical resources such as physical devices, encoders, decoders, etc. This is tricky. Some of the information about resources is fundamentally implementation specific, so finding where to draw the line between what must be modeled and what must not is hard. Thanks, Paul > 2. UML sequence diagrams can be adopted to describe CLUE call flows, > i.e. the DYNAMIC part of the framework, which clearly envisages the > co-existence of SDP and CLUE protocol messages. XML schemas are not > suitable for this dynamic part. > > This said, it is clear that CLUE protocol messages (in particular, CLUE > advertisements) will be constructed by leveraging information contained > inside a CLUE instance. Which parts of a CLUE instance should go into an > advertisement and which should be carried inside SDP can be a matter of > discussion. > > My 2 cents, > > Simon > > > Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: > >> On 10/29/12 6:23 PM, Roni Even wrote: >>> Paul, >>> This was the statement I answered "no" >>> " The general agreement on the call is that the data model as >>> reflected in >>> draft-presta-clue-data-model-schema describes the data needed by the CLUE >>> application" >>> I disagree that it reflects that data needed by a CLUE application and I >>> explained why. >> >> OK, fair enough. >> >> Mary can comment, but my take was that the point of her question was >> to distinguish between two alternatives: >> - the data model represents all the data needed by the clue app. >> (which implies to me that it encompasses all the data in the >> framework.) >> - the data model represents the data to be exchanged in >> clue messages. >> >> It is a bigger deal if the framework includes things that are not >> needed by the clue application. I was of the impression that, except >> for some fine tuning, we were largely in agreement on the framework. >> >> If we don't have consensus on *that* then resolving that is of higher >> priority that much of the other stuff we are discussing. >> >> Thanks, >> Paul >> >>> Roni >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>> Kyzivat >>> Sent: 29 October, 2012 9:46 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] Data model - agreement on objective and basic >>> approach >>> >>> On 10/29/12 3:19 PM, Roni Even wrote: >>>> Hi, >>>> >>>> My view is 'no". I still fail to see the need for the encoding groups >>>> and individual encodes. >>>> >>>> In the current definition of capture scene, I am not sure what is the >>>> meaning of different individual encodes and eventually the receiver >>>> can define what it can receive (Typically H.264 is symmetric in terms >>>> of profile but does not need to be in the level) and can ask for >>>> specific resolution with the SDP image attribute >>> >>> ISTM that you are answering a different question than the one Mary asked. >>> You seem to be saying that you disagree with the framework as it is - >>> that >>> it can/should be simpler. >>> >>> That is a separate question. If such changes were made it might affect a >>> lot. >>> >>> Thanks, >>> Paul >>> >>>> Roni Even >>>> >>>> *From:*clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org] *On Behalf >>>> Of *Mary Barnes >>>> *Sent:* 29 October, 2012 7:52 PM >>>> *To:* CLUE >>>> *Subject:* [clue] Data model - agreement on objective and basic >>>> approach >>>> >>>> On the call earlier today, we also discussed the data model. The >>>> general agreement on the call is that the data model as reflected in >>>> draft-presta-clue-data-model-schema describes the data needed by the >>>> CLUE application - i.e., it's the CLUE instance concept. It does not >>>> directly reflect the contents of a CLUE message. The application data >>>> would be used to populate CLUE messages, as well as SDP and would >>>> reflect updates based on both the CLUE and SDP signaling. >>>> >>>> If we can get agreement on that before the meeting, I believe our >>>> discussions can be much more productive. If folks could please reply >>>> "Yes" or "No" reflecting agreement with the above, that would be >>>> helpful. If you reply "No", please explain why. >>>> >>>> Regards, >>>> >>>> Mary >>>> >>>> as CLUE WG co-chair >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _\\|//_ > ( 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 pkyzivat@alum.mit.edu Thu Nov 1 08:55: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 1FF9921F8DB4 for ; Thu, 1 Nov 2012 08:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 jhVM8SXobLjQ for ; Thu, 1 Nov 2012 08:55:14 -0700 (PDT) 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 A6ACD21F8D55 for ; Thu, 1 Nov 2012 08:55:13 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id JB2X1k0071ap0As55FvJv2; Thu, 01 Nov 2012 15:55:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id JFvo1k00S3ZTu2S3iFvonl; Thu, 01 Nov 2012 15:55:48 +0000 Message-ID: <50929B5E.7010108@alum.mit.edu> Date: Thu, 01 Nov 2012 11:55:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> In-Reply-To: <508FAABC.2000404@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Data model - agreement on objective and basic approach X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 15:55:16 -0000 Simon, It is good to get a fresh perspective from someone who hasn't lived through the evolution of the current documents. I don't really know whether to comment on this as a chair or as an individual, or even how to distinguish the two. For the moment lets assume that the following comments are from me as an individual. On 10/30/12 6:23 AM, Simon Pietro Romano wrote: > Hi Christian, > > a rough estimation would be the following: > > a) keep sections 1 through 4 inside the framework document; > b) move sections 5 through 8 to the data model document IMO *moving* 5-8 to the data model would "gut" the framework. A lot of the descriptive information in these sections still needs to be in the framework. Some of the detail about specific elements, such as the lowest level elements and/or the values they can take on, would perhaps be better if moved to the data model, near to the schema definitions of them. (That will help minimize the chances for divergence with the schema, and remove unnecessary detail from the framework.) The stuff that remains in the framework will of course need to be repeated, with more detail, in the data model document. > c) move the XML schema to the data model document (final section of the > data model, which provides 'one possible' example of how to formally > describe the things in the document); At the expense of some difficulty in maintaining the document, I would find it helpful to have *elements* of the schema defined "in line" in the data model document, with the textual description of the element. Then a consolidated schema at the end. > d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the > protocol document; Again, I think it would gut the framework to move this entirely. Now that I look again, I find an asymmetry in the document. Section 9 is largely a discussion of what will be a Configuration message. But the description of what will be the Advertisement is spread across section 6-8. And 9.4 is really a high level intro to the complete protocol. I think the framework certainly needs something akin to the figure in 9.4. (But not precisely that figure.) I expect a protocol document to extensively elaborate on this and coordinate it with the information conveyed in sip. > e) move subsection 9.4 to the call flows document; No. *This* (or an improved version) is much more abstract that what I expect in a call flow document. I don't see how we can have a framework, or a protocol document, that doesn't have something like this in it. > f) move section 10 to the data model document; I agree that the framework is probably the wrong place for a discussion of extensibility. But addressing extensibility only in the data model document also isn't the answer. Certainly the protocol document needs to discuss extensibility. Depending on details of the division between protocol and data model, the data model doc may also need to address it. (The *encodings* of information from the data model that are exchanged via the protocol need to have and extensibility story. If those encodings are defined in the data model doc, then that is where to address it.) > g) move section 11 to the call flows document. Yes. Thanks, Paul > Obviously, the resulting framework document should be revised (and > enriched) in view of the proposed distribution of work inside the WG. I > would like it to represent an orchestration document, providing an > overview of issues, requirements, architecture and protocols. A sort of > summary reference for all of the related "drill-down" documents, each > expanding on a specific WG item (data model, protocol, call flows, etc.). > > I acknowledge the fact that this looks much like a revolution, but I > nonetheless believe that we already have most of the needed material at > hand and just need to better distribute it across the documents produced > by the WG. > > Cheers, > > Simon > > > > > Il 30/10/2012 10:33, Christian Groves ha scritto: >> Hello Simon, >> >> When you say that you want to remove "all" the data model stuff from >> the framework can you be a bit more specific as to what parts you want >> removed? >> >> Regards, Christian >> >> On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: >>> Hi all, >>> >>> just to be clear on the current structure of the data model schema: >>> all the things you find there were 'extracted' (by Roberta and me) >>> from information currently contained inside the framework draft (as >>> well as from some side documents, associated with either the data >>> model or the envisaged call flows). So, unless we have misinterpreted >>> the above document(s) (which is obviously possible), we should first >>> of all focus on the framework in order to try and converge on an >>> agreed-upon CLUE architecture. Once done with this, we can fine-tune >>> the data model. As I already stated on this list, it is my personal >>> opinion that we should remove from the framework document all of the >>> data-model stuff that it currently contains, and rather focus on a >>> clear definition of framework components and interfaces. I might look >>> naif, but I would like to arrive at an 'ordinary' set of documents: >>> (i) general framework; (ii) data model; (iii) clue protocol (with >>> advertisement and configuration messages); (iv) call flows (showing >>> how SDP O/A and CLUE protocol messages concur in effectively setting >>> up a CLUE session). >>> >>> As to the 'UML vs XML' querelle, I would suggest that: >>> >>> 1. Both UML class diagrams and XML schema can be adopted for the >>> description of the data model, i.e., the STATIC part of the >>> framework, associated with the description of what some of you >>> properly called a 'CLUE instance'; >>> 2. UML sequence diagrams can be adopted to describe CLUE call flows, >>> i.e. the DYNAMIC part of the framework, which clearly envisages the >>> co-existence of SDP and CLUE protocol messages. XML schemas are not >>> suitable for this dynamic part. >>> >>> This said, it is clear that CLUE protocol messages (in particular, >>> CLUE advertisements) will be constructed by leveraging information >>> contained inside a CLUE instance. Which parts of a CLUE instance >>> should go into an advertisement and which should be carried inside >>> SDP can be a matter of discussion. >>> >>> My 2 cents, >>> >>> Simon >>> >>> >>> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: >>> >>>> On 10/29/12 6:23 PM, Roni Even wrote: >>>>> Paul, >>>>> This was the statement I answered "no" >>>>> " The general agreement on the call is that the data model as >>>>> reflected in >>>>> draft-presta-clue-data-model-schema describes the data needed by >>>>> the CLUE >>>>> application" >>>>> I disagree that it reflects that data needed by a CLUE application >>>>> and I >>>>> explained why. >>>> >>>> OK, fair enough. >>>> >>>> Mary can comment, but my take was that the point of her question was >>>> to distinguish between two alternatives: >>>> - the data model represents all the data needed by the clue app. >>>> (which implies to me that it encompasses all the data in the >>>> framework.) >>>> - the data model represents the data to be exchanged in >>>> clue messages. >>>> >>>> It is a bigger deal if the framework includes things that are not >>>> needed by the clue application. I was of the impression that, except >>>> for some fine tuning, we were largely in agreement on the framework. >>>> >>>> If we don't have consensus on *that* then resolving that is of >>>> higher priority that much of the other stuff we are discussing. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Roni >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org >>>>> [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>> Kyzivat >>>>> Sent: 29 October, 2012 9:46 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] Data model - agreement on objective and basic >>>>> approach >>>>> >>>>> On 10/29/12 3:19 PM, Roni Even wrote: >>>>>> Hi, >>>>>> >>>>>> My view is 'no". I still fail to see the need for the encoding groups >>>>>> and individual encodes. >>>>>> >>>>>> In the current definition of capture scene, I am not sure what is the >>>>>> meaning of different individual encodes and eventually the receiver >>>>>> can define what it can receive (Typically H.264 is symmetric in terms >>>>>> of profile but does not need to be in the level) and can ask for >>>>>> specific resolution with the SDP image attribute >>>>> >>>>> ISTM that you are answering a different question than the one Mary >>>>> asked. >>>>> You seem to be saying that you disagree with the framework as it is >>>>> - that >>>>> it can/should be simpler. >>>>> >>>>> That is a separate question. If such changes were made it might >>>>> affect a >>>>> lot. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Roni Even >>>>>> >>>>>> *From:*clue-bounces@ietf.org >>>>>> [mailto:clue-bounces@ietf.org] *On Behalf >>>>>> Of *Mary Barnes >>>>>> *Sent:* 29 October, 2012 7:52 PM >>>>>> *To:* CLUE >>>>>> *Subject:* [clue] Data model - agreement on objective and basic >>>>>> approach >>>>>> >>>>>> On the call earlier today, we also discussed the data model. The >>>>>> general agreement on the call is that the data model as reflected in >>>>>> draft-presta-clue-data-model-schema describes the data needed by the >>>>>> CLUE application - i.e., it's the CLUE instance concept. It does not >>>>>> directly reflect the contents of a CLUE message. The application >>>>>> data >>>>>> would be used to populate CLUE messages, as well as SDP and would >>>>>> reflect updates based on both the CLUE and SDP signaling. >>>>>> >>>>>> If we can get agreement on that before the meeting, I believe our >>>>>> discussions can be much more productive. If folks could please reply >>>>>> "Yes" or "No" reflecting agreement with the above, that would be >>>>>> helpful. If you reply "No", please explain why. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Mary >>>>>> >>>>>> as CLUE WG co-chair >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _\\|//_ >>> ( 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 >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > From spromano@unina.it Thu Nov 1 09:05:03 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5183E21F8F4C for ; Thu, 1 Nov 2012 09:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.384 X-Spam-Level: X-Spam-Status: No, score=-99.384 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, 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 v32xJHiHRVt6 for ; Thu, 1 Nov 2012 09:05:01 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2994121F8EB2 for ; Thu, 1 Nov 2012 09:04:59 -0700 (PDT) Received: from [1.131.207.73] ([94.160.163.52]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id qA1G4oX8006623 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 1 Nov 2012 17:04:53 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <50929B5E.7010108@alum.mit.edu> References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <50929B5E.7010108@alum.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----N2124EMGLKSK9MLRLI948OIB6OIW52" From: Simon Pietro Romano Date: Thu, 01 Nov 2012 17:04:45 +0100 To: Paul Kyzivat , clue@ietf.org Message-ID: <8f6e666d-8d37-4127-878b-f2410b718afb@email.android.com> Subject: Re: [clue] Data model - agreement on objective and basic approach X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:05:03 -0000 ------N2124EMGLKSK9MLRLI948OIB6OIW52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Paul, I'm ok with your revised view of my rough guess at documents optimization. As I said, it really was just a rough approach. I'll be happy to further elaborate on all this, if you all think this can prove useful. Most importantly, I would like, together with you and Roberta, to focus on your call flows skeleton and ladder diagram, so to arrive at a first detailed idea of the structure of the CLUE protocol, in terms of proper interaction between O/A, advertisement and configure messages. Simon Paul Kyzivat ha scritto: >Simon, > >It is good to get a fresh perspective from someone who hasn't lived >through the evolution of the current documents. > >I don't really know whether to comment on this as a chair or as an >individual, or even how to distinguish the two. For the moment lets >assume that the following comments are from me as an individual. > >On 10/30/12 6:23 AM, Simon Pietro Romano wrote: >> Hi Christian, >> >> a rough estimation would be the following: >> >> a) keep sections 1 through 4 inside the framework document; >> b) move sections 5 through 8 to the data model document > >IMO *moving* 5-8 to the data model would "gut" the framework. >A lot of the descriptive information in these sections still needs to >be >in the framework. Some of the detail about specific elements, such as >the lowest level elements and/or the values they can take on, would >perhaps be better if moved to the data model, near to the schema >definitions of them. (That will help minimize the chances for >divergence >with the schema, and remove unnecessary detail from the framework.) The > >stuff that remains in the framework will of course need to be repeated, > >with more detail, in the data model document. > >> c) move the XML schema to the data model document (final section of >the >> data model, which provides 'one possible' example of how to formally >> describe the things in the document); > >At the expense of some difficulty in maintaining the document, I would >find it helpful to have *elements* of the schema defined "in line" in >the data model document, with the textual description of the element. >Then a consolidated schema at the end. > >> d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the >> protocol document; > >Again, I think it would gut the framework to move this entirely. > >Now that I look again, I find an asymmetry in the document. Section 9 >is >largely a discussion of what will be a Configuration message. But the >description of what will be the Advertisement is spread across section >6-8. And 9.4 is really a high level intro to the complete protocol. > >I think the framework certainly needs something akin to the figure in >9.4. (But not precisely that figure.) I expect a protocol document to >extensively elaborate on this and coordinate it with the information >conveyed in sip. > >> e) move subsection 9.4 to the call flows document; > >No. *This* (or an improved version) is much more abstract that what I >expect in a call flow document. I don't see how we can have a >framework, >or a protocol document, that doesn't have something like this in it. > >> f) move section 10 to the data model document; > >I agree that the framework is probably the wrong place for a discussion > >of extensibility. But addressing extensibility only in the data model >document also isn't the answer. > >Certainly the protocol document needs to discuss extensibility. > >Depending on details of the division between protocol and data model, >the data model doc may also need to address it. > >(The *encodings* of information from the data model that are exchanged >via the protocol need to have and extensibility story. If those >encodings are defined in the data model doc, then that is where to >address it.) > >> g) move section 11 to the call flows document. > >Yes. > > Thanks, > Paul > >> Obviously, the resulting framework document should be revised (and >> enriched) in view of the proposed distribution of work inside the WG. >I >> would like it to represent an orchestration document, providing an >> overview of issues, requirements, architecture and protocols. A sort >of >> summary reference for all of the related "drill-down" documents, each >> expanding on a specific WG item (data model, protocol, call flows, >etc.). >> >> I acknowledge the fact that this looks much like a revolution, but I >> nonetheless believe that we already have most of the needed material >at >> hand and just need to better distribute it across the documents >produced >> by the WG. >> >> Cheers, >> >> Simon >> >> >> >> >> Il 30/10/2012 10:33, Christian Groves ha scritto: >>> Hello Simon, >>> >>> When you say that you want to remove "all" the data model stuff from >>> the framework can you be a bit more specific as to what parts you >want >>> removed? >>> >>> Regards, Christian >>> >>> On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: >>>> Hi all, >>>> >>>> just to be clear on the current structure of the data model schema: >>>> all the things you find there were 'extracted' (by Roberta and me) >>>> from information currently contained inside the framework draft (as >>>> well as from some side documents, associated with either the data >>>> model or the envisaged call flows). So, unless we have >misinterpreted >>>> the above document(s) (which is obviously possible), we should >first >>>> of all focus on the framework in order to try and converge on an >>>> agreed-upon CLUE architecture. Once done with this, we can >fine-tune >>>> the data model. As I already stated on this list, it is my personal >>>> opinion that we should remove from the framework document all of >the >>>> data-model stuff that it currently contains, and rather focus on a >>>> clear definition of framework components and interfaces. I might >look >>>> naif, but I would like to arrive at an 'ordinary' set of documents: >>>> (i) general framework; (ii) data model; (iii) clue protocol (with >>>> advertisement and configuration messages); (iv) call flows (showing >>>> how SDP O/A and CLUE protocol messages concur in effectively >setting >>>> up a CLUE session). >>>> >>>> As to the 'UML vs XML' querelle, I would suggest that: >>>> >>>> 1. Both UML class diagrams and XML schema can be adopted for the >>>> description of the data model, i.e., the STATIC part of the >>>> framework, associated with the description of what some of you >>>> properly called a 'CLUE instance'; >>>> 2. UML sequence diagrams can be adopted to describe CLUE call >flows, >>>> i.e. the DYNAMIC part of the framework, which clearly envisages the >>>> co-existence of SDP and CLUE protocol messages. XML schemas are not >>>> suitable for this dynamic part. >>>> >>>> This said, it is clear that CLUE protocol messages (in particular, >>>> CLUE advertisements) will be constructed by leveraging information >>>> contained inside a CLUE instance. Which parts of a CLUE instance >>>> should go into an advertisement and which should be carried inside >>>> SDP can be a matter of discussion. >>>> >>>> My 2 cents, >>>> >>>> Simon >>>> >>>> >>>> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: >>>> >>>>> On 10/29/12 6:23 PM, Roni Even wrote: >>>>>> Paul, >>>>>> This was the statement I answered "no" >>>>>> " The general agreement on the call is that the data model as >>>>>> reflected in >>>>>> draft-presta-clue-data-model-schema describes the data needed by >>>>>> the CLUE >>>>>> application" >>>>>> I disagree that it reflects that data needed by a CLUE >application >>>>>> and I >>>>>> explained why. >>>>> >>>>> OK, fair enough. >>>>> >>>>> Mary can comment, but my take was that the point of her question >was >>>>> to distinguish between two alternatives: >>>>> - the data model represents all the data needed by the clue app. >>>>> (which implies to me that it encompasses all the data in the >>>>> framework.) >>>>> - the data model represents the data to be exchanged in >>>>> clue messages. >>>>> >>>>> It is a bigger deal if the framework includes things that are not >>>>> needed by the clue application. I was of the impression that, >except >>>>> for some fine tuning, we were largely in agreement on the >framework. >>>>> >>>>> If we don't have consensus on *that* then resolving that is of >>>>> higher priority that much of the other stuff we are discussing. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Roni >>>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org >>>>>> [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>>>> Kyzivat >>>>>> Sent: 29 October, 2012 9:46 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] Data model - agreement on objective and basic >>>>>> approach >>>>>> >>>>>> On 10/29/12 3:19 PM, Roni Even wrote: >>>>>>> Hi, >>>>>>> >>>>>>> My view is 'no". I still fail to see the need for the encoding >groups >>>>>>> and individual encodes. >>>>>>> >>>>>>> In the current definition of capture scene, I am not sure what >is the >>>>>>> meaning of different individual encodes and eventually the >receiver >>>>>>> can define what it can receive (Typically H.264 is symmetric in >terms >>>>>>> of profile but does not need to be in the level) and can ask for >>>>>>> specific resolution with the SDP image attribute >>>>>> >>>>>> ISTM that you are answering a different question than the one >Mary >>>>>> asked. >>>>>> You seem to be saying that you disagree with the framework as it >is >>>>>> - that >>>>>> it can/should be simpler. >>>>>> >>>>>> That is a separate question. If such changes were made it might >>>>>> affect a >>>>>> lot. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> Roni Even >>>>>>> >>>>>>> *From:*clue-bounces@ietf.org >>>>>>> [mailto:clue-bounces@ietf.org] *On Behalf >>>>>>> Of *Mary Barnes >>>>>>> *Sent:* 29 October, 2012 7:52 PM >>>>>>> *To:* CLUE >>>>>>> *Subject:* [clue] Data model - agreement on objective and basic >>>>>>> approach >>>>>>> >>>>>>> On the call earlier today, we also discussed the data model. >The >>>>>>> general agreement on the call is that the data model as >reflected in >>>>>>> draft-presta-clue-data-model-schema describes the data needed by >the >>>>>>> CLUE application - i.e., it's the CLUE instance concept. It does >not >>>>>>> directly reflect the contents of a CLUE message. The >application >>>>>>> data >>>>>>> would be used to populate CLUE messages, as well as SDP and >would >>>>>>> reflect updates based on both the CLUE and SDP signaling. >>>>>>> >>>>>>> If we can get agreement on that before the meeting, I believe >our >>>>>>> discussions can be much more productive. If folks could please >reply >>>>>>> "Yes" or "No" reflecting agreement with the above, that would be >>>>>>> helpful. If you reply "No", please explain why. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Mary >>>>>>> >>>>>>> as CLUE WG co-chair >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _\\|//_ >>>> ( 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 >>> >>> _______________________________________________ >>> 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 ------N2124EMGLKSK9MLRLI948OIB6OIW52 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Paul,

I'm ok with your revised view of my rough guess at documents optimization. As I said, it really was just a rough approach. I'll be happy to further elaborate on all this, if you all think this can prove useful. Most importantly, I would like, together with you and Roberta, to focus on your call flows skeleton and ladder diagram, so to arrive at a first detailed idea of the structure of the CLUE protocol, in terms of proper interaction between O/A, advertisement and configure messages.

Simon

Paul Kyzivat <pkyzivat@alum.mit.edu> ha scritto:
Simon,

It is good to get a fresh perspective from someone who hasn't lived 
through the evolution of the current documents.

I don't really know whether to comment on this as a chair or as an 
individual, or even how to distinguish the two. For the moment lets 
assume that the following comments are from me as an individual.

On 10/30/12 6:23 AM, Simon Pietro Romano wrote:
Hi Christian,

a rough estimation would be the following:

a) keep sections 1 through 4 inside the framework document;
b) move sections 5 through 8 to the data model document

IMO *moving* 5-8 to the data model would "gut" the framework.
A lot of the descriptive information in these sections still!
  needs
to be 
in the framework. Some of the detail about specific elements, such as 
the lowest level elements and/or the values they can take on, would 
perhaps be better if moved to the data model, near to the schema 
definitions of them. (That will help minimize the chances for divergence 
with the schema, and remove unnecessary detail from the framework.) The 
stuff that remains in the framework will of course need to be repeated, 
with more detail, in the data model document.

c) move the XML schema to the data model document (final section of the
data model, which provides 'one possible' example of how to formally
describe the things in the document);

At the expense of some difficulty in maintaining the document, I would 
find it helpful to have *elements* of the schema defined "in l!
 ine" in

the data model document, with the textual description of the element. 
Then a consolidated schema at the end.

d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the
protocol document;

Again, I think it would gut the framework to move this entirely.

Now that I look again, I find an asymmetry in the document. Section 9 is 
largely a discussion of what will be a Configuration message. But the 
description of what will be the Advertisement is spread across section 
6-8. And 9.4 is really a high level intro to the complete protocol.

I think the framework certainly needs something akin to the figure in 
9.4. (But not precisely that figure.) I expect a protocol document to 
extensively elaborate on this and coordinate it with the information 
conveyed in si!
 p.

e) move subsection 9.4 to the call flows document;

No. *This* (or an improved version) is much more abstract that what I 
expect in a call flow document. I don't see how we can have a framework, 
or a protocol document, that doesn't have something like this in it.

f) move section 10 to the data model document;

I agree that the framework is probably the wrong place for a discussion 
of extensibility. But addressing extensibility only in the data model 
document also isn't the answer.

Certainly the protocol document needs to discuss extensibility.

Depending on details of the division between protocol and data model, 
the data model doc may also !
 need to
address it.

(The *encodings* of information from the data model that are exchanged 
via the protocol need to have and extensibility story. If those 
encodings are defined in the data model doc, then that is where to 
address it.)

g) move section 11 to the call flows document.

Yes.

 Thanks,
 Paul

Obviously, the resulting framework document should be revised (and
enriched) in view of the proposed distribution of work inside the WG. I
would like it to represent an orchestration document, providing an
overview of issues, requirements, architecture and protocols. A sort of
summary reference for all of the related "drill-down" documents, each
e!
 xpanding
on a specific WG item (data model, protocol, call flows, etc.).

I acknowledge the fact that this looks much like a revolution, but I
nonetheless believe that we already have most of the needed material at
hand and just need to better distribute it across the documents produced
by the WG.

Cheers,

Simon




Il 30/10/2012 10:33, Christian Groves ha scritto:
Hello Simon,

When you say that you want to remove "all" the data model stuff from
the framework can you be a bit more specific as to what parts you want
removed?

Regards, Christian

On 30/10/2012 7:03 PM, Simon Pietro Romano wrote:
Hi all,

just to be clear on !
 the
current structure of the data model schema:
all the things you find there were 'extracted' (by Roberta and me)
from information currently contained inside the framework draft (as
well as from some side documents, associated with either the data
model or the envisaged call flows). So, unless we have misinterpreted
the above document(s) (which is obviously possible), we should first
of all focus on the framework in order to try and converge on an
agreed-upon CLUE architecture. Once done with this, we can fine-tune
the data model. As I already stated on this list, it is my personal
opinion that we should remove from the framework document all of the
data-model stuff that it currently contains, and rather focus on a
clear definition of framework components and interfaces. I might look
naif, but I would like to arrive at an 'ordinary' set of documents:
(i)  general framework; (ii) data model; (iii) clue protocol (wi!
 th
advertisement and configuration messages); (iv) call flows (showing
how SDP O/A and CLUE protocol messages concur in effectively setting
up a CLUE session).

As to the 'UML vs XML' querelle, I would suggest that:

1. Both UML class diagrams and XML schema can be adopted for the
description of the data model, i.e., the STATIC part of the
framework, associated with the description of what some of you
properly called a 'CLUE instance';
2. UML sequence diagrams can be adopted to describe CLUE call flows,
i.e. the DYNAMIC part of the framework, which clearly envisages the
co-existence of SDP and CLUE protocol messages. XML schemas are not
suitable for this dynamic part.

This said, it is clear that CLUE protocol messages  (in particular,
CLUE advertisements) will be constructed by leveraging information
contained inside a CLUE instance. Which parts of a CLUE instance
should go into an
advertisement and which should be carried inside
SDP can be a matter of discussion.

My 2 cents,

Simon


Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto:

On 10/29/12 6:23 PM, Roni Even wrote:
Paul,
This was the statement I answered "no"
" The general agreement on the call is that the data model as
reflected in
draft-presta-clue-data-model-schema describes the data needed by
the CLUE
application"
I disagree that it reflects that data needed by a CLUE application
and I
explained why.

OK, fair enough.

Mary can comment, but my take was that the point of her question was
to distinguish between two
alternatives:
- the data model represents all the data needed by the clue app.
(which implies to me that it encompasses all the data in the
framework.)
- the data model represents the data to be exchanged in
clue messages.

It is a bigger deal if the framework includes things that are not
needed by the clue application. I was of the impression that, except
for some fine tuning, we were largely in agreement on the framework.

If we don't have consensus on *that* then resolving that is of
higher priority that much of the other stuff we are discussing.

Thanks,
Paul

Roni

-----Original Message-----
From: clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>
[mailto:clue-bounces@ietf.org] On Behalf Of Paul
Kyzivat
Sent: 29 October, 2012 9:46 PM!
 
To: clue@ietf.org <mailto:clue@ietf.org>
Subject: Re: [clue] Data model - agreement on objective and basic
approach

On 10/29/12 3:19 PM, Roni Even wrote:
Hi,

My view is 'no". I still fail to see the need for the encoding groups
and individual encodes.

In the current definition of capture scene, I am not sure what is the
meaning of different individual encodes and eventually the receiver
can define what it can receive (Typically H.264 is symmetric in terms
of profile but does not need to be in the level) and can ask for
specific resolution with the SDP image attribute

ISTM that you are answering a different question than the one Mary
asked.
You seem to be saying that you disagree with the framework as it is
- that
it can/should be simpler.
That is a separate question. If such changes were made it might
affect a
lot.

Thanks,
Paul

Roni Even

*From:*clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>
[mailto:clue-bounces@ietf.org] *On Behalf
Of *Mary Barnes
*Sent:* 29 October, 2012 7:52 PM
*To:* CLUE
*Subject:* [clue] Data model - agreement on objective and basic
approach

On the call earlier today, we also discussed the data model.  The
general agreement on the call is that the data model as reflected in
draft-presta-clue-data-model-schema describes the data needed by the
CLUE application - i.e., it's the CLUE instance concept. It does not
directly reflect the contents of a CLUE message.  The application
data
would be used to populate CLUE messages, as well as SDP and would
reflect updates based on both the CLUE and SDP signaling.

If we can get agreement on that before the meeting, I believe our
discussions can be much more productive. If folks could please reply
"Yes" or "No" reflecting agreement with the above, that would be
helpful.  If you reply "No", please explain why.

Regards,

Mary

as CLUE WG co-chair




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



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




clue mailing list
clue@ietf.org <mailto: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 <mailto:spromano@unina.it>

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








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

------N2124EMGLKSK9MLRLI948OIB6OIW52-- From stephen.botzko@gmail.com Thu Nov 1 09:11: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 DAD8E21F8F24 for ; Thu, 1 Nov 2012 09:11:54 -0700 (PDT) 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 nfe3-u7Z7Jpx for ; Thu, 1 Nov 2012 09:11:53 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1A2121F8E80 for ; Thu, 1 Nov 2012 09:11:53 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so1835582pad.31 for ; Thu, 01 Nov 2012 09:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xm5rb4mYmGoUH3LotqdrjR8K8PHYv0GaHLGc+BfPxY4=; b=r0ggDlMQbSHt6y7UTrlCFYsUxa8GMJsHe86qTp8iObjqpIfH43bTu8oWlPfK133tPd 0bFZoHHb33VHjJKUjHFZBWcvJdVHLHaKYafsHRL8j09gR79YSd0sWNEKABVE6rLs2FTf 0L3V55YhjdEONk6RZ7RAyOXQhskksrtFNZ9OAVQbnLwiAdNKchHqx0Y6O7CJlSkKdLSi sOynUiB8Nbbk8+xJUmjAxv+9OAL4mzRBdCNrTdx1c+5CeZa8Ts49mP0ygqqTKFae3Mwm 0PookzDn1BQwp6Cid60EGD7vWjiHTaRJy91/kvDdycI0tFISGx2abXeEuZM3VZV/gr9S 8kYg== MIME-Version: 1.0 Received: by 10.68.192.5 with SMTP id hc5mr89998245pbc.16.1351786313387; Thu, 01 Nov 2012 09:11:53 -0700 (PDT) Received: by 10.68.60.98 with HTTP; Thu, 1 Nov 2012 09:11:53 -0700 (PDT) In-Reply-To: References: <5091DEF5.6010608@nteczone.com> Date: Thu, 1 Nov 2012 12:11:53 -0400 Message-ID: From: Stephen Botzko To: Mary Barnes Content-Type: multipart/alternative; boundary=e89a8f64328e05909704cd7147f2 Cc: "clue@ietf.org" Subject: Re: [clue] CLUE media capture 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, 01 Nov 2012 16:11:55 -0000 --e89a8f64328e05909704cd7147f2 Content-Type: text/plain; charset=ISO-8859-1 I have a couple of clarifications in-line. Steve B. On Thu, Nov 1, 2012 at 10:35 AM, Mary Barnes wrote: > I'll let other WG members respond to the details of this proposal. It > would be helpful if you could forward the document submitted to Q5 unless > it really is as brief as you suggest. I also have one important comment > below. [MB] > > Mary. > CLUE WG co-chair > > On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves < > Christian.Groves@nteczone.com> wrote: > >> >> CLUE media capture description >> draft-groves-clue-capture-**attr-00 >> >> I won't be attending the IETF next week so as a pre-cursor to next weeks >> CLUE WG meeting I thought i'd put a few words together about >> draft-groves-clue-capture-**attr-0 >> http://datatracker.ietf.org/**doc/draft-groves-clue-capture-**attr/ >> >> The main idea behind the draft is that a CLUE advertisement should >> include enough information for the receiver to make an educated decision >> about what captures it chooses. Having a had a close look at the content >> attribute I think (for the reasons outlined in the draft) it is >> insufficient to fully describe the multi-stream conferencing environments >> that CLUE is addressing/enabling. >> >> A contribution with essentially the same text as the draft was submitted >> to the recent Q.5/16 meeting to solicit feedback from the people at the >> meeting about the different parameters presented in the draft. In general I >> think people were in agreement that the current Content attribute was not >> sufficient. However it was noted that it needs to be considered how CLUE >> maps to the existing usages of the content attribute and mapping to H.239. >> > [MB] While Q.5 might need to do this, it is absolutely out of scope for > the CLUE WG. It is not in our charter and the requirements clearly state > such: > "Non IETF protocol based systems, such as > those based on ITU-T Rec. H.323, are out of scope." > [/MB] > [SB] I'd like to make three clarifications on this: -Q5/16 itself is not endorsing Christian's contribution and is not requesting any action on it from either CLUE or the IETF. Q5/16 of course would use the normal liaison mechanisms for that kind of communication. Christian's draft is an individual draft like any other. -Q5/16 is following the CLUE work closely, because there is strong support there for using a consistent approach for multiple streams. Generally it has focused most of its attention on aspects of telepresence systems that are out-of-scope for CLUE, but which are still needed to get good interoperability. For instance, specifications for audio levels, video color space, etc. -Q5/16 was not considering H.323 specifically when it provided feedback on Christian's contribution. Personally I think the draft makes some good points that we should consider. [/SB] > >> Below is a list of attributes and comments. If I've left out anything or >> mispoken hopefully Steve Botzko can correct me. >> >> Presentation >> ------------ >> People thought it was worthwhile to know if a capture related to a >> presentation. There was some questioning if it was worthwhile to know if >> the capture was slides, images etc. It was thought it may help where >> multiple presentation streams were used. >> >> View >> ---- >> It was clarified that the aim of the attribute is to allow a remote end >> to make an automatic decision on what region of the scene it wants to see. >> The idea is that there is a standard keyword that the remote end could scan >> for e.g. lectern. This is a way of providing meaning to a particular >> spatial area. >> >> Language >> -------- >> There seemed to be general support for a language parameter. >> >> Role >> ---- >> It was thought that role could be related to "participants" or >> "material". Currently the attribute only discusses role from the aspect of >> a participant. It was also noted that the role may change based on meeting >> type. For example: in the medical use case there could be "Surgeon", >> "Professor", in an accessible conference there could be an "Interpreter" or >> "signer". With respect to Materials it was thought presentation could show >> something like "Agenda", "Contribution". >> >> Priority >> -------- >> There was some discussion as to whether this was needed. It was thought >> that if captures were properly described then priority wouldn't be needed >> as the remote end could make an educated decision about what it wants. At >> the moment with the minimal set of attributes it was thought that priority >> at least helped the remote end make a decision. >> >> Dynamic >> ------- >> I think people were OK with this being optional. >> >> >> Embedded Text >> ------------- >> Again I think people thought it was reasonable. It was clarified this >> could also be used to indicate captioning was being used with the capture. >> >> >> Supplementary description >> ------------------------- >> There was some question about how this related to side bar conferences. >> It was clarified this was mainly about the case where information >> (captures) were provided by people (or devices) who were not captured by >> the conference video. >> >> Telepresence >> ------------ >> This parameter probably had the least support/understanding. I was noted >> that CLUE was to allow multi-stream operation it didn't necessarily >> indicate/mandate a telepresence experience. >> >> Hopefully this provides some further background for the CLUE discussions. >> If the group could come to some general agreement about each of the >> parameters then I could work on some specific text for the framework (or >> whatever document we decide). >> >> 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 > > --e89a8f64328e05909704cd7147f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have a couple of clarif= ications in-line.=A0

Steve B.


On Thu, Nov 1, 2012 at 10:35 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
I'll let other WG members respond to the details of this proposal. =A0I= t would be helpful if you could forward the document submitted to Q5 unless= it really is as brief as you suggest. =A0I also have one important comment= below. [MB]

Mary.
CLUE WG co-chair

On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves = <Christian.Groves@nteczone.com> wrote:

CLUE media capture description
draft-groves-clue-capture-attr-00

I won't be attending the IETF next week so as a pre-cursor to next week= s CLUE WG meeting =A0I thought i'd put a few words together about draft= -groves-clue-capture-attr-0
http://datatracker.ietf.org/doc/draft-groves-clue= -capture-attr/

The main idea behind the draft is that a CLUE advertisement should include = enough information for the receiver to make an educated decision about what= captures it chooses. Having a had a close look at the content attribute I = think (for the reasons outlined in the draft) it is insufficient to fully d= escribe the multi-stream conferencing environments that CLUE is addressing/= enabling.

A contribution with essentially the same text as the draft was submitted to= the recent Q.5/16 meeting to solicit feedback from the people at the meeti= ng about the different parameters presented in the draft. In general I thin= k people were in agreement that the current Content attribute was not suffi= cient. However it was noted that it needs to be considered how CLUE maps to= the existing usages of the content attribute and mapping to H.239.
[MB] While Q.5 might need to do this, it is absolut= ely out of scope for the CLUE WG. It is not in our charter and the requirem= ents clearly state such:
=A0 =A0"Non IETF protocol based sys= tems, such as
=A0 =A0those based on ITU-T Rec. H.323, are out of scope."
<= span class=3D"HOEnZb">
[/MB]
[SB]
I'd like to make three clarifica= tions on this:=A0

-Q5/16 itself is not endorsing Christian's contribution and is not = requesting any action on it from either CLUE or the IETF.=A0 Q5/16 of cours= e would use the normal liaison mechanisms for that kind of communication.= =A0 Christian's draft is an individual draft like any other.

-Q5/16 is following the CLUE work closely, because there is strong supp= ort there for using a consistent approach for multiple streams.=A0 Generall= y it has focused most of its attention on aspects of telepresence systems t= hat are out-of-scope for CLUE, but which are still needed to get good inter= operability.=A0 For instance, specifications for audio levels, video color = space, etc.

-Q5/16 was not considering H.323 specifically when it provided feedback= on Christian's contribution.=A0

Personally I think the draft m= akes some good points that we should consider.
[/SB]

Below is a list of attributes and comments. If I've left out anything o= r mispoken hopefully Steve Botzko can correct me.

Presentation
------------
People thought it was worthwhile to know if a capture related to a presenta= tion. There was some questioning if it was worthwhile to know if the captur= e was slides, images etc. It was thought it may help where multiple present= ation streams were used.

View
----
It was clarified that the aim of the attribute is to allow a remote end to = make an automatic decision on what region of the scene it wants to see. The= idea is that there is a standard keyword that the remote end could scan fo= r e.g. lectern. This is a way of providing meaning to a particular spatial = area.

Language
--------
There seemed to be general support for a language parameter.

Role
----
It was thought that role could be related to "participants" or &q= uot;material". Currently the attribute only discusses role from the as= pect of a participant. It was also noted that the role may change based on = meeting type. For example: in the medical use case there could be "Sur= geon", "Professor", in an accessible conference there could = be an "Interpreter" or "signer". With respect to Materi= als it was thought presentation could show something like "Agenda"= ;, "Contribution".

Priority
--------
There was some discussion as to whether this was needed. It was thought tha= t if captures were properly described then priority wouldn't be needed = as the remote end could make an educated decision about what it wants. At t= he moment with the minimal set of attributes it was thought that priority a= t least helped the remote end make a decision.

Dynamic
-------
I think people were OK with this being optional.


Embedded Text
-------------
Again I think people thought it was reasonable. It was clarified this could= also be used to indicate captioning was being used with the capture.


Supplementary description
-------------------------
There was some question about how this related to side bar conferences. It = was clarified this was mainly about the case where information (captures) w= ere provided by people (or devices) who were not captured by the conference= video.

Telepresence
------------
This parameter probably had the least support/understanding. I was noted th= at CLUE was to allow multi-stream operation it didn't necessarily indic= ate/mandate a telepresence experience.

Hopefully this provides some further background for the CLUE discussions. I= f the group could come to some general agreement about each of the paramete= rs then I could work on some specific text for the framework (or whatever d= ocument we decide).

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


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


--e89a8f64328e05909704cd7147f2-- From pkyzivat@alum.mit.edu Thu Nov 1 09:15: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 E77DA21F8F8E for ; Thu, 1 Nov 2012 09:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 j-uYkaTtbzmY for ; Thu, 1 Nov 2012 09:15:51 -0700 (PDT) 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 6FBF621F8EC5 for ; Thu, 1 Nov 2012 09:15:51 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta08.westchester.pa.mail.comcast.net with comcast id JCLz1k0041swQuc58GFvWr; Thu, 01 Nov 2012 16:15:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id JGKh1k0133ZTu2S3bGKihs; Thu, 01 Nov 2012 16:19:42 +0000 Message-ID: <5092A034.7030402@alum.mit.edu> Date: Thu, 01 Nov 2012 12:15:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Simon Pietro Romano References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <50929B5E.7010108@alum.mit.edu> <8f6e666d-8d37-4127-878b-f2410b718afb@email.android.com> In-Reply-To: <8f6e666d-8d37-4127-878b-f2410b718afb@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:15:53 -0000 On 11/1/12 12:04 PM, Simon Pietro Romano wrote: > Hi Paul, > > I'm ok with your revised view of my rough guess at documents > optimization. As I said, it really was just a rough approach. I'll be > happy to further elaborate on all this, if you all think this can prove > useful. Next week should provide good opportunity to discuss this. > Most importantly, I would like, together with you and Roberta, > to focus on your call flows skeleton and ladder diagram, so to arrive at > a first detailed idea of the structure of the CLUE protocol, in terms of > proper interaction between O/A, advertisement and configure messages. I hope you can tell that I also consider this a priority! I am finding it remarkably difficult to sort out. IMO this is exposing differences of opinion about stuff that we seemingly had already agreed upon. That tells me that what we have written in the framework, etc. is not sufficiently detailed for everyone to understand in a consistent way. I hope we make progress on this next week. Thanks, Paul > Simon > > Paul Kyzivat ha scritto: > > Simon, > > It is good to get a fresh perspective from someone who hasn't lived > through the evolution of the current documents. > > I don't really know whether to comment on this as a chair or as an > individual, or even how to distinguish the two. For the moment lets > assume that the following comments are from me as an individual. > > On 10/30/12 6:23 AM, Simon Pietro Romano wrote: > > Hi Christian, > > a rough estimation would be the following: > > a) keep sections 1 through 4 inside the framework document; > b) move sections 5 through 8 to the data model document > > > IMO *moving* 5-8 to the data model would "gut" the framework. > A lot of the descriptive information in these sections still! > needs > to be > in the framework. Some of the detail about specific elements, such as > the lowest level elements and/or the values they can take on, would > perhaps be better if moved to the data model, near to the schema > definitions of them. (That will help minimize the chances for divergence > with the schema, and remove unnecessary detail from the framework.) The > stuff that remains in the framework will of course need to be repeated, > with more detail, in the data model document. > > c) move the XML schema to the data model document (final section > of the > data model, which provides 'one possible' example of how to formally > describe the things in the document); > > > At the expense of some difficulty in maintaining the document, I would > find it helpful to have *elements* of the schema defined "in l! > ine" in > > the data model document, with the textual description of the element. > Then a consolidated schema at the end. > > d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the > protocol document; > > > Again, I think it would gut the framework to move this entirely. > > Now that I look again, I find an asymmetry in the document. Section 9 is > largely a discussion of what will be a Configuration message. But the > description of what will be the Advertisement is spread across section > 6-8. And 9.4 is really a high level intro to the complete protocol. > > I think the framework certainly needs something akin to the figure in > 9.4. (But not precisely that figure.) I expect a protocol document to > extensively elaborate on this and coordinate it with the information > conveyed in si! > p. > > e) move subsection 9.4 to the call flows document; > > > No. *This* (or an improved version) is much more abstract that what I > expect in a call flow document. I don't see how we can have a framework, > or a protocol document, that doesn't have something like this in it. > > f) move section 10 to the data model document; > > > I agree that the framework is probably the wrong place for a discussion > of extensibility. But addressing extensibility only in the data model > document also isn't the answer. > > Certainly the protocol document needs to discuss extensibility. > > Depending on details of the division between protocol and data model, > the data model doc may also ! > need to > address it. > > (The *encodings* of information from the data model that are exchanged > via the protocol need to have and extensibility story. If those > encodings are defined in the data model doc, then that is where to > address it.) > > g) move section 11 to the call flows document. > > > Yes. > > Thanks, > Paul > > Obviously, the resulting framework document should be revised (and > enriched) in view of the proposed distribution of work inside > the WG. I > would like it to represent an orchestration document, providing an > overview of issues, requirements, architecture and protocols. A > sort of > summary reference for all of the related "drill-down" documents, > each > e! xpanding on a specific WG item (data model, protocol, call > flows, etc.). > > I acknowledge the fact that this looks much like a revolution, but I > nonetheless believe that we already have most of the needed > material at > hand and just need to better distribute it across the documents > produced > by the WG. > > Cheers, > > Simon > > > > > Il 30/10/2012 10:33, Christian Groves ha scritto: > > Hello Simon, > > When you say that you want to remove "all" the data model > stuff from > the framework can you be a bit more specific as to what > parts you want > removed? > > Regards, Christian > > On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: > > Hi all, > > just to be clear on ! the current structure of the data > model schema: > all the things you find there were 'extracted' (by > Roberta and me) > from information currently contained inside the > framework draft (as > well as from some side documents, associated with either > the data > model or the envisaged call flows). So, unless we have > misinterpreted > the above document(s) (which is obviously possible), we > should first > of all focus on the framework in order to try and > converge on an > agreed-upon CLUE architecture. Once done with this, we > can fine-tune > the data model. As I already stated on this list, it is > my personal > opinion that we should remove from the framework > document all of the > data-model stuff that it currently contains, and rather > focus on a > clear definition of framework components and interfaces. > I might look > naif, but I would like to arrive at an 'ordinary' set of > documents: > (i) general framework; (ii) data model; (iii) clue > protocol (wi! th > advertisement and configuration messages); (iv) call > flows (showing > how SDP O/A and CLUE protocol messages concur in > effectively setting > up a CLUE session). > > As to the 'UML vs XML' querelle, I would suggest that: > > 1. Both UML class diagrams and XML schema can be adopted > for the > description of the data model, i.e., the STATIC part of the > framework, associated with the description of what some > of you > properly called a 'CLUE instance'; > 2. UML sequence diagrams can be adopted to describe CLUE > call flows, > i.e. the DYNAMIC part of the framework, which clearly > envisages the > co-existence of SDP and CLUE protocol messages. XML > schemas are not > suitable for this dynamic part. > > This said, it is clear that CLUE protocol messages (in > particular, > CLUE advertisements) will be constructed by leveraging > information > contained inside a CLUE instance. Which parts of a CLUE > instance > should go into an advertisement and which should be > carried inside > SDP can be a matter of discussion. > > My 2 cents, > > Simon > > > Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha > scritto: > > On 10/29/12 6:23 PM, Roni Even wrote: > > Paul, > This was the statement I answered "no" > " The general agreement on the call is that the > data model as > reflected in > draft-presta-clue-data-model-schema describes > the data needed by > the CLUE > application" > I disagree that it reflects that data needed by > a CLUE application > and I > explained why. > > > OK, fair enough. > > Mary can comment, but my take was that the point of > her question was > to distinguish between two alternatives: > - the data model represents all the data needed by > the clue app. > (which implies to me that it encompasses all the > data in the > framework.) > - the data model represents the data to be exchanged in > clue messages. > > It is a bigger deal if the framework includes things > that are not > needed by the clue application. I was of the > impression that, except > for some fine tuning, we were largely in agreement > on the framework. > > If we don't have consensus on *that* then resolving > that is of > higher priority that much of the other stuff we are > discussing. > > Thanks, > Paul > > Roni > > -----Original Message----- > From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: 29 October, 2012 9:46 PM! > To: clue@ietf.org > Subject: Re: [clue] Data model - agreement on > objective and basic > approach > > On 10/29/12 3:19 PM, Roni Even wrote: > > Hi, > > My view is 'no". I still fail to see the > need for the encoding groups > and individual encodes. > > In the current definition of capture scene, > I am not sure what is the > meaning of different individual encodes and > eventually the receiver > can define what it can receive (Typically > H.264 is symmetric in terms > of profile but does not need to be in the > level) and can ask for > specific resolution with the SDP image attribute > > > ISTM that you are answering a different question > than the one Mary > asked. > You seem to be saying that you disagree with the > framework as it is > - that > it can/should be simpler. > That is a separate question. If such changes > were made it might > affect a > lot. > > Thanks, > Paul > > Roni Even > > *From:*clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 29 October, 2012 7:52 PM > *To:* CLUE > *Subject:* [clue] Data model - agreement on > objective and basic > approach > > On the call earlier today, we also discussed > the data model. The > general agreement on the call is that the > data model as reflected in > draft-presta-clue-data-model-schema > describes the data needed by the > CLUE application - i.e., it's the CLUE > instance concept. It does not > directly reflect the contents of a CLUE > message. The application > data > would be used to populate CLUE messages, as > well as SDP and would > reflect updates based on both the CLUE and > SDP signaling. > > If we can get agreement on that before the > meeting, I believe our > discussions can be much more productive. If > folks could please reply > "Yes" or "No" reflecting agreement with the > above, that would be > helpful. If you reply "No", please explain why. > > Regards, > > Mary > > as CLUE WG co-chair > > > > ------------------------------------------------------------------------ > > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > ------------------------------------------------------------------------ > > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > > ------------------------------------------------------------------------ > > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _\\|//_ > ( 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 > > > ------------------------------------------------------------------------ > > 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 Nov 1 09:38: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 3203E21F900A for ; Thu, 1 Nov 2012 09:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.64 X-Spam-Level: X-Spam-Status: No, score=0.64 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_BELOW2=2.154, 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 kysi5-miJ-8P for ; Thu, 1 Nov 2012 09:38:54 -0700 (PDT) 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 2F3ED21F900C for ; Thu, 1 Nov 2012 09:38:54 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta02.westchester.pa.mail.comcast.net with comcast id JGDl1k00M17dt5G51GexFq; Thu, 01 Nov 2012 16:38:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id JGfr1k00W3ZTu2S3ZGfrdA; Thu, 01 Nov 2012 16:39:51 +0000 Message-ID: <5092A599.4010601@alum.mit.edu> Date: Thu, 01 Nov 2012 12:38:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <01d301cdb74d$10857940$31906bc0$@gmail.com> In-Reply-To: <01d301cdb74d$10857940$31906bc0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Do we need the encodings as secified in the framework document - proposal to remove them from the framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:38:55 -0000 (As co-chair) Roni is proposing a significant change here. PLEASE carefully consider this and comment on it here on the mailing list! *If* this works and satisfies all objectives then it will be a helpful simplification. But it may be that simplifying things this way excludes some required behavior. This is something that would benefit from discussion next week. But that won't be helpful if people haven't already thought about it. Thanks, Paul On 10/31/12 5:49 AM, Roni Even wrote: > Hi, > > From the email discussion it looks to me that the concept of the > encoding as specified in the framework document is not clear. I will try > to describe my understanding of sections 7 and 8 of the framework > document and explain why I think that it is not important to CLUE as > specified. I am looking for response if my understanding of the encoding > based on the framework is correct and how it will work for the examples > I will provide bellow > > The purpose of the Encodings is to provide INFORMATION about the > provider abilities to send streams. This relates to the available > resources (compute and BW) of the providers. > > The encodings are constructed from encoding groups and each encoding > group is include individual encodes. > > The encoding group provide a value for the total maximum BW and compute > H264Mbps (note that it is H.264 specific) of all the individual encodes > in the group that the provider can use to send audio and video. > > Each encoding group include a list of individual encodes (audio and /or > video). These provide maximum values that can be used to instantiate a > media stream by the provider. > > Each video individual encodes identified by an encodeID provides maximum > values for BW, compute, resolution and frame rate for H.264. (BTW: the > maxH264Mbps can be computed from the resolution and frame rate as > defined in table 2 making it redundant). > > Each audio encode has only a BW value (no identifier). > > A media capture is associated with an encoding group !!!!! not an > individual encoding. > > The provider can use one of the individual encoding to instantiate a > media capture, each individual encoding can be used by one media > capture, the decision of which one to use according to the framework is > by the provider. The consumer does not select an individual encode. > > The maximum number of streams that can result from a particular encoding > group is equal to the number of individual encodings in the group (note > that this is why the example in the current data model allows only for > one video and one audio streams). > > Section 8 of the framework talk about having more than one individual > encoding assigned to a media capture (simulcast) and also claims that it > can be done by the consumer but there is no way to do it since the media > capture is associated only with an encoding group. There is no way for a > consumer even to assign a specific individual encoding to a group. > > My view is that this mechanism does not work and can be removed. The > reasons are given bellow > > The encoding as currently specified is provided as information since > there is no way to map one or more individual encoding to a specific > media capture > > The video is H.264 specific and not general > > The relation between the individual encode and encoding group makes it > difficult to achieve a reasonable set even if the consumer will be able > to select the mapping. This is due to the fact the total defined by the > group limits the usage for individual encoding. For example if we have > a three camera system and we set a value in the group for > maxGroupH264Mbps and want to allow for simulcast (two resolutions), we > will need to define six individual encodes, three with high resolution ( > also high maxH264Mbps) and three lower resolution with lower > maxH264Mbps. If the compute resource can do all six it will reflected > in the value of maxGroupH264Mbps but I assume that there is a constrain > (otherwise why have encodings) making it lower. So if the consumer will > ask for all six what will happen. Since there is more than one degree of > freedom he will not be able to predict if he will get all or part on > lower frame rate , if he will get only a subset of the streams, if he > will get different resolutions. > > On the other hand if the 6 individual encodes will include lower values > to allow for the group limit it will mean that a consumer not doing > simulcast is limited by the fact the simulcast and ask (if possible) for > only three streams, the individual encodes limit will be low so he will > not be able to use the full compute resources. > > Section 8 concludes that the number of individual encodes in a group > must allow for all media capture in a capture scene entry to be used > simultaneously. > > So it look like this system does not work well for simulcast. What about > no simulcast, is it needed. For example a three camera system that also > have one presentation. My view that the cameras will be one capture > scene and the presentation will be a second one. The question is if they > all belong to one encoding group, here my view is “no” since they have > different priority and should not compete for compute resources. So we > will have two encoding groups one for presentation and one for the three > cameras. For the three cameras each sending one stream I assume that the > resource allocation will be a third for each so we will have three > individual encode with the same values, this is the basic one and if it > is a third than no need for advertising or configuring. Now if we also > want to have an individual encode that has higher compute if the > consumer wants only one capture (of the whole room), the group will have > fourth one with higher value. So if there is way for consumer to > configure individual encode when using three media captures, he may > select the higher capability one with two lower ones. The total will be > limited by the encoding group value and again it is not clear how the > actual streams will be encoded to address the group limit since there > are multiple options. > > To summarize I do not see value in the encoding as currently specified > since they only provide information and no option for configuration. The > value of it as information does not justify specifying them and if the > intention is to allow configurations of individual encoding it must be > reflected and the explained how it works. > > My proposal is at the moment to remove the encoding until we get some > text that defines how to use it for configuring encoding to media > captures including for the simulcast case > > Thanks > > Roni Even > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Nov 1 09:57: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 F2F7021F9026 for ; Thu, 1 Nov 2012 09:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.051, 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 Lmlf74eFwee9 for ; Thu, 1 Nov 2012 09:57:09 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 4939621F9003 for ; Thu, 1 Nov 2012 09:57:09 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id JGoq1k0021ei1Bg57GxDEQ; Thu, 01 Nov 2012 16:57:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id JGx51k0173ZTu2S3kGx6Bg; Thu, 01 Nov 2012 16:57:06 +0000 Message-ID: <5092A9E3.6010000@alum.mit.edu> Date: Thu, 01 Nov 2012 12:57:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Roberta Presta References: <508A6242.80001@unina.it> <5091009C.8070805@unina.it> In-Reply-To: <5091009C.8070805@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] again on X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 16:57:10 -0000 On 10/31/12 6:42 AM, Roberta Presta wrote: > Hi Paul, > > I don't see any problem in putting media captures inside capture scenes and delete the section under . > The sceneIDREF attribute of does not need to exist anymore, since the coordinate space would be the one of the involving capture scene. WFM > The remaining point now is the new definition of the media capture type, which presents the section that allows to contain spatial information or, > alternatively, to mark the media capture as "non spatially definible". > What do you think about that proposal? I'm ok with it. > I copy below the schema snapshot for convenience. > > Cheers, > > Roberta > > > > > > > > > > > > > > > > > > I'm an xml lightweight. In the above, why isn't it just: What do the s add? Thanks, Paul > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------- > > Roberta, > > I don't see how this addresses the problem. I think I see why. Comment > inline > > On 10/26/12 6:13 AM, Roberta Presta wrote: > [snip] > > * The element is referred to the coordinate space > of the capture scene indicated in the "sceneIDREF" attribute. > The framework doesn't seem to force a capture to be associated with only > one scene (or, at least, I don't remember to have read such a constraint > in the framework document). > If a capture is involved in more than one scene, more than one > should be provided, each one related to the > coordinate space of the involving scene. > > > > Whether clear or not, IMO it is *intended* that each capture is > associated (belongs to) a single scene. ISTM an obvious way to represent > this would be to have an instance of mediaCapturesType within > captureSceneType, rather than within clueInfoType. > > Thanks, > > Paul > > > > From Christian.Groves@nteczone.com Thu Nov 1 17:42: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 1049F21F9833 for ; Thu, 1 Nov 2012 17:42:15 -0700 (PDT) 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] 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 mL1U-5ZzcEfC for ; Thu, 1 Nov 2012 17:42:14 -0700 (PDT) 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 1B54221F97E2 for ; Thu, 1 Nov 2012 17:42:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIIWk1B20R8y/2dsb2JhbAANN8ZYAQEBBAEBATUbFQYKARALGAkWCAcJAwIBAgEPBh8RBg0BBQIBAYdwAxqpPIoBDYlUixRnhjsDlCOCcIoXiBQ Received: from ppp118-209-31-50.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.31.50]) by ipmail06.adl2.internode.on.net with ESMTP; 02 Nov 2012 11:11:47 +1030 Message-ID: <509316C5.6060003@nteczone.com> Date: Fri, 02 Nov 2012 11:41:41 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stephen Botzko References: <5091DEF5.6010608@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] CLUE media capture 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: Fri, 02 Nov 2012 00:42:15 -0000 Hello Steve and Mary Steve, I fully agree with your points. The contribution was provided for information as there is a Q5 document which uses much of the work of CLUE. The contents of the contribution was the same as the draft apart from templates issues so all the information is in draft-groves-clue-capture-attr. With respect to the comment about the scope, I don't think it was suggested that CLUE have a work item to define things for H.323 systems. The point was more that there are existing uses of the values related to the Content Attribute in both SIP and H.323 systems that work in with the control that H.239 offers. I think that interoperability with these systems should at least be considered when making protocol/design decisions. If we can make a choice which allows easier interworking why wouldn't we do that? I don't see that as out of scope. Regards, Christian On 2/11/2012 3:11 AM, Stephen Botzko wrote: > I have a couple of clarifications in-line. > > Steve B. > > > On Thu, Nov 1, 2012 at 10:35 AM, Mary Barnes > > wrote: > > I'll let other WG members respond to the details of this proposal. > It would be helpful if you could forward the document submitted > to Q5 unless it really is as brief as you suggest. I also have > one important comment below. [MB] > > Mary. > CLUE WG co-chair > > On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves > > wrote: > > > CLUE media capture description > draft-groves-clue-capture-attr-00 > > I won't be attending the IETF next week so as a pre-cursor to > next weeks CLUE WG meeting I thought i'd put a few words > together about draft-groves-clue-capture-attr-0 > http://datatracker.ietf.org/doc/draft-groves-clue-capture-attr/ > > The main idea behind the draft is that a CLUE advertisement > should include enough information for the receiver to make an > educated decision about what captures it chooses. Having a had > a close look at the content attribute I think (for the reasons > outlined in the draft) it is insufficient to fully describe > the multi-stream conferencing environments that CLUE is > addressing/enabling. > > A contribution with essentially the same text as the draft was > submitted to the recent Q.5/16 meeting to solicit feedback > from the people at the meeting about the different parameters > presented in the draft. In general I think people were in > agreement that the current Content attribute was not > sufficient. However it was noted that it needs to be > considered how CLUE maps to the existing usages of the content > attribute and mapping to H.239. > > [MB] While Q.5 might need to do this, it is absolutely out of > scope for the CLUE WG. It is not in our charter and the > requirements clearly state such: > "Non IETF protocol based systems, such as > those based on ITU-T Rec. H.323, are out of scope." > [/MB] > > [SB] > I'd like to make three clarifications on this: > > -Q5/16 itself is not endorsing Christian's contribution and is not > requesting any action on it from either CLUE or the IETF. Q5/16 of > course would use the normal liaison mechanisms for that kind of > communication. Christian's draft is an individual draft like any other. > > -Q5/16 is following the CLUE work closely, because there is strong > support there for using a consistent approach for multiple streams. > Generally it has focused most of its attention on aspects of > telepresence systems that are out-of-scope for CLUE, but which are > still needed to get good interoperability. For instance, > specifications for audio levels, video color space, etc. > > -Q5/16 was not considering H.323 specifically when it provided > feedback on Christian's contribution. > > Personally I think the draft makes some good points that we should > consider. > [/SB] > > > Below is a list of attributes and comments. If I've left out > anything or mispoken hopefully Steve Botzko can correct me. > > Presentation > ------------ > People thought it was worthwhile to know if a capture related > to a presentation. There was some questioning if it was > worthwhile to know if the capture was slides, images etc. It > was thought it may help where multiple presentation streams > were used. > > View > ---- > It was clarified that the aim of the attribute is to allow a > remote end to make an automatic decision on what region of the > scene it wants to see. The idea is that there is a standard > keyword that the remote end could scan for e.g. lectern. This > is a way of providing meaning to a particular spatial area. > > Language > -------- > There seemed to be general support for a language parameter. > > Role > ---- > It was thought that role could be related to "participants" or > "material". Currently the attribute only discusses role from > the aspect of a participant. It was also noted that the role > may change based on meeting type. For example: in the medical > use case there could be "Surgeon", "Professor", in an > accessible conference there could be an "Interpreter" or > "signer". With respect to Materials it was thought > presentation could show something like "Agenda", "Contribution". > > Priority > -------- > There was some discussion as to whether this was needed. It > was thought that if captures were properly described then > priority wouldn't be needed as the remote end could make an > educated decision about what it wants. At the moment with the > minimal set of attributes it was thought that priority at > least helped the remote end make a decision. > > Dynamic > ------- > I think people were OK with this being optional. > > > Embedded Text > ------------- > Again I think people thought it was reasonable. It was > clarified this could also be used to indicate captioning was > being used with the capture. > > > Supplementary description > ------------------------- > There was some question about how this related to side bar > conferences. It was clarified this was mainly about the case > where information (captures) were provided by people (or > devices) who were not captured by the conference video. > > Telepresence > ------------ > This parameter probably had the least support/understanding. I > was noted that CLUE was to allow multi-stream operation it > didn't necessarily indicate/mandate a telepresence experience. > > Hopefully this provides some further background for the CLUE > discussions. If the group could come to some general agreement > about each of the parameters then I could work on some > specific text for the framework (or whatever document we decide). > > 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 Fri Nov 2 02:24: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 6BC6621F9751 for ; Fri, 2 Nov 2012 02:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqSYVQQK7bem for ; Fri, 2 Nov 2012 02:24:55 -0700 (PDT) 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 880FB21F9755 for ; Fri, 2 Nov 2012 02:24:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBADeQk1B20R8y/2dsb2JhbAANN8ZdAQEBAwEBAQEvAQUbFAcKAQUHAgILEQEDAQEBCRYIBwkDAgECAQkGBh8DBggGDQEFAgEBh3QDCRGoQYlxDYlUBIsWZxqGIQOLSYZ+gV2IMoRWiBSBUA Received: from ppp118-209-31-50.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.31.50]) by ipmail04.adl6.internode.on.net with ESMTP; 02 Nov 2012 19:54:52 +1030 Message-ID: <5093915D.4010900@nteczone.com> Date: Fri, 02 Nov 2012 20:24:45 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mary Barnes References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <020401cdb76a$16131c60$42395520$@gmail.com> <5091C644.5070401@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 02 Nov 2012 09:24:57 -0000 Hello Mary, Please see my replies below. Regards, Christian On 2/11/2012 12:12 AM, Mary Barnes wrote: > On Wed, Oct 31, 2012 at 7:45 PM, Christian Groves > > > wrote: > > I agree the framework document in its current state isn't the > easiest or most precise document so we need to do something to > make it easier to understand. However I agree with Roni that > removing sections 1-4 doesn't leave much. > > I still am not convinced about having a data model document > related to a CLUE instance. What I'm trying to see is the actual > benefit for this approach? > > [MB] The benefit of the data model is that it takes the data as > defined in the framework to a lower level of abstraction that can be > thus used as elements in a protocol. [/MB] [CNG] If the CLUE data instance equals the CLUE advertisement then to me the most important documents will be the framework which gives the overview of how CLUE works and the protocol document itself. > > Is it to help implementers? > > [MB] The implementers will use it as a reference within the context of > the protocol. [/MB] [CNG] I assume that the protocol document will take precedence in case of any discrepancies? > > Is it to help us as specifiers? > > [MB] Yes. This is an objected oriented design model - you define the > data you need for the functionality and then define the mechanisms for > creating, updating, etc. [/MB] > > I know XCON and SIPREC followed this approach but from my view as > a casual observer of the process is that these activities took a > long time to completion. > > [MB] The data model was the last thing that kept any of these WGs from > making good progress. The XCON data model was started well before any > of the other aspects of the protocol. SIPREC is moving along about as > a good of a piece as many other WGs, so I'm not sure why you have that > specific perception of that WG. [/MB] > > My fear is that Simon will be the only one who actually > understands the data model well. Others will just be put off from > looking closely at it because of the syntax. > > [MB] I personally find that quite silly since XML schemas are very, > very commonly used in IETF protocol documents these days. You haven't > been on the design team calls, but we had some very useful discussions > using the schema as a starting point. It helps very much to have > something concrete on the table and think most folks are now pretty > familiar with ready XML schemas. For folks that aren't, there are > quite a few useful books and websites. There are certainly some > nuances that you need to be aware of to use properly, but it's pretty > easy to learn enough to interpret the schema. We would get the XML > gurus to review the schema before progressing anything. > [/MB] [CNG] Silly? I seen enough protocol development over the years to know that people have different strengths in different schemes. I though it would be worth raising this to see if any people on the list weren't comfortable with XML. I'm glad to hear that it has been useful on the phone calls. > > Regards, Christian > > > On 1/11/2012 1:05 AM, Mary Barnes wrote: > > Simon also suggested that we need to enrich the framework. We > have gotten feedback in the past that it's difficult to read > as I think there is a middle level of detail that is missing. > We have had wonderful diagrams in .ppts at the meetings but > we have very few diagrams in the FW. I think it could help a > lot to add some. > > Mary. > > > On Wed, Oct 31, 2012 at 8:17 AM, Roni Even > > >> wrote: > > Hi Simon, > This will make the framework empty, section 1-4 do not > have any > information > that merit a document. > Roni > > -----Original Message----- > From: clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org > >] On > Behalf Of > Simon Pietro Romano > Sent: 30 October, 2012 12:24 PM > To: Christian Groves > Cc: clue@ietf.org > > > Subject: Re: [clue] Data model - agreement on objective > and basic > approach > > Hi Christian, > > a rough estimation would be the following: > > a) keep sections 1 through 4 inside the framework document; > b) move sections 5 through 8 to the data model document > c) move the XML schema to the data model document (final > section > of the data > model, which provides 'one possible' example of how to > formally > describe the > things in the document); > d) move section 9, together with subsections 9.1, 9.2 and > 9.3 to the > protocol document; > e) move subsection 9.4 to the call flows document; > f) move section 10 to the data model document; > g) move section 11 to the call flows document. > > Obviously, the resulting framework document should be > revised (and > enriched) in view of the proposed distribution of work > inside the > WG. I > would like it to represent an orchestration document, > providing an > overview > of issues, requirements, architecture and protocols. A > sort of summary > reference for all of the related "drill-down" documents, each > expanding on a > specific WG item (data model, protocol, call flows, etc.). > > I acknowledge the fact that this looks much like a > revolution, but I > nonetheless believe that we already have most of the needed > material at hand > and just need to better distribute it across the documents > produced by the > WG. > > Cheers, > > Simon > > > > > Il 30/10/2012 10:33, Christian Groves ha scritto: > > Hello Simon, > > > > When you say that you want to remove "all" the data > model stuff from > > the framework can you be a bit more specific as to what > parts > you want > > removed? > > > > Regards, Christian > > > > On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: > >> Hi all, > >> > >> just to be clear on the current structure of the data > model schema: > >> all the things you find there were 'extracted' (by > Roberta and me) > >> from information currently contained inside the > framework draft (as > >> well as from some side documents, associated with > either the data > >> model or the envisaged call flows). So, unless we have > misinterpreted > >> the above document(s) (which is obviously possible), we > should > first > >> of all focus on the framework in order to try and > converge on an > >> agreed-upon CLUE architecture. Once done with this, we can > fine-tune > >> the data model. As I already stated on this list, it is > my personal > >> opinion that we should remove from the framework > document all > of the > >> data-model stuff that it currently contains, and rather > focus on a > >> clear definition of framework components and interfaces. I > might look > >> naif, but I would like to arrive at an 'ordinary' set > of documents: > >> (i) general framework; (ii) data model; (iii) clue > protocol (with > >> advertisement and configuration messages); (iv) call > flows (showing > >> how SDP O/A and CLUE protocol messages concur in > effectively > setting > >> up a CLUE session). > >> > >> As to the 'UML vs XML' querelle, I would suggest that: > >> > >> 1. Both UML class diagrams and XML schema can be > adopted for the > >> description of the data model, i.e., the STATIC part of the > >> framework, associated with the description of what some > of you > >> properly called a 'CLUE instance'; 2. UML sequence > diagrams can be > >> adopted to describe CLUE call flows, i.e. the DYNAMIC > part of the > >> framework, which clearly envisages the co-existence of > SDP and CLUE > >> protocol messages. XML schemas are not suitable for > this dynamic > >> part. > >> > >> This said, it is clear that CLUE protocol messages (in > particular, > >> CLUE advertisements) will be constructed by leveraging > information > >> contained inside a CLUE instance. Which parts of a CLUE > instance > >> should go into an advertisement and which should be > carried inside > >> SDP can be a matter of discussion. > >> > >> My 2 cents, > >> > >> Simon > >> > >> > >> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha > scritto: > >> > >>> On 10/29/12 6:23 PM, Roni Even wrote: > >>>> Paul, > >>>> This was the statement I answered "no" > >>>> " The general agreement on the call is that the data > model as > >>>> reflected in draft-presta-clue-data-model-schema > describes > the data > >>>> needed by the CLUE application" > >>>> I disagree that it reflects that data needed by a CLUE > application > >>>> and I explained why. > >>> > >>> OK, fair enough. > >>> > >>> Mary can comment, but my take was that the point of her > question was > >>> to distinguish between two alternatives: > >>> - the data model represents all the data needed by the > clue app. > >>> (which implies to me that it encompasses all the data > in the > >>> framework.) > >>> - the data model represents the data to be exchanged > in clue > >>> messages. > >>> > >>> It is a bigger deal if the framework includes things > that are not > >>> needed by the clue application. I was of the > impression that, > except > >>> for some fine tuning, we were largely in agreement on the > framework. > >>> > >>> If we don't have consensus on *that* then resolving > that is of > >>> higher priority that much of the other stuff we are > discussing. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Roni > >>>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org > > > >> > >>>> [mailto:clue-bounces@ietf.org > >] > On Behalf Of Paul Kyzivat > >>>> Sent: 29 October, 2012 9:46 PM > >>>> To: clue@ietf.org > > > > >> > >>>> Subject: Re: [clue] Data model - agreement on > objective and basic > >>>> approach > >>>> > >>>> On 10/29/12 3:19 PM, Roni Even wrote: > >>>>> Hi, > >>>>> > >>>>> My view is 'no". I still fail to see the need for > the encoding > >>>>> groups and individual encodes. > >>>>> > >>>>> In the current definition of capture scene, I am not > sure > what is > >>>>> the meaning of different individual encodes and > eventually the > >>>>> receiver can define what it can receive (Typically > H.264 is > >>>>> symmetric in terms of profile but does not need to > be in the > >>>>> level) and can ask for specific resolution with the > SDP image > >>>>> attribute > >>>> > >>>> ISTM that you are answering a different question than > the one > Mary > >>>> asked. > >>>> You seem to be saying that you disagree with the > framework as > it is > >>>> - that > >>>> it can/should be simpler. > >>>> > >>>> That is a separate question. If such changes were > made it might > >>>> affect a lot. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Roni Even > >>>>> > >>>>> *From:*clue-bounces@ietf.org > > > >> > >>>>> [mailto:clue-bounces@ietf.org > > >] *On Behalf Of *Mary Barnes > > >>>>> *Sent:* 29 October, 2012 7:52 PM > >>>>> *To:* CLUE > >>>>> *Subject:* [clue] Data model - agreement on > objective and basic > >>>>> approach > >>>>> > >>>>> On the call earlier today, we also discussed the > data model. > The > >>>>> general agreement on the call is that the data model as > reflected > >>>>> in draft-presta-clue-data-model-schema describes the > data needed > >>>>> by the CLUE application - i.e., it's the CLUE instance > concept. It > >>>>> does not directly reflect the contents of a CLUE > message. The > >>>>> application data would be used to populate CLUE > messages, as > well > >>>>> as SDP and would reflect updates based on both the > CLUE and SDP > >>>>> signaling. > >>>>> > >>>>> If we can get agreement on that before the meeting, I > believe our > >>>>> discussions can be much more productive. If folks > could please > >>>>> reply "Yes" or "No" reflecting agreement with the > above, that > >>>>> would be helpful. If you reply "No", please explain > why. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Mary > >>>>> > >>>>> as CLUE WG co-chair > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > > > > > >> > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > > > > > >> > >>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > > > > > >> > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _\\|//_ > >> ( 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 > > > > _______________________________________________ > > 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 Science Department > Phone: +39 081 7683823 > -- > Fax: +39 081 7684219 > > e-mail: spromano@unina.it > > > > http://www.comics.unina.it/simonpietro.romano > > < idioti. Ci rifletto un istante; e mi scoraggio>>. > Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ > Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > _______________________________________________ > 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 Fri Nov 2 02:36: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 4329021F9941 for ; Fri, 2 Nov 2012 02:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 ZUf0cU4IkHYB for ; Fri, 2 Nov 2012 02:36:21 -0700 (PDT) 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 78FA521F994D for ; Fri, 2 Nov 2012 02:36:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAL+Sk1B20R8y/2dsb2JhbAANN8ZdAQEBAwE4GxUhCyElDwJGEwgBAYgAqD+TTYwLgw2DJAOpQA Received: from ppp118-209-31-50.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.31.50]) by ipmail04.adl6.internode.on.net with ESMTP; 02 Nov 2012 20:06:20 +1030 Message-ID: <5093940E.50603@nteczone.com> Date: Fri, 02 Nov 2012 20:36:14 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <50929378.3010701@alum.mit.edu> In-Reply-To: <50929378.3010701@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Data model - agreement on objective and basic approach X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 02 Nov 2012 09:36:22 -0000 Hello Paul, I had the same confusion and concern as you below. I think that keeping the data model just to the advertisement would simplify things. If an *instance* includes the things you mention below it seems to me that the data model is going beyond a protocol to communicate captures. The model starts to get into the realm of defining overall multistream conference state. Regards, Christian > >> 1. Both UML class diagrams and XML schema can be adopted for the >> description of the data model, i.e., the STATIC part of the framework, >> associated with the description of what some of you properly called a >> 'CLUE instance'; > > IMO, regardless of intent, it is currently hard to tell by looking > whether the current version of the model is a representation of an > *instance* or of an *advertisement*. > > ISTM that the "clueInfo" element maps almost 1:1 onto an advertisement. > > An instance will require more state. E.g. > - the content of the most recently sent advertisement > - the content of the most recently received configuration > - the content of the most recently completed SDP O/A exchange > - the mapping of the configuration to physical resources such as > physical devices, encoders, decoders, etc. > > This is tricky. Some of the information about resources is > fundamentally implementation specific, so finding where to draw the > line between what must be modeled and what must not is hard. > > Thanks, > Paul From roberta.presta@unina.it Fri Nov 2 03:31: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 9DFCB21F99C8 for ; Fri, 2 Nov 2012 03:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.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] 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 6HR5O1bm3jKu for ; Fri, 2 Nov 2012 03:31:52 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id B92D621F99BB for ; Fri, 2 Nov 2012 03:31:51 -0700 (PDT) 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 qA2AVk0J025078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2012 11:31:46 +0100 Message-ID: <5093A121.2040805@unina.it> Date: Fri, 02 Nov 2012 11:32:01 +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: Paul Kyzivat References: <508A6242.80001@unina.it> <5091009C.8070805@unina.it> <5092A9E3.6010000@alum.mit.edu> In-Reply-To: <5092A9E3.6010000@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------040005010301020109030509" X-Antivirus: avast! (VPS 121101-1, 01/11/2012), Outbound message X-Antivirus-Status: Clean Cc: clue@ietf.org Subject: Re: [clue] again on X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 02 Nov 2012 10:31:52 -0000 This is a multi-part message in MIME format. --------------040005010301020109030509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Il 01/11/2012 17:57, Paul Kyzivat ha scritto: > On 10/31/12 6:42 AM, Roberta Presta wrote: > >> >> >> > type="tns:spatialInformationType" maxOccurs="unbounded"/> >> >> > type="xs:boolean" fixed="true"/> >> > > I'm an xml lightweight. In the above, why isn't it just: > > > type="tns:spatialInformationType" maxOccurs="unbounded"/> > type="xs:boolean" fixed="true"/> > > > What do the s add? > > Thanks, > Paul Hi Paul, putting the element inside with maxOccurs="unbounded" means that you can find more than one describing a capture. Using a definition without , on the other hand, means that you can find only one describing a capture. The definition would look like the following: The current definition (the one with ) leaves open the possibility of specifying more than one for a capture. That chance could be exploited in case of composed capture to describe spatially each component by adding a element for each of them (I don't know if it could be really useful, I have left the definition "as is" to the aim of discussing about it). Alternatively, we can decide that only one can be provided for a capture. In case of composed capture that are also spatially definible, the single element would carry the information of the maximum captured space. In that case, the XML Schema definition would remove the envelope and the maxOccurs="unbounded" attribute, as reported above. What is the option that makes more sense to you? Cheers, Roberta --------------040005010301020109030509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Il 01/11/2012 17:57, Paul Kyzivat ha scritto:
On 10/31/12 6:42 AM, Roberta Presta wrote:

          <xs:choice>
              <xs:sequence>
               <xs:element name="spatialInformation" type="tns:spatialInformationType" maxOccurs="unbounded"/>
             </xs:sequence>                
              <xs:element name="nonSpatiallyDefinible" type="xs:boolean" fixed="true"/>                
          </xs:choice>

I'm an xml lightweight. In the above, why isn't it just:

<xs:choice>
  <xs:element name="spatialInformation"
              type="tns:spatialInformationType" maxOccurs="unbounded"/>
  <xs:element name="nonSpatiallyDefinible"
              type="xs:boolean" fixed="true"/>                
</xs:choice>

What do the <sequence>s add?

    Thanks,
    Paul

Hi Paul,

putting the <spatialInformation> element inside <sequence> with maxOccurs="unbounded" means that you can find more than one <spatialInformation> describing a capture.
Using a definition without <sequence>, on the other hand, means that you can find only one <spatialInformation> describing a capture. The definition would look like the following:

<xs:choice>
  <xs:element name="spatialInformation"
              type="tns:spatialInformationType"/>
  <xs:element name="nonSpatiallyDefinible"
              type="xs:boolean" fixed="true"/>                
</xs:choice>


The current definition (the one with <sequence>) leaves open the possibility of specifying more than one <spatialInformation> for a capture.  That chance could be exploited in case of composed capture to describe spatially each component  by adding  a <spatialInformation> element for each of them (I don't know if it could be really useful, I have left the definition "as is" to the aim of discussing about it).

Alternatively, we can decide that only one <spatialInformation> can be provided for a capture.
In case of composed capture that are also spatially definible, the single <spatialInformation> element would carry the information of the maximum captured space.
In that case, the XML Schema definition would remove the <sequence> envelope and the maxOccurs="unbounded" attribute, as reported above.

What is the option that makes more sense to you?

Cheers,

Roberta


--------------040005010301020109030509-- From spromano@unina.it Fri Nov 2 04:34: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 30FA521F9937 for ; Fri, 2 Nov 2012 04:34:07 -0700 (PDT) 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 xhbAdPIMUIEP for ; Fri, 2 Nov 2012 04:34:06 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 18BC621F9375 for ; Fri, 2 Nov 2012 04:34:05 -0700 (PDT) Received: from [10.219.32.44] ([10.219.32.44]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id qA2BXoLK030991 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 2 Nov 2012 12:34:00 +0100 Message-ID: <5093AF90.5030801@unina.it> Date: Fri, 02 Nov 2012 12:33:36 +0100 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "clue@ietf.org >> CLUE" References: <508A6242.80001@unina.it> <5091009C.8070805@unina.it> <5092A9E3.6010000@alum.mit.edu> <5093A121.2040805@unina.it> In-Reply-To: <5093A121.2040805@unina.it> Content-Type: multipart/alternative; boundary="------------050605010600090502000304" Subject: Re: [clue] again on X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 02 Nov 2012 11:34:07 -0000 This is a multi-part message in MIME format. --------------050605010600090502000304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear all, waiting for I-D submissions to re-open, I have temporarily published the new version of the clue data model schema on the following site: http://www.grid.unina.it/Didattica/RetiDiCalcolatori/inf/draft-presta-clue-data-model-schema-02.html I hope this proves useful for those who want to have fresh information at the upcoming CLUE session on Monday. The file contains the updated version of the schema (which tries to adhere to the latest discussions), as well as a sample XML file compliant with the proposed schema. Cheers, Simon Il 02/11/2012 11:32, Roberta Presta ha scritto: > Il 01/11/2012 17:57, Paul Kyzivat ha scritto: >> On 10/31/12 6:42 AM, Roberta Presta wrote: >> >>> >>> >>> >> type="tns:spatialInformationType" maxOccurs="unbounded"/> >>> >>> >> type="xs:boolean" fixed="true"/> >>> >> >> I'm an xml lightweight. In the above, why isn't it just: >> >> >> > type="tns:spatialInformationType" maxOccurs="unbounded"/> >> > type="xs:boolean" fixed="true"/> >> >> >> What do the s add? >> >> Thanks, >> Paul > > Hi Paul, > > putting the element inside with > maxOccurs="unbounded" means that you can find more than one > describing a capture. > Using a definition without , on the other hand, means that > you can find only one describing a capture. The > definition would look like the following: > > > type="tns:spatialInformationType"/> > type="xs:boolean" fixed="true"/> > > > > The current definition (the one with ) leaves open the > possibility of specifying more than one for a > capture. That chance could be exploited in case of composed capture > to describe spatially each component by adding a > element for each of them (I don't know if it > could be really useful, I have left the definition "as is" to the aim > of discussing about it). > > Alternatively, we can decide that only one can be > provided for a capture. > In case of composed capture that are also spatially definible, the > single element would carry the information of the > maximum captured space. > In that case, the XML Schema definition would remove the > envelope and the maxOccurs="unbounded" attribute, as reported above. > > What is the option that makes more sense to you? > > Cheers, > > Roberta > > > > > _______________________________________________ > 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 Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --------------050605010600090502000304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

waiting for I-D submissions to re-open, I have temporarily published the new version of the clue data model schema on the following site:

http://www.grid.unina.it/Didattica/RetiDiCalcolatori/inf/draft-presta-clue-data-model-schema-02.html

 I hope this proves useful for those who want to have fresh information at the upcoming CLUE session on Monday. The file contains the updated version of the schema (which tries to adhere to the latest discussions), as well as a sample XML file compliant with the proposed schema.

Cheers,

Simon


Il 02/11/2012 11:32, Roberta Presta ha scritto:
Il 01/11/2012 17:57, Paul Kyzivat ha scritto:
On 10/31/12 6:42 AM, Roberta Presta wrote:

          <xs:choice>
              <xs:sequence>
               <xs:element name="spatialInformation" type="tns:spatialInformationType" maxOccurs="unbounded"/>
             </xs:sequence>                
              <xs:element name="nonSpatiallyDefinible" type="xs:boolean" fixed="true"/>                
          </xs:choice>

I'm an xml lightweight. In the above, why isn't it just:

<xs:choice>
  <xs:element name="spatialInformation"
              type="tns:spatialInformationType" maxOccurs="unbounded"/>
  <xs:element name="nonSpatiallyDefinible"
              type="xs:boolean" fixed="true"/>                
</xs:choice>

What do the <sequence>s add?

    Thanks,
    Paul

Hi Paul,

putting the <spatialInformation> element inside <sequence> with maxOccurs="unbounded" means that you can find more than one <spatialInformation> describing a capture.
Using a definition without <sequence>, on the other hand, means that you can find only one <spatialInformation> describing a capture. The definition would look like the following:

<xs:choice>
  <xs:element name="spatialInformation"
              type="tns:spatialInformationType"/>
  <xs:element name="nonSpatiallyDefinible"
              type="xs:boolean" fixed="true"/>                
</xs:choice>


The current definition (the one with <sequence>) leaves open the possibility of specifying more than one <spatialInformation> for a capture.  That chance could be exploited in case of composed capture to describe spatially each component  by adding  a <spatialInformation> element for each of them (I don't know if it could be really useful, I have left the definition "as is" to the aim of discussing about it).

Alternatively, we can decide that only one <spatialInformation> can be provided for a capture.
In case of composed capture that are also spatially definible, the single <spatialInformation> element would carry the information of the maximum captured space.
In that case, the XML Schema definition would remove the <sequence> envelope and the maxOccurs="unbounded" attribute, as reported above.

What is the option that makes more sense to you?

Cheers,

Roberta




_______________________________________________
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 Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
--------------050605010600090502000304-- From pkyzivat@alum.mit.edu Fri Nov 2 06:42: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 529B521F888B for ; Fri, 2 Nov 2012 06:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=0.041, 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 zBln2h4OTZoC for ; Fri, 2 Nov 2012 06:42:32 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 948EA21F8887 for ; Fri, 2 Nov 2012 06:42:32 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta15.westchester.pa.mail.comcast.net with comcast id JbqT1k00B0QuhwU5Fdj64E; Fri, 02 Nov 2012 13:43:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id Jdi01k00G3ZTu2S3Ndi0gr; Fri, 02 Nov 2012 13:42:00 +0000 Message-ID: <5093CDC6.2090607@alum.mit.edu> Date: Fri, 02 Nov 2012 09:42:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <020401cdb76a$16131c60$42395520$@gmail.com> <5091C644.5070401@nteczone.com> <5093915D.4010900@nteczone.com> In-Reply-To: <5093915D.4010900@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Data model - agreement on objective and basic approach X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 02 Nov 2012 13:42:33 -0000 Christian, >> My fear is that Simon will be the only one who actually >> understands the data model well. Others will just be put off from >> looking closely at it because of the syntax. >> >> [MB] I personally find that quite silly since XML schemas are very, >> very commonly used in IETF protocol documents these days. You haven't >> been on the design team calls, but we had some very useful discussions >> using the schema as a starting point. It helps very much to have >> something concrete on the table and think most folks are now pretty >> familiar with ready XML schemas. For folks that aren't, there are >> quite a few useful books and websites. There are certainly some >> nuances that you need to be aware of to use properly, but it's pretty >> easy to learn enough to interpret the schema. We would get the XML >> gurus to review the schema before progressing anything. >> [/MB] > [CNG] Silly? I seen enough protocol development over the years to know > that people have different strengths in different schemes. I though it > would be worth raising this to see if any people on the list weren't > comfortable with XML. I'm glad to hear that it has been useful on the > phone calls. At the end of the day we have to adopt *some* formalism about data - at least the data carried in protocol messages. Most new things being developed today are using XML. I expect that people involved in IETF at a deep enough level to care about the details of the protocol will learn the formalisms needed to understand the protocol definitions. IMO people who can't at least *read* an xml schema should consider a new line of work. (I feel the same about UML, but it is used less often in this context so I am willing to cut people a little slack on it.) That does't mean everyone has to be an expert on XML. I'm certainly not. I can construct most of a simple schema using some cut and paste. But I'm not competent make good decisions on the best way to represent things, or how to represent some complex things. So I look for someone like Roberta to help with things like that. Thanks, Paul From pkyzivat@alum.mit.edu Fri Nov 2 06: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 D188821F8946 for ; Fri, 2 Nov 2012 06:55:09 -0700 (PDT) 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 lSn8niyi2cpU for ; Fri, 2 Nov 2012 06:55:09 -0700 (PDT) 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 7E48821F87DF for ; Fri, 2 Nov 2012 06:55:08 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id JdCw1k00y1uE5Es53dv7RZ; Fri, 02 Nov 2012 13:55:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id JdvL1k00R3ZTu2S3cdvL8e; Fri, 02 Nov 2012 13:55:20 +0000 Message-ID: <5093D0B3.1060800@alum.mit.edu> Date: Fri, 02 Nov 2012 09:54:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Roberta Presta References: <508A6242.80001@unina.it> <5091009C.8070805@unina.it> <5092A9E3.6010000@alum.mit.edu> <5093A121.2040805@unina.it> In-Reply-To: <5093A121.2040805@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] again on X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 02 Nov 2012 13:55:09 -0000 On 11/2/12 6:32 AM, Roberta Presta wrote: > Il 01/11/2012 17:57, Paul Kyzivat ha scritto: >> On 10/31/12 6:42 AM, Roberta Presta wrote: >> >>> >>> >>> >> type="tns:spatialInformationType" maxOccurs="unbounded"/> >>> >>> >> type="xs:boolean" fixed="true"/> >>> >> >> I'm an xml lightweight. In the above, why isn't it just: >> >> >> > type="tns:spatialInformationType" maxOccurs="unbounded"/> >> > type="xs:boolean" fixed="true"/> >> >> >> What do the s add? >> >> Thanks, >> Paul > > Hi Paul, > > putting the element inside with > maxOccurs="unbounded" means that you can find more than one > describing a capture. Oh, duh! Sorry. I totally missed the "unbounded". Now I understand the difference. > Using a definition without , on the other hand, means that you > can find only one describing a capture. The > definition would look like the following: > > > type="tns:spatialInformationType"/> > type="xs:boolean" fixed="true"/> > > > > The current definition (the one with ) leaves open the > possibility of specifying more than one for a > capture. That chance could be exploited in case of composed capture to > describe spatially each component by adding a > element for each of them (I don't know if it could be really useful, I > have left the definition "as is" to the aim of discussing about it). Thanks for pointing that out now. That deserves some discussion. There is a slippery slope here into some major complexity. We started to talk about that at the interim. In the case of a switched capture where all of the switched sources come from the same scene this could be somewhat meaningful, though I wonder if it would be *useful*. In the case of a composed capture where all the sources come from the same scene I have difficulty understanding how to make any sense of this info. And this isn't even capable of representing the case of a switched or composed capture where the sources come from *different* scenes. > Alternatively, we can decide that only one can be > provided for a capture. > In case of composed capture that are also spatially definible, the > single element would carry the information of the > maximum captured space. > In that case, the XML Schema definition would remove the > envelope and the maxOccurs="unbounded" attribute, as reported above. > > What is the option that makes more sense to you? Let's discuss a bit and see what others have to say. For now I think that the latter may be the most expedient choice. Thanks, Paul From apeppere@gmail.com Fri Nov 2 08:20: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 E4FC51F0C3A for ; Fri, 2 Nov 2012 08:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.222 X-Spam-Level: X-Spam-Status: No, score=0.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, 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 B1pQjX-zXfC4 for ; Fri, 2 Nov 2012 08:20:19 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA7821F8B14 for ; Fri, 2 Nov 2012 08:20:19 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so943037qao.10 for ; Fri, 02 Nov 2012 08:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iop5cOoE9w8vP8dGK1kdBfHkQtomfghyq5DhHYFc0G4=; b=DfJbRBcXpDIiaYZ4GiAT26wxrTI84n1J3w5mBDZGqAOJNlpvD3qgeb4AwYoQ1x0AQV JjCB8YlJBTL0X/d60eAui989AceV/I0ltAqnIm6k5lYoqCErAlyPF/0VICQcy7qofX5W dyJAxra5Vc+kKIDqGmUG9574Jk6QfTJWch7ctU+cYA2Em6XjAxXs3OtIFsF26Uvau3+z RzbtntucPbpIvLrpNPZd9SbnnMBBgKdDkkbls4YLIxw6Y/BbO6+pIZI2flPJbUH/YivO gAirAIUvA/zqoLCG70fNoxZK5er/igs/An0EZeIdovdF6H/1fE0QAKPP0ZRGBIdUYGls d+iw== MIME-Version: 1.0 Received: by 10.49.118.40 with SMTP id kj8mr2892214qeb.64.1351869618645; Fri, 02 Nov 2012 08:20:18 -0700 (PDT) Received: by 10.49.96.98 with HTTP; Fri, 2 Nov 2012 08:20:18 -0700 (PDT) In-Reply-To: <5092A599.4010601@alum.mit.edu> References: <01d301cdb74d$10857940$31906bc0$@gmail.com> <5092A599.4010601@alum.mit.edu> Date: Fri, 2 Nov 2012 15:20:18 +0000 Message-ID: From: Andy Pepperell To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b6d981266eae004cd84ac16 Cc: clue@ietf.org Subject: Re: [clue] Do we need the encodings as secified in the framework document - proposal to remove them from the framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 02 Nov 2012 15:20:22 -0000 --047d7b6d981266eae004cd84ac16 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >Paul: >*If* this works and satisfies all objectives then it will be a helpful simplification. But it may be that simplifying things this way excludes some required behavior. I certainly agree with Paul's point here... however, with not all that many of Roni's (as might be expected :) ) - to be specific: >Roni: >Each encoding group include a list of individual encodes (audio and /or video). These provide maximum values that can be used to instantiate a media stream by the provider.**** Yes, I think that's a good summary. ** ** >Each video individual encodes identified by an encodeID provides maximum values for BW, compute, resolution and frame rate for H.264. (BTW: the maxH264Mbps can be computed from the resolution and frame rate as defined in table 2 making it redundant).**** >Each audio encode has only a BW value (no identifier).**** Also agreed - apart from the H.264 point I think - a maximum resolution and a maximum frame rate doesn't necessarily imply a maxMbps - many systems can encode 1280x720 at some frame rate < 30 *or* some lower resolution at up to 30fps without necessarily being able to send 720p30, surely? ** ** ** ** > Roni: >A media capture is associated with an encoding group !!!!! not an individual encoding.**** That's true, and by design. To re-iterate the original design intent here, the idea behind the encoding groups idea was to be able to model 2 common Telepresence architectures we see today: 1) a multi-screen endpoint room comprised of multiple endpoints (most vendors' "3 screen" systems, for instance, tend to be composed of 3 of their "1 screen" products linked together) 2) a flexible media generation system such as a software or hardware MCU For the "1)" case above, due to real-world constraints such as camera wiring etc., it seemed to us that a media capture representing, say, the left camera of 3, would only be able to be encoded by the hardware it was directly connected to - thus, such a system would use one "encoding group" for its left constituent, one for its centre and one for its right. >Roni: >The provider can use one of the individual encoding to instantiate a media capture, each individual encoding can be used by one media capture, the decision of which one to use according to the framework is by the provider. The consumer does not select an individual encode.**** That was not the intent - it should be the consumer that chooses media capture / individual encoding pairs to instantiate "capture encodings". When forming its configure message, the consumer essentially supplies a set of media capture ID + encoding ID pairs to instruct the provider on which capture encodings to send. Having just re-read it, I think that the description as per Section 9 of the current framework document described this well (though Mark deserves the credit for that, obviously!). **>Roni: ** >The maximum number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group (note that this is why the example in the current data model allows only for one video and one audio streams).**** It is true that the number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group - however, a fully flexible system might choose to have a single encoding group and so no real restriction need be introduced by this (unless the provider system has such restrictions - in which case they can be modelled in this way). >Roni: >Section 8 of the framework talk about having more than one individual encoding assigned to a media capture (simulcast) and also claims that it can be done by the consumer but there is no way to do it since the media capture is associated only with an encoding group. There is no way for a consumer even to assign a specific individual encoding to a group.**** You're right that there's no way for the consumer to assign a specific individual encoding to a group, but it's not clear what the need is - if a provider system is sufficiently flexible that any encoding can be used by any media capture, then it should construct its advertisement to use just a single encoding group to comprise all encodings, at which point the consumer has greater flexibility in which it can choose to be sent to it. **>Roni: ** >The video is H.264 specific and not general The problem we had was that we needed to come up with a way of describing a big block of video encoding capability and how it could be subdivided. e.g. you might be able to send 2 x 720p30 but not a single 720p60. The best scheme we could come up with was to, for each of H.264, H.265 etc. include some specific parameters that would allow both a provider's overall capability to be signalled and how it might be subdivided across multiple encodings. It's true that currently the parameters only really work for H.264 and, moreover, only really work for a provider sending all encodings within a group using the same codec, but the expectation was that new codecs would have their own equivalent parameters added here in a similar way. ** >Roni: >The relation between the individual encode and encoding group makes it difficult to achieve a reasonable set even if the consumer will be able to select the mapping. This is due to the fact the total defined by the group limits the usage for individual encoding. For example if we have a three camera system and we set a value in the group for maxGroupH264Mbps and want to allow for simulcast (two resolutions), we will need to define six individual encodes, three with high resolution ( also high maxH264Mbps) and three lower resolution with lower maxH264Mbps. If the compute resource can do all six it will reflected in the value of maxGroupH264Mbps but I assume that there is a constrain (otherwise why have encodings) making it lower. So if the consumer will ask for all six what will happen. Since there is more than one degree of freedom he will not be able to predict if he will get all or part on lower frame rate , if he will get only a subset of the streams, if he will get different resolutions.**** The situation you describe is, I would argue, exactly what the parameters are for. The consumer would be allowed to ask for all 6, each with consumer-imposed maximum values. The provider would be bound by its overall maxGroupH264Mbps as well as each individual encoding's max. value - in many senses this is no difference to existing systems' balancing of bit rate across main and presentation limits. I think if the consumer asks for all six then what will happen should be very predictable - 6 capture encodings will be sent to the consumer, with each capped by the lower of the consumer's request parameters and the provider's limitations. It is true that the frame rate / resolution would be bounded but not fixed, but this is true today on a video call - if you can receive 720p30 you don't know whether the far end will send you 720p30, 720p5, CIF30 etc. I'm not sure I see how what we're talking about here does anything but follow normal encoder and decoder behavior as seen today (equally, I confess that I may not be fully understanding the intricacies of the case you describe). >On the other hand if the 6 individual encodes will include lower values to allow for the group limit it will mean that a consumer not doing simulcast is limited by the fact the simulcast and ask (if possible) for only three streams, the individual encodes limit will be low so he will not be able to use the full compute resources. ** ** >Roni: >Section 8 concludes that the number of individual encodes in a group must allow for all media capture in a capture scene entry to be used simultaneously.**** Yes, this is a corollary of the constraint that all media captures in a capture scene entry must be able to be provided simultaneously (which itself is a corollary of the idea that each capture scene entry is in itself a useful representation of the scene). ** ** >So it look like this system does not work well for simulcast. What about no simulcast, is it needed. For example a three camera system that also have one presentation. My view that the cameras will be one capture scene and the presentation will be a second one. The question is if they all belong to one encoding group, here my view is =93no=94 since they have different priority and should not compete for compute resources. Another view is that if the provider does encode the cameras and the presentation from the same pool of encoding resource then it is valid for the consumer to choose which to prioritise (i.e. the provider could leave the consumer to allocate encodings to the media captures). >Roni: >So we will have two encoding groups one for presentation and one for the three cameras. For the three cameras each sending one stream I assume that the resource allocation will be a third for each so we will have three individual encode with the same values, this is the basic one and if it is a third than no need for advertising or configuring. Now if we also want to have an individual encode that has higher compute if the consumer wants only one capture (of the whole room), the group will have fourth one with higher value. So if there is way for consumer to configure individual encode when using three media captures, he may select the higher capability one with two lower ones. The total will be limited by the encoding group value and again it is not clear how the actual streams will be encoded to address the group limit since there are multiple options.**** To my mind this is no different to the sort of trace offs / choices that are already made in this sort of system today - in a video call it is common to not be able to send a camera stream at full resolution and full frame rate either because of bandwidth limitations or the capabilities of the receiver. In the case you cite, yes, the consumer could choose to impose different video limits on the left center and right cameras, but it would be within its rights to do so, just as the provider would then be within its rights to send them all at the lowest of the 3 levels. **>Roni: ** >To summarize I do not see value in the encoding as currently specified since they only provide information and no option for configuration. The value of it as information does not justify specifying them and if the intention is to allow configurations of individual encoding it must be reflected and the explained how it works.**** **>Roni: ** >My proposal is at the moment to remove the encoding until we get some text that defines how to use it for configuring encoding to media captures including for the simulcast case I think I'd agree with you if it really were true that simulcast was ill-defined here, but I think it's covered pretty well. It's clear that you've thought about it in a lot of detail though, so I'm sure there'll be more to discuss on this... Regards, Andy On Thu, Nov 1, 2012 at 4:38 PM, Paul Kyzivat wrote: > (As co-chair) > > Roni is proposing a significant change here. > > PLEASE carefully consider this and comment on it here on the mailing list= ! > > *If* this works and satisfies all objectives then it will be a helpful > simplification. But it may be that simplifying things this way excludes > some required behavior. > > This is something that would benefit from discussion next week. But that > won't be helpful if people haven't already thought about it. > > Thanks, > Paul > > > On 10/31/12 5:49 AM, Roni Even wrote: > >> Hi, >> >> From the email discussion it looks to me that the concept of the >> encoding as specified in the framework document is not clear. I will try >> to describe my understanding of sections 7 and 8 of the framework >> document and explain why I think that it is not important to CLUE as >> specified. I am looking for response if my understanding of the encoding >> based on the framework is correct and how it will work for the examples >> I will provide bellow >> >> The purpose of the Encodings is to provide INFORMATION about the >> provider abilities to send streams. This relates to the available >> resources (compute and BW) of the providers. >> >> The encodings are constructed from encoding groups and each encoding >> group is include individual encodes. >> >> The encoding group provide a value for the total maximum BW and compute >> H264Mbps (note that it is H.264 specific) of all the individual encodes >> in the group that the provider can use to send audio and video. >> >> Each encoding group include a list of individual encodes (audio and /or >> video). These provide maximum values that can be used to instantiate a >> media stream by the provider. >> >> Each video individual encodes identified by an encodeID provides maximum >> values for BW, compute, resolution and frame rate for H.264. (BTW: the >> maxH264Mbps can be computed from the resolution and frame rate as >> defined in table 2 making it redundant). >> >> Each audio encode has only a BW value (no identifier). >> >> A media capture is associated with an encoding group !!!!! not an >> individual encoding. >> >> The provider can use one of the individual encoding to instantiate a >> media capture, each individual encoding can be used by one media >> capture, the decision of which one to use according to the framework is >> by the provider. The consumer does not select an individual encode. >> >> The maximum number of streams that can result from a particular encoding >> group is equal to the number of individual encodings in the group (note >> that this is why the example in the current data model allows only for >> one video and one audio streams). >> >> Section 8 of the framework talk about having more than one individual >> encoding assigned to a media capture (simulcast) and also claims that it >> can be done by the consumer but there is no way to do it since the media >> capture is associated only with an encoding group. There is no way for a >> consumer even to assign a specific individual encoding to a group. >> >> My view is that this mechanism does not work and can be removed. The >> reasons are given bellow >> >> The encoding as currently specified is provided as information since >> there is no way to map one or more individual encoding to a specific >> media capture >> >> The video is H.264 specific and not general >> >> The relation between the individual encode and encoding group makes it >> difficult to achieve a reasonable set even if the consumer will be able >> to select the mapping. This is due to the fact the total defined by the >> group limits the usage for individual encoding. For example if we have >> a three camera system and we set a value in the group for >> maxGroupH264Mbps and want to allow for simulcast (two resolutions), we >> will need to define six individual encodes, three with high resolution ( >> also high maxH264Mbps) and three lower resolution with lower >> maxH264Mbps. If the compute resource can do all six it will reflected >> in the value of maxGroupH264Mbps but I assume that there is a constrain >> (otherwise why have encodings) making it lower. So if the consumer will >> ask for all six what will happen. Since there is more than one degree of >> freedom he will not be able to predict if he will get all or part on >> lower frame rate , if he will get only a subset of the streams, if he >> will get different resolutions. >> >> On the other hand if the 6 individual encodes will include lower values >> to allow for the group limit it will mean that a consumer not doing >> simulcast is limited by the fact the simulcast and ask (if possible) for >> only three streams, the individual encodes limit will be low so he will >> not be able to use the full compute resources. >> >> Section 8 concludes that the number of individual encodes in a group >> must allow for all media capture in a capture scene entry to be used >> simultaneously. >> >> So it look like this system does not work well for simulcast. What about >> no simulcast, is it needed. For example a three camera system that also >> have one presentation. My view that the cameras will be one capture >> scene and the presentation will be a second one. The question is if they >> all belong to one encoding group, here my view is =93no=94 since they ha= ve >> different priority and should not compete for compute resources. So we >> will have two encoding groups one for presentation and one for the three >> cameras. For the three cameras each sending one stream I assume that the >> resource allocation will be a third for each so we will have three >> individual encode with the same values, this is the basic one and if it >> is a third than no need for advertising or configuring. Now if we also >> want to have an individual encode that has higher compute if the >> consumer wants only one capture (of the whole room), the group will have >> fourth one with higher value. So if there is way for consumer to >> configure individual encode when using three media captures, he may >> select the higher capability one with two lower ones. The total will be >> limited by the encoding group value and again it is not clear how the >> actual streams will be encoded to address the group limit since there >> are multiple options. >> >> To summarize I do not see value in the encoding as currently specified >> since they only provide information and no option for configuration. The >> value of it as information does not justify specifying them and if the >> intention is to allow configurations of individual encoding it must be >> reflected and the explained how it works. >> >> My proposal is at the moment to remove the encoding until we get some >> text that defines how to use it for configuring encoding to media >> captures including for the simulcast case >> >> Thanks >> >> Roni Even >> >> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> >> > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --047d7b6d981266eae004cd84ac16 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
>Paul:
>*If* this works and satisfies all objectives then it will be a helpful = simplification. But it may be that simplifying things this way excludes som= e required behavior.

I certainly agree with Paul's point here... however, with not all that = many of Roni's (as might be expected :) ) - to be specific:
>Roni:

>Each encoding grou= p include a list of individual encodes =A0(audio and /or video). These prov= ide maximum values that can be used to instantiate a media stream by the pr= ovider.


Yes, I think that's a good summary.

=A0

>Each video individ= ual encodes identified by an encodeID provides maximum values =A0for BW, co= mpute, resolution and frame rate for H.264. (BTW: the maxH264Mbps can be co= mputed from the resolution and frame rate as defined in table 2 making it r= edundant).

>Each audio encode = has only a BW value (no identifier).


Also a= greed - apart from the H.264 point I think - a maximum resolution and a max= imum frame rate doesn't necessarily imply a maxMbps - many systems can = encode 1280x720 at some frame rate < 30 *or* some lower resolution at up= to 30fps without necessarily being able to send 720p30, surely?

=A0

= =A0

> Roni:

>A media capture is associated with an encoding group !!!!! not an ind= ividual encoding.


That's true, and by design. To re-iterate the original d= esign intent here, the idea behind the encoding groups idea was to be able = to model 2 common Telepresence architectures we see today:

1) a multi-screen endpoint room comprised of multipl= e endpoints (most vendors' "3 screen" systems, for instance, = tend to be composed of 3 of their "1 screen" products linked toge= ther)

2) a flexible media generation system such as a soft= ware or hardware MCU


For the "1)" case above, due to real-world constraints such as= camera wiring etc., it seemed to us that a media capture representing, say= , the left camera of 3, would only be able to be encoded by the hardware it= was directly connected to - thus, such a system would use one "encodi= ng group" for its left constituent, one for its centre and one for its= right.


>Roni:

<= p class=3D"MsoNormal" style=3D"color:rgb(34,34,34)">>The provider can us= e one of the individual encoding to instantiate a media capture, each indiv= idual encoding can be used by one media capture, the decision of which one = to use according to the framework is by the provider. The consumer does not= select an individual encode.


That was not the intent - it should be the consumer that cho= oses media capture / individual encoding pairs to instantiate "capture= encodings". When forming its configure message, the consumer essentia= lly supplies a set of media capture ID + encoding ID pairs to instruct the = provider on which capture encodings to send. Having just re-read it, I thin= k that the description as per Section 9 of the current framework document d= escribed this well (though Mark deserves the credit for that, obviously!).<= /p>


>Roni:=A0

>The maximum number of streams that ca= n result from a particular encoding group is equal to the number of individ= ual encodings in the group (note that this is why the example in the curren= t data model allows only for one video and one audio streams).


It is true that the number of streams that can result from a= particular encoding group is equal to the number of individual encodings i= n the group - however, a fully flexible system might choose to have a singl= e encoding group and so no real restriction need be introduced by this (unl= ess the provider system has such restrictions - in which case they can be m= odelled in this way).



>Roni:
<= br>

>Section 8 of th= e framework talk about having more than one individual encoding assigned to= a media capture (simulcast) and also claims that it can be done by the con= sumer but there is no way to do it since the media capture is associated on= ly with an encoding group. There is no way for a consumer even to assign a = specific individual encoding to a group.


You're right that there's no way for the consumer to= assign a specific individual encoding to a group, but it's not clear w= hat the need is - if a provider system is sufficiently flexible that any en= coding can be used by any media capture, then it should construct its adver= tisement to use just a single encoding group to comprise all encodings, at = which point the consumer has greater flexibility in which it can choose to = be sent to it.



>Roni:= =A0

>The video is H.264 specific and = not general


The problem we had was that we needed to come up with a way = of describing a big block of video encoding capability and how it could be = subdivided. e.g. you might be able to send 2 x 720p30 but not a single 720p= 60. The best scheme we could come up with was to, for each of H.264, H.265 = etc. include some specific parameters that would allow both a provider'= s overall capability to be signalled and how it might be subdivided across = multiple encodings. It's true that currently the parameters only really= work for H.264 and, moreover, only really work for a provider sending all = encodings within a group using the same codec, but the expectation was that= new codecs would have their own equivalent parameters added here in a simi= lar way.



>Roni:

>The relation bet= ween the individual encode and encoding group makes it difficult to achieve= a reasonable set even if the consumer will be able to select the mapping. = This is due to the fact the total defined by the group limits the usage for= individual encoding. For example if =A0we have a three camera system and w= e set a value in the=A0 group for maxGroupH264Mbps and want to allow for si= mulcast (two resolutions), we will need to define six individual encodes, t= hree with high resolution ( also high maxH264Mbps) and three lower resoluti= on with lower maxH264Mbps. If the compute resource can do all six it will= =A0 reflected in the value of maxGroupH264Mbps but I assume that there is a= constrain (otherwise why have encodings) making it lower. So if the consum= er will ask for all six what will happen. Since there is more than one degr= ee of freedom he will not be able to predict if he will get all or part on = lower frame rate , if he will get only a subset of the streams, if he will = get different resolutions.


The situation you describe is, I would argue, exactly what t= he parameters are for. The consumer would be allowed to ask for all 6, each= with consumer-imposed maximum values. The provider would be bound by its o= verall maxGroupH264Mbps as well as each individual encoding's max. valu= e - in many senses this is no difference to existing systems' balancing= of bit rate across main and presentation limits. I think if the consumer a= sks for all six then what will happen should be very predictable - 6 captur= e encodings will be sent to the consumer, with each capped by the lower of = the consumer's request parameters and the provider's limitations. I= t is true that the frame rate / resolution would be bounded but not fixed, = but this is true today on a video call - if you can receive 720p30 you don&= #39;t know whether the far end will send you 720p30, 720p5, CIF30 etc. I= 9;m not sure I see how what we're talking about here does anything but = follow normal encoder and decoder behavior as seen today (equally, I confes= s that I may not be fully understanding the intricacies of the case you des= cribe).


>On the other hand if the 6 individual encodes will include l= ower values to allow for the group limit it will mean that a consumer not d= oing simulcast is limited by the fact the simulcast and ask (if possible) f= or only three streams, the individual encodes limit will be low so he will = not be able to use the full compute resources.


>Roni:

>Section 8 concludes that the number of individual encodes in a group mu= st allow for all media capture in a capture scene entry to be used simultan= eously.


Yes, this is a corollary of the constr= aint that all media captures in a capture scene entry must be able to be pr= ovided simultaneously (which itself is a corollary of the idea that each ca= pture scene entry is in itself a useful representation of the scene).

=A0

>So it look like this system does not work well= for simulcast. What about no simulcast, is it needed. For example a three = camera system that also have one presentation. My view that the cameras wil= l be one capture scene and the presentation will be a second one. The quest= ion is if they all belong to one encoding group, here my view is =93no=94 s= ince they have different priority and should not compete for compute resour= ces.


Another view is that if the provider does encode the cameras= and the presentation from the same pool of encoding resource then it is va= lid for the consumer to choose which to prioritise (i.e. the provider could= leave the consumer to allocate encodings to the media captures).


>Roni:

>So we will have two encoding groups one for presentati= on and one for the three cameras. For the three cameras each sending one st= ream I assume that the resource allocation will be a third for each so we w= ill have three individual encode with the same values, this is the basic on= e and if it is a third than no need for advertising or configuring. Now if = we also want to have an individual encode that has higher compute if the co= nsumer wants only one capture (of the whole room), the group will have four= th one with higher value. So if there is way for consumer to configure indi= vidual encode when using three media captures, he may select the higher cap= ability one with two lower ones. The total will be limited by the encoding = group value and again it is not clear how the actual streams will be encode= d to address the group limit since there are multiple options.


To my mind this is no different to the sort of trace offs / = choices that are already made in this sort of system today - in a video cal= l it is common to not be able to send a camera stream at full resolution an= d full frame rate either because of bandwidth limitations or the capabiliti= es of the receiver. In the case you cite, yes, the consumer could choose to= impose different video limits on the left center and right cameras, but it= would be within its rights to do so, just as the provider would then be wi= thin its rights to send them all at the lowest of the 3 levels.


>Roni:=A0

>To summarize I do not see value in th= e encoding as currently specified since they only provide information and n= o option for configuration. The value of it as information does not justify= specifying them and if the intention is to allow configurations of individ= ual encoding it must be reflected and the explained how it works.=


>Roni:=A0

>M= y proposal is at the moment to remove the encoding until we get some text t= hat defines how to use it for configuring encoding to media captures includ= ing for the simulcast case


I think I'd agree with you if it really= were true that simulcast was ill-defined here, but I think it's covere= d pretty well. It's clear that you've thought about it in a lot of = detail though, so I'm sure there'll be more to discuss on this...

Regards,

Andy


On Thu, Nov 1, 2012 at 4:38 PM, Pa= ul Kyzivat <pkyzivat@alum.mit.edu> wrote:
(As co-chair)

Roni is proposing a significant change here.

PLEASE carefully consider this and comment on it here on the mailing list!<= br>
*If* this works and satisfies all objectives then it will be a helpful simp= lification. But it may be that simplifying things this way excludes some re= quired behavior.

This is something that would benefit from discussion next week. But that wo= n't be helpful if people haven't already thought about it.

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


On 10/31/12 5:49 AM, Roni Even wrote:
Hi,

=A0From the email discussion it looks to me that the concept of the
encoding as specified in the framework document is not clear. I will try to describe my understanding of sections 7 and 8 of the framework
document and explain why I think that it is not important to CLUE as
specified. I am looking for response if my understanding of the encoding based on the framework is correct and how it will work for the examples
I will provide bellow

The purpose of the Encodings is to provide INFORMATION about the
provider abilities to send streams. This relates to the available
resources (compute and BW) of the providers.

The encodings are constructed from encoding groups and each encoding
group is include individual encodes.

The encoding group provide a value for the total maximum BW and compute
H264Mbps (note that it is H.264 specific) of all the individual encodes
in the group that the provider can use to send audio and video.

Each encoding group include a list of individual encodes =A0(audio and /or<= br> video). These provide maximum values that can be used to instantiate a
media stream by the provider.

Each video individual encodes identified by an encodeID provides maximum values =A0for BW, compute, resolution and frame rate for H.264. (BTW: the maxH264Mbps can be computed from the resolution and frame rate as
defined in table 2 making it redundant).

Each audio encode has only a BW value (no identifier).

A media capture is associated with an encoding group !!!!! not an
individual encoding.

The provider can use one of the individual encoding to instantiate a
media capture, each individual encoding can be used by one media
capture, the decision of which one to use according to the framework is
by the provider. The consumer does not select an individual encode.

The maximum number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group (note
that this is why the example in the current data model allows only for
one video and one audio streams).

Section 8 of the framework talk about having more than one individual
encoding assigned to a media capture (simulcast) and also claims that it can be done by the consumer but there is no way to do it since the media capture is associated only with an encoding group. There is no way for a consumer even to assign a specific individual encoding to a group.

My view is that this mechanism does not work and can be removed. The
reasons are given bellow

The encoding as currently specified is provided as information since
there is no way to map one or more individual encoding to a specific
media capture

The video is H.264 specific and not general

The relation between the individual encode and encoding group makes it
difficult to achieve a reasonable set even if the consumer will be able
to select the mapping. This is due to the fact the total defined by the
group limits the usage for individual encoding. For example if =A0we have a three camera system and we set a value in the =A0group for
maxGroupH264Mbps and want to allow for simulcast (two resolutions), we
will need to define six individual encodes, three with high resolution ( also high maxH264Mbps) and three lower resolution with lower
maxH264Mbps. If the compute resource can do all six it will =A0reflected in the value of maxGroupH264Mbps but I assume that there is a constrain
(otherwise why have encodings) making it lower. So if the consumer will
ask for all six what will happen. Since there is more than one degree of freedom he will not be able to predict if he will get all or part on
lower frame rate , if he will get only a subset of the streams, if he
will get different resolutions.

On the other hand if the 6 individual encodes will include lower values
to allow for the group limit it will mean that a consumer not doing
simulcast is limited by the fact the simulcast and ask (if possible) for only three streams, the individual encodes limit will be low so he will
not be able to use the full compute resources.

Section 8 concludes that the number of individual encodes in a group
must allow for all media capture in a capture scene entry to be used
simultaneously.

So it look like this system does not work well for simulcast. What about no simulcast, is it needed. For example a three camera system that also
have one presentation. My view that the cameras will be one capture
scene and the presentation will be a second one. The question is if they all belong to one encoding group, here my view is =93no=94 since they have<= br> different priority and should not compete for compute resources. So we
will have two encoding groups one for presentation and one for the three cameras. For the three cameras each sending one stream I assume that the resource allocation will be a third for each so we will have three
individual encode with the same values, this is the basic one and if it
is a third than no need for advertising or configuring. Now if we also
want to have an individual encode that has higher compute if the
consumer wants only one capture (of the whole room), the group will have fourth one with higher value. So if there is way for consumer to
configure individual encode when using three media captures, he may
select the higher capability one with two lower ones. The total will be
limited by the encoding group value and again it is not clear how the
actual streams will be encoded to address the group limit since there
are multiple options.

To summarize I do not see value in the encoding as currently specified
since they only provide information and no option for configuration. The value of it as information does not justify specifying them and if the
intention is to allow configurations of individual encoding it must be
reflected and the explained how it works.

My proposal is at the moment to remove the encoding until we get some
text that defines how to use it for configuring encoding to media
captures including for the simulcast case

Thanks

Roni Even



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


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

--047d7b6d981266eae004cd84ac16-- From mary.ietf.barnes@gmail.com Fri Nov 2 09: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 74A0F21F87E4 for ; Fri, 2 Nov 2012 09:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iakZQ59AyI3g for ; Fri, 2 Nov 2012 09:55:55 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7F421F86B6 for ; Fri, 2 Nov 2012 09:55:54 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2974702lam.31 for ; Fri, 02 Nov 2012 09:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hfa3SkQTgnz/W70nn7peHiqzkjZtq9SuuDyHSH5G6Qk=; b=ibCeQUqij11yaVAdHNVptyykYO+A3qcKGv3uzkNuM6pVuVn1qcZxsOps0Xyyx3m3Sp e9r+9jUZmApbOdWYvUg0S79e/vIGyuP0WiqUhIFkUMChwplyhXoJVu6hpn2SQJRIPps/ LzL5uvVY/22/7aitS0Uvyx3DQPNMMMnOVia6cuG0372tQ7yaN7MXRO0vr//uWZrZ8zb/ Iy2in/gZZbHHK4UVXLP6Gvui23iAsyOQF2v3rBzCINhWKstlsiEZy3SBEB8WV7Z+8K2q 66nxSRUDwBZCPcJb5e9E5bIpGGna2DfDeubydoH8JL/+yt2Lx0kE9d+bKp0agVwIrxvM qwCA== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr2200501lab.30.1351875353375; Fri, 02 Nov 2012 09:55:53 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Fri, 2 Nov 2012 09:55:53 -0700 (PDT) In-Reply-To: <509316C5.6060003@nteczone.com> References: <5091DEF5.6010608@nteczone.com> <509316C5.6060003@nteczone.com> Date: Fri, 2 Nov 2012 11:55:53 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=e89a8f23466537f37004cd86024f Cc: "clue@ietf.org" Subject: Re: [clue] CLUE media capture 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: Fri, 02 Nov 2012 16:55:56 -0000 --e89a8f23466537f37004cd86024f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 1, 2012 at 7:41 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Steve and Mary > > Steve, I fully agree with your points. The contribution was provided for > information as there is a Q5 document which uses much of the work of CLUE. > The contents of the contribution was the same as the draft apart from > templates issues so all the information is in draft-groves-clue-capture-** > attr. > > With respect to the comment about the scope, I don't think it was > suggested that CLUE have a work item to define things for H.323 systems. > The point was more that there are existing uses of the values related to > the Content Attribute in both SIP and H.323 systems that work in with the > control that H.239 offers. I think that interoperability with these systems > should at least be considered when making protocol/design decisions. If we > can make a choice which allows easier interworking why wouldn't we do that? > I don't see that as out of scope. > [MB] It's WBN if it works with H.323 - it is not in scope and we will not be making decisions based on that interworking. It is not in scope for CLUE nor the IETF. Certainly, you as an individual can bring contributions that you have evaluated that would work for both, but our decisions within this WG will be based upon what works best for the CLUE protocol being defined in IETF which is based on using SIP signaling. [/MB] > > Regards, Christian > > > On 2/11/2012 3:11 AM, Stephen Botzko wrote: > >> I have a couple of clarifications in-line. >> >> Steve B. >> >> >> On Thu, Nov 1, 2012 at 10:35 AM, Mary Barnes > mary.ietf.barnes@**gmail.com >> wrote: >> >> I'll let other WG members respond to the details of this proposal. >> It would be helpful if you could forward the document submitted >> to Q5 unless it really is as brief as you suggest. I also have >> one important comment below. [MB] >> >> Mary. >> CLUE WG co-chair >> >> On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves >> > >> >> wrote: >> >> >> CLUE media capture description >> draft-groves-clue-capture-**attr-00 >> >> I won't be attending the IETF next week so as a pre-cursor to >> next weeks CLUE WG meeting I thought i'd put a few words >> together about draft-groves-clue-capture-**attr-0 >> http://datatracker.ietf.org/**doc/draft-groves-clue-capture-** >> attr/ >> >> The main idea behind the draft is that a CLUE advertisement >> should include enough information for the receiver to make an >> educated decision about what captures it chooses. Having a had >> a close look at the content attribute I think (for the reasons >> outlined in the draft) it is insufficient to fully describe >> the multi-stream conferencing environments that CLUE is >> addressing/enabling. >> >> A contribution with essentially the same text as the draft was >> submitted to the recent Q.5/16 meeting to solicit feedback >> from the people at the meeting about the different parameters >> presented in the draft. In general I think people were in >> agreement that the current Content attribute was not >> sufficient. However it was noted that it needs to be >> considered how CLUE maps to the existing usages of the content >> attribute and mapping to H.239. >> >> [MB] While Q.5 might need to do this, it is absolutely out of >> scope for the CLUE WG. It is not in our charter and the >> requirements clearly state such: >> "Non IETF protocol based systems, such as >> those based on ITU-T Rec. H.323, are out of scope." >> [/MB] >> >> [SB] >> I'd like to make three clarifications on this: >> >> -Q5/16 itself is not endorsing Christian's contribution and is not >> requesting any action on it from either CLUE or the IETF. Q5/16 of course >> would use the normal liaison mechanisms for that kind of communication. >> Christian's draft is an individual draft like any other. >> >> -Q5/16 is following the CLUE work closely, because there is strong >> support there for using a consistent approach for multiple streams. >> Generally it has focused most of its attention on aspects of telepresence >> systems that are out-of-scope for CLUE, but which are still needed to get >> good interoperability. For instance, specifications for audio levels, >> video color space, etc. >> >> -Q5/16 was not considering H.323 specifically when it provided feedback >> on Christian's contribution. >> >> Personally I think the draft makes some good points that we should >> consider. >> [/SB] >> >> >> Below is a list of attributes and comments. If I've left out >> anything or mispoken hopefully Steve Botzko can correct me. >> >> Presentation >> ------------ >> People thought it was worthwhile to know if a capture related >> to a presentation. There was some questioning if it was >> worthwhile to know if the capture was slides, images etc. It >> was thought it may help where multiple presentation streams >> were used. >> >> View >> ---- >> It was clarified that the aim of the attribute is to allow a >> remote end to make an automatic decision on what region of the >> scene it wants to see. The idea is that there is a standard >> keyword that the remote end could scan for e.g. lectern. This >> is a way of providing meaning to a particular spatial area. >> >> Language >> -------- >> There seemed to be general support for a language parameter. >> >> Role >> ---- >> It was thought that role could be related to "participants" or >> "material". Currently the attribute only discusses role from >> the aspect of a participant. It was also noted that the role >> may change based on meeting type. For example: in the medical >> use case there could be "Surgeon", "Professor", in an >> accessible conference there could be an "Interpreter" or >> "signer". With respect to Materials it was thought >> presentation could show something like "Agenda", "Contribution". >> >> Priority >> -------- >> There was some discussion as to whether this was needed. It >> was thought that if captures were properly described then >> priority wouldn't be needed as the remote end could make an >> educated decision about what it wants. At the moment with the >> minimal set of attributes it was thought that priority at >> least helped the remote end make a decision. >> >> Dynamic >> ------- >> I think people were OK with this being optional. >> >> >> Embedded Text >> ------------- >> Again I think people thought it was reasonable. It was >> clarified this could also be used to indicate captioning was >> being used with the capture. >> >> >> Supplementary description >> ------------------------- >> There was some question about how this related to side bar >> conferences. It was clarified this was mainly about the case >> where information (captures) were provided by people (or >> devices) who were not captured by the conference video. >> >> Telepresence >> ------------ >> This parameter probably had the least support/understanding. I >> was noted that CLUE was to allow multi-stream operation it >> didn't necessarily indicate/mandate a telepresence experience. >> >> Hopefully this provides some further background for the CLUE >> discussions. If the group could come to some general agreement >> about each of the parameters then I could work on some >> specific text for the framework (or whatever document we decide). >> >> 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 >> >> >> > --e89a8f23466537f37004cd86024f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Nov 1, 2012 at 7:41 PM, Christia= n Groves <Christian.Groves@nteczone.com> wrote:<= br>
Hello Steve and Mary

Steve, I fully agree with your points. The contribution was provided for in= formation as there is a Q5 document which uses much of the work of CLUE. Th= e contents of the contribution was the same as the draft apart from templat= es issues so all the information is in draft-groves-clue-capture-att= r.

With respect to the comment about the scope, I don't think it was sugge= sted that CLUE have a work item to define things for H.323 systems. The poi= nt was more that there are existing uses of the values related to the Conte= nt Attribute in both SIP and H.323 systems that work in with the control th= at H.239 offers. I think that interoperability with these systems should at= least be considered when making protocol/design decisions. If we can make = a choice which allows easier interworking why wouldn't we do that? I do= n't see that as out of scope.
=A0[MB] It's WBN if it works with H.323 - it is not i= n scope and we will not be making decisions based on that interworking. =A0= It is not in scope for CLUE nor the IETF. =A0Certainly, you as an individua= l can bring contributions that you have evaluated that would work for both,= but our decisions within this WG will be based upon what works best for th= e CLUE protocol being defined in IETF which is based on using SIP signaling= . [/MB]

Regards, Christian


On 2/11/2012 3:11 AM, Stephen Botzko wrote:
I have a couple of clarifications in-line.

Steve B.


On Thu, Nov 1, 2012 at 10:35 AM, Mary Barnes <mary.ietf.barnes@gmail.com <ma= ilto:mary.i= etf.barnes@gmail.com>> wrote:

=A0 =A0 I'll let other WG members respond to the details of this propos= al.
=A0 =A0 =A0It would be helpful if you could forward the document submitted<= br> =A0 =A0 to Q5 unless it really is as brief as you suggest. =A0I also have =A0 =A0 one important comment below. [MB]

=A0 =A0 Mary.
=A0 =A0 CLUE WG co-chair

=A0 =A0 On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves
=A0 =A0 <Christian.Groves@nteczone.com
=A0 =A0 <mailto:Christian.Groves@nteczone.com>> wrote:


=A0 =A0 =A0 =A0 CLUE media capture description
=A0 =A0 =A0 =A0 draft-groves-clue-capture-attr-00

=A0 =A0 =A0 =A0 I won't be attending the IETF next week so as a pre-cur= sor to
=A0 =A0 =A0 =A0 next weeks CLUE WG meeting =A0I thought i'd put a few w= ords
=A0 =A0 =A0 =A0 together about draft-groves-clue-capture-attr-0
=A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc/d= raft-groves-clue-capture-attr/

=A0 =A0 =A0 =A0 The main idea behind the draft is that a CLUE advertisement=
=A0 =A0 =A0 =A0 should include enough information for the receiver to make = an
=A0 =A0 =A0 =A0 educated decision about what captures it chooses. Having a = had
=A0 =A0 =A0 =A0 a close look at the content attribute I think (for the reas= ons
=A0 =A0 =A0 =A0 outlined in the draft) it is insufficient to fully describe=
=A0 =A0 =A0 =A0 the multi-stream conferencing environments that CLUE is
=A0 =A0 =A0 =A0 addressing/enabling.

=A0 =A0 =A0 =A0 A contribution with essentially the same text as the draft = was
=A0 =A0 =A0 =A0 submitted to the recent Q.5/16 meeting to solicit feedback<= br> =A0 =A0 =A0 =A0 from the people at the meeting about the different paramete= rs
=A0 =A0 =A0 =A0 presented in the draft. In general I think people were in =A0 =A0 =A0 =A0 agreement that the current Content attribute was not
=A0 =A0 =A0 =A0 sufficient. However it was noted that it needs to be
=A0 =A0 =A0 =A0 considered how CLUE maps to the existing usages of the cont= ent
=A0 =A0 =A0 =A0 attribute and mapping to H.239.

=A0 =A0 [MB] While Q.5 might need to do this, it is absolutely out of
=A0 =A0 scope for the CLUE WG. It is not in our charter and the
=A0 =A0 requirements clearly state such:
=A0 =A0 =A0 =A0"Non IETF protocol based systems, such as
=A0 =A0 =A0 =A0those based on ITU-T Rec. H.323, are out of scope."
=A0 =A0 [/MB]

[SB]
I'd like to make three clarifications on this:

-Q5/16 itself is not endorsing Christian's contribution and is not requ= esting any action on it from either CLUE or the IETF. Q5/16 of course would= use the normal liaison mechanisms for that kind of communication. =A0Chris= tian's draft is an individual draft like any other.

-Q5/16 is following the CLUE work closely, because there is strong support = there for using a consistent approach for multiple streams. =A0Generally it= has focused most of its attention on aspects of telepresence systems that = are out-of-scope for CLUE, but which are still needed to get good interoper= ability. =A0For instance, specifications for audio levels, video color spac= e, etc.

-Q5/16 was not considering H.323 specifically when it provided feedback on = Christian's contribution.

Personally I think the draft makes some good points that we should consider= .
[/SB]


=A0 =A0 =A0 =A0 Below is a list of attributes and comments. If I've lef= t out
=A0 =A0 =A0 =A0 anything or mispoken hopefully Steve Botzko can correct me.=

=A0 =A0 =A0 =A0 Presentation
=A0 =A0 =A0 =A0 ------------
=A0 =A0 =A0 =A0 People thought it was worthwhile to know if a capture relat= ed
=A0 =A0 =A0 =A0 to a presentation. There was some questioning if it was
=A0 =A0 =A0 =A0 worthwhile to know if the capture was slides, images etc. I= t
=A0 =A0 =A0 =A0 was thought it may help where multiple presentation streams=
=A0 =A0 =A0 =A0 were used.

=A0 =A0 =A0 =A0 View
=A0 =A0 =A0 =A0 ----
=A0 =A0 =A0 =A0 It was clarified that the aim of the attribute is to allow = a
=A0 =A0 =A0 =A0 remote end to make an automatic decision on what region of = the
=A0 =A0 =A0 =A0 scene it wants to see. The idea is that there is a standard=
=A0 =A0 =A0 =A0 keyword that the remote end could scan for e.g. lectern. Th= is
=A0 =A0 =A0 =A0 is a way of providing meaning to a particular spatial area.=

=A0 =A0 =A0 =A0 Language
=A0 =A0 =A0 =A0 --------
=A0 =A0 =A0 =A0 There seemed to be general support for a language parameter= .

=A0 =A0 =A0 =A0 Role
=A0 =A0 =A0 =A0 ----
=A0 =A0 =A0 =A0 It was thought that role could be related to "particip= ants" or
=A0 =A0 =A0 =A0 "material". Currently the attribute only discusse= s role from
=A0 =A0 =A0 =A0 the aspect of a participant. It was also noted that the rol= e
=A0 =A0 =A0 =A0 may change based on meeting type. For example: in the medic= al
=A0 =A0 =A0 =A0 use case there could be "Surgeon", "Professo= r", in an
=A0 =A0 =A0 =A0 accessible conference there could be an "Interpreter&q= uot; or
=A0 =A0 =A0 =A0 "signer". With respect to Materials it was though= t
=A0 =A0 =A0 =A0 presentation could show something like "Agenda", = "Contribution".

=A0 =A0 =A0 =A0 Priority
=A0 =A0 =A0 =A0 --------
=A0 =A0 =A0 =A0 There was some discussion as to whether this was needed. It=
=A0 =A0 =A0 =A0 was thought that if captures were properly described then =A0 =A0 =A0 =A0 priority wouldn't be needed as the remote end could mak= e an
=A0 =A0 =A0 =A0 educated decision about what it wants. At the moment with t= he
=A0 =A0 =A0 =A0 minimal set of attributes it was thought that priority at =A0 =A0 =A0 =A0 least helped the remote end make a decision.

=A0 =A0 =A0 =A0 Dynamic
=A0 =A0 =A0 =A0 -------
=A0 =A0 =A0 =A0 I think people were OK with this being optional.


=A0 =A0 =A0 =A0 Embedded Text
=A0 =A0 =A0 =A0 -------------
=A0 =A0 =A0 =A0 Again I think people thought it was reasonable. It was
=A0 =A0 =A0 =A0 clarified this could also be used to indicate captioning wa= s
=A0 =A0 =A0 =A0 being used with the capture.


=A0 =A0 =A0 =A0 Supplementary description
=A0 =A0 =A0 =A0 -------------------------
=A0 =A0 =A0 =A0 There was some question about how this related to side bar<= br> =A0 =A0 =A0 =A0 conferences. It was clarified this was mainly about the cas= e
=A0 =A0 =A0 =A0 where information (captures) were provided by people (or =A0 =A0 =A0 =A0 devices) who were not captured by the conference video.

=A0 =A0 =A0 =A0 Telepresence
=A0 =A0 =A0 =A0 ------------
=A0 =A0 =A0 =A0 This parameter probably had the least support/understanding= . I
=A0 =A0 =A0 =A0 was noted that CLUE was to allow multi-stream operation it<= br> =A0 =A0 =A0 =A0 didn't necessarily indicate/mandate a telepresence expe= rience.

=A0 =A0 =A0 =A0 Hopefully this provides some further background for the CLU= E
=A0 =A0 =A0 =A0 discussions. If the group could come to some general agreem= ent
=A0 =A0 =A0 =A0 about each of the parameters then I could work on some
=A0 =A0 =A0 =A0 specific text for the framework (or whatever document we de= cide).

=A0 =A0 =A0 =A0 Regards, Christian
=A0 =A0 =A0 =A0 _______________________________________________
=A0 =A0 =A0 =A0 clue mailing list
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org>

=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/clue



=A0 =A0 _______________________________________________
=A0 =A0 clue mailing list
=A0 =A0 clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/listinfo/clue




--e89a8f23466537f37004cd86024f-- From Christian.Groves@nteczone.com Sun Nov 4 18:08: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 65D6521F8876 for ; Sun, 4 Nov 2012 18:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Wz-JwCpA2-cz for ; Sun, 4 Nov 2012 18:08:03 -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 410BA21F86C6 for ; Sun, 4 Nov 2012 18:07:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAPoel1B20SQh/2dsb2JhbAANLQrGXwEBAQQBAQE1GxUGCgEQCxgJFggHCQMCAQIBDwYfEQYNAQUCAQGHdAMapiCIbw2JVIsZaBCGLAOUJoJxiheIFA Received: from ppp118-209-36-33.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.36.33]) by ipmail04.adl6.internode.on.net with ESMTP; 05 Nov 2012 12:37:46 +1030 Message-ID: <50971F70.3090304@nteczone.com> Date: Mon, 05 Nov 2012 13:07:44 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mary Barnes References: <5091DEF5.6010608@nteczone.com> <509316C5.6060003@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] CLUE media capture 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: Mon, 05 Nov 2012 02:08:05 -0000 Hello Mary, I don't see why considering interoperability with H.323 (or other open standards) is absolutely out of scope? I understand the requirements document mentions that H.323 is in out of scope of the document however, from the approved CLUE charter (Charter charter-ietf-clue-01): "The working group may identify interoperability obstacles in existing open standards. If so, the WG will develop requirements to be communicated to other IETF WGs or Standards Forums, or recharter as appropriate." All I was trying to do was point out that there may be some issues around the use of Content. Regards, Christian On 3/11/2012 3:55 AM, Mary Barnes wrote: > > > On Thu, Nov 1, 2012 at 7:41 PM, Christian Groves > > > wrote: > > Hello Steve and Mary > > Steve, I fully agree with your points. The contribution was > provided for information as there is a Q5 document which uses much > of the work of CLUE. The contents of the contribution was the same > as the draft apart from templates issues so all the information is > in draft-groves-clue-capture-attr. > > With respect to the comment about the scope, I don't think it was > suggested that CLUE have a work item to define things for H.323 > systems. The point was more that there are existing uses of the > values related to the Content Attribute in both SIP and H.323 > systems that work in with the control that H.239 offers. I think > that interoperability with these systems should at least be > considered when making protocol/design decisions. If we can make a > choice which allows easier interworking why wouldn't we do that? I > don't see that as out of scope. > > [MB] It's WBN if it works with H.323 - it is not in scope and we will > not be making decisions based on that interworking. It is not in > scope for CLUE nor the IETF. Certainly, you as an individual can > bring contributions that you have evaluated that would work for both, > but our decisions within this WG will be based upon what works best > for the CLUE protocol being defined in IETF which is based on using > SIP signaling. [/MB] > > > Regards, Christian > > > On 2/11/2012 3:11 AM, Stephen Botzko wrote: > > I have a couple of clarifications in-line. > > Steve B. > > > On Thu, Nov 1, 2012 at 10:35 AM, Mary Barnes > > >> wrote: > > I'll let other WG members respond to the details of this > proposal. > It would be helpful if you could forward the document > submitted > to Q5 unless it really is as brief as you suggest. I also > have > one important comment below. [MB] > > Mary. > CLUE WG co-chair > > On Wed, Oct 31, 2012 at 9:31 PM, Christian Groves > > >> wrote: > > > CLUE media capture description > draft-groves-clue-capture-attr-00 > > I won't be attending the IETF next week so as a > pre-cursor to > next weeks CLUE WG meeting I thought i'd put a few words > together about draft-groves-clue-capture-attr-0 > http://datatracker.ietf.org/doc/draft-groves-clue-capture-attr/ > > The main idea behind the draft is that a CLUE > advertisement > should include enough information for the receiver to > make an > educated decision about what captures it chooses. > Having a had > a close look at the content attribute I think (for the > reasons > outlined in the draft) it is insufficient to fully > describe > the multi-stream conferencing environments that CLUE is > addressing/enabling. > > A contribution with essentially the same text as the > draft was > submitted to the recent Q.5/16 meeting to solicit feedback > from the people at the meeting about the different > parameters > presented in the draft. In general I think people were in > agreement that the current Content attribute was not > sufficient. However it was noted that it needs to be > considered how CLUE maps to the existing usages of the > content > attribute and mapping to H.239. > > [MB] While Q.5 might need to do this, it is absolutely out of > scope for the CLUE WG. It is not in our charter and the > requirements clearly state such: > "Non IETF protocol based systems, such as > those based on ITU-T Rec. H.323, are out of scope." > [/MB] > > [SB] > I'd like to make three clarifications on this: > > -Q5/16 itself is not endorsing Christian's contribution and is > not requesting any action on it from either CLUE or the IETF. > Q5/16 of course would use the normal liaison mechanisms for > that kind of communication. Christian's draft is an > individual draft like any other. > > -Q5/16 is following the CLUE work closely, because there is > strong support there for using a consistent approach for > multiple streams. Generally it has focused most of its > attention on aspects of telepresence systems that are > out-of-scope for CLUE, but which are still needed to get good > interoperability. For instance, specifications for audio > levels, video color space, etc. > > -Q5/16 was not considering H.323 specifically when it provided > feedback on Christian's contribution. > > Personally I think the draft makes some good points that we > should consider. > [/SB] > > > Below is a list of attributes and comments. If I've > left out > anything or mispoken hopefully Steve Botzko can > correct me. > > Presentation > ------------ > People thought it was worthwhile to know if a capture > related > to a presentation. There was some questioning if it was > worthwhile to know if the capture was slides, images > etc. It > was thought it may help where multiple presentation > streams > were used. > > View > ---- > It was clarified that the aim of the attribute is to > allow a > remote end to make an automatic decision on what > region of the > scene it wants to see. The idea is that there is a > standard > keyword that the remote end could scan for e.g. > lectern. This > is a way of providing meaning to a particular spatial > area. > > Language > -------- > There seemed to be general support for a language > parameter. > > Role > ---- > It was thought that role could be related to > "participants" or > "material". Currently the attribute only discusses > role from > the aspect of a participant. It was also noted that > the role > may change based on meeting type. For example: in the > medical > use case there could be "Surgeon", "Professor", in an > accessible conference there could be an "Interpreter" or > "signer". With respect to Materials it was thought > presentation could show something like "Agenda", > "Contribution". > > Priority > -------- > There was some discussion as to whether this was > needed. It > was thought that if captures were properly described then > priority wouldn't be needed as the remote end could > make an > educated decision about what it wants. At the moment > with the > minimal set of attributes it was thought that priority at > least helped the remote end make a decision. > > Dynamic > ------- > I think people were OK with this being optional. > > > Embedded Text > ------------- > Again I think people thought it was reasonable. It was > clarified this could also be used to indicate > captioning was > being used with the capture. > > > Supplementary description > ------------------------- > There was some question about how this related to side bar > conferences. It was clarified this was mainly about > the case > where information (captures) were provided by people (or > devices) who were not captured by the conference video. > > Telepresence > ------------ > This parameter probably had the least > support/understanding. I > was noted that CLUE was to allow multi-stream operation it > didn't necessarily indicate/mandate a telepresence > experience. > > Hopefully this provides some further background for > the CLUE > discussions. If the group could come to some general > agreement > about each of the parameters then I could work on some > specific text for the framework (or whatever document > we decide). > > 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 ron.even.tlv@gmail.com Mon Nov 5 05:58:32 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8138A21F8491 for ; Mon, 5 Nov 2012 05:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, 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 bt0A4HG8YRtM for ; Mon, 5 Nov 2012 05:58:22 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id D36D421F84C5 for ; Mon, 5 Nov 2012 05:58:21 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so3944769pad.31 for ; Mon, 05 Nov 2012 05:58:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=/x6Rd9JBRb+Tp0S+9b9xefq9MUlBDu/aWJvtuBM/4uk=; b=bULn2c8zNAyhIQS1vubxcJ39YRGdY5Y7jD33EfYM9lgrJymEmHTXIm3NCYBQK/vUnQ mRAxk+JjchI393hVJNSgw5/RCrLFPKxvD3yZuoGLtut2vK23sZofRyrwVZuts69c9i0r uGwWhdNmpWQtpP4aS2J29Q9A+RxI95UCJo0dBnVMUF9Q4HewjLzdcQEHjdTVUpoLfv1g 36g36QTBAGF42MfzEbnvDawQnoPh/n/AqGRImMTJEL54tQZK7j2gSLpeX8rxxRTv6RIv bJnKh5kPsntRN4TXb8BKKIGWUIiudeLnJ8Pwbk1sC7S6ErlveCU/A0w0NM/SFKfh0X7y JJCw== Received: by 10.68.227.197 with SMTP id sc5mr22493598pbc.157.1352123901563; Mon, 05 Nov 2012 05:58:21 -0800 (PST) Received: from RoniE ([2001:df8:0:16:19f7:967a:abb6:4267]) by mx.google.com with ESMTPS id pq9sm9737016pbc.1.2012.11.05.05.58.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Nov 2012 05:58:20 -0800 (PST) From: "Roni Even" To: "'Andy Pepperell'" , "'Paul Kyzivat'" References: <01d301cdb74d$10857940$31906bc0$@gmail.com> <5092A599.4010601@alum.mit.edu> In-Reply-To: Date: Mon, 5 Nov 2012 08:55:45 -0500 Message-ID: <019401cdbb5d$42c71b70$c8555250$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0195_01CDBB33.59F5A750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGd50DMAF+DH9t0mI1O0aq46xBPTAGcYWeqAtPA0D2YF2lJYA== Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Do we need the encodings as secified in the framework document - proposal to remove them from the framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2012 13:58:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0195_01CDBB33.59F5A750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy, Can you explain how the encoding works with the dynamic mapping of RTP to Media Captures. Does this mean that the consumer will get advertisements from all the participants of the multipoint call and will need to calculate the limitations in each switch and ask for a new configuration since the group limits may enforce different limitations. In the static mapping case all this can be achieved using imageattr and the codec parameters Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy Pepperell Sent: 02 November, 2012 11:20 AM To: Paul Kyzivat Cc: clue@ietf.org Subject: Re: [clue] Do we need the encodings as secified in the framework document - proposal to remove them from the framework >Paul: >*If* this works and satisfies all objectives then it will be a helpful simplification. But it may be that simplifying things this way excludes some required behavior. I certainly agree with Paul's point here... however, with not all that many of Roni's (as might be expected :) ) - to be specific: >Roni: >Each encoding group include a list of individual encodes (audio and /or video). These provide maximum values that can be used to instantiate a media stream by the provider. Yes, I think that's a good summary. >Each video individual encodes identified by an encodeID provides maximum values for BW, compute, resolution and frame rate for H.264. (BTW: the maxH264Mbps can be computed from the resolution and frame rate as defined in table 2 making it redundant). >Each audio encode has only a BW value (no identifier). Also agreed - apart from the H.264 point I think - a maximum resolution and a maximum frame rate doesn't necessarily imply a maxMbps - many systems can encode 1280x720 at some frame rate < 30 *or* some lower resolution at up to 30fps without necessarily being able to send 720p30, surely? > Roni: >A media capture is associated with an encoding group !!!!! not an individual encoding. That's true, and by design. To re-iterate the original design intent here, the idea behind the encoding groups idea was to be able to model 2 common Telepresence architectures we see today: 1) a multi-screen endpoint room comprised of multiple endpoints (most vendors' "3 screen" systems, for instance, tend to be composed of 3 of their "1 screen" products linked together) 2) a flexible media generation system such as a software or hardware MCU For the "1)" case above, due to real-world constraints such as camera wiring etc., it seemed to us that a media capture representing, say, the left camera of 3, would only be able to be encoded by the hardware it was directly connected to - thus, such a system would use one "encoding group" for its left constituent, one for its centre and one for its right. >Roni: >The provider can use one of the individual encoding to instantiate a media capture, each individual encoding can be used by one media capture, the decision of which one to use according to the framework is by the provider. The consumer does not select an individual encode. That was not the intent - it should be the consumer that chooses media capture / individual encoding pairs to instantiate "capture encodings". When forming its configure message, the consumer essentially supplies a set of media capture ID + encoding ID pairs to instruct the provider on which capture encodings to send. Having just re-read it, I think that the description as per Section 9 of the current framework document described this well (though Mark deserves the credit for that, obviously!). >Roni: >The maximum number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group (note that this is why the example in the current data model allows only for one video and one audio streams). It is true that the number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group - however, a fully flexible system might choose to have a single encoding group and so no real restriction need be introduced by this (unless the provider system has such restrictions - in which case they can be modelled in this way). >Roni: >Section 8 of the framework talk about having more than one individual encoding assigned to a media capture (simulcast) and also claims that it can be done by the consumer but there is no way to do it since the media capture is associated only with an encoding group. There is no way for a consumer even to assign a specific individual encoding to a group. You're right that there's no way for the consumer to assign a specific individual encoding to a group, but it's not clear what the need is - if a provider system is sufficiently flexible that any encoding can be used by any media capture, then it should construct its advertisement to use just a single encoding group to comprise all encodings, at which point the consumer has greater flexibility in which it can choose to be sent to it. >Roni: >The video is H.264 specific and not general The problem we had was that we needed to come up with a way of describing a big block of video encoding capability and how it could be subdivided. e.g. you might be able to send 2 x 720p30 but not a single 720p60. The best scheme we could come up with was to, for each of H.264, H.265 etc. include some specific parameters that would allow both a provider's overall capability to be signalled and how it might be subdivided across multiple encodings. It's true that currently the parameters only really work for H.264 and, moreover, only really work for a provider sending all encodings within a group using the same codec, but the expectation was that new codecs would have their own equivalent parameters added here in a similar way. >Roni: >The relation between the individual encode and encoding group makes it difficult to achieve a reasonable set even if the consumer will be able to select the mapping. This is due to the fact the total defined by the group limits the usage for individual encoding. For example if we have a three camera system and we set a value in the group for maxGroupH264Mbps and want to allow for simulcast (two resolutions), we will need to define six individual encodes, three with high resolution ( also high maxH264Mbps) and three lower resolution with lower maxH264Mbps. If the compute resource can do all six it will reflected in the value of maxGroupH264Mbps but I assume that there is a constrain (otherwise why have encodings) making it lower. So if the consumer will ask for all six what will happen. Since there is more than one degree of freedom he will not be able to predict if he will get all or part on lower frame rate , if he will get only a subset of the streams, if he will get different resolutions. The situation you describe is, I would argue, exactly what the parameters are for. The consumer would be allowed to ask for all 6, each with consumer-imposed maximum values. The provider would be bound by its overall maxGroupH264Mbps as well as each individual encoding's max. value - in many senses this is no difference to existing systems' balancing of bit rate across main and presentation limits. I think if the consumer asks for all six then what will happen should be very predictable - 6 capture encodings will be sent to the consumer, with each capped by the lower of the consumer's request parameters and the provider's limitations. It is true that the frame rate / resolution would be bounded but not fixed, but this is true today on a video call - if you can receive 720p30 you don't know whether the far end will send you 720p30, 720p5, CIF30 etc. I'm not sure I see how what we're talking about here does anything but follow normal encoder and decoder behavior as seen today (equally, I confess that I may not be fully understanding the intricacies of the case you describe). >On the other hand if the 6 individual encodes will include lower values to allow for the group limit it will mean that a consumer not doing simulcast is limited by the fact the simulcast and ask (if possible) for only three streams, the individual encodes limit will be low so he will not be able to use the full compute resources. >Roni: >Section 8 concludes that the number of individual encodes in a group must allow for all media capture in a capture scene entry to be used simultaneously. Yes, this is a corollary of the constraint that all media captures in a capture scene entry must be able to be provided simultaneously (which itself is a corollary of the idea that each capture scene entry is in itself a useful representation of the scene). >So it look like this system does not work well for simulcast. What about no simulcast, is it needed. For example a three camera system that also have one presentation. My view that the cameras will be one capture scene and the presentation will be a second one. The question is if they all belong to one encoding group, here my view is "no" since they have different priority and should not compete for compute resources. Another view is that if the provider does encode the cameras and the presentation from the same pool of encoding resource then it is valid for the consumer to choose which to prioritise (i.e. the provider could leave the consumer to allocate encodings to the media captures). >Roni: >So we will have two encoding groups one for presentation and one for the three cameras. For the three cameras each sending one stream I assume that the resource allocation will be a third for each so we will have three individual encode with the same values, this is the basic one and if it is a third than no need for advertising or configuring. Now if we also want to have an individual encode that has higher compute if the consumer wants only one capture (of the whole room), the group will have fourth one with higher value. So if there is way for consumer to configure individual encode when using three media captures, he may select the higher capability one with two lower ones. The total will be limited by the encoding group value and again it is not clear how the actual streams will be encoded to address the group limit since there are multiple options. To my mind this is no different to the sort of trace offs / choices that are already made in this sort of system today - in a video call it is common to not be able to send a camera stream at full resolution and full frame rate either because of bandwidth limitations or the capabilities of the receiver. In the case you cite, yes, the consumer could choose to impose different video limits on the left center and right cameras, but it would be within its rights to do so, just as the provider would then be within its rights to send them all at the lowest of the 3 levels. >Roni: >To summarize I do not see value in the encoding as currently specified since they only provide information and no option for configuration. The value of it as information does not justify specifying them and if the intention is to allow configurations of individual encoding it must be reflected and the explained how it works. >Roni: >My proposal is at the moment to remove the encoding until we get some text that defines how to use it for configuring encoding to media captures including for the simulcast case I think I'd agree with you if it really were true that simulcast was ill-defined here, but I think it's covered pretty well. It's clear that you've thought about it in a lot of detail though, so I'm sure there'll be more to discuss on this... Regards, Andy On Thu, Nov 1, 2012 at 4:38 PM, Paul Kyzivat wrote: (As co-chair) Roni is proposing a significant change here. PLEASE carefully consider this and comment on it here on the mailing list! *If* this works and satisfies all objectives then it will be a helpful simplification. But it may be that simplifying things this way excludes some required behavior. This is something that would benefit from discussion next week. But that won't be helpful if people haven't already thought about it. Thanks, Paul On 10/31/12 5:49 AM, Roni Even wrote: Hi, From the email discussion it looks to me that the concept of the encoding as specified in the framework document is not clear. I will try to describe my understanding of sections 7 and 8 of the framework document and explain why I think that it is not important to CLUE as specified. I am looking for response if my understanding of the encoding based on the framework is correct and how it will work for the examples I will provide bellow The purpose of the Encodings is to provide INFORMATION about the provider abilities to send streams. This relates to the available resources (compute and BW) of the providers. The encodings are constructed from encoding groups and each encoding group is include individual encodes. The encoding group provide a value for the total maximum BW and compute H264Mbps (note that it is H.264 specific) of all the individual encodes in the group that the provider can use to send audio and video. Each encoding group include a list of individual encodes (audio and /or video). These provide maximum values that can be used to instantiate a media stream by the provider. Each video individual encodes identified by an encodeID provides maximum values for BW, compute, resolution and frame rate for H.264. (BTW: the maxH264Mbps can be computed from the resolution and frame rate as defined in table 2 making it redundant). Each audio encode has only a BW value (no identifier). A media capture is associated with an encoding group !!!!! not an individual encoding. The provider can use one of the individual encoding to instantiate a media capture, each individual encoding can be used by one media capture, the decision of which one to use according to the framework is by the provider. The consumer does not select an individual encode. The maximum number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group (note that this is why the example in the current data model allows only for one video and one audio streams). Section 8 of the framework talk about having more than one individual encoding assigned to a media capture (simulcast) and also claims that it can be done by the consumer but there is no way to do it since the media capture is associated only with an encoding group. There is no way for a consumer even to assign a specific individual encoding to a group. My view is that this mechanism does not work and can be removed. The reasons are given bellow The encoding as currently specified is provided as information since there is no way to map one or more individual encoding to a specific media capture The video is H.264 specific and not general The relation between the individual encode and encoding group makes it difficult to achieve a reasonable set even if the consumer will be able to select the mapping. This is due to the fact the total defined by the group limits the usage for individual encoding. For example if we have a three camera system and we set a value in the group for maxGroupH264Mbps and want to allow for simulcast (two resolutions), we will need to define six individual encodes, three with high resolution ( also high maxH264Mbps) and three lower resolution with lower maxH264Mbps. If the compute resource can do all six it will reflected in the value of maxGroupH264Mbps but I assume that there is a constrain (otherwise why have encodings) making it lower. So if the consumer will ask for all six what will happen. Since there is more than one degree of freedom he will not be able to predict if he will get all or part on lower frame rate , if he will get only a subset of the streams, if he will get different resolutions. On the other hand if the 6 individual encodes will include lower values to allow for the group limit it will mean that a consumer not doing simulcast is limited by the fact the simulcast and ask (if possible) for only three streams, the individual encodes limit will be low so he will not be able to use the full compute resources. Section 8 concludes that the number of individual encodes in a group must allow for all media capture in a capture scene entry to be used simultaneously. So it look like this system does not work well for simulcast. What about no simulcast, is it needed. For example a three camera system that also have one presentation. My view that the cameras will be one capture scene and the presentation will be a second one. The question is if they all belong to one encoding group, here my view is "no" since they have different priority and should not compete for compute resources. So we will have two encoding groups one for presentation and one for the three cameras. For the three cameras each sending one stream I assume that the resource allocation will be a third for each so we will have three individual encode with the same values, this is the basic one and if it is a third than no need for advertising or configuring. Now if we also want to have an individual encode that has higher compute if the consumer wants only one capture (of the whole room), the group will have fourth one with higher value. So if there is way for consumer to configure individual encode when using three media captures, he may select the higher capability one with two lower ones. The total will be limited by the encoding group value and again it is not clear how the actual streams will be encoded to address the group limit since there are multiple options. To summarize I do not see value in the encoding as currently specified since they only provide information and no option for configuration. The value of it as information does not justify specifying them and if the intention is to allow configurations of individual encoding it must be reflected and the explained how it works. My proposal is at the moment to remove the encoding until we get some text that defines how to use it for configuring encoding to media captures including for the simulcast case Thanks Roni Even _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_0195_01CDBB33.59F5A750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy,

Can you explain how the encoding works with the dynamic mapping of = RTP to Media Captures.

Does this mean that the consumer will get advertisements from all the = participants of the multipoint call and will need to calculate the = limitations in each switch and ask for a new configuration since the = group limits may enforce different limitations.

 

In the static mapping case all this can be achieved using imageattr = and the codec parameters

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Andy Pepperell
Sent: 02 November, 2012 11:20 = AM
To: Paul Kyzivat
Cc: = clue@ietf.org
Subject: Re: [clue] Do we need the encodings as = secified in the framework document - proposal to remove them from the = framework

 

>Paul:

>*If* this works and satisfies all objectives then it will be a = helpful simplification. But it may be that simplifying things this way = excludes some required behavior.

 

I certainly agree with Paul's point here... however, with not all that = many of Roni's (as might be expected :) ) - to be = specific:

 

>Roni:

>Each encoding group include a = list of individual encodes  (audio and /or video). These provide = maximum values that can be used to instantiate a media stream by the = provider.

 

Yes, I think that's a good = summary.

 

>Each video individual encodes = identified by an encodeID provides maximum values  for BW, compute, = resolution and frame rate for H.264. (BTW: the maxH264Mbps can be = computed from the resolution and frame rate as defined in table 2 making = it redundant).

>Each audio encode has only a BW = value (no identifier).

 

Also agreed - apart from the H.264 = point I think - a maximum resolution and a maximum frame rate doesn't = necessarily imply a maxMbps - many systems can encode 1280x720 at some = frame rate < 30 *or* some lower resolution at up to 30fps without = necessarily being able to send 720p30, surely?

 

 

> = Roni:

>A media capture is associated = with an encoding group !!!!! not an individual = encoding.

 

That's true, and by design. To = re-iterate the original design intent here, the idea behind the encoding = groups idea was to be able to model 2 common Telepresence architectures = we see today:

1) a multi-screen endpoint room = comprised of multiple endpoints (most vendors' "3 screen" = systems, for instance, tend to be composed of 3 of their "1 = screen" products linked together)

2) a flexible media generation system = such as a software or hardware MCU

 

For the "1)" case above, = due to real-world constraints such as camera wiring etc., it seemed to = us that a media capture representing, say, the left camera of 3, would = only be able to be encoded by the hardware it was directly connected to = - thus, such a system would use one "encoding group" for its = left constituent, one for its centre and one for its = right.

 

>Roni:

 

>The provider can use one of the = individual encoding to instantiate a media capture, each individual = encoding can be used by one media capture, the decision of which one to = use according to the framework is by the provider. The consumer does not = select an individual encode.

 

That was not the intent - it should = be the consumer that chooses media capture / individual encoding pairs = to instantiate "capture encodings". When forming its configure = message, the consumer essentially supplies a set of media capture ID + = encoding ID pairs to instruct the provider on which capture encodings to = send. Having just re-read it, I think that the description as per = Section 9 of the current framework document described this well (though = Mark deserves the credit for that, obviously!).

 

>Roni: 

>The maximum number of streams = that can result from a particular encoding group is equal to the number = of individual encodings in the group (note that this is why the example = in the current data model allows only for one video and one audio = streams).

 

It is true that the number of streams = that can result from a particular encoding group is equal to the number = of individual encodings in the group - however, a fully flexible system = might choose to have a single encoding group and so no real restriction = need be introduced by this (unless the provider system has such = restrictions - in which case they can be modelled in this = way).

 

 

>Roni:

 

>Section 8 of the framework talk = about having more than one individual encoding assigned to a media = capture (simulcast) and also claims that it can be done by the consumer = but there is no way to do it since the media capture is associated only = with an encoding group. There is no way for a consumer even to assign a = specific individual encoding to a group.

 

You're right that there's no way for = the consumer to assign a specific individual encoding to a group, but = it's not clear what the need is - if a provider system is sufficiently = flexible that any encoding can be used by any media capture, then it = should construct its advertisement to use just a single encoding group = to comprise all encodings, at which point the consumer has greater = flexibility in which it can choose to be sent to = it.

 

 

>Roni: 

>The video is H.264 specific and = not general

 

The problem we had was that we needed = to come up with a way of describing a big block of video encoding = capability and how it could be subdivided. e.g. you might be able to = send 2 x 720p30 but not a single 720p60. The best scheme we could come = up with was to, for each of H.264, H.265 etc. include some specific = parameters that would allow both a provider's overall capability to be = signalled and how it might be subdivided across multiple encodings. It's = true that currently the parameters only really work for H.264 and, = moreover, only really work for a provider sending all encodings within a = group using the same codec, but the expectation was that new codecs = would have their own equivalent parameters added here in a similar = way.

 

 

>Roni:

>The relation between the = individual encode and encoding group makes it difficult to achieve a = reasonable set even if the consumer will be able to select the mapping. = This is due to the fact the total defined by the group limits the usage = for individual encoding. For example if  we have a three camera = system and we set a value in the  group for maxGroupH264Mbps and = want to allow for simulcast (two resolutions), we will need to define = six individual encodes, three with high resolution ( also high = maxH264Mbps) and three lower resolution with lower maxH264Mbps. If the = compute resource can do all six it will  reflected in the value of = maxGroupH264Mbps but I assume that there is a constrain (otherwise why = have encodings) making it lower. So if the consumer will ask for all six = what will happen. Since there is more than one degree of freedom he will = not be able to predict if he will get all or part on lower frame rate , = if he will get only a subset of the streams, if he will get different = resolutions.

 

The situation you describe is, I = would argue, exactly what the parameters are for. The consumer would be = allowed to ask for all 6, each with consumer-imposed maximum values. The = provider would be bound by its overall maxGroupH264Mbps as well as each = individual encoding's max. value - in many senses this is no difference = to existing systems' balancing of bit rate across main and presentation = limits. I think if the consumer asks for all six then what will happen = should be very predictable - 6 capture encodings will be sent to the = consumer, with each capped by the lower of the consumer's request = parameters and the provider's limitations. It is true that the frame = rate / resolution would be bounded but not fixed, but this is true today = on a video call - if you can receive 720p30 you don't know whether the = far end will send you 720p30, 720p5, CIF30 etc. I'm not sure I see how = what we're talking about here does anything but follow normal encoder = and decoder behavior as seen today (equally, I confess that I may not be = fully understanding the intricacies of the case you = describe).

 

>On the other hand if the 6 = individual encodes will include lower values to allow for the group = limit it will mean that a consumer not doing simulcast is limited by the = fact the simulcast and ask (if possible) for only three streams, the = individual encodes limit will be low so he will not be able to use the = full compute resources.

 

>Roni:

>Section 8 concludes that the = number of individual encodes in a group must allow for all media capture = in a capture scene entry to be used = simultaneously.

 

Yes, this is a corollary of the = constraint that all media captures in a capture scene entry must be able = to be provided simultaneously (which itself is a corollary of the idea = that each capture scene entry is in itself a useful representation of = the scene).

 

>So it look like this system does = not work well for simulcast. What about no simulcast, is it needed. For = example a three camera system that also have one presentation. My view = that the cameras will be one capture scene and the presentation will be = a second one. The question is if they all belong to one encoding group, = here my view is “no” since they have different priority and = should not compete for compute resources.

 

Another view is that if the provider = does encode the cameras and the presentation from the same pool of = encoding resource then it is valid for the consumer to choose which to = prioritise (i.e. the provider could leave the consumer to allocate = encodings to the media captures).

 

>Roni:

>So we will have two encoding = groups one for presentation and one for the three cameras. For the three = cameras each sending one stream I assume that the resource allocation = will be a third for each so we will have three individual encode with = the same values, this is the basic one and if it is a third than no need = for advertising or configuring. Now if we also want to have an = individual encode that has higher compute if the consumer wants only one = capture (of the whole room), the group will have fourth one with higher = value. So if there is way for consumer to configure individual encode = when using three media captures, he may select the higher capability one = with two lower ones. The total will be limited by the encoding group = value and again it is not clear how the actual streams will be encoded = to address the group limit since there are multiple = options.

 

To my mind this is no different to = the sort of trace offs / choices that are already made in this sort of = system today - in a video call it is common to not be able to send a = camera stream at full resolution and full frame rate either because of = bandwidth limitations or the capabilities of the receiver. In the case = you cite, yes, the consumer could choose to impose different video = limits on the left center and right cameras, but it would be within its = rights to do so, just as the provider would then be within its rights to = send them all at the lowest of the 3 levels.

 

>Roni: 

>To summarize I do not see value = in the encoding as currently specified since they only provide = information and no option for configuration. The value of it as = information does not justify specifying them and if the intention is to = allow configurations of individual encoding it must be reflected and the = explained how it works.

 

>Roni: 

>My proposal is at the moment to = remove the encoding until we get some text that defines how to use it = for configuring encoding to media captures including for the simulcast = case

 

I think I'd agree with you if it really were true that simulcast was = ill-defined here, but I think it's covered pretty well. It's clear that = you've thought about it in a lot of detail though, so I'm sure there'll = be more to discuss on this...

 

Regards,

 

Andy

 

 

On Thu, = Nov 1, 2012 at 4:38 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

(As co-chair)

Roni is proposing a significant = change here.

PLEASE carefully consider this and comment on it = here on the mailing list!

*If* this works and satisfies all = objectives then it will be a helpful simplification. But it may be that = simplifying things this way excludes some required behavior.

This = is something that would benefit from discussion next week. But that = won't be helpful if people haven't already thought about = it.

        Thanks,
      =   Paul



On = 10/31/12 5:49 AM, Roni Even wrote:

Hi,

 From the email = discussion it looks to me that the concept of the
encoding as = specified in the framework document is not clear. I will try
to = describe my understanding of sections 7 and 8 of the = framework
document and explain why I think that it is not important = to CLUE as
specified. I am looking for response if my understanding = of the encoding
based on the framework is correct and how it will = work for the examples
I will provide bellow

The purpose of the = Encodings is to provide INFORMATION about the
provider abilities to = send streams. This relates to the available
resources (compute and = BW) of the providers.

The encodings are constructed from encoding = groups and each encoding
group is include individual = encodes.

The encoding group provide a value for the total maximum = BW and compute
H264Mbps (note that it is H.264 specific) of all the = individual encodes
in the group that the provider can use to send = audio and video.

Each encoding group include a list of individual = encodes  (audio and /or
video). These provide maximum values = that can be used to instantiate a
media stream by the = provider.

Each video individual encodes identified by an encodeID = provides maximum
values  for BW, compute, resolution and frame = rate for H.264. (BTW: the
maxH264Mbps can be computed from the = resolution and frame rate as
defined in table 2 making it = redundant).

Each audio encode has only a BW value (no = identifier).

A media capture is associated with an encoding group = !!!!! not an
individual encoding.

The provider can use one of = the individual encoding to instantiate a
media capture, each = individual encoding can be used by one media
capture, the decision of = which one to use according to the framework is
by the provider. The = consumer does not select an individual encode.

The maximum number = of streams that can result from a particular encoding
group is equal = to the number of individual encodings in the group (note
that this is = why the example in the current data model allows only for
one video = and one audio streams).

Section 8 of the framework talk about = having more than one individual
encoding assigned to a media capture = (simulcast) and also claims that it
can be done by the consumer but = there is no way to do it since the media
capture is associated only = with an encoding group. There is no way for a
consumer even to assign = a specific individual encoding to a group.

My view is that this = mechanism does not work and can be removed. The
reasons are given = bellow

The encoding as currently specified is provided as = information since
there is no way to map one or more individual = encoding to a specific
media capture

The video is H.264 = specific and not general

The relation between the individual = encode and encoding group makes it
difficult to achieve a reasonable = set even if the consumer will be able
to select the mapping. This is = due to the fact the total defined by the
group limits the usage for = individual encoding. For example if  we have
a three camera = system and we set a value in the  group for
maxGroupH264Mbps and = want to allow for simulcast (two resolutions), we
will need to define = six individual encodes, three with high resolution (
also high = maxH264Mbps) and three lower resolution with lower
maxH264Mbps. If = the compute resource can do all six it will  reflected
in the = value of maxGroupH264Mbps but I assume that there is a = constrain
(otherwise why have encodings) making it lower. So if the = consumer will
ask for all six what will happen. Since there is more = than one degree of
freedom he will not be able to predict if he will = get all or part on
lower frame rate , if he will get only a subset of = the streams, if he
will get different resolutions.

On the = other hand if the 6 individual encodes will include lower values
to = allow for the group limit it will mean that a consumer not = doing
simulcast is limited by the fact the simulcast and ask (if = possible) for
only three streams, the individual encodes limit will = be low so he will
not be able to use the full compute = resources.

Section 8 concludes that the number of individual = encodes in a group
must allow for all media capture in a capture = scene entry to be used
simultaneously.

So it look like this = system does not work well for simulcast. What about
no simulcast, is = it needed. For example a three camera system that also
have one = presentation. My view that the cameras will be one capture
scene and = the presentation will be a second one. The question is if they
all = belong to one encoding group, here my view is “no” since = they have
different priority and should not compete for compute = resources. So we
will have two encoding groups one for presentation = and one for the three
cameras. For the three cameras each sending one = stream I assume that the
resource allocation will be a third for each = so we will have three
individual encode with the same values, this is = the basic one and if it
is a third than no need for advertising or = configuring. Now if we also
want to have an individual encode that = has higher compute if the
consumer wants only one capture (of the = whole room), the group will have
fourth one with higher value. So if = there is way for consumer to
configure individual encode when using = three media captures, he may
select the higher capability one with = two lower ones. The total will be
limited by the encoding group value = and again it is not clear how the
actual streams will be encoded to = address the group limit since there
are multiple options.

To = summarize I do not see value in the encoding as currently = specified
since they only provide information and no option for = configuration. The
value of it as information does not justify = specifying them and if the
intention is to allow configurations of = individual encoding it must be
reflected and the explained how it = works.

My proposal is at the moment to remove the encoding until = we get some
text that defines how to use it for configuring encoding = to media
captures including for the simulcast = case

Thanks

Roni = Even


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


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

 

------=_NextPart_000_0195_01CDBB33.59F5A750-- From ron.even.tlv@gmail.com Mon Nov 5 06:03: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 99FD721F84C5 for ; Mon, 5 Nov 2012 06:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, 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 8n7xLFCEs9bk for ; Mon, 5 Nov 2012 06:03:29 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5086221F84FB for ; Mon, 5 Nov 2012 06:03:10 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so2696060dan.31 for ; Mon, 05 Nov 2012 06:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=kd67FxrC2VDosxD0budq6w3eYaedG9VhVJ4cBEKdZr8=; b=QFA5sXrd9zc6wApYiakYysPPojEM3nE6cKXbm97m2JZzpCJfy4UCeCPopdNgpGB78c 1fXFeYEiUKoIsz80ZwUVTvxdr7mdg4UXieLNO8do6f9ss9ZW5/GGYY9xE+Rdx4Naypik dlLe1RdeYsDDKI+ZE1syujn0yZu5WA+swFPzzfqlATkzB7dKOCcclcXxoLw4nkQoWJWV bxRR3Nm2WP7rk/LDtV6dfsmU39/UALALdyNYtSst0x/Q3+pkpBLYDycKiLfxPnckXwo1 4Rta2Mrc33IRKb1v6dA5kZBDqSYoj0YJLCMLoB0AsWyrYylsJrYKsIqoqsnpjjP7cRM1 2D2Q== Received: by 10.68.209.230 with SMTP id mp6mr30361386pbc.8.1352124190075; Mon, 05 Nov 2012 06:03:10 -0800 (PST) Received: from RoniE ([2001:df8:0:16:19f7:967a:abb6:4267]) by mx.google.com with ESMTPS id o1sm10692758paz.34.2012.11.05.06.03.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Nov 2012 06:03:09 -0800 (PST) From: "Roni Even" To: "'Andy Pepperell'" , "'Paul Kyzivat'" References: <01d301cdb74d$10857940$31906bc0$@gmail.com> <5092A599.4010601@alum.mit.edu> In-Reply-To: Date: Mon, 5 Nov 2012 09:00:34 -0500 Message-ID: <019f01cdbb5d$eeeb67d0$ccc23770$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A0_01CDBB34.06189420" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGd50DMAF+DH9t0mI1O0aq46xBPTAGcYWeqAtPA0D2YF2vX8A== Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Do we need the encodings as secified in the framework document - proposal to remove them from the framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2012 14:03:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A0_01CDBB34.06189420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Andy, I was wondering how can an MCU create a common encoding group and individual encodes if all participating EP do not have a common limit since it needs to provide a common advertisement Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy Pepperell Sent: 02 November, 2012 11:20 AM To: Paul Kyzivat Cc: clue@ietf.org Subject: Re: [clue] Do we need the encodings as secified in the framework document - proposal to remove them from the framework >Paul: >*If* this works and satisfies all objectives then it will be a helpful simplification. But it may be that simplifying things this way excludes some required behavior. I certainly agree with Paul's point here... however, with not all that many of Roni's (as might be expected :) ) - to be specific: >Roni: >Each encoding group include a list of individual encodes (audio and /or video). These provide maximum values that can be used to instantiate a media stream by the provider. Yes, I think that's a good summary. >Each video individual encodes identified by an encodeID provides maximum values for BW, compute, resolution and frame rate for H.264. (BTW: the maxH264Mbps can be computed from the resolution and frame rate as defined in table 2 making it redundant). >Each audio encode has only a BW value (no identifier). Also agreed - apart from the H.264 point I think - a maximum resolution and a maximum frame rate doesn't necessarily imply a maxMbps - many systems can encode 1280x720 at some frame rate < 30 *or* some lower resolution at up to 30fps without necessarily being able to send 720p30, surely? > Roni: >A media capture is associated with an encoding group !!!!! not an individual encoding. That's true, and by design. To re-iterate the original design intent here, the idea behind the encoding groups idea was to be able to model 2 common Telepresence architectures we see today: 1) a multi-screen endpoint room comprised of multiple endpoints (most vendors' "3 screen" systems, for instance, tend to be composed of 3 of their "1 screen" products linked together) 2) a flexible media generation system such as a software or hardware MCU For the "1)" case above, due to real-world constraints such as camera wiring etc., it seemed to us that a media capture representing, say, the left camera of 3, would only be able to be encoded by the hardware it was directly connected to - thus, such a system would use one "encoding group" for its left constituent, one for its centre and one for its right. >Roni: >The provider can use one of the individual encoding to instantiate a media capture, each individual encoding can be used by one media capture, the decision of which one to use according to the framework is by the provider. The consumer does not select an individual encode. That was not the intent - it should be the consumer that chooses media capture / individual encoding pairs to instantiate "capture encodings". When forming its configure message, the consumer essentially supplies a set of media capture ID + encoding ID pairs to instruct the provider on which capture encodings to send. Having just re-read it, I think that the description as per Section 9 of the current framework document described this well (though Mark deserves the credit for that, obviously!). >Roni: >The maximum number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group (note that this is why the example in the current data model allows only for one video and one audio streams). It is true that the number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group - however, a fully flexible system might choose to have a single encoding group and so no real restriction need be introduced by this (unless the provider system has such restrictions - in which case they can be modelled in this way). >Roni: >Section 8 of the framework talk about having more than one individual encoding assigned to a media capture (simulcast) and also claims that it can be done by the consumer but there is no way to do it since the media capture is associated only with an encoding group. There is no way for a consumer even to assign a specific individual encoding to a group. You're right that there's no way for the consumer to assign a specific individual encoding to a group, but it's not clear what the need is - if a provider system is sufficiently flexible that any encoding can be used by any media capture, then it should construct its advertisement to use just a single encoding group to comprise all encodings, at which point the consumer has greater flexibility in which it can choose to be sent to it. >Roni: >The video is H.264 specific and not general The problem we had was that we needed to come up with a way of describing a big block of video encoding capability and how it could be subdivided. e.g. you might be able to send 2 x 720p30 but not a single 720p60. The best scheme we could come up with was to, for each of H.264, H.265 etc. include some specific parameters that would allow both a provider's overall capability to be signalled and how it might be subdivided across multiple encodings. It's true that currently the parameters only really work for H.264 and, moreover, only really work for a provider sending all encodings within a group using the same codec, but the expectation was that new codecs would have their own equivalent parameters added here in a similar way. >Roni: >The relation between the individual encode and encoding group makes it difficult to achieve a reasonable set even if the consumer will be able to select the mapping. This is due to the fact the total defined by the group limits the usage for individual encoding. For example if we have a three camera system and we set a value in the group for maxGroupH264Mbps and want to allow for simulcast (two resolutions), we will need to define six individual encodes, three with high resolution ( also high maxH264Mbps) and three lower resolution with lower maxH264Mbps. If the compute resource can do all six it will reflected in the value of maxGroupH264Mbps but I assume that there is a constrain (otherwise why have encodings) making it lower. So if the consumer will ask for all six what will happen. Since there is more than one degree of freedom he will not be able to predict if he will get all or part on lower frame rate , if he will get only a subset of the streams, if he will get different resolutions. The situation you describe is, I would argue, exactly what the parameters are for. The consumer would be allowed to ask for all 6, each with consumer-imposed maximum values. The provider would be bound by its overall maxGroupH264Mbps as well as each individual encoding's max. value - in many senses this is no difference to existing systems' balancing of bit rate across main and presentation limits. I think if the consumer asks for all six then what will happen should be very predictable - 6 capture encodings will be sent to the consumer, with each capped by the lower of the consumer's request parameters and the provider's limitations. It is true that the frame rate / resolution would be bounded but not fixed, but this is true today on a video call - if you can receive 720p30 you don't know whether the far end will send you 720p30, 720p5, CIF30 etc. I'm not sure I see how what we're talking about here does anything but follow normal encoder and decoder behavior as seen today (equally, I confess that I may not be fully understanding the intricacies of the case you describe). >On the other hand if the 6 individual encodes will include lower values to allow for the group limit it will mean that a consumer not doing simulcast is limited by the fact the simulcast and ask (if possible) for only three streams, the individual encodes limit will be low so he will not be able to use the full compute resources. >Roni: >Section 8 concludes that the number of individual encodes in a group must allow for all media capture in a capture scene entry to be used simultaneously. Yes, this is a corollary of the constraint that all media captures in a capture scene entry must be able to be provided simultaneously (which itself is a corollary of the idea that each capture scene entry is in itself a useful representation of the scene). >So it look like this system does not work well for simulcast. What about no simulcast, is it needed. For example a three camera system that also have one presentation. My view that the cameras will be one capture scene and the presentation will be a second one. The question is if they all belong to one encoding group, here my view is "no" since they have different priority and should not compete for compute resources. Another view is that if the provider does encode the cameras and the presentation from the same pool of encoding resource then it is valid for the consumer to choose which to prioritise (i.e. the provider could leave the consumer to allocate encodings to the media captures). >Roni: >So we will have two encoding groups one for presentation and one for the three cameras. For the three cameras each sending one stream I assume that the resource allocation will be a third for each so we will have three individual encode with the same values, this is the basic one and if it is a third than no need for advertising or configuring. Now if we also want to have an individual encode that has higher compute if the consumer wants only one capture (of the whole room), the group will have fourth one with higher value. So if there is way for consumer to configure individual encode when using three media captures, he may select the higher capability one with two lower ones. The total will be limited by the encoding group value and again it is not clear how the actual streams will be encoded to address the group limit since there are multiple options. To my mind this is no different to the sort of trace offs / choices that are already made in this sort of system today - in a video call it is common to not be able to send a camera stream at full resolution and full frame rate either because of bandwidth limitations or the capabilities of the receiver. In the case you cite, yes, the consumer could choose to impose different video limits on the left center and right cameras, but it would be within its rights to do so, just as the provider would then be within its rights to send them all at the lowest of the 3 levels. >Roni: >To summarize I do not see value in the encoding as currently specified since they only provide information and no option for configuration. The value of it as information does not justify specifying them and if the intention is to allow configurations of individual encoding it must be reflected and the explained how it works. >Roni: >My proposal is at the moment to remove the encoding until we get some text that defines how to use it for configuring encoding to media captures including for the simulcast case I think I'd agree with you if it really were true that simulcast was ill-defined here, but I think it's covered pretty well. It's clear that you've thought about it in a lot of detail though, so I'm sure there'll be more to discuss on this... Regards, Andy On Thu, Nov 1, 2012 at 4:38 PM, Paul Kyzivat wrote: (As co-chair) Roni is proposing a significant change here. PLEASE carefully consider this and comment on it here on the mailing list! *If* this works and satisfies all objectives then it will be a helpful simplification. But it may be that simplifying things this way excludes some required behavior. This is something that would benefit from discussion next week. But that won't be helpful if people haven't already thought about it. Thanks, Paul On 10/31/12 5:49 AM, Roni Even wrote: Hi, From the email discussion it looks to me that the concept of the encoding as specified in the framework document is not clear. I will try to describe my understanding of sections 7 and 8 of the framework document and explain why I think that it is not important to CLUE as specified. I am looking for response if my understanding of the encoding based on the framework is correct and how it will work for the examples I will provide bellow The purpose of the Encodings is to provide INFORMATION about the provider abilities to send streams. This relates to the available resources (compute and BW) of the providers. The encodings are constructed from encoding groups and each encoding group is include individual encodes. The encoding group provide a value for the total maximum BW and compute H264Mbps (note that it is H.264 specific) of all the individual encodes in the group that the provider can use to send audio and video. Each encoding group include a list of individual encodes (audio and /or video). These provide maximum values that can be used to instantiate a media stream by the provider. Each video individual encodes identified by an encodeID provides maximum values for BW, compute, resolution and frame rate for H.264. (BTW: the maxH264Mbps can be computed from the resolution and frame rate as defined in table 2 making it redundant). Each audio encode has only a BW value (no identifier). A media capture is associated with an encoding group !!!!! not an individual encoding. The provider can use one of the individual encoding to instantiate a media capture, each individual encoding can be used by one media capture, the decision of which one to use according to the framework is by the provider. The consumer does not select an individual encode. The maximum number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group (note that this is why the example in the current data model allows only for one video and one audio streams). Section 8 of the framework talk about having more than one individual encoding assigned to a media capture (simulcast) and also claims that it can be done by the consumer but there is no way to do it since the media capture is associated only with an encoding group. There is no way for a consumer even to assign a specific individual encoding to a group. My view is that this mechanism does not work and can be removed. The reasons are given bellow The encoding as currently specified is provided as information since there is no way to map one or more individual encoding to a specific media capture The video is H.264 specific and not general The relation between the individual encode and encoding group makes it difficult to achieve a reasonable set even if the consumer will be able to select the mapping. This is due to the fact the total defined by the group limits the usage for individual encoding. For example if we have a three camera system and we set a value in the group for maxGroupH264Mbps and want to allow for simulcast (two resolutions), we will need to define six individual encodes, three with high resolution ( also high maxH264Mbps) and three lower resolution with lower maxH264Mbps. If the compute resource can do all six it will reflected in the value of maxGroupH264Mbps but I assume that there is a constrain (otherwise why have encodings) making it lower. So if the consumer will ask for all six what will happen. Since there is more than one degree of freedom he will not be able to predict if he will get all or part on lower frame rate , if he will get only a subset of the streams, if he will get different resolutions. On the other hand if the 6 individual encodes will include lower values to allow for the group limit it will mean that a consumer not doing simulcast is limited by the fact the simulcast and ask (if possible) for only three streams, the individual encodes limit will be low so he will not be able to use the full compute resources. Section 8 concludes that the number of individual encodes in a group must allow for all media capture in a capture scene entry to be used simultaneously. So it look like this system does not work well for simulcast. What about no simulcast, is it needed. For example a three camera system that also have one presentation. My view that the cameras will be one capture scene and the presentation will be a second one. The question is if they all belong to one encoding group, here my view is "no" since they have different priority and should not compete for compute resources. So we will have two encoding groups one for presentation and one for the three cameras. For the three cameras each sending one stream I assume that the resource allocation will be a third for each so we will have three individual encode with the same values, this is the basic one and if it is a third than no need for advertising or configuring. Now if we also want to have an individual encode that has higher compute if the consumer wants only one capture (of the whole room), the group will have fourth one with higher value. So if there is way for consumer to configure individual encode when using three media captures, he may select the higher capability one with two lower ones. The total will be limited by the encoding group value and again it is not clear how the actual streams will be encoded to address the group limit since there are multiple options. To summarize I do not see value in the encoding as currently specified since they only provide information and no option for configuration. The value of it as information does not justify specifying them and if the intention is to allow configurations of individual encoding it must be reflected and the explained how it works. My proposal is at the moment to remove the encoding until we get some text that defines how to use it for configuring encoding to media captures including for the simulcast case Thanks Roni Even _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_01A0_01CDBB34.06189420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

I was wondering how can an MCU create a common encoding group and = individual encodes if all participating EP do not have a common limit = since it needs to provide a common advertisement

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Andy Pepperell
Sent: 02 November, 2012 11:20 = AM
To: Paul Kyzivat
Cc: = clue@ietf.org
Subject: Re: [clue] Do we need the encodings as = secified in the framework document - proposal to remove them from the = framework

 

>Paul:

>*If* this works and satisfies all objectives then it will be a = helpful simplification. But it may be that simplifying things this way = excludes some required behavior.

 

I certainly agree with Paul's point here... however, with not all that = many of Roni's (as might be expected :) ) - to be = specific:

 

>Roni:

>Each encoding group include a = list of individual encodes  (audio and /or video). These provide = maximum values that can be used to instantiate a media stream by the = provider.

 

Yes, I think that's a good = summary.

 

>Each video individual encodes = identified by an encodeID provides maximum values  for BW, compute, = resolution and frame rate for H.264. (BTW: the maxH264Mbps can be = computed from the resolution and frame rate as defined in table 2 making = it redundant).

>Each audio encode has only a BW = value (no identifier).

 

Also agreed - apart from the H.264 = point I think - a maximum resolution and a maximum frame rate doesn't = necessarily imply a maxMbps - many systems can encode 1280x720 at some = frame rate < 30 *or* some lower resolution at up to 30fps without = necessarily being able to send 720p30, surely?

 

 

> = Roni:

>A media capture is associated = with an encoding group !!!!! not an individual = encoding.

 

That's true, and by design. To = re-iterate the original design intent here, the idea behind the encoding = groups idea was to be able to model 2 common Telepresence architectures = we see today:

1) a multi-screen endpoint room = comprised of multiple endpoints (most vendors' "3 screen" = systems, for instance, tend to be composed of 3 of their "1 = screen" products linked together)

2) a flexible media generation system = such as a software or hardware MCU

 

For the "1)" case above, = due to real-world constraints such as camera wiring etc., it seemed to = us that a media capture representing, say, the left camera of 3, would = only be able to be encoded by the hardware it was directly connected to = - thus, such a system would use one "encoding group" for its = left constituent, one for its centre and one for its = right.

 

>Roni:

 

>The provider can use one of the = individual encoding to instantiate a media capture, each individual = encoding can be used by one media capture, the decision of which one to = use according to the framework is by the provider. The consumer does not = select an individual encode.

 

That was not the intent - it should = be the consumer that chooses media capture / individual encoding pairs = to instantiate "capture encodings". When forming its configure = message, the consumer essentially supplies a set of media capture ID + = encoding ID pairs to instruct the provider on which capture encodings to = send. Having just re-read it, I think that the description as per = Section 9 of the current framework document described this well (though = Mark deserves the credit for that, obviously!).

 

>Roni: 

>The maximum number of streams = that can result from a particular encoding group is equal to the number = of individual encodings in the group (note that this is why the example = in the current data model allows only for one video and one audio = streams).

 

It is true that the number of streams = that can result from a particular encoding group is equal to the number = of individual encodings in the group - however, a fully flexible system = might choose to have a single encoding group and so no real restriction = need be introduced by this (unless the provider system has such = restrictions - in which case they can be modelled in this = way).

 

 

>Roni:

 

>Section 8 of the framework talk = about having more than one individual encoding assigned to a media = capture (simulcast) and also claims that it can be done by the consumer = but there is no way to do it since the media capture is associated only = with an encoding group. There is no way for a consumer even to assign a = specific individual encoding to a group.

 

You're right that there's no way for = the consumer to assign a specific individual encoding to a group, but = it's not clear what the need is - if a provider system is sufficiently = flexible that any encoding can be used by any media capture, then it = should construct its advertisement to use just a single encoding group = to comprise all encodings, at which point the consumer has greater = flexibility in which it can choose to be sent to = it.

 

 

>Roni: 

>The video is H.264 specific and = not general

 

The problem we had was that we needed = to come up with a way of describing a big block of video encoding = capability and how it could be subdivided. e.g. you might be able to = send 2 x 720p30 but not a single 720p60. The best scheme we could come = up with was to, for each of H.264, H.265 etc. include some specific = parameters that would allow both a provider's overall capability to be = signalled and how it might be subdivided across multiple encodings. It's = true that currently the parameters only really work for H.264 and, = moreover, only really work for a provider sending all encodings within a = group using the same codec, but the expectation was that new codecs = would have their own equivalent parameters added here in a similar = way.

 

 

>Roni:

>The relation between the = individual encode and encoding group makes it difficult to achieve a = reasonable set even if the consumer will be able to select the mapping. = This is due to the fact the total defined by the group limits the usage = for individual encoding. For example if  we have a three camera = system and we set a value in the  group for maxGroupH264Mbps and = want to allow for simulcast (two resolutions), we will need to define = six individual encodes, three with high resolution ( also high = maxH264Mbps) and three lower resolution with lower maxH264Mbps. If the = compute resource can do all six it will  reflected in the value of = maxGroupH264Mbps but I assume that there is a constrain (otherwise why = have encodings) making it lower. So if the consumer will ask for all six = what will happen. Since there is more than one degree of freedom he will = not be able to predict if he will get all or part on lower frame rate , = if he will get only a subset of the streams, if he will get different = resolutions.

 

The situation you describe is, I = would argue, exactly what the parameters are for. The consumer would be = allowed to ask for all 6, each with consumer-imposed maximum values. The = provider would be bound by its overall maxGroupH264Mbps as well as each = individual encoding's max. value - in many senses this is no difference = to existing systems' balancing of bit rate across main and presentation = limits. I think if the consumer asks for all six then what will happen = should be very predictable - 6 capture encodings will be sent to the = consumer, with each capped by the lower of the consumer's request = parameters and the provider's limitations. It is true that the frame = rate / resolution would be bounded but not fixed, but this is true today = on a video call - if you can receive 720p30 you don't know whether the = far end will send you 720p30, 720p5, CIF30 etc. I'm not sure I see how = what we're talking about here does anything but follow normal encoder = and decoder behavior as seen today (equally, I confess that I may not be = fully understanding the intricacies of the case you = describe).

 

>On the other hand if the 6 = individual encodes will include lower values to allow for the group = limit it will mean that a consumer not doing simulcast is limited by the = fact the simulcast and ask (if possible) for only three streams, the = individual encodes limit will be low so he will not be able to use the = full compute resources.

 

>Roni:

>Section 8 concludes that the = number of individual encodes in a group must allow for all media capture = in a capture scene entry to be used = simultaneously.

 

Yes, this is a corollary of the = constraint that all media captures in a capture scene entry must be able = to be provided simultaneously (which itself is a corollary of the idea = that each capture scene entry is in itself a useful representation of = the scene).

 

>So it look like this system does = not work well for simulcast. What about no simulcast, is it needed. For = example a three camera system that also have one presentation. My view = that the cameras will be one capture scene and the presentation will be = a second one. The question is if they all belong to one encoding group, = here my view is “no” since they have different priority and = should not compete for compute resources.

 

Another view is that if the provider = does encode the cameras and the presentation from the same pool of = encoding resource then it is valid for the consumer to choose which to = prioritise (i.e. the provider could leave the consumer to allocate = encodings to the media captures).

 

>Roni:

>So we will have two encoding = groups one for presentation and one for the three cameras. For the three = cameras each sending one stream I assume that the resource allocation = will be a third for each so we will have three individual encode with = the same values, this is the basic one and if it is a third than no need = for advertising or configuring. Now if we also want to have an = individual encode that has higher compute if the consumer wants only one = capture (of the whole room), the group will have fourth one with higher = value. So if there is way for consumer to configure individual encode = when using three media captures, he may select the higher capability one = with two lower ones. The total will be limited by the encoding group = value and again it is not clear how the actual streams will be encoded = to address the group limit since there are multiple = options.

 

To my mind this is no different to = the sort of trace offs / choices that are already made in this sort of = system today - in a video call it is common to not be able to send a = camera stream at full resolution and full frame rate either because of = bandwidth limitations or the capabilities of the receiver. In the case = you cite, yes, the consumer could choose to impose different video = limits on the left center and right cameras, but it would be within its = rights to do so, just as the provider would then be within its rights to = send them all at the lowest of the 3 levels.

 

>Roni: 

>To summarize I do not see value = in the encoding as currently specified since they only provide = information and no option for configuration. The value of it as = information does not justify specifying them and if the intention is to = allow configurations of individual encoding it must be reflected and the = explained how it works.

 

>Roni: 

>My proposal is at the moment to = remove the encoding until we get some text that defines how to use it = for configuring encoding to media captures including for the simulcast = case

 

I think I'd agree with you if it really were true that simulcast was = ill-defined here, but I think it's covered pretty well. It's clear that = you've thought about it in a lot of detail though, so I'm sure there'll = be more to discuss on this...

 

Regards,

 

Andy

 

 

On Thu, = Nov 1, 2012 at 4:38 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

(As co-chair)

Roni is proposing a significant = change here.

PLEASE carefully consider this and comment on it = here on the mailing list!

*If* this works and satisfies all = objectives then it will be a helpful simplification. But it may be that = simplifying things this way excludes some required behavior.

This = is something that would benefit from discussion next week. But that = won't be helpful if people haven't already thought about = it.

        Thanks,
      =   Paul



On = 10/31/12 5:49 AM, Roni Even wrote:

Hi,

 From the email = discussion it looks to me that the concept of the
encoding as = specified in the framework document is not clear. I will try
to = describe my understanding of sections 7 and 8 of the = framework
document and explain why I think that it is not important = to CLUE as
specified. I am looking for response if my understanding = of the encoding
based on the framework is correct and how it will = work for the examples
I will provide bellow

The purpose of the = Encodings is to provide INFORMATION about the
provider abilities to = send streams. This relates to the available
resources (compute and = BW) of the providers.

The encodings are constructed from encoding = groups and each encoding
group is include individual = encodes.

The encoding group provide a value for the total maximum = BW and compute
H264Mbps (note that it is H.264 specific) of all the = individual encodes
in the group that the provider can use to send = audio and video.

Each encoding group include a list of individual = encodes  (audio and /or
video). These provide maximum values = that can be used to instantiate a
media stream by the = provider.

Each video individual encodes identified by an encodeID = provides maximum
values  for BW, compute, resolution and frame = rate for H.264. (BTW: the
maxH264Mbps can be computed from the = resolution and frame rate as
defined in table 2 making it = redundant).

Each audio encode has only a BW value (no = identifier).

A media capture is associated with an encoding group = !!!!! not an
individual encoding.

The provider can use one of = the individual encoding to instantiate a
media capture, each = individual encoding can be used by one media
capture, the decision of = which one to use according to the framework is
by the provider. The = consumer does not select an individual encode.

The maximum number = of streams that can result from a particular encoding
group is equal = to the number of individual encodings in the group (note
that this is = why the example in the current data model allows only for
one video = and one audio streams).

Section 8 of the framework talk about = having more than one individual
encoding assigned to a media capture = (simulcast) and also claims that it
can be done by the consumer but = there is no way to do it since the media
capture is associated only = with an encoding group. There is no way for a
consumer even to assign = a specific individual encoding to a group.

My view is that this = mechanism does not work and can be removed. The
reasons are given = bellow

The encoding as currently specified is provided as = information since
there is no way to map one or more individual = encoding to a specific
media capture

The video is H.264 = specific and not general

The relation between the individual = encode and encoding group makes it
difficult to achieve a reasonable = set even if the consumer will be able
to select the mapping. This is = due to the fact the total defined by the
group limits the usage for = individual encoding. For example if  we have
a three camera = system and we set a value in the  group for
maxGroupH264Mbps and = want to allow for simulcast (two resolutions), we
will need to define = six individual encodes, three with high resolution (
also high = maxH264Mbps) and three lower resolution with lower
maxH264Mbps. If = the compute resource can do all six it will  reflected
in the = value of maxGroupH264Mbps but I assume that there is a = constrain
(otherwise why have encodings) making it lower. So if the = consumer will
ask for all six what will happen. Since there is more = than one degree of
freedom he will not be able to predict if he will = get all or part on
lower frame rate , if he will get only a subset of = the streams, if he
will get different resolutions.

On the = other hand if the 6 individual encodes will include lower values
to = allow for the group limit it will mean that a consumer not = doing
simulcast is limited by the fact the simulcast and ask (if = possible) for
only three streams, the individual encodes limit will = be low so he will
not be able to use the full compute = resources.

Section 8 concludes that the number of individual = encodes in a group
must allow for all media capture in a capture = scene entry to be used
simultaneously.

So it look like this = system does not work well for simulcast. What about
no simulcast, is = it needed. For example a three camera system that also
have one = presentation. My view that the cameras will be one capture
scene and = the presentation will be a second one. The question is if they
all = belong to one encoding group, here my view is “no” since = they have
different priority and should not compete for compute = resources. So we
will have two encoding groups one for presentation = and one for the three
cameras. For the three cameras each sending one = stream I assume that the
resource allocation will be a third for each = so we will have three
individual encode with the same values, this is = the basic one and if it
is a third than no need for advertising or = configuring. Now if we also
want to have an individual encode that = has higher compute if the
consumer wants only one capture (of the = whole room), the group will have
fourth one with higher value. So if = there is way for consumer to
configure individual encode when using = three media captures, he may
select the higher capability one with = two lower ones. The total will be
limited by the encoding group value = and again it is not clear how the
actual streams will be encoded to = address the group limit since there
are multiple options.

To = summarize I do not see value in the encoding as currently = specified
since they only provide information and no option for = configuration. The
value of it as information does not justify = specifying them and if the
intention is to allow configurations of = individual encoding it must be
reflected and the explained how it = works.

My proposal is at the moment to remove the encoding until = we get some
text that defines how to use it for configuring encoding = to media
captures including for the simulcast = case

Thanks

Roni = Even


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


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

 

------=_NextPart_000_01A0_01CDBB34.06189420-- From mary.ietf.barnes@gmail.com Mon Nov 5 12:35: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 322A821F87C6 for ; Mon, 5 Nov 2012 12:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[AWL=0.227, 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 2zlnt91HTB6a for ; Mon, 5 Nov 2012 12:35:24 -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 C88BC21F879E for ; Mon, 5 Nov 2012 12:35:23 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so4799939lbo.31 for ; Mon, 05 Nov 2012 12:35: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 :content-type; bh=B1vh1gU9ukfoxFD3vdtcF3x8LR4O+6M5HNXnDGslpho=; b=Am3ydKwoeJJfnon/06/1D6pZ4XN+BI8+OADKGBttwutfC49VVMuphNC7ttfYH7CLiZ wUciLgi27inenaX8SKNNeat6JzaJA4WQL3191NwP0lGd6zdj+boglXIcBKKY0SGfjB5f 4Z2X819Z1TcpsMc3uRmE2V8jQ8bXFDJbpcuT0GlnXVRLkG+6bf9F5vHcN3NTPEf+V889 J1DV6oJWJgj1IsmtbtfTN9Vk3f8PV+FqbcVLW3uXMCdXsCvQBEr9CTVwu7MJkC9lT4om S+HY1tSsllTU1PGQ1a/um66hNDhsH0RXKABLO55h/G0C225VXpFGgT7KuO5OPVtf9Rs8 Sc4Q== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr10254598lab.30.1352147722752; Mon, 05 Nov 2012 12:35:22 -0800 (PST) Received: by 10.114.69.139 with HTTP; Mon, 5 Nov 2012 12:35:22 -0800 (PST) In-Reply-To: References: <1784642497.12892.1351698965567.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Mon, 5 Nov 2012 14:35:22 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=e89a8f234665b2d2cb04cdc56c97 Subject: Re: [clue] Doodle: Link for poll "CLUE WG dinner" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2012 20:35:25 -0000 --e89a8f234665b2d2cb04cdc56c97 Content-Type: text/plain; charset=ISO-8859-1 As a reminder, I was trying to organize a CLUE WG dinner on Wed. nite. At this time, there are only 3 responses, which is okay, but I was thinking more folks might be interested. I need to know by 7pm today so I can make an appropriate registration. If I can, I'll try to book here: http://www.tedsmontanagrill.com/tmg001.html Otherwise, it will be Legal Seafood. So, you don't have to read so much, here's the link: http://www.doodle.com/7q2ipk6nvkezk8y3 Thanks, Mary. On Wed, Oct 31, 2012 at 11:01 AM, Mary Barnes wrote: > Hi all, > > I thought it would be good as usual for us to have a CLUE informal dinner > at this IETF meeting. Right now, Wednesday evening is the only evening I > have open. I know that conflicts with a certain company's regular mafia > dinner, but I don't think that eliminates too many people. > > If folks could please respond no later than 5pm on Nov 4th, so I can get > an appropriate reservation. Unless I find another restaurant or someone > has a suggestion that is more exciting, I will plan on Legal Seafoods (I'm > sure I can tolerate 3 meals in one week there ;) > > Mary. > > > ---------- Forwarded message ---------- > From: Doodle > Date: Wed, Oct 31, 2012 at 10:56 AM > Subject: Doodle: Link for poll "CLUE WG dinner" > To: mary.ietf.barnes@gmail.com > > > You have initiated a poll "CLUE WG dinner" at Doodle. The link to your > poll is: > > http://www.doodle.com/7q2ipk6nvkezk8y3 > > Share this link with all those who should cast their votes. Do not forget > to cast your vote, too. > (If you did not initiate this poll, somebody must accidentally have used > your e-mail address; simply ignore this e-mail, please.) > > --e89a8f234665b2d2cb04cdc56c97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a reminder, I was trying to organize a CLUE WG dinner on Wed. nite. =A0A= t this time, there are only 3 responses, which is okay, but I was thinking = more folks might be interested. =A0I need to know by 7pm today so I can mak= e an appropriate registration. =A0If I can, I'll try to book here:
Otherwise, it will be Legal Sea= food.

So, you don't have to read so much, = here's the link:

Thanks,
Mary= .


On Wed= , Oct 31, 2012 at 11:01 AM, Mary Barnes <mary.ietf.barnes@gmail.c= om> wrote:
Hi all,

I thought it woul= d be good as usual for us to have a CLUE informal dinner at this IETF meeti= ng. =A0Right now, Wednesday evening is the only evening I have open. =A0I k= now that conflicts with a certain company's regular mafia dinner, but I= don't think that eliminates too many people.=A0

If folks could please respond no later than 5pm on Nov = 4th, so I can get an appropriate reservation. =A0Unless I find another rest= aurant or someone has a suggestion that is more exciting, I will plan on Le= gal Seafoods (I'm sure I can tolerate 3 meals in one week there ;)=A0

Mary.=A0


---------- Forwarded message ----------
From: Doodle <mailer@doodle.com>
Date: Wed, Oct 31, 2012 at 10:56 AM
Subject: Doodle: Link for poll "= ;CLUE WG dinner"
To: mary.ietf.barnes@gmail.com


You have initia= ted a poll "CLUE WG dinner" at Doodle. The link to your poll is:<= br>
http:/= /www.doodle.com/7q2ipk6nvkezk8y3

Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too.
(If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.)


--e89a8f234665b2d2cb04cdc56c97-- From pkyzivat@alum.mit.edu Mon Nov 5 12:42: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 BAC4F21F865E for ; Mon, 5 Nov 2012 12:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 xjDKECJfvLCR for ; Mon, 5 Nov 2012 12:42:41 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 37F6121F84AB for ; Mon, 5 Nov 2012 12:42:41 -0800 (PST) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta03.emeryville.ca.mail.comcast.net with comcast id Ksiz1k00L17UAYkA3wigj0; Mon, 05 Nov 2012 20:42:40 +0000 Received: from dhcp-16c4.meeting.ietf.org ([IPv6:2001:df8:0:16:fc58:84ca:9c09:f77a]) by omta13.emeryville.ca.mail.comcast.net with comcast id Kwig1k0083U80KV8Zwig0r; Mon, 05 Nov 2012 20:42:40 +0000 Message-ID: <50982520.6010204@alum.mit.edu> Date: Mon, 05 Nov 2012 15:44:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <1784642497.12892.1351698965567.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Doodle: Link for poll "CLUE WG dinner" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2012 20:42:41 -0000 On 11/5/12 3:35 PM, Mary Barnes wrote: > As a reminder, I was trying to organize a CLUE WG dinner on Wed. nite. > At this time, there are only 3 responses, which is okay, but I was > thinking more folks might be interested. I need to know by 7pm today so > I can make an appropriate registration. If I can, I'll try to book here: > http://www.tedsmontanagrill.com/tmg001.html > Otherwise, it will be Legal Seafood. > > So, you don't have to read so much, here's the link: > http://www.doodle.com/7q2ipk6nvkezk8y3 Ah! I was signed up already. But Teds is better for us carnivores. :-) Thanks, Paul > Thanks, > Mary. > > > On Wed, Oct 31, 2012 at 11:01 AM, Mary Barnes > > wrote: > > Hi all, > > I thought it would be good as usual for us to have a CLUE informal > dinner at this IETF meeting. Right now, Wednesday evening is the > only evening I have open. I know that conflicts with a certain > company's regular mafia dinner, but I don't think that eliminates > too many people. > > If folks could please respond no later than 5pm on Nov 4th, so I can > get an appropriate reservation. Unless I find another restaurant or > someone has a suggestion that is more exciting, I will plan on Legal > Seafoods (I'm sure I can tolerate 3 meals in one week there ;) > > Mary. > > > ---------- Forwarded message ---------- > From: *Doodle* > > Date: Wed, Oct 31, 2012 at 10:56 AM > Subject: Doodle: Link for poll "CLUE WG dinner" > To: mary.ietf.barnes@gmail.com > > > You have initiated a poll "CLUE WG dinner" at Doodle. The link to > your poll is: > > http://www.doodle.com/7q2ipk6nvkezk8y3 > > Share this link with all those who should cast their votes. Do not > forget to cast your vote, too. > (If you did not initiate this poll, somebody must accidentally have > used your e-mail address; simply ignore this e-mail, please.) > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Nov 5 12:45: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 4DA2821F86D3 for ; Mon, 5 Nov 2012 12:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LqfsMYMkMqe for ; Mon, 5 Nov 2012 12:45:12 -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 7CE9B21F86F3 for ; Mon, 5 Nov 2012 12:45:08 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so4805866lbo.31 for ; Mon, 05 Nov 2012 12:45:07 -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=ltDwStKcwVKiZK9TCqBbuRD4xpE2s/mcTYzOP8gjhN8=; b=CKiVQTxTNp6opfLnHIw5VavvIlXG5ERcHp3djJvjezMNlL1uQW3J/EBXBgQRg1rKHU 6qxaZFUfJHVpg1desv9nWZ7YhsY0lkZtEoWAYEHdXgvPMPj3Z2TdCApul6jhSNlqzb4S yI3JNDMoCJwDg/MEyDXpBm5CR73r2U2kZiySRcMeP/Jk8eCgK2kfHFiTpZZaMXrLU3hC lxzAfuW6K8bl0r6f7dwpM0pypZcwDsZt5Xv2UEhbLNFfn07k5p1bCSxEEmZOFVOGijbe P38nEYy1zHgQHtlvEh9nhjypTGeVjNlbZFwKCW1v5/VrRvYy47HiCloZudfNtxjB4ksW E4OQ== MIME-Version: 1.0 Received: by 10.112.50.106 with SMTP id b10mr4461351lbo.122.1352148307405; Mon, 05 Nov 2012 12:45:07 -0800 (PST) Received: by 10.114.69.139 with HTTP; Mon, 5 Nov 2012 12:45:07 -0800 (PST) In-Reply-To: <50982520.6010204@alum.mit.edu> References: <1784642497.12892.1351698965567.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <50982520.6010204@alum.mit.edu> Date: Mon, 5 Nov 2012 14:45:07 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d0401fe598bebb804cdc58f5f Cc: CLUE Subject: Re: [clue] Doodle: Link for poll "CLUE WG dinner" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2012 20:45:13 -0000 --f46d0401fe598bebb804cdc58f5f Content-Type: text/plain; charset=ISO-8859-1 They also have a GF menu, so I'm good. And, they have a few veggie items - meal size salads and veggie burger. On Mon, Nov 5, 2012 at 2:44 PM, Paul Kyzivat wrote: > On 11/5/12 3:35 PM, Mary Barnes wrote: > >> As a reminder, I was trying to organize a CLUE WG dinner on Wed. nite. >> At this time, there are only 3 responses, which is okay, but I was >> thinking more folks might be interested. I need to know by 7pm today so >> I can make an appropriate registration. If I can, I'll try to book here: >> http://www.tedsmontanagrill.**com/tmg001.html >> Otherwise, it will be Legal Seafood. >> >> So, you don't have to read so much, here's the link: >> http://www.doodle.com/**7q2ipk6nvkezk8y3 >> > > Ah! I was signed up already. But Teds is better for us carnivores. :-) > > Thanks, > Paul > > Thanks, >> Mary. >> >> >> On Wed, Oct 31, 2012 at 11:01 AM, Mary Barnes >> >> >> wrote: >> >> Hi all, >> >> I thought it would be good as usual for us to have a CLUE informal >> dinner at this IETF meeting. Right now, Wednesday evening is the >> only evening I have open. I know that conflicts with a certain >> company's regular mafia dinner, but I don't think that eliminates >> too many people. >> >> If folks could please respond no later than 5pm on Nov 4th, so I can >> get an appropriate reservation. Unless I find another restaurant or >> someone has a suggestion that is more exciting, I will plan on Legal >> Seafoods (I'm sure I can tolerate 3 meals in one week there ;) >> >> Mary. >> >> >> ---------- Forwarded message ---------- >> From: *Doodle* > >> Date: Wed, Oct 31, 2012 at 10:56 AM >> Subject: Doodle: Link for poll "CLUE WG dinner" >> To: mary.ietf.barnes@gmail.com >> > >> >> >> You have initiated a poll "CLUE WG dinner" at Doodle. The link to >> your poll is: >> >> http://www.doodle.com/**7q2ipk6nvkezk8y3 >> >> Share this link with all those who should cast their votes. Do not >> forget to cast your vote, too. >> (If you did not initiate this poll, somebody must accidentally have >> used your e-mail address; simply ignore this e-mail, please.) >> >> >> >> >> ______________________________**_________________ >> 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 > --f46d0401fe598bebb804cdc58f5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable They also have a GF menu, so I'm good. =A0 And, they have a few veggie = items - meal size salads and veggie burger.

<= br>
On Mon, Nov 5, 2012 at 2:44 PM, Paul Kyzivat = <pkyzivat@alum.mit.edu> wrote:
On 11/5/12 3:35 PM, Mary B= arnes wrote:
As a reminder, I was trying to organize a CLUE WG dinner on Wed. nite.
=A0 At this time, there are only 3 responses, which is okay, but I was
thinking more folks might be interested. =A0I need to know by 7pm today so<= br> I can make an appropriate registration. =A0If I can, I'll try to book h= ere:
h= ttp://www.tedsmontanagrill.com/tmg001.html
Otherwise, it will be Legal Seafood.

So, you don't have to read so much, here's the link:
http:/= /www.doodle.com/7q2ipk6nvkezk8y3

Ah! I was signed up already. But Teds is better for us carnivores. :-)

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

Thanks,
Mary.


On Wed, Oct 31, 2012 at 11:01 AM, Mary Barnes
<mary.ie= tf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com>> wrote= :

=A0 =A0 Hi all,

=A0 =A0 I thought it would be good as usual for us to have a CLUE informal<= br> =A0 =A0 dinner at this IETF meeting. =A0Right now, Wednesday evening is the=
=A0 =A0 only evening I have open. =A0I know that conflicts with a certain =A0 =A0 company's regular mafia dinner, but I don't think that elim= inates
=A0 =A0 too many people.

=A0 =A0 If folks could please respond no later than 5pm on Nov 4th, so I ca= n
=A0 =A0 get an appropriate reservation. =A0Unless I find another restaurant= or
=A0 =A0 someone has a suggestion that is more exciting, I will plan on Lega= l
=A0 =A0 Seafoods (I'm sure I can tolerate 3 meals in one week there ;)<= br>
=A0 =A0 Mary.


=A0 =A0 ---------- Forwarded message ----------
=A0 =A0 From: *Doodle* <mailer@doodle.com <mailto:mailer@doodle.com>>
=A0 =A0 Date: Wed, Oct 31, 2012 at 10:56 AM
=A0 =A0 Subject: Doodle: Link for poll "CLUE WG dinner"
=
=A0 =A0 To: mary.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com>

=A0 =A0 You have initiated a poll "CLUE WG dinner" at Doodle. The= link to
=A0 =A0 your poll is:

=A0 =A0 http://www.doodle.com/7q2ipk6nvkezk8y3

=A0 =A0 Share this link with all those who should cast their votes. Do not<= br> =A0 =A0 forget to cast your vote, too.
=A0 =A0 (If you did not initiate this poll, somebody must accidentally have=
=A0 =A0 used your e-mail address; simply ignore this e-mail, please.)




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


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

--f46d0401fe598bebb804cdc58f5f-- From pkyzivat@alum.mit.edu Mon Nov 5 12:54: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 E3C3121F8674 for ; Mon, 5 Nov 2012 12:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 miFeqVc1B1s3 for ; Mon, 5 Nov 2012 12:54:01 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 5082621F862E for ; Mon, 5 Nov 2012 12:54:01 -0800 (PST) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta01.emeryville.ca.mail.comcast.net with comcast id KoMw1k0060lTkoCA1wu1XM; Mon, 05 Nov 2012 20:54:01 +0000 Received: from dhcp-16c4.meeting.ietf.org ([130.129.22.196]) by omta04.emeryville.ca.mail.comcast.net with comcast id Kwrp1k00l4Dqbui8QwrsLl; Mon, 05 Nov 2012 20:51:58 +0000 Message-ID: <50982746.2@alum.mit.edu> Date: Mon, 05 Nov 2012 15:53:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mary Barnes References: <1784642497.12892.1351698965567.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <50982520.6010204@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Doodle: Link for poll "CLUE WG dinner" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2012 20:54:02 -0000 On 11/5/12 3:45 PM, Mary Barnes wrote: > They also have a GF menu, so I'm good. And, they have a few veggie > items - meal size salads and veggie burger. And a bison burger from Ted's ranch! :-) > On Mon, Nov 5, 2012 at 2:44 PM, Paul Kyzivat > wrote: > > On 11/5/12 3:35 PM, Mary Barnes wrote: > > As a reminder, I was trying to organize a CLUE WG dinner on Wed. > nite. > At this time, there are only 3 responses, which is okay, but > I was > thinking more folks might be interested. I need to know by 7pm > today so > I can make an appropriate registration. If I can, I'll try to > book here: > http://www.tedsmontanagrill.__com/tmg001.html > > Otherwise, it will be Legal Seafood. > > So, you don't have to read so much, here's the link: > http://www.doodle.com/__7q2ipk6nvkezk8y3 > > > > Ah! I was signed up already. But Teds is better for us carnivores. :-) > > Thanks, > Paul > > Thanks, > Mary. > > > On Wed, Oct 31, 2012 at 11:01 AM, Mary Barnes > > >> wrote: > > Hi all, > > I thought it would be good as usual for us to have a CLUE > informal > dinner at this IETF meeting. Right now, Wednesday evening > is the > only evening I have open. I know that conflicts with a certain > company's regular mafia dinner, but I don't think that > eliminates > too many people. > > If folks could please respond no later than 5pm on Nov 4th, > so I can > get an appropriate reservation. Unless I find another > restaurant or > someone has a suggestion that is more exciting, I will plan > on Legal > Seafoods (I'm sure I can tolerate 3 meals in one week there ;) > > Mary. > > > ---------- Forwarded message ---------- > From: *Doodle* >> > Date: Wed, Oct 31, 2012 at 10:56 AM > Subject: Doodle: Link for poll "CLUE WG dinner" > To: mary.ietf.barnes@gmail.com > > > > > > You have initiated a poll "CLUE WG dinner" at Doodle. The > link to > your poll is: > > http://www.doodle.com/__7q2ipk6nvkezk8y3 > > > Share this link with all those who should cast their votes. > Do not > forget to cast your vote, too. > (If you did not initiate this poll, somebody must > accidentally have > used your e-mail address; simply ignore this e-mail, please.) > > > > > _________________________________________________ > 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 Nov 5 13:35: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 B52F221F8835 for ; Mon, 5 Nov 2012 13:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 69yw+dPhht9s for ; Mon, 5 Nov 2012 13:35:54 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 10BA321F8836 for ; Mon, 5 Nov 2012 13:35:53 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-05-509831380179 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 93.F2.06323.83138905; Mon, 5 Nov 2012 22:35:52 +0100 (CET) Received: from ESESSHC011.ericsson.se (153.88.183.51) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 5 Nov 2012 22:35:52 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 22:35:52 +0100 From: Christer Holmberg To: 'Mary Barnes' , CLUE Thread-Topic: [clue] Doodle: Link for poll "CLUE WG dinner" Thread-Index: AQHNt4ER4RNXSzwO2ECWi7fcHS1dppfbqmEAgAAhi0A= Date: Mon, 5 Nov 2012 21:35:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B025AF5@ESESSMB209.ericsson.se> References: <1784642497.12892.1351698965567.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B025AF5ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvja6F4YwAg21LjC32n7rMbPF5/35m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj1tfzrAUbjSpOf5nF2sB4SquLkZNDQsBE YuLDFjYIW0ziwr31QDYXh5DASUaJB9ePM4IkhAR2MEp0rpeBSCwGshdsYuli5OBgE7CQ6P6n DVIjIuAiMfXgZLBBwgJWEtdmHGCDiFtLHJ5/lh3CtpI48GsaM4jNIqAi0XmgDczmFfCWmDfx MNTiJ4wSOy9vB2vmFAiU2PN+H5jNCHTd91NrmEBsZgFxiVtP5jNBXC0gsWTPeWYIW1Ti5eN/ rBC2osTOs+3MEPX5EvMfXmOBWCYocXLmExaIx7QlWhZPYJ/AKDYLydhZSFpmIWmBiOtILNj9 iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxjZcxMzc9LLzTcxAqPt4JbfBjsYN90XO8QozcGiJM6r p7rfX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMj1wyVF/drNV62W3VN/usgV6pbfVPFR0Tk fxRnWtbeSOFWyXWyepJyYQdzPUp2Jm0WcgjykxSWM/d4NKml7/+CvPBrB6sXrHo0c23fq4ia 9ew/eKpSb53eW7gtJGhGTU5fudPrmdsnz3shtLNbhPevm4rU46otLzK/rL2WtGqCTrVQ0TfG mhNKLMUZiYZazEXFiQDw71y6hAIAAA== Subject: Re: [clue] Doodle: Link for poll "CLUE WG dinner" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2012 21:35:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B025AF5ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Legal seafood would be better for me, because it's next to my hotel :) ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: 5. marraskuuta 2012 22:35 To: CLUE Subject: Re: [clue] Doodle: Link for poll "CLUE WG dinner" As a reminder, I was trying to organize a CLUE WG dinner on Wed. nite. At = this time, there are only 3 responses, which is okay, but I was thinking mo= re folks might be interested. I need to know by 7pm today so I can make an= appropriate registration. If I can, I'll try to book here: http://www.tedsmontanagrill.com/tmg001.html Otherwise, it will be Legal Seafood. So, you don't have to read so much, here's the link: http://www.doodle.com/7q2ipk6nvkezk8y3 Thanks, Mary. On Wed, Oct 31, 2012 at 11:01 AM, Mary Barnes > wrote: Hi all, I thought it would be good as usual for us to have a CLUE informal dinner a= t this IETF meeting. Right now, Wednesday evening is the only evening I ha= ve open. I know that conflicts with a certain company's regular mafia dinn= er, but I don't think that eliminates too many people. If folks could please respond no later than 5pm on Nov 4th, so I can get an= appropriate reservation. Unless I find another restaurant or someone has = a suggestion that is more exciting, I will plan on Legal Seafoods (I'm sure= I can tolerate 3 meals in one week there ;) Mary. ---------- Forwarded message ---------- From: Doodle > Date: Wed, Oct 31, 2012 at 10:56 AM Subject: Doodle: Link for poll "CLUE WG dinner" To: mary.ietf.barnes@gmail.com You have initiated a poll "CLUE WG dinner" at Doodle. The link to your poll= is: http://www.doodle.com/7q2ipk6nvkezk8y3 Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.) --_000_7594FB04B1934943A5C02806D1A2204B025AF5ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Legal seafood would be better for= me, because it's next to my hotel :)

From: clue-bounces@ietf.org [mailto= :clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 5. marraskuuta 2012 22:35
To: CLUE
Subject: Re: [clue] Doodle: Link for poll "CLUE WG dinner"=

As a reminder, I was trying to organize a CLUE WG dinner on Wed. nite. &nbs= p;At this time, there are only 3 responses, which is okay, but I was thinki= ng more folks might be interested.  I need to know by 7pm today so I c= an make an appropriate registration.  If I can, I'll try to book here:
Otherwise, it will be Legal Seafood.

So, you don't have to read so much, here's the link:

Thanks,
Mary.


On Wed, Oct 31, 2012 at 11:01 AM, Mary Barnes <mary.ie= tf.barnes@gmail.com> wrote:
Hi all,

I thought it would be good as usual for us to have a CLUE informal din= ner at this IETF meeting.  Right now, Wednesday evening is the only ev= ening I have open.  I know that conflicts with a certain company's reg= ular mafia dinner, but I don't think that eliminates too many people. 

If folks could please respond no later than 5pm on Nov 4th, so I can g= et an appropriate reservation.  Unless I find another restaurant or so= meone has a suggestion that is more exciting, I will plan on Legal Seafoods= (I'm sure I can tolerate 3 meals in one week there ;) 
Mary. 


---------- Forwarded message ----------
From: Doodle <mailer@doodle.com><= /span>
Date: Wed, Oct 31, 2012 at 10:56 AM
Subject: Doodle: Link for poll "CLUE WG dinner"
To: mary.ie= tf.barnes@gmail.com


You have initiated a poll "CLUE WG dinner" at Doodle. The link to= your poll is:

http:/= /www.doodle.com/7q2ipk6nvkezk8y3

Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too.
(If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.)


--_000_7594FB04B1934943A5C02806D1A2204B025AF5ESESSMB209ericsso_-- From prvs=3656e1871a=aallen@rim.com Mon Nov 5 15:08: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 CBF9221F8479 for ; Mon, 5 Nov 2012 15:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 YdiTNvT5sVVF for ; Mon, 5 Nov 2012 15:08:19 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9343121F8471 for ; Mon, 5 Nov 2012 15:08:18 -0800 (PST) X-AuditID: 0a412830-b7f0c6d0000004c1-3b-509846d73029 Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 0A.86.01217.7D648905; Mon, 5 Nov 2012 17:08:07 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 17:08:06 -0600 From: Andrew Allen To: "christer.holmberg@ericsson.com" , "mary.ietf.barnes@gmail.com" , "clue@ietf.org" Thread-Topic: [clue] Doodle: Link for poll "CLUE WG dinner" Thread-Index: AQHNu6ppv4JsPDnNN0aEduHnO9MUwg== Date: Mon, 5 Nov 2012 23:08:05 +0000 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B025AF5@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338CB9FC0XMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBKsWRmVeSWpSXmKPExsXC5ZyvrXvdbUaAQftNWYsLMw8zWuw/dZnZ 4vP+/cwOzB6/vl5l89g56y67x5IlP5kCmKMaGG2SEkvKgjPT8/TtbBLz8vJLEktSFVJSi5Nt lXxS0xNzFAKKMssSkysVXDKLk3MSM3NTi5QUMlNslUyUFApyEpNTc1PzSmyVEgsKUvNSlOy4 FDCADVBZZp5Cal5yfkpmXrqtkmewv66FhamlrqGSnW5CJ0/Gql8nmQp2eFfc7D3M3sC4xrOL kZNDQsBEYsPCHUwQtpjEhXvr2boYuTiEBNqYJJq69kE5mxglFvatYQGpYhNQllj+ewYjiC0i sJRRYscfThBbWMBKovX2VSaIuLXE4fln2SFsPYkzxw6B1bMIqEic/H2RGcTmFfCQ2PNzG9hM TgEfiTm/NoDVMwrISuw+ex1sDrOAuMStJ/OhrhOQWLLnPDOELSrx8vE/VghbUeLv3u+sEPX5 ElMXzmeFmC8ocXLmE5YJjMKzkIyahaRsFpKyWYwcQHFNifW79CFKFCWmdD9kh7A1JFrnzGVH Fl/AyL6KUTA3o9jAzDA5L1mvKDNXLy+1ZBMjKHU4ahjsYHz/3uIQowAHoxIPb5rZjAAh1sSy 4srcQ4wSHMxKIrwcd6YHCPGmJFZWpRblxxeV5qQWH2IMAgbQRGYp7uR8YFrLK4k3NjAgkqMk zvtZZEKAkEA6MF1lp6YWpBbBDGXi4ARZyiUlUgxMOqlFiaUlGfGg1BhfDEyOUg2MkzoZSp55 19+3NLi7hH+faf8u1+tJrsy5EhW+LJMbmKzkl/60P/SfKTPaT3DJ7DApHg7Ja3c3HjCVncis zvHIT92jLv+38x0GgdSL+wSO6dw+vOuH8q+5E86GC39K/SByMWfq+kkJt/lbZGpdbhh6qZ0S +JY9c8mSE+nLOcsiPbiXh79a9MpeiaU4I9FQi7moOBEAGWyvTGsDAAA= Subject: Re: [clue] Doodle: Link for poll "CLUE WG dinner" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2012 23:08:20 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338CB9FC0XMB104ADSrimnet_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 Q291bnQgbWUgaW4NCg0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0bzpjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDA1LCAy MDEyIDAzOjM1IFBNIENlbnRyYWwgU3RhbmRhcmQgVGltZQ0KVG86ICdNYXJ5IEJhcm5lcycg PG1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPjsgQ0xVRSA8Y2x1ZUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbY2x1ZV0gRG9vZGxlOiBMaW5rIGZvciBwb2xsICJDTFVFIFdHIGRpbm5l ciINCg0KTGVnYWwgc2VhZm9vZCB3b3VsZCBiZSBiZXR0ZXIgZm9yIG1lLCBiZWNhdXNlIGl0 J3MgbmV4dCB0byBteSBob3RlbCA6KQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2x1ZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyeSBCYXJuZXMNClNlbnQ6IDUuIG1hcnJhc2t1 dXRhIDIwMTIgMjI6MzUNClRvOiBDTFVFDQpTdWJqZWN0OiBSZTogW2NsdWVdIERvb2RsZTog TGluayBmb3IgcG9sbCAiQ0xVRSBXRyBkaW5uZXIiDQoNCkFzIGEgcmVtaW5kZXIsIEkgd2Fz IHRyeWluZyB0byBvcmdhbml6ZSBhIENMVUUgV0cgZGlubmVyIG9uIFdlZC4gbml0ZS4gIEF0 IHRoaXMgdGltZSwgdGhlcmUgYXJlIG9ubHkgMyByZXNwb25zZXMsIHdoaWNoIGlzIG9rYXks IGJ1dCBJIHdhcyB0aGlua2luZyBtb3JlIGZvbGtzIG1pZ2h0IGJlIGludGVyZXN0ZWQuICBJ IG5lZWQgdG8ga25vdyBieSA3cG0gdG9kYXkgc28gSSBjYW4gbWFrZSBhbiBhcHByb3ByaWF0 ZSByZWdpc3RyYXRpb24uICBJZiBJIGNhbiwgSSdsbCB0cnkgdG8gYm9vayBoZXJlOg0KaHR0 cDovL3d3dy50ZWRzbW9udGFuYWdyaWxsLmNvbS90bWcwMDEuaHRtbA0KT3RoZXJ3aXNlLCBp dCB3aWxsIGJlIExlZ2FsIFNlYWZvb2QuDQoNClNvLCB5b3UgZG9uJ3QgaGF2ZSB0byByZWFk IHNvIG11Y2gsIGhlcmUncyB0aGUgbGluazoNCmh0dHA6Ly93d3cuZG9vZGxlLmNvbS83cTJp cGs2bnZrZXprOHkzDQoNClRoYW5rcywNCk1hcnkuDQoNCg0KT24gV2VkLCBPY3QgMzEsIDIw MTIgYXQgMTE6MDEgQU0sIE1hcnkgQmFybmVzIDxtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNv bTxtYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20+PiB3cm90ZToNCkhpIGFsbCwN Cg0KSSB0aG91Z2h0IGl0IHdvdWxkIGJlIGdvb2QgYXMgdXN1YWwgZm9yIHVzIHRvIGhhdmUg YSBDTFVFIGluZm9ybWFsIGRpbm5lciBhdCB0aGlzIElFVEYgbWVldGluZy4gIFJpZ2h0IG5v dywgV2VkbmVzZGF5IGV2ZW5pbmcgaXMgdGhlIG9ubHkgZXZlbmluZyBJIGhhdmUgb3Blbi4g IEkga25vdyB0aGF0IGNvbmZsaWN0cyB3aXRoIGEgY2VydGFpbiBjb21wYW55J3MgcmVndWxh ciBtYWZpYSBkaW5uZXIsIGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgZWxpbWluYXRlcyB0b28g bWFueSBwZW9wbGUuDQoNCklmIGZvbGtzIGNvdWxkIHBsZWFzZSByZXNwb25kIG5vIGxhdGVy IHRoYW4gNXBtIG9uIE5vdiA0dGgsIHNvIEkgY2FuIGdldCBhbiBhcHByb3ByaWF0ZSByZXNl cnZhdGlvbi4gIFVubGVzcyBJIGZpbmQgYW5vdGhlciByZXN0YXVyYW50IG9yIHNvbWVvbmUg aGFzIGEgc3VnZ2VzdGlvbiB0aGF0IGlzIG1vcmUgZXhjaXRpbmcsIEkgd2lsbCBwbGFuIG9u IExlZ2FsIFNlYWZvb2RzIChJJ20gc3VyZSBJIGNhbiB0b2xlcmF0ZSAzIG1lYWxzIGluIG9u ZSB3ZWVrIHRoZXJlIDspDQoNCk1hcnkuDQoNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVz c2FnZSAtLS0tLS0tLS0tDQpGcm9tOiBEb29kbGUgPG1haWxlckBkb29kbGUuY29tPG1haWx0 bzptYWlsZXJAZG9vZGxlLmNvbT4+DQpEYXRlOiBXZWQsIE9jdCAzMSwgMjAxMiBhdCAxMDo1 NiBBTQ0KU3ViamVjdDogRG9vZGxlOiBMaW5rIGZvciBwb2xsICJDTFVFIFdHIGRpbm5lciIN ClRvOiBtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbTxtYWlsdG86bWFyeS5pZXRmLmJhcm5l c0BnbWFpbC5jb20+DQoNCg0KWW91IGhhdmUgaW5pdGlhdGVkIGEgcG9sbCAiQ0xVRSBXRyBk aW5uZXIiIGF0IERvb2RsZS4gVGhlIGxpbmsgdG8geW91ciBwb2xsIGlzOg0KDQpodHRwOi8v d3d3LmRvb2RsZS5jb20vN3EyaXBrNm52a2V6azh5Mw0KDQpTaGFyZSB0aGlzIGxpbmsgd2l0 aCBhbGwgdGhvc2Ugd2hvIHNob3VsZCBjYXN0IHRoZWlyIHZvdGVzLiBEbyBub3QgZm9yZ2V0 IHRvIGNhc3QgeW91ciB2b3RlLCB0b28uDQooSWYgeW91IGRpZCBub3QgaW5pdGlhdGUgdGhp cyBwb2xsLCBzb21lYm9keSBtdXN0IGFjY2lkZW50YWxseSBoYXZlIHVzZWQgeW91ciBlLW1h aWwgYWRkcmVzczsgc2ltcGx5IGlnbm9yZSB0aGlzIGUtbWFpbCwgcGxlYXNlLikNCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0 YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmls ZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29s aWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25z dGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1h dGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHBy b2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVy cm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9u LCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBi eSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1 bmxhd2Z1bC4NCg== --_000_BBF5DDFE515C3946BC18D733B20DAD2338CB9FC0XMB104ADSrimnet_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5 cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBjb250ZW50 PSJNU0hUTUwgNi4wMC42MDAwLjE3MTE0IiBuYW1lPSJHRU5FUkFUT1IiPg0KPC9oZWFkPg0K PGJvZHk+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Q291bnQgbWUgaW48L2ZvbnQ+PGJyPg0KJm5ic3A7PGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxiPkZyb208L2I+ OiBDaHJpc3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbV0NCjxicj4NCjxiPlNlbnQ8L2I+OiBNb25kYXksIE5vdmVtYmVyIDA1LCAyMDEyIDAz OjM1IFBNIENlbnRyYWwgU3RhbmRhcmQgVGltZTxicj4NCjxiPlRvPC9iPjogJ01hcnkgQmFy bmVzJyAmbHQ7bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20mZ3Q7OyBDTFVFICZsdDtjbHVl QGlldGYub3JnJmd0OyA8YnI+DQo8Yj5TdWJqZWN0PC9iPjogUmU6IFtjbHVlXSBEb29kbGU6 IExpbmsgZm9yIHBvbGwgJnF1b3Q7Q0xVRSBXRyBkaW5uZXImcXVvdDsgPGJyPg0KPC9mb250 PiZuYnNwOzxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPjxzcGFu IGNsYXNzPSI4NjUyNDM1MjEtMDUxMTIwMTIiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0i IzAwMDBmZiIgc2l6ZT0iMiI+TGVnYWwgc2VhZm9vZCB3b3VsZCBiZSBiZXR0ZXIgZm9yIG1l LCBiZWNhdXNlIGl0J3MgbmV4dCB0byBteSBob3RlbCA6KTwvZm9udD48L3NwYW4+PC9kaXY+ DQo8YnI+DQo8ZGl2IGNsYXNzPSJPdXRsb29rTWVzc2FnZUhlYWRlciIgbGFuZz0iZW4tdXMi IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjxmb250IGZh Y2U9IlRhaG9tYSIgc2l6ZT0iMiI+PGI+RnJvbTo8L2I+IGNsdWUtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ TWFyeSBCYXJuZXM8YnI+DQo8Yj5TZW50OjwvYj4gNS4gbWFycmFza3V1dGEgMjAxMiAyMjoz NTxicj4NCjxiPlRvOjwvYj4gQ0xVRTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2NsdWVd IERvb2RsZTogTGluayBmb3IgcG9sbCAmcXVvdDtDTFVFIFdHIGRpbm5lciZxdW90Ozxicj4N CjwvZm9udD48YnI+DQo8L2Rpdj4NCjxkaXY+PC9kaXY+DQpBcyBhIHJlbWluZGVyLCBJIHdh cyB0cnlpbmcgdG8gb3JnYW5pemUgYSBDTFVFIFdHIGRpbm5lciBvbiBXZWQuIG5pdGUuICZu YnNwO0F0IHRoaXMgdGltZSwgdGhlcmUgYXJlIG9ubHkgMyByZXNwb25zZXMsIHdoaWNoIGlz IG9rYXksIGJ1dCBJIHdhcyB0aGlua2luZyBtb3JlIGZvbGtzIG1pZ2h0IGJlIGludGVyZXN0 ZWQuICZuYnNwO0kgbmVlZCB0byBrbm93IGJ5IDdwbSB0b2RheSBzbyBJIGNhbiBtYWtlIGFu IGFwcHJvcHJpYXRlIHJlZ2lzdHJhdGlvbi4gJm5ic3A7SWYgSQ0KIGNhbiwgSSdsbCB0cnkg dG8gYm9vayBoZXJlOjxicj4NCjxkaXY+PGEgaHJlZj0iaHR0cDovL3d3dy50ZWRzbW9udGFu YWdyaWxsLmNvbS90bWcwMDEuaHRtbCI+aHR0cDovL3d3dy50ZWRzbW9udGFuYWdyaWxsLmNv bS90bWcwMDEuaHRtbDwvYT48L2Rpdj4NCjxkaXY+T3RoZXJ3aXNlLCBpdCB3aWxsIGJlIExl Z2FsIFNlYWZvb2QuPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Tbywg eW91IGRvbid0IGhhdmUgdG8gcmVhZCBzbyBtdWNoLCBoZXJlJ3MgdGhlIGxpbms6PC9kaXY+ DQo8ZGl2PjxhIGhyZWY9Imh0dHA6Ly93d3cuZG9vZGxlLmNvbS83cTJpcGs2bnZrZXprOHkz Ij5odHRwOi8vd3d3LmRvb2RsZS5jb20vN3EyaXBrNm52a2V6azh5MzwvYT48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+TWFyeS48 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+T24gV2VkLCBPY3QgMzEsIDIwMTIgYXQgMTE6MDEgQU0sIE1hcnkg QmFybmVzIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86bWFyeS5pZXRm LmJhcm5lc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ5LmlldGYuYmFybmVzQGdt YWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4 IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4NCkhpIGFsbCwNCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgdGhvdWdodCBpdCB3b3VsZCBiZSBnb29kIGFzIHVz dWFsIGZvciB1cyB0byBoYXZlIGEgQ0xVRSBpbmZvcm1hbCBkaW5uZXIgYXQgdGhpcyBJRVRG IG1lZXRpbmcuICZuYnNwO1JpZ2h0IG5vdywgV2VkbmVzZGF5IGV2ZW5pbmcgaXMgdGhlIG9u bHkgZXZlbmluZyBJIGhhdmUgb3Blbi4gJm5ic3A7SSBrbm93IHRoYXQgY29uZmxpY3RzIHdp dGggYSBjZXJ0YWluIGNvbXBhbnkncyByZWd1bGFyIG1hZmlhIGRpbm5lciwgYnV0IEkgZG9u J3QgdGhpbmsgdGhhdA0KIGVsaW1pbmF0ZXMgdG9vIG1hbnkgcGVvcGxlLiZuYnNwOzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYgZm9sa3MgY291bGQgcGxlYXNlIHJlc3Bv bmQgbm8gbGF0ZXIgdGhhbiA1cG0gb24gTm92IDR0aCwgc28gSSBjYW4gZ2V0IGFuIGFwcHJv cHJpYXRlIHJlc2VydmF0aW9uLiAmbmJzcDtVbmxlc3MgSSBmaW5kIGFub3RoZXIgcmVzdGF1 cmFudCBvciBzb21lb25lIGhhcyBhIHN1Z2dlc3Rpb24gdGhhdCBpcyBtb3JlIGV4Y2l0aW5n LCBJIHdpbGwgcGxhbiBvbiBMZWdhbCBTZWFmb29kcyAoSSdtIHN1cmUgSSBjYW4gdG9sZXJh dGUgMyBtZWFscyBpbg0KIG9uZSB3ZWVrIHRoZXJlIDspJm5ic3A7PC9kaXY+DQo8c3BhbiBj bGFzcz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPC9mb250Pjwvc3Bhbj4NCjxkaXY+PHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQgY29s b3I9IiM4ODg4ODgiPk1hcnkuJm5ic3A7PC9mb250Pjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IGNs YXNzPSJoNSI+PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPi0tLS0tLS0t LS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxicj4NCkZyb206IDxiIGNsYXNzPSJn bWFpbF9zZW5kZXJuYW1lIj5Eb29kbGU8L2I+IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJl Zj0ibWFpbHRvOm1haWxlckBkb29kbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbGVyQGRv b2RsZS5jb208L2E+Jmd0Ozwvc3Bhbj48YnI+DQpEYXRlOiBXZWQsIE9jdCAzMSwgMjAxMiBh dCAxMDo1NiBBTTxicj4NClN1YmplY3Q6IERvb2RsZTogTGluayBmb3IgcG9sbCAmcXVvdDtD TFVFIFdHIGRpbm5lciZxdW90Ozxicj4NClRvOiA8YSBocmVmPSJtYWlsdG86bWFyeS5pZXRm LmJhcm5lc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ5LmlldGYuYmFybmVzQGdt YWlsLmNvbTwvYT48YnI+DQo8YnI+DQo8YnI+DQpZb3UgaGF2ZSBpbml0aWF0ZWQgYSBwb2xs ICZxdW90O0NMVUUgV0cgZGlubmVyJnF1b3Q7IGF0IERvb2RsZS4gVGhlIGxpbmsgdG8geW91 ciBwb2xsIGlzOjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuZG9vZGxlLmNvbS83 cTJpcGs2bnZrZXprOHkzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5kb29kbGUuY29t LzdxMmlwazZudmtlems4eTM8L2E+PGJyPg0KPGJyPg0KU2hhcmUgdGhpcyBsaW5rIHdpdGgg YWxsIHRob3NlIHdobyBzaG91bGQgY2FzdCB0aGVpciB2b3Rlcy4gRG8gbm90IGZvcmdldCB0 byBjYXN0IHlvdXIgdm90ZSwgdG9vLjxicj4NCihJZiB5b3UgZGlkIG5vdCBpbml0aWF0ZSB0 aGlzIHBvbGwsIHNvbWVib2R5IG11c3QgYWNjaWRlbnRhbGx5IGhhdmUgdXNlZCB5b3VyIGUt bWFpbCBhZGRyZXNzOyBzaW1wbHkgaWdub3JlIHRoaXMgZS1tYWlsLCBwbGVhc2UuKTxicj4N CjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnI+DQo8L2Rpdj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpUaGlzIHRyYW5z bWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0 ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxp Y2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlv bi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBs eSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIg c3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0 aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBu b3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BBF5DDFE515C3946BC18D733B20DAD2338CB9FC0XMB104ADSrimnet_-- From apeppere@gmail.com Tue Nov 6 04:01: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 A03D721F8883 for ; Tue, 6 Nov 2012 04:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 3S7tF9WS1vDy for ; Tue, 6 Nov 2012 04:01:12 -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 6F58621F886F for ; Tue, 6 Nov 2012 04:01:12 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so233277qca.31 for ; Tue, 06 Nov 2012 04:01:11 -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=mDNZvflRQlVBJ/Ctf2NTfXc14OxMZUpnWXNSI90UWgI=; b=N4HNjl1UjuBr8K0+rKNvnEI3sNzEn7C2iYbml6qEtPywpyNsiRLtELEnp1m3aSdjku Z4bjrByL//AO5Fvo/ETl49Vg4dRdbdLamVNMYXCHTK0nn11ohovr1Q6UaZjlZuhpxXJl SpzYRSqfd8mGyLsLtYsaSpQHrn0vR7ATy2ZvD2vINa37vHRA7t/h0R6N/Zl4twODgIZc kk95yJbF8lCGPF/V78u3HY0FSbu+VUxzLal6iGGjhYo/D4yf2x8Ptb+O5bqYCqCCuYA7 29cS3A+LHCRzYLjrDctxDUIfIdK0jnbEX7lCYxFlTR+uotXazHl70O9IhA84a31K5DvJ 0dww== MIME-Version: 1.0 Received: by 10.224.189.196 with SMTP id df4mr1186602qab.16.1352203271529; Tue, 06 Nov 2012 04:01:11 -0800 (PST) Received: by 10.49.96.98 with HTTP; Tue, 6 Nov 2012 04:01:11 -0800 (PST) In-Reply-To: <019401cdbb5d$42c71b70$c8555250$@gmail.com> References: <01d301cdb74d$10857940$31906bc0$@gmail.com> <5092A599.4010601@alum.mit.edu> <019401cdbb5d$42c71b70$c8555250$@gmail.com> Date: Tue, 6 Nov 2012 12:01:11 +0000 Message-ID: From: Andy Pepperell To: Roni Even Content-Type: multipart/alternative; boundary=20cf300fafd7a9e56604cdd25bbe Cc: clue@ietf.org Subject: Re: [clue] Do we need the encodings as secified in the framework document - proposal to remove them from the framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 06 Nov 2012 12:01:15 -0000 --20cf300fafd7a9e56604cdd25bbe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Roni, >Can you explain how the encoding works with the dynamic mapping of RTP to Media Captures. I'll have a go... Firstly, I'd say that the dynamic mapping relates to *capture encodings* rather than media captures. You mention the MCU case; I'd say this depends on how you envisage the MCU case operating: If the MCU were transcoding then it would offer separate capture scene entries for 1 capture, 2 capture, 3 capture etc. transcodings of the main scene, and perhaps a capture scene for presentation as well. If the MCU were switching, I'd envisage it offering some number of loudest speaker streams in a "main" capture scene and allowing consumer devices to choose the number they were able to render and display. I myself never saw the multipoint case as involving all individual participants' advertisements being sent out to all other participants - I think MCUs should be performing some sensible aggregation of what participants advertise to them in order to avoid scalability problems. I agree that if you're switching from multiple sources and not transcoding then all of those contributing provider advertisements might contribute to (/ modify) the MCU's provider advertisement that gets sent out, though I don't really see how dynamic RTP vs static RTP is that relevant here (i.e. I think the complexities here are present no matter how the SSRCs etc. are derived). In the dynamic case, the consumer essentially chooses header extension IDs for the capture encodings it requests from the provider, and decodes / renders the media sent to it from the provider. I wonder if we're getting 2 separate topics needlessly entangled here, a) dynamic vs static mapping and b) how a multipoint provider determines its own provider advertisement from multiple participants' such advertisements. For the multipoint case, I'd argue that the MCU's role here would be to distil down the individual other participants' media into sensible capture scenes and capture scene entries that give each consumer a sensible set of media captures to choose from. Regards, Andy On Mon, Nov 5, 2012 at 1:55 PM, Roni Even wrote: > Andy,**** > > Can you explain how the encoding works with the dynamic mapping of RTP to > Media Captures. **** > > Does this mean that the consumer will get advertisements from all the > participants of the multipoint call and will need to calculate the > limitations in each switch and ask for a new configuration since the grou= p > limits may enforce different limitations.**** > > ** ** > > In the static mapping case all this can be achieved using imageattr and > the codec parameters**** > > Roni**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Andy Pepperell > *Sent:* 02 November, 2012 11:20 AM > *To:* Paul Kyzivat > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Do we need the encodings as secified in the > framework document - proposal to remove them from the framework**** > > ** ** > > >Paul:**** > > >*If* this works and satisfies all objectives then it will be a helpful > simplification. But it may be that simplifying things this way excludes > some required behavior.**** > > ** ** > > I certainly agree with Paul's point here... however, with not all that > many of Roni's (as might be expected :) ) - to be specific:**** > > ** ** > > >Roni:**** > > >Each encoding group include a list of individual encodes (audio and /or > video). These provide maximum values that can be used to instantiate a > media stream by the provider.**** > > ** ** > > Yes, I think that's a good summary.**** > > **** > > >Each video individual encodes identified by an encodeID provides maximum > values for BW, compute, resolution and frame rate for H.264. (BTW: the > maxH264Mbps can be computed from the resolution and frame rate as defined > in table 2 making it redundant).**** > > >Each audio encode has only a BW value (no identifier).**** > > ** ** > > Also agreed - apart from the H.264 point I think - a maximum resolution > and a maximum frame rate doesn't necessarily imply a maxMbps - many syste= ms > can encode 1280x720 at some frame rate < 30 *or* some lower resolution at > up to 30fps without necessarily being able to send 720p30, surely?**** > > **** > > **** > > > Roni:**** > > >A media capture is associated with an encoding group !!!!! not an > individual encoding.**** > > ** ** > > That's true, and by design. To re-iterate the original design intent here= , > the idea behind the encoding groups idea was to be able to model 2 common > Telepresence architectures we see today:**** > > 1) a multi-screen endpoint room comprised of multiple endpoints (most > vendors' "3 screen" systems, for instance, tend to be composed of 3 of > their "1 screen" products linked together)**** > > 2) a flexible media generation system such as a software or hardware MCU*= * > ** > > ** ** > > For the "1)" case above, due to real-world constraints such as camera > wiring etc., it seemed to us that a media capture representing, say, the > left camera of 3, would only be able to be encoded by the hardware it was > directly connected to - thus, such a system would use one "encoding group= " > for its left constituent, one for its centre and one for its right.**** > > ** ** > > >Roni:**** > > ** ** > > >The provider can use one of the individual encoding to instantiate a > media capture, each individual encoding can be used by one media capture, > the decision of which one to use according to the framework is by the > provider. The consumer does not select an individual encode.**** > > ** ** > > That was not the intent - it should be the consumer that chooses media > capture / individual encoding pairs to instantiate "capture encodings". > When forming its configure message, the consumer essentially supplies a s= et > of media capture ID + encoding ID pairs to instruct the provider on which > capture encodings to send. Having just re-read it, I think that the > description as per Section 9 of the current framework document described > this well (though Mark deserves the credit for that, obviously!).**** > > ** ** > > >Roni: **** > > >The maximum number of streams that can result from a particular encoding > group is equal to the number of individual encodings in the group (note > that this is why the example in the current data model allows only for on= e > video and one audio streams).**** > > ** ** > > It is true that the number of streams that can result from a particular > encoding group is equal to the number of individual encodings in the grou= p > - however, a fully flexible system might choose to have a single encoding > group and so no real restriction need be introduced by this (unless the > provider system has such restrictions - in which case they can be modelle= d > in this way).**** > > ** ** > > ** ** > > >Roni:**** > > ** ** > > >Section 8 of the framework talk about having more than one individual > encoding assigned to a media capture (simulcast) and also claims that it > can be done by the consumer but there is no way to do it since the media > capture is associated only with an encoding group. There is no way for a > consumer even to assign a specific individual encoding to a group.**** > > ** ** > > You're right that there's no way for the consumer to assign a specific > individual encoding to a group, but it's not clear what the need is - if = a > provider system is sufficiently flexible that any encoding can be used by > any media capture, then it should construct its advertisement to use just= a > single encoding group to comprise all encodings, at which point the > consumer has greater flexibility in which it can choose to be sent to it.= * > *** > > ** ** > > ** ** > > >Roni: **** > > >The video is H.264 specific and not general**** > > ** ** > > The problem we had was that we needed to come up with a way of describing > a big block of video encoding capability and how it could be subdivided. > e.g. you might be able to send 2 x 720p30 but not a single 720p60. The be= st > scheme we could come up with was to, for each of H.264, H.265 etc. includ= e > some specific parameters that would allow both a provider's overall > capability to be signalled and how it might be subdivided across multiple > encodings. It's true that currently the parameters only really work for > H.264 and, moreover, only really work for a provider sending all encoding= s > within a group using the same codec, but the expectation was that new > codecs would have their own equivalent parameters added here in a similar > way.**** > > ** ** > > ** ** > > >Roni:**** > > >The relation between the individual encode and encoding group makes it > difficult to achieve a reasonable set even if the consumer will be able t= o > select the mapping. This is due to the fact the total defined by the grou= p > limits the usage for individual encoding. For example if we have a three > camera system and we set a value in the group for maxGroupH264Mbps and > want to allow for simulcast (two resolutions), we will need to define six > individual encodes, three with high resolution ( also high maxH264Mbps) a= nd > three lower resolution with lower maxH264Mbps. If the compute resource ca= n > do all six it will reflected in the value of maxGroupH264Mbps but I assu= me > that there is a constrain (otherwise why have encodings) making it lower. > So if the consumer will ask for all six what will happen. Since there is > more than one degree of freedom he will not be able to predict if he will > get all or part on lower frame rate , if he will get only a subset of the > streams, if he will get different resolutions.**** > > ** ** > > The situation you describe is, I would argue, exactly what the parameters > are for. The consumer would be allowed to ask for all 6, each with > consumer-imposed maximum values. The provider would be bound by its overa= ll > maxGroupH264Mbps as well as each individual encoding's max. value - in ma= ny > senses this is no difference to existing systems' balancing of bit rate > across main and presentation limits. I think if the consumer asks for all > six then what will happen should be very predictable - 6 capture encoding= s > will be sent to the consumer, with each capped by the lower of the > consumer's request parameters and the provider's limitations. It is true > that the frame rate / resolution would be bounded but not fixed, but this > is true today on a video call - if you can receive 720p30 you don't know > whether the far end will send you 720p30, 720p5, CIF30 etc. I'm not sure = I > see how what we're talking about here does anything but follow normal > encoder and decoder behavior as seen today (equally, I confess that I may > not be fully understanding the intricacies of the case you describe).**** > > ** ** > > >On the other hand if the 6 individual encodes will include lower values > to allow for the group limit it will mean that a consumer not doing > simulcast is limited by the fact the simulcast and ask (if possible) for > only three streams, the individual encodes limit will be low so he will n= ot > be able to use the full compute resources.**** > > ** ** > > >Roni:**** > > >Section 8 concludes that the number of individual encodes in a group mus= t > allow for all media capture in a capture scene entry to be used > simultaneously.**** > > ** ** > > Yes, this is a corollary of the constraint that all media captures in a > capture scene entry must be able to be provided simultaneously (which > itself is a corollary of the idea that each capture scene entry is in > itself a useful representation of the scene).**** > > **** > > >So it look like this system does not work well for simulcast. What about > no simulcast, is it needed. For example a three camera system that also > have one presentation. My view that the cameras will be one capture scene > and the presentation will be a second one. The question is if they all > belong to one encoding group, here my view is =93no=94 since they have > different priority and should not compete for compute resources.**** > > ** ** > > Another view is that if the provider does encode the cameras and the > presentation from the same pool of encoding resource then it is valid for > the consumer to choose which to prioritise (i.e. the provider could leave > the consumer to allocate encodings to the media captures).**** > > ** ** > > >Roni:**** > > >So we will have two encoding groups one for presentation and one for the > three cameras. For the three cameras each sending one stream I assume tha= t > the resource allocation will be a third for each so we will have three > individual encode with the same values, this is the basic one and if it i= s > a third than no need for advertising or configuring. Now if we also want = to > have an individual encode that has higher compute if the consumer wants > only one capture (of the whole room), the group will have fourth one with > higher value. So if there is way for consumer to configure individual > encode when using three media captures, he may select the higher capabili= ty > one with two lower ones. The total will be limited by the encoding group > value and again it is not clear how the actual streams will be encoded to > address the group limit since there are multiple options.**** > > ** ** > > To my mind this is no different to the sort of trace offs / choices that > are already made in this sort of system today - in a video call it is > common to not be able to send a camera stream at full resolution and full > frame rate either because of bandwidth limitations or the capabilities of > the receiver. In the case you cite, yes, the consumer could choose to > impose different video limits on the left center and right cameras, but i= t > would be within its rights to do so, just as the provider would then be > within its rights to send them all at the lowest of the 3 levels.**** > > ** ** > > >Roni: **** > > >To summarize I do not see value in the encoding as currently specified > since they only provide information and no option for configuration. The > value of it as information does not justify specifying them and if the > intention is to allow configurations of individual encoding it must be > reflected and the explained how it works.**** > > ** ** > > >Roni: **** > > >My proposal is at the moment to remove the encoding until we get some > text that defines how to use it for configuring encoding to media capture= s > including for the simulcast case**** > > ** ** > > I think I'd agree with you if it really were true that simulcast was > ill-defined here, but I think it's covered pretty well. It's clear that > you've thought about it in a lot of detail though, so I'm sure there'll b= e > more to discuss on this...**** > > ** ** > > Regards,**** > > ** ** > > Andy**** > > ** ** > > ** ** > > On Thu, Nov 1, 2012 at 4:38 PM, Paul Kyzivat > wrote:**** > > (As co-chair) > > Roni is proposing a significant change here. > > PLEASE carefully consider this and comment on it here on the mailing list= ! > > *If* this works and satisfies all objectives then it will be a helpful > simplification. But it may be that simplifying things this way excludes > some required behavior. > > This is something that would benefit from discussion next week. But that > won't be helpful if people haven't already thought about it. > > Thanks, > Paul**** > > > > On 10/31/12 5:49 AM, Roni Even wrote:**** > > Hi, > > From the email discussion it looks to me that the concept of the > encoding as specified in the framework document is not clear. I will try > to describe my understanding of sections 7 and 8 of the framework > document and explain why I think that it is not important to CLUE as > specified. I am looking for response if my understanding of the encoding > based on the framework is correct and how it will work for the examples > I will provide bellow > > The purpose of the Encodings is to provide INFORMATION about the > provider abilities to send streams. This relates to the available > resources (compute and BW) of the providers. > > The encodings are constructed from encoding groups and each encoding > group is include individual encodes. > > The encoding group provide a value for the total maximum BW and compute > H264Mbps (note that it is H.264 specific) of all the individual encodes > in the group that the provider can use to send audio and video. > > Each encoding group include a list of individual encodes (audio and /or > video). These provide maximum values that can be used to instantiate a > media stream by the provider. > > Each video individual encodes identified by an encodeID provides maximum > values for BW, compute, resolution and frame rate for H.264. (BTW: the > maxH264Mbps can be computed from the resolution and frame rate as > defined in table 2 making it redundant). > > Each audio encode has only a BW value (no identifier). > > A media capture is associated with an encoding group !!!!! not an > individual encoding. > > The provider can use one of the individual encoding to instantiate a > media capture, each individual encoding can be used by one media > capture, the decision of which one to use according to the framework is > by the provider. The consumer does not select an individual encode. > > The maximum number of streams that can result from a particular encoding > group is equal to the number of individual encodings in the group (note > that this is why the example in the current data model allows only for > one video and one audio streams). > > Section 8 of the framework talk about having more than one individual > encoding assigned to a media capture (simulcast) and also claims that it > can be done by the consumer but there is no way to do it since the media > capture is associated only with an encoding group. There is no way for a > consumer even to assign a specific individual encoding to a group. > > My view is that this mechanism does not work and can be removed. The > reasons are given bellow > > The encoding as currently specified is provided as information since > there is no way to map one or more individual encoding to a specific > media capture > > The video is H.264 specific and not general > > The relation between the individual encode and encoding group makes it > difficult to achieve a reasonable set even if the consumer will be able > to select the mapping. This is due to the fact the total defined by the > group limits the usage for individual encoding. For example if we have > a three camera system and we set a value in the group for > maxGroupH264Mbps and want to allow for simulcast (two resolutions), we > will need to define six individual encodes, three with high resolution ( > also high maxH264Mbps) and three lower resolution with lower > maxH264Mbps. If the compute resource can do all six it will reflected > in the value of maxGroupH264Mbps but I assume that there is a constrain > (otherwise why have encodings) making it lower. So if the consumer will > ask for all six what will happen. Since there is more than one degree of > freedom he will not be able to predict if he will get all or part on > lower frame rate , if he will get only a subset of the streams, if he > will get different resolutions. > > On the other hand if the 6 individual encodes will include lower values > to allow for the group limit it will mean that a consumer not doing > simulcast is limited by the fact the simulcast and ask (if possible) for > only three streams, the individual encodes limit will be low so he will > not be able to use the full compute resources. > > Section 8 concludes that the number of individual encodes in a group > must allow for all media capture in a capture scene entry to be used > simultaneously. > > So it look like this system does not work well for simulcast. What about > no simulcast, is it needed. For example a three camera system that also > have one presentation. My view that the cameras will be one capture > scene and the presentation will be a second one. The question is if they > all belong to one encoding group, here my view is =93no=94 since they hav= e > different priority and should not compete for compute resources. So we > will have two encoding groups one for presentation and one for the three > cameras. For the three cameras each sending one stream I assume that the > resource allocation will be a third for each so we will have three > individual encode with the same values, this is the basic one and if it > is a third than no need for advertising or configuring. Now if we also > want to have an individual encode that has higher compute if the > consumer wants only one capture (of the whole room), the group will have > fourth one with higher value. So if there is way for consumer to > configure individual encode when using three media captures, he may > select the higher capability one with two lower ones. The total will be > limited by the encoding group value and again it is not clear how the > actual streams will be encoded to address the group limit since there > are multiple options. > > To summarize I do not see value in the encoding as currently specified > since they only provide information and no option for configuration. The > value of it as information does not justify specifying them and if the > intention is to allow configurations of individual encoding it must be > reflected and the explained how it works. > > My proposal is at the moment to remove the encoding until we get some > text that defines how to use it for configuring encoding to media > captures including for the simulcast case > > Thanks > > Roni Even > > > **** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --20cf300fafd7a9e56604cdd25bbe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Roni,

>Can you explain how the encoding works= with the dynamic mapping of RTP to Media Captures.

I'll have a go...

Firstly, I'd say= that the dynamic mapping relates to *capture encodings* rather than media = captures. You mention the MCU case; I'd say this depends on how you env= isage the MCU case operating:

If the MCU were transcoding then it would offer separat= e capture scene entries for 1 capture, 2 capture, 3 capture etc. transcodin= gs of the main scene, and perhaps a capture scene for presentation as well.=

If the MCU were switching, I'd envisage it offering= some number of loudest speaker streams in a "main" capture scene= and allowing consumer devices to choose the number they were able to rende= r and display.

I myself never saw the multipoint case as involving all= individual participants' advertisements being sent out to all other pa= rticipants - I think MCUs should be performing some sensible aggregation of= what participants advertise to them in order to avoid scalability problems= .

I agree that if you're switching from multiple sour= ces and not transcoding then all of those contributing provider advertiseme= nts might contribute to (/ modify) the MCU's provider advertisement tha= t gets sent out, though I don't really see how dynamic RTP vs static RT= P is that relevant here (i.e. I think the complexities here are present no = matter how the SSRCs etc. are derived). In the dynamic case, the consumer e= ssentially chooses header extension IDs for the capture encodings it reques= ts from the provider, and decodes / renders the media sent to it from the p= rovider.

I wonder if we're getting 2 separate topics needles= sly entangled here, a) dynamic vs static mapping and b) how a multipoint pr= ovider determines its own provider advertisement from multiple participants= ' such advertisements. For the multipoint case, I'd argue that the = MCU's role here would be to distil down the individual other participan= ts' media into sensible capture scenes and capture scene entries that g= ive each consumer a sensible set of media captures to choose from.

Regards,

Andy

On Mon, Nov 5, 2012 at 1:55 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Andy,<= u>

Can you explain how the e= ncoding works with the dynamic mapping of RTP to Media Captures. =

Does this mean that the c= onsumer will get advertisements from all the participants of the multipoint= call and will need to calculate the limitations in each switch and ask for= a new configuration since the group limits may enforce different limitatio= ns.

=A0<= /p>

In the static mapping = case all this can be achieved using imageattr and the codec parameters

Roni=

=A0

From: clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf Of Andy Pepperell
Sent: 02 November, 2012 11:20 AM
To: Paul Kyzivat
Cc= : clue@ietf.org<= br>Subject: Re: [clue] Do we need the encodings as secified in the f= ramework document - proposal to remove them from the framework

=A0

>Paul:=

>*If* this works and satisfies all objectives then it will be= a helpful simplification. But it may be that simplifying things this way e= xcludes some required behavior.

=A0

I certainly agree with Paul's point here... ho= wever, with not all that many of Roni's (as might be expected :) ) - to= be specific:

=A0

>Roni:

=

>Each encoding group include a list of individual encodes =A0(audio= and /or video). These provide maximum values that can be used to instantia= te a media stream by the provider.

=A0

Yes, I think that's a good = summary.

=A0

>Each video individual encode= s identified by an encodeID provides maximum values =A0for BW, compute, res= olution and frame rate for H.264. (BTW: the maxH264Mbps can be computed fro= m the resolution and frame rate as defined in table 2 making it redundant).=

>Each audio encode has only a BW value (no identifier).

=A0

Also agreed - apart from the H.264 point I think - a maximum res= olution and a maximum frame rate doesn't necessarily imply a maxMbps - = many systems can encode 1280x720 at some frame rate < 30 *or* some lower= resolution at up to 30fps without necessarily being able to send 720p30, s= urely?

=A0

=A0

> Roni:

= >A media capture is associated with an encoding group !!!!! not an indiv= idual encoding.

=A0

That's true, and by design.= To re-iterate the original design intent here, the idea behind the encodin= g groups idea was to be able to model 2 common Telepresence architectures w= e see today:

1) a multi-screen endpoint room comprised of multiple endpoints (most = vendors' "3 screen" systems, for instance, tend to be compose= d of 3 of their "1 screen" products linked together)

2) a flexible media generation system such as a software or hardware M= CU

=A0

For the "1)" case above, due to real-world constraints such = as camera wiring etc., it seemed to us that a media capture representing, s= ay, the left camera of 3, would only be able to be encoded by the hardware = it was directly connected to - thus, such a system would use one "enco= ding group" for its left constituent, one for its centre and one for i= ts right.

=A0

>Roni:

=A0

>The provider can use one of the individua= l encoding to instantiate a media capture, each individual encoding can be = used by one media capture, the decision of which one to use according to th= e framework is by the provider. The consumer does not select an individual = encode.

=A0

That was not the intent - it sh= ould be the consumer that chooses media capture / individual encoding pairs= to instantiate "capture encodings". When forming its configure m= essage, the consumer essentially supplies a set of media capture ID + encod= ing ID pairs to instruct the provider on which capture encodings to send. H= aving just re-read it, I think that the description as per Section 9 of the= current framework document described this well (though Mark deserves the c= redit for that, obviously!).

=A0

>Roni:=A0

=

>The maximum number of streams that can re= sult from a particular encoding group is equal to the number of individual = encodings in the group (note that this is why the example in the current da= ta model allows only for one video and one audio streams).

=A0

It is true that the number of s= treams that can result from a particular encoding group is equal to the num= ber of individual encodings in the group - however, a fully flexible system= might choose to have a single encoding group and so no real restriction ne= ed be introduced by this (unless the provider system has such restrictions = - in which case they can be modelled in this way).

= =A0

=A0

= >Roni:

=A0

>Section 8 of = the framework talk about having more than one individual encoding assigned = to a media capture (simulcast) and also claims that it can be done by the c= onsumer but there is no way to do it since the media capture is associated = only with an encoding group. There is no way for a consumer even to assign = a specific individual encoding to a group.

=A0

You're right that there'= ;s no way for the consumer to assign a specific individual encoding to a gr= oup, but it's not clear what the need is - if a provider system is suff= iciently flexible that any encoding can be used by any media capture, then = it should construct its advertisement to use just a single encoding group t= o comprise all encodings, at which point the consumer has greater flexibili= ty in which it can choose to be sent to it.

= =A0

=A0

>Roni:=A0

>The video is H.264 = specific and not general

=A0

The problem we had was that we = needed to come up with a way of describing a big block of video encoding ca= pability and how it could be subdivided. e.g. you might be able to send 2 x= 720p30 but not a single 720p60. The best scheme we could come up with was = to, for each of H.264, H.265 etc. include some specific parameters that wou= ld allow both a provider's overall capability to be signalled and how i= t might be subdivided across multiple encodings. It's true that current= ly the parameters only really work for H.264 and, moreover, only really wor= k for a provider sending all encodings within a group using the same codec,= but the expectation was that new codecs would have their own equivalent pa= rameters added here in a similar way.

= =A0

=A0

>Roni:

>The relation between t= he individual encode and encoding group makes it difficult to achieve a rea= sonable set even if the consumer will be able to select the mapping. This i= s due to the fact the total defined by the group limits the usage for indiv= idual encoding. For example if =A0we have a three camera system and we set = a value in the=A0 group for maxGroupH264Mbps and want to allow for simulcas= t (two resolutions), we will need to define six individual encodes, three w= ith high resolution ( also high maxH264Mbps) and three lower resolution wit= h lower maxH264Mbps. If the compute resource can do all six it will=A0 refl= ected in the value of maxGroupH264Mbps but I assume that there is a constra= in (otherwise why have encodings) making it lower. So if the consumer will = ask for all six what will happen. Since there is more than one degree of fr= eedom he will not be able to predict if he will get all or part on lower fr= ame rate , if he will get only a subset of the streams, if he will get diff= erent resolutions.

=A0

The situation you describe is, = I would argue, exactly what the parameters are for. The consumer would be a= llowed to ask for all 6, each with consumer-imposed maximum values. The pro= vider would be bound by its overall maxGroupH264Mbps as well as each indivi= dual encoding's max. value - in many senses this is no difference to ex= isting systems' balancing of bit rate across main and presentation limi= ts. I think if the consumer asks for all six then what will happen should b= e very predictable - 6 capture encodings will be sent to the consumer, with= each capped by the lower of the consumer's request parameters and the = provider's limitations. It is true that the frame rate / resolution wou= ld be bounded but not fixed, but this is true today on a video call - if yo= u can receive 720p30 you don't know whether the far end will send you 7= 20p30, 720p5, CIF30 etc. I'm not sure I see how what we're talking = about here does anything but follow normal encoder and decoder behavior as = seen today (equally, I confess that I may not be fully understanding the in= tricacies of the case you describe).

=A0

>On the other hand if the 6 i= ndividual encodes will include lower values to allow for the group limit it= will mean that a consumer not doing simulcast is limited by the fact the s= imulcast and ask (if possible) for only three streams, the individual encod= es limit will be low so he will not be able to use the full compute resourc= es.

=A0

>Roni:<= /p>

>Section 8 concludes that the number of in= dividual encodes in a group must allow for all media capture in a capture s= cene entry to be used simultaneously.

=A0

Yes, t= his is a corollary of the constraint that all media captures in a capture s= cene entry must be able to be provided simultaneously (which itself is a co= rollary of the idea that each capture scene entry is in itself a useful rep= resentation of the scene).

=A0

>So it look like this system = does not work well for simulcast. What about no simulcast, is it needed. Fo= r example a three camera system that also have one presentation. My view th= at the cameras will be one capture scene and the presentation will be a sec= ond one. The question is if they all belong to one encoding group, here my = view is =93no=94 since they have different priority and should not compete = for compute resources.

=A0

Another view is that if the pro= vider does encode the cameras and the presentation from the same pool of en= coding resource then it is valid for the consumer to choose which to priori= tise (i.e. the provider could leave the consumer to allocate encodings to t= he media captures).

=A0

>Roni:

>So we will have two encoding groups one f= or presentation and one for the three cameras. For the three cameras each s= ending one stream I assume that the resource allocation will be a third for= each so we will have three individual encode with the same values, this is= the basic one and if it is a third than no need for advertising or configu= ring. Now if we also want to have an individual encode that has higher comp= ute if the consumer wants only one capture (of the whole room), the group w= ill have fourth one with higher value. So if there is way for consumer to c= onfigure individual encode when using three media captures, he may select t= he higher capability one with two lower ones. The total will be limited by = the encoding group value and again it is not clear how the actual streams w= ill be encoded to address the group limit since there are multiple options.=

=A0

To my mind this is no different= to the sort of trace offs / choices that are already made in this sort of = system today - in a video call it is common to not be able to send a camera= stream at full resolution and full frame rate either because of bandwidth = limitations or the capabilities of the receiver. In the case you cite, yes,= the consumer could choose to impose different video limits on the left cen= ter and right cameras, but it would be within its rights to do so, just as = the provider would then be within its rights to send them all at the lowest= of the 3 levels.

=A0

>Roni:=A0

=

>To summarize I do not see value in the en= coding as currently specified since they only provide information and no op= tion for configuration. The value of it as information does not justify spe= cifying them and if the intention is to allow configurations of individual = encoding it must be reflected and the explained how it works.=

=A0

>Roni:=A0

>My proposal is at the moment to remove th= e encoding until we get some text that defines how to use it for configurin= g encoding to media captures including for the simulcast case=

=A0

I think I'd agree with you if it really were t= rue that simulcast was ill-defined here, but I think it's covered prett= y well. It's clear that you've thought about it in a lot of detail = though, so I'm sure there'll be more to discuss on this...

=A0

Regards,

=A0

Andy

=A0

=A0

On Thu, Nov= 1, 2012 at 4:38 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

(As co-chair)

Roni is proposing a significant= change here.

PLEASE carefully consider this and comment on it here = on the mailing list!

*If* this works and satisfies all objectives th= en it will be a helpful simplification. But it may be that simplifying thin= gs this way excludes some required behavior.

This is something that would benefit from discussion next week. But tha= t won't be helpful if people haven't already thought about it.
<= br>=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul



On 10/31/12 5:49 AM, Roni Even wrote:

=

Hi,

=A0From the email discussion it looks to me that the concept of = the
encoding as specified in the framework document is not clear. I will= try
to describe my understanding of sections 7 and 8 of the framework document and explain why I think that it is not important to CLUE as
spe= cified. I am looking for response if my understanding of the encoding
ba= sed on the framework is correct and how it will work for the examples
I will provide bellow

The purpose of the Encodings is to provide INF= ORMATION about the
provider abilities to send streams. This relates to t= he available
resources (compute and BW) of the providers.

The enc= odings are constructed from encoding groups and each encoding
group is include individual encodes.

The encoding group provide a va= lue for the total maximum BW and compute
H264Mbps (note that it is H.264= specific) of all the individual encodes
in the group that the provider = can use to send audio and video.

Each encoding group include a list of individual encodes =A0(audio and = /or
video). These provide maximum values that can be used to instantiate= a
media stream by the provider.

Each video individual encodes id= entified by an encodeID provides maximum
values =A0for BW, compute, resolution and frame rate for H.264. (BTW: themaxH264Mbps can be computed from the resolution and frame rate as
defi= ned in table 2 making it redundant).

Each audio encode has only a BW= value (no identifier).

A media capture is associated with an encoding group !!!!! not an
in= dividual encoding.

The provider can use one of the individual encodi= ng to instantiate a
media capture, each individual encoding can be used = by one media
capture, the decision of which one to use according to the framework is
= by the provider. The consumer does not select an individual encode.

= The maximum number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group (note
= that this is why the example in the current data model allows only for
o= ne video and one audio streams).

Section 8 of the framework talk abo= ut having more than one individual
encoding assigned to a media capture (simulcast) and also claims that itcan be done by the consumer but there is no way to do it since the mediacapture is associated only with an encoding group. There is no way for a<= br> consumer even to assign a specific individual encoding to a group.

M= y view is that this mechanism does not work and can be removed. The
reas= ons are given bellow

The encoding as currently specified is provided= as information since
there is no way to map one or more individual encoding to a specific
med= ia capture

The video is H.264 specific and not general

The re= lation between the individual encode and encoding group makes it
difficu= lt to achieve a reasonable set even if the consumer will be able
to select the mapping. This is due to the fact the total defined by the
= group limits the usage for individual encoding. For example if =A0we havea three camera system and we set a value in the =A0group for
maxGroupH= 264Mbps and want to allow for simulcast (two resolutions), we
will need to define six individual encodes, three with high resolution (also high maxH264Mbps) and three lower resolution with lower
maxH264Mbp= s. If the compute resource can do all six it will =A0reflected
in the va= lue of maxGroupH264Mbps but I assume that there is a constrain
(otherwise why have encodings) making it lower. So if the consumer will
= ask for all six what will happen. Since there is more than one degree offreedom he will not be able to predict if he will get all or part on
lower frame rate , if he will get only a subset of the streams, if he
wi= ll get different resolutions.

On the other hand if the 6 individual = encodes will include lower values
to allow for the group limit it will m= ean that a consumer not doing
simulcast is limited by the fact the simulcast and ask (if possible) foronly three streams, the individual encodes limit will be low so he willnot be able to use the full compute resources.

Section 8 concludes = that the number of individual encodes in a group
must allow for all media capture in a capture scene entry to be used
sim= ultaneously.

So it look like this system does not work well for simu= lcast. What about
no simulcast, is it needed. For example a three camera= system that also
have one presentation. My view that the cameras will be one capture
scen= e and the presentation will be a second one. The question is if they
all= belong to one encoding group, here my view is =93no=94 since they have
different priority and should not compete for compute resources. So we
w= ill have two encoding groups one for presentation and one for the three
= cameras. For the three cameras each sending one stream I assume that the resource allocation will be a third for each so we will have three
indiv= idual encode with the same values, this is the basic one and if it
is a = third than no need for advertising or configuring. Now if we also
want t= o have an individual encode that has higher compute if the
consumer wants only one capture (of the whole room), the group will havefourth one with higher value. So if there is way for consumer to
config= ure individual encode when using three media captures, he may
select the= higher capability one with two lower ones. The total will be
limited by the encoding group value and again it is not clear how the
ac= tual streams will be encoded to address the group limit since there
are = multiple options.

To summarize I do not see value in the encoding as= currently specified
since they only provide information and no option for configuration. Thevalue of it as information does not justify specifying them and if the
= intention is to allow configurations of individual encoding it must be
reflected and the explained how it works.

My proposal is at the mome= nt to remove the encoding until we get some
text that defines how to use= it for configuring encoding to media
captures including for the simulca= st case

Thanks

Roni Even


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

=


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

=A0

<= /blockquote>

--20cf300fafd7a9e56604cdd25bbe-- From apeppere@gmail.com Tue Nov 6 04:32: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 46A7621F88D6 for ; Tue, 6 Nov 2012 04:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 TNAux5Ts8XtX for ; Tue, 6 Nov 2012 04:32:53 -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 0007121F88D5 for ; Tue, 6 Nov 2012 04:32:52 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id c4so218094qae.10 for ; Tue, 06 Nov 2012 04:32:52 -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=iT/MoaKz6opdjYKrpHOUh6pWW7pFGwGsYgqZ8SVDTfA=; b=tt/TckC5vgthrZDAuXwILhK8Z+X8tlQhHkbMi+ggHzELhLNJpF3CaggNZDsyqq6UGz kVJGrMHW4ehrbnaBUhEpRNM/O1WWIkhKvfvgF00upuRkZXjbiJndq1T4a4QAMG5r+D/h 992HaOpj00SWug23igPpafimlvChAjZNmMM4/0KIIe/cgz1y7xj/uyyO0sbFDnPywajf 58nSzzyXJ0c+yhZ8x24b6by1j/fYOBjllO1fxynn/9jxpYZ83wJ2hPrblkmkHYpCU9Tg AY1SYO5v2Zz6WuM3HrhKt5mhB3xLC9u1K1LjtpAzT1AFB2oV+gghzvqGVc6SgfIrMv2E RwVA== MIME-Version: 1.0 Received: by 10.224.189.196 with SMTP id df4mr1316416qab.16.1352205172223; Tue, 06 Nov 2012 04:32:52 -0800 (PST) Received: by 10.49.96.98 with HTTP; Tue, 6 Nov 2012 04:32:52 -0800 (PST) In-Reply-To: <019f01cdbb5d$eeeb67d0$ccc23770$@gmail.com> References: <01d301cdb74d$10857940$31906bc0$@gmail.com> <5092A599.4010601@alum.mit.edu> <019f01cdbb5d$eeeb67d0$ccc23770$@gmail.com> Date: Tue, 6 Nov 2012 12:32:52 +0000 Message-ID: From: Andy Pepperell To: Roni Even Content-Type: multipart/alternative; boundary=20cf300fafd7f42f3804cdd2ccf1 Cc: clue@ietf.org Subject: Re: [clue] Do we need the encodings as secified in the framework document - proposal to remove them from the framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 06 Nov 2012 12:32:56 -0000 --20cf300fafd7f42f3804cdd2ccf1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Roni, >I was wondering how can an MCU create a common encoding group and individual encodes if all participating EP do not have a common limit since it needs to provide a common advertisement Again, I'd say there's no single algorithm here as it would depend on the characteristics of the MCU - whether it is transcoding or switching, and what experience it's intending to provide to other (presumably CLUE-capable) participants acting as consumers. It is true though that the MCU needs to create a provider advertisement that in some senses summarizes the conference as a whole; however, it's also the case that: - each conference participant will have performed their own individual O/A exchange with the MCU to set session-wide limits for things such as overall H.264 maxMbps and to agree on which payload types to use for different encoding types - the provider advertisement values are strictly maximum values, and so the MCU does not need to automatically decrease its advertised values to all consumers based on lower values in other participants' advertisements. If we're talking about a non-transcoding MCU which was intending to provide just a single loudest speaker video stream to each consumer, I'd expect that MCU's provider advertisement to include a capture scene entry of a single video capture whose encoding group and encoding would reflect the largest bandwidth / resolution / maxMbps of all potential sources for that capture (but need not; this could perfectly reasonably be capped by a limit chosen by the MCU). Once a consumer had requested a capture encoding of that media capture, it might be (depending on the values of the encoding limits specified by the consumer) that the MCU might issue new configuration messages to other participants with lower maximum values in order that that capture can be switched (with appropriate payload re-writing / header extension additions) to multiple consumers. This would be subject to individual, per-consumer, tweaking; as well as the payload re-writing, it might be that the MCU would send the "2nd loudest" speaker back to the loudest speaker, or might eschew additional offer / answer cycles to all participants to accommodate a new consumer unable to receive the same set of video codecs as the others at the expense of a slightly worse conferencing experience for those lower capable consumers, for instance. Going back to: >I was wondering how can an MCU create a common encoding group and individual encodes if all participating EP do not have a common limit since it needs to provide a common advertisement I think I'd be reluctant to go into too much more detail on this here because I think perhaps the question needs restating slightly - a common encoding group and individual encodes would be reasonably straightforward to come up with given the semantics of those encodings' values as being maximum values for bandwidth / resolution / mbps etc. Perhaps a more interesting question is how an MCU would modify the configuration messages it sends to other conference participants based on new participants' configuration messages to it. In many senses though I would say these issues aren't introduced by CLUE - a straightforward SIP MCU today that was trying to switch loudest speaker streams to conference participants when those participants support different codecs / bandwidth limits would run into very similar "lowest common denominator" type issues, and presumably may need to readvertise to its participants, rewrite RTP payload types etc. as part of being able to switch one source stream out to multiple destinations... Regards, Andy P.S. You say "... since it needs to provide a common advertisement" - technically, the MCU would be perfectly within its rights to form a new provider advertisement for each consumer / participant. This might be appropriate, for instance, if it wished to reflect the overall call bandwidth in its individual encodings or to, say, omit H.264 parameters if the initial offer answer yielded no common H.264 modes, or to omit video captures if its video capacity had been exhausted. On Mon, Nov 5, 2012 at 2:00 PM, Roni Even wrote: > Hi Andy,**** > > I was wondering how can an MCU create a common encoding group and > individual encodes if all participating EP do not have a common limit sin= ce > it needs to provide a common advertisement**** > > Roni**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Andy Pepperell > *Sent:* 02 November, 2012 11:20 AM > *To:* Paul Kyzivat > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Do we need the encodings as secified in the > framework document - proposal to remove them from the framework**** > > ** ** > > >Paul:**** > > >*If* this works and satisfies all objectives then it will be a helpful > simplification. But it may be that simplifying things this way excludes > some required behavior.**** > > ** ** > > I certainly agree with Paul's point here... however, with not all that > many of Roni's (as might be expected :) ) - to be specific:**** > > ** ** > > >Roni:**** > > >Each encoding group include a list of individual encodes (audio and /or > video). These provide maximum values that can be used to instantiate a > media stream by the provider.**** > > ** ** > > Yes, I think that's a good summary.**** > > **** > > >Each video individual encodes identified by an encodeID provides maximum > values for BW, compute, resolution and frame rate for H.264. (BTW: the > maxH264Mbps can be computed from the resolution and frame rate as defined > in table 2 making it redundant).**** > > >Each audio encode has only a BW value (no identifier).**** > > ** ** > > Also agreed - apart from the H.264 point I think - a maximum resolution > and a maximum frame rate doesn't necessarily imply a maxMbps - many syste= ms > can encode 1280x720 at some frame rate < 30 *or* some lower resolution at > up to 30fps without necessarily being able to send 720p30, surely?**** > > **** > > **** > > > Roni:**** > > >A media capture is associated with an encoding group !!!!! not an > individual encoding.**** > > ** ** > > That's true, and by design. To re-iterate the original design intent here= , > the idea behind the encoding groups idea was to be able to model 2 common > Telepresence architectures we see today:**** > > 1) a multi-screen endpoint room comprised of multiple endpoints (most > vendors' "3 screen" systems, for instance, tend to be composed of 3 of > their "1 screen" products linked together)**** > > 2) a flexible media generation system such as a software or hardware MCU*= * > ** > > ** ** > > For the "1)" case above, due to real-world constraints such as camera > wiring etc., it seemed to us that a media capture representing, say, the > left camera of 3, would only be able to be encoded by the hardware it was > directly connected to - thus, such a system would use one "encoding group= " > for its left constituent, one for its centre and one for its right.**** > > ** ** > > >Roni:**** > > ** ** > > >The provider can use one of the individual encoding to instantiate a > media capture, each individual encoding can be used by one media capture, > the decision of which one to use according to the framework is by the > provider. The consumer does not select an individual encode.**** > > ** ** > > That was not the intent - it should be the consumer that chooses media > capture / individual encoding pairs to instantiate "capture encodings". > When forming its configure message, the consumer essentially supplies a s= et > of media capture ID + encoding ID pairs to instruct the provider on which > capture encodings to send. Having just re-read it, I think that the > description as per Section 9 of the current framework document described > this well (though Mark deserves the credit for that, obviously!).**** > > ** ** > > >Roni: **** > > >The maximum number of streams that can result from a particular encoding > group is equal to the number of individual encodings in the group (note > that this is why the example in the current data model allows only for on= e > video and one audio streams).**** > > ** ** > > It is true that the number of streams that can result from a particular > encoding group is equal to the number of individual encodings in the grou= p > - however, a fully flexible system might choose to have a single encoding > group and so no real restriction need be introduced by this (unless the > provider system has such restrictions - in which case they can be modelle= d > in this way).**** > > ** ** > > ** ** > > >Roni:**** > > ** ** > > >Section 8 of the framework talk about having more than one individual > encoding assigned to a media capture (simulcast) and also claims that it > can be done by the consumer but there is no way to do it since the media > capture is associated only with an encoding group. There is no way for a > consumer even to assign a specific individual encoding to a group.**** > > ** ** > > You're right that there's no way for the consumer to assign a specific > individual encoding to a group, but it's not clear what the need is - if = a > provider system is sufficiently flexible that any encoding can be used by > any media capture, then it should construct its advertisement to use just= a > single encoding group to comprise all encodings, at which point the > consumer has greater flexibility in which it can choose to be sent to it.= * > *** > > ** ** > > ** ** > > >Roni: **** > > >The video is H.264 specific and not general**** > > ** ** > > The problem we had was that we needed to come up with a way of describing > a big block of video encoding capability and how it could be subdivided. > e.g. you might be able to send 2 x 720p30 but not a single 720p60. The be= st > scheme we could come up with was to, for each of H.264, H.265 etc. includ= e > some specific parameters that would allow both a provider's overall > capability to be signalled and how it might be subdivided across multiple > encodings. It's true that currently the parameters only really work for > H.264 and, moreover, only really work for a provider sending all encoding= s > within a group using the same codec, but the expectation was that new > codecs would have their own equivalent parameters added here in a similar > way.**** > > ** ** > > ** ** > > >Roni:**** > > >The relation between the individual encode and encoding group makes it > difficult to achieve a reasonable set even if the consumer will be able t= o > select the mapping. This is due to the fact the total defined by the grou= p > limits the usage for individual encoding. For example if we have a three > camera system and we set a value in the group for maxGroupH264Mbps and > want to allow for simulcast (two resolutions), we will need to define six > individual encodes, three with high resolution ( also high maxH264Mbps) a= nd > three lower resolution with lower maxH264Mbps. If the compute resource ca= n > do all six it will reflected in the value of maxGroupH264Mbps but I assu= me > that there is a constrain (otherwise why have encodings) making it lower. > So if the consumer will ask for all six what will happen. Since there is > more than one degree of freedom he will not be able to predict if he will > get all or part on lower frame rate , if he will get only a subset of the > streams, if he will get different resolutions.**** > > ** ** > > The situation you describe is, I would argue, exactly what the parameters > are for. The consumer would be allowed to ask for all 6, each with > consumer-imposed maximum values. The provider would be bound by its overa= ll > maxGroupH264Mbps as well as each individual encoding's max. value - in ma= ny > senses this is no difference to existing systems' balancing of bit rate > across main and presentation limits. I think if the consumer asks for all > six then what will happen should be very predictable - 6 capture encoding= s > will be sent to the consumer, with each capped by the lower of the > consumer's request parameters and the provider's limitations. It is true > that the frame rate / resolution would be bounded but not fixed, but this > is true today on a video call - if you can receive 720p30 you don't know > whether the far end will send you 720p30, 720p5, CIF30 etc. I'm not sure = I > see how what we're talking about here does anything but follow normal > encoder and decoder behavior as seen today (equally, I confess that I may > not be fully understanding the intricacies of the case you describe).**** > > ** ** > > >On the other hand if the 6 individual encodes will include lower values > to allow for the group limit it will mean that a consumer not doing > simulcast is limited by the fact the simulcast and ask (if possible) for > only three streams, the individual encodes limit will be low so he will n= ot > be able to use the full compute resources.**** > > ** ** > > >Roni:**** > > >Section 8 concludes that the number of individual encodes in a group mus= t > allow for all media capture in a capture scene entry to be used > simultaneously.**** > > ** ** > > Yes, this is a corollary of the constraint that all media captures in a > capture scene entry must be able to be provided simultaneously (which > itself is a corollary of the idea that each capture scene entry is in > itself a useful representation of the scene).**** > > **** > > >So it look like this system does not work well for simulcast. What about > no simulcast, is it needed. For example a three camera system that also > have one presentation. My view that the cameras will be one capture scene > and the presentation will be a second one. The question is if they all > belong to one encoding group, here my view is =93no=94 since they have > different priority and should not compete for compute resources.**** > > ** ** > > Another view is that if the provider does encode the cameras and the > presentation from the same pool of encoding resource then it is valid for > the consumer to choose which to prioritise (i.e. the provider could leave > the consumer to allocate encodings to the media captures).**** > > ** ** > > >Roni:**** > > >So we will have two encoding groups one for presentation and one for the > three cameras. For the three cameras each sending one stream I assume tha= t > the resource allocation will be a third for each so we will have three > individual encode with the same values, this is the basic one and if it i= s > a third than no need for advertising or configuring. Now if we also want = to > have an individual encode that has higher compute if the consumer wants > only one capture (of the whole room), the group will have fourth one with > higher value. So if there is way for consumer to configure individual > encode when using three media captures, he may select the higher capabili= ty > one with two lower ones. The total will be limited by the encoding group > value and again it is not clear how the actual streams will be encoded to > address the group limit since there are multiple options.**** > > ** ** > > To my mind this is no different to the sort of trace offs / choices that > are already made in this sort of system today - in a video call it is > common to not be able to send a camera stream at full resolution and full > frame rate either because of bandwidth limitations or the capabilities of > the receiver. In the case you cite, yes, the consumer could choose to > impose different video limits on the left center and right cameras, but i= t > would be within its rights to do so, just as the provider would then be > within its rights to send them all at the lowest of the 3 levels.**** > > ** ** > > >Roni: **** > > >To summarize I do not see value in the encoding as currently specified > since they only provide information and no option for configuration. The > value of it as information does not justify specifying them and if the > intention is to allow configurations of individual encoding it must be > reflected and the explained how it works.**** > > ** ** > > >Roni: **** > > >My proposal is at the moment to remove the encoding until we get some > text that defines how to use it for configuring encoding to media capture= s > including for the simulcast case**** > > ** ** > > I think I'd agree with you if it really were true that simulcast was > ill-defined here, but I think it's covered pretty well. It's clear that > you've thought about it in a lot of detail though, so I'm sure there'll b= e > more to discuss on this...**** > > ** ** > > Regards,**** > > ** ** > > Andy**** > > ** ** > > ** ** > > On Thu, Nov 1, 2012 at 4:38 PM, Paul Kyzivat > wrote:**** > > (As co-chair) > > Roni is proposing a significant change here. > > PLEASE carefully consider this and comment on it here on the mailing list= ! > > *If* this works and satisfies all objectives then it will be a helpful > simplification. But it may be that simplifying things this way excludes > some required behavior. > > This is something that would benefit from discussion next week. But that > won't be helpful if people haven't already thought about it. > > Thanks, > Paul**** > > > > On 10/31/12 5:49 AM, Roni Even wrote:**** > > Hi, > > From the email discussion it looks to me that the concept of the > encoding as specified in the framework document is not clear. I will try > to describe my understanding of sections 7 and 8 of the framework > document and explain why I think that it is not important to CLUE as > specified. I am looking for response if my understanding of the encoding > based on the framework is correct and how it will work for the examples > I will provide bellow > > The purpose of the Encodings is to provide INFORMATION about the > provider abilities to send streams. This relates to the available > resources (compute and BW) of the providers. > > The encodings are constructed from encoding groups and each encoding > group is include individual encodes. > > The encoding group provide a value for the total maximum BW and compute > H264Mbps (note that it is H.264 specific) of all the individual encodes > in the group that the provider can use to send audio and video. > > Each encoding group include a list of individual encodes (audio and /or > video). These provide maximum values that can be used to instantiate a > media stream by the provider. > > Each video individual encodes identified by an encodeID provides maximum > values for BW, compute, resolution and frame rate for H.264. (BTW: the > maxH264Mbps can be computed from the resolution and frame rate as > defined in table 2 making it redundant). > > Each audio encode has only a BW value (no identifier). > > A media capture is associated with an encoding group !!!!! not an > individual encoding. > > The provider can use one of the individual encoding to instantiate a > media capture, each individual encoding can be used by one media > capture, the decision of which one to use according to the framework is > by the provider. The consumer does not select an individual encode. > > The maximum number of streams that can result from a particular encoding > group is equal to the number of individual encodings in the group (note > that this is why the example in the current data model allows only for > one video and one audio streams). > > Section 8 of the framework talk about having more than one individual > encoding assigned to a media capture (simulcast) and also claims that it > can be done by the consumer but there is no way to do it since the media > capture is associated only with an encoding group. There is no way for a > consumer even to assign a specific individual encoding to a group. > > My view is that this mechanism does not work and can be removed. The > reasons are given bellow > > The encoding as currently specified is provided as information since > there is no way to map one or more individual encoding to a specific > media capture > > The video is H.264 specific and not general > > The relation between the individual encode and encoding group makes it > difficult to achieve a reasonable set even if the consumer will be able > to select the mapping. This is due to the fact the total defined by the > group limits the usage for individual encoding. For example if we have > a three camera system and we set a value in the group for > maxGroupH264Mbps and want to allow for simulcast (two resolutions), we > will need to define six individual encodes, three with high resolution ( > also high maxH264Mbps) and three lower resolution with lower > maxH264Mbps. If the compute resource can do all six it will reflected > in the value of maxGroupH264Mbps but I assume that there is a constrain > (otherwise why have encodings) making it lower. So if the consumer will > ask for all six what will happen. Since there is more than one degree of > freedom he will not be able to predict if he will get all or part on > lower frame rate , if he will get only a subset of the streams, if he > will get different resolutions. > > On the other hand if the 6 individual encodes will include lower values > to allow for the group limit it will mean that a consumer not doing > simulcast is limited by the fact the simulcast and ask (if possible) for > only three streams, the individual encodes limit will be low so he will > not be able to use the full compute resources. > > Section 8 concludes that the number of individual encodes in a group > must allow for all media capture in a capture scene entry to be used > simultaneously. > > So it look like this system does not work well for simulcast. What about > no simulcast, is it needed. For example a three camera system that also > have one presentation. My view that the cameras will be one capture > scene and the presentation will be a second one. The question is if they > all belong to one encoding group, here my view is =93no=94 since they hav= e > different priority and should not compete for compute resources. So we > will have two encoding groups one for presentation and one for the three > cameras. For the three cameras each sending one stream I assume that the > resource allocation will be a third for each so we will have three > individual encode with the same values, this is the basic one and if it > is a third than no need for advertising or configuring. Now if we also > want to have an individual encode that has higher compute if the > consumer wants only one capture (of the whole room), the group will have > fourth one with higher value. So if there is way for consumer to > configure individual encode when using three media captures, he may > select the higher capability one with two lower ones. The total will be > limited by the encoding group value and again it is not clear how the > actual streams will be encoded to address the group limit since there > are multiple options. > > To summarize I do not see value in the encoding as currently specified > since they only provide information and no option for configuration. The > value of it as information does not justify specifying them and if the > intention is to allow configurations of individual encoding it must be > reflected and the explained how it works. > > My proposal is at the moment to remove the encoding until we get some > text that defines how to use it for configuring encoding to media > captures including for the simulcast case > > Thanks > > Roni Even > > > **** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --20cf300fafd7f42f3804cdd2ccf1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Roni,

>I was wondering how can an MCU create a com= mon encoding group and individual encodes if all participating EP do not ha= ve a common limit since it needs to provide a common advertisement

Again, I'd say there's no single algorithm here= as it would depend on the characteristics of the MCU - whether it is trans= coding or switching, and what experience it's intending to provide to o= ther (presumably CLUE-capable) participants acting as consumers.

It is true though that the MCU needs to create a provid= er advertisement that in some senses summarizes the conference as a whole; = however, it's also the case that:
- each conference participa= nt will have performed their own individual O/A exchange with the MCU to se= t session-wide limits for things such as overall H.264 maxMbps and to agree= on which payload types to use for different encoding types
- the provider advertisement values are strictly maximum values, and s= o the MCU does not need to automatically decrease its advertised values to = all consumers based on lower values in other participants' advertisemen= ts.

If we're talking about a non-transcoding MCU which = was intending to provide just a single loudest speaker video stream to each= consumer, I'd expect that MCU's provider advertisement to include = a capture scene entry of a single video capture whose encoding group and en= coding would reflect the largest bandwidth / resolution / maxMbps of all po= tential sources for that capture (but need not; this could perfectly reason= ably be capped by a limit chosen by the MCU). Once a consumer had requested= a capture encoding of that media capture, it might be (depending on the va= lues of the encoding limits specified by the consumer) that the MCU might i= ssue new configuration messages to other participants with lower maximum va= lues in order that that capture can be switched (with appropriate payload r= e-writing / header extension additions) to multiple consumers. This would b= e subject to individual, per-consumer, tweaking; as well as the payload re-= writing, it might be that the MCU would send the "2nd loudest" sp= eaker back to the loudest speaker, or might eschew additional offer / answe= r cycles to all participants to accommodate a new consumer unable to receiv= e the same set of video codecs as the others at the expense of a slightly w= orse conferencing experience for those lower capable consumers, for instanc= e.

Going back to:
>I was wondering how can an= MCU create a common encoding group and individual encodes if all participa= ting EP do not have a common limit since it needs to provide a common adver= tisement

I think I'd be reluctant to go into too much more d= etail on this here because I think perhaps the question needs restating sli= ghtly - a common encoding group and individual encodes would be reasonably = straightforward to come up with given the semantics of those encodings'= values as being maximum values for bandwidth / resolution / mbps etc. Perh= aps a more interesting question is how an MCU would modify the configuratio= n messages it sends to other conference participants based on new participa= nts' configuration messages to it. In many senses though I would say th= ese issues aren't introduced by CLUE - a straightforward SIP MCU today = that was trying to switch loudest speaker streams to conference participant= s when those participants support different codecs / bandwidth limits would= run into very similar "lowest common denominator" type issues, a= nd presumably may need to readvertise to its participants, rewrite RTP payl= oad types etc. as part of being able to switch one source stream out to mul= tiple destinations...

Regards,

Andy

P.S. You say "...=A0=A0since it needs to provide a common adv= ertisement" - technically, the MCU would be perfectly within its right= s to form a new provider advertisement for each consumer / participant. Thi= s might be appropriate, for instance, if it wished to reflect the overall c= all bandwidth in its individual encodings or to, say, omit H.264 parameters= if the initial offer answer yielded no common H.264 modes, or to omit vide= o captures if its video capacity had been exhausted.



On Mon, Nov 5, 2012 = at 2:00 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Andy,

I was wondering how can an MCU create a common e= ncoding group and individual encodes if all participating EP do not have a = common limit since it needs to provide a common advertisement=

Roni=

= =A0

From: clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf Of Andy Pepperell
Sent: 02 November, 2012 11:20 AM
To: Paul Kyzivat
Cc= : clue@ietf.org<= br>Subject: Re: [clue] Do we need the encodings as secified in the f= ramework document - proposal to remove them from the framework

=A0

>Paul:<= /u>

>*If* this works and satisfies all obj= ectives then it will be a helpful simplification. But it may be that simpli= fying things this way excludes some required behavior.=

=A0

I certainly agree with Paul's point here... ho= wever, with not all that many of Roni's (as might be expected :) ) - to= be specific:

=A0

>Roni:

=

>Each encoding group include a list of individual encodes =A0(audio= and /or video). These provide maximum values that can be used to instantia= te a media stream by the provider.

=A0

Yes, I think that's a good = summary.

=A0

>Each video individual encode= s identified by an encodeID provides maximum values =A0for BW, compute, res= olution and frame rate for H.264. (BTW: the maxH264Mbps can be computed fro= m the resolution and frame rate as defined in table 2 making it redundant).=

>Each audio encode has only a BW value (no identifier).

=A0

Also agreed - apart from the H.264 point I think - a maximum res= olution and a maximum frame rate doesn't necessarily imply a maxMbps - = many systems can encode 1280x720 at some frame rate < 30 *or* some lower= resolution at up to 30fps without necessarily being able to send 720p30, s= urely?

=A0

=A0

> Roni:

= >A media capture is associated with an encoding group !!!!! not an indiv= idual encoding.

=A0

That's true, and by design.= To re-iterate the original design intent here, the idea behind the encodin= g groups idea was to be able to model 2 common Telepresence architectures w= e see today:

1) a multi-screen endpoint room comprised of multiple endpoints (most = vendors' "3 screen" systems, for instance, tend to be compose= d of 3 of their "1 screen" products linked together)

2) a flexible media generation system such as a software or hardware M= CU

=A0

For the "1)" case above, due to real-world constraints such = as camera wiring etc., it seemed to us that a media capture representing, s= ay, the left camera of 3, would only be able to be encoded by the hardware = it was directly connected to - thus, such a system would use one "enco= ding group" for its left constituent, one for its centre and one for i= ts right.

=A0

>Roni:

=A0

>The provider can use one of the individua= l encoding to instantiate a media capture, each individual encoding can be = used by one media capture, the decision of which one to use according to th= e framework is by the provider. The consumer does not select an individual = encode.

=A0

That was not the intent - it sh= ould be the consumer that chooses media capture / individual encoding pairs= to instantiate "capture encodings". When forming its configure m= essage, the consumer essentially supplies a set of media capture ID + encod= ing ID pairs to instruct the provider on which capture encodings to send. H= aving just re-read it, I think that the description as per Section 9 of the= current framework document described this well (though Mark deserves the c= redit for that, obviously!).

=A0

>Roni:=A0

=

>The maximum number of streams that can re= sult from a particular encoding group is equal to the number of individual = encodings in the group (note that this is why the example in the current da= ta model allows only for one video and one audio streams).

=A0

It is true that the number of s= treams that can result from a particular encoding group is equal to the num= ber of individual encodings in the group - however, a fully flexible system= might choose to have a single encoding group and so no real restriction ne= ed be introduced by this (unless the provider system has such restrictions = - in which case they can be modelled in this way).

= =A0

=A0

= >Roni:

=A0

>Section 8 of = the framework talk about having more than one individual encoding assigned = to a media capture (simulcast) and also claims that it can be done by the c= onsumer but there is no way to do it since the media capture is associated = only with an encoding group. There is no way for a consumer even to assign = a specific individual encoding to a group.

=A0

You're right that there'= ;s no way for the consumer to assign a specific individual encoding to a gr= oup, but it's not clear what the need is - if a provider system is suff= iciently flexible that any encoding can be used by any media capture, then = it should construct its advertisement to use just a single encoding group t= o comprise all encodings, at which point the consumer has greater flexibili= ty in which it can choose to be sent to it.

= =A0

=A0

>Roni:=A0

>The video is H.264 = specific and not general

=A0

The problem we had was that we = needed to come up with a way of describing a big block of video encoding ca= pability and how it could be subdivided. e.g. you might be able to send 2 x= 720p30 but not a single 720p60. The best scheme we could come up with was = to, for each of H.264, H.265 etc. include some specific parameters that wou= ld allow both a provider's overall capability to be signalled and how i= t might be subdivided across multiple encodings. It's true that current= ly the parameters only really work for H.264 and, moreover, only really wor= k for a provider sending all encodings within a group using the same codec,= but the expectation was that new codecs would have their own equivalent pa= rameters added here in a similar way.

= =A0

=A0

>Roni:

>The relation between t= he individual encode and encoding group makes it difficult to achieve a rea= sonable set even if the consumer will be able to select the mapping. This i= s due to the fact the total defined by the group limits the usage for indiv= idual encoding. For example if =A0we have a three camera system and we set = a value in the=A0 group for maxGroupH264Mbps and want to allow for simulcas= t (two resolutions), we will need to define six individual encodes, three w= ith high resolution ( also high maxH264Mbps) and three lower resolution wit= h lower maxH264Mbps. If the compute resource can do all six it will=A0 refl= ected in the value of maxGroupH264Mbps but I assume that there is a constra= in (otherwise why have encodings) making it lower. So if the consumer will = ask for all six what will happen. Since there is more than one degree of fr= eedom he will not be able to predict if he will get all or part on lower fr= ame rate , if he will get only a subset of the streams, if he will get diff= erent resolutions.

=A0

The situation you describe is, = I would argue, exactly what the parameters are for. The consumer would be a= llowed to ask for all 6, each with consumer-imposed maximum values. The pro= vider would be bound by its overall maxGroupH264Mbps as well as each indivi= dual encoding's max. value - in many senses this is no difference to ex= isting systems' balancing of bit rate across main and presentation limi= ts. I think if the consumer asks for all six then what will happen should b= e very predictable - 6 capture encodings will be sent to the consumer, with= each capped by the lower of the consumer's request parameters and the = provider's limitations. It is true that the frame rate / resolution wou= ld be bounded but not fixed, but this is true today on a video call - if yo= u can receive 720p30 you don't know whether the far end will send you 7= 20p30, 720p5, CIF30 etc. I'm not sure I see how what we're talking = about here does anything but follow normal encoder and decoder behavior as = seen today (equally, I confess that I may not be fully understanding the in= tricacies of the case you describe).

=A0

>On the other hand if the 6 i= ndividual encodes will include lower values to allow for the group limit it= will mean that a consumer not doing simulcast is limited by the fact the s= imulcast and ask (if possible) for only three streams, the individual encod= es limit will be low so he will not be able to use the full compute resourc= es.

=A0

>Roni:<= /p>

>Section 8 concludes that the number of in= dividual encodes in a group must allow for all media capture in a capture s= cene entry to be used simultaneously.

=A0

Yes, t= his is a corollary of the constraint that all media captures in a capture s= cene entry must be able to be provided simultaneously (which itself is a co= rollary of the idea that each capture scene entry is in itself a useful rep= resentation of the scene).

=A0

>So it look like this system = does not work well for simulcast. What about no simulcast, is it needed. Fo= r example a three camera system that also have one presentation. My view th= at the cameras will be one capture scene and the presentation will be a sec= ond one. The question is if they all belong to one encoding group, here my = view is =93no=94 since they have different priority and should not compete = for compute resources.

=A0

Another view is that if the pro= vider does encode the cameras and the presentation from the same pool of en= coding resource then it is valid for the consumer to choose which to priori= tise (i.e. the provider could leave the consumer to allocate encodings to t= he media captures).

=A0

>Roni:

>So we will have two encoding groups one f= or presentation and one for the three cameras. For the three cameras each s= ending one stream I assume that the resource allocation will be a third for= each so we will have three individual encode with the same values, this is= the basic one and if it is a third than no need for advertising or configu= ring. Now if we also want to have an individual encode that has higher comp= ute if the consumer wants only one capture (of the whole room), the group w= ill have fourth one with higher value. So if there is way for consumer to c= onfigure individual encode when using three media captures, he may select t= he higher capability one with two lower ones. The total will be limited by = the encoding group value and again it is not clear how the actual streams w= ill be encoded to address the group limit since there are multiple options.=

=A0

To my mind this is no different= to the sort of trace offs / choices that are already made in this sort of = system today - in a video call it is common to not be able to send a camera= stream at full resolution and full frame rate either because of bandwidth = limitations or the capabilities of the receiver. In the case you cite, yes,= the consumer could choose to impose different video limits on the left cen= ter and right cameras, but it would be within its rights to do so, just as = the provider would then be within its rights to send them all at the lowest= of the 3 levels.

=A0

>Roni:=A0

=

>To summarize I do not see value in the en= coding as currently specified since they only provide information and no op= tion for configuration. The value of it as information does not justify spe= cifying them and if the intention is to allow configurations of individual = encoding it must be reflected and the explained how it works.=

=A0

>Roni:=A0

>My proposal is at the moment to remove th= e encoding until we get some text that defines how to use it for configurin= g encoding to media captures including for the simulcast case=

=A0

I think I'd agree with you if it really were t= rue that simulcast was ill-defined here, but I think it's covered prett= y well. It's clear that you've thought about it in a lot of detail = though, so I'm sure there'll be more to discuss on this...

=A0

Regards,

=A0

Andy

=A0

=A0

On Thu, Nov= 1, 2012 at 4:38 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

(As co-chair)

Roni is proposing a significant= change here.

PLEASE carefully consider this and comment on it here = on the mailing list!

*If* this works and satisfies all objectives th= en it will be a helpful simplification. But it may be that simplifying thin= gs this way excludes some required behavior.

This is something that would benefit from discussion next week. But tha= t won't be helpful if people haven't already thought about it.
<= br>=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul



On 10/31/12 5:49 AM, Roni Even wrote:

=

Hi,

=A0From the email discussion it looks to me that the concept of = the
encoding as specified in the framework document is not clear. I will= try
to describe my understanding of sections 7 and 8 of the framework document and explain why I think that it is not important to CLUE as
spe= cified. I am looking for response if my understanding of the encoding
ba= sed on the framework is correct and how it will work for the examples
I will provide bellow

The purpose of the Encodings is to provide INF= ORMATION about the
provider abilities to send streams. This relates to t= he available
resources (compute and BW) of the providers.

The enc= odings are constructed from encoding groups and each encoding
group is include individual encodes.

The encoding group provide a va= lue for the total maximum BW and compute
H264Mbps (note that it is H.264= specific) of all the individual encodes
in the group that the provider = can use to send audio and video.

Each encoding group include a list of individual encodes =A0(audio and = /or
video). These provide maximum values that can be used to instantiate= a
media stream by the provider.

Each video individual encodes id= entified by an encodeID provides maximum
values =A0for BW, compute, resolution and frame rate for H.264. (BTW: themaxH264Mbps can be computed from the resolution and frame rate as
defi= ned in table 2 making it redundant).

Each audio encode has only a BW= value (no identifier).

A media capture is associated with an encoding group !!!!! not an
in= dividual encoding.

The provider can use one of the individual encodi= ng to instantiate a
media capture, each individual encoding can be used = by one media
capture, the decision of which one to use according to the framework is
= by the provider. The consumer does not select an individual encode.

= The maximum number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group (note
= that this is why the example in the current data model allows only for
o= ne video and one audio streams).

Section 8 of the framework talk abo= ut having more than one individual
encoding assigned to a media capture (simulcast) and also claims that itcan be done by the consumer but there is no way to do it since the mediacapture is associated only with an encoding group. There is no way for a<= br> consumer even to assign a specific individual encoding to a group.

M= y view is that this mechanism does not work and can be removed. The
reas= ons are given bellow

The encoding as currently specified is provided= as information since
there is no way to map one or more individual encoding to a specific
med= ia capture

The video is H.264 specific and not general

The re= lation between the individual encode and encoding group makes it
difficu= lt to achieve a reasonable set even if the consumer will be able
to select the mapping. This is due to the fact the total defined by the
= group limits the usage for individual encoding. For example if =A0we havea three camera system and we set a value in the =A0group for
maxGroupH= 264Mbps and want to allow for simulcast (two resolutions), we
will need to define six individual encodes, three with high resolution (also high maxH264Mbps) and three lower resolution with lower
maxH264Mbp= s. If the compute resource can do all six it will =A0reflected
in the va= lue of maxGroupH264Mbps but I assume that there is a constrain
(otherwise why have encodings) making it lower. So if the consumer will
= ask for all six what will happen. Since there is more than one degree offreedom he will not be able to predict if he will get all or part on
lower frame rate , if he will get only a subset of the streams, if he
wi= ll get different resolutions.

On the other hand if the 6 individual = encodes will include lower values
to allow for the group limit it will m= ean that a consumer not doing
simulcast is limited by the fact the simulcast and ask (if possible) foronly three streams, the individual encodes limit will be low so he willnot be able to use the full compute resources.

Section 8 concludes = that the number of individual encodes in a group
must allow for all media capture in a capture scene entry to be used
sim= ultaneously.

So it look like this system does not work well for simu= lcast. What about
no simulcast, is it needed. For example a three camera= system that also
have one presentation. My view that the cameras will be one capture
scen= e and the presentation will be a second one. The question is if they
all= belong to one encoding group, here my view is =93no=94 since they have
different priority and should not compete for compute resources. So we
w= ill have two encoding groups one for presentation and one for the three
= cameras. For the three cameras each sending one stream I assume that the resource allocation will be a third for each so we will have three
indiv= idual encode with the same values, this is the basic one and if it
is a = third than no need for advertising or configuring. Now if we also
want t= o have an individual encode that has higher compute if the
consumer wants only one capture (of the whole room), the group will havefourth one with higher value. So if there is way for consumer to
config= ure individual encode when using three media captures, he may
select the= higher capability one with two lower ones. The total will be
limited by the encoding group value and again it is not clear how the
ac= tual streams will be encoded to address the group limit since there
are = multiple options.

To summarize I do not see value in the encoding as= currently specified
since they only provide information and no option for configuration. Thevalue of it as information does not justify specifying them and if the
= intention is to allow configurations of individual encoding it must be
reflected and the explained how it works.

My proposal is at the mome= nt to remove the encoding until we get some
text that defines how to use= it for configuring encoding to media
captures including for the simulca= st case

Thanks

Roni Even


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

=


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

=A0

<= /blockquote>

--20cf300fafd7f42f3804cdd2ccf1-- From ietf@meetecho.com Fri Nov 9 09:05: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 C42B121F8759 for ; Fri, 9 Nov 2012 09:05:35 -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 E8bcxtjEoYQu for ; Fri, 9 Nov 2012 09:05:32 -0800 (PST) Received: from smtpdg9.aruba.it (smtpdg9.aruba.it [62.149.158.239]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD7A21F8749 for ; Fri, 9 Nov 2012 09:05:31 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV5S1k0140ELJoa01V5TVs; Fri, 09 Nov 2012 18:05:28 +0100 Message-ID: <509D37D4.8020103@meetecho.com> Date: Fri, 09 Nov 2012 18:05:24 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Meetecho session recording X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Nov 2012 17:05:35 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From mary.ietf.barnes@gmail.com Fri Nov 16 13:44: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 2D2E721F8B12 for ; Fri, 16 Nov 2012 13:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.425 X-Spam-Level: X-Spam-Status: No, score=-103.425 tagged_above=-999 required=5 tests=[AWL=0.173, 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 X8DBZKYyvSlh for ; Fri, 16 Nov 2012 13:44:42 -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 4743421F8AF7 for ; Fri, 16 Nov 2012 13:44:42 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2600981lah.31 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: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d040714afcf023904cea3ac8c Subject: [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: Fri, 16 Nov 2012 21:44:43 -0000 --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-- From mary.ietf.barnes@gmail.com Fri Nov 16 13:52: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 46D5C21F84C6 for ; Fri, 16 Nov 2012 13:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.429 X-Spam-Level: X-Spam-Status: No, score=-103.429 tagged_above=-999 required=5 tests=[AWL=0.169, 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 sE3Uik5+KePN for ; Fri, 16 Nov 2012 13:52:53 -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 5FB2B21F8B11 for ; Fri, 16 Nov 2012 13:52:53 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2684763lbk.31 for ; Fri, 16 Nov 2012 13:52:52 -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=QH5EwscRJXk3McM0fYgUFCARkzqC5Z6p+LWjoEzthYE=; b=QLWeYuhSWAX7+gg7Z/XJTGOCEjGMOw9YoFYLbk6Fb69SFiTquED8/IrqyyueMTX6eh 4Q4ExZebGgpJm1ZTsk49FnbwD9MIfZB/uXdXFvHrjj5g6DLtO96bT2sLVggjwMZg4M83 qj6nRNeYJtgPTii3qkRovYJeC1jcsOQk6FHHcAEggh5v66auVdba19x2Zd5aMIFJHoUz aGtjUhqHOsdC4TTMRXm/FqkkkjuscGFqcDxa7OCN46HISTUnsF5DJtXegNshaGPVp0Do vUQ77BX0OiKU3+rNcIpeg2ZaSXxCBiiMj7uu+7FkcZjj6ox0/3gSq9Y943Tc5XS3UwYX p0hw== MIME-Version: 1.0 Received: by 10.112.83.7 with SMTP id m7mr2579652lby.15.1353102772225; Fri, 16 Nov 2012 13:52:52 -0800 (PST) Received: by 10.114.69.139 with HTTP; Fri, 16 Nov 2012 13:52:52 -0800 (PST) Date: Fri, 16 Nov 2012 15:52:52 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=14dae9d717bc1547dd04cea3ca6b Subject: [clue] Summary WG deliverables with assignees X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2012 21:52:54 -0000 --14dae9d717bc1547dd04cea3ca6b Content-Type: text/plain; charset=ISO-8859-1 Hi all, As discussed at the IETF-85 meeting, we will be updating the CLUE WG milestones to include the following deliverables with the authors and contributors identified: - Framework: Stephan Wenger (refactoring), Andy Pepperell, Mark Duckwork - Data Model: Roberta Presta, Simon Pietro Romano, Christian Hoene - Signaling (CLUE & SDP): Rob Hansen, Roni Even, Simon, Roberta, Christer Holmberg - RTP mapping and usage: Roni, Jonathan Lennox - Call Flows: Lorenzo Miniero, Simon, Rob, Roni As identified at the meeting, there are several individual drafts related to each of these deliverables that can be used as a starting point for developing a document that can be considered as the basis for the WG deliverables. The following are the proposed milestones: May 2013 Use Case document (Informational) May 2013 Requirements document (Informational) May 2013 Framework (Standards Track) Oct 2013 Data Model document (Standards Track) Oct 2013 CLUE and SDP Signaling (Standards Track) Oct 2013 RTP Mapping (Standards Track) Oct 2013 Call Flows (Informational) Regards, Mary and Paul CLUE WG co-chairs --14dae9d717bc1547dd04cea3ca6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

As discussed at the IETF-85 meeting, we will be = updating the CLUE WG milestones to include the following deliverables with = the authors and contributors identified:=A0

- Fram= ework: =A0Stephan Wenger (refactoring), Andy Pepperell, Mark Duckwork
- Data Model: Roberta Presta, Simon Pietro Romano, Christian Hoene
- Signaling (CLUE & SDP): =A0Rob Hansen, Roni Even, Simon, Rober= ta, Christer Holmberg
- RTP mapping and usage: Roni, Jonathan Len= nox
- Call Flows: Lorenzo Miniero, Simon, Rob, Roni

As identified at the meeting, there are several individual drafts relate= d to each of these deliverables that can be used as a starting point for de= veloping a document that can be considered as the basis for the WG delivera= bles.=A0

The following are the proposed milestones:
May 2013 Use Case document (Informational)
May = 2013 Requirements document (Informational)
May 2013 Framework (St= andards Track)
Oct 2013 =A0 Data Model document (Standards Track)
Oct 2013 = =A0CLUE and SDP Signaling (Standards Track)
Oct 2013 =A0RTP Mappi= ng (Standards Track)=A0
Oct 2013 =A0Call Flows (Informational)

Regards,
Mary and Paul
=
CLUE WG co-chairs










--14dae9d717bc1547dd04cea3ca6b-- From Christian.Groves@nteczone.com Thu Nov 22 19:56:03 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ABC21F85C1 for ; Thu, 22 Nov 2012 19:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 l6Pje9POAcAq for ; Thu, 22 Nov 2012 19:56:03 -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 E32A621F85BC for ; Thu, 22 Nov 2012 19:56:02 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4GAKnyrlB20TEU/2dsb2JhbAANN78pBAOBFGyCZBsfBj0WGAMCAQIBSw0IAQG0P5NAkHgDqUY Received: from ppp118-209-49-20.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.49.20]) by ipmail06.adl6.internode.on.net with ESMTP; 23 Nov 2012 14:26:00 +1030 Message-ID: <50AEF3CB.7020904@nteczone.com> Date: Fri, 23 Nov 2012 14:55: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 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, 23 Nov 2012 03:56:03 -0000 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. 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. 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..." - 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...." - 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.". - 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." 4) The framework uses the terms "media provider" and "provider". We probably should be consistent in the use of the term throughout the framework. 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. Thoughts? Regards, Christian From christer.holmberg@ericsson.com Sat Nov 24 06:54:03 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695EC21F855B for ; Sat, 24 Nov 2012 06:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=0.227, 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 RCutaIqbCsO9 for ; Sat, 24 Nov 2012 06:54:02 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 37F3021F8553 for ; Sat, 24 Nov 2012 06:54:02 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-b4-50b0df880165 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A5.B3.11564.88FD0B05; Sat, 24 Nov 2012 15:54:01 +0100 (CET) Received: from ESESSHC008.ericsson.se (153.88.183.42) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sat, 24 Nov 2012 15:54:00 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0318.001; Sat, 24 Nov 2012 15:54:00 +0100 From: Christer Holmberg To: 'Christian Groves' , "clue@ietf.org" Thread-Topic: [clue] Capture scene clarifications Thread-Index: AQHNyS6CrQlen+NBOkeUtOGFfioJz5f5E0wg Date: Sat, 24 Nov 2012 14:53:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B044380@ESESSMB209.ericsson.se> 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: 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+NgFrrBLMWRmVeSWpSXmKPExsUyM+JvjW7n/Q0BBqtamCy+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJXx49t11oJm3YqNZ0+yNTBuUu5i5OSQEDCR +LP1ASuELSZx4d56ti5GLg4hgZOMEudaWtghnJ2MEvsO/2WCcJYwSsz49Jqxi5GDg03AQqL7 nzZIt4hApMSc/5/ZQGxhAQOJkx9vsEPEDSW2LpnDCmEbSfy+eI4FxGYRUJVY2tHACGLzCnhL XNt7mx1kpJCAtsTDqcYgYU4BHYk7Xx8wg9iMQMd9P7WGCcRmFhCXuPVkPhPE0QISS/acZ4aw RSVePv4H9YyixM6z7cwQ9ToSC3Z/YoOwtSWWLXzNDLFWUOLkzCdg54CsbVk8gX0Co/gsJCtm IWmfhaR9FpL2BYwsqxjZcxMzc9LLDTcxAmPn4JbfujsYT50TOcQozcGiJM7LlbTfX0ggPbEk NTs1tSC1KL6oNCe1+BAjEwenVAPjjIuurPxAJ5tF+FpXX6vladA5EVXHtXvy2Tmf30ezLl3z JZ8pJCO3Tf/28dxZAuvOHEr+Finl2aDfEHTptUpUteMBAZV7Ls0abiIRK1cq+FhOv8fBfnTf y/mXpa79fbRiY/DrI5pyzhInXjPUdU9PWbX5+VrrRwVsLiF32H9N2fZyebea4BIlluKMREMt 5qLiRAApdQluawIAAA== 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, 24 Nov 2012 14:54:03 -0000 Hi Christian, If one intention is to clarify that a capture scene entry represents a whil= e scene, why not remove "capture", and simply call it "scene entry", or som= ething... And, as the defintion for "scene" already talks about media captures, we co= uld remove "media capture" from the definition of "scene entry", and say: "A list of alternative representations of a single scene" ...or something like that. I think things would be more clear if we try to keep "capture" and "scene" = apart from each other. Regards, Christer=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= istian Groves Sent: 23. marraskuuta 2012 5:56 To: clue@ietf.org Subject: [clue] Capture scene clarifications Hello, Paul K reminded me that I have an action point from the interim meeting reg= arding 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 i= ntent 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 f= ollowing 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. 2) Update the definition of "Capture scene entry" to make it clearer that i= t 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. 3) Update section 6.2 on Capture scenes to reflect the above intents.=20 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 cap= ture scene..." - 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...." - 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.". - 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 p= aragraph. "A consumer may receive an advertisement with multiple capture scenes.=20 A consumer may choose to receive any number of capture scenes. An advertise= d capture scene it may contain one of more capture scene entries that may c= ontain one of more media captures. A consumer may choose an capture scene e= ntry 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 en= try rather than choosing individual captures from multiple capture scene en= tries. 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." 4) The framework uses the terms "media provider" and "provider". We probabl= y should be consistent in the use of the term throughout the framework. 5) Related to the "capture group" concept that didn't seem to get support i= s the ordering in the Capture scene, Capture scene entry, Media captures. T= here was some discussion that people had assumed some sort of prioritisatio= n / ordering related to these structures. i.e. If I have a capture scene en= try VC0, VC1, VC2 do I assume they should be rendered left to right or is t= here 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 proba= bly should also add something for that. Thoughts? Regards, Christian _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Mon Nov 26 07:12: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 7A8BF21F8469 for ; Mon, 26 Nov 2012 07:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qgo0V1Ssgqc for ; Mon, 26 Nov 2012 07:12:30 -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 57ACE21F8461 for ; Mon, 26 Nov 2012 07:12:27 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so9242701lah.31 for ; Mon, 26 Nov 2012 07:12:26 -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=MOD56pwcml7NOlzbLlsTrUhSU2Ts8PVRg0DhRv9SydA=; b=nh4ZBq581+C93VRjJIQndNVxUqk7HB/x7cwsxkuD189QQM6ckjznM4eponq74xYdiB xjjQeRnX6rfRBuMI472ni4Mk3NyvrVp1NSrVdcc4/0XdtogVE2d+pI/1v80fgcOQZxLI G3uwn4/q30NY+X4RlqwUUEQSYuNQbJixQWr2NQYrE2r3vcalL1WZF26BrSQlY2ia8iQw beljaIOE1y/HmnAxwdIcFrVCzmVestbW0KzODzOIHGxIXijVDZWSXktnCn+4pILzuPfP H6JWQhjddm796h8ja1Hx9jtMRbtN1d3OFPzM2xvlz2Lb12TWwHDCSJLo1QY7T46yDYqM QlFA== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr11343329lab.11.1353942746209; Mon, 26 Nov 2012 07:12:26 -0800 (PST) Received: by 10.114.62.73 with HTTP; Mon, 26 Nov 2012 07:12:26 -0800 (PST) Date: Mon, 26 Nov 2012 09:12:26 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d04088ef56f1c8804cf675c9c Subject: [clue] No CLUE Design team meeting today (Nov 26) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Nov 2012 15:12:31 -0000 --f46d04088ef56f1c8804cf675c9c Content-Type: text/plain; charset=ISO-8859-1 Hi all, Per the schedule below, the plan was to get an update on the RTP convergence. However, there has not yet been enough progress to report back. So, we will cancel this week's meeting. Mary. On Fri, Nov 16, 2012 at 3:44 PM, Mary Barnes wrote: > 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 > --f46d04088ef56f1c8804cf675c9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Per the schedule below, the plan was to get an u= pdate on the RTP convergence. =A0However, there has not yet been enough pro= gress to report back. =A0So, we will cancel this week's meeting.
<= div>
Mary.


On Fri, Nov 16, 2012 at 3:44 PM, Mary Barnes &= lt;mary.iet= f.barnes@gmail.com> wrote:
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 w= ill 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 who= le week. =A0I have jury duty on the 10th, so we'll skip that unless som= eone has something compelling they 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

--f46d04088ef56f1c8804cf675c9c-- From pkyzivat@alum.mit.edu Mon Nov 26 07:14: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 748B921F85A6 for ; Mon, 26 Nov 2012 07:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 uBqLccyAp0Xi for ; Mon, 26 Nov 2012 07:14:25 -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 D5C1321F8469 for ; Mon, 26 Nov 2012 07:14:24 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id UDbY1k0021uE5Es54FEQQj; Mon, 26 Nov 2012 15:14:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id UFEP1k01f3ZTu2S3cFEQBK; Mon, 26 Nov 2012 15:14:24 +0000 Message-ID: <50B38773.6080206@alum.mit.edu> Date: Mon, 26 Nov 2012 10:14:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <50AEF3CB.7020904@nteczone.com> In-Reply-To: <50AEF3CB.7020904@nteczone.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, 26 Nov 2012 15:14:25 -0000 Christian, Thanks for providing these. They all seem reasonable to me, with one exception: On 11/22/12 10:55 PM, Christian Groves wrote: [snip] > - 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. Above seems ok. > 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." This doesn't cover the intent as I understand it. We certainly don't intend to require that a receiver request captures that it intends to ignore. Selecting a subset of the captures in a capture scene entry is ok if that is what the receiver wants to do, even though it may result in an incomplete rendering of the scene. Also, it is ok to select some or all of the captures from multiple capture scene entries if that is what you really want to do. This might be unusual behavior for an endpoint, but not forbidden. It might be entirely reasonable for a MCU to do this. This is all in the spirit of the sender not trying to second guess what the receiver might want to do. Thanks, Paul From pkyzivat@alum.mit.edu Mon Nov 26 08:02: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 29E3621F8569 for ; Mon, 26 Nov 2012 08:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Ku0fe+d2qxJM for ; Mon, 26 Nov 2012 08:02:11 -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 7879F21F855C for ; Mon, 26 Nov 2012 08:02:11 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta05.westchester.pa.mail.comcast.net with comcast id UBWt1k0041vXlb855G2AnE; Mon, 26 Nov 2012 16:02:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id UG2A1k0163ZTu2S3dG2Ag4; Mon, 26 Nov 2012 16:02:10 +0000 Message-ID: <50B39282.1080202@alum.mit.edu> Date: Mon, 26 Nov 2012 11:02:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] cancelling CLUE Design Team meeting for today X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Nov 2012 16:02:12 -0000 It seems people weren't ready to discussed the planned topic yet. And some people have been away and are just catching up anyway. Meanwhile - please keep working on things. Also, there are relevant discussions going on on the mmusic mailing list. I suggest all the clueful pay attention to that. Note the thread with subject "RFC 5576 is da answah". Thanks, Paul From pkyzivat@alum.mit.edu Mon Nov 26 08:30: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 4BCF321F85C2 for ; Mon, 26 Nov 2012 08:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, 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 cygZgDWX62-U for ; Mon, 26 Nov 2012 08:30:28 -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 6396C21F85AE for ; Mon, 26 Nov 2012 08:30:27 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id UCjD1k00C1YDfWL53GWS5U; Mon, 26 Nov 2012 16:30:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id UGWS1k00Y3ZTu2S3gGWSo8; Mon, 26 Nov 2012 16:30:26 +0000 Message-ID: <50B39921.6030903@alum.mit.edu> Date: Mon, 26 Nov 2012 11:30:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] CLUE-specific SDP discussion in MMUSIC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Nov 2012 16:30:29 -0000 There has been considerable discussion on the MMUSIC list of SDP issues important to CLUE. This has come up primarily in the context of RTCWEB. It is becoming increasingly clear that CLUE and RTCWEB both have needs for RTP multiplexing that are similar and go beyond common and well defined usage. So we both are inventing solutions, and we need to work together on this. There are a few people in common to the two groups. More would be better. We can use more people following and contributing to these discussions. A recent relevant discussion can be found at: http://www.ietf.org/mail-archive/web/mmusic/current/msg09933.html Thanks, Paul From christer.holmberg@ericsson.com Mon Nov 26 11:30: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 46BA521F8517 for ; Mon, 26 Nov 2012 11:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 fcs-pnmGpGr6 for ; Mon, 26 Nov 2012 11:30:01 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 443F221F8509 for ; Mon, 26 Nov 2012 11:30:01 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-a4-50b3c3375d5f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E0.C0.11564.733C3B05; Mon, 26 Nov 2012 20:30:00 +0100 (CET) Received: from ESESSHC004.ericsson.se (153.88.183.30) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 26 Nov 2012 20:30:00 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 20:29:59 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , "clue@ietf.org" Thread-Topic: [clue] Capture scene clarifications Thread-Index: AQHNy+i8zk8+n3np90eOVjDiWPg3K5f8f/kg Date: Mon, 26 Nov 2012 19:29:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> In-Reply-To: <50B38773.6080206@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+Jvja7F4c0BBpOu8VjsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGz/mTGQvOcVUs37SduYFxE0cXIweHhICJ xIRrCl2MnECmmMSFe+vZuhi5OIQETjJKHD63nRHC2ckocXTdBkaQKiGBJYwSnxepgzSzCVhI dP/TBgmLCHhLLPq0iBnEFhYwkDj58QY7RNxQYuuSOawg5SICRhLf5maDhFkEVCU23X4IVsIL 1Hrg/WFmiOneEu9XPAbbxCmgI9H+4h2YzQh02/dTa5hAbGYBcYlbT+YzQdwsILFkz3lmCFtU 4uXjf6wQtqLEzrPtzBD1OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywQe7UlWhZPYJ/AKD4LyYpZ SNpnIWmfhaR9ASPLKkb23MTMnPRyw02MwLg5uOW37g7GU+dEDjFKc7AoifNyJe33FxJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cAY3/ZwwdTmxoXmL9ce3hjCOKPHVPnSx7DwosuPTaYJxSzm OCx+tY3hJVtys6y4z/aQVzyLGANnC1U9W69zY/o6wTCLmYz8ls1/jk7L/PhC/ootnwlfwfSF m5c5vtXZlfTkbH5R4hO5ddyWt858XOQtlOumcmVHuGfRGadO13ORr5/M+npyEd8+JZbijERD Leai4kQAKXnWpGkCAAA= 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, 26 Nov 2012 19:30:02 -0000 Hi,=20 >> For a particular media type the >> 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." > > This doesn't cover the intent as I understand it. > > We certainly don't intend to require that a receiver request captures tha= t it intends to ignore. Selecting a subset=20 > of the captures in a capture scene entry is ok if that is what the receiv= er wants to do, even though it may result=20 > in an incomplete rendering of the scene. I guess I would be ok with that. > Also, it is ok to select some or all of the captures from multiple captur= e scene entries if that is what you really=20 > want to do. This might be unusual behavior for an endpoint, but not forbi= dden. It might be entirely reasonable for a=20 > MCU to do this. Doesn't that complicate things, for no obvious reason? How does one know that the provider even is able to submit captures from di= fferent entries (e.g. maybe the same physical camera is used for different = things, depending on which capture scene entry is "active")? We would need = to have lots of ANDs, ORs and XORs... Regards, Christer From pkyzivat@alum.mit.edu Mon Nov 26 11:57: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 C85A921F8524 for ; Mon, 26 Nov 2012 11:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, 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 QdDBYsYLbV6I for ; Mon, 26 Nov 2012 11:57:41 -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 28C4F21F851E for ; Mon, 26 Nov 2012 11:57:39 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id UBvw1k00E1c6gX853Kxfrh; Mon, 26 Nov 2012 19:57:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id UKxe1k00t3ZTu2S3jKxfLq; Mon, 26 Nov 2012 19:57:39 +0000 Message-ID: <50B3C9B2.3030100@alum.mit.edu> Date: Mon, 26 Nov 2012 14:57:38 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> 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, 26 Nov 2012 19:57:41 -0000 On 11/26/12 2:29 PM, Christer Holmberg wrote: > > Hi, > >>> 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." >> >> This doesn't cover the intent as I understand it. >> >> We certainly don't intend to require that a receiver request captures that it intends to ignore. Selecting a subset >> of the captures in a capture scene entry is ok if that is what the receiver wants to do, even though it may result >> in an incomplete rendering of the scene. > > I guess I would be ok with that. > >> Also, it is ok to select some or all of the captures from multiple capture scene entries if that is what you really >> want to do. This might be unusual behavior for an endpoint, but not forbidden. It might be entirely reasonable for a >> MCU to do this. > > Doesn't that complicate things, for no obvious reason? Some reasons: - an MCU that selects multiple scene entries from an endpoint may be able to advertise more flexible alternatives in its own advertisements. - an endpoint might find that every capture scene entry has more captures than it can handle, so it is forced to choose some incomple representation of the scene. It may be that choosing selected captures from different scene entries might be more useful to it than selecting a subset of captures from a single entry. - a user of an endpoint with good flexible UI controls may be able to browse the entire advertisement and pick what he likes. > How does one know that the provider even is able to submit captures from different entries (e.g. maybe the same physical camera is used for different things, depending on which capture scene entry is "active")? We would need to have lots of ANDs, ORs and XORs... The simultaneous transmission set is supposed to provide this information. I thought it was good when Christian came along and gave a fresh perspective on this without having lived through all the discussions that led up to the framework as it is. So he was pointing out holes ambiguities in the text. But I find it very interesting that even people who have been involved for a long time are disagreeing about what is supposedly settled ground. Thanks, Paul > Regards, > > Christer > > From Christian.Groves@nteczone.com Mon Nov 26 20:12: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 6551721F8484 for ; Mon, 26 Nov 2012 20:12:48 -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 dCPc56T92pPe for ; Mon, 26 Nov 2012 20:12:47 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 004E521F8413 for ; Mon, 26 Nov 2012 20:12:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcDANI8tFB20XYl/2dsb2JhbAANN78YBAOEMAEBAQQBAQE1GxsEBgEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBAYgVrEiDLZA1BIw3hEEDqUg Received: from ppp118-209-118-37.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.118.37]) by ipmail07.adl2.internode.on.net with ESMTP; 27 Nov 2012 14:42:42 +1030 Message-ID: <50B43DB9.9040209@nteczone.com> Date: Tue, 27 Nov 2012 15:12: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: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <7594FB04B1934943A5C02806D1A2204B044380@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B044380@ESESSMB209.ericsson.se> 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: Tue, 27 Nov 2012 04:12:48 -0000 Hello Christer, I'm all for simplifying things. If we can use one term throughout the draft instead of two closely related ones I think it would be good. However can we completely decouple "scene" and "capture" after all a set of captures basically constitutes a scene? Regards, Christian On 25/11/2012 1:53 AM, Christer Holmberg wrote: > Hi Christian, > > If one intention is to clarify that a capture scene entry represents a while scene, why not remove "capture", and simply call it "scene entry", or something... > > And, as the defintion for "scene" already talks about media captures, we could remove "media capture" from the definition of "scene entry", and say: > > "A list of alternative representations of a single scene" > > ...or something like that. > > I think things would be more clear if we try to keep "capture" and "scene" apart from each other. > > Regards, > > Christer > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 23. marraskuuta 2012 5:56 > 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. > > 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. > > 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..." > > - 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...." > > - 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." > > 4) The framework uses the terms "media provider" and "provider". We probably should be consistent in the use of the term throughout the framework. > > 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. > > Thoughts? > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Nov 26 20:51: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 B394A21F8479 for ; Mon, 26 Nov 2012 20:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 GlkOrnL-Uv8U for ; Mon, 26 Nov 2012 20:51:18 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id C0DC921F844D for ; Mon, 26 Nov 2012 20:51:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAHBGtFB20XYl/2dsb2JhbAANMQbDUgEBAQMBAQEBNRsbChELGAkWDwkDAgECARUwEwYCAQGIAxKsSoMtkDcEjDMnhBoDqUg Received: from ppp118-209-118-37.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.118.37]) by ipmail07.adl2.internode.on.net with ESMTP; 27 Nov 2012 15:20:51 +1030 Message-ID: <50B446A8.2010307@nteczone.com> Date: Tue, 27 Nov 2012 15:50: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> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> In-Reply-To: <50B3C9B2.3030100@alum.mit.edu> 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: Tue, 27 Nov 2012 04:51:18 -0000 Hello Paul, I had the same thoughts as Christer. Picking a subset is something that I could live with, cherry picking captures from different capture scene entries I think is complicating the issue. The framework says that provider must be able to supply media related to all the captures within a capture scene entry. If the consumer chooses different captures then the provider may not be able to supply these? Do we then need an extra message for the provider to signal to the consumer that it can't honour its choice? Regards, Christian On 27/11/2012 6:57 AM, Paul Kyzivat wrote: > On 11/26/12 2:29 PM, Christer Holmberg wrote: >> >> Hi, >> >>>> 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." >>> >>> This doesn't cover the intent as I understand it. >>> >>> We certainly don't intend to require that a receiver request >>> captures that it intends to ignore. Selecting a subset >>> of the captures in a capture scene entry is ok if that is what the >>> receiver wants to do, even though it may result >>> in an incomplete rendering of the scene. >> >> I guess I would be ok with that. >> >>> Also, it is ok to select some or all of the captures from multiple >>> capture scene entries if that is what you really >>> want to do. This might be unusual behavior for an endpoint, but not >>> forbidden. It might be entirely reasonable for a >>> MCU to do this. >> >> Doesn't that complicate things, for no obvious reason? > > Some reasons: > > - an MCU that selects multiple scene entries from an endpoint may be > able to advertise more flexible alternatives in its own advertisements. [CNG] Are you inferring that CLUE is an end-to-end protocol? I would see in this case the MCU would simply construct its own advertisement. The original provider can only provide what it can provide irrespective of what a MCU would subsequently offer. > > - an endpoint might find that every capture scene entry has more > captures than it can handle, so it is forced to choose some incomple > representation of the scene. It may be that choosing selected captures > from different scene entries might be more useful to it than selecting > a subset of captures from a single entry. [CNG] How will the consumer know that it can provide these captures from different entries at once? Given the current attributes for captures I'm not sure that a consumer would know enough to determine that a group of different captures from multiple capture scene entries constitutes an entire scene. If we say the consumer is smart enough to determine this then why bother with the capture scene entry concept? > > > - a user of an endpoint with good flexible UI controls may be able to > browse the entire advertisement and pick what he likes. [CNG] In theory yes but at this point there won't be any video/audio so unless the user is knowledgeable in XML I don't see that they'd go down to the individual capture level. > >> How does one know that the provider even is able to submit captures >> from different entries (e.g. maybe the same physical camera is used >> for different things, depending on which capture scene entry is >> "active")? We would need to have lots of ANDs, ORs and XORs... > > The simultaneous transmission set is supposed to provide this > information. [CNG] This does say that the consumer "must make sure that it chooses one and not more of the mutually exclusive sets"? Also is the sending of a simultaneous transmission set mandatory? > > I thought it was good when Christian came along and gave a fresh > perspective on this without having lived through all the discussions > that led up to the framework as it is. So he was pointing out holes > ambiguities in the text. [CNG] Well I have followed discussions on the mailing list, I think it was attending the Andover CLUE interim where I think it became apparent people had slightly different understandings. > > But I find it very interesting that even people who have been involved > for a long time are disagreeing about what is supposedly settled ground. [CNG] :-) > > Thanks, > Paul > >> Regards, >> >> Christer >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Nov 26 21:25: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 5B3D821F84BC for ; Mon, 26 Nov 2012 21:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Q-b2E8q+TRC1 for ; Mon, 26 Nov 2012 21:25:00 -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 742A921F84BA for ; Mon, 26 Nov 2012 21:24:59 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id UUmD1k00W1c6gX853VQyR4; Tue, 27 Nov 2012 05:24:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id UVQx1k00U3ZTu2S3jVQyNu; Tue, 27 Nov 2012 05:24:58 +0000 Message-ID: <50B44EA9.30707@alum.mit.edu> Date: Tue, 27 Nov 2012 00:24:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> <50B446A8.2010307@nteczone.com> In-Reply-To: <50B446A8.2010307@nteczone.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: Tue, 27 Nov 2012 05:25:01 -0000 On 11/26/12 11:50 PM, Christian Groves wrote: > Hello Paul, Disclaimer - AFAIK I am simply restating the intent of the framework as it stands. These were not my concepts. But I think I have assimilated the intent. So it is certainly possible to recast this stuff, but then I think there will need to be some further discussion to fully understand the ramifications of such a change. > I had the same thoughts as Christer. Picking a subset is something that > I could live with, cherry picking captures from different capture scene > entries I think is complicating the issue. Certainly one can argue about how one would know enough to make such a choice. But I don't see why it is a "complication" from the point of view of the provider. > The framework says that > provider must be able to supply media related to all the captures > within a capture scene entry. If the consumer chooses different captures > then the provider may not be able to supply these? Do we then need an > extra message for the provider to signal to the consumer that it can't > honour its choice? The simultaneous transmission sets are intended to indicate what can be transmitted simultaneously. The advertiser should thus be able to transmit any selection that is in accord with the advertisement. The specification that the provider must be able to supply media related to all captures within a scene entry is simply a further constraint on the provider. Once the provider has constructed its advertisement to reflect its constraints, it should be no extra complication to supply any conforming selection, regardless of which scene entries the captures come from. Perhaps making a limitation of only selecting from one scene entry per scene might simplify the advertisement - perhaps eliminating the need for the simultaneous transmission set. Or it might simplify the choice of configuration. But neither of these seems like enough of a complication to worry about. So ISTM that such a change will need to be based on esthetics and conceptual simplicity. Thanks, Paul > Regards, Christian > > > On 27/11/2012 6:57 AM, Paul Kyzivat wrote: >> On 11/26/12 2:29 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>>>> 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." >>>> >>>> This doesn't cover the intent as I understand it. >>>> >>>> We certainly don't intend to require that a receiver request >>>> captures that it intends to ignore. Selecting a subset >>>> of the captures in a capture scene entry is ok if that is what the >>>> receiver wants to do, even though it may result >>>> in an incomplete rendering of the scene. >>> >>> I guess I would be ok with that. >>> >>>> Also, it is ok to select some or all of the captures from multiple >>>> capture scene entries if that is what you really >>>> want to do. This might be unusual behavior for an endpoint, but not >>>> forbidden. It might be entirely reasonable for a >>>> MCU to do this. >>> >>> Doesn't that complicate things, for no obvious reason? >> >> Some reasons: >> >> - an MCU that selects multiple scene entries from an endpoint may be >> able to advertise more flexible alternatives in its own advertisements. > [CNG] Are you inferring that CLUE is an end-to-end protocol? I would see > in this case the MCU would simply construct its own advertisement. The > original provider can only provide what it can provide irrespective of > what a MCU would subsequently offer. >> >> - an endpoint might find that every capture scene entry has more >> captures than it can handle, so it is forced to choose some incomple >> representation of the scene. It may be that choosing selected captures >> from different scene entries might be more useful to it than selecting >> a subset of captures from a single entry. > [CNG] How will the consumer know that it can provide these captures from > different entries at once? Given the current attributes for captures I'm > not sure that a consumer would know enough to determine that a group of > different captures from multiple capture scene entries constitutes an > entire scene. If we say the consumer is smart enough to determine this > then why bother with the capture scene entry concept? > >> >> >> - a user of an endpoint with good flexible UI controls may be able to >> browse the entire advertisement and pick what he likes. > [CNG] In theory yes but at this point there won't be any video/audio so > unless the user is knowledgeable in XML I don't see that they'd go down > to the individual capture level. >> >>> How does one know that the provider even is able to submit captures >>> from different entries (e.g. maybe the same physical camera is used >>> for different things, depending on which capture scene entry is >>> "active")? We would need to have lots of ANDs, ORs and XORs... >> >> The simultaneous transmission set is supposed to provide this >> information. > [CNG] This does say that the consumer "must make sure that it chooses one > and not more of the mutually exclusive sets"? Also is the sending of > a simultaneous transmission set mandatory? > >> >> I thought it was good when Christian came along and gave a fresh >> perspective on this without having lived through all the discussions >> that led up to the framework as it is. So he was pointing out holes >> ambiguities in the text. > [CNG] Well I have followed discussions on the mailing list, I think it > was attending the Andover CLUE interim where I think it became apparent > people had slightly different understandings. >> >> But I find it very interesting that even people who have been involved >> for a long time are disagreeing about what is supposedly settled ground. > [CNG] :-) >> >> Thanks, >> Paul >> >>> 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 Tue Nov 27 00:48: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 D358621F8532 for ; Tue, 27 Nov 2012 00:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 wx-DM+m0clMg for ; Tue, 27 Nov 2012 00:48:42 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 947A821F8530 for ; Tue, 27 Nov 2012 00:48:41 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-c3-50b47e67b4ff Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F3.A2.11564.76E74B05; Tue, 27 Nov 2012 09:48:39 +0100 (CET) Received: from ESESSHC007.ericsson.se (153.88.183.39) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 27 Nov 2012 09:48:39 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 09:48:39 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [clue] Capture scene clarifications Thread-Index: AQHNy+i8zk8+n3np90eOVjDiWPg3K5f8f/kg///4BACAAOZO8A== Date: Tue, 27 Nov 2012 08:48:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0464D7@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> In-Reply-To: <50B3C9B2.3030100@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+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvjW563ZYAgyl9Jhb7T11mtlix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxfUN2wUmxiqObXzM3MP4V7GLk5JAQMJE4 0nuKDcIWk7hwbz2QzcUhJHCSUeLVlWZGCGcno8SGiQdZQaqEBJYwSjzaFN3FyMHBJmAh0f1P G8QUEdCQmLRVDaSCWUBZ4mvDJiYQW1jAQOLkxxvsILaIgKHE1iVzWCFsJ4mWFavB4iwCqhJ7 P3aDxXkFvCWu75/CDrF2PaPEuV8PGEESnAI6EvPuXGQGsRmBDv1+ag0TxDJxiVtP5jNBPCAg sWTPeWYIW1Ti5eN/rBC2osTOs+3MEPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBAvaku0LJ7A PoFRYhaSFbOQtM9C0j4LSfsCRpZVjOy5iZk56eWGmxiBEXVwy2/dHYynzokcYpTmYFES5+VK 2u8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVFsE8+F00v1tAqtKnh5Kj4bL/t9WmXzg/RF ns0/zjpJ+kUz2OVq7bzU++MT4521xzVU/IUnXe2ZfEhC77/Q6cdT9swTslJVVctu1TcInrNZ qc2ka8vjFL2Ty8xUbD0XvFWz/HUg9GmDYJJDTOE9x437jl722hkwSaK28BybFoOEqZ26uPuD A0osxRmJhlrMRcWJADt68812AgAA 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: Tue, 27 Nov 2012 08:48:42 -0000 Hi, >>>> For a particular media type the >>>> consumer shall choose one capture scene entry rather than choosing=20 >>>> individual captures from multiple capture scene entries. However=20 >>>> this does not mean that a consuming endpoint must render all the=20 >>>> media captures. What is locally rendered and how is a local decision." >>> >>> This doesn't cover the intent as I understand it. >>> >>> We certainly don't intend to require that a receiver request captures=20 >>> that it intends to ignore. Selecting a subset of the captures in a=20 >>> capture scene entry is ok if that is what the receiver wants to do, eve= n though it may result in an incomplete rendering of the scene. >> >> I guess I would be ok with that. >> >>> Also, it is ok to select some or all of the captures from multiple=20 >>> capture scene entries if that is what you really want to do. This=20 >>> might be unusual behavior for an endpoint, but not forbidden. It might = be entirely reasonable for a MCU to do this. >> >> Doesn't that complicate things, for no obvious reason? > > Some reasons: > > - an MCU that selects multiple scene entries from an endpoint may be able= to advertise more flexible alternatives in its own advertisements. > > - an endpoint might find that every capture scene entry has more captures= than it can handle, so it is forced to choose some incomple representation= of the scene. It may be that choosing selected captures from different sce= ne entries might be more=20 >useful to it than selecting a subset of captures from a single entry. > >- a user of an endpoint with good flexible UI controls may be able to brow= se the entire advertisement and pick what he likes. Those reasons are all theoretical, in my view. If the provider advertises a= wide range of capture scene entries, I am sure the consumer will find a su= itable one - especially if it also can selects specific captures of the cap= ture scene entry. >> How does one know that the provider even is able to submit captures from= different entries (e.g. maybe the same physical camera is used=20 >> for different things, depending on which capture scene entry is "active"= )? We would need to have lots of ANDs, ORs and XORs... > > The simultaneous transmission set is supposed to provide this information= . > > I thought it was good when Christian came along and gave a fresh perspect= ive on this without having lived through all the discussions that led up to= the framework as it is. So he was pointing out holes ambiguities in the te= xt. > > But I find it very interesting that even people who have been involved fo= r a long time are disagreeing about what is supposedly settled ground. I think I DID express concern about selecting stuff from different capture = scene entries at that last interim. Regards, Christer From christer.holmberg@ericsson.com Tue Nov 27 01:06: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 80F9221F84D7 for ; Tue, 27 Nov 2012 01:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 U-3e9REdyvco for ; Tue, 27 Nov 2012 01:06:20 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 78A0B21F84D0 for ; Tue, 27 Nov 2012 01:06:19 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-8c-50b482894f4a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 18.9B.06323.98284B05; Tue, 27 Nov 2012 10:06:17 +0100 (CET) Received: from ESESSHC003.ericsson.se (153.88.183.27) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 27 Nov 2012 10:06:15 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 10:06:15 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Capture scene clarifications Thread-Index: AQHNy+i8zk8+n3np90eOVjDiWPg3K5f8f/kg///4BACAAJT3AIAACYqAgABKBzA= Date: Tue, 27 Nov 2012 09:06:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B046501@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> <50B446A8.2010307@nteczone.com> <50B44EA9.30707@alum.mit.edu> In-Reply-To: <50B44EA9.30707@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+NgFrrJLMWRmVeSWpSXmKPExsUyM+JvjW5n05YAg383tS32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj9K3lbAUHxSsmN55lbGC8LdTFyMkhIWAi seTyHyYIW0ziwr31bF2MXBxCAicZJXpvb2KBcHYySiy+P5UVpEpIYAmjxO2Nll2MHBxsAhYS 3f+0QcIiAp4SOz5OYQaxhQUMJE5+vMEOETeU2LpkDiuE7Sfx69Q8sDiLgKrE6U6QZZwcvALe EpevnGeC2PWeUWJmwzuwBk4BLYljfZsYQWxGoOu+n1oDdimzgLjErSfzoa4WkFiy5zwzhC0q 8fLxP1YIW1Fi59l2Zoh6HYkFuz+xQdjaEssWvmaGWCwocXLmExaIv7QlWhZPYJ/AKD4LyYpZ SNpnIWmfhaR9ASPLKkb23MTMnPRy802MwOg5uOW3wQ7GTffFDjFKc7AoifPqqe73FxJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cCoePnqmT2FMgdVTTVU+xtuRRw6tcS71iZgafBKtjMHdScm RrVPNijMVqzM2K7k3Dtn5oqVZStr982x1tj0Z3VsImfQFJe1tsK23LOWW77bdiv81s9K0Xb9 jVpenowRSstZ0vz4tWotX4Vv0XT5pRByo/uN05Q52mL9P5cePhptK6uZ1cPsYaDEUpyRaKjF XFScCAAjbKQNbAIAAA== 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: Tue, 27 Nov 2012 09:06:21 -0000 Hi, > Disclaimer - AFAIK I am simply restating the intent of the framework as i= t stands. These were not my concepts. But I think I have assimilated the in= tent. > > So it is certainly possible to recast this stuff, but then I think there = will need to be some further discussion to fully understand the ramificatio= ns of such a change. > >> I had the same thoughts as Christer. Picking a subset is something=20 >> that I could live with, cherry picking captures from different capture=20 >> scene entries I think is complicating the issue. > > Certainly one can argue about how one would know enough to make such a ch= oice. But I don't see why it is a "complication" from the point of view of = the provider. It makes the procedures more complex. Without the option to "cherry picking", the provider only needs to say: "These are my CSEs (Capture Scene Entries). Please pick one, and then till = me which captures you want." With the option to cherry pick, the provider would in addition also need to= be able to say: "BTW, if you choose CSE_X, and capture CAP_X, then from CSE_Y can only choo= se captures CAP_Y1, CAP_Y2, CAP_Y3 - unless you also from CSE_W chooses cap= ture CAP_W1, in which case you can only choose CAP_Y2 and CAP_Y3 from CSE_Y= ". Etc etc etc etc etc. I could become very complicated, depending on how far we want to go. >> The framework says that >> provider must be able to supply media related to all the captures=20 >> within a capture scene entry. If the consumer chooses different=20 >> captures then the provider may not be able to supply these? Do we then=20 >> need an extra message for the provider to signal to the consumer that=20 >> it can't honour its choice? > > The simultaneous transmission sets are intended to indicate what can be t= ransmitted simultaneously. The advertiser should thus be able to transmit a= ny selection that is in accord with the advertisement. > > The specification that the provider must be able to supply media related = to all captures within a scene entry is simply a further constraint on the = provider. > > Once the provider has constructed its advertisement to reflect its constr= aints, it should be no extra complication to supply any conforming selectio= n, regardless of which scene entries the captures come from. > > Perhaps making a limitation of only selecting from one scene entry per sc= ene might simplify the advertisement - perhaps eliminating the need for the= simultaneous transmission set. Or it might simplify the choice of configur= ation. But neither of these=20 > seems like enough of a complication to worry about. I disagree. I think it can become very complicated. Simultaneous transmission sets is perhaps something we could add in future,= if there is a need. Also, if people are afraid that things will become too easy, please join th= e discussions about SDP and multiple streams per m- line :) Regards, Christer From christer.holmberg@ericsson.com Tue Nov 27 01:08: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 46A0521F84D7 for ; Tue, 27 Nov 2012 01:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 Ek0mvnTC08KT for ; Tue, 27 Nov 2012 01:08:29 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A875A21F84D9 for ; Tue, 27 Nov 2012 01:08:28 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-19-50b483081dfe Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F8.51.26143.80384B05; Tue, 27 Nov 2012 10:08:24 +0100 (CET) Received: from ESESSHC014.ericsson.se (153.88.183.60) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 27 Nov 2012 10:08:24 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 10:08:23 +0100 From: Christer Holmberg To: Christian Groves Thread-Topic: [clue] Capture scene clarifications Thread-Index: AQHNzFVxzk8+n3np90eOVjDiWPg3K5f9ZIZg Date: Tue, 27 Nov 2012 09:08:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B046515@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <7594FB04B1934943A5C02806D1A2204B044380@ESESSMB209.ericsson.se> <50B43DB9.9040209@nteczone.com> In-Reply-To: <50B43DB9.9040209@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+NgFnrCLMWRmVeSWpSXmKPExsUyM+JvjS5H85YAg5VHpS2+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJWx8MtT9oIPRhUtr26wNjBuV+9i5OSQEDCR OPHpNhuELSZx4d56IJuLQ0jgJKPE8jVXGSGcnYwSZ/8cZ4ZwljBKrDqyg7WLkYODTcBCovuf NogpAjRp/llNkEHMAsoSXxs2MYHYwgIGEic/3mAHsUUEDCW2LpnDCmEbSezp2go2hUVAVeLz KiuQMK+At8TrizuYIDb1M0o8nPcZrJ5TQEfi4dVGsJmMQId+P7WGCWKXuMStJ/OZIB4QkFiy 5zwzhC0q8fLxP1YIW1Fi59l2Zoh6HYkFuz+xQdjaEssWvmaGWCwocXLmExYQWwgo3rJ4AvsE RolZSFbMQtI+C0n7LCTtCxhZVjGy5yZm5qSXG21iBMbUwS2/VXcw3jkncohRmoNFSZzXeuse fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MvqIzqiOlb9X+y669trnv3KP/v/bk9qr02AQv WRW0nUFwA7cp4/U/ch82Lpf/k3V0XXPG3N3eGeUWFpdKbVPfZr1OdJvIe3RGd5gIi90c3Vlr rvc7TitNZGv3iny/Jqqt1SFt6Z5bSjEGh802cq85HvD14T7Xu+oVjiwrJIt0xXNkzSyjPdSU WIozEg21mIuKEwGOdXrtdwIAAA== 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: Tue, 27 Nov 2012 09:08:30 -0000 Hi, >I'm all for simplifying things. If we can use one term throughout the draf= t instead of two closely related ones I think it would be good.=20 >However can we completely decouple "scene" and "capture" after all a set o= f captures basically constitutes a scene? Yes, and in the definition we say that a scene is a set of captures. Then w= e don't need to talk about "capture scene entry", which at least to me soun= ds confusing :) Regards, Christer On 25/11/2012 1:53 AM, Christer Holmberg wrote: > Hi Christian, > > If one intention is to clarify that a capture scene entry represents a wh= ile scene, why not remove "capture", and simply call it "scene entry", or s= omething... > > And, as the defintion for "scene" already talks about media captures, we = could remove "media capture" from the definition of "scene entry", and say: > > "A list of alternative representations of a single scene" > > ...or something like that. > > I think things would be more clear if we try to keep "capture" and "scene= " apart from each other. > > Regards, > > Christer > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Christian Groves > Sent: 23. marraskuuta 2012 5:56 > 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 spatia= l > 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 on= e > that determines what a complete scene is. A consumer choses > a capture scene entry from the scene in the knowledge that i= t > 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 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. > > 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. > > 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..." > > - 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...." > > - 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 scen= e > entries in a capture scene are different alternatives the provider i= s > suggesting for representing the entire capture scene. 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 adverti= sed 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 f= or a particular media type and that all media captures are spatially relate= d. 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 a= ll the media captures. What is locally rendered and how is a local decision= ." > > 4) The framework uses the terms "media provider" and "provider". We proba= bly should be consistent in the use of the term throughout the framework. > > 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 prioritisat= ion / 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 di= dn't see anything in the framework regarding what should be assumed. We pro= bably should also add something for that. > > Thoughts? > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Tue Nov 27 03:39:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F383821F84D0 for ; Tue, 27 Nov 2012 03:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 3TBy4ROWmull for ; Tue, 27 Nov 2012 03:39:44 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A79A921F850E for ; Tue, 27 Nov 2012 03:39:43 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-38-50b4a67e4eff Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0F.CF.26143.E76A4B05; Tue, 27 Nov 2012 12:39:42 +0100 (CET) Received: from ESESSHC020.ericsson.se (153.88.183.78) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 27 Nov 2012 12:39:42 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 12:39:41 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Capture scene clarifications Thread-Index: AQHNy+i8zk8+n3np90eOVjDiWPg3K5f8f/kg///4BACAAJT3AIAACYqAgABKBzCAAC5pAA== Date: Tue, 27 Nov 2012 11:39:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B046A37@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> <50B446A8.2010307@nteczone.com> <50B44EA9.30707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B046501@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B046501@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW7dsi0BBue2GVnsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG1yfn2Av65SvOdN9kb2D8L9HFyMkhIWAi sfnrNFYIW0ziwr31bF2MXBxCAicZJZ5/WsYGkhAS2MkocaElDsJewiix7XRCFyMHB5uAhUT3 P22QsIhAvcT8Y7cYQWxhAQOJkx9vsEPEDSW2LpnDClIuIhAm0XHRFyTMIqAq8a1/JhOIzSvg LfF7wXJGiLUbmSSW/dwAluAU8JF4+nYOC4jNCHTb91NrwOLMAuISt57MZ4K4WUBiyZ7zzBC2 qMTLx/+gflGU2Hm2nRmiXkdiwe5PbBC2tsSyha+ZIRYLSpyc+YQF4i1tiZbFE9gnMIrPQrJi FpL2WUjaZyFpX8DIsoqRPTcxMye93GgTIzByDm75rbqD8c45kUOM0hwsSuK81lv3+AsJpCeW pGanphakFsUXleakFh9iZOLglGpglAtT+nLMrMj8ymTHB/NXrX8lU75u74RNApdr3p8szI+4 xX6UpZvx38V1k7sjwkVnNN+v1QDau29p1bX8zIVRhpcDjmZ3WHPtCdmzr/PUvjefLRk6wic1 rT5kWabt1KG0XGHlpj0CXpVegRMK44Jy8tcmGd355tRUd3C94+Ql1o6ckyuOR7YrsRRnJBpq MRcVJwIACowcc2oCAAA= 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: Tue, 27 Nov 2012 11:39:45 -0000 Hi, A little more on this: Instead of having simultaneous transmission sets, I think it would be more = important to have something like "simultaneous capture scene sets". Because, AFAIK, the video captures and a presentation capture might be part= of separate capture scene entries (as the presentation does not have any s= patial relationship with the video). But, this would not be cherry picking individual captures from different CS= Es, but rather selecting different CSEs - and being able to advertise that = one can provide CSEs simultaneously. Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= ister Holmberg Sent: 27. marraskuuta 2012 11:06 To: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] Capture scene clarifications Hi, > Disclaimer - AFAIK I am simply restating the intent of the framework as i= t stands. These were not my concepts. But I think I have assimilated the in= tent. > > So it is certainly possible to recast this stuff, but then I think there = will need to be some further discussion to fully understand the ramificatio= ns of such a change. > >> I had the same thoughts as Christer. Picking a subset is something=20 >> that I could live with, cherry picking captures from different=20 >> capture scene entries I think is complicating the issue. > > Certainly one can argue about how one would know enough to make such a ch= oice. But I don't see why it is a "complication" from the point of view of = the provider. It makes the procedures more complex. Without the option to "cherry picking", the provider only needs to say: "These are my CSEs (Capture Scene Entries). Please pick one, and then till = me which captures you want." With the option to cherry pick, the provider would in addition also need to= be able to say: "BTW, if you choose CSE_X, and capture CAP_X, then from CSE_Y can only choo= se captures CAP_Y1, CAP_Y2, CAP_Y3 - unless you also from CSE_W chooses cap= ture CAP_W1, in which case you can only choose CAP_Y2 and CAP_Y3 from CSE_Y= ". Etc etc etc etc etc. I could become very complicated, depending on how far we want to go. >> The framework says that >> provider must be able to supply media related to all the captures=20 >> within a capture scene entry. If the consumer chooses different=20 >> captures then the provider may not be able to supply these? Do we=20 >> then need an extra message for the provider to signal to the consumer=20 >> that it can't honour its choice? > > The simultaneous transmission sets are intended to indicate what can be t= ransmitted simultaneously. The advertiser should thus be able to transmit a= ny selection that is in accord with the advertisement. > > The specification that the provider must be able to supply media related = to all captures within a scene entry is simply a further constraint on the = provider. > > Once the provider has constructed its advertisement to reflect its constr= aints, it should be no extra complication to supply any conforming selectio= n, regardless of which scene entries the captures come from. > > Perhaps making a limitation of only selecting from one scene entry per=20 > scene might simplify the advertisement - perhaps eliminating the need for= the simultaneous transmission set. Or it might simplify the choice of conf= iguration. But neither of these seems like enough of a complication to worr= y about. I disagree. I think it can become very complicated. Simultaneous transmission sets is perhaps something we could add in future,= if there is a need. Also, if people are afraid that things will become too easy, please join th= e discussions about SDP and multiple streams per m- line :) Regards, Christer _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Tue Nov 27 05:56:51 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC9921F8599 for ; Tue, 27 Nov 2012 05:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 8fjgej77oUlH for ; Tue, 27 Nov 2012 05:56:50 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF1F21F8589 for ; Tue, 27 Nov 2012 05:56:50 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 27 Nov 2012 05:56:50 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 27 Nov 2012 05:56:48 -0800 Thread-Topic: Framework tickets to be closed Thread-Index: Ac3MpfA36MCpdgGvQq+7sj4sf3/TEA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6103917973F1@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6103917973F1CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Framework tickets to be closed X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Nov 2012 13:56:51 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6103917973F1CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Mary and Paul, I think a few open tickets can be closed based on draft-ietf-clue-framework= -07. Ticket #9 - axis of captu= re description Ticket #17 - capture enc= oding term Ticket #18 - limitations= on simulcast If you agree, can you please mark these tickets as closed? Notes in the "Changes" section of draft-ietf-clue-framework-07: - Ticket #9. Rename Axis of Capture Point attribute to Point on Li= ne of Capture. Clarify the description of this attribute. - Ticket #17. Add "capture encoding" definition. Use this new term= throughout document as appropriate, replacing some usage of the terms "str= eam" and "encoding". - Ticket #18. Add Max Capture Encodings media capture attribute. Thanks, Mark Duckworth --_000_44C6B6B2D0CF424AA90B6055548D7A6103917973F1CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Mary and P= aul,

 

I think a few open tickets can be closed based on draft-ietf-clue-fr= amework-07.

 

= Ticket #9 – axis of capture description

Tic= ket #17 – capture encoding term

Ticket #18<= /a> – limitations on simulcast

 

If you agree, can you please mark th= ese tickets as closed?

 =

Notes in the “Changes” section of draf= t-ietf-clue-framework-07:

-&nb= sp;         Ticket #9. Rename Axis of Capture Point attribute to Point on Line of Capt= ure. Clarify the description of this attribute.

-          Ticket #17. Add "capture encoding" definitio= n. Use this new term throughout document as appropriate, replacing some usa= ge of the terms "stream" and "encoding".

=

-       &nb= sp;  Ticket #18. Add Max Capture Encodings med= ia capture attribute.

 <= /p>

Thanks,
Mark Duckworth

= --_000_44C6B6B2D0CF424AA90B6055548D7A6103917973F1CRPMBOXPRD01p_-- From ron.even.tlv@gmail.com Tue Nov 27 06:56:33 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2AA21F8557 for ; Tue, 27 Nov 2012 06:56:33 -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 FBj1aczOnprB for ; Tue, 27 Nov 2012 06:56:31 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 263F721F843A for ; Tue, 27 Nov 2012 06:56:30 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so7798813eek.31 for ; Tue, 27 Nov 2012 06:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=F8VPfApPrqQf3F+jF17F9ZIr5M7PucTVCIdvKzfIYgw=; b=rHThlp5lklPEAWDZkn6TbRbxJxj1g/OEXeMOjhki0QAv/xmWJho2j9J4g1rxyHgUej 2PIP8sf8oqFAqflGjOOlY3nmK/MWQCBNqWco6cRBfbqviFRGpg+l7ZI4R4ihN8PNOB8G t0zLeHbSWh4+tV7ujieXTillw5mcptLzTK1Zpqj06K8NLagz9uazZUBBpsK/2MmYTfH4 mTmp0R2NX9SBddpWn7wBubuXq9Q2gqGZR2vB/iU+zKg4BP9j9oKwYEhptZSHp0gAuK6h 8aS2q2993aUArfNUTp3uyT6veMiioTvESQP6A+UtCMw2wVjvJpLuhZ328TQxCmpzG2ho o5cA== Received: by 10.14.174.194 with SMTP id x42mr59082034eel.22.1354028190261; Tue, 27 Nov 2012 06:56:30 -0800 (PST) Received: from RoniE ([109.64.71.197]) by mx.google.com with ESMTPS id n7sm23369279eeo.2.2012.11.27.06.56.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 06:56:29 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , Date: Tue, 27 Nov 2012 16:53:55 +0200 Message-ID: <044401cdccaf$07ba5ed0$172f1c70$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0445_01CDCCBF.CB446750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3Mrs2GkHijAPmzT1q4GGQI1nIs8g== Content-Language: en-us Subject: Re: [clue] Framework tickets to be closed - simulcast support X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Nov 2012 14:56:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0445_01CDCCBF.CB446750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I agree on the first two tickets As for ticket #18 the meeting minutes say "Roni - Not sure this is enough as does not provide info on which can be simulcast if for example there is a limit of two which two does it mean. Rob Hanson - Not so convinced that this is a problem we need to solve in clue (sorry some missing). Roni - Can agree with the previous speaker that does not need to be solved in clue." This are partial notes but clearly this parameter does not solve simulcast. So I am not sure why it was added. So in my view if we take this ticket out we agree that 1. simulcast should not be addressed in CLUE (until we have a different solution) 2. There is no need for the new Max Capture Encoding attribute. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 27 November, 2012 3:57 PM To: clue@ietf.org Subject: [clue] Framework tickets to be closed Hello Mary and Paul, I think a few open tickets can be closed based on draft-ietf-clue-framework-07. Ticket #9 - axis of capture description Ticket #17 - capture encoding term Ticket #18 - limitations on simulcast If you agree, can you please mark these tickets as closed? Notes in the "Changes" section of draft-ietf-clue-framework-07: - Ticket #9. Rename Axis of Capture Point attribute to Point on Line of Capture. Clarify the description of this attribute. - Ticket #17. Add "capture encoding" definition. Use this new term throughout document as appropriate, replacing some usage of the terms "stream" and "encoding". - Ticket #18. Add Max Capture Encodings media capture attribute. Thanks, Mark Duckworth ------=_NextPart_000_0445_01CDCCBF.CB446750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I agree on the = first two tickets

 

As for = ticket #18 the meeting minutes say 

“Roni - Not =
sure this is enough as does not provide info on which can be simulcast =
if for example there is a limit of two which two does it =
mean.

Rob Hanson - Not so = convinced that this is a problem we need to solve in clue (sorry some = missing).

Roni - Can agree with the = previous speaker that does not need to be solved in = clue.”

 

This are partial notes but clearly this parameter does = not solve simulcast. So I am not sure why it was added.

 

So in my = view if we take this ticket out we agree that

1.       = simulcast should not be = addressed in CLUE (until we have a different solution)

2.       = There is no need for the = new Max Capture Encoding attribute.

 

Roni

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: 27 November, 2012 3:57 = PM
To: clue@ietf.org
Subject: [clue] Framework = tickets to be closed

 

Hello Mary = and Paul,

 

I think a few open tickets can be closed based on = draft-ietf-clue-framework-07.

 

Ticket #9 = – axis of capture description

Ticket = #17 – capture encoding term

Ticket = #18 – limitations on simulcast

 

If you = agree, can you please mark these tickets as closed?

 

Notes in the = “Changes” section of = draft-ietf-clue-framework-07:

-          = Ticket #9. Rename Axis of = Capture Point attribute to Point on Line of Capture. Clarify the = description of this attribute.

-          = Ticket #17. Add = "capture encoding" definition. Use this new term throughout = document as appropriate, replacing some usage of the terms = "stream" and "encoding".

-          = Ticket #18. Add Max = Capture Encodings media capture attribute.

 

Thanks,
Mark = Duckworth

------=_NextPart_000_0445_01CDCCBF.CB446750-- From Mark.Duckworth@polycom.com Tue Nov 27 07:19: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 786FD21F84FD for ; Tue, 27 Nov 2012 07:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 PH2nLyXzh1FE for ; Tue, 27 Nov 2012 07:19:19 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 92BB421F856B for ; Tue, 27 Nov 2012 07:19:19 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 27 Nov 2012 07:19:19 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 27 Nov 2012 07:19:17 -0800 Thread-Topic: [clue] Framework tickets to be closed - simulcast support Thread-Index: Ac3Mrs2GkHijAPmzT1q4GGQI1nIs8gAAxaDg Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610391797488@CRPMBOXPRD01.polycom.com> References: <044401cdccaf$07ba5ed0$172f1c70$@gmail.com> In-Reply-To: <044401cdccaf$07ba5ed0$172f1c70$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A610391797488CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] Framework tickets to be closed - simulcast support X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Nov 2012 15:19:21 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A610391797488CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Ticket #18 says "Need to define the mechanism to indicate limitations on si= mulcast in the advertisement." It sounds like you are saying you disagree with the premise of Ticket #18, = and we should not need to indicate any limitation on simulcast in the adver= tisement. Is that what you mean? Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, November 27, 2012 9:54 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Framework tickets to be closed - simulcast support Hi, I agree on the first two tickets As for ticket #18 the meeting minutes say "Roni - Not sure this is enough as does not provide info on which can be si= mulcast if for example there is a limit of two which two does it mean. Rob Hanson - Not so convinced that this is a problem we need to solve in cl= ue (sorry some missing). Roni - Can agree with the previous speaker that does not need to be solved = in clue." This are partial notes but clearly this parameter does not solve simulcast.= So I am not sure why it was added. So in my view if we take this ticket out we agree that 1. simulcast should not be addressed in CLUE (until we have a differe= nt solution) 2. There is no need for the new Max Capture Encoding attribute. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: 27 November, 2012 3:57 PM To: clue@ietf.org Subject: [clue] Framework tickets to be closed Hello Mary and Paul, I think a few open tickets can be closed based on draft-ietf-clue-framework= -07. Ticket #9 - axis of captu= re description Ticket #17 - capture enc= oding term Ticket #18 - limitations= on simulcast If you agree, can you please mark these tickets as closed? Notes in the "Changes" section of draft-ietf-clue-framework-07: - Ticket #9. Rename Axis of Capture Point attribute to Point on Li= ne of Capture. Clarify the description of this attribute. - Ticket #17. Add "capture encoding" definition. Use this new term= throughout document as appropriate, replacing some usage of the terms "str= eam" and "encoding". - Ticket #18. Add Max Capture Encodings media capture attribute. Thanks, Mark Duckworth --_000_44C6B6B2D0CF424AA90B6055548D7A610391797488CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

Ticket #18 says “Need to define the mechanism to = indicate limitations on simulcast in the advertisement.”

It sounds like = you are saying you disagree with the premise of Ticket #18, and we should n= ot need to indicate any limitation on simulcast in the advertisement. = Is that what you mean?

Mark

 

<= p class=3DMsoNormal>From: Roni Even [mailto:ron.even.tlv@gmail.com]
Se= nt: Tuesday, November 27, 2012 9:54 AM
To: Duckworth, Mark; c= lue@ietf.org
Subject: RE: [clue] Framework tickets to be closed -= simulcast support

 

Hi,

I agree on the first two tickets

 

As for ticket #18 the meeting minute= s say 

“Roni - Not sure this is enough as does not provid=
e info on which can be simulcast if for example there is a limit of two whi=
ch two does it mean.

Rob Hanson= - Not so convinced that this is a problem we need to solve in clue (sorry = some missing).

Roni - Can agree with the= previous speaker that does not need to be solved in clue.”

 

This ar= e partial notes but clearly this parameter does not solve simulcast. So I a= m not sure why it was added.

 =

So in my view if we take this ticket out we = agree that

1.   =     simulcast should not be addresse= d in CLUE (until we have a different solution)

2.       There is no need for the new Max Capture Encoding attribute.=

 

Roni

 

&nbs= p;

From: clue-bounces@ietf= .org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
= Sent: 27 November, 2012 3:57 PM
To: clue@ietf.org
Su= bject: [clue] Framework tickets to be closed

 

Hello= Mary and Paul,

 

I think a few open tickets can be closed based on draft-i= etf-clue-framework-07.

 =

Ticket #9 – axis of capture description

=

Ticket #17 – capture encoding term

= Ticket #18 – limitations on simulcast

 

If you agree, can you ple= ase mark these tickets as closed?

&= nbsp;

Notes in the “Changes” sect= ion of draft-ietf-clue-framework-07:

-          = Ticket #9. Rename Axis of Capture Point attribute to Point on Lin= e of Capture. Clarify the description of this attribute.

-        &= nbsp; Ticket #17. Add "capture encoding" = definition. Use this new term throughout document as appropriate, replacing= some usage of the terms "stream" and "encoding".<= /o:p>

-      =     Ticket #18. Add Max Capture Enco= dings media capture attribute.

&nbs= p;

Thanks,
Mark Duckworth

= --_000_44C6B6B2D0CF424AA90B6055548D7A610391797488CRPMBOXPRD01p_-- From ron.even.tlv@gmail.com Tue Nov 27 07:52: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 66CFC21F84CC for ; Tue, 27 Nov 2012 07:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 5FUNdTy1bOYb for ; Tue, 27 Nov 2012 07:52:08 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF01121F84CD for ; Tue, 27 Nov 2012 07:52:05 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so7840596eek.31 for ; Tue, 27 Nov 2012 07:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=0ssivAl/d10xLMACdzLZvm8JGdaf30iezDVXibiVfNI=; b=ua0RM2magPyj35ytFwA2yYoK35hJpMkCVBZi6aJoDS7TmBfix4v0akj4VGJEVbCgHu arq8/X7Ug+aSPpvhbGhOnvK9/XuAeRh1buAKTOMXP+YI7ukKgvIsTwfJaKa+wp0pv8tw Dl4SXWS9edbtS+3PytnNH0slsl/NYVBXNqoK/fr8AytKkcYZRwHwyFzxMZuXIyqI5E1Z wZg5RCoZUUp6Dw88T6an2fQEDScOgndHkdSLXdtXUZxZCdu8UiirYYyQTDV1HMtiM/iN O2QAp9IaqF6hXTs597SY01E31NSORq5kL1bj9IGXUMDcHf1t0Y1qirg0sfQxre95tyTf Apog== Received: by 10.14.216.70 with SMTP id f46mr59563988eep.12.1354031514011; Tue, 27 Nov 2012 07:51:54 -0800 (PST) Received: from RoniE ([109.64.71.197]) by mx.google.com with ESMTPS id y44sm41396035eel.14.2012.11.27.07.51.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 07:51:52 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <044401cdccaf$07ba5ed0$172f1c70$@gmail.com> <44C6B6B2D0CF424AA90B6055548D7A610391797488@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A610391797488@CRPMBOXPRD01.polycom.com> Date: Tue, 27 Nov 2012 17:49:17 +0200 Message-ID: <045501cdccb6$c48272d0$4d875870$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0456_01CDCCC7.880CC970" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHw5rvXEApERPQsFuIb6EjUTJuw9QK0O1Epl6H7riA= Content-Language: en-us Subject: Re: [clue] Framework tickets to be closed - simulcast support X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Nov 2012 15:52:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0456_01CDCCC7.880CC970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mark, What I was saying is that the Max capture Encoding attribute does not address the simulcast issue. For example if there are 6 different individual encodes in the group 2 HD 2 SD and 2 CIF and the Max Capture encode for a media capture is 2. Which two can the provider send ( HD +SD or HD + CIF or SD+CIF or 2HD .) So there is no solution yet for simulcast which I think other agreed in the meeting. Rob proposed that support for simulcast should not be discussed in CLUE. This is the reason for the two points I made. So we can remove ticket #18 and the Max Capture Encoding If need max capture encoding then need to specify the usage and it is not to address simulcast. Note that the same issue I mentioned in the example above still holds. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 27 November, 2012 5:19 PM To: clue@ietf.org Subject: Re: [clue] Framework tickets to be closed - simulcast support Hi Roni, Ticket #18 says "Need to define the mechanism to indicate limitations on simulcast in the advertisement." It sounds like you are saying you disagree with the premise of Ticket #18, and we should not need to indicate any limitation on simulcast in the advertisement. Is that what you mean? Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, November 27, 2012 9:54 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Framework tickets to be closed - simulcast support Hi, I agree on the first two tickets As for ticket #18 the meeting minutes say "Roni - Not sure this is enough as does not provide info on which can be simulcast if for example there is a limit of two which two does it mean. Rob Hanson - Not so convinced that this is a problem we need to solve in clue (sorry some missing). Roni - Can agree with the previous speaker that does not need to be solved in clue." This are partial notes but clearly this parameter does not solve simulcast. So I am not sure why it was added. So in my view if we take this ticket out we agree that 1. simulcast should not be addressed in CLUE (until we have a different solution) 2. There is no need for the new Max Capture Encoding attribute. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 27 November, 2012 3:57 PM To: clue@ietf.org Subject: [clue] Framework tickets to be closed Hello Mary and Paul, I think a few open tickets can be closed based on draft-ietf-clue-framework-07. Ticket #9 - axis of capture description Ticket #17 - capture encoding term Ticket #18 - limitations on simulcast If you agree, can you please mark these tickets as closed? Notes in the "Changes" section of draft-ietf-clue-framework-07: - Ticket #9. Rename Axis of Capture Point attribute to Point on Line of Capture. Clarify the description of this attribute. - Ticket #17. Add "capture encoding" definition. Use this new term throughout document as appropriate, replacing some usage of the terms "stream" and "encoding". - Ticket #18. Add Max Capture Encodings media capture attribute. Thanks, Mark Duckworth ------=_NextPart_000_0456_01CDCCC7.880CC970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mark,

What I was saying is = that the Max capture Encoding attribute does not address the simulcast = issue. For example if there are 6 different individual encodes in the = group 2 HD 2 SD and 2 CIF and the Max Capture encode for a media capture = is 2. Which two can the provider send ( HD +SD or HD + CIF or SD+CIF or = 2HD …)

So there is no solution yet for simulcast which = I think other agreed in the meeting.

Rob proposed that = support for simulcast should not be discussed in = CLUE.

This is the reason for the two points I = made.

So we can remove ticket #18 and the Max Capture = Encoding

 

If need max capture = encoding then need to specify the usage and it is not to address = simulcast. Note that the same issue I mentioned in the example above = still holds.

 

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: 27 November, 2012 5:19 = PM
To: clue@ietf.org
Subject: Re: [clue] Framework = tickets to be closed - simulcast = support

 

Hi Roni,

Ticket #18 says = “Need to define the mechanism to indicate limitations on simulcast = in the advertisement.”

It sounds like you are = saying you disagree with the premise of Ticket #18, and we should not = need to indicate any limitation on simulcast in the advertisement.  = Is that what you mean?

Mark

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]=
Sent: Tuesday, November 27, 2012 9:54 AM
To: = Duckworth, Mark; clue@ietf.org
Subject: RE: = [clue] Framework tickets to be closed - simulcast = support

 

Hi,

I agree on the = first two tickets

 

As for = ticket #18 the meeting minutes say 

“Roni=
 - Not sure this is enough as does not provide info on which can be =
simulcast if for example there is a limit of two which two does it =
mean.

Rob Hanson - Not so = convinced that this is a problem we need to solve in clue (sorry some = missing).

Roni - Can agree with the = previous speaker that does not need to be solved in = clue.”

 

This are partial notes but clearly this parameter does = not solve simulcast. So I am not sure why it was added.

 

So in my = view if we take this ticket out we agree that

1.       = simulcast should not be = addressed in CLUE (until we have a different solution)

2.       = There is no need for the = new Max Capture Encoding attribute.

 

Roni

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: 27 November, 2012 = 3:57 PM
To: clue@ietf.org
Subject: = [clue] Framework tickets to be = closed

 

Hello Mary = and Paul,

 

I think a few open tickets can be closed based on = draft-ietf-clue-framework-07.

 

Ticket #9 = – axis of capture description

Ticket = #17 – capture encoding term

Ticket = #18 – limitations on simulcast

 

If you = agree, can you please mark these tickets as closed?

 

Notes in the = “Changes” section of = draft-ietf-clue-framework-07:

-          = Ticket #9. Rename Axis of = Capture Point attribute to Point on Line of Capture. Clarify the = description of this attribute.

-          = Ticket #17. Add = "capture encoding" definition. Use this new term throughout = document as appropriate, replacing some usage of the terms = "stream" and "encoding".

-          = Ticket #18. Add Max = Capture Encodings media capture attribute.

 

Thanks,
Mark = Duckworth

------=_NextPart_000_0456_01CDCCC7.880CC970-- From Christian.Groves@nteczone.com Tue Nov 27 20:16: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 1428011E8099 for ; Tue, 27 Nov 2012 20:16:41 -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 FWLTGxbm99EH for ; Tue, 27 Nov 2012 20:16:40 -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 D1F4F21F867A for ; Tue, 27 Nov 2012 20:16:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBALePtVB20a6R/2dsb2JhbAANOMA5gxEBAQEEAQEBNRsbBAYBDAQLEQQBAQEJFggHCQMCAQIBFR8JCAYNAQUCAQGIFatPk0oEjDqEQQOpSQ Received: from ppp118-209-174-145.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.174.145]) by ipmail06.adl6.internode.on.net with ESMTP; 28 Nov 2012 14:46:10 +1030 Message-ID: <50B59007.9070502@nteczone.com> Date: Wed, 28 Nov 2012 15:16:07 +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: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> <50B446A8.2010307@nteczone.com> <50B44EA9.30707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B046501@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B046A37@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B046A37@ESESSMB209.ericsson.se> 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: Wed, 28 Nov 2012 04:16:41 -0000 Hello Christer, A simultaneous set applies across all capture scenes in an advertisement so would cover the presentation / video case. I assume each simultaneous set can have a mix of media types, although this is not explicit in the framework? I agree however if a consumer isn't allowed to select individual captures from multiple capture scene entries and scenes then we could probably simplify the use of simultaneous sets to the scene level. Regards, Christian On 27/11/2012 10:39 PM, Christer Holmberg wrote: > Hi, > > A little more on this: > > Instead of having simultaneous transmission sets, I think it would be more important to have something like "simultaneous capture scene sets". > > Because, AFAIK, the video captures and a presentation capture might be part of separate capture scene entries (as the presentation does not have any spatial relationship with the video). > > But, this would not be cherry picking individual captures from different CSEs, but rather selecting different CSEs - and being able to advertise that one can provide CSEs simultaneously. > > Regards, > > Christer > > > > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 27. marraskuuta 2012 11:06 > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] Capture scene clarifications > > Hi, > >> Disclaimer - AFAIK I am simply restating the intent of the framework as it stands. These were not my concepts. But I think I have assimilated the intent. >> >> So it is certainly possible to recast this stuff, but then I think there will need to be some further discussion to fully understand the ramifications of such a change. >> >>> I had the same thoughts as Christer. Picking a subset is something >>> that I could live with, cherry picking captures from different >>> capture scene entries I think is complicating the issue. >> Certainly one can argue about how one would know enough to make such a choice. But I don't see why it is a "complication" from the point of view of the provider. > It makes the procedures more complex. > > Without the option to "cherry picking", the provider only needs to say: > > "These are my CSEs (Capture Scene Entries). Please pick one, and then till me which captures you want." > > With the option to cherry pick, the provider would in addition also need to be able to say: > > "BTW, if you choose CSE_X, and capture CAP_X, then from CSE_Y can only choose captures CAP_Y1, CAP_Y2, CAP_Y3 - unless you also from CSE_W chooses capture CAP_W1, in which case you can only choose CAP_Y2 and CAP_Y3 from CSE_Y". > > Etc etc etc etc etc. > > I could become very complicated, depending on how far we want to go. > >>> The framework says that >>> provider must be able to supply media related to all the captures >>> within a capture scene entry. If the consumer chooses different >>> captures then the provider may not be able to supply these? Do we >>> then need an extra message for the provider to signal to the consumer >>> that it can't honour its choice? >> The simultaneous transmission sets are intended to indicate what can be transmitted simultaneously. The advertiser should thus be able to transmit any selection that is in accord with the advertisement. >> >> The specification that the provider must be able to supply media related to all captures within a scene entry is simply a further constraint on the provider. >> >> Once the provider has constructed its advertisement to reflect its constraints, it should be no extra complication to supply any conforming selection, regardless of which scene entries the captures come from. >> >> Perhaps making a limitation of only selecting from one scene entry per >> scene might simplify the advertisement - perhaps eliminating the need for the simultaneous transmission set. Or it might simplify the choice of configuration. But neither of these seems like enough of a complication to worry about. > I disagree. I think it can become very complicated. > > Simultaneous transmission sets is perhaps something we could add in future, if there is a need. > > Also, if people are afraid that things will become too easy, please join the discussions about SDP and multiple streams per m- line :) > > 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 Tue Nov 27 23:29: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 BC8C221F8798 for ; Tue, 27 Nov 2012 23:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.221, 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 YdlLEOKcdy+f for ; Tue, 27 Nov 2012 23:29:04 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6D27921F8784 for ; Tue, 27 Nov 2012 23:29:03 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-c7-50b5bd3d6056 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 95.16.26143.D3DB5B05; Wed, 28 Nov 2012 08:29:01 +0100 (CET) Received: from ESESSHC017.ericsson.se (153.88.183.69) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 28 Nov 2012 08:29:01 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 08:29:00 +0100 From: Christer Holmberg To: Christian Groves Thread-Topic: [clue] Capture scene clarifications Thread-Index: AQHNy+i8zk8+n3np90eOVjDiWPg3K5f8f/kg///4BACAAJT3AIAACYqAgABKBzCAAC5pAIABBqqAgABFOkA= Date: Wed, 28 Nov 2012 07:28:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B047E33@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> <50B446A8.2010307@nteczone.com> <50B44EA9.30707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B046501@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B046A37@ESESSMB209.ericsson.se> <50B59007.9070502@nteczone.com> In-Reply-To: <50B59007.9070502@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+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvja7t3q0BBm/2KFh8ed/IYrH/1GVm ixUbDrA6MHv8ff+ByWPJkp9MHivOz2QJYI7isklJzcksSy3St0vgylhw1bdgtnbF838PGRsY nyl1MXJySAiYSJw8NoUVwhaTuHBvPVsXIxeHkMBJRokdG5+yQjg7GSW6FrdDZZYwSvQv/8Hc xcjBwSZgIdH9TxvEFAGaNP+sJsggZgFPib4Ts9lAbGEBA4mTH2+wg9giAoYSW5fMYYWwkyQ+ 3LzICGKzCKhKHADbxcnBK+At0TWtnwli1VRmifc3zrODzOcU0JE43eEOUsMIdOj3U2uYIHaJ S9x6Mp8J4gEBiSV7zjND2KISLx//g3pMUWLn2XZmiHodiQW7P7FB2NoSyxa+ZobYKyhxcuYT FhBbCCjesngC+wRGiVlIVsxC0j4LSfssJO0LGFlWMbLnJmbmpJcbbWIERtnBLb9VdzDeOSdy iFGag0VJnNd66x5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyyOjNUb83humrSI5bu6D4x 7YDlBf73c5JZIq92CLLYZSeqSt9eoLNNqGXF/aMln6d4PlptdkL7Z+0ti1JVX8trWTLsZ01n 2IVN2Rqi+CGe9XKlW//qh+1G6U5V/HbBb5/xfGViE/j0ZGv8310JZsV3zjd6Xjq0stvolPei 79Er303KeiP3+qUSS3FGoqEWc1FxIgBRKqtYgAIAAA== 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, 28 Nov 2012 07:29:04 -0000 Hi, > A simultaneous set applies across all capture scenes in an advertisement = so would cover the presentation / video case. I assume each simultaneous se= t can have a mix of media types, although this is not explicit in the frame= work? Sure. But, my understanding was that all captures within a scene have a spa= tial relationship. So, for that reason a presentation would have to be part= of a separate scene (unless, of course, the presentation does have some ki= nd of spatial relationship with the other captures). > I agree however if a consumer isn't allowed to select individual captures= from multiple capture scene entries and scenes then we could probably simp= lify the use of simultaneous sets to the scene level. I would support such approach. And, in practice this would still allow a consumer to select individual cap= tures, by selecting multiple scenes, and then select captures from each sce= ne. BUT, we would not need to describe which captures can be simultaneously= provided, because if a provider indicates that SCENES can be provided simu= ltaneously it automatically means that all captures within those scenes can= be simultaneously provided. Regards, Christer Regards, Christian On 27/11/2012 10:39 PM, Christer Holmberg wrote: > Hi, > > A little more on this: > > Instead of having simultaneous transmission sets, I think it would be mor= e important to have something like "simultaneous capture scene sets". > > Because, AFAIK, the video captures and a presentation capture might be pa= rt of separate capture scene entries (as the presentation does not have any= spatial relationship with the video). > > But, this would not be cherry picking individual captures from different = CSEs, but rather selecting different CSEs - and being able to advertise tha= t one can provide CSEs simultaneously. > > Regards, > > Christer > > > > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Christer Holmberg > Sent: 27. marraskuuta 2012 11:06 > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] Capture scene clarifications > > Hi, > >> Disclaimer - AFAIK I am simply restating the intent of the framework as = it stands. These were not my concepts. But I think I have assimilated the i= ntent. >> >> So it is certainly possible to recast this stuff, but then I think there= will need to be some further discussion to fully understand the ramificati= ons of such a change. >> >>> I had the same thoughts as Christer. Picking a subset is something=20 >>> that I could live with, cherry picking captures from different=20 >>> capture scene entries I think is complicating the issue. >> Certainly one can argue about how one would know enough to make such a c= hoice. But I don't see why it is a "complication" from the point of view of= the provider. > It makes the procedures more complex. > > Without the option to "cherry picking", the provider only needs to say: > > "These are my CSEs (Capture Scene Entries). Please pick one, and then til= l me which captures you want." > > With the option to cherry pick, the provider would in addition also need = to be able to say: > > "BTW, if you choose CSE_X, and capture CAP_X, then from CSE_Y can only ch= oose captures CAP_Y1, CAP_Y2, CAP_Y3 - unless you also from CSE_W chooses c= apture CAP_W1, in which case you can only choose CAP_Y2 and CAP_Y3 from CSE= _Y". > > Etc etc etc etc etc. > > I could become very complicated, depending on how far we want to go. > >>> The framework says that >>> provider must be able to supply media related to all the captures=20 >>> within a capture scene entry. If the consumer chooses different=20 >>> captures then the provider may not be able to supply these? Do we=20 >>> then need an extra message for the provider to signal to the=20 >>> consumer that it can't honour its choice? >> The simultaneous transmission sets are intended to indicate what can be = transmitted simultaneously. The advertiser should thus be able to transmit = any selection that is in accord with the advertisement. >> >> The specification that the provider must be able to supply media related= to all captures within a scene entry is simply a further constraint on the= provider. >> >> Once the provider has constructed its advertisement to reflect its const= raints, it should be no extra complication to supply any conforming selecti= on, regardless of which scene entries the captures come from. >> >> Perhaps making a limitation of only selecting from one scene entry=20 >> per scene might simplify the advertisement - perhaps eliminating the nee= d for the simultaneous transmission set. Or it might simplify the choice of= configuration. But neither of these seems like enough of a complication to= worry about. > I disagree. I think it can become very complicated. > > Simultaneous transmission sets is perhaps something we could add in futur= e, if there is a need. > > Also, if people are afraid that things will become too easy, please=20 > join the discussions about SDP and multiple streams per m- line :) > > 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 pkyzivat@alum.mit.edu Wed Nov 28 10:05: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 1285B21F885C for ; Wed, 28 Nov 2012 10:05:01 -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 Tg8LEFzFU+Rq for ; Wed, 28 Nov 2012 10:05:00 -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 54C7A21F87CB for ; Wed, 28 Nov 2012 10:04:31 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta02.westchester.pa.mail.comcast.net with comcast id V00P1k0031ei1Bg5164Wdt; Wed, 28 Nov 2012 18:04:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id V64W1k0063ZTu2S3k64WUQ; Wed, 28 Nov 2012 18:04:30 +0000 Message-ID: <50B6522D.2060309@alum.mit.edu> Date: Wed, 28 Nov 2012 13:04:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> <50B446A8.2010307@nteczone.com> <50B44EA9.30707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B046501@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B046A37@ESESSMB209.ericsson.se> <50B59007.9070502@nteczone.com> <7594FB04B1934943A5C02806D1A2204B047E33@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B047E33@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=1354125870; bh=6LSixwVsK6VC1J5FsWI37SdJ0DKNoP7WdzpR4Cf4MXs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iRLSbBxpqHovqUaxiE6huSueIBk6kuiUD79uqY6ER3LnvGAbtOCWBbHawfyar8Asf Ss74BJfbo+wJXldjT0E/nD4JaIE52iTz/gqMf/14InFKHkIWmICioXk7WSOLLWGSii 2RtaKfjx7DLG4wqhJNJiemNWuxk+tRZeHsGOHUyMpuOQRKX2gke8wB89VOEPZU6bNK t6SGuLyXPiNKZlbdxMR7HoqwzenLaWvzM/tWtzcLfmjMUHDtbnPq9bPs69aSAU8Obl iStVjKjnv11D0iboZz9eQTLWeeGGsfNpBBfHZIv9kg7FVdzHu3U5ZKJrsrePzfvOlN Ev7AVoCUXsEDw== 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, 28 Nov 2012 18:05:01 -0000 Consider a case where an endpoint has a camera that can be used either to show part of the room or as a document camera. But it can't be used for both. This might be a case where the presentation stream should be included in the same scene as the room. (Because it is a view of a whiteboard that has a physical location within the room.) But maybe not - it might still be desirable to include it in a separate scene. Lets assume that is the intent. Then in this case there will be a mutual exclusion between captures in one or more scene entries in the room scene, and a capture in a scene entry in the presentation scene. So there is still a need for mutual exclusion sets. Or maybe a more radical change in structure. As I have tried to explain before, scene entries present alternative representations of a scene. But there is no way for the advertiser to indicate tradeoffs between captures in different scenes. Perhaps we should consider allowing an "entry" to contain captures from multiple scenes, and a single list of such entries, rather than a list per scene. This would permit the advertiser to make its own decision of tradeoffs render its advertisement as a whole. If we did that, then a scene would simply be an coordinate space and a set of captures that belong to that coordinate space. Thanks, Paul On 11/28/12 2:28 AM, Christer Holmberg wrote: > Hi, > >> A simultaneous set applies across all capture scenes in an advertisement so would cover the presentation / video case. I assume each simultaneous set can have a mix of media types, although this is not explicit in the framework? > > Sure. But, my understanding was that all captures within a scene have a spatial relationship. So, for that reason a presentation would have to be part of a separate scene (unless, of course, the presentation does have some kind of spatial relationship with the other captures). > >> I agree however if a consumer isn't allowed to select individual captures from multiple capture scene entries and scenes then we could probably simplify the use of simultaneous sets to the scene level. > > I would support such approach. > > And, in practice this would still allow a consumer to select individual captures, by selecting multiple scenes, and then select captures from each scene. BUT, we would not need to describe which captures can be simultaneously provided, because if a provider indicates that SCENES can be provided simultaneously it automatically means that all captures within those scenes can be simultaneously provided. > > Regards, > > Christer > > > Regards, Christian > > On 27/11/2012 10:39 PM, Christer Holmberg wrote: >> Hi, >> >> A little more on this: >> >> Instead of having simultaneous transmission sets, I think it would be more important to have something like "simultaneous capture scene sets". >> >> Because, AFAIK, the video captures and a presentation capture might be part of separate capture scene entries (as the presentation does not have any spatial relationship with the video). >> >> But, this would not be cherry picking individual captures from different CSEs, but rather selecting different CSEs - and being able to advertise that one can provide CSEs simultaneously. >> >> Regards, >> >> Christer >> >> >> >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Christer Holmberg >> Sent: 27. marraskuuta 2012 11:06 >> To: Paul Kyzivat; clue@ietf.org >> Subject: Re: [clue] Capture scene clarifications >> >> Hi, >> >>> Disclaimer - AFAIK I am simply restating the intent of the framework as it stands. These were not my concepts. But I think I have assimilated the intent. >>> >>> So it is certainly possible to recast this stuff, but then I think there will need to be some further discussion to fully understand the ramifications of such a change. >>> >>>> I had the same thoughts as Christer. Picking a subset is something >>>> that I could live with, cherry picking captures from different >>>> capture scene entries I think is complicating the issue. >>> Certainly one can argue about how one would know enough to make such a choice. But I don't see why it is a "complication" from the point of view of the provider. >> It makes the procedures more complex. >> >> Without the option to "cherry picking", the provider only needs to say: >> >> "These are my CSEs (Capture Scene Entries). Please pick one, and then till me which captures you want." >> >> With the option to cherry pick, the provider would in addition also need to be able to say: >> >> "BTW, if you choose CSE_X, and capture CAP_X, then from CSE_Y can only choose captures CAP_Y1, CAP_Y2, CAP_Y3 - unless you also from CSE_W chooses capture CAP_W1, in which case you can only choose CAP_Y2 and CAP_Y3 from CSE_Y". >> >> Etc etc etc etc etc. >> >> I could become very complicated, depending on how far we want to go. >> >>>> The framework says that >>>> provider must be able to supply media related to all the captures >>>> within a capture scene entry. If the consumer chooses different >>>> captures then the provider may not be able to supply these? Do we >>>> then need an extra message for the provider to signal to the >>>> consumer that it can't honour its choice? >>> The simultaneous transmission sets are intended to indicate what can be transmitted simultaneously. The advertiser should thus be able to transmit any selection that is in accord with the advertisement. >>> >>> The specification that the provider must be able to supply media related to all captures within a scene entry is simply a further constraint on the provider. >>> >>> Once the provider has constructed its advertisement to reflect its constraints, it should be no extra complication to supply any conforming selection, regardless of which scene entries the captures come from. >>> >>> Perhaps making a limitation of only selecting from one scene entry >>> per scene might simplify the advertisement - perhaps eliminating the need for the simultaneous transmission set. Or it might simplify the choice of configuration. But neither of these seems like enough of a complication to worry about. >> I disagree. I think it can become very complicated. >> >> Simultaneous transmission sets is perhaps something we could add in future, if there is a need. >> >> Also, if people are afraid that things will become too easy, please >> join the discussions about SDP and multiple streams per m- line :) >> >> 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 pkyzivat@alum.mit.edu Wed Nov 28 10:27: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 66A3921F8431 for ; Wed, 28 Nov 2012 10:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_23=0.6, 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 kfY8hixfDgFK for ; Wed, 28 Nov 2012 10:27:29 -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 9A51C21F8415 for ; Wed, 28 Nov 2012 10:27:29 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta13.westchester.pa.mail.comcast.net with comcast id Uyzm1k0010xGWP85D6TVzg; Wed, 28 Nov 2012 18:27:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id V6TU1k00m3ZTu2S3Y6TUzP; Wed, 28 Nov 2012 18:27:28 +0000 Message-ID: <50B65790.4050507@alum.mit.edu> Date: Wed, 28 Nov 2012 13:27:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <044401cdccaf$07ba5ed0$172f1c70$@gmail.com> <44C6B6B2D0CF424AA90B6055548D7A610391797488@CRPMBOXPRD01.polycom.com> <045501cdccb6$c48272d0$4d875870$@gmail.com> In-Reply-To: <045501cdccb6$c48272d0$4d875870$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354127249; bh=kcom+Q4FlRxLO0LcWmrq5MrLLQk6Ea8zK5wk+ShvvWI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EGjRU21TLPZoBpRYHtesc5ZRqSmylEaR3lEQ/gCxnRfi2Xdb2WDF+gJYksYm7Qykz 4Jglmnrdovicr/5jBpgh3rW2+Bp3cfa3/2d5F6JB6d/cnkeVXcRkZEA+FApqxBeTdF EN4q7S61D1Qpw4Grs56b4gtE0uZ4oUQfFaHMjkRMFTr4UCKtiJJ4S8aonENl5M6gud Cco0LhkjcuPkjSFaG0riaccw+hMn458W9EK1TH0/Napc334TtU+tGRHepHTVc+oRAj /HZYKaD6TXfQMtfTYQUyzCvNxEZCZVFhwRMS4gejQeaUQ4Kp3v4frkIL61ipSGHyfo CIExWgOx94JlQ== Subject: Re: [clue] Framework tickets to be closed - simulcast support X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 28 Nov 2012 18:27:30 -0000 (speaking as an individual for now) I think I see Roni's point about Max Capture Encoding not being sufficient. But regarding whether we need to address this in CLUE, I'm not ready to sweep this away yet. It *may* be that this can be sufficiently addressed using existing SDP mechanisms and so need not be explicitly addressed by CLUE. But until this is demonstrated I would like to keep the issue open. I have been thinking that in general a receiver will be able to look at an advertisement and decide on a configuration that will be mutually supported - that it is known before sending the configuration that it will "work". It *might* be necessary to do an O/A first, to prepare for the configuration. But it also ought to be possible to construct that O/A so that it doesn't harm the *current* configuration, even if it can't be fully honored by the advertiser. I can't see how the details of this will play out yet. Thanks, Paul On 11/27/12 10:49 AM, Roni Even wrote: > Mark, > > What I was saying is that the Max capture Encoding attribute does not > address the simulcast issue. For example if there are 6 different > individual encodes in the group 2 HD 2 SD and 2 CIF and the Max Capture > encode for a media capture is 2. Which two can the provider send ( HD > +SD or HD + CIF or SD+CIF or 2HD …) > > So there is no solution yet for simulcast which I think other agreed in > the meeting. > > Rob proposed that support for simulcast should not be discussed in CLUE. > > This is the reason for the two points I made. > > So we can remove ticket #18 and the Max Capture Encoding > > If need max capture encoding then need to specify the usage and it is > not to address simulcast. Note that the same issue I mentioned in the > example above still holds. > > Roni > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Duckworth, Mark > *Sent:* 27 November, 2012 5:19 PM > *To:* clue@ietf.org > *Subject:* Re: [clue] Framework tickets to be closed - simulcast support > > Hi Roni, > > Ticket #18 says “Need to define the mechanism to indicate limitations on > simulcast in the advertisement.” > > It sounds like you are saying you disagree with the premise of Ticket > #18, and we should not need to indicate any limitation on simulcast in > the advertisement. Is that what you mean? > > Mark > > *From:*Roni Even [mailto:ron.even.tlv@gmail.com] > *Sent:* Tuesday, November 27, 2012 9:54 AM > *To:* Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Framework tickets to be closed - simulcast support > > Hi, > > I agree on the first two tickets > > As for ticket #18 the meeting minutes say > > “Roni - Not sure this is enough as does not provide info on which can be simulcast if for example there is a limit of two which two does it mean. > > Rob Hanson - Not so convinced that this is a problem we need to solve in > clue (sorry some missing). > > Roni - Can agree with the previous speaker that does not need to be > solved in clue.” > > This are partial notes but clearly this parameter does not solve > simulcast. So I am not sure why it was added. > > So in my view if we take this ticket out we agree that > > 1.simulcast should not be addressed in CLUE (until we have a different > solution) > > 2.There is no need for the new Max Capture Encoding attribute. > > Roni > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, Mark > *Sent:* 27 November, 2012 3:57 PM > *To:* clue@ietf.org > *Subject:* [clue] Framework tickets to be closed > > Hello Mary and Paul, > > I think a few open tickets can be closed based on > draft-ietf-clue-framework-07. > > Ticket #9 – axis of > capture description > > Ticket #17 – capture > encoding term > > Ticket #18 – > limitations on simulcast > > If you agree, can you please mark these tickets as closed? > > Notes in the “Changes” section of draft-ietf-clue-framework-07: > > -Ticket #9. Rename Axis of Capture Point attribute to Point on Line of > Capture. Clarify the description of this attribute. > > -Ticket #17. Add "capture encoding" definition. Use this new term > throughout document as appropriate, replacing some usage of the terms > "stream" and "encoding". > > -Ticket #18. Add Max Capture Encodings media capture attribute. > > Thanks, > Mark Duckworth > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Wed Nov 28 11:52: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 6B65421F8843 for ; Wed, 28 Nov 2012 11:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.083 X-Spam-Level: X-Spam-Status: No, score=-6.083 tagged_above=-999 required=5 tests=[AWL=0.166, 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 EjG-ftEDyWCr for ; Wed, 28 Nov 2012 11:52:44 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E9E1D21F86D6 for ; Wed, 28 Nov 2012 11:52:43 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-26-50b66b8ad48b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FA.DE.26143.A8B66B05; Wed, 28 Nov 2012 20:52:42 +0100 (CET) Received: from ESESSHC013.ericsson.se (153.88.183.57) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 28 Nov 2012 20:52:42 +0100 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, 28 Nov 2012 20:52:42 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [clue] Capture scene clarifications Thread-Index: AQHNy+i8zk8+n3np90eOVjDiWPg3K5f8f/kg///4BACAAJT3AIAACYqAgABKBzCAAC5pAIABBqqAgABFOkCAAKI3gIAAK/Hd Date: Wed, 28 Nov 2012 19:52:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B048A1E@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> <50B446A8.2010307@nteczone.com> <50B44EA9.30707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B046501@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B046A37@ESESSMB209.ericsson.se> <50B59007.9070502@nteczone.com> <7594FB04B1934943A5C02806D1A2204B047E33@ESESSMB209.ericsson.se>, <50B6522D.2060309@alum.mit.edu> In-Reply-To: <50B6522D.2060309@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+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW5X9rYAg8c/dS2+vG9ksdh/6jKz xYoNB1gdmD3+vv/A5LFkyU8mjxXnZ7IEMEdx2aSk5mSWpRbp2yVwZbTsiSm4Y1/R9+c5UwPj B6MuRk4OCQETian3r7FD2GISF+6tZ+ti5OIQEjjJKLHk2RYoZyejRPfmiewQzhJGiR3XXgJl ODjYBCwkuv9pg5giAhoSk7aqgQxiFgiXuPB4JhuILSxgIHHy4w2wBSIChhJbl8xhhSjPk2hb FwQSZhFQldjZMpkVxOYV8Ja48+UOK8Sm78wSm7+fZQFJcAroSJx8dp0JxGYEOvT7qTVMELvE JW49mc8E8YCAxJI955khbFGJl4//sULYihI7z7YzQ9TrSCzY/YkNwtaWWLbwNTPEYkGJkzOf gO0SAoq3LJ7APoFRYhaSFbOQtM9C0j4LSfsCRpZVjOy5iZk56eVGmxiBUXZwy2/VHYx3zokc YpTmYFES57XeusdfSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6OUSYOO5uv/Kw+kvQ0WXPtN WingaJ5Gy+I40Z274lnfpjYKXxbSj9lgbbjtvdmqJMat6THOr7nuN0S1XX05s3KVwY7KtcUu H/Y9bpbilX8w+9h3Q/NNDtpC9v6Zlse+VpmrruEWDJHqtPbbe/PwNqZbrvk7eDe8tbSr1znR /fQmW8/Fw7orhJVYijMSDbWYi4oTASf/ClSAAgAA 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, 28 Nov 2012 19:52:45 -0000 Hi, > Consider a case where an endpoint has a camera that can be used either > to show part of the room or as a document camera. But it can't be used > for both. > > This might be a case where the presentation stream should be included in > the same scene as the room. (Because it is a view of a whiteboard that > has a physical location within the room.) But maybe not - it might still > be desirable to include it in a separate scene. Lets assume that is the > intent. Well, then you have 3 different scene entries: 1. Room 2. Presentation 3. Room + presentation (where the presentation is the view of the whiteboar= d) Then you indicate that you can provide the following scenes: 1 OR 2 OR 3 OR= (1 AND 2). >Then in this case there will be a mutual exclusion between captures in >one or more scene entries in the room scene, and a capture in a scene >entry in the presentation scene. > >So there is still a need for mutual exclusion sets. I think providing different scene alternatives is enough. Sure, one can come up with examples which, if you need a separate scene to = cover everything, would result in a large numer of scene entries. But, I do= n't really think it's needed in real-life. >Or maybe a more radical change in structure. As I have tried to explain >before, scene entries present alternative representations of a scene. >But there is no way for the advertiser to indicate tradeoffs between >captures in different scenes. Well, my opinion is that there is no need for that. It's enough to indicate= which scenes (including all associated captures) can be provided simultane= ously, as in the example above.=20 Some telepresence vendor can correct me if I'm wrong, but from my personal = experience that would cover existing use-cases, and probably many future on= es too. (We can make sure the protocol is extendable, if someone wants to add more = stuff in future, but I don't think it's needed in order the first shipment.= ) Regards, Christer >Perhaps we should consider allowing an "entry" to contain captures from >multiple scenes, and a single list of such entries, rather than a list >per scene. This would permit the advertiser to make its own decision of >tradeoffs render its advertisement as a whole. > >If we did that, then a scene would simply be an coordinate space and a >set of captures that belong to that coordinate space. Thanks, Paul On 11/28/12 2:28 AM, Christer Holmberg wrote: > Hi, > >> A simultaneous set applies across all capture scenes in an advertisement= so would cover the presentation / video case. I assume each simultaneous s= et can have a mix of media types, although this is not explicit in the fram= ework? > > Sure. But, my understanding was that all captures within a scene have a s= patial relationship. So, for that reason a presentation would have to be pa= rt of a separate scene (unless, of course, the presentation does have some = kind of spatial relationship with the other captures). > >> I agree however if a consumer isn't allowed to select individual capture= s from multiple capture scene entries and scenes then we could probably sim= plify the use of simultaneous sets to the scene level. > > I would support such approach. > > And, in practice this would still allow a consumer to select individual c= aptures, by selecting multiple scenes, and then select captures from each s= cene. BUT, we would not need to describe which captures can be simultaneous= ly provided, because if a provider indicates that SCENES can be provided si= multaneously it automatically means that all captures within those scenes c= an be simultaneously provided. > > Regards, > > Christer > > > Regards, Christian > > On 27/11/2012 10:39 PM, Christer Holmberg wrote: >> Hi, >> >> A little more on this: >> >> Instead of having simultaneous transmission sets, I think it would be mo= re important to have something like "simultaneous capture scene sets". >> >> Because, AFAIK, the video captures and a presentation capture might be p= art of separate capture scene entries (as the presentation does not have an= y spatial relationship with the video). >> >> But, this would not be cherry picking individual captures from different= CSEs, but rather selecting different CSEs - and being able to advertise th= at one can provide CSEs simultaneously. >> >> Regards, >> >> Christer >> >> >> >> >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Christer Holmberg >> Sent: 27. marraskuuta 2012 11:06 >> To: Paul Kyzivat; clue@ietf.org >> Subject: Re: [clue] Capture scene clarifications >> >> Hi, >> >>> Disclaimer - AFAIK I am simply restating the intent of the framework as= it stands. These were not my concepts. But I think I have assimilated the = intent. >>> >>> So it is certainly possible to recast this stuff, but then I think ther= e will need to be some further discussion to fully understand the ramificat= ions of such a change. >>> >>>> I had the same thoughts as Christer. Picking a subset is something >>>> that I could live with, cherry picking captures from different >>>> capture scene entries I think is complicating the issue. >>> Certainly one can argue about how one would know enough to make such a = choice. But I don't see why it is a "complication" from the point of view o= f the provider. >> It makes the procedures more complex. >> >> Without the option to "cherry picking", the provider only needs to say: >> >> "These are my CSEs (Capture Scene Entries). Please pick one, and then ti= ll me which captures you want." >> >> With the option to cherry pick, the provider would in addition also need= to be able to say: >> >> "BTW, if you choose CSE_X, and capture CAP_X, then from CSE_Y can only c= hoose captures CAP_Y1, CAP_Y2, CAP_Y3 - unless you also from CSE_W chooses = capture CAP_W1, in which case you can only choose CAP_Y2 and CAP_Y3 from CS= E_Y". >> >> Etc etc etc etc etc. >> >> I could become very complicated, depending on how far we want to go. >> >>>> The framework says that >>>> provider must be able to supply media related to all the captures >>>> within a capture scene entry. If the consumer chooses different >>>> captures then the provider may not be able to supply these? Do we >>>> then need an extra message for the provider to signal to the >>>> consumer that it can't honour its choice? >>> The simultaneous transmission sets are intended to indicate what can be= transmitted simultaneously. The advertiser should thus be able to transmit= any selection that is in accord with the advertisement. >>> >>> The specification that the provider must be able to supply media relate= d to all captures within a scene entry is simply a further constraint on th= e provider. >>> >>> Once the provider has constructed its advertisement to reflect its cons= traints, it should be no extra complication to supply any conforming select= ion, regardless of which scene entries the captures come from. >>> >>> Perhaps making a limitation of only selecting from one scene entry >>> per scene might simplify the advertisement - perhaps eliminating the ne= ed for the simultaneous transmission set. Or it might simplify the choice o= f configuration. But neither of these seems like enough of a complication t= o worry about. >> I disagree. I think it can become very complicated. >> >> Simultaneous transmission sets is perhaps something we could add in futu= re, if there is a need. >> >> Also, if people are afraid that things will become too easy, please >> join the discussions about SDP and multiple streams per m- line :) >> >> 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 Mark.Duckworth@polycom.com Wed Nov 28 12:36: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 1350C21F84BA for ; Wed, 28 Nov 2012 12:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 bU3ze5P6SzDA for ; Wed, 28 Nov 2012 12:36:27 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 96D0521F88B5 for ; Wed, 28 Nov 2012 12:36:26 -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, 28 Nov 2012 12:36:24 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 28 Nov 2012 12:36:24 -0800 Thread-Topic: [clue] Framework tickets to be closed - simulcast support Thread-Index: AQHw5rvXEApERPQsFuIb6EjUTJuw9QK0O1Epl6H7riCAAeIDMA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610391797B38@CRPMBOXPRD01.polycom.com> References: <044401cdccaf$07ba5ed0$172f1c70$@gmail.com> <44C6B6B2D0CF424AA90B6055548D7A610391797488@CRPMBOXPRD01.polycom.com> <045501cdccb6$c48272d0$4d875870$@gmail.com> In-Reply-To: <045501cdccb6$c48272d0$4d875870$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A610391797B38CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] Framework tickets to be closed - simulcast support X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 28 Nov 2012 20:36:30 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A610391797B38CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Roni, I agree your example is not supported by the current framework. But in my = view, your example shows a media provider restriction that is not intended = to be supported by the framework, regardless of any simulcast consideration= . For example, consider this other case, using the same encoding group of 6 d= ifferent individual encodes in the group 2 HD 2 SD and 2 CIF. And suppose = media captures VC1, VC2, VC3, and VC4 all use that encoding group. But the= media provider has a restriction that VC2 cannot be encoded in HD. The fr= amework does not support this case, and it wasn't intended to. In my view,= this is the same sort of restriction as in your simulcast example. The solution for both examples is that the media provider must use a differ= ent set of encodings in different encoding groups in order to express an ad= vertisement it can actually support. The media provider may not be able to= express all possible flexibility of the different combinations it can supp= ort, but that's okay, the framework isn't trying to enable all conceivable = combinations. More specifically, for your example, suppose the media provi= der can support only HD + CIF for the media capture in question, then the m= edia provider should use an encoding group with 1 HD and 1 CIF for this cap= ture. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, November 27, 2012 10:49 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Framework tickets to be closed - simulcast support Mark, What I was saying is that the Max capture Encoding attribute does not addre= ss the simulcast issue. For example if there are 6 different individual enc= odes in the group 2 HD 2 SD and 2 CIF and the Max Capture encode for a medi= a capture is 2. Which two can the provider send ( HD +SD or HD + CIF or SD+= CIF or 2HD ...) So there is no solution yet for simulcast which I think other agreed in the= meeting. Rob proposed that support for simulcast should not be discussed in CLUE. This is the reason for the two points I made. So we can remove ticket #18 and the Max Capture Encoding If need max capture encoding then need to specify the usage and it is not t= o address simulcast. Note that the same issue I mentioned in the example ab= ove still holds. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: 27 November, 2012 5:19 PM To: clue@ietf.org Subject: Re: [clue] Framework tickets to be closed - simulcast support Hi Roni, Ticket #18 says "Need to define the mechanism to indicate limitations on si= mulcast in the advertisement." It sounds like you are saying you disagree with the premise of Ticket #18, = and we should not need to indicate any limitation on simulcast in the adver= tisement. Is that what you mean? Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, November 27, 2012 9:54 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Framework tickets to be closed - simulcast support Hi, I agree on the first two tickets As for ticket #18 the meeting minutes say "Roni - Not sure this is enough as does not provide info on which can be si= mulcast if for example there is a limit of two which two does it mean. Rob Hanson - Not so convinced that this is a problem we need to solve in cl= ue (sorry some missing). Roni - Can agree with the previous speaker that does not need to be solved = in clue." This are partial notes but clearly this parameter does not solve simulcast.= So I am not sure why it was added. So in my view if we take this ticket out we agree that 1. simulcast should not be addressed in CLUE (until we have a differe= nt solution) 2. There is no need for the new Max Capture Encoding attribute. Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: 27 November, 2012 3:57 PM To: clue@ietf.org Subject: [clue] Framework tickets to be closed Hello Mary and Paul, I think a few open tickets can be closed based on draft-ietf-clue-framework= -07. Ticket #9 - axis of captu= re description Ticket #17 - capture enc= oding term Ticket #18 - limitations= on simulcast If you agree, can you please mark these tickets as closed? Notes in the "Changes" section of draft-ietf-clue-framework-07: - Ticket #9. Rename Axis of Capture Point attribute to Point on Li= ne of Capture. Clarify the description of this attribute. - Ticket #17. Add "capture encoding" definition. Use this new term= throughout document as appropriate, replacing some usage of the terms "str= eam" and "encoding". - Ticket #18. Add Max Capture Encodings media capture attribute. Thanks, Mark Duckworth --_000_44C6B6B2D0CF424AA90B6055548D7A610391797B38CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roni,

I agree your example is not supported by the current fra= mework.  But in my view, your example shows a media provider restricti= on that is not intended to be supported by the framework, regardless of any= simulcast consideration.

 

For example, consider this other case, using the= same encoding group of 6 different in= dividual encodes in the group 2 HD 2 SD and 2 CIF.  And suppose media = captures VC1, VC2, VC3, and VC4 all use that encoding group.  But the = media provider has a restriction that VC2 cannot be encoded in HD.  Th= e framework does not support this case, and it wasn’t intended to.&nb= sp; In my view, this is the same sort of restriction as in your simulcast e= xample.

 

The solution for both examples is that the media provider must use= a different set of encodings in different encoding groups in order to expr= ess an advertisement it can actually support.  The media provider may = not be able to express all possible flexibility of the different combinatio= ns it can support, but that’s okay, the framework isn’t trying = to enable all conceivable combinations.  More specifically, for your e= xample, suppose the media provider can support only HD + CIF for the media = capture in question, then the media provider should use an encoding group w= ith 1 HD and 1 CIF for this capture.

 

Mark

 

= From:= Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Tuesday, Novemb= er 27, 2012 10:49 AM
To: Duckworth, Mark; clue@ietf.org
Sub= ject: RE: [clue] Framework tickets to be closed - simulcast support

 

Mark,

=

What I was saying is tha= t the Max capture Encoding attribute does not address the simulcast issue. = For example if there are 6 different individual encodes in the group 2 HD 2= SD and 2 CIF and the Max Capture encode for a media capture is 2. Which tw= o can the provider send ( HD +SD or HD + CIF or SD+CIF or 2HD …)=

So ther= e is no solution yet for simulcast which I think other agreed in the meetin= g.

= Rob proposed that support for simulcast should not be discussed in CLUE.

This = is the reason for the two points I made.

So we can remove ticket #18 and the M= ax Capture Encoding

 

If need max capture encoding then need to specify th= e usage and it is not to address simulcast. Note that the same issue I ment= ioned in the example above still holds.

 

Roni

 

From: clue-bounces@ietf.org [mailto:clue-bou= nces@ietf.org] On Behalf Of Duckworth, Mark
Sent: 27 Novem= ber, 2012 5:19 PM
To: clue@ietf.org
Subject: Re: [clue]= Framework tickets to be closed - simulcast support

 

Hi Roni,

Ticket #18 says “Need to define the= mechanism to indicate limitations on simulcast in the advertisement.”= ;

I= t sounds like you are saying you disagree with the premise of Ticket #18, a= nd we should not need to indicate any limitation on simulcast in the advert= isement.  Is that what you mean?

Mark

 

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Tuesday, = November 27, 2012 9:54 AM
To: Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Framework ti= ckets to be closed - simulcast support

 

Hi,<= /p>

I agree on the first two tickets

 

As for ticket #1= 8 the meeting minutes say 

“Roni - Not sure this is enoug=
h as does not provide info on which can be simulcast if for example there i=
s a limit of two which two does it mean.

Rob Hanson - Not so convinced that this is a problem we need to s= olve in clue (sorry some missing).

Roni = - Can agree with the previous speaker that does not need to be solved in cl= ue.”

 

This are partial notes but clearly this parameter does not sol= ve simulcast. So I am not sure why it was added.

 

So in my view if we take= this ticket out we agree that

1.2.       = There is no need for the new Max Capture Encoding a= ttribute.

 

Roni

 

 

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: 27 November, 2012 3:57 PM<= br>To: clue@ietf.org
Subj= ect: [clue] Framework tickets to be closed

<= /div>

 

Hello M= ary and Paul,

 

I think a few open tickets can be closed based on draft-iet= f-clue-framework-07.

 

Ticket #9 – axis of capture description

Ticket #17 – capture encoding term

= Ticket #18 – limitations on simulcast

 

If you agree, can you ple= ase mark these tickets as closed?

&= nbsp;

Notes in the “Changes” sect= ion of draft-ietf-clue-framework-07:

-          = Ticket #9. Rename Axis of Capture Point attribute to Point on Lin= e of Capture. Clarify the description of this attribute.

-        &= nbsp; Ticket #17. Add "capture encoding" = definition. Use this new term throughout document as appropriate, replacing= some usage of the terms "stream" and "encoding".<= /o:p>

-      =     Ticket #18. Add Max Capture Enco= dings media capture attribute.

&nbs= p;

Thanks,
Mark Duckworth

= --_000_44C6B6B2D0CF424AA90B6055548D7A610391797B38CRPMBOXPRD01p_-- From pkyzivat@alum.mit.edu Wed Nov 28 12:50: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 AC1DF21F84CA for ; Wed, 28 Nov 2012 12:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[AWL=0.069, 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 0RsFBgrs6UG2 for ; Wed, 28 Nov 2012 12:50:29 -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 71C0D21F8909 for ; Wed, 28 Nov 2012 12:50:10 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta01.westchester.pa.mail.comcast.net with comcast id V0yX1k0050ldTLk518q9pT; Wed, 28 Nov 2012 20:50:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id V8q91k00X3ZTu2S3Q8q9Hc; Wed, 28 Nov 2012 20:50:09 +0000 Message-ID: <50B67900.5030708@alum.mit.edu> Date: Wed, 28 Nov 2012 15:50:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> <50B446A8.2010307@nteczone.com> <50B44EA9.30707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B046501@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B046A37@ESESSMB209.ericsson.se> <50B59007.9070502@nteczone.com> <7594FB04B1934943A5C02806D1A2204B047E33@ESESSMB209.ericsson.se>, <50B6522D.2060309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B048A1E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B048A1E@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=1354135809; bh=4OYANYQ+FU1nx0CKFA+wOjeHq2YVYDL8zLez6nSuuZo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Org9b/bD8e09Z/unZGqc/4fgphgrR8tJRbWo7u4pBVBTeDUVg+219IX1AWhVWXBP5 bpbL5y18KUjGbsS4efBzLEWU8Fwmss3XEhLOaskd+H2DY5InSUS9DxQ5cYbuW+8uNq +B+4f590mazF80aee+C9DQ5TYHG1LdK/gRd9CNyDlTEs/+uLWu6DWuA/JZJY+wLJcX DlTefI1PMJGWM9ul2yyw5QI7HQzznrd7VwuCe5sqmxIHpUgDScEUtWRHnmretAirYe kxs5qqigYgCA2kesBFwPQQ8Mto2XY/m7LL5XH6c44HK/eZFfT9Rgk19Q5/e3tvtFoB t7nFRc3DDGtHg== 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, 28 Nov 2012 20:50:30 -0000 Where is everybody else??? We need other people in this discussion. More inline. On 11/28/12 2:52 PM, Christer Holmberg wrote: > > Hi, > >> Consider a case where an endpoint has a camera that can be used either >> to show part of the room or as a document camera. But it can't be used >> for both. >> >> This might be a case where the presentation stream should be included in >> the same scene as the room. (Because it is a view of a whiteboard that >> has a physical location within the room.) But maybe not - it might still >> be desirable to include it in a separate scene. Lets assume that is the >> intent. > > Well, then you have 3 different scene entries: > > 1. Room > 2. Presentation > 3. Room + presentation (where the presentation is the view of the whiteboard) > > Then you indicate that you can provide the following scenes: 1 OR 2 OR 3 OR (1 AND 2). I don't think so. Above is mixing up scenes and scene entries. Lets get a little more specific. Assume the room has three total cameras: - a "left" camera - a "right" camera - a camera that can be moved & focused, to provide either a view of the whole room, or a view of a document platform. The whole room view may show people not easily and fully viwed in the left/right cameras, but doesn't show people life size. So there are four potential captures: - "left" capture - "right" capture - "whole room" capture - "presentation" capture There will be two scenes in the room, a "room" scene and a "presentation" scene. The "room" scene has multiple entries, while the "presentation" scene has only one entry. "room" scene: - entry: "left", "right", "whole room" - entry: "left", "right" - entry: "whole room" "presentation" scene: - entry: "presentation" Mutual exclusion sets: - "whole room", "presentation" Note that the above gives no guidance to the receiver that can handle only a single capture. Should it take the presentation or the whole room? >> Then in this case there will be a mutual exclusion between captures in >> one or more scene entries in the room scene, and a capture in a scene >> entry in the presentation scene. >> >> So there is still a need for mutual exclusion sets. > > I think providing different scene alternatives is enough. I think I still don't understand what you are proposing. > Sure, one can come up with examples which, if you need a separate scene to cover everything, would result in a large numer of scene entries. But, I don't really think it's needed in real-life. > >> Or maybe a more radical change in structure. As I have tried to explain >> before, scene entries present alternative representations of a scene. >> But there is no way for the advertiser to indicate tradeoffs between >> captures in different scenes. > > Well, my opinion is that there is no need for that. It's enough to indicate which scenes (including all associated captures) can be provided simultaneously, as in the example above. > > Some telepresence vendor can correct me if I'm wrong, but from my personal experience that would cover existing use-cases, and probably many future ones too. > > (We can make sure the protocol is extendable, if someone wants to add more stuff in future, but I don't think it's needed in order the first shipment.) For the example I gave above, using what I am proposing here, there would be a single set of entries covering both scenes: "room" scene: - entry: "left", "right", "whole room" - entry: "left", "right", "presentation" The above are the only alternatives that truely represent the entire room. They don't give any guidance about which to choose if you can't handle three captures. It would be possible to look at attributes of the captures and make some guesses. Alternatively, it would be possible for the advertiser to make its own decisions about what tradeoffs to make when fewer captures can be handled. If so, we might see: "room" scene: - entry: "left", "right", "whole room" - entry: "left", "right", "presentation" - entry: "left", "right" - entry: "whole room" - entry: "presentation" None of the two or one capture entries is really acceptable. It may be necessary for the client to switch among them. Thanks, Paul From christer.holmberg@ericsson.com Thu Nov 29 01:46: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 9F5DD21F89A4 for ; Thu, 29 Nov 2012 01:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.121, 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 8FVSBMro-2zc for ; Thu, 29 Nov 2012 01:46:19 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1760221F89A3 for ; Thu, 29 Nov 2012 01:46:18 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-53-50b72ee8ffeb Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 49.A0.06323.8EE27B05; Thu, 29 Nov 2012 10:46:16 +0100 (CET) Received: from ESESSHC007.ericsson.se (153.88.183.39) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 29 Nov 2012 10:46:14 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 10:46:14 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [clue] Capture scene clarifications Thread-Index: AQHNy+i8zk8+n3np90eOVjDiWPg3K5f8f/kg///4BACAAJT3AIAACYqAgABKBzCAAC5pAIABBqqAgABFOkCAAKI3gIAAK/HdgAACVwCAAOKf4A== Date: Thu, 29 Nov 2012 09:46:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B048FC0@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> <50B446A8.2010307@nteczone.com> <50B44EA9.30707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B046501@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B046A37@ESESSMB209.ericsson.se> <50B59007.9070502@nteczone.com> <7594FB04B1934943A5C02806D1A2204B047E33@ESESSMB209.ericsson.se>, <50B6522D.2060309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B048A1E@ESESSMB209.ericsson.se> <50B67900.5030708@alum.mit.edu> In-Reply-To: <50B67900.5030708@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+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvje4Lve0BBrv/6Vl8ed/IYrH/1GVm ixUbDrA6MHv8ff+ByWPJkp9MHivOz2QJYI7isklJzcksSy3St0vgyuid2cRcsE+zYsbXBqYG xscKXYycHBICJhJndsxlh7DFJC7cW8/WxcjFISRwklFiwsxZ7BDOTkaJp2cWQzlLGCWufP3B 3MXIwcEmYCHR/U8bxBQR0JCYtFUNZBCzQLjEhccz2UBsYQEDiZMfb4AtEBEwlNi6ZA4rhF0n 8fbDJRYQm0VAVeLN/ptgNbwC3hJ3nt+GWnWbRWLDtLvMIAlOAR2Jv1smM4LYjECXfj+1hgli mbjErSfzmSA+EJBYsuc8M4QtKvHy8T9WCFtRYufZdmaIeh2JBbs/sUHY2hLLFr5mhlgsKHFy 5hOwg4SA4i2LJ7BPYJSYhWTFLCTts5C0z0LSvoCRZRUje25iZk56ufkmRmCkHdzy22AH46b7 YocYpTlYlMR59VT3+wsJpCeWpGanphakFsUXleakFh9iZOLglGpg3KzUcaKjbcdlzqc6bSbu 8woM5iXauyx20l/GHGbPfiW6/wXfOobmP9vMY6Yz1b+fviLyj9bFX+1zat0SfH0Nezur4msP nKwRWsQutefKzGUm79JYZr/mfX7Bd45gIM+GD9lm65SU/6eGTT4jwTHhT/eKBVb7ry64l3E3 c3rSRP1HJTfEc5SOKbEUZyQaajEXFScCAEwj8uWCAgAA 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, 29 Nov 2012 09:46:20 -0000 Hi, >Where is everybody else??? We need other people in this discussion. Especially those who actually design telepresence rooms. >>> Consider a case where an endpoint has a camera that can be used=20 >>> either to show part of the room or as a document camera. But it can't=20 >>> be used for both. >>> >>> This might be a case where the presentation stream should be included=20 >>> in the same scene as the room. (Because it is a view of a whiteboard=20 >>> that has a physical location within the room.) But maybe not - it=20 >>> might still be desirable to include it in a separate scene. Lets=20 >>> assume that is the intent. >> >> Well, then you have 3 different scene entries: >> >> 1. Room >> 2. Presentation >> 3. Room + presentation (where the presentation is the view of the=20 >> whiteboard) >> >> Then you indicate that you can provide the following scenes: 1 OR 2 OR 3= OR (1 AND 2). > > I don't think so. Above is mixing up scenes and scene entries. I guess I messed up terminology. Sorry for that. I was meant to say that we have 3 different SCENES. (Perhaps one could argue that 1) and 3) are capture scene entries for the s= ame scene, but I don't think it is). >Lets get a little more specific. Assume the room has three total cameras: >- a "left" camera >- a "right" camera >- a camera that can be moved & focused, to provide either > a view of the whole room, or a view of a document platform. > The whole room view may show people not easily and fully viwed > in the left/right cameras, but doesn't show people life size. > >So there are four potential captures: >- "left" capture >- "right" capture >- "whole room" capture >- "presentation" capture Yes. >There will be two scenes in the room, a "room" scene and a "presentation" = scene. The "room" scene has multiple entries, while the "presentation" scen= e has only one entry. > > >"room" scene: >- entry: "left", "right", "whole room" >- entry: "left", "right" >- entry: "whole room" Yes. >"presentation" scene: >- entry: "presentation" Yes. >Mutual exclusion sets: >- "whole room", "presentation" Yes.=20 >Note that the above gives no guidance to the receiver that can handle only= a single capture. Should it take the presentation or the whole room? It is of course good if we can provide a mechanism to convey information, b= ut the actual decision is an application issue. >>> Then in this case there will be a mutual exclusion between captures=20 >>> in one or more scene entries in the room scene, and a capture in a=20 >>> scene entry in the presentation scene. >>> >>> So there is still a need for mutual exclusion sets. >> >> I think providing different scene alternatives is enough. > > I think I still don't understand what you are proposing. I think I am proposing exactly what you described above :) >>>> Sure, one can come up with examples which, if you need a separate scen= e to cover everything, would result in a large numer of scene entries. But,= I don't really think it's needed in real-life. >>>> >>>> Or maybe a more radical change in structure. As I have tried to=20 >>>> explain before, scene entries present alternative representations of a= scene. >>>> But there is no way for the advertiser to indicate tradeoffs between=20 >>>> captures in different scenes. >>> >>> Well, my opinion is that there is no need for that. It's enough to indi= cate which scenes (including all associated captures) can be provided simul= taneously, as in the example above. >>> >>> Some telepresence vendor can correct me if I'm wrong, but from my perso= nal experience that would cover existing use-cases, and probably many futur= e ones too. >>> >>> (We can make sure the protocol is extendable, if someone wants to add=20 >>> more stuff in future, but I don't think it's needed in order the first= =20 >>> shipment.) >> >> For the example I gave above, using what I am proposing here, there woul= d be a single set of entries covering both scenes: >> >> "room" scene: >> - entry: "left", "right", "whole room" >> - entry: "left", "right", "presentation" > > The above are the only alternatives that truely represent the entire room= . They don't give any guidance about which to choose if you can't handle=20 > three captures. It would be possible to look at attributes of the capture= s and make some guesses. Yes. >Alternatively, it would be possible for the advertiser to make its own dec= isions about what tradeoffs to make when fewer captures can be handled. If = so, we might see: > >"room" scene: >- entry: "left", "right", "whole room" >- entry: "left", "right", "presentation" >- entry: "left", "right" >- entry: "whole room" >- entry: "presentation" > > None of the two or one capture entries is really acceptable. It may be ne= cessary for the client to switch among them. Sure. But, again, I don't we need to provide a mechanism for the receiver t= o create his own entry, by cherry picking captures from different entries. = Because, that would mean that the provider, for each capture in each entry,= need to indicate how/if a capture can be provided together with captures i= n other entries. Regards, Christer From Christian.Groves@nteczone.com Thu Nov 29 15:58: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 5F27421F88F2 for ; Thu, 29 Nov 2012 15:58: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=[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 4-FX0R0Iet4V for ; Thu, 29 Nov 2012 15:58:58 -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 EE1FA21F8231 for ; Thu, 29 Nov 2012 15:58:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQDAHD1t1B20YOe/2dsb2JhbAANLQq8PoJBBAOBFoMRAQEBBDgbIQQBEAsYCRYPCQMCAQIBRQYNAQcBARWzQZNVjEARhDADkk+WfA Received: from ppp118-209-131-158.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.131.158]) by ipmail06.adl2.internode.on.net with ESMTP; 30 Nov 2012 10:28:56 +1030 Message-ID: <50B7F6BB.2030309@nteczone.com> Date: Fri, 30 Nov 2012 10:58:51 +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: Christer Holmberg References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> <50B446A8.2010307@nteczone.com> <50B44EA9.30707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B046501@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B046A37@ESESSMB209.ericsson.se> <50B59007.9070502@nteczone.com> <7594FB04B1934943A5C02806D1A2204B047E33@ESESSMB209.ericsson.se>, <50B6522D.2060309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B048A1E@ESESSMB209.ericsson.se> <50B67900.5030708@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B048FC0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B048FC0@ESESSMB209.ericsson.se> 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, 29 Nov 2012 23:58:59 -0000 Hello, On 29/11/2012 8:46 PM, Christer Holmberg wrote: > Hi, > >> Where is everybody else??? We need other people in this discussion. > Especially those who actually design telepresence rooms. > >>>> Consider a case where an endpoint has a camera that can be used >>>> either to show part of the room or as a document camera. But it can't >>>> be used for both. >>>> >>>> This might be a case where the presentation stream should be included >>>> in the same scene as the room. (Because it is a view of a whiteboard >>>> that has a physical location within the room.) But maybe not - it >>>> might still be desirable to include it in a separate scene. Lets >>>> assume that is the intent. >>> Well, then you have 3 different scene entries: >>> >>> 1. Room >>> 2. Presentation >>> 3. Room + presentation (where the presentation is the view of the >>> whiteboard) >>> >>> Then you indicate that you can provide the following scenes: 1 OR 2 OR 3 OR (1 AND 2). >> I don't think so. Above is mixing up scenes and scene entries. > I guess I messed up terminology. Sorry for that. > > I was meant to say that we have 3 different SCENES. > > (Perhaps one could argue that 1) and 3) are capture scene entries for the same scene, but I don't think it is). [CNG] Isn't there still only two scenes? Is the room + presentation spatially related? If not then they are two separate scenes. > > >> Lets get a little more specific. Assume the room has three total cameras: >> - a "left" camera >> - a "right" camera >> - a camera that can be moved & focused, to provide either >> a view of the whole room, or a view of a document platform. >> The whole room view may show people not easily and fully viwed >> in the left/right cameras, but doesn't show people life size. >> >> So there are four potential captures: >> - "left" capture >> - "right" capture >> - "whole room" capture >> - "presentation" capture > Yes. > >> There will be two scenes in the room, a "room" scene and a "presentation" scene. The "room" scene has multiple entries, while the "presentation" scene has only one entry. >> >> >> "room" scene: >> - entry: "left", "right", "whole room" >> - entry: "left", "right" >> - entry: "whole room" > Yes. > >> "presentation" scene: >> - entry: "presentation" > Yes. > >> Mutual exclusion sets: >> - "whole room", "presentation" > Yes. > >> Note that the above gives no guidance to the receiver that can handle only a single capture. Should it take the presentation or the whole room? > It is of course good if we can provide a mechanism to convey information, but the actual decision is an application issue. [CNG] I think this perhaps is a fundamental point. Its hard to define the protocol if we don't at least have a good understanding of what the sender and the receiver will do with the information. The idea behind the capture attribute draft was to give enough information to the receiver to decide what capture/s (and scenes) is more important to it. My assumption is that the receiver will parse a CLUE advertisement in the following manner: 1a. For each scene parse the capture scene entries 1b. For each media type: 1c. Check capture attributes to determine if best match according to local policy. i.e. best match according to content and spatial information. 2. The result of stage 1 will be to identify: a) a list of scenes that the receiving would like b) a for each scene a prioritised list of capture scene entries. 3. Based on stage 2 the receiver will then check the prioritised scenes/capture scene entries against any simultaneity requirements. 4. The resultant selected captures are then checked against encoding requirements. 5. The receiver then replies to the advertiser the scenes/capture scene entries that it wishes to receive. Is this what others had in mind? > >>>> Then in this case there will be a mutual exclusion between captures >>>> in one or more scene entries in the room scene, and a capture in a >>>> scene entry in the presentation scene. >>>> >>>> So there is still a need for mutual exclusion sets. >>> I think providing different scene alternatives is enough. >> I think I still don't understand what you are proposing. > I think I am proposing exactly what you described above :) > > > >>>>> Sure, one can come up with examples which, if you need a separate scene to cover everything, would result in a large numer of scene entries. But, I don't really think it's needed in real-life. >>>>> >>>>> Or maybe a more radical change in structure. As I have tried to >>>>> explain before, scene entries present alternative representations of a scene. >>>>> But there is no way for the advertiser to indicate tradeoffs between >>>>> captures in different scenes. >>>> Well, my opinion is that there is no need for that. It's enough to indicate which scenes (including all associated captures) can be provided simultaneously, as in the example above. >>>> >>>> Some telepresence vendor can correct me if I'm wrong, but from my personal experience that would cover existing use-cases, and probably many future ones too. >>>> >>>> (We can make sure the protocol is extendable, if someone wants to add >>>> more stuff in future, but I don't think it's needed in order the first >>>> shipment.) >>> For the example I gave above, using what I am proposing here, there would be a single set of entries covering both scenes: >>> >>> "room" scene: >>> - entry: "left", "right", "whole room" >>> - entry: "left", "right", "presentation" >> The above are the only alternatives that truely represent the entire room. They don't give any guidance about which to choose if you can't handle >> three captures. It would be possible to look at attributes of the captures and make some guesses. > Yes. > >> Alternatively, it would be possible for the advertiser to make its own decisions about what tradeoffs to make when fewer captures can be handled. If so, we might see: >> >> "room" scene: >> - entry: "left", "right", "whole room" >> - entry: "left", "right", "presentation" >> - entry: "left", "right" >> - entry: "whole room" >> - entry: "presentation" >> >> None of the two or one capture entries is really acceptable. It may be necessary for the client to switch among them. [CNG] Are you proposing that the advertiser provides these alternatives or is this what the consumer constructs? > Sure. But, again, I don't we need to provide a mechanism for the receiver to create his own entry, by cherry picking captures from different entries. Because, that would mean that the provider, for each capture in each entry, need to indicate how/if a capture can be provided together with captures in other entries. > > Regards, > > Christer > > From christer.holmberg@ericsson.com Thu Nov 29 23:54: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 0307E21F88E9 for ; Thu, 29 Nov 2012 23:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.088, 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 zGUdvISKylk1 for ; Thu, 29 Nov 2012 23:54:37 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 906FE21F8946 for ; Thu, 29 Nov 2012 23:54:36 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-1f-50b8663bd889 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 57.4F.11564.B3668B05; Fri, 30 Nov 2012 08:54:35 +0100 (CET) Received: from ESESSHC003.ericsson.se (153.88.183.27) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 30 Nov 2012 08:54:35 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 08:54:35 +0100 From: Christer Holmberg To: Christian Groves Thread-Topic: [clue] Capture scene clarifications Thread-Index: AQHNy+i8zk8+n3np90eOVjDiWPg3K5f8f/kg///4BACAAJT3AIAACYqAgABKBzCAAC5pAIABBqqAgABFOkCAAKI3gIAAK/HdgAACVwCAAOKf4IAA5HCAgACSFqA= Date: Fri, 30 Nov 2012 07:54:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B049FBF@ESESSMB209.ericsson.se> References: <50AEF3CB.7020904@nteczone.com> <50B38773.6080206@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B04618E@ESESSMB209.ericsson.se> <50B3C9B2.3030100@alum.mit.edu> <50B446A8.2010307@nteczone.com> <50B44EA9.30707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B046501@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B046A37@ESESSMB209.ericsson.se> <50B59007.9070502@nteczone.com> <7594FB04B1934943A5C02806D1A2204B047E33@ESESSMB209.ericsson.se>, <50B6522D.2060309@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B048A1E@ESESSMB209.ericsson.se> <50B67900.5030708@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B048FC0@ESESSMB209.ericsson.se> <50B7F6BB.2030309@nteczone.com> In-Reply-To: <50B7F6BB.2030309@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+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvja512o4AgxP35S2+vG9ksdh/6jKz xYoNB1gdmD3+vv/A5LFkyU8mjxXnZ7IEMEdx2aSk5mSWpRbp2yVwZRzfv5C14KdZxa+WOawN jHu0uxg5OSQETCQuNW5mhLDFJC7cW8/WxcjFISRwklHi+MNnzBDOTkaJc/9WsYBUCQksYZQ4 fTWvi5GDg03AQqL7nzaIKQI0aP5ZTZAKZgFPib4Ts9lAbGEBA4mTH2+wg9giAoYSW5fMYQUZ KSLQxSixtXkiE0iCRUBV4vLN2WDjeQW8Ja5OesIEsXc/q8Te9q1gRZwCOhKP738Du5QR6NLv p9YwQWwTl7j1ZD4TxAcCEkv2nGeGsEUlXj7+xwphK0rsPNvODFGvI7Fg9yc2CFtbYtnC18wQ iwUlTs58AvWjtkTL4gnsExglZiFZMQtJ+ywk7bOQtC9gZFnFyJ6bmJmTXm64iREYaQe3/Nbd wXjqnMghRmkOFiVxXq6k/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGOUrdz/nebtbyvT8 soB7Ztbfvx1+s8aOdcaN/bE5cu0Mn48vOJPC8u7D0dW5SROnJqmdPHd6TfbXKSb72q0Fnbt/ 3Vjyc+PZe34he1dOZ9ku1usYcdere0/c6aAtToEc6xsMBULlU48c1lCdteGayI9IodVy9V9/ tXyvuT+jf6G8Q1TJC7nLX5crsRRnJBpqMRcVJwIAhuBUUYICAAA= 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, 30 Nov 2012 07:54:38 -0000 Hi, >>>>> Consider a case where an endpoint has a camera that can be used=20 >>>>> either to show part of the room or as a document camera. But it=20 >>>>> can't be used for both. >>>>> >>>>> This might be a case where the presentation stream should be=20 >>>>> included in the same scene as the room. (Because it is a view of a=20 >>>>> whiteboard that has a physical location within the room.) But maybe=20 >>>>> not - it might still be desirable to include it in a separate=20 >>>>> scene. Lets assume that is the intent. >>>> Well, then you have 3 different scene entries: >>>> >>>> 1. Room >>>> 2. Presentation >>>> 3. Room + presentation (where the presentation is the view of the >>>> whiteboard) >>>> >>>> Then you indicate that you can provide the following scenes: 1 OR 2 OR= 3 OR (1 AND 2). >>> I don't think so. Above is mixing up scenes and scene entries. >> I guess I messed up terminology. Sorry for that. >> >> I was meant to say that we have 3 different SCENES. >> >> (Perhaps one could argue that 1) and 3) are capture scene entries for th= e same scene, but I don't think it is). > [CNG] Isn't there still only two scenes? Is the room + presentation spati= ally related? If not then they are two separate scenes. In the Room + Presentation alternative they ARE spatially related. >>> Lets get a little more specific. Assume the room has three total camera= s: >>> - a "left" camera >>> - a "right" camera >>> - a camera that can be moved & focused, to provide either >>> a view of the whole room, or a view of a document platform. >>> The whole room view may show people not easily and fully viwed >>> in the left/right cameras, but doesn't show people life size. >>> >>> So there are four potential captures: >>> - "left" capture >>> - "right" capture >>> - "whole room" capture >>> - "presentation" capture >> Yes. >> >>> There will be two scenes in the room, a "room" scene and a "presentatio= n" scene. The "room" scene has multiple entries, while the "presentation" s= cene has only one entry. >>> >>> >>> "room" scene: >>> - entry: "left", "right", "whole room" >>> - entry: "left", "right" >>> - entry: "whole room" >> Yes. >> >>> "presentation" scene: >>> - entry: "presentation" >> Yes. >> >>> Mutual exclusion sets: >>> - "whole room", "presentation" >> Yes. >> >>> Note that the above gives no guidance to the receiver that can handle o= nly a single capture. Should it take the presentation or the whole room? >> It is of course good if we can provide a mechanism to convey information= , but the actual decision is an application issue. >> > [CNG] I think this perhaps is a fundamental point. Its hard to define the= protocol if we don't at least have a good understanding of what the sender= and the=20 > receiver will do with the information. The idea behind the capture attrib= ute draft was to give enough information to the receiver to decide what cap= ture/s (and scenes)=20 > is more important to it.=20 The spatial information of course need to be there. Then, as you say, we either have to provide content information about the c= apture, OR provide enough entries so that virtually any receiver will find = one which fits its capabilities. > My assumption is that the receiver will parse a CLUE advertisement in the= following manner: > 1a. For each scene parse the capture scene entries > 1b. For each media type: > 1c. Check capture attributes to determine if best match > according to local policy. i.e. best match according > to content and spatial information. > 2. The result of stage 1 will be to identify: > a) a list of scenes that the receiving would like > b) a for each scene a prioritised list of capture scene entries. > 3. Based on stage 2 the receiver will then check the prioritised scenes/c= apture scene entries against any simultaneity requirements. > 4. The resultant selected captures are then checked against encoding requ= irements. > 5. The receiver then replies to the advertiser the scenes/capture scene e= ntries that it wishes to receive. > > Is this what others had in mind? Steps 1-4 are of course implementation dependent, but my assumption is also= that step 5 is the outcome :) >>>>>> Sure, one can come up with examples which, if you need a separate sc= ene to cover everything, would result in a large numer of scene entries. Bu= t, I don't really think it's needed in real-life. >>>>>> >>>>>> Or maybe a more radical change in structure. As I have tried to=20 >>>>>> explain before, scene entries present alternative representations of= a scene. >>>>>> But there is no way for the advertiser to indicate tradeoffs=20 >>>>>> between captures in different scenes. >>>>> Well, my opinion is that there is no need for that. It's enough to in= dicate which scenes (including all associated captures) can be provided sim= ultaneously, as in the example above. >>>>> >>>>> Some telepresence vendor can correct me if I'm wrong, but from my per= sonal experience that would cover existing use-cases, and probably many fut= ure ones too. >>>>> >>>>> (We can make sure the protocol is extendable, if someone wants to=20 >>>>> add more stuff in future, but I don't think it's needed in order=20 >>>>> the first >>>>> shipment.) >>>> For the example I gave above, using what I am proposing here, there wo= uld be a single set of entries covering both scenes: >>>> >>>> "room" scene: >>>> - entry: "left", "right", "whole room" >>>> - entry: "left", "right", "presentation" >>> The above are the only alternatives that truely represent the entire=20 >>> room. They don't give any guidance about which to choose if you can't h= andle three captures. It would be possible to look at attributes of the cap= tures and make some guesses. >> Yes. >> >>> Alternatively, it would be possible for the advertiser to make its own = decisions about what tradeoffs to make when fewer captures can be handled. = If so, we might see: >>> >>> "room" scene: >>> - entry: "left", "right", "whole room" >>> - entry: "left", "right", "presentation" >>> - entry: "left", "right" >>> - entry: "whole room" >>> - entry: "presentation" >>> >>> None of the two or one capture entries is really acceptable. It may be = necessary for the client to switch among them. > > [CNG] Are you proposing that the advertiser provides these alternatives o= r is this what the consumer constructs? I guess Paul should reply, but my opinion is still that the receiver shall = not construct entries. It shall choose from the advertised entries. Otherwise, the provider will have to convey information about how entries c= an be constructed (how captures from different entries can be combined into= a new entry, etc), and I see no need for that. If an advertiser provides enough entries, I'm sure the receiver will find a= suitable one :) Regards, Christer From christer.holmberg@ericsson.com Fri Nov 30 05:29:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE6421F84DC for ; Fri, 30 Nov 2012 05:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.082, 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 Hy+aKqPO+BF4 for ; Fri, 30 Nov 2012 05:29:22 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 37C3221F8570 for ; Fri, 30 Nov 2012 05:29:21 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-6d-50b8b4af31f6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 73.02.26143.FA4B8B05; Fri, 30 Nov 2012 14:29:19 +0100 (CET) Received: from ESESSHC014.ericsson.se (153.88.183.60) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 30 Nov 2012 14:29:19 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 14:29:19 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Scene for non-CLUE/single stream devices Thread-Index: Ac3O/cBOqjJfJqi7TtKPPA0WZP9uYQ== Date: Fri, 30 Nov 2012 13:29:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B04A64C@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B04A64CESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje76LTsCDP5+07bYf+oyswOjx5Il P5kCGKO4bFJSczLLUov07RK4Mvbde8hUcNq54tWuu+wNjJ+tuhg5OSQETCSWX2pnhrDFJC7c W8/WxcjFISRwklHi7/0lLBDOTkaJfQ0PmUCqhASWMEp8fi3RxcjBwSZgIdH9TxskLCKgLHF0 cz8biC0sYCjx48V6Voi4mcTGVe0sELaexOGur8wgrSwCqhKbrhSDhHkFvCW2rpjMCGIzAt3w /dQasE3MAuISt57MZ4K4TUBiyZ7zUHeKSrx8/I8VwlaU2HkW4n5mgXyJGavusUHMFJQ4OfMJ C8TF2hItiyewT2AUmYVk7CwkLbOQtEDEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjOy5 iZk56eVGmxiBUXJwy2/VHYx3zokcYpTmYFES57XeusdfSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA2NUc7WckJZggfz7IJ6OL6vESuep7N3SKqduVfda117GRbJX2S7Qba0r93lhHg6hFnEf ttKXS84U/49fpWVpuXdi91OVdovZ4RE5PmI2c1hEmAW/7PffGSUWd9x55nal82FLLT6qreKd Yp7wfRXz4bKMxwHJBxI0GD+1VnG1HnwYzZGwOGqWEktxRqKhFnNRcSIAAMvsEWACAAA= Subject: [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: Fri, 30 Nov 2012 13:29:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B04A64CESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As we know, we have use-case and requirement to interwork with non-CLUE/"si= ngle 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 l= ook like, 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 un= derstand multiple streams per m- line, and the need for understanding the s= tream content is minimal. The provider of course have to be prepared that the non-CLUE entity may rej= ect one or more of the offered streams. For example, an audio-only device w= ould 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. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B04A64CESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As we know, we have use-case and requirement to inte= rwork 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 fro= m a CLUE entity shall look like, 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:

 

-     &= nbsp;    1 audio stream (single ssrc)

-     &= nbsp;    1 video stream (single ssrc)

-     &= nbsp;    1 presentation (video?) stream (single ssrc)

 

This does not require spatial information, the recei= ver 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.

 

Regards,

 

Christer

 

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B04A64CESESSMB209ericsso_-- From pkyzivat@alum.mit.edu Fri Nov 30 10:02: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 BB31121F8A60 for ; Fri, 30 Nov 2012 10:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=0.045, 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 6n4+JqPOJjPt for ; Fri, 30 Nov 2012 10:02:36 -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 EF6A421F89A5 for ; Fri, 30 Nov 2012 10:02:35 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id Vsmi1k00H1uE5Es53u2VlN; Fri, 30 Nov 2012 18:02:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id Vu2V1k00W3ZTu2S3cu2Vvx; Fri, 30 Nov 2012 18:02:29 +0000 Message-ID: <50B8F4B3.6010206@alum.mit.edu> Date: Fri, 30 Nov 2012 13:02:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B04A64C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B04A64C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354298549; bh=3p/D5q8JEH3s/s4Vpw654Al9TrDxOPgjYlWjY4XL/1Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LNLSHoUJtvxpZoOpD7XORCVHeCjrzrvypZiYQkVnT2mtSYTwQtCtEQQitHACMmDP2 SG28a2MCOkU5qwtylu8j9dlbgowNdGJFii5lZlEp+ONe/3AS6BF1xv4wfRV9cMT7AK t7eTTPJQB+X1IaGicY0aXYqxXY3p2S8K23I8JqHgXYOS4WSvj09onRCXBJtCt7rp2v mwAtwHQogGrZdbevUu9UwLiEcLvy/BSD8EMwgKoTyd7OyPU+70+O+MYBoXnSc4lIB9 WJkGA10X1s+FTR4DEf8qHzfppYRZTMYpQCU5YrYaAFFHXE8LDls+lx1lwG1zKmtnKL iVSk+8E7fyF7A== 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: Fri, 30 Nov 2012 18:02:36 -0000 On 11/30/12 8:29 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. > 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. 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? Thanks Paul