Subject: Re: [clue] more taxonomy

From: Christian Groves <[email-masked]>
Date: Tue, 17 Jun 2014 11:33:06 +1000

Hello Mark,

Please see my comments below.

Regards, Christian

On 14/05/2014 10:03 AM, Duckworth, Mark wrote:
>
> I’m looking at more terms and concepts that are used both in CLUE and 
> in draft-ietf-avtext-rtp-grouping-taxonomy-01.
>
> Should we add some of this to the framework definitions section, to 
> indicate how the CLUE terms relate to taxonomy terms?
>
> CLUE Media Capture: I’m not sure about this. I was going to say it is 
> the same as taxonomy Media Capture, with either physical stimulus or 
> synthetic stimulus. But the taxonomy draft says a CLUE Media Capture 
> is the same as a taxonomy Media Source. I don’t see how it makes any 
> difference to CLUE either way. What do you think?
>
[CNG] I think CLUE captures can be either a RTP taxonomy media capture 
or media source. The distinguishing factor appears to be that the media 
capture is raw stream and a media source is a processed stream. CLUE 
media captures could be either. This could be updated in the taxonomy draft.
>
> CLUE Individual Encoding: I think this is parameters of the taxonomy 
> Media Encoder transformation. Taxonomy draft says “CLUE’s ‘Capture 
> Encoding’ provides specific encoding configuration for this purpose 
> [Media Encoder]”. I think it should be “CLUE’s ‘Individual Encoding’”, 
> not “Capture Encoding”. (suggest change this in taxonomy draft, also 
> in Packet Stream section)
>
[CNG] I agree individual coding would be more appropriate.

> CLUE Capture Encoding: same as taxonomy Encoded Stream. (suggest add 
> this to taxonomy draft)
>
[CNG] I think its similar but not the same. A CLUE capture encoding does 
result in an encoded stream but due to the link with a CLUE media 
capture ID there is also semantic information that is associated with 
the encoded stream.
>
> CLUE Stream: same as taxonomy Packet Stream. (taxonomy draft already 
> equates CLUE Stream with Packet Stream).
>

> CLUE Endpoint: includes a taxonomy End Point and a Participant.
>
[CNG] Yes
>
> CLUE MCU: includes multiple taxonomy End Points and a Participant for 
> each conference.
>
[CNG] Yes
>
> I can post suggestions to avtext to change the taxonomy draft 
> regarding these CLUE terms, but I’d like to hear feedback from this 
> group first.
>
> Regards,
> Mark
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Bo Burman <[email-masked]>
Date: Tue, 17 Jun 2014 12:08:47 +0000

Hi,

I am currently updating the RTP Taxonomy, so this review of CLUE terms is really welcome. I plan to submit a new version of the Taxonomy draft within the next few days and would like to include the result of this discussion.

Please find a few comments and questions inline below.

Cheers,
Bo

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: den 17 juni 2014 03:33
> To: [email-masked]
> Subject: Re: [clue] more taxonomy
> 
> Hello Mark,
> 
> > I'm looking at more terms and concepts that are used both in CLUE and
> > CLUE Media Capture: I'm not sure about this. I was going to say it is
> > is the same as a taxonomy Media Source. I don't see how it makes any
> [CNG] I think CLUE captures can be either a RTP taxonomy media capture or media source. The distinguishing factor
> appears to be that the media capture is raw stream and a media source is a processed stream. CLUE media captures could
> be either. This could be updated in the taxonomy draft.
[BoB] OK

> > Media Encoder transformation. Taxonomy draft says "CLUE's 'Capture
> > Encoding' provides specific encoding configuration for this purpose
> > [Media Encoder]". I think it should be "CLUE's 'Individual Encoding'",
> > not "Capture Encoding". (suggest change this in taxonomy draft, also
[BoB] OK

> [CNG] I think its similar but not the same. A CLUE capture encoding does result in an encoded stream but due to the link
> with a CLUE media capture ID there is also semantic information that is associated with the encoded stream.
[BoB] OK. I get a feeling that the CLUE capture encoding term is (at least in the CLUE framework) mostly used to describe an Encoded Stream, but is sometimes also used to denote the Media Encoder transformation and the result is then (correctly) described as a Stream. Am I correct? If so, do you want to change that "duality" of capture encoding, or do you rather prefer that I just reflect this fact in the Taxonomy?

> > CLUE Endpoint: includes a taxonomy End Point and a Participant.
[BoB] Could not a CLUE Endpoint consist of multiple End Points (multiple entities running separate RTP stacks), or is that an unnecessary generalization?

> > CLUE MCU: includes multiple taxonomy End Points and a Participant for
[BoB] You mean the MCU itself is a Participant in each conference and as such also includes multiple End Points per conference, right?

> > regarding these CLUE terms, but I'd like to hear feedback from this
> > group first.
> >
> > Regards,
> > Mark
> >
> >
> >

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 20 Jun 2014 11:17:06 -0700

Hi,

There are a few suggestions below for the taxonomy document to clarify references to CLUE terms, which Bo has agreed with, or had questions which I tried to answer below.

So I think it is not necessary to add anything in the CLUE framework that refers back to the taxonomy document, does that sound right?  Or do we want to add all this information about the relationship between CLUE and taxonomy into the framework doc also?

Some more inline below.

Mark

> From: clue [mailto:[email-masked]] On Behalf Of Bo Burman
> Sent: Tuesday, June 17, 2014 8:09 AM
> To: Christian Groves; [email-masked]
> I am currently updating the RTP Taxonomy, so this review of CLUE terms is
> really welcome. I plan to submit a new version of the Taxonomy draft within
> the next few days and would like to include the result of this discussion.
> 
> > > I'm looking at more terms and concepts that are used both in CLUE
> > > and in draft-ietf-avtext-rtp-grouping-taxonomy-01.
> > >
> > > CLUE Media Capture: I'm not sure about this. I was going to say it
> > > is the same as taxonomy Media Capture, with either physical stimulus
> > > or synthetic stimulus. But the taxonomy draft says a CLUE Media
> > > Capture is the same as a taxonomy Media Source. I don't see how it
> > > makes any difference to CLUE either way. What do you think?
> > >
> > or media source. The distinguishing factor appears to be that the
> > media capture is raw stream and a media source is a processed stream.
> CLUE media captures could be either. This could be updated in the taxonomy
> draft.
> [BoB] OK
> 
> > >
> > > [Media Encoder]". I think it should be "CLUE's 'Individual
> > > Encoding'", not "Capture Encoding". (suggest change this in taxonomy
> > > draft, also in Packet Stream section)
> > >
> > [CNG] I think its similar but not the same. A CLUE capture encoding
> > does result in an encoded stream but due to the link with a CLUE media
> capture ID there is also semantic information that is associated with the
> encoded stream.
> [BoB] OK. I get a feeling that the CLUE capture encoding term is (at least in
> the CLUE framework) mostly used to describe an Encoded Stream, but is
> sometimes also used to denote the Media Encoder transformation and the
> result is then (correctly) described as a Stream. Am I correct? If so, do you
> want to change that "duality" of capture encoding, or do you rather prefer
> that I just reflect this fact in the Taxonomy?
[Duckworth, Mark] I still think a Capture Encoding is the same as an Encoded Stream.  Yes, there is a link to the semantic information, but still it is an Encoded Stream.  I don't think Capture Encoding refers to the media encoder transformation.  It is the output of the transformation, which is the Encoded Stream.

> [BoB] Could not a CLUE Endpoint consist of multiple End Points (multiple
> entities running separate RTP stacks), or is that an unnecessary
> generalization?
[Duckworth, Mark] I think a CLUE Endpoint is exactly one End Point.  CLUE definition says "exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent)".  I think this is all consistent.

> > > CLUE MCU: includes multiple taxonomy End Points and a Participant
> > > for each conference.
> > >
> > [CNG] Yes
> [BoB] You mean the MCU itself is a Participant in each conference and as
> such also includes multiple End Points per conference, right?
[Duckworth, Mark] I think so.  A CLUE MCU shouldn't be any different than any other MCU.  The taxonomy document doesn't mention MCU or multipoint.  I suggest neither CLUE framework nor taxonomy doc needs to add anything about relation between MCU and End Point and Participant.

---

From: Christian Groves <[email-masked]>
Date: Mon, 23 Jun 2014 14:57:09 +1000

Hello

Please find my comments below.

> So I think it is not necessary to add anything in the CLUE framework that refers back to the taxonomy document, does that sound right?  Or do we want to add all this information about the relations…
[CNG] I don't think its strictly necessary to add anything. If the 
taxonomy document became an RFC before the CLUE framework maybe we could 
add something, but I don't think there's a need to create a dependency.

> ..snip..
[CNG] I agree that a CLUE capture encoding results in an encoded stream 
from a transport perspective. From a CLUE perspective its an encoded 
stream with a particular semantic. I think its important to capture the 
"CLUE" part of the definition of "CLUE capture encoding".
> [Duckworth, Mark] I think a CLUE Endpoint is exactly one End Point.  CLUE definition says "exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent)".  I think this is…
[CNG] I agree.
> [Duckworth, Mark] I think so.  A CLUE MCU shouldn't be any different than any other MCU.  The taxonomy document doesn't mention MCU or multipoint.  I suggest neither CLUE framework nor taxonomy doc…
[CNG] I agree.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jun 2014 10:50:00 -0400

> So I think it is not necessary to add anything in the CLUE framework that refers back to the taxonomy document, does that sound right?  Or do we want to add all this information about the relations…

I think it is important that the relationships be clearly defined 
*somewhere*. In the long term I expect that other documents will 
reference the taxonomy and use its terminology or else explicitly relate 
their terminology to it.

But the taxonomy has to start somewhere. If it is willing to reference 
the clue documents then we don't need to make the back reference.

> Some more inline below.

Me too.

> [Duckworth, Mark] I still think a Capture Encoding is the same as an Encoded Stream.  Yes, there is a link to the semantic information, but still it is an Encoded Stream.  I don't think Capture Enc…

I think it is more-or-less correct.

There is a question of whether we want to dig into the distinction 
between the names of things and the things that are named.

Specifically, the Configure message describes Capture Encodings that are 
being requested. But those don't exist as Encoded Streams until the 
Configure is received by the provider and acted upon.

But I don't think we need to worry about that level of distinction.

> [Duckworth, Mark] I think a CLUE Endpoint is exactly one End Point.  CLUE definition says "exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent)".  I think this is…

I think Bo has it right. While a CLUE Endpoint has a single signaling 
address (making it a Taxonomy Participant), it can be decomposed into 
components that have separate RTP addresses. (E.g., one per screen.)

>> such also includes multiple End Points per conference, right?

I'm don't understand the question. What do you mean by "each conference"?

Are you thinking of the MCU as a server that supports multiple 
concurrent clue conferences?

Or is an MCU an abstraction for the resources supporting a single 
conference?

Of course real devices will support multiple concurrent conferences. But 
should we consider those to be one MCU or several?

This is like the distinction between a UA and a server that can host 
multiple UAs.

Right now the clue framework seems to define the MCU as supporting a 
single conference. And I think that is probably the right thing to do. 
We don't intend to define any normative behavior that applies across 
multiple conferences in the same server, so we don't need a term to talk 
about that. So having the term MCU talk about the support of a single 
conference is more useful to us.

> [Duckworth, Mark] I think so.  A CLUE MCU shouldn't be any different than any other MCU.  The taxonomy document doesn't mention MCU or multipoint.  I suggest neither CLUE framework nor taxonomy doc…

 From a CLUE perspective an MCU is a type of endpoint. It is unclear to 
me whether more needs to be said about it than that. Is there anything 
that an MCU does that a non-MCU endpoint would *never* do? Or is it just 
that there are behaviors that an MCU is more likely to do than other 
endpoints?

It may be useful for the Taxonomy to discuss MCUs in general.
And ideally that would indeed be consistent with the CLUE notion of MCU.

	Thanks,
	Paul

---

From: Bo Burman <[email-masked]>
Date: Tue, 24 Jun 2014 10:40:55 +0000

Responses inline

> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: den 23 juni 2014 16:50
> To: [email-masked]

...snip...
> >> [BoB] OK. I get a feeling that the CLUE capture encoding term is (at
> >> least in the CLUE framework) mostly used to describe an Encoded
> >> Stream, but is sometimes also used to denote the Media Encoder
> >> transformation and the result is then (correctly) described as a
> >> Stream. Am I correct? If so, do you want to change that "duality" of
> >> capture encoding, or do you rather prefer that I just reflect this fact in the Taxonomy?
> > [Duckworth, Mark] I still think a Capture Encoding is the same as an Encoded Stream.  Yes, there is a link to the semantic
> information, but still it is an Encoded Stream.  I don't think Capture Encoding refers to the media encoder transformation.
> It is the output of the transformation, which is the Encoded Stream.
> 
> There is a question of whether we want to dig into the distinction between the names of things and the things that are
> named.
> 
> Specifically, the Configure message describes Capture Encodings that are being requested. But those don't exist as
> Encoded Streams until the Configure is received by the provider and acted upon.
> 
[BoB] OK. Agree that we don't need that level of distinction in Taxonomy. I'll list Capture Encoding as an Encoded Stream related to CLUE specific semantic information.

...snip... (will respond to End Point discussion in a separate mail)

> >> [BoB] You mean the MCU itself is a Participant in each conference and
> >> as such also includes multiple End Points per conference, right?
> 
> Are you thinking of the MCU as a server that supports multiple concurrent clue conferences?
[BoB] I was.

> 
> Or is an MCU an abstraction for the resources supporting a single conference?
[BoB] No.

> 
> Of course real devices will support multiple concurrent conferences. But should we consider those to be one MCU or
> several?
> 
> This is like the distinction between a UA and a server that can host multiple UAs.
> 
> Right now the clue framework seems to define the MCU as supporting a single conference. And I think that is probably
> the right thing to do.
> We don't intend to define any normative behavior that applies across multiple conferences in the same server, so we
> don't need a term to talk about that. So having the term MCU talk about the support of a single conference is more
> useful to us.
[BoB] OK. Agree.

> 
> > [Duckworth, Mark] I think so.  A CLUE MCU shouldn't be any different than any other MCU.  The taxonomy document
> doesn't mention MCU or multipoint.  I suggest neither CLUE framework nor taxonomy doc needs to add anything about
> relation between MCU and End Point and Participant.
> 
>  From a CLUE perspective an MCU is a type of endpoint. It is unclear to me whether more needs to be said about it than
> that. Is there anything that an MCU does that a non-MCU endpoint would *never* do? Or is it just that there are
> behaviors that an MCU is more likely to do than other endpoints?
> 
[BoB] OK. I'll include a short provisional text on MCU in the Taxonomy, but I will not make it specific to CLUE in any way.