Subject: RE: [XCON] Control Values and the Data Model

From: "Chris Boulton" <[email-masked]>
Date: Wed, 3 May 2006 17:51:01 +0100

Now, here's the interesting issue: where, if anywhere, does this
	document represent what the specific value for Bob's gain for
his
	AudioOut channel is?

[CJB] Adam - I'm a bit confused (doesn't take much :-).  This is taken
from the 02 version of the templates
(http://www.ietf.org/internet-drafts/draft-boulton-xcon-media-template-0
2.txt): 

<stream type="audio" name="AudioOut" dir="out">
                          <control type="real" name="gain" enable="true"
                            <label>Volume</label>
                            <value>1.0</value>
                           </control>
                         </stream>

As you can see we had a 'value' element that represents the gain.

	It can't go in the Template portion, since the template has
      entries for each role, not for each user. In other words, it has
      precisely one "Participant" section, even though there can be
      multiple participants.

[CJB] But each participant will have a relevant view of the template -
indicating there own particular gain.  The Conference server will have a
view of all participants and there relevant conference view.

Chris.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: 03 May 2006 00:21
To: XCON-IETF
Subject: [XCON] Control Values and the Data Model

In a recent discussion that the XCON operations document editors were
having, an interesting issue arose. It's not clear to me that we have
given a lot of thought to this issue, so I'd like to see what opinions
the working group has on the topic:

The current view of the data model as described in the framework is that
we have a common conference portion (based primarily on the schema given
in draft-ietf-sipping-conference-package-12); and we have a template
portion (such as those described in
draft-boulton-xcon-media-template-02).

Eliding a lot of information, this leads us to a breakdown of
information roughly along the lines of:

<!-- COMMON PORTION -->

<conference-info>
  <users>
    <user entity="sip:[email-masked]">
      <roles>
        <entry>participant</entry>
      </roles>
      <endpoint entity="sip:[email-masked]">
        <media id="1">
          <type>audio</audio>
        </media>
        <media id="2">
          <type>video</audio>
        </media>
      </endpoint>
    </user>
  </users>

<!-- TEMPLATE PORTION -->

  <template name="basic-audio-video">
    <role name="participant">
      <stream type="audio" name="AudioIn" dir="in">
        <control type="boolean" name="mute" enable="true">
          <label>Mute-Audio</label>
        </control>
      </stream>
      <stream type="video" name="VideoIn" dir="in">
        <control type="boolean" name="pause-video" enable="true">
          <label>Pause-Video</label>
        </control>
      </stream>
      <stream type="audio" name="AudioOut" dir="out">
        <control type="integer" name="gain" enable="true">
          <label>Volume</label>
        </control>
      </stream>
      <stream type="video" name="VideoOut" dir="out" />
    </role>
  </template>
</conference-info>

Now, here's the interesting issue: where, if anywhere, does this
document represent what the specific value for Bob's gain for his
AudioOut channel is?

With the current structure:

    * It can't go in the Template portion, since the template has
      entries for each role, not for each user. In other words, it has
      precisely one "Participant" section, even though there can be
      multiple participants.

    * It can't go in the Common portion, since that part of the document
      is defined to not change regardless of the template in use.
      Because of this, I don't think we can start putting control values
      specific to the template up there.

I can think of two ways to handle this, although there may be more:

   1. Add yet another section to the document, associated with the
      template part, that basically forms the cross product of each user
      and their relevant controls. In other words, add a section like:

      <conference-info>
      ...
        </template>
        <control-values>
          <endpoint entity="sip:[email-masked]">
            <control stream="AudioOut" name="gain" value="92" />
            <control stream="AudioIn" name="mute" value="false" />
            <control stream="VideoOut" name="pause" value="false" />
          </endpoint>
          <endpoint entity="sip:[email-masked]">
            <control stream="AudioOut" name="gain" value="92" />
            <control stream="AudioIn" name="mute" value="false" />
            <control stream="VideoOut" name="pause" value="false" />
          </endpoint>
          <endpoint entity="sip:[email-masked]">
            <control stream="AudioOut" name="gain" value="92" />
            <control stream="AudioIn" name="mute" value="false" />
            <control stream="VideoOut" name="pause" value="false" />
          </endpoint>
          <endpoint entity="sip:[email-masked]">
            <control stream="AudioOut" name="gain" value="92" />
            <control stream="AudioIn" name="mute" value="false" />
            <control stream="VideoOut" name="pause" value="false" />
          </endpoint>
        </control-values>
      </conference-info>

   2. Don't include the literal control values in the document. Instead,
      clients can use the list of user devices and the roles associated
      with them to ascertain which controls are valid for which
      user/endpoint/media-stream combination. Then, the control values
      could be explicitly queried and set by the operations protocol. As
      an example, the XML document representing the conference state
      would never include the value of my "gain" control -- but you
      could learn what it was by issuing a command that basically said
      "query user=sip:[email-masked], device=sip:[email-masked],
      stream=AudioOut, control=gain".

Thoughts?

/a

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 3 May 2006 14:37:24 -0400

I think I understand Adam's concern.  If the conference state is represented
by the conference object, then the template part of the object needs a
branch for every participant (in the role) so that an authorized entity can
read or set the value of Bob's gain different from Alice's gain.  Sure, Bob
may only see his own value, but the moderator may be able to see everyone's.

I think this is pretty much tied to the protocol.  The protocol can have a
concept of a complex key (user+device+control), which doesn't imply that the
object itself has branches for user and device.

As I said in a previous message, I'm not so sure now, having reflected on
the subject, that getting away from the central notion that the conference
state is defined as an object with a schema that is part common and part
template, and manipulating conference state is directly manipulating said
object is a good idea.  The "functional" protocol idea DOES get away from
that notion; it imposes a different view of conference state which is not
the conference object and provides methods that act on that view.

If we were to get back to that notion (conference state = object state),
then the object would indeed need branches for user and possibly device,
which would change the template definition.  We could then argue whether it
was user.device.control or control.user.device (that is, which are the
leaves and which are the main branches of the tree?)

I don't think putting the controls into the common part of the object (which
does have participant branches) is wise.

Brian

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Wednesday, May 03, 2006 12:51 PM
To: Adam Roach; XCON-IETF
Subject: RE: [XCON] Control Values and the Data Model

                            <label>Volume</label>
                            <value>1.0</value>
                           </control>
                         </stream>

Chris.

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: 03 May 2006 00:21
To: XCON-IETF
Subject: [XCON] Control Values and the Data Model

<!-- COMMON PORTION -->

<conference-info>
  <users>

      <conference-info>
      ...
        </template>
        <control-values>

Thoughts?

/a

Information contained in this e-mail and any attachments are intended for
the use of the addressee only, and may contain confidential information of
Ubiquity Software Corporation.  All unauthorized use, disclosure or
distribution is strictly prohibited.  If you are not the addressee, please
notify the sender immediately and destroy all copies of this email.  Unless
otherwise expressly agreed in writing signed by an officer of Ubiquity
Software Corporation, nothing in this communication shall be deemed to be
legally binding.  Thank you.

---

From: <[email-masked]>
Date: Wed, 3 May 2006 16:01:46 -0500

Hi,

In the template draft, we had defined an element called controlArray
which is basically a control set on set of streams. From the basic-audio
template, for the moderator role we have 
			<role name="moderator">
				 <controlArray>
                           <LogicalStream type="audio"
name="MainAudioOut" />
                           <control name="mute" type="boolean"
enable="false">
                            <label>MuteOutputAudio</label>
                            <value>False</value>
                           </control>
                          </controlArray>
                  </role>

The intention of this element is to have the moderator the capability to
mute the stream going to the participant. Of course what we are missing
in this XML is the identification of the user (or device) and we will
add that, but the point is the moderator can have the capability to set
the values of the controls for each and every participant in the
conference. 

Umesh

>From: ext Brian Rosen [mailto:[email-masked]] 
>Sent: Wednesday, May 03, 2006 1:37 PM
>To: 'Chris Boulton'; 'Adam Roach'; 'XCON-IETF'
>I think I understand Adam's concern.  If the conference state 
>is represented by the conference object, then the template 
>part of the object needs a branch for every participant (in 
>the role) so that an authorized entity can read or set the 
>value of Bob's gain different from Alice's gain.  Sure, Bob 
>I think this is pretty much tied to the protocol.  The 
>protocol can have a concept of a complex key 
>(user+device+control), which doesn't imply that the object 
>itself has branches for user and device.
>
>As I said in a previous message, I'm not so sure now, having 
>reflected on the subject, that getting away from the central 
>notion that the conference state is defined as an object with 
>a schema that is part common and part template, and 
>manipulating conference state is directly manipulating said 
>object is a good idea.  The "functional" protocol idea DOES 
>get away from that notion; it imposes a different view of 
>conference state which is not the conference object and 
>provides methods that act on that view.
>
>If we were to get back to that notion (conference state = 
>object state), then the object would indeed need branches for 
>user and possibly device, which would change the template 
>definition.  We could then argue whether it was 
>user.device.control or control.user.device (that is, which are 
>the leaves and which are the main branches of the tree?)
>
>I don't think putting the controls into the common part of the 
>object (which does have participant branches) is wise.
>
>Brian
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 3 May 2006 17:10:17 -0400

If I am following you, this control is ONLY available to moderators.
I don't think that is the kind of thing we should be encouraging.
I also don't think using the "LogicalStream" construction as a stand-In for
the actual stream is a good idea.

I really think the mute is a control on the user's "MainAudioOut" stream,
defined under the participant role.  It's available to him, and it's
available to any entity the permissions allow.  We need a way to address it.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 03, 2006 5:02 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

 Hi,

Umesh

---

From: <[email-masked]>
Date: Wed, 3 May 2006 20:40:06 -0500

>Sent: Wednesday, May 03, 2006 4:10 PM
>To: Chandra Umesh (Nokia-NRC/Dallas); [email-masked]; 
>[email-masked]; [email-masked]
>I also don't think using the "LogicalStream" construction as a 
>stand-In for the actual stream is a good idea.
>
>I really think the mute is a control on the user's 
>"MainAudioOut" stream, defined under the participant role.  
>It's available to him, and it's available to any entity the 
>permissions allow.  We need a way to address it.
>

Yes the control (to mute outoging stream of all the participants) is
given only to moderator role. If I understand correctly the basis for
classification for roles is the privileges each role is assigned. So for
a basic audio template an moderator (or any other role name which we
want to use) would have the privilge to mute the audio streams of all
the participants. Anyways we have to define in the templates what roles
are being specified for this conference and what controls are available
in each role. Are you suggesting that the privilges (or permissions)
assigned to each role would change during the course of the conference ?

Umesh

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 4 May 2006 09:18:12 -0400

I don't think we really need to change permissions during a conference, but
I don't think it's very difficult to allow it.  I think that you need a
permission system to be able to define who gets to view and/or change what.

I think, for example, in most systems, you can get a roster, but you won't
be able to see the details of all the streams each participant is sending or
getting from the mixer.

I do think that some controls will be available only to participants in a
role.  The example you are using (mute) is not a good one, because the user
needs to control his own mute, and moderated conferences need the ability
for the moderator to control it.  I can even imagine defining a floor, where
getting the floor changes the state of the mutes automatically.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 03, 2006 9:40 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

Umesh

---

From: <[email-masked]>
Date: Thu, 4 May 2006 08:31:46 -0500

inline as [UC}

>Sent: Thursday, May 04, 2006 8:18 AM
>I don't think we really need to change permissions during a 
>conference, but I don't think it's very difficult to allow it. 
> I think that you need a permission system to be able to 
>define who gets to view and/or change what.

[UC} But then how do we indicate the change of the permissions in the
template. The template is defining roles and in roles we are defining
certain controls that are availble for that particular role. So if a
template says that control foo is available only to a role of creator,
then it is available only to the role of creator and not any other role.

>
>I think, for example, in most systems, you can get a roster, 
>but you won't be able to see the details of all the streams 
>each participant is sending or getting from the mixer.
>
>I do think that some controls will be available only to 
>participants in a role.  The example you are using (mute) is 
>not a good one, because the user needs to control his own 
>mute, and moderated conferences need the ability for the 
>moderator to control it.  I can even imagine defining a floor, 
>where getting the floor changes the state of the mutes automatically.
>
>Brian
>

[UC} The control Mute is applicable not only to the participant role
(the participant can mute its stream so as the moderator). We have
defined the controlArray element in the moderator role section where the
idea is to have the moderator be able to mute the streams of all the
participants in the conference. And I do agree with your earlier comment
that logicalstream might not be a good idea. We are planning to change
that.

BR

Umesh

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 4 May 2006 09:48:25 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 9:32 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

 inline as [UC}

<br>well, "available to" is problematic.  It's defined ON the role; only
people in the role have one.  There is another question of who gets to view
and/or change it.  That's different from who owns it.

<br> But then you have two controls that do exactly the same thing, and the
user can't see the moderator's control. 

Would it not be better to have one control, and change who can set it?

Brian

---

From: <[email-masked]>
Date: Thu, 4 May 2006 09:12:26 -0500

>[UC} But then how do we indicate the change of the permissions 
>in the template. The template is defining roles and in roles 
>we are defining certain controls that are availble for that 
>particular role. So if a template says that control foo is 
>available only to a role of creator, then it is available only 
>to the role of creator and not any other role.
>
><br>well, "available to" is problematic.  It's defined ON the 
>role; only people in the role have one.  There is another 
>question of who gets to view and/or change it.  That's 
>different from who owns it.
>

[UC] What I mean by "available" is that particular role owns it and can
view it and change it. I quite didn't understand your distinction of
owning the control and be able to view/change it. If a control is
defined in a particular role, then the participant has to have that role
to use that control.

>[UC} The control Mute is applicable not only to the 
>participant role (the participant can mute its stream so as 
>the moderator). We have defined the controlArray element in 
>the moderator role section where the idea is to have the 
>moderator be able to mute the streams of all the participants 
>in the conference. And I do agree with your earlier comment 
>that logicalstream might not be a good idea. We are planning 
>to change that.
>
><br> But then you have two controls that do exactly the same 
>thing, and the user can't see the moderator's control. 
>

[UC] But do we really want the user to know what controls are avaialable
to the moderator. If  we take the Mute example, you would want the
moderator to have the control since it can mute the participant from the
mix, if it not following the conference rules. At that same time you
would want to have the control available to the user too...