XCON Framework Overview & Issues Editors: Mary Barnes Chris Boulton

Slides:



Advertisements
Similar presentations
XCON Framework Overview & Issues Editors: Mary Barnes Chris Boulton
Advertisements

Status of Extensible SCCS-SM Concept Green Book 12 February
XCON Framework Overview & Issues Editors: Mary Barnes Chris Boulton
SIMPLE WG IETF-68 Meeting Centralized Conferencing (XCON) using the Message Session Relay Protocol (MSRP) draft-boulton-xcon-msrp-conferencing-04 Editors:
1 CPCP Hisham Khartabil XCON WG IETF 60, San Diego 2 nd August, 2004
OASIS Reference Model for Service Oriented Architecture 1.0
PAWN: A Novel Ingestion Workflow Technology for Digital Preservation
XCON architecture and protocol musings Henning Schulzrinne Columbia University.
Martin Dolly, Gary Munson AT&T Labs James Rafferty Cantata Roni Even Polycom draft-dolly-xcon-mediacntrlframe-03.txt draft-even-media-server-req-02.txt.
Membership and Media Management in Centralized Multimedia Conferences based on Internet Engineering Task Force Protocol Building Blocks Author: Ritu Mittal.
What is the problem we are solving? How a conference aware participant manipulates media streams at the mixer The client is a UA (in sip) The server is.
The chapter will address the following questions:
1 SIPREC Recording Metadata format (draft-ram-siprec-metadata-format- 01) IETF-80 SIPREC MEETING R Parthasarathi On behalf of the team Team: Paul Kyzivat,
1 RTCWEB interim Remote recording use case / requirements John Elwell.
XCON Working Group IETF 61 Washington, DC. The Normal Stuff NOTE WELL statement Minute Taker Jabber Scribe Blue Sheets.
S New Security Developments in DICOM Lawrence Tarbox, Ph.D Chair, DICOM WG 14 (Security) Siemens Corporate Research.
CLUE Framework Status and Issues IETF89 - London March 5, 2014 Mark Duckworth draft-ietf-clue-framework-14 1.
CLUE WG IETF-89 Mary Barnes (WG co-chair) Paul Kyzivat (WG co-chair)
XCON Framework Overview & Issues Editors: Mary Barnes Chris Boulton
CLUE Framework Issues CLUE virtual interim meeting Jan 27, 2014 Mark Duckworth draft-ietf-clue-framework-13 1.
MPTCP – MULTIPATH TCP Interim meeting #3 20 th October 2011 audio Yoshifumi Nishida Philip Eardley.
XCON WG IETF-73 Meeting Instant Messaging Sessions with a Centralized Conferencing (XCON) System draft-boulton-xcon-session-chat-02 Authors: Chris Boulton.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
XCON IETF 64 November 8 th – 9 th, 2005 Vancouver, BC, Canada.
XCON IETF 63 08/01/2005 Paris, France. Administrative Stuff Read “Note Well” statement (yellow sheet in your registration packet) Minutes Scribe Blue.
CLUE WG IETF-84 Mary Barnes (WG co-chair) Paul Kyzivat (WG co-chair)
1 SIPREC draft-ietf-siprec-architecture-00 An Architecture for Media Recording using SIP IETF SIPREC INTERIM – Sept 28 th 2010 Andrew Hutton.
Mediactrl Framework draft-melanchuk-mediactrl-framework-00 Tim Melanchuk
A Basic IVR Control Package for SIP Chris Boulton, Tim Melanchuk, Scott McGlashan draft-boulton-ivr-control-package-05 IETF 70 Vancouver, Canada.
1 SIPREC Recording Metadata for SRS (draft-ietf-siprec-metadata-03) July 28, 2011 IETF 81 meeting Ram Mohan R On behalf of the team Team: Paul Kyzivat,
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
SIP and SIPPING WGsMay, IETF Interim Meeting Orit levin Conferencing Requirements for SIP Based Applications.
Update on SIP Conferencing SIPPING WG IETF 59 Seoul, Korea March 3, 2004.
1 CPCP Open Issues Hisham Khartabil XCON WG Interim Meeting, Boston 26 th May, 2004
Slide #1 Boston, Jan 5 – 6, 2005XCON WG Interim draft-levin-xcon-cccp-01.txt By Orit Levin
Christian Groves Describing Captures in CLUE and relation to multipoint conferencing draft-groves-clue-multi-content-00 CLUE Interim meeting (09/13)
® A Proposed UML Profile For EXPRESS David Price Seattle ISO STEP Meeting October 2004.
1 SIPPING Working Group IETF 74 Dale Worley Martin Dolly Dan Petrie Profile Datasets draft-ietf-sipping-profile-datasets-03.
XCON BOF IETF 57 Vienna, Austria July 15, Administriva Conscripting a Scribe Note Well announcement (Read Section 10 of RFC 2026) Blue Sheets.
Media Control Policy Chris Boulton, Umesh Chandra, Roni Even, Cullen Jennings, Alan Johnston, Brian Rosen, Mark Trayer.
Page 1 IETF Speermint Working Group Speermint Requirements/Guidelines for SIP session peering draft-ietf-speermint-requirements-02 IETF 69 - Monday July.
May 9th 2011 IETF SIPREC INTERIM - draft-ietf-siprec-architecture 1 An Architecture for Media Recording using the Session Initiation Protocol draft-ietf-siprec-architecture.
Slide #1 Nov 6 – 11, 2005XCON WG IETF54 Conference Package Extensions draft-levin-xcon-conference-package-ext-00 by Orit Levin The Discussion Starter.
Software Requirements Specification Document (SRS)
A Framework for Session Initiation Protocol User Agent Profile Delivery (draft-ietf-sipping-config-framework-11) SIPPING – IETF 68 Mar 19, 2007 Sumanth.
Mixer Control Package for Media Control Channel Framework Tim Melanchuk, Scott McGlashan, Chris Boulton draft-ietf-mediactrl-mixer-control-package-00 IETF.
Doc.: IEEE /0147r0 Submission January 2012 Rolf de Vegt (Qualcomm)) Slide ai Spec Development Process Update Proposal Date:
1 CPCP Hisham Khartabil XCON WG IETF 59, Seoul
SIP Events: Changes and Open Issues IETF 50 / SIP Working Group Adam Roach
Fusion Design Overview Object Interaction Graph Visibility Graph Class Descriptions Inheritance Graphs Fusion: Design The overall goal of Design is to.
CLUE WG chair: Mary Barnes RTCWEB WG chair: Ted Hardie CLUE & RTCWEB WGs Adhoc Common (SDP/RTP) building blocks IETF-82.
SIPPING Drafts Jonathan Rosenberg dynamicsoft. Conferencing Package Issues Only one – scope Depends on broader work in conferencing May include –Participant.
XCON CCMP Call Flow Examples draft-barnes-xcon-examples-00 Authors: Mary Barnes Chris Boulton
Slide #1 Nov 7 – 12, 2004XCON WG IETF51 draft-levin-xcon-cccp-00.txt By Orit Levin
Copyright © 2007, Oracle. All rights reserved. Managing Items and Item Catalogs.
Conference Control Manipulation Protocol (CCMP) draft-ietf-xcon-ccmp-02.txt Authors: Mary Barnes Chris Boulton.
CLUE Framework 01 – comments and issues Interim meeting October 2011 Roni Even.
Draft-srinivasan-xcon-eventpkg- extension-01 IETF July 2007 Srivatsa Srinivasan Roni Even
CLUE Framework IETF 88 – Nov 8, 2013 Mark Duckworth draft-ietf-clue-framework-12 draft-groves-clue-multi-content-00 draft-duckworth-clue-switching-example-01.
SIPPING Working Group IETF 67 Mary Barnes Gonzalo Camarillo.
XCON WG IETF-64 Meeting Centralized Conferencing (XCON) using the Message Session Relay Protocol (MSRP) draft-boulton-xcon-msrp-conferencing-02 Editors:
Netconf Notifications Sharon Chisholm Hector Trevino IETF 67 November 2006.
CLUE WG Interim Meeting San Jose, CA Sept , 2012
XCON WG IETF-64 Meeting XCON Framework Overview & Issues
CLUE WG Interim Meeting San Jose, CA Sept , 2012
CLUE WG Interim Meeting San Jose, CA Sept , 2012
IETF 71 Philadelphia, PA, US
IETF 57 Vienna, Austria July 15, 2003
draft-levin-xcon-cccp-02.txt Orit Levin
STIR WG IETF-99 PASSPorT Extension for Resource-Priority Authorization (draft-ietf-stir-rph-00) July, 2017 Ray P. Singh, Martin Dolly, Subir Das, and An.
Presentation transcript:

XCON Framework Overview & Issues Editors: Mary Barnes Chris Boulton Orit Levin XCON WG Interim Meeting Boston, Jan 5-6th, 2005

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

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

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

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

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  ….

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?

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.

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.

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

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.

11 XCON Framework Jan 5-6th, 2005 Other Issues  Conf announcements and recordings  Sidebar  Whisper – not in scope?

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

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

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.

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.

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”  ….

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.

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

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

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)

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.

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 ?

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?

24 XCON Framework Jan 5-6th, 2005 Backup  Diagram SIP/XCON relationships

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