Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Conference Control Manipulation Protocol (CCMP) draft-ietf-xcon-ccmp-01.txt PowerPoint Presentation
Download Presentation
Conference Control Manipulation Protocol (CCMP) draft-ietf-xcon-ccmp-01.txt

Conference Control Manipulation Protocol (CCMP) draft-ietf-xcon-ccmp-01.txt

147 Views Download Presentation
Download Presentation

Conference Control Manipulation Protocol (CCMP) draft-ietf-xcon-ccmp-01.txt

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. 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 (mary.barnes@nortel.com) Chris Boulton (cboulton@avaya.com) Simon Pietro Romano(spromano@unina.it) Henning Schulzrinne (hgs+xcon@cs.columbia.edu)

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

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

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

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

  6. 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!

  7. CCMP Protocol overview & implementation Implementation Based on work of Simon Pietro Romano, et al (University of Napoli)

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

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

  10. CCMP in action: the meetecho* client *http://www.meetecho.com Send a confsRequest (with a “retrieve” operation) message to the conf server

  11. “confsRequest”  answer from server…

  12. Creating a new conference via blueprints

  13. “blueprintsRequest”  answer from server Send a blueprintRequest to the conf server

  14. “blueprintResponse” and creation through blueprint cloning blueprintResponse Prepare new conf object from blueprint SendconfRequest/create to the confserver…

  15. “confRequest”  creation and joining… Note well: no floor is currently available. Need to use BFCP for that…

  16. Active conferences (through notifications…)

  17. BFCP in action: • Setting the chair: • Asking for a floor: • Taking decisions:

  18. Enjoying a conference (1/2)

  19. Enjoying a conference (2/2)

  20. 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!

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

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

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

  24. 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 parallelwithprototypebringdetails back to XCON • Definepolicies and roles in a companiondocument

  25. 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?

  26. 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!!

  27. ANY COMMENTS/Questions?