RE: [XCON] XCON Data Model

["Morgan, Dave" <[e-mail]>]

These are some good points.  I was not able to attend the meeting
either, but I think there were some assumptions made that have not yet
been communicated and would lead to changes in the framework document.
So let me ask the team the following:
1) Will the data model be the basis of the conference object?
2) If that is the case, will there be a unique instance of the data
model for each conference which can be manipulated by the other
conference protocols?  
2) Will the data models which are pre-populated with certain initial
values and ranges act as conference blueprints?

If the answer to the above questions are yes, then I think that having 1
data structure may not be any more complex than having 2.  The structure
may grow big, but as long as there are precautions in making the data
model extensible then we should be OK.  

As far as the endpoint controls are concerned, and the endpoint
bandwidth, there's an inherent tradeoff between space and time -- the
size of the data model and the speed of the communication.  If we are
moving in the direction of a large all inclusive data model, then we are
going to want a simple and faster conference control protocol.  This WG
has touched on this before, and there was a good amount of interest in
the simple control protocol (which is my preference).  Coming full
circle, although I wasn't involved in the discussions on the conference
protocol, that's probably why it failed, because you first need to
decide the data model to determine what you need to communicate.  That's
why Oscar first took the initiative to consolidate this group's prior
work into a single data model.  It looks like the final step is to
absorb the unique data elements expressed in the template into the
common conference data model.

Dave 



------------------------------------------------------------------------

David P. Morgan, PhD 
VP, Enterprise Technology & Architecture 
Fidelity Investments Systems Company 
Phone:  [phone] 
Fax:      [phone] 
Mailing: 82 Devonshire St, MZ V2A 
            Boston, MA 02109-3614 
Office:   245 Summer Street, 2nd Floor 



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, July 12, 2006 7:31 PM
To: [e-mail]; [e-mail]
Subject: RE: [XCON] XCON Data Model

Hello,

I am trying to understand how moving the template part (controls etc) to
the data model is going to help. The main motiviation for the templates
is to define the mixer behaviour and also provide the media control
capabilities that are available to the end users in the conference.
Based on the template the client can provide a user interface, with
appropriate buttons, slide bars etc for controls. What I failed to
understand is how moving the controls and other elements from the
templates into the data model is going to help us if not do away with
some of the flexibility we had with templates. 

For one how does an endpoint know what all controls are available to it
before the conference starts so that it can provide a user interface to
the user. Also adding simple audio controls (as illustrated in the
latest data model draft) is easy, but I am not sure adding more complex
video related controls might be a bit challenging. Also the controls
differ based on the roles of each participant of the conference. How
will this be reflected in the data model? Also is it possible for an
authorized entity say moderator to view/change the values of the
controls.

I am not able to attend  IETF meeting this time around since I was tied
up pretty hard moving from Dallas to Bay area.

BR

Umesh
  

 

>-----Original Message-----
>From: ext Adam Roach [mailto:[e-mail]] 
>Sent: Monday, July 10, 2006 9:57 AM
>To: XCON-IETF
>Subject: [XCON] XCON Data Model
>
>At the Dallas IETF meeting (IETF 65), the chairs called for a 
>team of editors to work during the following several months to 
>produce a set of protocol operations (semantics, not syntax) 
>that can be used to manipulate conference state. During the 
>course of the discussions, it became clear that the apparent 
>consensus on the data model within the working group was more 
>illusory than rough. Unable to build the operations on a 
>shifting foundation, we disbanded the operations document 
>editor team to focus our efforts on the data model.
>
>On June 21st, the chairs sent out a call for participants for 
>an editing session to work on the data model to be held on 
>Sunday, July 9th. 
>Participants in the session are listed at the end of this message.
>
>As a result of this editing session, Oscar Novo (the editor of 
>the data model document) will be producing and publishing a 
>new version of the data model document shortly.
>
>In attempting to solve some of the difficulties that we have 
>had with the data model, the participants of this editing 
>session concluded that a preponderance of the issues resulted 
>from the division of the template portion of conference state 
>from the fixed portion of conference state.
>
>To address this issue, the team produced text and examples 
>that incorporate the controls associated with audio streams 
>directly into what was previously called the "fixed part" of 
>the conference. Other information relating to the conference 
>(e.g. moderator controls on streams that affect all 
>participants' audio) are moved into appropriate other 
>locations (in the example given above, into the 
><available-media/> section).
>
>Additional controls required by the conference server can be 
>added to the document in the same way that PIDF presence 
>documents can be extended.
>
>So, for example, under <users>/<user>/<endpoint>, the document 
>for a user participating in an audio/video conference might 
>look something like this (with some of the elements that 
>aren't interesting for this example elided):
>
><endpoint>
>  <media>
>    <type>audio</type>
>    <display-type/>
>    <label/>
>    <src-id/>
>    <status/>
>    <to-mixer name="AudioIn">
>      <floor name="main" floor_id="1" instances="1" enable="true"
>         value="false">
>      </floor>   
>        <controls>
>          <control type ="boolean" name="mute" enable="true">
>            <display-text xml:lang="en">Mute-Audio</display-text>
>            <value>True</value>
>          </control>
>        </controls>
>    </to-mixer>
>    <from-mixer name="AudioOut">
>      <controls>
>        <control type="signed-char" name="gain" enable="true" >
>          <display-text xml:lang="en">Volume</label>
>          <value>0</value>
>        </control>
>      </from-mixer>
>    </controls>
>  </media>
>
>  <media>
>    <type>video</type> (from SIP conferencing event package)
>    <display-type/> (from SIP conferencing event package)
>    <label/> (from SIP conferencing event package)
>    <src-id/> (from SIP conferencing event package)
>    <status/> (from SIP conferencing event package)
>    <to-mixer name="VideoIn">
>      <floor name="main" floor_id="1" instances="1" enable="true"
>         value="false">
>      </floor>   
>        <controls>
>          <control type="boolean" name="blank" enable="true">
>            <display-text xml:lang="en">Mute Video</display-text>
>            <value>True</value>
>          </control>
>        </controls>
>    </to-mixer>
>    <from-mixer name="VideoOut">
>      <controls>
>        <control name="layout" type="enum" enable="false">
>          <display-text xml:lang="en">Video Layout</label>
>          <value>quadrate</value>
>        </control>
>      </controls>
>    </from-mixer>
>  </media>
></endpoint>
>
>Similarly, controls that apply at a different level than 
>endpoint/stream would appear at an appropriate place in the 
>document. So, moderator controls that affect all media output 
>would go under <conference-description>/<available-media>, and 
>look something like:
>
><available-media>
>  <entry label="23985u7t6">
>    <type>audio</type>
>    <display-text/>
>    <status/>
>    <mixing-mode/>
>    <mix-level>
>    <codecs>
>      <entry/>
>    </codecs>
>    <controls>
>      <control name="mute" type="boolean" enable="false">
>        <display-text xml:lang="en">Mute All Audio</label>
>        <value>False</value>
>      </control>
>    </controls>
>  </entry>
>  <entry label="90gj2094">
>    <type>video</type>
>    <display-text/>
>    <status/>
>    <mixing-mode/>
>    <mix-level>
>    <codecs>
>      <entry/>
>    </codecs>
>    <controls>
>      <control name="layout" type="enum" enable="false">
>        <display-text xml:lang="en">Video Layout</label>
>        <value>quadrate</value>
>      </control>
>    </controls>
>  </entry>
></available-media>
>
>We would like to have feedback on this approach before we 
>invest too much time finalizing the approach in the data model 
>draft. If time allows, please discuss on this list prior to 
>the meeting on Thursday. We will, of course, visit these 
>issues in the meeting on Thursday.
>
>/a
>
>---
>The team that met consisted of the following participants:
>
>Oscar Novo
>Roni Even
>Alan Johnston
>Rohan Mahy
>Cullen Jennings
>Mary Barnes
>Gonzalo Camarillo
>Srivatsa Srinivasan
>
>_______________________________________________
>XCON mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/xcon
>

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


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