Subject: [clue] Fwd: Meeting invitation: CLUE WG Design Team

From: Mary Barnes <[email-masked]>
Date: Mon, 9 Apr 2012 15:51:17 -0500

Hi folks,

Below please find the webex details for tomorrow's Design team call.  These
details should apply to the calls through July 17th, 2012, so please either
save this email or add this to your calendar by clicking the link below.

We'll send the topic for tomorrow shortly.

Thanks,
Mary.

---------- Forwarded message ----------
From: Clue Working Group <[email-masked]>
Date: Mon, Apr 9, 2012 at 3:37 PM
Subject: Meeting invitation: CLUE WG Design Team
To: [email-masked]

Hello ,

Clue Working Group invites you to attend this online meeting.

Topic: CLUE WG Design Team
Date: Every Tuesday, from Tuesday, April 10, 2012 to Tuesday, July 17, 2012
Time: 9:00 am, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 641 658 366
Meeting Password: 1234

-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to
https://ietf.webex.com/ietf/j.php?ED=152424912&UID=1244287392&PW=NZTliYmY5NDA4&RT=MiM3
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?ED=152424912&UID=1244287392&PW=NZTliYmY5NDA4&ORT=MiM3

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
Call-in toll number (US/Canada): +1-408-600-3600

Access code:641 658 366

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You can contact me at:
[email-masked]

To add this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://ietf.webex.com/ietf/j.php?ED=152424912&UID=1244287392&ICS=MI&LD=1&RD=2&ST=1&SHA2=FcyzMIRvFFq-rm7Ros88rwGpeYrVAOhJutQlkgKgFrc=&RT=MiM3

The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in the
meeting, please check whether you have the players installed on your
computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com

CCP:+14086003600x641658366#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio
and any documents and other materials exchanged or viewed during the
session to be recorded. By joining this session, you automatically consent
to such recordings. If you do not consent to the recording, discuss your
concerns with the meeting host prior to the start of the recording or do
not join the session. Please note that any such recordings may be subject
to discovery in the event of litigation.

---

From: John Leslie <[email-masked]>
Date: Tue, 17 Apr 2012 11:05:28 -0400

John Leslie, Paul Kyzivat, Brian Baldino, Jonathan, Mark Duckworth, Marshall Eubanks, Rob Hansen, Spencer

1004 
Paul: Don't know whether there's convergence on the Interim date
Spencer: acting as if the RTCweb date is nailed
Marshall: Mary was trying to get them to move...

Paul: don't know if Mary intended to meet today
Spencer: I'll try to find her on jabber

Paul: Christer is starting work on a data model
Spencer: Mary will join shortly

1012 Mary joined
"Tax Day" discussion

Paul: timing questions maybe...

Paul put up email from Marshall re timing
Mary: better not to try to shoehorn to another group's definitions
Marshall: a few hundred milliseconds is typically acceptable (seconds are not); RTT likely to be hundreds of milliseconds.
Rob: agree with the numbers... implications of switching
Marshall: what about showing name of the speaker
Rob: not at frame level -- only things vital to rendering belong at frame level -- things you can't fix later
Marshall: are we going to have to set up our own "clue" channel?
Rob: we concluded we won't do "everything" in SDP
Marshall: separate logical from transport
Rob: several RTTs, 
Jonathan: small number of seconds
Marshall: will CLUE have border controllers
Jonathan: satellite uplink?

Mary: Christen working on data model -- how fast things change, requirements... do we agree on three time-scales of interest?
(general agreement)
Paul: Marshall proposed mechanisms for three time-frames, whether data fits is a separable question, maybe doesn't fit in any bucket -- we may send several-second stuff in a CLUE 200-msec channel because of its size
Marshall: is there a possibility we might have gigabyte-size messages? (do we need a background priority
Jonathan?: roster for huge conferences could be large

1032
Paul: question whether we have enough data to drive recipient decision
Jonathan: perhaps I haven't thought about it as much as Paul
Paul: between abstract and concrete -- think it would help to sort out use cases in more details, equipment used
Marshall: three images on two screens, e.g.
Paul: answers I'm hearing, pick an entry which fits your configuration; we could e.g. require a one-screen redering be sent
Mark: are you talking about issue #8?
Paul: talking about two different problem... in one scene, there may not be any rows that match your need... if you need to throw something out, e.g. two screens available for three-screen offering
Mark: what do you think might be able to solve that?
Rob: three-screen system could offer switched version on two screens, or receiver could do the switching
Paul: wasn't clear during mixed/switched discussion that recipient has enough inforation... if you send both a composed and a switched, do I have
the information to choose... if I knew one was previous speaker...
Marshall: to me, I wouldn't flip current-speaker/previous-speaker on-screen
Paul: provider might offer both a switched-current-speaker and a switched-previous-speaker, I could choose
Rob: algorithm could offer current-loudest-speaker and current-N... sender sends the one you ask for... you can subscribe to part of a capture set
Paul: might have one entry with three capture, another with two... I could take all the capture in that entry
Rob: my understanding is you can ask for individual captures in an entry
Mark: receiver may be incapable of receiving all, you can ask for just one or two
Paul: in effect, captures in an entry will map to mlines? ... when I select particular captures from particular capture scenes ... I have to pick which I want to receive ... the advertisement specified what they are, such as left-middle-right
Rob: in the switched case, you could ask for "up-to-two"...
Paul: I think this is what's too fuzzy... do I know what I'm choosing
Rob: algorithm might be anything, e.g. three loudest
Marshall: sounds like a middleware issue, does the middleware have the info? does it relay it back to the sender?
Paul: could make it easier by pushing back on provider -- it should provide sets for any number of screens up to its maximum
Rob: examples that do one-screen and three-screen, but not two
Marshall: we could assumed they were in order of importance
Paul: from cameras raw, you have good coordinates, if switched, not... coordinates not meaningful for presentation... if coordinate system different, needs to be in different scene
Marshal: do we have a mechanism to say "must show this screen"
Jonathan: what is the or-else? drop the call?
Paul: could define a priority
Marshall: should we allow priorities to be set
Jonathan: but who sets the priorities?... I've tried to avoid defining
things where it's not clear how they're set
Marshall: example IETF WG meeting... maybe we need to write down use cases

1059
Mary: we have use-cases, but they're often insufficiently detailed, we don't have any how-to-use these use-cases documents
Marshall: perhaps start with use-cases that are "special"... bottom-up
Paul: think we can start with use-cases we have, and elaborate on them... equipment at each end, e.g.
Mary: somebody need to take an action-item to elaborate one use-case
Paul: I will do that

1102 adjourn

--
John Leslie <[email-masked]>