Subject: [clue] CLUE Roles and SIP Conference Events

From: Christian Groves <[email-masked]>
Date: Mon, 16 Dec 2013 15:08:37 +1100

Hello all,

There have been some thoughts that the Conference Framework is more 
appropriate to carry the role information associated with captures. I 
don't believe it is. I've provided my thoughts on this before the design 
meeting this week.

Structure from RFC 4575
-----------------------
  conference-info
      |
      |-- conference-description
      |
      |-- host-info
      |
      |-- conference-state
      |
      |-- users
      |    |-- user
      |    |    |-- endpoint
      |    |    |    |-- media
      |    |    |    |-- media
      |    |    |    |-- call-info

The structure is not optimal for describing the people in captures. i.e. 
if I have 3 people being depicted by a single stream. If users actually 
represented the persons within the media (which I contend it does not) 
it would have three user structures pointing to the same media stream. 
The XML schema in RFC4575 only allows for one display-text(name) and 
role per user-type.

RFC 4575 Section 5.6 <users> - this appears to be related to who owns 
the endpoint NOT who is contained in the media. i.e. the conference 
framework indicates that the users must have a unique URI in the 
conference. This view appears to also be supported by section 
6.3/RFC5239 (XCON framework) and section 4.6.5/RFC6501 (XCON data 
schema). It seems non-nonsensical that all the people depicted in the 
conference all have a URI associated with them. Therefore it doesn't 
seem appropriate to use the "user" structure to represent all the people 
within a single media. The usage of "roles" from RFC 4575 is not 
appropriate because it relates to the owner of the endpoint not the 
people displayed in the media capture encoding.

In order to have Capture Scene/Captures in the Conferencing framework 
the information would be need to be added under the endpoint, i.e.

      |    |-- user
      |         |-- endpoint
      |              |-- media
      |              |-- capture_scene
      |                   |--capture1
      |                   |--capture2
      |                   |--capturex

These concepts would have to be included into the conferencing framework 
before CLUE role information could be provided. However this could mean 
a several year delay in adding "role" information because it's not in 
the scope of the CLUE WG. If it was decided to follow this route, the 
captures could provide a label to correlate to the media in the above 
structure. This structure would effectively mirror what is in a CLUE 
Advertisement (Its not clear what the benefit would be for duplicating 
the information). The complicating factor is that the conference focus 
(MCU) may CLUE Advertise different captures than what was originally 
advertised from the source Endpoints. i.e. the MCU may compose/switch 
streams. Therefore the information about the captures from the Endpoint 
(i.e. role) may be different from what is received by a Consumer in an 
Advertisement. This would be problematic for a Consumer to try to 
correlate the information from the Conference Event Package to what it 
actually receives in the CLUE Advertisement for the purpose Capture 
selection based on the role information.

A further complication is the relationship between the CLUE messages and 
any SIP subscribes/Notifies related to the Capture Scene /Capture / Role 
information. There would be race conditions regarding when the 
Conference Package data is received vs when an CLUE Advertisement is 
received vs the reception of updated SDP Offer/Answers. This 
co-ordination would be non-trivial.

To avoid this situation it's appropriate to provide information 
regarding captures (including the role information) in the CLUE messages 
as it relates to the people in the captures and removes any interaction 
issues.

It also must be remembered that the Capture attributes are intended for 
processing by automata and/or humans. The focus of the Conference Event 
framework is purely with respect to endpoint and media information as 
per RFC4575 Sect 5.1 is "...<endpoint>, and <media> are intended for 
display to human subscribers only". The intent of the "role" information 
in CLUE is to allow for processing by automata. RFC4575 Section 5.6.3 
there is no definition of what this is other than a set of strings. Its 
only for human consumption. RFC6501 section 4.6.5.2 does provide some 
values for "role" but these do not cover vCard type information nor the 
full set of conference roles. Also given the scope issue raised above it 
wouldn't be possible to indicate the people within the capture.

Furthermore CLUE is meant for use in point to point and multi-point 
environments. So far it has been designed to be largely independent from 
other protocols. i.e. its not coupled to BUNDLE and the encoding 
information is separate. The conference framework may or may not be used 
depending on the call or network scenario. Therefore it doesn't seem 
wise to place capture attribute information such as "role" information 
only in the Conference Event Package. This would mean that the role 
information could only be used in a limited sub-set of scenarios.

Therefore I believe its appropriate to add role in CLUE at this time.

Comments?

Regards, Christian

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 17 Dec 2013 09:39:26 +0100

Hello Christian and all,

when it comes to role management, I have multiple times expressed my concerns with respect to its direct inclusion in 'orthogonal' structures (like data model, conference information and the like). You might want to have a look at a specific thread dedicated to policies and roles inside XCON, back in 2007. I expressed my personal view on this subject in a (long) e-mail (http://www.ietf.org/mail-archive/web/xcon/current/msg01919.html). I keep on thinking that we should definitely try and adhere to the well-known design pattern associated with the concept of separation of concerns and use something like XACML to express role information inside CLUE.

My two cents,

Simon

Il giorno 16/dic/2013, alle ore 05:08, Christian Groves ha scritto:

> Hello all,
> 
> There have been some thoughts that the Conference Framework is more appropriate to carry the role information associated with captures. I don't believe it is. I've provided my thoughts on this before the design meeting this week.
> 
> Structure from RFC 4575
> -----------------------
> conference-info
>     |
> The structure is not optimal for describing the people in captures. i.e. if I have 3 people being depicted by a single stream. If users actually represented the persons within the media (which I contend it does not) it would have three user structures pointing to the same media stream. The XML schema in RFC4575 only allows for one display-text(name) and role per user-type.
> 
> RFC 4575 Section 5.6 <users> - this appears to be related to who owns the endpoint NOT who is contained in the media. i.e. the conference framework indicates that the users must have a unique URI in the conference. This view appears to also be supported by section 6.3/RFC5239 (XCON framework) and section 4.6.5/RFC6501 (XCON data schema). It seems non-nonsensical that all the people depicted in the conference all have a URI associated with them. Therefore it doesn't seem appropriate to use the "user" structure to represent all the people within a single media. The usage of "roles" from RFC 4575 is not appropriate because it relates to the owner of the endpoint not the people displayed in the media capture encoding.
> 
> In order to have Capture Scene/Captures in the Conferencing framework the information would be need to be added under the endpoint, i.e.
> 
>     |    |-- user
>     |         |-- endpoint
>     |              |-- media
>     |              |-- capture_scene
>     |                   |--capture1
>     |                   |--capture2
>     |                   |--capturex
> 
> These concepts would have to be included into the conferencing framework before CLUE role information could be provided. However this could mean a several year delay in adding "role" information because it's not in the scope of the CLUE WG. If it was decided to follow this route, the captures could provide a label to correlate to the media in the above structure. This structure would effectively mirror what is in a CLUE Advertisement (Its not clear what the benefit would be for duplicating the information). The complicating factor is that the conference focus (MCU) may CLUE Advertise different captures than what was originally advertised from the source Endpoints. i.e. the MCU may compose/switch streams. Therefore the information about the captures from the Endpoint (i.e. role) may be different from what is received by a Consumer in an Advertisement. This would be problematic for a Consumer to try to correlate the information from the Conference Event Package to what it actually receives in the CLUE Advertisement for the purpose Capture selection based on the role information.
> 
> A further complication is the relationship between the CLUE messages and any SIP subscribes/Notifies related to the Capture Scene /Capture / Role information. There would be race conditions regarding when the Conference Package data is received vs when an CLUE Advertisement is received vs the reception of updated SDP Offer/Answers. This co-ordination would be non-trivial.
> 
> To avoid this situation it's appropriate to provide information regarding captures (including the role information) in the CLUE messages as it relates to the people in the captures and removes any interaction issues.
> 
> It also must be remembered that the Capture attributes are intended for processing by automata and/or humans. The focus of the Conference Event framework is purely with respect to endpoint and media information as per RFC4575 Sect 5.1 is "...<endpoint>, and <media> are intended for display to human subscribers only". The intent of the "role" information in CLUE is to allow for processing by automata. RFC4575 Section 5.6.3 there is no definition of what this is other than a set of strings. Its only for human consumption. RFC6501 section 4.6.5.2 does provide some values for "role" but these do not cover vCard type information nor the full set of conference roles. Also given the scope issue raised above it wouldn't be possible to indicate the people within the capture.
> 
> Furthermore CLUE is meant for use in point to point and multi-point environments. So far it has been designed to be largely independent from other protocols. i.e. its not coupled to BUNDLE and the encoding information is separate. The conference framework may or may not be used depending on the call or network scenario. Therefore it doesn't seem wise to place capture attribute information such as "role" information only in the Conference Event Package. This would mean that the role information could only be used in a limited sub-set of scenarios.
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
> 

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Christian Groves <[email-masked]>
Date: Tue, 17 Dec 2013 21:09:00 +1100

Hello Simon,

I had a look at the email you referred to and XACML. I think these are 
far beyond what I'm currently proposing with respect to "role" in CLUE. 
The work you refer to seems to be related to policy and conference 
control. This is not the intention behind my proposal for vCard and 
meeting roles (generically know as roles). There may be some overlap 
with what I describe as conference roles with floor control. 
Unfortunately it seems "Role" is a loaded word. I think if we had called 
it "participant information" from the start there wouldn't be many 
concerns...

The intention is to provide information about who is in each capture for 
the purpose selection of captures and possible rendering. These do not 
provide any permissions or control from a conference perspective. I 
think such "control/policy" aspects are best left outside of CLUE.

What i'd like to see is that the information needed for a protocol is 
self contained. I.e. you have all the information needed for 
scene/captures selection in CLUE, for policy/conferencing rolls that 
could be described as you mentioned above, for conference state its 
covered by the SIP conferencing framework, encoding information is kept 
in SDP etc.

Regards, Christian

On 17/12/2013 7:39 PM, Simon Pietro Romano wrote:
> Hello Christian and all,
>
> when it comes to role management, I have multiple times expressed my 
> concerns with respect to its direct inclusion in 'orthogonal' 
> structures (like data model, conference information and the like). You 
> might want to have a look at a specific thread dedicated to policies 
> and roles inside XCON, back in 2007. I expressed my personal view on 
> this subject in a (long) e-mail 
> (http://www.ietf.org/mail-archive/web/xcon/current/msg01919.html). I 
> keep on thinking that we should definitely try and adhere to the 
> well-known design pattern associated with the concept of separation of 
> concerns and use something like XACML to express role information 
> inside CLUE.
>
> My two cents,
>
> Simon
>
>
>> don't believe it is. I've provided my thoughts on this before the 
>> design meeting this week.
>>
>> Structure from RFC 4575
>> -----------------------
>> conference-info
>>     |
>> The structure is not optimal for describing the people in captures. 
>> i.e. if I have 3 people being depicted by a single stream. If users 
>> actually represented the persons within the media (which I contend it 
>> does not) it would have three user structures pointing to the same 
>> media stream. The XML schema in RFC4575 only allows for one 
>> display-text(name) and role per user-type.
>>
>> seem appropriate to use the "user" structure to represent all the 
>> people within a single media. The usage of "roles" from RFC 4575 is 
>> not appropriate because it relates to the owner of the endpoint not 
>> the people displayed in the media capture encoding.
>>
>> These concepts would have to be included into the conferencing 
>> framework before CLUE role information could be provided. However 
>> this could mean a several year delay in adding "role" information 
>> because it's not in the scope of the CLUE WG. If it was decided to 
>> follow this route, the captures could provide a label to correlate to 
>> the media in the above structure. This structure would effectively 
>> mirror what is in a CLUE Advertisement (Its not clear what the 
>> benefit would be for duplicating the information). The complicating 
>> factor is that the conference focus (MCU) may CLUE Advertise 
>> different captures than what was originally advertised from the 
>> source Endpoints. i.e. the MCU may compose/switch streams. Therefore 
>> the information about the captures from the Endpoint (i.e. role) may 
>> be different from what is received by a Consumer in an Advertisement. 
>> This would be problematic for a Consumer to try to correlate the 
>> information from the Conference Event Package to what it actually 
>> receives in the CLUE Advertisement for the purpose Capture selection 
>> based on the role information.
>>
>> A further complication is the relationship between the CLUE messages 
>> and any SIP subscribes/Notifies related to the Capture Scene /Capture 
>> / Role information. There would be race conditions regarding when the 
>> regarding captures (including the role information) in the CLUE 
>> messages as it relates to the people in the captures and removes any 
>> interaction issues.
>>
>> It also must be remembered that the Capture attributes are intended 
>> for processing by automata and/or humans. The focus of the Conference 
>> Event framework is purely with respect to endpoint and media 
>> information as per RFC4575 Sect 5.1 is "...<endpoint>, and <media> 
>> are intended for display to human subscribers only". The intent of 
>> the "role" information in CLUE is to allow for processing by 
>> automata. RFC4575 Section 5.6.3 there is no definition of what this 
>> is other than a set of strings. Its only for human consumption. 
>> RFC6501 section 4.6.5.2 does provide some values for "role" but these 
>> do not cover vCard type information nor the full set of conference 
>> roles. Also given the scope issue raised above it wouldn't be 
>> possible to indicate the people within the capture.
>>
>> environments. So far it has been designed to be largely independent 
>> from other protocols. i.e. its not coupled to BUNDLE and the encoding 
>> information is separate. The conference framework may or may not be 
>> used depending on the call or network scenario. Therefore it doesn't 
>> seem wise to place capture attribute information such as "role" 
>> information only in the Conference Event Package. This would mean 
>> that the role information could only be used in a limited sub-set of 
>> scenarios.
>>
>> [email-masked] <mailto:[email-masked]>
>  e-mail: [email-masked] <mailto:[email-masked]>
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 17 Dec 2013 10:00:21 -0600

Individual opinions below [MB].

Mary.

On Tue, Dec 17, 2013 at 4:09 AM, Christian Groves <
[email-masked]> wrote:

> Hello Simon,
>
> I had a look at the email you referred to and XACML. I think these are far
> beyond what I'm currently proposing with respect to "role" in CLUE. The
> work you refer to seems to be related to policy and conference control.
> This is not the intention behind my proposal for vCard and meeting roles
> (generically know as roles). There may be some overlap with what I describe
> as conference roles with floor control. Unfortunately it seems "Role" is a
> loaded word. I think if we had called it "participant information" from the
> start there wouldn't be many concerns...
>
> provide any permissions or control from a conference perspective. I think
> such "control/policy" aspects are best left outside of CLUE.
>
> What i'd like to see is that the information needed for a protocol is self
> contained. I.e. you have all the information needed for scene/captures
> selection in CLUE, for policy/conferencing rolls that could be described as
> you mentioned above, for conference state its covered by the SIP
> conferencing framework, encoding information is kept in SDP etc.
>
[MB] Right. And, SIP conferencing has an event package/data model that
defines roles.  There are a number of folks that don't implement CCMP, but
they still use the XCON data model as it provides a richer set of
information.    My personal preference is that the XCON data model be
extended to handle roles in the context of multi-streams.  [/MB]

>> concerns with respect to its direct inclusion in 'orthogonal' structures
>> (like data model, conference information and the like). You might want to
>> have a look at a specific thread dedicated to policies and roles inside
>> XCON, back in 2007. I expressed my personal view on this subject in a
>> (long) e-mail (http://www.ietf.org/mail-archive/web/xcon/current/
>> msg01919.html). I keep on thinking that we should definitely try and
>> adhere to the well-known design pattern associated with the concept of
>> separation of concerns and use something like XACML to express role
>> information inside CLUE.
>>
>> My two cents,
>>
>> Simon
>>
>>
>>> appropriate to carry the role information associated with captures. I don't
>>> believe it is. I've provided my thoughts on this before the design meeting
>>> this week.
>>>
>>> Structure from RFC 4575
>>> -----------------------
>>> conference-info
>>>     |
>>> represented the persons within the media (which I contend it does not) it
>>> would have three user structures pointing to the same media stream. The XML
>>> schema in RFC4575 only allows for one display-text(name) and role per
>>> user-type.
>>>
>> [MB] I suggest you look at RFC 6501. [/MB]

>>> conference. This view appears to also be supported by section 6.3/RFC5239
>>> (XCON framework) and section 4.6.5/RFC6501 (XCON data schema). It seems
>>> non-nonsensical that all the people depicted in the conference all have a
>>> URI associated with them.
>>>
>> [MB] I don't think that's at all non-sensical. That's normal SIP
processing and SIP conferencing.   [/MB]

> Therefore it doesn't seem appropriate to use the "user" structure to
>>> represent all the people within a single media. The usage of "roles" from
>>> RFC 4575 is not appropriate because it relates to the owner of the endpoint
>>> not the people displayed in the media capture encoding.
>>>
>>> before CLUE role information could be provided.
>>>
>> [MB] Not necessarily.  The data model is extensible and you can make some
of the information optional (but required for a CLUE endpoint.  [/MB]

> However this could mean a several year delay in adding "role" information
>>> because it's not in the scope of the CLUE WG.
>>>
>> [MB] I certainly don't think so.  We've added additional extensions to
the XCON data model recently and it doesn't take several years. The design
is intended to support extensibility and we should be able to progress
these extensions in parallel with CLUE.
[/MB]

> If it was decided to follow this route, the captures could provide a label
>>> to correlate to the media in the above structure. This structure would
>>> effectively mirror what is in a CLUE Advertisement (Its not clear what the
>>> benefit would be for duplicating the information). The complicating factor
>>> is that the conference focus (MCU) may CLUE Advertise different captures
>>> than what was originally advertised from the source Endpoints. i.e. the MCU
>>> may compose/switch streams. Therefore the information about the captures
>>> from the Endpoint (i.e. role) may be different from what is received by a
>>> Consumer in an Advertisement. This would be problematic for a Consumer to
>>> try to correlate the information from the Conference Event Package to what
>>> it actually receives in the CLUE Advertisement for the purpose Capture
>> [MB] The reality is that a CLUE implementation will have to correlate
some of this information, but those are implementation details that we can
provide guidance on but would be non-normative.  Call Flows are a really
good place to illustrate this sort of thing. [/MB]

>>> information. There would be race conditions regarding when the Conference
>>> Package data is received vs when an CLUE Advertisement is received vs the
>>> reception of updated SDP Offer/Answers. This co-ordination would be
>>> non-trivial.
>>>
>>
>>> regarding captures (including the role information) in the CLUE messages as
>>> it relates to the people in the captures and removes any interaction issues.
>>>
>> [MB] If we do that, you then need to explain the relationship between
this information and role information in the event package and still ensure
that it's consistent.  Again, CLUE is based on SIP/SIP conferencing.  We
must ensure that there's consistency in information. So, your proposal
moves the problem around and adds unnecessary complexity to CLUE that isn't
required for fundamental multi-stream processing.  It's certainly useful
information for the application, but not fundamental to CLUE deliverables
(just as rosters are out of scope). [/MB]

>>> framework is purely with respect to endpoint and media information as per
>>> RFC4575 Sect 5.1 is "...<endpoint>, and <media> are intended for display to
>>> human subscribers only".
>>>
>> [MB]  And, I think that's actually an error in RFC 4575.  If you read
further, it notes that  <media> is used to [/MB]

> The intent of the "role" information in CLUE is to allow for processing by
>>> automata. RFC4575 Section 5.6.3 there is no definition of what this is
>>> other than a set of strings. Its only for human consumption. RFC6501
>>> section 4.6.5.2 does provide some values for "role" but these do not cover
>>> vCard type information nor the full set of conference roles.
>>>
>> [MB] Certainly, but it could be extended to include such. Personally, I
don't think this is crucial to the CLUE deliverables at this point.  We
could certainly do extensions later, once we get the basic CLUE stuff done
(which I believe (putting on my chair hat) is a much higher priority than
adding this element) [/MB]

> Also given the scope issue raised above it wouldn't be possible to
>>> indicate the people within the capture.
>>>
>>> information is separate.
>> [MB] It's not directly coupled, but CLUE is coupled with SDP based upon
the decision to include the encoding limits in SDP.  [/MB]

> The conference framework may or may not be used depending on the call or
>>> network scenario. Therefore it doesn't seem wise to place capture attribute
>>> information such as "role" information only in the Conference Event
>>> Package. This would mean that the role information could only be used in a
>>> limited sub-set of scenarios.
>>>
>> [MB] That is certainly a valid point, but I still contend that this is
not something that is NOT specific to CLUE or multi-stream in general.
 Also, as I've said before, this issue has been raised generally in
DISPATCH:
http://www.ietf.org/mail-archive/web/dispatch/current/msg04805.html    Now,
if this were something fundamental to CLUE, then I would fully agree that
solving the problem just for CLUE is the right thing to do, but it's not,
so I think working on something more general and then later extending CLUE
is a much better option at this juncture.  [/MB]