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 WGInterim Meeting

Boston, Jan 5-6th, 2005

mailto:[email protected]

mailto:[email protected]

2 XCON Framework Jan 5-6th, 2005

Overview

Part 1 - Wednesday:

Current status of XCON framework document

Proposed Data Model

Issue Discussion

Part 2 - Thursday:

Updates based on meeting agreements

Way Forward


Current Framework Status

Total re-write from -00 version based on IETF-61 discussions.

Terminology and descriptions are protocol agnostic in terms of call control signaling.

Centers on Data Model (types and objects)

No duplication of content from SIPPING Conferencing Framework (section 8 intended to address relationship)

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).


XCON System DecompositionLogical XCON Server

Floor ControlClient

TEMPLATEOf the SYSTEM:•Pre-configured•Initial/Default values

Conf EventNotification Server

Focus

CPCP Client

CCCPClient

CPCPServer

CCCPServer

CallSignaling

Client

TEMPLATE Policy:•Of TYPE RULES

RESERVATION Policy:•Of TYPE RULES

CURRENT Policy:•Of TYPE RULES

RESERVATIONOf the INSTANCE:•Of TYPE CONFERENCE-INFO

STATEOf the CURRENT INSTANCE:•Of TYPE CONFERENCE-INFO

NotificationClient

FloorControl Server

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

CCCPCPCPSIP NOTIFY/Etc. BFCP

Logical XCON Client


Basic Data Objects

INSTANCE

RULES

INSTANCE

RULES

INSTANCE (Type Conference-Info)

RULES

Conference-Information Type

Conference Description

Membership (Roles, Capacity, Names)

Signaling (Protocol, Direction, Status)

Sidebars (and other attributes)

UserInput

Pattern

AudioMix

Pattern

VideoTiles

Pattern

Conference Definition, Creation, Lifetime

TEMPLATE (Type Conference-Info)

RULES

RESERVATION (Type Conference-Info )

RULES


Issues – Terminology

What do we call a Conference Specific Instance? “State” can be confusing because each of the conference objects has its own “state”

(not a conference instance only…) Proposal: Occurrence.

Mixing pattern - type defined to abstract the details of the media mixer. Pending the TEMPLATE issue resolution “Pattern” concept can be used not for mixing only, but also for abstracting other

advanced features, such as “user input pattern”, etc.

Focus - do we need a new (enhanced) definition for XCON?

Multimedia Stream Defined as the union of the set of media (in the context of FW) Keith L’s proposal that a stream shouldn’t consist of multiple media – propose to be

consistent with RTP. Proposal: be consistent with RTP or remove definition altogether as it’s only

referenced in the context of RTP and the use of the signaling interface to manipulate.

Define others and use consistently: XCON Server XCON client ….


Issue – Data model and Template

The current framework approach Conference Information Type is an umbrella for all conference

information Media pattern is a subtype (or set of subtypes), each registered

with IANA and used by the conference information type. (Note, issue raised over terminology “Mixing pattern”)

Template, reservation and instance are data objects - all of the same Conference Information type.

Brian’s alternative approach Template is the top type which includes all other possible

conference information XCON will define multiple templates and register each with IANA In order to create a reservation or a conference instance, an XCON

server needs to apply a separate set of ranges and policy rules to one of the standard template.xsd.

Proposal: To be discussed later today?


Issue – Recurring Conferences

Agreement on the need to be able to “schedule“ a conference. Need to tighten definitions of “reservation” and “state” supporting this

functionality

Need to introduce naming conventions

When the state (or the instance) begins – with the Focus creation.

Lack of agreement on the “recurrence” of a “scheduled” conference being in scope (i.e. it seems to be more of an application problem than XCON problem).

Proposal: Data structures and naming conventions should support the concept of a recurring/scheduled conference.

Proposal: The application mechanisms to cause the instantiation based on the “recurrence” are out of scope as for now.


Issue – Policy Rules

What is the format of the “rules” in XCON? XCON framework assumes that the common policy framework is

the basis for the “rules” in XCON.

What parts of CPCP XML schema remain and what need to be removed to support the XCON model? To be discussed later during separate discussion on Policy.


Issues – addt’l mailing list feedback How is a conference created?

Who/what does a client talk to?

How is reservation created?

Floor control: Suggestions that more detail is required.

Other suggestion that there is too much detail (perhaps due to needing more detail in other sections of section 5?).

Specific points: “input access” - > gain access to resources that are limited. Don’t necessarily need to be a participant to be floor chair

(however, participant doesn’t have to be involved in media mixing).


Issues – addt’l mailing list feedback Terminology:

General consistency and definition of terms for referring to Conference state, data, information, rules, etc.

XCON Server proposed as a general term to use consistently throughout

Conference Policy – more general, less data object centric definition

….

Section 8 – XCON relationship to SIPPING Conf FW: Should this be earlier in the document?

Needs to be completed (Diagram in backup charts needs refining).

Many other detailed points on consistency and clarifications needed.


Other Issues

Conf announcements and recordings

Sidebar

Whisper – not in scope?


Part 2:

Updates based on meeting agreements

Additional Work items

Way Forward


XCON System DecompositionConference System

Floor ControlClient

TEMPLATEOf the SYSTEM:•Pre-configured•Initial/Default values

Conf EventNotification Server

Focus

CallSignaling

Client

TEMPLATE Policy:

RESERVATION Policy:

CURRENT Policy:

RESERVATIONOf the INSTANCE:

STATEOf the CURRENT INSTANCE:

NotificationClient

FloorControl Server

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

SIP NOTIFY/Etc. BFCP

Client

Updated Logical names.Updated Logical names.Corrected “directionality”. Corrected “directionality”. Added logical grouping of dataAdded logical grouping of data

Conference-Object

DataManipulation

Server

DataManipulation

Client


Basic Data Object

INSTANCE

RULES

INSTANCE

RULES

INSTANCE (Type Conference-Info)

RULES

Conference-Information Type

Conference Description

Membership (Roles, Capacity, Names)

Signaling (Protocol, Direction, Status)

Sidebars (and other attributes)

Conference Template

Conference Definition, Creation, Lifetime

TEMPLATE (Type Conference-Info)

RULES

RESERVATION (Type Conference-Info )

RULES

No changes Agreed.No changes Agreed.Generally, support the notionGenerally, support the notionto “collapse” the objects into a single object to “collapse” the objects into a single object (per logical grouping on previous chart;(per logical grouping on previous chart;Authors feel there’s value in separation Authors feel there’s value in separation In understanding functionality. In understanding functionality.



What do we call a Conference Specific Instance? “State” can be confusing because each of the conference objects has its

own “state” (not a conference instance only…) Proposal: Occurrence. Conclusion: Conference Object.

Mixing pattern - type defined to abstract the details of the media mixer. “Pattern” concept can be used not for mixing only, but also for abstracting

other advanced features, such as “user input pattern”, etc. Conclusion: Subsumed by “Conference Template”

Focus - do we need a new (enhanced) definition for XCON? Conclusion: need a more general definition for XCON. Proposal: Focus: The focus is a call signaling endpoint that is addressed by a

unique conference identifier. The focus maintains a call signaling relationship with each participant in the conference. The focus ensures, in some way, that each participant receives the media that make up the conference. The focus also implements conference policies. The focus is a logical role.



Multimedia Stream Defined as the union of the set of media (in the context of FW)

Keith L’s proposal that a stream shouldn’t consist of multiple media – propose to be consistent with RTP.

Proposal: be consistent with RTP or remove definition altogether as it’s only referenced in the context of RTP and the use of the signaling interface to manipulate.

Conclusion: Agreement to remove definition until we actually reference.

Define others and use consistently: XCON Server Conclusion: Use general term:

“conferencing system”

XCON client Proposal: Use term: “<protocol> client”

….


Issue – Data model and Template

The current framework approach Conference Information Type is an umbrella for all conference

information Media pattern is a subtype (or set of subtypes), each registered

with IANA and used by the conference information type. (Note, issue raised over terminology “Mixing pattern”)

Template, reservation and instance are data objects - all of the same Conference Information type.

Brian’s alternative approach Template is the top type which includes all other possible

conference information XCON will define multiple templates and register each with IANA In order to create a reservation or a conference instance, an XCON

server needs to apply a separate set of ranges and policy rules to one of the standard template.xsd.

Conclusion: Concluded; check minutes.


Issue – Recurring Conferences

Agreement on the need to be able to “schedule” a conference. Need to tighten definitions of “reservation” and “state” supporting this

functionality

Need to introduce naming conventions

Conclusion: will need a reference (handle to instance) to an ical thing (eg. Time range)

When the state (or the instance) begins – with the Focus creation. Conclusion: Implementation issue

Lack of agreement on the “recurrence” of a “scheduled” conference being in scope (i.e. it seems to be more of an application problem than XCON problem).

Conclusion: ical object used to describe “time”.

Conclusion: ical proposed as the required mechanism to be referenced (i.e. XCON won’t define any ical extensions).


Issue – Policy Rules

What is the format of the “rules” in XCON? XCON framework assumes that the common policy framework is

the basis for the “rules” in XCON.

What parts of CPCP XML schema remain and what need to be removed to support the XCON model? To be discussed later during separate discussion on Policy.

Conclusion: Use ranges to control limits on values

Conclusion: Use list format described in minutes to control membership and permissions


Issues – addt’l mailing list feedback How is a conference created?

Who/what does a client talk to?

How is reservation created?

Conclusion: Need to add text to address this concept per earlier discussion

Floor control: Suggestions that more detail is required.

Other suggestion that there is too much detail (perhaps due to needing more detail in other sections of section 5?).

Specific points: “input access” - > gain access to resources that are limited. Don’t necessarily need to be a participant to be floor chair (however,

participant doesn’t have to be involved in media mixing).

Conclusion: ensure that the text is consistent with BFCP doc. Security aspects need to be addressed (e.g. nonce from CPCP)


Issues – addt’l mailing list feedback Terminology:

General consistency and definition of terms for referring to Conference state, data, information, rules, etc. Conclusion: Agree that changes are needed

Conferencing Server proposed as a general term to use consistently throughout (rather than XCON server, etc.)

• Conference Policy – more general, less data object centric definition. Proposal: Conference Policy: The complete set of rules for a particular

conference manipulated by a CPCP server. The conference policy is used to specify and control the operation of a conference occurrence, reservation and template.

Section 8 – XCON relationship to SIPPING Conf FW: Should this be earlier in the document? Needs to be completed (Diagram in backup charts needs refining). Conclusion: Complete the section and then decide whether it makes sense to

move earlier in the document. Conclusion: Agree that need some minimal introductory text to set the context

for the XCON FW (without duplicating functionality defined in SIPPING Conf FW).

Many other detailed points on consistency and clarifications needed.


Additional work items to incorporate

Need 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.

Add some full physical realization EXAMPLES with a mix of XCON functions and existing protocols ?


Way Forward

Plans are to update doc based on mailing list discussion thus far and meeting conclusions.

Is the general direction of the document sufficient to agree this as a WG document?


Backup

Diagram SIP/XCON relationships


•State of Current Instance including:

•Members •Media details

Conf Policy

Basic model

Conf AwareParticipant

1

Template:•Pre-configured•Initial/Default values

Conf Notification Server

Focus

Conf UnawareParticipant

3

Conf UnawareParticipant

2

Conference Rules:•Policy•Privileges•Allowed media

CPCPServer

Signaling I/F – not defined by XCON (e.g. SIP)Data I/FSignaling I/F - defined by XCON

CCCPServer

XCON DATA

Conf State

System Templates:•Pre-configured•System/mixer limits•Templates supported

Conference Rules:•Policy•Privileges•Allowed media

Conf Instantiation

Applied duringConf Instantiation

UpdatesDuringConf

Basic CONF FW

Floor ControlServer

XCON Framework Overview & Issues Editors: Mary Barnes ( mary.barnes@nortelnetworks )

Documents

Transcript of XCON Framework Overview & Issues Editors: Mary Barnes ( mary.barnes@nortelnetworks )