Re: [clue] Agenda: CLUE WG Design Team

["Roni Even" <[e-mail]>]

Hi,
Sorry for not attending the meeting, we had our Holiday and I missed the
call.
As for the notes.

I have no problem with source selection not in version 1. My view is that
this is a nice to have feature but currently in multipoint I think most
solutions use stimulus based approach using a web interface or some menus
based on DTMF or some H.224 based signaling since they cannot count on
source selection support as part of the endpoint application.

On multiple capture scenes, my comment was about the point to point use
case. Is there a case where there may be more than one capture scene in an
advertisement. If there is such a case we will need to be able to describe
it at the capture scene level using some attribute that will carry the
semantics of the scene. If not, we should say in the text that there will be
just one. This is for completeness of the model.

On the transport work, I think that the transport drat provide the options
but we are not sure yet which one is the way to go forward. We may need to
discuss it in the interim meeting with the discussion on the data model.

Roni Even



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Marshall Eubanks
> Sent: Tuesday, April 10, 2012 6:30 PM
> To: Mary Barnes
> Cc: CLUE
> Subject: Re: [clue] Agenda: CLUE WG Design Team
> 
> (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
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue