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

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

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

5. Conference-Information Type INSTANCE INSTANCE INSTANCE (Type Conference-Info) RESERVATION (Type Conference-Info ) TEMPLATE (Type Conference-Info) R U L E S R U L E S R U L E S R U L E S R U L E S Conference Description Membership (Roles, Capacity, Names) Signaling (Protocol, Direction, Status) Sidebars (and other attributes) Audio Mix Pattern User Input Pattern Video Tiles Pattern Basic Data Objects Conference Definition, Creation, Lifetime

6. 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. 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. 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. 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. 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. 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. Other Issues • Conf announcements and recordings • Sidebar • Whisper – not in scope?

13. Part 2: • Updates based on meeting agreements • Additional Work items • Way Forward

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

15. INSTANCE INSTANCE INSTANCE (Type Conference-Info) RESERVATION (Type Conference-Info ) TEMPLATE (Type Conference-Info) R U L E S R U L E S R U L E S R U L E S R U L E S Basic Data Object Conference Definition, Creation, Lifetime Conference-Information Type Conference Description 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. Membership (Roles, Capacity, Names) Signaling (Protocol, Direction, Status) Sidebars (and other attributes) Conference Template

16. 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. 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. 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. 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. 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. 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. 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. 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. 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. Backup • Diagram SIP/XCON relationships

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