xcon framework overview & issues editors: mary barnes ( mary.barnes@nortelnetworks )
DESCRIPTION
XCON WG Interim Meeting Boston, Jan 5-6th, 2005. XCON Framework Overview & Issues Editors: Mary Barnes ( [email protected] ) Chris Boulton ( [email protected] ) Orit Levin ( [email protected] ). Overview. Part 1 - Wednesday: - PowerPoint PPT PresentationTRANSCRIPT
XCON FrameworkOverview & Issues
Editors: Mary Barnes ([email protected]) Chris Boulton ([email protected]) Orit Levin ([email protected])
XCON WGInterim Meeting
Boston, Jan 5-6th, 2005
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
3 XCON Framework Jan 5-6th, 2005
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).
4 XCON Framework Jan 5-6th, 2005
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
5 XCON Framework Jan 5-6th, 2005
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
6 XCON Framework Jan 5-6th, 2005
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 ….
7 XCON Framework Jan 5-6th, 2005
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?
8 XCON Framework Jan 5-6th, 2005
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.
9 XCON Framework Jan 5-6th, 2005
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.
10 XCON Framework Jan 5-6th, 2005
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).
11 XCON Framework Jan 5-6th, 2005
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.
12 XCON Framework Jan 5-6th, 2005
Other Issues
Conf announcements and recordings
Sidebar
Whisper – not in scope?
13 XCON Framework Jan 5-6th, 2005
Part 2:
Updates based on meeting agreements
Additional Work items
Way Forward
14 XCON Framework Jan 5-6th, 2005
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
15 XCON Framework Jan 5-6th, 2005
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.
16 XCON Framework Jan 5-6th, 2005
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. 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.
17 XCON Framework Jan 5-6th, 2005
Issues – Terminology
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”
….
18 XCON Framework Jan 5-6th, 2005
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.
19 XCON Framework Jan 5-6th, 2005
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).
20 XCON Framework Jan 5-6th, 2005
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
21 XCON Framework Jan 5-6th, 2005
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)
22 XCON Framework Jan 5-6th, 2005
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.
23 XCON Framework Jan 5-6th, 2005
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 ?
24 XCON Framework Jan 5-6th, 2005
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?
25 XCON Framework Jan 5-6th, 2005
Backup
Diagram SIP/XCON relationships
26 XCON Framework Jan 5-6th, 2005
•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