conference control manipulation protocol (ccmp) draft-ietf-xcon-ccmp-01.txt

Post on 04-Jan-2016

43 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

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 ) - PowerPoint PPT Presentation

TRANSCRIPT

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)

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?

top related