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

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 4 Mar 2013 15:06:52 -0800

Hi Paul,

My comments inline.

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Sunday, February 24, 2013 5:21 PM
> To: [email-masked]
> Subject: Re: [clue] New framework I-D posted
> 
> 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."

[Duckworth, Mark] either way is okay with me.

> 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.

[Duckworth, Mark] I agree, Paul.  If this is what the group wants, the framework document should clearly say CLUE devices follow all SDP O/A rules.  Should we also refer to some specific RFCs?
 
> 
> 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.

[Duckworth, Mark] I agree.  I'm not sure what happened here.  Sounds like it might be confusing Capture Scenes with Capture Scene Entries.  I'll check with Stephan and Andy about the intent of this.

> 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.)

[Duckworth, Mark] I'm not sure exactly where to draw the line about which things go in which document.  Site switch and segment switch description actually came from the use case document, we just repeated it in the framework.  Are you suggesting we just keep in the framework some of the text about switching and composition that was already in the framework?  And not move so much of it to another document?

> 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.

[Duckworth, Mark] I agree

> 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.)

[Duckworth, Mark] I agree

> 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)
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 4 Mar 2013 17:11:37 -0800

Hi Christian,

Thanks for the feedback.
Comments inline.

Mark

> Christian Groves
> Sent: Thursday, February 28, 2013 1:20 AM
> To: CLUE
> 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".

[Duckworth, Mark] I'm not sure what you mean.  Are you talking about page 4, paragraph numbered (2)?  What do you suggest changing?

> 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."

[Duckworth, Mark] I think it should just say "Simultaneous capture sets are discussed in section 6.3", removing the incorrect part about being part of a Capture Scene.

> 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.

[Duckworth, Mark] "describing specific aspects of the content of the media" is referring to the Captures and Capture Scene information.  That's how I read it anyway.

> 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?

[Duckworth, Mark] I believe the scope of all this is limited to media streams over RTP.

> 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.

[Duckworth, Mark] I agree we should include text, and possibly other types of media but I don't have any specific examples.  Maybe this issue is a more for the data model, to make sure it doesn't exclude other media types that go over RTP?

> 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?

[Duckworth, Mark] I think after we get a somewhat stable signaling document we should make sure all the documents are consistent.

> 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.

[Duckworth, Mark] I think anything can change from one advertisement to the next, so I agree we should delete the word "static".

> 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.

[Duckworth, Mark] Seems like we need more discussion on where to draw the line between what goes in framework and what goes in the data model.
 
> 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.

[Duckworth, Mark] Yes, the Consumer can choose whatever it wants, subject to constraints of the advertisement.  Section 6.3 says "... the Consumer should choose one Capture Scene Entry for each media type, but may choose individual Captures based on the Simultaneous Transmission Sets."  I think the framework is saying what we agreed on the list.  But maybe not clearly enough?  Do you have a specific suggestion?

> 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?

[Duckworth, Mark] Yes, I think it should be greater than or equal to the outer extents of the individual captures.

> 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?

[Duckworth, Mark] Good question.  Related to Paul's question about picking different CSEs for different media types, which could have different values for the scene-switch-policy.

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

[Duckworth, Mark] I agree that doesn't add any value here.  Specifics would be in the data model, I think.

> 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.

[Duckworth, Mark] Yes, my understanding is it is required.

> 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.

[Duckworth, Mark] The intent is to say something like the Consumer must send a new Configure in response to receiving an Advertisement.   Does that make more sense?  I agree this could be separate from acknowledging receipt of the Advertisement.

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

[Duckworth, Mark] I believe the scope of all this is limited to media streams over RTP.  I don't recall hearing anybody talk about expanding to 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).
> > See (some of) you in hellhole Orlando.
> > Stephan
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 00:50:20 +0800

On 3/5/13 7:06 AM, Duckworth, Mark wrote:

Trimming

> [Duckworth, Mark] I agree, Paul.  If this is what the group wants, the framework document should clearly say CLUE devices follow all SDP O/A rules.  Should we also refer to some specific RFCs?

Since we are talking about SDP, we can at least reference 4566 and 
draft-ietf-mmusic-rfc4566bis. I don't think we need to mention any SDP 
extensions here unless we have reason to talk about them explicitly.

> [Duckworth, Mark] I'm not sure exactly where to draw the line about which things go in which document.  Site switch and segment switch description actually came from the use case document, we just…

I don't think we define them very well at all.
So we probably need some new text. Maybe somebody has a better idea, but 
ISTM that these are *concepts* that need to be explained. People may 
have a general notion from the names, but we should be more precise than 
that. Especially in the case of switching, this later becomes 
fundamental to the notions of dynamic and static mapping.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Mar 2013 01:11:18 +0800

> [Duckworth, Mark] I agree we should include text, and possibly other types of media but I don't have any specific examples.  Maybe this issue is a more for the data model, to make sure it doesn't e…

I think there may be some subtle issues that show up when considering 
real-time-text captures. Specifically, there may not be dedicated 
devices for rendering this text. Should it be rendered on top of video 
displays? Should the spatial coordinates indicate where it ought to be 
rendered, or what? Also, how does switching work with these?

ISTM that we should defer this, or have some people work on it 
independently in parallel with other work, to avoid getting distracted.

But at least we should set up the data model to allow additional types 
of captures, beyond audio and video.

> [Duckworth, Mark] I think after we get a somewhat stable signaling document we should make sure all the documents are consistent.

I don't think we need to mention ACK in the FW at all.
It is signaling-related detail.

> [Duckworth, Mark] Yes, I think it should be greater than or equal to the outer extents of the individual captures.

Some time ago I mentioned that the Area of Scene needs to be three 
dimensional (Volume of Scene?). Otherwise it doesn't reasonable 
accommodate arrangements of captures that not planar.

> [Duckworth, Mark] Good question.  Related to Paul's question about picking different CSEs for different media types, which could have different values for the scene-switch-policy.

This relates to my question about providing a thorough description of 
switching in the FW. That should include how switched video captures 
relate to switched audio captures (and switched real-time-text captures).

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Thu, 07 Mar 2013 14:21:18 +1100

Hello,

Please see my responses below marked [CNG].

Regards, Christian

On 6/03/2013 3:50 AM, Paul Kyzivat wrote:
>> [Duckworth, Mark] I agree, Paul.  If this is what the group wants, 
>> the framework document should clearly say CLUE devices follow all SDP 
>> O/A rules.  Should we also refer to some specific RFCs?
>

[CNG] I'd be a little hesitant to mandate that a devices supporting CLUE 
must support SDP O/A. That may not make much sense for non-SIP devices. 
Yes I know this working group is only working on SIP CLUE but the 
charter says we should identify interoperability obstacles in existing 
open standards
>> [Duckworth, Mark] I'm not sure exactly where to draw the line about 
>> which things go in which document.  Site switch and segment switch 
>> description actually came from the use case document, we just 
>> repeated it in the framework.  Are you suggesting we just keep in the 
>> framework some of the text about switching and composition that was 
>> already in the framework? And not move so much of it to another 
>> document?
>
> So we probably need some new text. Maybe somebody has a better idea, 
> but ISTM that these are *concepts* that need to be explained. People 
> may have a general notion from the names, but we should be more 
> precise than that. Especially in the case of switching, this later 
> becomes fundamental to the notions of dynamic and static mapping.
[CNG] I agree.

---

From: Christian Groves <[email-masked]>
Date: Thu, 07 Mar 2013 15:09:40 +1100

Hello Mark,

Please see my responses below.

Regards, Christian

..snip

> [Duckworth, Mark] I'm not sure what you mean.  Are you talking about page 4, paragraph numbered (2)?  What do you suggest changing?
[CNG] Sorry it should be bullet (2). The comment is that the draft uses 
the terms "Provider" and "Consumer". Whereas this point talks about 
"operator". An operator could be at either a provider endpoint or 
consumer endpoint. I think that its probably easier to say:

  "The Capture
    Scene concept allows for the description of multiple setups for
    those multiple capture devices that could represent sensible
    operation points of the physical capture devices in a room, chosen
    by the <<provider>>."
> [Duckworth, Mark] I think it should just say "Simultaneous capture sets are discussed in section 6.3", removing the incorrect part about being part of a Capture Scene.
[CNG] OK
> [Duckworth, Mark] "describing specific aspects of the content of the media" is referring to the Captures and Capture Scene information.  That's how I read it anyway.
[CNG] When you say "content of media" I think "a=content:". I think what 
CLUE is doing is more than what is in the stream it describes the 
context of a stream.
> [Duckworth, Mark] I believe the scope of all this is limited to media streams over RTP.
[CNG] Yes the charter says that we are concentrating on RTP. However I 
wonder what in the current framework limits us to RTP? We don't have any 
RTP specific information in the CLUE protocol as it currently stands.
> [Duckworth, Mark] I agree we should include text, and possibly other types of media but I don't have any specific examples.  Maybe this issue is a more for the data model, to make sure it doesn't e…
[CNG] I think the framework drives the data model. Thus if we allow 
different media types we should have some text to describe the other 
possibilities. For example: This framework uses audio captures and video 
captures to illustrate the CLUE protocol procedures. Capture types for 
other RTP based media such as text captures are possible.

> [Duckworth, Mark] I think after we get a somewhat stable signaling document we should make sure all the documents are consistent.
[CNG] Agreed
> [Duckworth, Mark] I think anything can change from one advertisement to the next, so I agree we should delete the word "static".
[CNG] OK
> ..snip
[CNG] I think the aspect of STSs is missing from the part of 6.2. the 
consumer. The consumer pick and choose Media Captures regardless of how 
the provider arranges them in CSE, within the scope of an STS.
> [Duckworth, Mark] Yes, I think it should be greater than or equal to the outer extents of the individual captures.
[CNG] I agree. Maybe we should add this to the framework?
> [Duckworth, Mark] I agree that doesn't add any value here.  Specifics would be in the data model, I think.
[CNG] OK
> [Duckworth, Mark] Yes, my understanding is it is required.
[CNG] So an encoding is mandatory and the indicated parameters are also 
mandatory for a particular media type?
How about maxH264Mbps? What if I'm not using H264?

Also the maxGroup??? parameters even if this equals or exceeds the 
individual values it has to be sent?

> [Duckworth, Mark] The intent is to say something like the Consumer must send a new Configure in response to receiving an Advertisement.   Does that make more sense?  I agree this could be separate…
[CNG] For the initial Advertisement the Consumer must send a Configure. 
For subsequent Advertisements the consumer only has to send a Configure 
if something in the new Advertisement has changed the consumer state and 
it needs to send a Configure. The consumer should always ack/nack the 
reception of an Advertisement.

..snip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Mar 2013 22:50:53 +0800

> charter says we should identify interoperability obstacles in existing

We are working on SIP CLUE. When doing that it is necessary to conform 
to SDP O/A. Normally I would think that there is no need to emphasize 
that because it is implicit in supporting SIP.

But in this case there really may be a reason to talk about it: we do 
have another channel in which to negotiate things. Along the way there 
have been some suggestions that we might negotiate some media streams in 
the clue channel that weren't mentioned at all in SDP. I want to make it 
clear that we are *not* proposing to do that.

If/when an H.323 version of clue is derived from this it can make the 
appropriate corresponding statements for H.323.

Or do you think we need to be more restrictive in our use of SDP in 
order to facilitate interop with H.323?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Mar 2013 22:58:32 +0800

On 3/7/13 12:09 PM, Christian Groves wrote:

>> [Duckworth, Mark] The intent is to say something like the Consumer
>> must send a new Configure in response to receiving an Advertisement.
>> Does that make more sense?  I agree this could be separate from
>> acknowledging receipt of the Advertisement.

IMO this starts to get into protocol details. So I would like to avoid 
talking about this in the FW if possible. If it seems necessary to talk 
about it, then we will need to be careful to synchronize with the signaling.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 08 Mar 2013 13:57:07 +1100

Hello Paul,

I'm not asking to restrict the usage of SDP. What i'd like to avoid is 
in the framework to mandate the use of SDP (+specific RFCs) for an 
endpoint to use the CLUE signalling protocol. For the CLUE protocol 
signalling there's currently no reason to say that SDP should be 
supported. SDP offer/answer comes into play to setup up the SCTP 
connection and to establish the actual media streams. So I see CLUE as 
just CLUE, not SIP CLUE, sort of like BFCP which we don't call SIP BFCP.

Regards, Christian

On 8/03/2013 1:50 AM, Paul Kyzivat wrote:
> have been some suggestions that we might negotiate some media streams 
> in the clue channel that weren't mentioned at all in SDP. I want to 
> make it clear that we are *not* proposing to do that.
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 08 Mar 2013 14:03:55 +1100

Hello Paul,

I don't see much text in the framework on the actual method. I was more 
thinking a more high level description
i.e. "Advertisement and Configures are acknowledged by the remote 
endpoint. A consumer always sends a Configure in response to an initial 
Advertisement. For subsequent Advertisements it is optional to send a 
Configure."

If we have the framework and protocol document they should be aligned. 
If we leave the text to say something like "the Consumer must send a new 
Configure in response to receiving an Advertisement." and the protocol 
says something different them for sure when it comes to interop testing 
somebody is going to say "but the framework said..." where their 
protocol doesn't work...

Regards, Christian

On 8/03/2013 1:58 AM, Paul Kyzivat wrote:
> talking about this in the FW if possible. If it seems necessary to 
> talk about it, then we will need to be careful to synchronize with the 
> signaling.
>
>     Thanks,
>     Paul
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 8 Mar 2013 11:48:25 +0000

Hi,

The simple way is to say that SDP is used to create the media streams, and the CLUE is used to exchange the telepresence information. The only "connection" is that we need to map the m- lines (or, perhaps individual SSRCs) in the SDP with the corresponding captures in the CLUE signaling.

The problem is that there is information that one could claim belongs in both SDP and CLUE. If we decide to put such information in SDP, then CLUE does become dependent on SDP (or, SOME other protocol) for transporting that information. But, that is not the same as "putting SDP in CLUE".

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 8. maaliskuuta 2013 4:57
To: [email-masked]
Subject: Re: [clue] New framework I-D posted

Hello Paul,

I'm not asking to restrict the usage of SDP. What i'd like to avoid is in the framework to mandate the use of SDP (+specific RFCs) for an endpoint to use the CLUE signalling protocol. For the CLUE protocol signalling there's currently no reason to say that SDP should be supported. SDP offer/answer comes into play to setup up the SCTP connection and to establish the actual media streams. So I see CLUE as just CLUE, not SIP CLUE, sort of like BFCP which we don't call SIP BFCP.

Regards, Christian

On 8/03/2013 1:50 AM, Paul Kyzivat wrote:
>>>> the framework document should clearly say CLUE devices follow all 
>>>> SDP O/A rules.  Should we also refer to some specific RFCs?
>>>
>>> draft-ietf-mmusic-rfc4566bis. I don't think we need to mention any 
>>> SDP extensions here unless we have reason to talk about them explicitly.
>>
>> [CNG] I'd be a little hesitant to mandate that a devices supporting 
>> CLUE must support SDP O/A. That may not make much sense for non-SIP devices.
>> charter says we should identify interoperability obstacles in 
>> existing open standards
>