Subject: [clue] Fwd: New framework I-D posted

From: Mary Barnes <[email-masked]>
Date: Wed, 2 Jan 2013 09:57:56 -0600

Hi folks,

It would be really good for folks to take the time to review the
updated document this week and post any comments/questions to the
list.  We can then discuss this on next Monday's call (Jan. 7th @ 10am
Central).

Just a point of curiosity to the authors, what was the motivation for
switching back to Winword?     If it's a lack of an XML editor, there
are some decent quality freeware ones out there, including some WYSIWG
add ons.

Thanks,
Mary.

---------- Forwarded message ----------
From: Stephan Wenger <[email-masked]>
Date: Mon, Dec 24, 2012 at 6:49 PM
Subject: [clue] New framework I-D posted
To: "[email-masked]" <[email-masked]>

Hi all,
I just posted an update to the framework draft.  Most of the changes
are in the introduction, covering the basic outline of the CLUE
operation as discussed during the design team call.  It is our
intention to streamline this section later and to move out some of the
information into sections more appropriate than the intro.
In the spirit of avoiding "misapplying yesterday's technology today",
we are using Winword between us editors now, so there is no XML
version.   This resulted also in formatting changes which is going to
make the diff a bit less useful than usual.  It will be better from
the next version onwards.  If you want the word file, please contact
me.
Stephan

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 4 Jan 2013 18:20:20 +0100

Dear all,

I just read the new framework document. I'll try to report in this mail a couple of considerations, with the aim of fostering further discussion on the list.

From a high-level perspective, my first comment is that I am afraid we are still stuck on the very basic issue of defining the inner workings of clue, in terms of protocol, protocol messages, call flows and the like.
I think the situation is much better when it comes to the data model, which is now in a pretty good shape (it can definitely be fine-tuned, but I see no major outstanding issue). 
With respect to the inner workings, I thought we had somehow agreed on the fact that CLUE is, in a nutshell, a sort of enriched O/A based on advanced SDP-based negotiations (involving all the work-in-progress stuff on RTP mapping/multiplexing) and relying on a dedicated CLUE channel which is used to transfer all information that does not fit into SDP (e.g., spatial information). Just to summarize my current understanding, and per Stephan's e-mail of December 1st 2012, the phases involved should be something like:

> With reference to the call flow 02 doc (https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include_text=1) that exchange could look as follows:
> Invite from Alice, just like A.1 in call-flow-02
> 200 OK from Bob, A.2
> CLUE Advertisement Alice A.3, covering geometry stuff, encoding groups, etc.
> CLUE Advertisement Bob A.4; note that 3 and 4 would in practice overlap in time
> CLUE Response from Alice A.5, with the difference that these reposes DO NOT have the side effect of initiating any media channel related activity; they are pure signaling
> CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in time.
> Re-invite from Alice and Bob, respectively, with media channels as CLUE-"negotiated"
> 200 OK from Bob, Alice.  As the endpoints have already established their operation points through CLUE, this step will not fail except if an entity not involved in the CLUE negotiation intervenes—i.e. a middle box doesn't like that call.
The above steps are quite nicely reported in the Introduction of the new draft (outline starting at the end of page 4). By reading that part of the document (as well as the cited e-mail thread), I once again realize we need to clearly define what we mean by 'Advertisement'. Is this a message flowing across the CLUE channel and containing just the stuff that cannot be mapped onto SDP? Or is it a higher-level message containing general information about a clue telepresence room and which can be transported partially inside SDP and partially across the clue channel (for the parts that do not match any SDP structure)? The difference is in my view important, because in the latter case every time we state we 'send and advertisement' (like, e.g., in points 3. and 4. above), we mean we are sending "one SDP offer on the vanilla SIP channel + one clue message on the clue meta-channel". I don't know what is other people's opinion on this, but I think it is fundamental we converge on an agreed-upon definition. If we went for the latter approach, we might state in the framework that the advertisement is a 'logical' message having a well defined structure and which can be 'partially' mapped onto SDP.

Somehow related to the above point, I got completely lost when I arrived at section 9.4 (message flow, pages 26 and 27). The introduction of the "Consumer capabilities" message and related "Capture Advertisement" and "Configure Encodings" sounds totally new to me. I read the note about the authors' thinking and I believe this idea goes into the direction sketched by someone at the last meeting (if I recall correctly, it was stated stated that it might be useful to somehow pre-filter the advertisement sent by a provider) and which did not get that much consensus. Just correct me if I'm wrong. In any case, this introduces a brand new perspective inside clue signaling, which should be better introduced and illustrated in the introductory part.

Anyhow, coming back to the document's structure, I keep on believing we should avoid putting into the framework document too many details about the data model. I'd prefer the framework to contain high-level descriptions of the overall architecture, protocol, messages, data model and call flows. The reader of this document should come out with a clear idea of what CLUE means and does, while being redirected to the companion documents for the details. Practically speaking, I would suggest to move most of the material currently contained in sections 5 through 8 to the data model draft (which should also contain the XML schema). The framework might elaborate more on the big picture and try and clarify the overall functionality of clue. What do the others think of this?

Finally, a few minor nits:

- I would avoid explicitly mentioning H264-related stuff in the data model (like with macroblocks -- maxH264Mbps)
- why is the ID of the EncodingGroup called 'encodeGroupID' and not 'encodingGroupID' ?
- section 10, first bullet: replace 'can done' with 'can be done'
- section 10, third bullet: "Adding  new codecs" --> remove 'a'

That's all for now.

Cheers,

Simon

Il giorno 02/gen/2013, alle ore 16:57, Mary Barnes ha scritto:

> <Allegato di posta elettronica.eml>_______________________________________________
> clue mailing list
> [email-masked]

                     					       _\\|//_
                           				      ( 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: [email-masked]

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 06 Jan 2013 17:08:56 -0500

[as an individual]

There is no Changes Since Last Version entry for this version!
As best I can tell, there are substantial changes/additions to the 
Intro, and some small but significant changes in Definitions, and all 
other changes are superficial.

Here are some comments, both on the changes, and unchanged parts.

Intro:

    One initial motivation for this memo ...

seems oddly phrased. We don't normally refer to drafts as memos. How 
about replacing "memo" with "document"?

    This CLUE exchange is followed by an SDP offer answer exchange
    that not only establishes those aspects of the media that have not
    been "negotiated" over CLUE, ...

This makes it sound like the framework is constraining the ordering of 
clue and o/a messages. Lets decide if that is so, and not imply things 
that aren't intended.

    During the lifetime of a call, further exchanges can occur over
    the CLUE channel.  ...

Later, the discussion of legacy devices seems incomplete. It explains 
how a clue device realizes it is connected to a legacy device, but not 
what the expectations are in this case. I think we need to say more 
about the level of support expected for legacy devices.

Definitions:

We have Capture Encoding, Capture Scene, Capture Scene Entry, and Media 
Capture, but we have no definition for Capture itself! I suggest we 
define Capture as synonymous with Media Capture.

    Capture Scene: a structure representing the scene that is captured
    by a collection of capture devices.  A capture scene includes
    attributes and one or more capture scene entries, with each entry
    including one or more media captures.

The def of scene is circular. How about:

    Capture Scene: a structure representing a spatial region containing
    one or more Capture Devices, each capturing media representing a
    portion of the region. The spatial region represented by a scene
    may or may not correspond to a real region in physical space, such
    as a room.  A capture scene includes attributes and one
    or more capture scene entries, with each entry including one or more
    media captures.

"Individual Encoding: A variable with a set of attributes that describes 
the maximum values of a single audio or video capture encoding.": in 
what respect is this a *variable*? I think "parameter" is more 
appropriate. Also the definition is circular. And shouldn't it just be 
called "Encoding" rather than "Individual Encoding"? (That is the way it 
is used.)

"Media Capture: a source of Media, such as from one or more Capture 
Devices. A Media Capture (MC) may be the source of one or more capture 
encodings": This seems to be using "source" two ways, as seems confusing 
to me. I think there are some key points that ought to be made here:
- it is of a single media type (audio/video)
- it is associated with exactly one scene
- it has one set of location information.
   (what do we say about this for switched/composed captures?)
- it has one or more possible encodings
- it MAY be available in multiple encodings simultaneously

    Media Consumer: an Endpoint or middle box that receives media
    streams

    Media Provider: an Endpoint or middle box that sends Media streams

Wouldn't it be better to use Capture Encoding than stream in both of the 
above?

Section 4: Overview:

    A provider organizes its media captures that represent the same
    scene into capture scenes.  A consumer chooses which media
    captures it wants to receive according to the capture scenes sent
    by the provider.

Awkward language. How about:

    A provider organizes its media captures into one or more capture
    scenes, each representing a spatial region, such as a room.  A
    consumer chooses which media captures it wants to receive from
    each scene.

Section 5:

Probably more detail than we want. (E.g. the stuff about scale units.) 
But I'm ok to leave it here until we are sure that it has been 
incorporated into another doc.

Section 6:

    To distinguish between multiple instances, video and audio
    captures are numbered such as: VC1, VC2 and AC1, AC2.  VC1 and VC2
    refer to two different video captures and AC1 and AC2 refer to two
    different audio captures.

AFAIK the intent is really that these are arbitrary labels, not numbers, 
and that the usage shown is just a convention. It would be best if this 
would say that. E.g.

    To identify and distinguish between multiple instances, video and
    audio captures are labeled. For instance: VC1, VC2 and AC1, AC2
    where  VC1 and VC2 refer to two different video captures and AC1
    and AC2 refer to two different audio captures.

Section 6.2:

    A capture scene is a structure representing the scene that is
    captured by a collection of capture devices.  ...

Same issue as I mentioned above regarding the definition of Capture Scene.

Section 7.1:

    7.1. Individual Encodings

    An individual encoding represents a way to encode a media capture
    to become a capture encoding, ...

As mentioned earlier, I think the term should be Encoding, not 
Individual Encoding. ("Individual" can still be used as an adjective, 
but it isn't part of the term itself.) So I suggest this should be:

    7.1. Encoding

    An individual Encoding represents a way to encode a Media Capture
    to form a Capture Encoding, ...

Tables 2 & 4: These formatting of these tables is screwed up - the 
horizontal lines have been wrapped to two lines.

In order to insulate for H264 specifics, would it be reasonable to 
replace macroblocks per second with pixels per second? Aside from 
rounding, this just seems to be a linear change in units. Or perhaps max 
pixels per frame, in conjunction with max frame rate.

Section 9:

    The consumer need not send a new configure message to the provider
    when it receives a new capture advertisement from the provider
    unless the contents of the new capture advertisement cause the
    consumer's current configure message to become invalid.

This begs the question of how you would determine if your current 
configure would be come invalid.

I guess the simple answer is: take the old configure message, and change 
it only to update the advertisement id to refer to the new 
advertisement. Then verify if it is a correct config relative to the new 
advertisement.

If so, that means that if the new advertisement uses old IDs to 
reference changed attributes, then the consumer has implicitly requested 
those changes.

IMO we want to *recommend* that there be a new config in response to 
each new advertisement, even while saying what to expect until  that is 
done.

Section 9.4:

I thought we had abandoned the Consumer Capability message. If so, it 
should be removed from the framework. Given how long we have had it 
without any firm identified need, I think removing it now is safe. It 
can always be returned later if need be.

Section 10:

The macroblocks-per-second attributes, with a fixed size of macroblock, 
is not very extensible. As noted above, I think we might be able to 
abstract it.

Section 11.4:

Why have a subsection for media consumer behavior, but none for media 
provider behavoir?

I suggest moving 11.1-11.3 down under a new "media provider behavior" 
section.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 11 Jan 2013 13:33:40 -0800

Hi Paul,

I agree we should have a "changes since last version" section in every new version.  Sorry about that.

Are there places where we use the term "capture" by itself?  It should always be "media capture", so I agree with you that "capture" is the same as "media capture".

I think your definition of Capture Scene is an improvement, I like it.

Good point about definition of Individual Encoding.  But the term "individual encoding" is used in section 7.1, not just "encoding".  I'll look more closely to see if I agree with you about changing it to just "encoding".  How about this:

(Individual) Encoding: a representation of a way to encode a media capture to become a capture encoding.

And further elaboration of (Individual) Encoding should be in the body of the document, or data model, and not included in the definition.

I think your key points about Media Capture are important, but should not be part of a simple definition.  Stephan, Andy, and myself were planning on trying to shorten some of the definitions (so they are simple definitions, not complete explanations) and leave the explanations and elaboration to the body of the documents.

Media Consumer and Media Provider - I think "stream" is actually better here than "capture encoding", given that stream is defined as a capture encoding sent via RTP.

I agree with your other suggestions about sections 4 through 11.

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Sunday, January 06, 2013 5:09 PM
> To: [email-masked]
> Subject: Re: [clue] Fwd: New framework I-D posted: draft-ietf-clue-
> framework-08
> 
> [as an individual]
> 
> As best I can tell, there are substantial changes/additions to the Intro, and
> some small but significant changes in Definitions, and all other changes are
> superficial.
> 
> This makes it sound like the framework is constraining the ordering of clue
> and o/a messages. Lets decide if that is so, and not imply things that aren't
> intended.
> 
> Later, the discussion of legacy devices seems incomplete. It explains how a
> clue device realizes it is connected to a legacy device, but not what the
> expectations are in this case. I think we need to say more about the level of
> support expected for legacy devices.
> 
> Definitions:
> 
> Capture, but we have no definition for Capture itself! I suggest we define
> Capture as synonymous with Media Capture.
> 
> "Individual Encoding: A variable with a set of attributes that describes the
> maximum values of a single audio or video capture encoding.": in what
> respect is this a *variable*? I think "parameter" is more appropriate. Also the
> definition is circular. And shouldn't it just be called "Encoding" rather than
> "Individual Encoding"? (That is the way it is used.)
> 
> encodings": This seems to be using "source" two ways, as seems confusing to
> me. I think there are some key points that ought to be made here:
> Probably more detail than we want. (E.g. the stuff about scale units.) But I'm
> ok to leave it here until we are sure that it has been incorporated into
> another doc.
> 
> Section 6:
> 
> AFAIK the intent is really that these are arbitrary labels, not numbers, and
> that the usage shown is just a convention. It would be best if this would say
> that. E.g.
> 
> As mentioned earlier, I think the term should be Encoding, not Individual
> Encoding. ("Individual" can still be used as an adjective, but it isn't part of the
> term itself.) So I suggest this should be:
> 
>     7.1. Encoding
> 
> Tables 2 & 4: These formatting of these tables is screwed up - the horizontal
> lines have been wrapped to two lines.
> 
> In order to insulate for H264 specifics, would it be reasonable to replace
> macroblocks per second with pixels per second? Aside from rounding, this
> just seems to be a linear change in units. Or perhaps max pixels per frame, in
> conjunction with max frame rate.
> 
> Section 9:
> 
> This begs the question of how you would determine if your current configure
> would be come invalid.
> 
> I guess the simple answer is: take the old configure message, and change it
> only to update the advertisement id to refer to the new advertisement.
> Then verify if it is a correct config relative to the new advertisement.
> 
> If so, that means that if the new advertisement uses old IDs to reference
> changed attributes, then the consumer has implicitly requested those
> changes.
> 
> without any firm identified need, I think removing it now is safe. It can always
> be returned later if need be.
> 
> Section 10:
> 
> The macroblocks-per-second attributes, with a fixed size of macroblock, is
> not very extensible. As noted above, I think we might be able to abstract it.
> 
> Section 11.4:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jan 2013 17:38:49 -0500

> Are there places where we use the term "capture" by itself?  It should always be "media capture", so I agree with you that "capture" is the same as "media capture".

I'm not sure if it is used "by itself" or not. But it is used in Capture 
Scene, Capture Encoding, etc. (rather than Media Capture Scene, Media 
Capture Encoding). And whether it is used alone in this document or not, 
we certainly use it alone in discussions. It could just be noted as 
shorthand for Media Capture.

> (Individual) Encoding: a representation of a way to encode a media capture to become a capture encoding.

That could work. It just seems weird to me. It seems more natural to use 
"individual" in its normal role as an adjective - "individual Encoding" 
rather than "Individual Encoding". Or if you think "Encoding" isn't 
specific enough, how about "Media Encoding" as a parallel to "Media 
Capture"? (With "Encoding" being a shorthand for "Media Capture".)

> I think your key points about Media Capture are important, but should not be part of a simple definition.  Stephan, Andy, and myself were planning on trying to shorten some of the definitions (so t…

Yes, that seems like the right thing to do.

> Media Consumer and Media Provider - I think "stream" is actually better here than "capture encoding", given that stream is defined as a capture encoding sent via RTP.

OK.

	Thanks,
	Paul