Subject: [clue] New framework I-D posted

From: Stephan Wenger <[email-masked]>
Date: Thu, 21 Feb 2013 23:27:29 +0000

Hi,
Version 9 of the framework I-D is out.  Many editorial changes and cleanups, limited new substance.  Included are a number of editor's notes with questions to the WG, mostly in the context of the ongoing signaling discussion (so we will probably not be able to address those questions immediately).
See (some of) you in hellhole Orlando.
Stephan

Subject: New Version Notification for draft-ietf-clue-framework-09.txt
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Thu, 21 Feb 2013 15:24:13 -0800

A new version of I-D, draft-ietf-clue-framework-09.txt
has been successfully submitted by Stephan Wenger and posted to the
IETF repository.

Filename:	 draft-ietf-clue-framework
Revision:	 09
Title:		 Framework for Telepresence Multi-Streams
Creation date:	 2013-02-21
Group:		 clue
Number of pages: 50
URL:             
http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-09.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-clue-framework
Htmlized:        http://tools.ietf.org/html/draft-ietf-clue-framework-09
Diff:            
http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-09

Abstract:
   This document offers a framework for a protocol that enables
   devices in a telepresence conference to interoperate by specifying
   the relationships between multiple media streams.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Feb 2013 06:20:48 +0800

Stephan,

Thanks for doing this. I think the document is much improved.
I have a few comments:

Definition of Encoding:

It is given as: "Encoding or Individual Encoding: a set of parameters 
representing a way to encode a Media Capture to become a Capture Encoding."

This is fine as far as it goes, but I don't think it captures the full 
semantics. According to this definition, I would expect that I could 
apply an encoding to a number of captures concurrently, producing a 
number of capture encodings. But section 7.1 says an encoding can only 
handle one capture at any given time. That part of the meaning is 
lacking in the definition. A suggestion:

"Encoding or Individual Encoding: a resource that may be used to encode 
a Media Capture as a Capture Encoding, and a set of parameters 
describing how the encoding will be performed."

In section 4:

    Edt. note: The editors are not sure whether the mentioned
    overloading of established RTP channels using only CLUE messages is
    possible, or desired by the WG.  If it were, certainly there is
    need for specification work.  One possible issue: a Provider which
    thinks that it can switch, say, a audio codec algorithm by CLUE
    only, talks to a  Consumer which thinks that it has to faithfully
    answer the Providers Advertisement through a Configure, but does
    not dare setting up its internal resource until such time it has
    received its authoritative O/A exchange.  Working group input is
    solicited.

It was my understanding that we were not advocating doing anything that 
is contrary to the negotiated SDP. (E.g. using a codec not mentioned in 
the SDP.) But there are still plenty of changes that could potentially 
be made without violating the current SDP. E.g. selecting a new 
capture-encoding that uses an m-line that is already compatible.

Section 6.2:

    In more
    complex systems, the use of additional Capture Scenes is also
    sensible.  For example, a three camera room may advertise two
    Capture Scenes involving live video, one including only the center
    camera (and associated audio), the other involving all three
    cameras (and associated audio).

I'd like to hear more explanation of why this if a reasonable thing to 
advertise. It doesn't seem reasonable to me, since all of these things 
are spatially related.

I have another question related to this section, but unrelated to the 
recent changes:

We have structured things so that audio and video scene entries are 
independent - for each scene you need to choose one of each. But isn't 
it possible that some combinations don't make sense? For instance if you 
chose site switching for video then you should perhaps also choose site 
switching for audio.

This would be clearer if scene entries contained captures of all media 
types. But I realize doing that may greatly increase the number of entries.

Section 6.2.2:

While it makes sense to outsource the detailed attributes here, IMO it 
is NOT ok to defer the definition of switching and composition to the 
data model. There should be a discussion of the concepts of that 
*somewhere*, and I can't think of a better place than the FW. For 
instance, the difference between site switching and segment switching, 
and the difference between switching and composition. (And of course 
that these have some differences between audio and video.)

Section 8:

IMO a small bit of this content could be deferred to the data model:

    Each Capture has an Encoding Group attribute.  The value of this
    attribute is the encodeGroupID for the Encoding Group with which it
    is associated.

Section 9:

    Edt. Note: The editors solicit input from the working group as to
    whether or not a Consumer must respond to every Advertisement with
    a new Configure message.

I propose that we decide this as part of defining the signaling, and 
then reflect the outcome here. (Or maybe just don't mention it here.)

OPEN ISSUE

We have structured things so that audio and video scene entries are 
independent - for each scene you need to choose one of each. But isn't 
it possible that some combinations don't make sense? For instance if you 
chose site switching for video then you should perhaps also choose site 
switching for audio.

This would be clearer if scene entries contained captures of all media 
types. But I realize doing that may greatly increase the number of entries.

	Thanks,
	Paul (as individual)

---

From: Christian Groves <[email-masked]>
Date: Thu, 28 Feb 2013 17:19:44 +1100

Hello all,

The latest version looks pretty good, I've reviewed it and have the 
following comments/questions.

Section 1, Pg.3 bullet (3) - It talks about "chosen by operator" perhaps 
as the next part talks about "consumer" it should say "chosen by provider".

Section 1, Pg.3 bullet (3) - Simultaneous capture sets are actually 
above the capture scene description. Not part of the capture scene 
description. This is due to the ability to indicate simultaneity 
requirements between all capture scenes in an advertisement. i.e. from 
v8 "These simultaneous set constraints apply across
    all the captures scenes in the advertisement."

Section 1, Pg.3 bullet (5) - Why do we have the "sales pitch" :-) for 
RTP multiplexing in motivation for CLUE? Isn't the key point that CLUE 
allows for the possible reduction of RTP flows?

Section 3 Advertisement: Is this missing description of the aspect of 
"capture scenes" and "captures" etc? The definition seems to on the 
stream where the importance of the CLUE advertisement is really to 
signal the interrelation between the different media captures/streams.

General: The framework pretty much ties Capture/Capture encoding to RTP 
only. Thinking out aloud could this be a restriction when considering 
captures relating to presentations?

General: Text capture: According to our definitions CLUE support Text 
captures. i.e. Media indicates the possibility of timed text, A media 
capture indicates that its the source of "media". We also talk about 
streams being RTP. Sect 6.3 also talks about captures of a particular 
type (audio, video, text). If we are supporting it then we may be a 
"Text Capture" (TC). This may be an issue for Orlando.

Section 4 Figure: In the signalling document it shows ACKs to the 
Advertisement and Configure messages. Do we want to show those in the 
framework or at least say for brevity acknowledgements aren't shown?

Section 5: With respect to the coordinate system and the origin. We say 
that the location of the origin is up to the provider's choosing. Would 
it be beneficial to suggest a location for it?

Section 6.1.1: It says that capture attributes provide "static" 
information? What is meant by static here? Is it for the life of the 
CLUE association. Static until the next Advertisement is sent? I suggest 
deleting it.

Section 6.1.1: I'd prefer not to outsource the definitions of these 
attributes to the data model. Part of the framework is to understand 
what this information is used for.

Section 6.1.1: Area of capture: for consistency we should probably use 
"bottom camera left", "top camera right", etc...

Section 6.2 Pg.19 Para.4: I'm not sure this reflects the discussions 
we've had on the list. It basically says says that the consumer can do 
what ever it likes. I thought there was some agreement that the consumer 
SHOULD chose a CSE and that these were alternate representation of the 
entire scene (at least according to the scene definition). Section 6.3 
mentions choosing only one CSE.

Section 6.2.1: Like above I think its worth having some description in 
the framework document. You should need to look into two documents to 
get the gist of what CLUE is doing.

Section 6.2.1 Area of scene: If this is specified I take it that it must 
be greater than or equal to the outer extents of the individual 
captures? If it was smaller what would it mean?

Section 6.2.2: Should the scene switch policy be at a Capture scene 
level? For example if we allow the consumer to cherry pick captures from 
different CSEs what happens? Are the capture only related to a CSE 
switched together or all captures related to the scene switched?

Section 7.1 Pg26.: We can probably remove "Clue-protocol internal 
information" from the list of video codec specific parameters.

Section 8. : It says that every capture is associated with an encoding 
group. Does that mean a provider is REQUIRED to provide maximum the 
various maximum information? I couldn't find any text which suggests 
sending of encoding parameters is optional.

Section 9. pg. 32 para.4: Not sure that each Advertise is acknowledged 
by a Configure. Acknowledge of the receipt of a message and 
configuration could be separate.

Section 10.: It is envisaged that CLUE could support non-RTP streams in 
the future?

Section 11.1.1 Fig. : Nit - the figure has D but the text talks about 'd'.

Regards, Christian

On 22/02/2013 10:27 AM, Stephan Wenger wrote:
> Hi,
> Version 9 of the framework I-D is out.  Many editorial changes and 
> cleanups, limited new substance.  Included are a number of editor's 
> notes with questions to the WG, mostly in the context of the ongoing 
> signaling discussion (so we will probably not be able to address those 
> questions immediately).
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue