270 likes | 418 Views
XCON WG IETF-73 Meeting Minneapolis, Minnesota, Thursday November 20, 2008. Conference Control Manipulation Protocol (CCMP) draft-ietf-xcon-ccmp-01.txt Authors: Mary Barnes ( email@example.com ) Chris Boulton ( cboulton@a vaya.com )
E N D
XCON WG IETF-73 Meeting Minneapolis, Minnesota, Thursday November 20, 2008 Conference Control Manipulation Protocol (CCMP) draft-ietf-xcon-ccmp-01.txt Authors: Mary Barnes (firstname.lastname@example.org) Chris Boulton (email@example.com) Simon Pietro Romano(firstname.lastname@example.org) Henning Schulzrinne (email@example.com)
Agenda • A brief reminder of the most recent history of the CCMP • Changes since -00 version • Overview of Protocol & Implementation • Issue Discussion • Way Forward • Comments/Questions
Recent CCMP history • -00 version of the draft (@ Dublin 72): • Baseline protocol specification based on agreement for semantic approach: • CCMP was based on Web Services and SOAP • CCMP made use of discrete methods and operations • Prototype implementation available from University of Napoli: • Used as a proof-of-concept both for protocol specification and for its actual exploitation in real-world conferencing scenarios • Demo at IETF 72
The REST breakthrough… • At IETF 72, folks started to advertise a “brand-new” () protocol: • Let’s all go to REST! • REpresentational State Transfer: • CRUD approach: • Create (e.g. HTTP POST) • Read(e.g. HTTP GET) • Update (e.g. HTTP PUT) • Delete(e.g. HTTP DELETE)
…so now • CCMP is no more based on SOAP/WS • …webelieve the CCMP perfectlyfits the REST approach! • Version -01 proposestoadopt REST • Eventhough the protocolspecificationiskeptindependentof the chosentransportprotocol • Resources are associatedwithURIs • Providesmeansto: • Access information: • Active/scheduledconferences • Blueprints • Conferenceusers • ManipulateConferenceObjects • Creation, updating, deletion
CCMP-managed Resources • ConferenceObject: • compliantwith the XCON data model • uniquelyaddressablethroughan XCON URI • Blueprints: • sameasconferenceobjects… • Users: • a set of <user> elements • part of a conferenceobject, currentlynotdirectlyaddressable () • User: • a single <user> element • can existindependentlyof a ConferenceObject • directlyaddressablethrough the XCON-USERID • Mustbe a valid URI with the RESTfulapproach!
CCMP Protocol overview & implementation Implementation Based on work of Simon Pietro Romano, et al (University of Napoli)
XCON System Decomposition Logical XCON Server • CONFERENCE • RESERVATION: • Of TYPE CONFERENCE-INFO • CONFERENCE • RESERVATION: • Of TYPE CONFERENCE-INFO • CONFERENCE BLUEPRINT: • Pre-configured • Initial/Default values • CONFERENCE BLUEPRINT: • Pre-configured • Initial/Default values • ACTIVE Conference: • Of TYPE CONFERENCE-INFO • ACTIVE Conference: • Of TYPE CONFERENCE-INFO CCMP Server • Conf Event • Notification • Server • Floor • Control • Server Focus SIP/ PSTN/ H.323 T.120/ Etc. SIP NOTIFY/ Etc. CCMP BFCP Conference & Media Control Client Notification Client Floor Control Client Call Signaling Client Logical XCON Client
Basic Data Objects Conference Definition, Creation, Lifetime • CONFERENCE BLUEPRINT • (Type Conference-Info) • Pre-configured • Initial/Default values Conference-Information Type Conference-description Users: allowed-users-list, user, roles… conf-URIs, service-URIs, max-user-count, available-media RESERVATION (Type Conference-Info ) conference-state media-type, mixer-type INSTANCE floor-information ACTIVE CONFERENCE (Type Conference-Info) sidebars-by-ref, sidebars-by-val
CCMP in action: the meetecho* client *http://www.meetecho.com Send a confsRequest (with a “retrieve” operation) message to the conf server
“blueprintsRequest” answer from server Send a blueprintRequest to the conf server
“blueprintResponse” and creation through blueprint cloning blueprintResponse Prepare new conf object from blueprint SendconfRequest/create to the confserver…
“confRequest” creation and joining… Note well: no floor is currently available. Need to use BFCP for that…
BFCP in action: • Setting the chair: • Asking for a floor: • Taking decisions:
Solved issues since IETF 72 • XSD for Data Model: • The data model draft has been updated with xsd schema: • Appendix B. Non-Normative W3C XML Schema • Thanks to the authors for that!
Open issues as per IETF 72 (1/5) • Additional data required in data model: • Data element(s) for parent and child information supporting key framework concepts: • Cloning • Manipulating conference data: • for a “non-independent” child, changes to the parent impact the child • ‘ConfObjId’ element in a ‘create’ request signifies a parental conference object • Proposal: Update data model for this element(s) • Clarify text in document
Open issues as per IETF 72 (2/5) • Currently, only discrete element within <conference-info> element for which we’ve defined a request/response type is the <users> element • Should we define additional methods/messages such as allowed-users-list, deny-users-list, join-handling, etc.? • If so, which (or all)? • Proposal: • add those that facilitate use cases/call flows
Open issues as per IETF 72 (3/5) • The (newversionof the) protocolworks fine.. • ..but work isstillneeded in orderto: • complete itsspecification; • addtableto show whichheadersapplytowhichmessages, in termsofmandatory versus optional, etc.; • work callflows in parallelto validate protocol and toprovide input toprototype.
Open issues as per IETF 72 (4/5) • Define a RoleBased Access Control (RBAC) system tomanageaccesspoliciesto the system: • Whichusers can access/modify/create objects in the system? • Whichfieldsof a conferencingobjectshouldbemadeavailabletowhichusers? • Can XACML do the job? • Can the RBAC system berealizedas a 100% independentcomponentof the overallframework? • Proposal: • work on RBAC system in parallelwithprototypebringdetails back to XCON • Definepolicies and roles in a companiondocument
Open issues as per IETF 72 (5/5) • Weneedtomanagenotifications! • Options: • stick to SIP notification • HTTP "call back” • the CCMP client provides the conference server with an HTTP URL which is invoked when a change occurs • both of the above models appropriately combined? • PC-based clients behind NATs provide a SIP event URI • web servers would probably find the HTTP model much easier to program with • BOSH (http://xmpp.org/extensions/xep-0124.html)? • "...a transport protocol that emulates a bidirectional stream between two entities (such as a client and a server) by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of polling or asynchronous chunking.“ • Also discussed at the BLISS meeting… • XMPP (à la CONFIANCE in itsdistributedversion) • Plainsockets (withasynchronousnotifications...) • …more?
Way Forward • Move forward based on Issue resolution • Continue evolving protocol and prototype • Solicit additional feedback from WG and potential developer community • Please...READ THE DOCUMENT AND PROVIDE FEEDBACK!!