Re: [clue] Agenda: CLUE WG Design Team

[Marshall Eubanks <[e-mail]>]

(Fairly) raw notes from today's call.

Regards
Marshall

On Tue, Apr 10, 2012 at 10:04 AM, Mary Barnes
<[e-mail]> wrote:
>
>
> Agenda:
> 1) Review list of open action items.
> 2) Discuss current open items and decide if we need an issue opened in the
> tracker or whether these aren't real issues:
> - mixed/composed
> - simultaneous sets
> 3) Way forward for signaling solution(s) and data model.
>
> Thanks,
> Mary.
>
>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: *Clue Working Group* <[e-mail]
>>> <mailto:[e-mail]>>
>>> Date: Mon, Apr 9, 2012 at 3:37 PM
>>> Subject: Meeting invitation: CLUE WG Design Team
>>> To: [e-mail] <mailto:[e-mail]>
>>>
>>>
>>>

>
>
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>

CLUE Design Team

Tue Apr 10 10:03:01 EDT 2012

Marshall Eubanks
Allyn Romanow
Brian Baldino
John Leslie
Jonathan Lennox
Mark Duckworth
Mary Barnes (Chair)
Rob Hansen
Espen Berger
Paul Kyzivat

Mary : I thought we would go over some of issues and the things being
discussed on the list.

(shows active tickets)

The first issue is the source selection case.

Jonathan : I thought we discussed that in Andover. I thought the
conclusions was it was a good use case but not anything we want in
version 1.

Mary : OK, great, I will go ahead and close that out.

I don't see Roni. He has the RTCWEB use case. I don't think he is on right now.

? : Is it a Holiday in Israel?

Mary : Maybe. I know Saturday was Passover. I will consult with Roni.

Issue # 4 - there is not much we can do about that now. It has to be
on hold for a while.

Issue 5 is describing in room attributes.

<there is was a response from Espen that I couldn't hear>

Mary : There was 9, the axis of capture.

<Paul Kyzivat. joined at this point>

This is Stephan's. I will get back to him on this.

Ticket 8 is distinguishing between multiple capture scenes.

Espen : The classic case is where you have a lecture capture, with one
camera at the speaker and one at the white board and one on the
audience.

Mark : That sounds like it would fit better using the purpose attribute.

Espen : 4796 ?

Mark : That sounds right.

Jonathan : I thought this issue was about capture scenes.

Mark : My basic question is, does anybody think that adding a human
readable name as an attribute would help. I am thinking that the
purpose attribute would be more easily useful.

Espen : It is not only automatic, I want it to be in the message so I
can understand - it is in addition. So, maybe it has two source.

Rob : In the past we have talked about conferences with multiple
capture scenes for different users - there, they would have the same
purpose, so the purpose isn't enough.

Paul : There have been cases where purpose is not enough. Having a
human decipherable name is a fail-back.

Mark : If it is a human readable string, would the source be a human ?

Paul : That is not for us to decide.

Marshall : Don't these sorts of things tend to turn into profiles over
time? If you make this available, it will become something for the
automated machinery to use.

Paul : We talked about cases where there were 2 kinds of captures

Mary : XCON does have a display text for available media.

Paul : If the mapping to XCON is well understood, then maybe it is OK.

Do we agree that each capture is a participant ?

Mary : CLUE is built on SIP. XCON is built on SIPPING - if it is
already there, we
shouldn't be replicating it.

The conference is built on blocks of attributes, each representing a
participant. This is something to look at.

I think it is reasonable to say we want something human readable -
something capturable.

Espen : I think it depends on the use cases.

Mary : So it falls back to our use cases. Roni had comments on this too.

I think we can agree to some sort of human readable text.

So, that is the last open issue.

The most recent ML discussion was around the mixed proposed.

Paul : It seems we have been going in circles. The first thing to sort
out is, what is the point of these attributes? Why are they there ?

My take is that we are trying to provide enough information to map
captures onto equipment at the receiver side, and these attributes
will help with that.

Jonathan : A lot of the complication is, we have a mixer.

The consumer may be a middle box, which may not pass it along.

Paul : If we can figure out the purpose, we can then figure out if we
have the right information.

We got into this confusing discussion about what it means to be
composed. Maybe some captures from one camera can be composed.

Espen : You want to cover use cases where the end user relies on a
middle box, or the receiver receives something untouched from the
sender.

The first one I call composed, and the second original.

So, a middle box needs to be able to express that it can send either
original or composed scenes.

Paul : This sounds like an attribute  on the capture set.

Espen : I think we need more concrete examples.

Paul : I wonder if we need to identify some more challenging use cases.

If all you have is that some are composed or some or not

Espen : In this particular case, you don't mix. All are composed, or none.

Paul : You can compose the not composed ones, but leave the composed
ones alone.

Espen : The base is, I think, a single composed attribute.

Paul : Can we write down some of these cases ?

Mark : It seems to me that these scenarios are more general than
multiple streams for telepresence. The same issues apply to
non-telepresence single stream units.

Are we sure that CLUE is the best place for this ?

Mary : I am not sure that we are.

Espen : I can write down some of these use cases.

I remember from IETF in Paris that there are people discussing related
issues [in a number of different WG].

Paul : At the META level it's the same, but at the audio and video it
is quite different.

To me the fundamental problem in the scope of CLUE is, if you are the
end point, and you have received an advertisement, with some scenes
and captures, do you have sufficient information to select and map
what you have onto what you have got. If the geometry does not match,
then what ? Is there enough information to decide what to do?

Marshall : And that is very telepresence specific. Even in typical
videoconferencing you may not really care about what goes where in
what size, as long as it fits.

Espen : I think in other cases you may well care as well.

Paul : So, what is the next step ?

Mary : We can open a ticket and Espen said he would send something to the list.

[Mary asked about the status of the Wenger transport draft - I said
that I wasn't aware of any immediate plans to rev it.]

Mary : We have had a discussion about the data model and different
people had different views. To me, it is about what is to be carried.
I know that all of this is

If someone would like to volunteer and talk to Christer [Holmberg] on
the data model and volunteer, that would be good.

Allyn : Didn't Andy come out with a data model.

Espen : That document would be a good starting point for what you
should supply that isn't in SDP.

Mary : That was not an IETF draft.

Paul : It was his presentation.

Mary : Right.

I will let Christer know that that is available. I will forward this
document to him.

I think we will hold off other issues to next week.

Call ended
Tue Apr 10 10:56:21 EDT 2012