xcon framework overview & issues editors: mary barnes ( mary.barnes@nortelnetworks )

XCON FrameworkOverview & Issues

Editors: Mary Barnes ([email protected]) Chris Boulton ([email protected]) Orit Levin ([email protected])

XCON WGIETF-62 Meeting

Minneapolis, Mar 8th & 10th 2005

mailto:[email protected]

mailto:[email protected]

2 draft-barnes-xcon-framework-02Mar 8th, 2005

OverviewPart 1 – Tuesday (45 min): Current status of XCON framework document Data Model derived and tentatively agreed at Interim Issue Discussion

Part 2 – Thursday (15 min) (starts at chart 23): New work items Agreements/status of Discussion Points Summary of other open issues Additional Work items Way Forward


Current Framework Status

(Another) major re-write from -01 version based on interim meeting discussions and consensus: Inline with Adam’s summary on 08 Feb 2005. Simplified (and consistent) terminology:

Remains protocol agnostic in terms of call control signaling.

Defined “Focus” in the context of this framework. Added new terms: “active conference”, “media

graph”, etc. Removed unused terms: “multimedia stream”,

etc. Use of “Conferencing System” and “Client” rather

than “XCON server”, “XCON client”, etc.


Current Framework Status

Simplified (and consistent) terminology (continued): Updated “Template” terminology:

Template is associated with a human-readable doc (eg. RFC), with an IANA registry based on a triplet of form: name, RFC, XML schema.

Client can query a conferencing system for a list of templates that the system supports (per discussion of “Blueprints”).

Note: Blueprint is a data object, Template is a “type” Note: Discussion Point 3 on list around querying a

particular template


Current Framework Updates

Simplified Data Model (types and objects): No separation of “policy” from the conference

data itself ; it’s all part of the “Conference Object”. Policy uses ranges to control limits on values Policy is based on simple list structures (i.e. a list (of

clients) per type of data the listed clients have permission to manipulate).

Conference Object Type is comprised of “Common Conference Information” type and “Conference Template”. Supports each of the stages of a conference instance (e.g. “reservation”, “active”, etc.)


Current Framework Updates

Introduced the “Cloning Tree” as a model for System Realization.

Introduced iCal to support scheduling and recurring reservations.


Current Framework Updates Incorporated in a bit more background information to

set the context. No duplication of content from SIPPING

Conferencing Framework Section 8 intended to address relationship to

SIPPING. SIP used only as an example protocol, however,

objective is to ensure that basic conferencing functionality for SIP is not impacted.

Current version intended to provide the baseline terminology, model and high level interfaces (including protocols) -> more work definitely required to describe detailed functionality once basics are agreed (hopefully today).


“New-02” Conferencing System DecompositionConferencing System

Floor ControlClient

Notification Service

ConferenceControlClient

ConferenceControlServer

CallSignaling

Client

NotificationClient

FloorControl Server

SIP/PSTN/H.323T.120/Etc.

TBD SIP NOTIFY/Etc.

Conferencing Client

Foci

Conference Object

Conference Object

Conference Object

Updated Logical names.Updated Logical names.Simplified model bySimplified model bylogical grouping of datalogical grouping of data

BFCPData I/FXCONOther


“New-02” Conference Object TypeConference Object Type

UserControl Interface

Mixer Algorithm

InputsAnd

Outputs

User’sView Etc.

Conference Template Type

Conference Description

Membership (Roles, Capacity, Names)

Signaling (Protocol, Direction, Status)

Sidebars (and other attributes)

Common Conference Information Type


“New-02” Cloning Tree for System Realization Parent A Conference Object

Policies

Parent B Conference Object

Policies

(Created as “Independent from Parent) Child 1 Conference Object

Policies

Child 2 Conference Object

Policies


Issue – DP 1: Referring to Sets of Meetings Interim agreements reflected in current doc on scheduling a

conference: iCal defined as the required mechanism to be referenced (i.e. XCON

won’t define any ical extensions). iCal object used to describe “time” (eg. Start time, end time) Makes use of cloning tree model to create the “Conference Object for

Reservation”: Thus, can alter a series by manipulating this Parent Object. Can manipulate within the range of the series by cloning the

children associated within that time range. DP1 highlights an additional consideration not currently explicitly

addressed: Is it necessary to be able to identify "all future occurrences" of a conference

(i.e. “infinite series”) ?

Proposal: Should be inherently supportable with “cloning tree“ structure and iCal (i.e. should not impact current/planned iCal functionality)


Issue – DP 2: Floor Control Model in terms of “Groups of RTP streams”?

DP2 discusses the need to identify bundles of associated RTP streams, possibly at the protocol level, and possibly just as a concept for discussion of the protocols. Do we need this? If so, what do we call this? Is it represented in the protocols? If it is part of a protocol:

which protocol: Conference Control Protocol – inside templates? Inside SDP? Within BFCP (which is done already)?

how is the grouping defined? Mailing list feedback indicates, we don’t need this grouping

mechanism, but rather can use a stream name specific to a “role”. Proposal: go forward based on mailing list feedback. Validate

approach by working through further detailed flows, etc. with protocols (in section 7).


Issue – DP3: Querying Templates Interim Consensus: Agreement to provide the ability to

query a server that implements the XCON protocols to determine which templates it understands.

Additional discussion, but no consensus, around the ability to query a server about a particular template to retrieve a description -- probably an XML document, but possibly in some other form -- of that template. The idea behind this functionality would be enabling clients to interact with

templates that they don't natively understand. By extracting the variables from the template description and presenting

them to the user in some format that allows manipulation of their values, all clients can work with all templates, even those that were not defined when the client was developed.

— Is this an important property? Proposal: Yes, this property is important for templates to remain

flexible.


Issue – DP3: Querying Templates - continued What is the format in which the template description should be

presented? Alternative 1: XML Schema - as in current templates draft. This

then supplies all relevant information that a client needs. Alternative 2: “Blueprint”, per current FW, which includes a

template instantiation with customized values

Does the client retrieve this description from the server itself, or is there some centralized repository to get these descriptions from?

Mailing list feedback [Cullen]: can’t be from central repository. Proposal: XCON server advertises exactly what is supported by

the server.


Issue – DP3: Querying Templates- continued

Can the description be the same as the XML schema that is registered with IANA?

Proposal: Should be the same.

Is the description sent at the same time as the list of templates is sent to the client, or does a client need to explicitly ask about templates that it doesn't understand?

Proposal: A client would need to query any templates that it doesn't understand THEN make a decision on compatibility.


Issue – DP3: Querying Templates- continued

If we use the XML schema to describe the template, should we include user interface "hints" that allow clients to intelligently decide whether to display values as (e.g.) a slider versus a knob versus a number that can be typed in?

Proposal: Yes - interface hints need to be included e.g. per current template draft:<control type ="boolean" name="mute" default="true" enable="true"/><control type="boolean" name="mute" default="false" enable="true"/>

Mailing List: concern that don't even know if the device has a screen or not (or a keyboard or not


Issue – DP4: XML Schema StructureThree options:

1. Template at the top level, with Common Conference Information as a subsection. Single schema Requires knowledge of a particular Template schema by the

client in order to retrieve any basic information Requires Navigation of the template to get to common

conference information.

2. Common Conference Information, at top level, contains template information. Clients don’t need to care about templates for basic

conferencing. Common Conference Information must include an extension

point, which complicates XML validation


Issue – DP4: XML Schema Structure - continued

3. Template and Common Conference Information are conveyed as two separate objects: Separate schema, straightforward validation and easy access

to either information Increases protocol complexity (e.g. multipart mime or separate

protocols)

Proposal: option 2 (Editors’ choice) or 3 (if WG prefers).


Issue – DP5: State and Policy Manipulation Protocol(s)

Option 1: Syntactic (i.e. basic operations, with variable and data provided upon invocation) Allows for extensions to data model without impacting protocol

More suitable for Conference Template since it’s intended to be extended.

Server generally has to infer intent from data content rather than via direct signalling Processing overhead Interpretation may result in interoperability issues Poorly suited for “compound operations” such as moving objects



Option 2: Semantic (i.e. explicit operations) Efficient Server Implementation Promise of better interoperability Extensions to the underlying data model require extensions to the

protocol used to manipulate it More suitable for Common Conference Information since this

information is easily scoped by a relatively small number of primitives Easily extensible under a common protocol infrastructure

Can define data manipulations (syntactic) primitives Can define opaque stimulus operations

Option 3: Both Appears to conflict with objective to have a single protocol. Note, however, that semantic can also support fundamental syntactic

model (for data manipulations)



Mailing List Discussion: Seemed to converge to the point that the differentiation is artificial

and doesn’t resolve anything. Consistent with the point that semantic model can also support

fundamental syntactic model (for data manipulations)

Proposal: Option 2, with the operations to support basic data manipulations (for syntactic operations).

Several protocols put forth: CPCP, CCCP, CSCP, Netconf To be discussed on Thursday.


Issues – Identified during WG review Section 4.1: text around Conference Instance mapping to multiple

conference objects seems confusing. Proposal: propose re-wording as later text (in section 5) makes the

concept more clear.

Figure 2: show Floors/floor control (as part of Conference Object Type).

Section 4.5: Data Access Rights seems very much like Common Conference Rules. Editors: we needed to keep the concept of conference policies. There is

no longer any central repository per se, but there is a need to have the read/write access rights associated with each object. Permissions are reflected by the simple list structure.

Does this need further discussion/clarification? Proposal: remove differentiation of layers and clearly describe

necessary functionality to support the fundamental access to the data objects and the allowed ranges of the data, list of clients, etc. Include note as to a more general “Rule” mechanism being out of scope and FFS.


Issues – Identified during WG review 6.4: Floor control section – needs additional work. [Note: current

text is attempting to align terminology/identifiers from BFCP with XCON FW identifiers]

6.4.1: User Identifier: new section is a bit out of context here details need resolution.

Section 7.1: example is really media manipulation (i.e. section 7.2)


Part 2 (Thursday, March 10th):

New work items Agreements/status of Discussion Points Summary of other open issues Additional Work items Way Forward


New work identified by FrameworkThe following items are identified as requiring further specification, in

other documents, based upon the current discussion and concepts introduced in the framework:

URI schema for Conference Object Identifier Mechanism/details for Data Access Rights and Conference

Control Limits and Permissions (i.e. “conference policies”) . Alternative proposal for Floor control based on templates? User Identifier (for Conferencing System) – introduced in section

6.4.1. new section is a bit out of context here details need resolution - perhaps documented with the URI schema

for Conference Object Identifier)

All these items require further discussion on the list.


Agreed work items/DP status

DP1: Referring to Sets of Meetings. Agreement: Should be inherently supportable with “cloning tree“

structure and iCal (i.e. should not impact current/planned iCal functionality).

Action: Need to ensure that there is a single “time” from which other times are derived (subject to system considerations).

DP2: Floor Control Model in terms of “Groups of RTP streams”?

Agreement: go forward based on mailing list feedback that grouping may not be necessary (i.e. can use a stream name specific to a “role”. )

Validate approach by working through further detailed flows, etc. with protocols (in section 7).


Agreed work items/DP status DP3: Querying templates

Agreements: Need the ability to query a server about a particular

template to retrieve a description, with 2 options: XML Schema - as in current templates draft. This then

supplies all relevant information that a client needs. “Blueprint”, per current FW, which includes a template

instantiation with customized values

Description is the same as the XML schema that is registered with IANA.


Agreed work items/DP status DP3: Querying templates (continued)

Agreements (continued): XCON server “advertises” what it supports to the

client; Client retrieves the template from the server itself (and NOT from some centralized repository) A client would need to query any templates that it doesn't

understand THEN make a decision on compatibility. Interface hints need to be included e.g. per current template

draft.


Agreed work items/DP status DP4: XML Schema Structure – 3 options

proposed:1. Option 1: Template at the top level, with Common

Conference Information as a subsection.

2. Option 2: Common Conference Information at top

3. Option 3: Template and Common Conference Information are conveyed as two separate objects

No agreement.

Action: Continue discussion on list.


DP5: State and Policy Manipulation Protocol(s) Mailing List Discussion seemed to converge to the point that the

differentiation between syntactic and semantic is artificial and doesn’t resolve anything

Proposal that “ semantic model” can also support fundamental syntactic model (for data manipulations)

Updates to reflect conclusions to current WG discussions on specific protocol proposals.

Agreed work items/DP status


Additional work to complete 6.4: Floor control section:

Current text is attempting to align terminology/identifiers from BFCP with XCON FW identifiers.

Needs additional work/cleanup Complete detail in section 7:

Including functionality such as sidebars, private messages, etc. Need additional scenarios/flows to highlight how the XCON

functional elements work together and more importantly how a UA interfaces to the elements to achieve the desired functionality.

One example currently in section 7.1 -> need feedback on this approach or alternatives). Mailing list: section 7.1 is really section 7.2 (media

manipulation). Add some full physical realization EXAMPLES with a mix of XCON

functions and existing protocols?


Way Forward

Plans are to update doc based on discussions thus far, meeting conclusions and any additional mailing list feedback.

Submit doc as WG document, planning at least one review cycle prior to Paris.

xcon framework overview & issues editors: mary barnes ( mary.barnes@nortelnetworks )

Documents