[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04                                                
XCON                                                            O. Levin
Internet-Draft                                                 G. Kimchi
Expires: April 18, 2005                            Microsoft Corporation
                                                        October 18, 2004



             Centralized Conference Control Protocol (CCCP)
                        draft-levin-xcon-cccp-00


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on April 18, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   This document defines a new client-server Centralized Conferencing
   Control Protocol (CCCP) for manipulating a conference behavior by
   either a conference participant or otherwise authorized entity that
   implements a CCCP client.  By implementing a CCCP server, a
   conference focus provides a means for its clients to control the
   conference policy and the state of the focus and other participants
   in the conference.




Levin & Kimchi           Expires April 18, 2005                 [Page 1]


Internet-Draft                    CCCP                      October 2004



Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Data Model . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1   Relationships between Membership and Media Information . .  5
     4.2   Conference Policy  . . . . . . . . . . . . . . . . . . . .  6
     4.3   Conference State . . . . . . . . . . . . . . . . . . . . .  6
     4.4   Policy and State Dependencies  . . . . . . . . . . . . . .  7
   5.  The Protocol . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1   The Transaction Model  . . . . . . . . . . . . . . . . . .  7
     5.2   XML  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.3   Example  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 11
   9.2   Informative References . . . . . . . . . . . . . . . . . . . 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property and Copyright Statements . . . . . . . . 13






























Levin & Kimchi           Expires April 18, 2005                 [Page 2]


Internet-Draft                    CCCP                      October 2004



1.  Introduction


   General centralized conferencing architecture is described in the
   SIPPING Conference Framework [5].  The XCON Conference Framework
   [4] extends and expands upon the SIPPING conference framework
   architecture to provide a protocol agnostic centralized conferencing
   system, defining how it maps into the XCON entities and protocols and
   providing a related data model.  The framework documents define the
   concept of a conference policy and a conference state as the data
   model for representing all the information about a particular
   conference instance.


   This document defines the protocol for manipulation of this data
   model (both the policy and the state of a particular conference) in a
   system built according to the XCON architecture.


   This document extends the conference state information (defined in
   the SIPPING Conference Package [2]) to be reused as the data model
   for CCCP.


2.  Terminology


   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [1] and indicate requirement levels for
   compliant implementations.


3.  Background


   Today XCON defines a policy XML schema [8], and relies on data
   manipulation of the policy document to indirectly influence the
   conference state.  The policy updates can be done anytime, before or
   during a conference.


   CCCP approach doesnt preclude the use of CPCP for the manipulation
   of the data outside an "active" conference instance.  Conference
   policy changes may also need to be made during a conference, but they
   are likely to be much less frequent than conference state changes.
   Consequently, this document recognizes that during a conference, the
   most common conference control operations involve conference state
   rather than policy and lays out an architectural approach in which
   the control interface directly operates on the conference state
   providing the required expedient effect.


   The XCAP Usage for Conference Policy Manipulation [8] approach has no
   application semantics and requires a document locking property.
   Consequently, only one user can edit the policy document (or any




Levin & Kimchi           Expires April 18, 2005                 [Page 3]


Internet-Draft                    CCCP                      October 2004



   other shared XML document) at a time.


   In comparison, the CCCP approach defines a set of semantics (add,
   get, set, delete, remove) that operate directly on the conference
   state elements (as provided to the subscribed users in the SIPPING
   Conference Package [2] notifications).  CCCP requests are submitted
   to the focus and can be prioritized and queued, or even interleaved
   based on requester's role and the affected XML element(s)
   correspondingly.  No single lock per document is required, and the
   CCCP server implemented in the focus, can locally decide on its
   optimization strategy without relying on any special CCCP clients
   behavior.


4.  Data Model


   EDITOR's NOTE: It is suggested that this section will be incorporated
   into the XCON Framework document.


   The Figure 1 below depicts a Conference Server logical decomposition
   with an example of SIP mechanisms (SIP Call Control "1st-party"
   signaling and SUBSCRIBE/NOTIFY as a notification means) in
   conjunction with the CCCP (as a "3rd-party" control protocol for
   manipulation of conferencing policy and state) being used to
   communicate with external entities.




























Levin & Kimchi           Expires April 18, 2005                 [Page 4]


Internet-Draft                    CCCP                      October 2004



     +-----------------------------+    +------------------------------+
     |        P O L I C Y          |    |          S T A T E           |
     |                             |    |                              |
     | Conference Templates        |===>| Current Media Modes & Mixers |
     | Allowed Membership          |    | Current Membership           |
     | Required Media Resources    |    | Current Participants' Media  |
     | Etc.                        |    | Etc.                         |
     +-----------------------------+    +------------------------------+
           ^                             ^ ^                |
           |                             | |                |
           |  |--------------------------| |                |
           |  |                            |                |
           |  |     .......................|...........     |
           |  |     .                      |          .     v
     +----------------+    +----------------+    +-----------------------+
     |   CCCP Server  |....|   F O C U S    |    |  Notification Server  |
     +----------------+    +----------------+    +-----------------------+
             ^                      ^                       |
             |                      |                       |
             |                      |                       |
             |                      v                       v
     +----------------+    +----------------+    +-----------------------+
     |     CCCP       |    |SIP CC Signaling|    |    SUBSCRIBE/NOTIFY   |
     +----------------+    +----------------+    +-----------------------+


     Figure 1: Conference Server logical decomposition.





4.1  Relationships between Membership and Media Information


   All the information about a particular conference can be modeled as
   two main pieces of data: the conference policy and the conference
   state.


   In the data model defined in this document there is no strict
   separation between "the conference (i.e.  membership and signaling)
   data model" and "the media data model".  In other words, policy
   related to media is a part of the overall conference policy and state
   information about media is a part of the overall conference state.
   This meets the requirement in many conference control operations to
   enable synchronized access to the conference policy as a whole, the
   conference state as a whole, and for getting notifications about
   changes in any of them as a whole.


   The concept of a "template" is discussed in XCON Media Control [9] in
   strictly media terms.  However, a conference template can be thought




Levin & Kimchi           Expires April 18, 2005                 [Page 5]


Internet-Draft                    CCCP                      October 2004



   of as "pre-state" belonging to a conference policy.  It contains just
   enough information to define what the initial state of the conference
   will be when it is created.  While the conference state will be
   highly dynamic, the conference template (as a part of the larger
   conference policy) is likely to be relatively static.


   Today, the template contains basic information about the conference
   mixing capabilities, the conference media controls, sliders, radio
   boxes, etc.  but also the participant's roles, which is more general
   than just media-related.


   On the other hand, the XCON Media Control [9] document uses "Media
   Policy" terminology when referring to the concept called in this
   document the "Conference State".


   In conclusion, for advanced conference manipulations (e.g.  media
   layouts) extensions to both the policy (e.g.  to templates) and the
   state schemas will be needed.  Additionally, CCCP may need to be
   extended for manipulating the policy schema with its templates.


4.2  Conference Policy


   Conference policy is a set of parameters and rules (e.g.  maximum
   number of participants, needs chair-person supervision or not,
   password protected or not, duration, a way of media mixing, etc.)
   that are defined at the onset of a conference and MAY be modified
   during the conference.


   The Conference policy would typically be derived from the system's
   default template or templates.  On a particular conference onset, the
   default parameters and rules can be overridden and/or expanded.  The
   XCON CPCP [7] contains an example of a conference policy schema.


4.3  Conference State


   Conference state is the set of information describing the conference
   in progress.  This includes participants' information (such as dialog
   identifiers), media sessions in progress, the current loudest
   speaker, the current chair, etc.  The basic XML schema is defined the
   SIPPING Conference Package [2].


   CPCP is used to directly affect the conference state and expands it
   for this purpose.  Changes in the conference state also occur as a
   result of participants' state changes and learned by the focus
   through the call signaling channel with each of the participants.


   Changes in the conference state are reported to conferencing
   participants and otherwise authorized party using well-defined event




Levin & Kimchi           Expires April 18, 2005                 [Page 6]


Internet-Draft                    CCCP                      October 2004



   mechanisms subject to each interested party privileges.  For example,
   for SIP entities it is the Event Notification mechanism defined in
   RFC 3265 [1].


4.4  Policy and State Dependencies


   Changes in the Conference Policy can automatically cause changes in
   the Conference State, while changes in the conference state never
   change conference policy.


   There are many examples of how a change in conference policy can
   change the state - changing the end time of a conference causes the
   conference to end early, reducing the maximum number of participants
   could cause some to be booted.


   A change in conference state never changes the conference policy
   because by definition the conference policy must authorize any change
   in state.  If a request fails due to a policy, this will be indicated
   in the response reason.  The user may then attempt to change the
   policy, and then retry the state change request.


   For example, a user may request a participant to be added to a
   conference.  The focus must check the policy to see if the user's
   role and/or URI allow the user to participate in the conference.  For
   example, the policy might say that only members of example.com may
   join the conference.


5.  The Protocol


5.1  The Transaction Model


   CCCP is defined as a set of transactions issued over a reliable
   transport protocol.  A transaction consists of a Request carrying the
   required information in an XML body and a corresponding Response
   carrying an appropriate XML body.


   EDITOR's NOTE: TBD the requirements from the transport protocols
   fitting CCCP.


5.2  XML


   This document expands the XML schema defined in SIPPING Conference
   Package [2] as defined in this section below.



   <!--
   CONFERENCE REQUEST ELEMENT
   -->




Levin & Kimchi           Expires April 18, 2005                 [Page 7]


Internet-Draft                    CCCP                      October 2004



   <xs:element name="conference-request" type="conference-request-type


   <!--
   CONFERENCE RESPONSE ELEMENT
   -->
   <xs:element name="conference-response" type="conference-response-type"/>


   <!--
   CONFERENCE REQUEST TYPE
   -->
        <xs:complexType name="conference-request-type">
                <xs:sequence>
                  <xs:element name="content" type="conference-type"/>
                  <xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:attribute name="request-id" type="xs:string"/>
                <xs:anyAttribute/>
        </xs:complexType>


   <!--
   CONFERENCE RESPONSE TYPE
   -->
        <xs:complexType name="conference-response-type">
                <xs:sequence>
                  <xs:element name="content" type="conference-type" minOccurs="0"/>
                  <xs:element name="status" type="response-status-type"/>
                  <xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:attribute name="request-id" type="xs:string"/>
                <xs:anyAttribute/>
        </xs:complexType>


   <!--
   RESPONSE STATUS TYPE
   -->
        <xs:complexType name="response-status-type">
                <xs:sequence>
                  <xs:element name="code" type="response-code-type"/>
                  <xs:element name="reason" type="xs:string" minOccurs="0" />
                  <xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:anyAttribute/>
        </xs:complexType>


        <!--
        RESPONSE CODE TYPE
        -->
        <xs:simpleType name="response-code-type">


Levin & Kimchi           Expires April 18, 2005                 [Page 8]


Internet-Draft                    CCCP                      October 2004



                <xs:restriction base="xs:string">
                  <xs:enumeration value="success"/>
                  <xs:enumeration value="pending"/>
                  <xs:enumeration value="failure"/>
                </xs:restriction>
        </xs:simpleType>


        <!--
        OPERATOR TYPE
        -->
        <xs:complexType name="operator-type">
                <xs:sequence>
                  <xs:element name="code" type="operator-code-type"/>
                  <xs:element name="to-entity" type="xs:string" minOccurs="0" />
                  <xs:element name="from-entity" type="xs:string" minOccurs="0" />                        <xs:element name="extended" type="extended-type" minOccurs="0" maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:anyAttribute/>
        </xs:complexType>


                <!--
        OPERATOR CODE TYPE
        -->
        <xs:simpleType name="operator-code-type">
                <xs:restriction base="xs:string">
                  <xs:enumeration value="remove"/>
                  <xs:enumeration value="add"/>
                  <xs:enumeration value="get"/>
                  <xs:enumeration value="set"/>
                  <xs:enumeration value="move"/>
                </xs:restriction>
        </xs:simpleType>



5.3  Example


        <!--
        Add user BOB and DIAL OUT to its PC4 with main audio only
        -->


   <conference-request request-id="8797">
   <content entity="sips:conf233@example.com">
        <user entity="sip:bob@example.com">
                <operator><code>add</code></operator>
                <display-text>Bob Hoskins</display-text>
                <endpoint entity="sip:bob@pc4.example.com">
                  <display-text>Bob's Laptop</display-text>
                  <joining-method>dialed-out</joining-method>
                  <media entity="1">



Levin & Kimchi           Expires April 18, 2005                 [Page 9]


Internet-Draft                    CCCP                      October 2004



                    <display-text>main audio</display-text>
                    <proto>audio</proto>
                  </media>
                </endpoint>
        </user>
   </content>
   </conference-request>


   <!--
   REQUEST IS PENDING
   -->


   <conference-response request-id="8797">
   <status><code>pending</code></status>
   </conference-response>



   <!--
   SUCCESFUL RESPONSE
   -->


   <conference-response request-id="8797">
   <content entity="sips:conf233@example.com">
        <user entity="sip:bob@example.com">
                <display-text>Bob Hoskins</display-text>
                <endpoint entity="sip:bob@pc4.example.com">
                  <display-text>Bob's Laptop</display-text>
                  <state>connected</state>
                  <joining-method>dialed-out</joining-method>
                  <joining-info>
                    <when>2005-03-04T20:00:00Z</when>
                    <by>sip:mike@example.com</by>
                  </joining-info>
                  <media entity="1">
                    <display-text>main audio</display-text>
                    <proto>audio</proto>
                    <ssrc>432424</ssrc>
                    <label>34567</label>
                    <state>active</state>
                    <call>
                      <sip>
                        <display-text>full info</display-text>
                        <dialog-id>hsjh8980vhsb78</dialog-id>
                        <from-tag>vav738dvbs</from-tag>
                        <to-tag>8954jgjg8432</to-tag>
                      </sip>
                      </call>
                    </media>




Levin & Kimchi           Expires April 18, 2005                [Page 10]


Internet-Draft                    CCCP                      October 2004



                </endpoint>
        </user>
   </content>
   <status><code>success</code></status>
   </conference-response>




6.  IANA Considerations


   None.


7.  Security Considerations


   Will be completed in the next version.


8.  Acknowledgements


   Authors would like to thank Mary Barnes and Alan Johnston for
   providing helpful inputs.


9.  References


9.1  Normative References


   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.


   [2]  Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol
        (SIP) Event Package for Conference State",
        draft-ietf-sipping-conference-package-06 (work in progress),
        October 2004.


9.2  Informative References


   [3]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.


   [4]  Barnes, M., Boulton, C., "A Framework for Centralized
        Conferencing" draft-barnes-xcon-framework-00, (work in
        progress), October, 2004.


   [5]  Rosenberg, J., "A Framework for Conferencing with the Session
        Initiation Protocol",
        draft-ietf-sipping-conferencing-framework-02 (work in progress),




Levin & Kimchi           Expires April 18, 2005                [Page 11]


Internet-Draft                    CCCP                      October 2004



        June 2004.


   [6]  Levin, O. and R. Even, "High Level Requirements for Tightly
        Coupled SIP Conferencing",
        draft-ietf-sipping-conferencing-requirements-01 (work in
        progress), October 2004.


   [7]  Khartabil, H., "The Conference Policy Control Protocol (CPCP)",
        draft-ietf-xcon-cpcp-01 (work in progress), October 2004.


   [8]  Khartabil, H., "An Extensible Markup Language (XML)
        Configuration Access Protocol (XCAP)  Usages for Conference
        Policy Manipulation and Conference Policy Privelges
        Manipulation", draft-ietf-xcon-cpcp-xcap-03 (work in progress),
        October 2004.


   [9]  Jennings, C., "Media Mixer Control for XCON",
        draft-jennings-xcon-media-control-01 (work in progress), July
        2004.



Authors' Addresses


   Orit Levin
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA


   EMail: oritl@microsoft.com



   Gur Kimchi
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA


   EMail: gkimchi@microsoft.com













Levin & Kimchi           Expires April 18, 2005                [Page 12]


Internet-Draft                    CCCP                      October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Levin & Kimchi           Expires April 18, 2005                [Page 13]