RE: [XCON] Control Values and the Data Model
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [XCON] Control Values and the Data Model
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:adam at nostrum.com]
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:bob at example.com">
<roles>
<entry>participant</entry>
</roles>
<endpoint entity="sip:bob at 123.45.67.8">
<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:alice at 123.45.67.7">
<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:bob at 123.45.67.8">
<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:charlie at 123.45.67.9">
<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:dinah at 123.45.67.10">
<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:adam at estacado.net, device=sip:adam at 123.45.67.8,
stream=AudioOut, control=gain".
Thoughts?
/a
_______________________________________________
XCON mailing list
XCON at ietf.org
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
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.