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

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

mailto:[email protected]





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


-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


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— …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


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)


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


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


CCMP in action: the meetecho* client

Send a confsRequest (with a “retrieve”

operation) message to the conf server

*http://www.meetecho.com


“confsRequest” answer from server…


Creating a new conference via blueprints


“blueprintsRequest” answer from server

Send a blueprintRequest to

the conf server


“blueprintResponse” and creation through blueprint cloning

blueprintResponse Prepare new conf object from blueprint

Send confRequest/create to the conf server…


“confRequest” creation and joining…

Note well: no floor is currently available. Need to use BFCP

for that…


Active conferences (through notifications…)


BFCP in action:Setting the chair:

Asking for a floor:

Taking decisions:


Enjoying a conference (1/2)


Enjoying a conference (2/2)


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!


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



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



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.



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



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?


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


ANY COMMENTS/Questions?

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

Documents

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