Subject: Re: [clue] Roles

From: Christian Groves <[email-masked]>
Date: Wed, 04 Dec 2013 10:02:10 +1100

Hello all,

Does anyone have any more concerns or comments about the "roles" work?

It would be good to get your comments as soon as possible so that I 
could either address then via the list or prepare slides for next week's 
design team meeting to address them.

Regards, Christian

On 25/11/2013 12:20 PM, Christian Groves wrote:
> Hello all,
>
> I'd like to pick up the discussion on roles from the last CLUE WG 
> meeting and try and make some progress via email before the design 
> team meeting.
>
> First i'd like to clarify that "role" is not intended to be a single 
> attribute and it can have different meanings. My draft 
> (draft-groves-clue-role-clarifications-00) seeks to clarify and 
> provide a terminology to be more specific. I.e.:
>      2.1.  Meeting Roles
>      2.2.  Conference System Control Roles
>      2.3.  Institution type
>      2.4.  Person Name Title
>      2.5.  Person Occupation (Job Title)
>      2.6.  Organisation Name
>      2.7.  Meeting Specific Roles
>
> Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the 
> draft. 2.1 and 2.7 have also been grouped by the draft.
>
> There has been some concern that "roles" overlap with floor control. 
> From the role categories above I believe this is only relevant for 
> "conference system control" roles.
>
> Secondly the intended purpose of including "roles" into CLUE is not 
> for conference control or rostering but is for the selection of 
> Scenes/Captures and may be used for any subsequent rendering decisions 
> like the other CLUE attributes. The focus of the CLUE work has been to 
> focus on selecting captures based on technical aspects (what) e.g. 
> spatial properties but I think we've missed a more important aspect 
> that captures will depict people or entities (who). As a consumer I'm 
> likely to be more interested in who rather than what. For example if I 
> have a limited system and have received an Advertisement advertising 3 
> Captures(left/centre/right) and I have only one screen so must choose 
> one. One could choose the centre but this is a problem if my boss is 
> sitting in the left capture.
>
> Thirdly because CLUE enhances the support of multiple streams there is 
> likely to be a larger set of captures being advertised. Information 
> about sources scenes/captures including different combinations may be 
> sent to a consumer providing much more choice. Each of these 
> scenes/captures may have different role information. Rather than try 
> to implement role across several different methods and introduce 
> dependencies between CLUE and other methods (e.g. conference package 
> or SDP which have no Scene/capture/MCC concepts) it is most 
> straightforward to send the information where it is needed i.e. in CLUE.
>
> Fourthly we have included the "description" parameter at the Scene,CSE 
> and Capture level. I think people will use those as de-facto for 
> "role" type information e.g. Scene Description="Company X VIC meeting 
> room". Rather than have a completely unstructured usage of description 
> I think that having "role" type information provided in a structured 
> form (i.e. via vCard) will at least provide a consumer the ability to 
> do some intelligent processing/rendering of the information. By 
> allowing this "role" information to be sent in a structured way via 
> CLUE I think will be an enabler for some interesting services and 
> features.
>
> Finally to re-iterate what the proposal is from the draft:
> 1.      The addition of a capture attribute "Meeting Role" attribute
>         with values as per section 3.1 and 3.2.
> 2.      The addition of a capture attribute "Conference System
>         Control Role" attribute with values as per section 3.3.
> 3.      The addition of a capture attribute "vCard" that allows one
>         or more vCards according to [RFC6350] to be associated with a
>         capture.
> 4.      The addition of a capture attribute "End point vCard" that
>         allows a "group", "org" or "location" kind of vCard according
>         to section 6.1.4/[RFC6350] to be associated with a capture.
>
> Comments?
>
> Regards, Christian
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Roni Even <[email-masked]>
Date: Wed, 4 Dec 2013 13:21:15 +0000

Hi,
I would like to get clarfication only about the proposal, i think this will help us adopt this proposal.

>         with values as per section 3.1 and 3.2.

Are the meeting roles in section 3.1 enumareted value or free text (for human or machine selection?). If for machine selection, is there a priority selection order (pre defined preference) or is it left to each aplication decision.
Is the behavior of the consumer different between 3.1 and 3.2?

>         Control Role" attribute with values as per section 3.3.

Are these values to be enumarted or just text. are they used by the system or just diaplayed by the application.

>         or more vCards according to [RFC6350] to be associated with a

How do you see the linkage between a vCard and specfic person in a capture?

>         to section 6.1.4/[RFC6350] to be associated with a capture.

Roni

________________________________________
From: clue [[email-masked]] on behalf of Christian Groves [[email-masked]]
Sent: Wednesday, December 04, 2013 1:02 AM
To: [email-masked]
Subject: Re: [clue] Roles

Hello all,

Regards, Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 4 Dec 2013 15:09:54 -0800

Hi Christian,

I understand the reasoning you give for why these role attributes have value.  But I don't see a strong reason why they are necessary for CLUE.  I'm concerned it will distract us from more essential work.

I don't understand the difference between the proposal for a "vCard" attribute and the "End point vCard" attribute.  Can you explain?

Regarding vCard, have you thought about the impact to the CLUE data model and protocol?  I skimmed through RFC6350, and as I understand it the vCard format is all UTF-8 text, but not XML.  And it can be very large, particularly if it includes embedded audio and photographs.  I wonder if this potentially large non-XML data will cause problems if we add it to a CLUE advertisement message.

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Tuesday, December 03, 2013 6:02 PM
> To: [email-masked]
> It would be good to get your comments as soon as possible so that I could
> either address then via the list or prepare slides for next week's design team
> meeting to address them.
> 
> Regards, Christian
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 05 Dec 2013 12:02:02 +1100

Hello Roni,

Please see below.

Regards, Christian

> Is the behavior of the consumer different between 3.1 and 3.2?
[CNG] The idea is that the values in section 3.1 would be Enumerations 
as these are common meeting functions. This would allow for easier human 
and machine selection. There would however be the option to have free 
text in this field (instead of an enumeration) for other not so common 
meeting roles that may be specific to a meeting. There wouldn't be any 
priority selection order as this would be up to a local policy at the 
Consumer. If the Advertiser wanted to assign a priority to the capture 
it could use the existing priority attribute in addition.

> Are these values to be enumarted or just text. are they used by the system or just diaplayed by the application.
[CNG] The intention is that these are enumerated. They would be used for 
capture selection and/or displayed.

> How do you see the linkage between a vCard and specfic person in a capture?
[CNG] There would be a possibility to have multiple vCards per capture. 
This would the case where if multiple people were captured they could 
each provide vCard information.

---

From: Christian Groves <[email-masked]>
Date: Thu, 05 Dec 2013 14:18:37 +1100

Hello Mark,

Thanks for the comments. Please see my replies below.

Regards, Christian

> I understand the reasoning you give for why these role attributes have value.  But I don't see a strong reason why they are necessary for CLUE.  I'm concerned it will distract us from more essentia…
[CNG] I see these as just another attribute. I don't think the 
discussion holds up work on any other areas. These can progress in 
parallel. I see the "meeting roles" and "vCard" attributes as largely 
stand alone. The "conference roles" attribute I can see that there may 
be relationship with floor control that needs consideration. So we could 
delay on the "conference roles" if that's in the too hard basket.

With regards to the strong reason I really think it becomes valuable in 
a multiple stream environment.

Consider the heterogeneous use case that we considered for the MCC, i.e.
A conference between endpoints with the following characteristics:
Endpoint A - 4 screens, 3 cameras
Endpoint B - 3 screens, 3 cameras
Endpoint C - 3 screens, 3 cameras
Endpoint D - 3 screens, 3 cameras
Endpoint E - 1 screen, 1 camera
Endpoint F - 2 screens, 1 cameras
Endpoint G - 1 screen, 1 camera

A MCU would get the following Advertisements:

The Advertisements for such a scenario are described below.

+-----------------------+---------------------------------+
| Capture Scene #1| Description=Endpoint x|
+-----------------------|---------------------------------+
| VC1 | EncodingGroup=1|
| VC2 | EncodingGroup=1|
| VC3 | EncodingGroup=1|
| CSE(VC1, VC2, VC3)||
+---------------------------------------------------------+

Table 19: Advertisement received at the MCU from Endpoints A to D

+-----------------------+---------------------------------+
| Capture Scene #1| Description=Endpoint y|
+-----------------------|---------------------------------+
| VC1| EncodingGroup=1|
| CSE(VC1)||
+---------------------------------------------------------+

If the MCU then sends a Advertisement to Endpoint A with information 
about the sources:

+=======================+=================================+
| Capture Scene #1| |
+-----------------------|---------------------------------+
| VC4||
| VC5||
| VC6||
| CSE(VC4,VC5,VC6) ||
+=======================+=================================+
| Capture Scene #2| |
+-----------------------|---------------------------------+
| VC7||
| VC8||
| VC9||
| CSE(VC7,VC8,VC9)||
+=======================+=================================+
| Capture Scene #3| |
+-----------------------|---------------------------------+
| VC10||
| VC11||
| VC12||
| CSE(VC10,VC11,VC12) ||
+=======================+=================================+
| Capture Scene #4| |
+-----------------------|---------------------------------+
| VC13||
| CSE(VC13)||
+=======================+=================================+
| Capture Scene #5| |
+-----------------------|---------------------------------+
| VC14||
| CSE(VC14)||
+=======================+=================================+
| Capture Scene #6| |
+-----------------------|---------------------------------+
| VC15||
| CSE(VC15)||
+=======================+=================================+

It then uses MCCs to advertise site switching:

+=======================+=================================+
| Capture Scene #7| Description=Output3streammix|
+-----------------------|---------------------------------+
| MCC1(VC4,VC7,VC10)| CaptureArea=Left|
|| MaxCaptures=1|
|| SynchronisationID=1|
| | Policy=SoundLevel:0|
|| EncodingGroup=1|
|||
| MCC2(VC5,VC8,VC11,| CaptureArea=Left|
|VC13,VC14,VC15)| MaxCaptures=1|
|| SynchronisationID=1|
|| Policy=SoundLevel:0|
|| EncodingGroup=1|
|||
| MCC3(VC6,VC9,VC12)| CaptureArea=Left|
|| MaxCaptures=1|
|| SynchronisationID=1|
|| Policy=SoundLevel:0|
|| EncodingGroup=1|
|||
| CSE(MCC1,MCC2,MCC3) ||
+=======================+=================================+

Now on what basis does the Consumer decide which of the source captures 
it wants? There's no encodings for the sources so you couldn't rely on 
that. The attributes only tell spatial information/language etc not who 
or where the VC is actually from.

This is why I think you need a structured way to present the information 
about endpoint/scenes and captures. I don't think simply leaving it up 
to a free text field such as "Description" is the best that we can do. 
We'd be relying on multiple endpoints in multiple locations/companies to 
have the same policy in setting the free text field. For example: 
Endpoint B & C my might both be in California and both set "California 
meeting room" as a description. That's not enough to determine that one 
endpoint belongs to Google and the other Cisco. That's where I think 
having a structured format. vCard is a common way of saying:
VERSION:4.0
KIND:org
ORG:Cisco
ADR:;;;;California;;U.S.A
END:VCARD)
or:
VERSION:4.0
KIND:org
ORG:Google
ADR:;;;;California;;U.S.A
END:VCARD)

The information is structured and clear.
> I don't understand the difference between the proposal for a "vCard" attribute and the "End point vCard" attribute.  Can you explain?
[CNG] The difference is the scope of what the vCards cover. The "End 
point vCard" would be based on the endpoint/Capture scene. The 
individual "vCard" would be based on those in the Capture. It would be 
possible for a Provider to provide a vCard about the endpoint,scene and 
location in a structured manner. Section 6.1.4/RFC6350 defines the 
"KIND" parameter which indicates what the vCard represents. It gives 
some examples, which i'll borrow below. Organisational and Geographic 
vCards are not required to provide individual name information. Which 
makes them useful when the name information isn't known.

For example: The provider may be a endpoint that the marketing 
department of company ABC. So the provider could be configured to give 
this information as "organisational" vCard associated with the 
CaptureScene, i.e.

CaptueScene1(vCard=BEGIN:VCARD
VERSION:4.0
KIND:org
FN:ABC Marketing
ORG:ABC\, Inc.;North American Division;Marketing
END:VCARD)

In addition the Provider could send a vCard attribute associated with 
the Captures themselves about the person/people in the capture.
VC1(vCard=BEGIN:VCARD
VERSION:4.0
KIND:individual
FN:Jane Doe
ROLE:Executive
ORG:ABC\, Inc.;North American Division;Marketing
END:VCARD)

> Regarding vCard, have you thought about the impact to the CLUE data model and protocol?  I skimmed through RFC6350, and as I understand it the vCard format is all UTF-8 text, but not XML.  And it c…
[CNG] Yes I've given some thought to that. There is actually an vCard 
XML Representation we could use, xCard [IETF RFC 6351]. I'm not 
conversant enough with XML schema to say how to tie the CLUE and vCard 
schema together. I wouldn't think using UTF-8 vs XML would make much 
difference to the size. I think the size is largely driven by how much 
information is in the vCard. For simple vCards such as the above 
examples I don't think its an issue. However where a Provider wants to 
communicate photos or audio then I agree it will become an issue. In 
these situations I think that we would recommend that the provider 
provides a URI to the data (which is allowed by vCard) rather than 
embedding the data. That way the Consumer could fetch the information if 
it wanted to.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Dec 2013 10:43:51 -0500

I have the impression that there is also a definition for an xCard, that 
is like a vCard, but represented in XML. If that really exists it might 
be a better fit.

---

From: Christian Groves <[email-masked]>
Date: Thu, 12 Dec 2013 16:57:54 +1100

Any further questions/comments?

Christian