Re: [clue] Data model - agreement on objective and basic approach

["Roni Even" <[e-mail]>]

Hi Paul,
See inline
I am not sure What we are arguing, the mapping is always needed. I do no
understand why you mention static and dynamic mapping.
Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[e-mail]] 
Sent: 31 October, 2012 3:35 PM
To: Roni Even
Cc: [e-mail]
Subject: Re: [clue] Data model - agreement on objective and basic approach

On 10/31/12 2:43 AM, Roni Even wrote:
> Paul,
> I am saying that CLUE does not work without mapping of RTP streams 
> (identified by SSRC) and Media Captures, it is true for static or 
> dynamic mapping.

Oh, ok. Yes, I thought that was clear. It is my understanding that the
static mapping intends to associate a particular capture encoding with a
particular *ssrc*, and so to the RTP stream with that ssrc. That only works
when the capture encoding has a 1:1 association with a single ssrc.


Roni: the last sentence is the common usage today where the SSRC is fixed by
the sending EP or by the MCU who terminates the RTCP.

The point of the RTP extension for the dynamic mapping is to carry an
identifier for the capture encoding, independent of ssrc. That way the
capture encoding of an RTP stream can be identified even when the ssrc may
change over time for that stream.

Roni: The change may be signaled with the CSRC for the static use case.

	Thanks,
	Paul

> Roni
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Paul Kyzivat
> Sent: 31 October, 2012 2:22 AM
> To: [e-mail]
> Subject: Re: [clue] Data model - agreement on objective and basic 
> approach
>
> On 10/30/12 7:01 PM, Roni Even wrote:
>> Mary,
>>
>> Just as a point that CLUE does not work if you cannot say which SSRC 
>> is a specific media capture in CLUE
>
> I have now gotten lost in this thread. I don't understand what in the 
> thread this comment was intended to respond to.
>
> But responding to just this statement, it sounds like a denial of the 
> dynamic mapping, which explicitly separates the identification of a 
> capture (actually capture encoding) from an SSRC.
>
> So are you saying thata CLUE does not work with the dynamic mapping?
>
> 	Thanks,
> 	Paul
>
>> Roni
>>
>> *From:*[e-mail] [mailto:[e-mail]] *On 
>> Behalf Of *Mary Barnes
>> *Sent:* 30 October, 2012 11:49 PM
>> *To:* Roni Even
>> *Cc:* CLUE
>> *Subject:* Re: [clue] Data model - agreement on objective and basic 
>> approach
>>
>> I think that would belong in the protocol document - that is where the
>> SIPREC WG has described their usage of RTP.   Any specific changes to
>> the RTP and SDP would of course be submitted as documents in the 
>> AVTCORE and MMUSIC WGs.
>>
>> However, it may be better to keep that document separate for a while 
>> - that is also the model that SIPREC used/
>>
>> Mary.
>>
>> On Tue, Oct 30, 2012 at 4:42 PM, Roni Even 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> Hi Mary,
>>
>> What about the mapping of RTP streams to Media Captures, where does 
>> it fall
>>
>> BTW: the mapping may require an identfier for the media capture
>>
>> Roni
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>
>> *From:*[e-mail] <mailto:[e-mail]> 
>> [[e-mail] <mailto:[e-mail]>] on behalf of 
>> Mary Barnes [[e-mail] 
>> <mailto:[e-mail]>]
>> *Sent:* Tuesday, October 30, 2012 11:25 PM
>> *To:* CLUE
>>
>>
>> *Subject:* Re: [clue] Data model - agreement on objective and basic 
>> approach
>>
>> I think this is a reasonable split and I don't think it's that much 
>> of a killer task to do so.  We have talked in the past about whether 
>> we should split some material from the framework.  I think doing so 
>> will make it easier for individuals to edit the various pieces.  We 
>> will of course have to ensure consistency.  However,  this approach adds
some
>> good checks and balances, I believe.   This model is quite similar to
>> what worked very well for the XCON work and it's quite similar to 
>> what other WGs are doing (e.g., SIPREC).
>>
>> The chairs have delayed updating our milestones since we had not 
>> decided individual deliverables related to the solution.
>>
>> As chair I would like to gauge consensus on this approach.  So, if 
>> people could please respond as to whether they support the general 
>> idea of splitting the work into the following documents/deliverables:
>>
>> 1) Framework
>>
>> 2) Data model
>>
>> 3) Protocol
>>
>> 4) Call Flows
>>
>> If we can get consensus on the basic idea, then we can work out the 
>> details starting with Simon's suggestion.
>>
>> I do have one comment about the "orchestration document" as I think 
>> that might be appropriate for the framework, but we could certainly 
>> work on that separately and decide later.
>>
>> Thanks,
>>
>> Mary.
>>
>> On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano 
>> <[e-mail] <mailto:[e-mail]>> 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
>> 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: [e-mail] <mailto:[e-mail]>
>>          <mailto:[e-mail] <mailto:[e-mail]>>
>>          [mailto:[e-mail] <mailto:[e-mail]>] On
>>          Behalf Of Paul
>>          Kyzivat
>>          Sent: 29 October, 2012 9:46 PM
>>          To: [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>          <mailto:[e-mail]>>
>>          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:*[e-mail] <mailto:[e-mail]>
>>          <mailto:[e-mail] <mailto:[e-mail]>>
>>          [mailto:[e-mail] <mailto:[e-mail]>]
>>          *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
>>          [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>          <mailto:[e-mail]>>
>>          https://www.ietf.org/mailman/listinfo/clue
>>
>>
>>          _______________________________________________
>>          clue mailing list
>>          [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>          <mailto:[e-mail]>>
>>          https://www.ietf.org/mailman/listinfo/clue
>>
>>
>>          _______________________________________________
>>          clue mailing list
>>          [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>          <mailto:[e-mail]>>
>>          https://www.ietf.org/mailman/listinfo/clue
>>
>>
>>          _\\|//_
>>                 ( O-O )
>>            ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>>          Simon Pietro Romano
>>          Universita' di Napoli Federico II
>>            Computer Engineering Department
>>             Phone: [phone] <tel:%2B39%20081%207683823> -- Fax:
>>          [phone] <tel:%2B39%20081%207683816>
>>            e-mail: [e-mail] <mailto:[e-mail]>
>>          <mailto:[e-mail] <mailto:[e-mail]>>
>>
>>          <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli
>>            idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>>                                oooO
>>             ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>>                  \ (            (   )
>>                                   \_)          ) /
>>                                    (_/
>>
>>
>>
>>
>>
>>
>>
>>          _______________________________________________
>>          clue mailing list
>>          [e-mail] <mailto:[e-mail]>
>>          https://www.ietf.org/mailman/listinfo/clue
>>
>>
>>          _______________________________________________
>>          clue mailing list
>>          [e-mail] <mailto:[e-mail]>
>>          https://www.ietf.org/mailman/listinfo/clue
>>
>>      --
>>
>>                                   _\\|//_
>>                                   ( O-O )
>>          ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>>                           Simon Pietro Romano
>>                     Universita' di Napoli Federico II
>>
>>                        Computer Science Department
>>               Phone: [phone] <tel:%2B39%20081%207683823> -- Fax:
>>      [phone] <tel:%2B39%20081%207684219>
>>                       e-mail: [e-mail]
<mailto:[e-mail]>
>>      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~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>                                 \ (    (   )
>>                                  \_)    ) /
>>                                        (_/
>>
>>      _______________________________________________
>>      clue mailing list
>>      [e-mail] <mailto:[e-mail]>
>>      https://www.ietf.org/mailman/listinfo/clue
>>
>>
>>
>> _______________________________________________
>> clue mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>
>