Subject: [clue] Roles - Conference System Control Role

From: Christian Groves <[email-masked]>
Date: Mon, 09 Sep 2013 20:35:31 +1000

Hello

To follow up on my draft <draft-groves-clue-role-clarifications-00 
<http://datatracker.ietf.org/doc/draft-groves-clue-role-clarifications/>> on 
roles I'm proposing some text for the framework for 3 new attributes to 
stimulate some discussion. I'll keep each of the attributes in a 
separate thread as there may be different issues for each attribute.

My proposed text to add to the framework for conference system control 
role is:

In 6.1.1 Media Capture Attributes:

Conference System Control Role:

This attribute indicates that the person depicted in the media capture 
has certain conference control responsibilities. It does not provide any 
authorisation in a conference management system for these conference 
control roles.  The information is provided as a means for the consumer 
to select media captures and for display/playout purposes.

The conference system control roles attribute has the following values:

    Presenter       Indicates a person that can share content/media with
                    others.  May also be known as speaker.

    Controller      Indicates the person responsible for controlling
                    admission to the conference.  Sets up the meeting,
                    adds and shares contents, control who presents and
                    talks.  Also known as "host".

    Participant     Indicates a participant in the conference who does
                    not have any special control.  Receives media and
                    content from presenter.

    Unlike meeting role a person can only have one conference system
    control role at a time.  However as multiple people can be captured
    in a media capture the conference system control role may have
    multiple values.

Comments?

Regards, Christian

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 9 Sep 2013 15:37:49 -0400

Hi, Christian --

What I'm trying to understand (for all three of your proposed role attributes) is the use cases in which they'd be used.  Are they intended for automatic (machine) consumption, or human?

As I mentioned in the face-to-face meeting, why should these be part of CLUE, as opposed to XCON or something similar as part of the meeting roster information?

What should endpoints do in circumstances where the role types are entirely unlike the classic corporate-meeting model, e.g. our doctor's-surgery use case?

Are there any existing conferencing or telepresence systems that carry this sort of information, and how is it used in the system?

On Sep 9, 2013, at 6:35 AM, Christian Groves <[email-masked]> wrote:

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

--
Jonathan Lennox
[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Sep 2013 15:58:11 -0400

Christian,

Regarding Presenter and Participant, I'm confused about how you see them 
being used in different types of conferences:

- in our traditional TP conference, with several "rooms" that
   operate as peers, are all of them Presenters? Speakers? Both?

- in a conference like the above, but where we also have floor
   control over a presentation capture, does the Presenter role
   move around with the floor assignment? If so, who changes it?
   Must the endpoint getting the floor do it? Or the focus?

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 10 Sep 2013 11:45:01 +1000

Hello Jonathan,

Please see my comments below.

Regards, Christian

> What I'm trying to understand (for all three of your proposed role attributes) is the use cases in which they'd be used.  Are they intended for automatic (machine) consumption, or human?
[CNG] The parameters are intended for both automatic and/or human 
consumption. That is the idea behind having a a defined set of 
enumerations/keywords and data types. It allows automatic parsing of the 
information because systems because different systems will use the 
enumeration rather than using slightly different terms to describe 
essentially the same "role" or piece of information.

The "role information" (i.e. information associated with the three 
attributes) could be provided in several ways. i.e. when the conference 
is booked, automatic means such as an app on the participants smart 
phone that shares information or manually configured at the time of the 
meeting. The advertiser can then share this information with the 
consumer. The consumer could automatically parse some information based 
on a local policy, display information to prompt a user selection and 
potential use the information when it renders a capture (i.e. display text).

> As I mentioned in the face-to-face meeting, why should these be part of CLUE, as opposed to XCON or something similar as part of the meeting roster information?
[CNG] It needs to be in CLUE because a consumer needs to be able to 
choose which captures to receive based on this information. It may wish 
to chose one capture over another based on this information. If this 
information is received after the captures are chosen it will result in 
a renegotiation with a possible change of media etc. which isn't 
desirable for the user experience.
> What should endpoints do in circumstances where the role types are entirely unlike the classic corporate-meeting model, e.g. our doctor's-surgery use case?
[CNG] This depends on the attribute and the information they want to 
present. The vCard attribute is able to be used in any scenario. The 
structure of the information isn't going to change. People still have 
names, it allows to say Dr., etc. For the meeting roles I agree that not 
all the values would be used in a telemedical case. Participant, 
Presenter, Translator, may still be valid roles. In my draft I 
recognised the need to be able to have a "free text" field for user 
defined roles. This could be used to designate the roles outside a class 
corporate-meeting model, i.e. anaesthetist, surgeon, nurse etc. It isn't 
possible to enumerate every permutation and role but I believe that it 
is possible to come up with a list that will cover the majority of cases.
> Are there any existing conferencing or telepresence systems that carry this sort of information, and how is it used in the system?
[CNG] There's nothing formal that I'm aware of. I see CLUE as a new 
protocol that enables new and enhanced functions to provide a better 
experience to consumers. As I mention in the draft providing information 
about people in a conference is part of that. Its an extension of 
behaviour that we do in live meetings i.e. why do we put a little sign 
on the table in front of the chairman? Why do people mingle before a 
meeting and exchange business cards?

---

From: Christian Groves <[email-masked]>
Date: Tue, 10 Sep 2013 12:35:33 +1000

Hello Paul,

Regards, Christian

On 10/09/2013 5:58 AM, Paul Kyzivat wrote:
> Christian,
>
> Regarding Presenter and Participant, I'm confused about how you see 
> them being used in different types of conferences:
>
[CNG] In this case where there is no floor control being used then it 
wouldn't be necessary to send this attribute as there is no "conference 
control". Everyone can speak, listen etc.
>   Must the endpoint getting the floor do it? Or the focus?
[CNG] Where there is floor control then that's where I see the potential 
use of this parameter. It effectively gives the initial state of the 
conference system control roles this can then be used by the consumer to 
choose the appropriate captures. I think that BFCP should be used to 
control the assignment once the initial CLUE is established to prevent 
the need for both BFCP and CLUE updates however this would need the 
captureID concept to be incorporated into BFCP.

 From a RFC4582 perspective "Controller" is equivalent to "floor chair", 
"Participant" is equivalent to "participant" and "presenter" is 
equivalent to a participant that has been granted the floor.