PowerPoint Presentation - Title Subtitle

1

XCON WG IETF-72 Meeting Dublin, Ireland, Tuesday,
July 29, 2008
Conference Control Manipulation Protocol
(CCMP) Authors Mary Barnes
(mary.barnes_at_nortel.com) Chris
Boulton (cboulton_at_avaya.com)
Henning Schulzrinne (hgsxcon_at_cs.columbia.edu)
Simon Pietro Romano
(spromano_at_unina.it)
2
Contents

• Status
• Changes
• Overview of Protocol Implementation
• Issue Discussion
• Way Forward
• Comments/Questions

3
Status

• Foundation for protocol development is complete
  with publication of XCON Framework
• XCON Data model almost done
• CCMP protocol document agreed as WG document at
  IETF-71
• Lots of Protocol details filled in for WG -00
  based on agreement for semantic approach
• Purpose built protocol based on SOAP
• Using discrete methods and operations

4
Major changes since individual -04 version

• Added LOTS more detail for general description of
  Protocol Operations, including related response
  handling
• Updated Protocol Operations on conference objects
  section
• Defined more discrete messages for specific data
  element manipulations per IETF-71 feedback
• Described specific operations that apply to each
  message type
• e.g., userRequest (create) versus userRequest
  (change)
• Updated XML schema

5
CCMP Protocol overview implementation

• Implementation Based on work of Simon Pietro
  Romano, et al
• (University of Napoli)

6
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
7
Basic Data Objects
Conference Definition, Creation, Lifetime
Conference-Information Type

• CONFERENCE BLUEPRINT
• (Type Conference-Info)
• Pre-configured
• Initial/Default values

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
8
The protocol
9
Requests Responses
10
The abstract ccmp-request-message-type...
ltxscomplexType abstract"true"
name"ccmp-request-message-type"gt
ltxssequencegt ltxselement
name"requestID" type"xsstring"
minOccurs"1" maxOccurs"1" /gt
ltxselement name"confObjID" type"xsstring"
minOccurs"0" maxOccurs"1" /gt
ltxselement name"confUserID" type"xsstring"
minOccurs"0" maxOccurs"1" /gt
lt/xssequencegt
lt/xscomplexTypegt
11
...and its extensions
ltxscomplexType name"ccmp-options-request-mess
age-type"gt ltxscomplexContentgt
ltxsextension base"tnsccmp-request-message-type
"/gt lt/xscomplexContentgt
lt/xscomplexTypegt
ltxscomplexType name"ccmp-conf-request-me
ssage-type"gt ltxscomplexContentgt
ltxsextension base"tnsccmp-request-message-typ
e"gt ltxssequencegt
ltxselement ref"confRequest" /gt
lt/xssequencegt lt/xsextensiongt
lt/xscomplexContentgt lt/xscomplexTypegt
12
An example confRequestType
ltxselement name"confRequest"
type"confRequestType" /gt
ltxscomplexType name"confRequestType"gt
ltxssequencegt ltxselement
name"operation" type"operationType"
minOccurs"1" maxOccurs"1" /gt
ltxselement name"confInfo" type"xsstring"
minOccurs"0"/gt
lt/xssequencegt lt/xscomplexTypegt
13
The CCMP prototype
14
CCMP operations optionsRequest
15
optionsResponse
16
SOAP messages optionsRequest
17
SOAP messages optionsResponse
18
CCMP operations confRequest
19
confRequest retrieve (1/3)?
20
confRequest retrieve (2/3)?
21
confRequest retrieve (3/3)?
22
SOAP messages confRequest
23
SOAP messages confResponse
24
Errors e.g. trying to retrieve a non-existing
object
25
Error response
26
SOAP error message
27
ConfRequest create
28
ConfRequest create options

• new object from file
• new object from text area
• new object by cloning
• an existing object
• the default conference object

29
Create by cloning an existing object (1/2)?
30
Create by cloning an existing object (2/2)?
31
SOAP messages request
32
SOAP messages response
33
UserRequest messages

• Retrieve collect user's information
• Create add a new user, not necessarily
  associated with a conference
• Change modify user's information, e.g. add the
  user to an existing conference
• Delete remove user from the conferencing system

34
usersRequest

• Operations
• Retrieve
• Change
• Delete

35
sidebarRequest

• Operations
• Retrieve
• Change
• Delete

36
Open issues (1/6)? XSD for Data Model

• We need to use the data model inside CCMP
• Currently, no xsd schema is available for it
• Relax-ng is OK
• relaxer tool works quite fine
• Embedded utilities for object database management
  
• .. but
• automated tools (e.g. Eclipse plugins for Java
  programmers) work well with schemas
• Automatic generation of objects starting from the
  schema
• Just need the wsdl (service description) and the
  xsd (data structures i.e. Protocol messages and
  data model) to get for free a complete stub of
  the overall system...
• Proposal Update data model with xsd schema -gt
  appendix (NOT a replacement for Relax-NG)

37
Open issues (2/6)? New data elements

• Additional data required in data model
• Data element(s) for parent and child information
  support key supporting key framework concepts
• Cloning
• Manipulating conference data
• - i.e., for a non-independent child, changes to
  the parent impact the child
• ConfObjId element in a create request
  signifies a parental conference object In fact we
  should probably have a table showing where
  headers can exist in the formal definition).
• Proposal Update data model for this element(s)
• Clarify text in document

38
Open issues (3/6) Additional Discrete operations

• Currently, only discrete element within user
  element for which weve 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

39
Open issues (4/6)? Completing protocol

• 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

40
Open issues (5/6)? Policies/Access Control

• 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 - gt bring details back to XCON IF it
  works well with minimal/no impact on protocol
  (i.e., this would be an optional aspect for
  systems to support)

41
Open issues (6/6)? Notification Mechanism

• Need to manage notifications
• Should we go for a web friendly solution based on
  WS-N (Web Services Notification)?
• Can we allow for alternative approaches?
• XMPP (à la CONFIANCE in its distributed version)?
• Plain sockets (with asynchronous
  notifications...)?
• Third-party proprietary approaches
• AMI (Asterisk Manager Interface)?
• Like in CONFIANCE...
• Proposal work on notification mechanism in
  parallel with prototype - gt bring details back to
  XCON IF it works well with minimal/no impact on
  protocol (i.e., this would be an optional aspect
  for systems to support in particular for
  clients not supporting SIP)

42
Way Forward

• Document to be updated with new XML schema and
  WSDL based on prototype experiences of Simon,
  Lorenzo, et al (University of Napoli)
• Note demo at the end of this session.
• Move forward based on Issue resolution
• Continue evolving protocol and prototype
• Solicit additional feedback from WG and potential
  developer community

43

• ANY COMMENTS/Questions?