1 / 27

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

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@a vaya.com )

mareo
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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?

More Related