1. XCON Framework Overview & Issues Editors: Mary Barnes (mary.barnes@nortelnetworks.com)mary.barnes@nortelnetworks.com Chris Boulton (cboulton@ubiquity.net)cboulton@ubiquity.net Orit Levin (oritl@microsoft.com) XCON WG Interim Meeting Boston, Jan 5-6th, 2005

2. 1 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. 2 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. 3 XCON Framework Jan 5-6th, 2005 XCON System Decomposition Logical XCON Server Floor Control Client TEMPLATE Of the SYSTEM: Pre-configured Initial/Default values Conf Event Notification Server Focus CPCP Client CCCP Client CPCP Server CCCP Server Call Signaling Client TEMPLATE Policy: Of TYPE RULES RESERVATION Policy: Of TYPE RULES CURRENT Policy: Of TYPE RULES RESERVATION Of the INSTANCE: Of TYPE CONFERENCE-INFO STATE Of the CURRENT INSTANCE: Of TYPE CONFERENCE-INFO Notification Client Floor Control Server SIP/ PSTN/ H.323 T.120/ Etc. CCCP CPCP SIP NOTIFY/ Etc. BFCP Logical XCON Client

5. 4 XCON Framework Jan 5-6th, 2005 Basic Data Objects INSTANCE RULESRULES RULESRULES (Type Conference-Info) RULESRULES Conference-Information Type Conference Description Membership (Roles, Capacity, Names) Signaling (Protocol, Direction, Status) Sidebars (and other attributes) User Input Pattern Audio Mix Pattern Video Tiles Pattern Conference Definition, Creation, Lifetime TEMPLATE (Type Conference-Info) RULESRULES RESERVATION (Type Conference-Info ) RULESRULES

6. 5 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. 6 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. 7 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. 8 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. 9 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. 10 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. 11 XCON Framework Jan 5-6th, 2005 Other Issues  Conf announcements and recordings  Sidebar  Whisper – not in scope?

13. 12 XCON Framework Jan 5-6th, 2005 Part 2:  Updates based on meeting agreements  Additional Work items  Way Forward

14. 13 XCON Framework Jan 5-6th, 2005 XCON System Decomposition Conference System Floor Control Client TEMPLATE Of the SYSTEM: Pre-configured Initial/Default values Conf Event Notification Server Focus Call Signaling Client TEMPLATE Policy: RESERVATION Policy: CURRENT Policy: RESERVATION Of the INSTANCE: STATE Of the CURRENT INSTANCE: Notification Client Floor Control Server SIP/ PSTN/ H.323 T.120/ Etc. SIP NOTIFY/ Etc. BFCP Client Updated Logical names. Corrected “directionality”. Added logical grouping of data Conference-Object Data Manipulation Server Data Manipulation Client

15. 14 XCON Framework Jan 5-6th, 2005 Basic Data Object INSTANCE RULESRULES RULESRULES (Type Conference-Info) RULESRULES 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) RULESRULES RESERVATION (Type Conference-Info ) RULESRULES No changes Agreed. Generally, support the notion to “collapse” the objects into a single object (per logical grouping on previous chart; Authors feel there’s value in separation In understanding functionality.

16. 15 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. 16 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: “ client”  ….

18. 17 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. 18 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. 19 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. 20 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. 21 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. 22 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. 23 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. 24 XCON Framework Jan 5-6th, 2005 Backup  Diagram SIP/XCON relationships

26. 25 XCON Framework Jan 5-6th, 2005 State of Current Instance including: Members Media details Conf Policy Basic model Conf Aware Participant 1 Template: Pre-configured Initial/Default values Conf Notification Server Focus Conf Unaware Participant 3 Conf Unaware Participant 2 Conference Rules: Policy Privileges Allowed media CPCP Server Signaling I/F – not defined by XCON (e.g. SIP) Data I/F Signaling I/F - defined by XCON CCCP Server XCON DATA Conf State System Templates: Pre-configured System/mixer limits Templates supported Conference Rules: Policy Privileges Allowed media Conf Instantiation Applied during Conf Instantiation Updates During Conf Basic CONF FW Floor Control Server