Subject: [clue] Topic: CLUE WG DT meeting tomorrow (May 22 @ 9am central)

From: Mary Barnes <[email-masked]>
Date: Mon, 21 May 2012 18:04:06 -0500

Hi all,

Since it's been a few weeks since we have had a call, it would be good for
us to have one this week and discuss some of the recent issues that have
been discussed on the mailing list.  While I don't necessarily like a
meeting because people aren't responding on the mailing list, I think some
of these topics would benefit from non-email discussion.

1) Criteria for CLUE signaling:
http://www.ietf.org/mail-archive/web/clue/current/msg01433.html  [Note:
Christer cannot make this meeting, but we can still review and decide
whether we agree this is a good starting point]

2) Ticket #8: add description text to a capture scene
http://www.ietf.org/mail-archive/web/clue/current/msg01442.html

3) Ticket #8: capture scene coordinates and content attribute
http://www.ietf.org/mail-archive/web/clue/current/msg01446.html

Regards,
Mary.

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 21 May 2012 19:15:02 -0400

I am afraid that I am booked tomorrow and will have to send regrets.

Marshall

On Mon, May 21, 2012 at 7:04 PM, Mary Barnes <[email-masked]> wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 22 May 2012 01:51:23 +0000

Sorry, can't attend.
Stephan

From: Mary Barnes <[email-masked]<mailto:[email-masked]>>
Date: Monday, 21 May, 2012 16:04
To: CLUE <[email-masked]<mailto:[email-masked]>>
Subject: [clue] Topic: CLUE WG DT meeting tomorrow (May 22 @ 9am central)

Hi all,

Since it's been a few weeks since we have had a call, it would be good for us to have one this week and discuss some of the recent issues that have been discussed on the mailing list.  While I don't necessarily like a meeting because people aren't responding on the mailing list, I think some of these topics would benefit from non-email discussion.

1) Criteria for CLUE signaling:
http://www.ietf.org/mail-archive/web/clue/current/msg01433.html  [Note: Christer cannot make this meeting, but we can still review and decide whether we agree this is a good starting point]

Regards,
Mary.

---

From: John Leslie <[email-masked]>
Date: Tue, 22 May 2012 11:06:04 -0400

> http://www.ietf.org/mail-archive/web/clue/current/msg01446.html

Present: John Leslie, Paul Kyzivat, Jonathan Lennox, Rob Hansen, Brian Baldino, Espen Berger, Mary Barnes. After meeting start Mark, Allyn, Roni.

1003 CTO
Mary: sharing, browser, meeting tomorrow, Mark still not here... Mark joined, Allyn joining User9, Roni..., Christer not able to join
Mary: first, signaling intermediaries need access?
Roni: inaudible... it's also MCUs
Jonathan: not the same thing, SBCs could be ordinary...
Roni: if specific channel, would need to go through MCU anyway
Jonathan: inherent in CLUE channel... everything that head-rails do
Mary: agree with Jonathan, in nature of CLUE
Roni: chicken-and-egg, anything CLUE-aware needs access, routing needs to go through intermediary
Jonathan: question, whether this information is relevant to routing decision
Roni: selecting... if you have multiple streams, controller in middle would like to route only some of them based on policy
Mary: wouldn't policy in general cover that
Roni: not just policy, may be some other things, we should decide whether part of signaling or separate channel
Mary: reword to be more explicity
Paul: may be of interest to all intermediaries... stuff pertinent to routing is different -- needed at time routing is being established
Jonathan: use-case, trying to figure out which MCU...
Paul: knowing bandwidth that will be required for this call
Mary: hearing two separate things here
Roni: suggestion I sent was expanding on that
Mary: same channel is different question from who needs access
Roni: makes sense only if you can see all this at the same time
Mary: sub-bullets... three points that Roni made
Roni: last one doesn't apply
Jonathan: imagine session establishment...
Mary: signaling vs. media... #4... separate out the two?
Mary: #2 expected size... byte estimate
Mary: #3 expected frequency, 3-tiers
Mary: #4 whether sent during...
Roni: establishing signaling vs. media
Jonathan: what counts as "media"... other information...
Mary: idea, be able to identify bits of information
Roni: information, CLUE-call, then what else? establishing media comes last
Paul: information for session-establishment, needed for CLUE-channel establishment... maximum bandwidth needed, during SIP-session establishment
Mary: #5 whether information transport is delay-sensitive
Paul: how sensitive-to-delay, what delay is tolerable
Mary: we're defining characteristics needed
Roni: various messages, delays for messages
Mary: possible multiple ways
Paul: some tunneled, etc
Roni: not talking about anything except CLUE messages
Mary: no, we're talking about what needs to be signaled
Roni: delay-acceptable is for CLUE messages
Mary: only in an abstract sense...
Roni: whatever
Mary: if we had data-model, we'd evaluate against criteria...
Mary: #6 whether response is needed
Roni: reliability?
Jonathan: is there a handshake on action to take
Paul: two things hiding here, if unreliable channel, may need to verify delivery
Mary: that's later in #7
Mary: #8 needed by non-CLUE entity in order to participate
Jonathan: what does non-CLUE entity mean? legacy SIP? one-camera-one-screen?
Roni: should ask Christer what he meant
Mary: #9 whether CLUE info is using one transport... needs to be carried with other elements?
Roni: more-specific, media-capture, you can delete this one
Mary: will send to list
1040
Mary: ticket #8 add description text to capture scene
Mark: I thought we agreed to add human-readable, media-consumer can use that to let a human user make choice... related to ticket 8, though not a complete solution
Allyn: something an individual system wants to add... what it wants to display to users, not a CLUE thing what they present to users, most people won't touch it, doesn't solve any of our problems, I see no reason to do this
Mary: if optional, would it be a problem
Allyn: my designs don't include unnecessary things
Jonathan: how would you solve this problem
Allyn: take what information you have, present it to user... some classification, not free text
Paul: suppose you receive advertisement with two scenes, but you've only got one screen, how do you decide which one to display, what information would you use to decide
Allyn: typically you have one for presentation... why isn't this enough?
Paul: what if those aren't the labels
Allyn: if you had "main" and "presentation", what more would you need? specifically, what is inadequate
Paul: suppose I have three, two have main, third has presentation, I have only one screen and two "main"s
Allyn: you want different kinds of "main"; that's fine, we'll add categories, what categories are missing, you don't have to answer now
Roni: I agree with Allyn... it's not the text that distinguishes... if there's more than presentation and main, need to define characteristics
Paul: I want to somehow distinguish... there's no requirement that the purpose must be different
Roni: until we agree "what is a capture scene" we can't decide how to differentiate them... capture scene has its own coordinate space, presentation doesn't belong in main
Rob: each person has separate capture scene, same purpose
Roni: is each having no relation to the others, or does MCU relate them?
Rob: in first case, capture scenes have the same purpose
Paul: can still funnel through MCU, but it doesn't combine them
Roni: don't think that's the model we want to address.
John: might not multiple MCUs combine scenes differently
Roni: typically an MCU will build a virtual room with no scaling
John: sounds like a bad idea to lose the coordinate information
Paul: you could create a synthetic coordiate space
Roni: no you don't... the purpose is to adjust, if you do that, the mathematics will be wrong
Allyn: not assigning a virtual coordinate space... not useful unless you're going to lay out one next to the other
Mark: don't think we have a conclusion on description string
Allyn: I don't like it, is anyone adamently in favor?
Roni: the problem is that this isn't a ticket-8 issue -- human-readable text can't solve the ticket-8 issue, I don't object to human-reabable text, but we need a different proposal for ticket8
Mary: suggest we do consensus-call on-list
Roni: must be kept separate from ticket-8
Mary: OK... we're out of time

Adjourned 1101
--
John Leslie <[email-masked]>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 22 May 2012 11:59:17 -0500

I have uploaded the minutes from the meeting:
http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team

Thanks to John Leslie for again taking minutes.

Note, I also added the dialin number for the calls to the wiki.

Mary.