Conference Control Manipulation Protocol
(CCMP)draft-ietf-xcon-ccmp-01.txt
Authors: Mary Barnes ([email protected]) Chris Boulton ([email protected])
Simon Pietro Romano ([email protected]) Henning Schulzrinne ([email protected])
XCON WGIETF-73 Meeting
Minneapolis, Minnesota, Thursday November 20, 2008
2 XCON Protocol: CCMP November 20, 2008
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
Agenda
3 XCON Protocol: CCMP November 20, 2008
-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
Recent CCMP history
4 XCON Protocol: CCMP November 20, 2008
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 XCON Protocol: CCMP November 20, 2008
…so now
CCMP is no more based on SOAP/WS— …we believe the CCMP perfectly fits the REST approach!
Version -01 proposes to adopt REST— Even though the protocol specification is kept independent of the
chosen transport protocol
Resources are associated with URIs
Provides means to:— Access information:
– Active/scheduled conferences– Blueprints– Conference users
— Manipulate Conference Objects– Creation, updating, deletion
6 XCON Protocol: CCMP November 20, 2008
CCMP-managed Resources
Conference Object:— compliant with the XCON data model— uniquely addressable through an XCON URI
Blueprints:— same as conference objects…
Users:— a set of <user> elements— part of a conference object, currently not directly addressable ()
User:— a single <user> element— can exist independently of a Conference Object— directly addressable through the XCON-USERID
– Must be a valid URI with the RESTful approach!
CCMP Protocol overview & implementation
Implementation Based on work of Implementation Based on work of Simon Pietro Romano, et al Simon Pietro Romano, et al
(University of Napoli)(University of Napoli)
8 XCON Protocol: CCMP November 20, 2008
XCON System Decomposition
Logical XCON Server
Floor ControlClient
CONFERENCE BLUEPRINT:•Pre-configured•Initial/Default values
Conf EventNotification Server
Focus
Conference &Media Control
Client
CCMPServer
CallSignaling
Client
ACTIVE Conference:•Of TYPE CONFERENCE-INFO
NotificationClient
FloorControl Server
SIP/PSTN/H.323T.120/Etc.
CCMPSIP NOTIFY/Etc. BFCP
CONFERENCERESERVATION:•Of TYPE CONFERENCE-INFO
Logical XCON Client
ACTIVE Conference:•Of TYPE CONFERENCE-INFO
CONFERENCERESERVATION:•Of TYPE CONFERENCE-INFOCONFERENCE BLUEPRINT:
•Pre-configured•Initial/Default values
9 XCON Protocol: CCMP November 20, 2008
Basic Data Objects
INSTANCE ACTIVE CONFERENCE (Type Conference-Info)
Conference-Information Type
Conference-description
conf-URIs, service-URIs, max-user-count, available-media
conference-state
sidebars-by-ref, sidebars-by-val
Conference Definition, Creation, Lifetime CONFERENCE BLUEPRINT
(Type Conference-Info) • Pre-configured
• Initial/Default values
RESERVATION (Type Conference-Info )
floor-information
Users: allowed-users-list, user, roles…
media-type, mixer-type
10 XCON Protocol: CCMP November 20, 2008
CCMP in action: the meetecho* client
Send a confsRequest (with a “retrieve”
operation) message to the conf server
*http://www.meetecho.com
11 XCON Protocol: CCMP November 20, 2008
“confsRequest” answer from server…
12 XCON Protocol: CCMP November 20, 2008
Creating a new conference via blueprints
13 XCON Protocol: CCMP November 20, 2008
“blueprintsRequest” answer from server
Send a blueprintRequest to
the conf server
14 XCON Protocol: CCMP November 20, 2008
“blueprintResponse” and creation through blueprint cloning
blueprintResponse Prepare new conf object from blueprint
Send confRequest/create to the conf server…
15 XCON Protocol: CCMP November 20, 2008
“confRequest” creation and joining…
Note well: no floor is currently available. Need to use BFCP
for that…
16 XCON Protocol: CCMP November 20, 2008
Active conferences (through notifications…)
17 XCON Protocol: CCMP November 20, 2008
BFCP in action:Setting the chair:
Asking for a floor:
Taking decisions:
18 XCON Protocol: CCMP November 20, 2008
Enjoying a conference (1/2)
19 XCON Protocol: CCMP November 20, 2008
Enjoying a conference (2/2)
20 XCON Protocol: CCMP November 20, 2008
Solved issues since IETF 72XSD 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 XCON Protocol: CCMP November 20, 2008
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 XCON Protocol: CCMP November 20, 2008
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 XCON Protocol: CCMP November 20, 2008
Open issues as per IETF 72 (3/5)
The (new version of the) protocol works fine..
..but work is still needed in order to:—complete its specification;
—add table to show which headers apply to which messages, in terms of mandatory versus optional, etc.;
—work call flows in parallel to validate protocol and to provide input to prototype.
24 XCON Protocol: CCMP November 20, 2008
Open issues as per IETF 72 (4/5)
Define a Role Based Access Control (RBAC) system to manage access policies to the system:
—Which users can access/modify/create objects in the system?
—Which fields of a conferencing object should be made available to which users?
Can XACML do the job?
Can the RBAC system be realized as a 100% independent component of the overall framework?
Proposal:—work on RBAC system in parallel with prototype bring details
back to XCON
—Define policies and roles in a companion document
25 XCON Protocol: CCMP November 20, 2008
Open issues as per IETF 72 (5/5)
We need to manage notifications!
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 its distributed version)— Plain sockets (with asynchronous notifications...)— …more?
26 XCON Protocol: CCMP November 20, 2008
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 XCON Protocol: CCMP November 20, 2008
ANY COMMENTS/Questions?