Internet DRAFT - draft-boulton-xcon-conference-control-package

draft-boulton-xcon-conference-control-package






XCON Working Group                                            C. Boulton
Internet-Draft                                           NS-Technologies
Intended status: Standards Track                               M. Barnes
Expires: January 17, 2013                                        Polycom
                                                           July 16, 2012


An XCON Client Conference Control Package for the Media Control Channel
                               Framework
            draft-boulton-xcon-conference-control-package-07

Abstract

   The Centralized Conferencing framework defines a model whereby client
   initiated interactions are required for creation, deletion,
   manipulation and querying the state of a of conference.  This
   document defines a Media Control Channel Package for XCON client
   initiated Conference Control.  The Package is based on the Media
   Control Channel Framework, which is also used for media server
   control, thus optimizing the implementation for some entities
   participating in an XCON system.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 17, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Boulton & Barnes        Expires January 17, 2013                [Page 1]

Internet-Draft         Conference Control Package              July 2012


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Control Package Detail  . . . . . . . . . . . . . . . . . . . . 6
     5.1.  Control Package Name  . . . . . . . . . . . . . . . . . . . 6
     5.2.  Framework Message Usage . . . . . . . . . . . . . . . . . . 6
     5.3.  Common XML Support  . . . . . . . . . . . . . . . . . . . . 6
     5.4.  Control Message Bodies  . . . . . . . . . . . . . . . . . . 6
     5.5.  REPORT Message Bodies . . . . . . . . . . . . . . . . . . . 6
     5.6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Control Package Registration  . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8























Boulton & Barnes        Expires January 17, 2013                [Page 2]

Internet-Draft         Conference Control Package              July 2012


1.  Introduction

   The Conference Control Manipulation Protocol (CCMP) [RFC6503]
   provides a standards based mechanism to enable third party conference
   clients participating to interoperate with conference servers and
   manipulate conference parameters using HTTP as a transport.  A Data
   Model [RFC6501] provides the data associated with a conference
   instance that is the target for the CCMP protocol operations.

   A Control Channel Framework[RFC6230] has been created based on the
   Session Initiation protocol (SIP).  It uses SIP to setup, maintain
   and terminate a reliable control channel for the purpose of
   exchanging control based interactions.  While the control of media
   was the original problem domain for which this framework was
   developed, the Control Framework provides an extension template for
   creating extensions that specify the semantic detail associated with
   the control channel operations.  The extension documents are known as
   Control Packages and an example is the 'Basic Mixer Control Package'
   [RFC6505].

   This document will specify a Control Package for Conference Control
   using the SIP Control Framework.  The target for these operations is
   the same data, associated with conference instances per the data
   model, as CCMP.  It should be noted that this mechanism is a
   complementary approach to CCMP.  In fact this specification simply
   provides a different transport mechanism.  While the use of HTTP as a
   transport for CCMP is ideal for certain network deployments (for
   example Service Orientated Architectures), it is important to offer
   an alternative access method for clients with non SOA based
   technologies.

   The Media Control Channel Framework provides the ideal mechanism for
   reliably exchanging control messages between a conference client and
   server.  It provides inherent properties such as:

   o  Reliable delivery of control messages.
   o  Lightweight Protocol Data Units (PDU).
   o  Linked asynchronous transactional mechanism.
   o  Asynchronous event mechanism.

   The SIP Control Framework uses SIP as its overlying rendezvous
   mechanism.  This provides all the inherent benefits like:

   o  SIP Service Location - Use SIP Proxies or Back-to-Back User Agents
      for discovering Control Servers.
   o  SIP Security Mechanisms - Leverage established security mechanisms
      such as Transport Layer Security (TLS) and Client Authentication.




Boulton & Barnes        Expires January 17, 2013                [Page 3]

Internet-Draft         Conference Control Package              July 2012


   o  Connection Maintenance - The ability to re-negotiate a connection,
      ensure it is active, audit parameters, and so forth.
   o  Agnostic - Allows for ease of extension.

   Not only is the Media Control Channel Framework an ideal mechanism
   for controlling conference instances by participating clients, it
   also provides the property of re-use by conferencing systems of
   functionality implemented for controlling Media Servers etc.  This
   includes re-using the SIP stack for control channel setup as well as
   the Control Channel Framework stack for receiving/sending the PDUs
   for multiple control packages in a conference system.


2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


3.  Terminology

   This document reuses the terminology defined and used in the
   framework and data model for centralized conferencing [RFC5239],
   [RFC6501] and [RFC6503] .


4.  Overview

   The use of the Media Control Channel Framework offers an ideal
   mechanism for creating, deleting and manipulating XCON conference
   instances by participating clients.  As the Control Channel Framework
   is a generic mechanism, this section provides non-normative detail
   showing how the Control Channel Framework can be applied to this
   particular use-case.  In [RFC5239], two distinct roles are defined -
   A 'Control Client' and a 'Control Server'.  Such roles are
   interchangeable between entities within a session depending on
   package requirements.  A simple diagram is illustrated in Figure 1













Boulton & Barnes        Expires January 17, 2013                [Page 4]

Internet-Draft         Conference Control Package              July 2012


          +--------------SIP Traffic--------------+
          |                                       |
          v                                       v
       +-----+                                 +--+--+
       | SIP |                                 | SIP |
       |Stack|                                 |Stack|
   +---+-----+---+                         +---+-----+---+
   |   Control   |                         |   Control   |
   |   Client    |<----Control Channel---->|   Server    |
   +-------------+                         +-------------+



                       Figure 1: Basic Architecture

   The XCON Conference Control package will cast a participating
   compliant User Agent that wishes to control a conference instance as
   a 'Control Client' as defined in the SIP Control Framework.  It will
   have permission to generate and issue commands in CONTROL messages as
   defined in Section 5.2 of this document.  It will also have the
   ability to receive responses to Conference Package CONTROL requests
   that are contained in either appropriate responses or subsequent
   REPORT messages, also specified in Section 5.2.  The specific format
   of the conference control messages and responses are defined in
   Section 5.4 and Section 5.5.  They re-use the format specified in
   CCMP[RFC6503].  This provides a common binding set with alternative
   access mechanism depending on client requirements.  The previous
   diagram can be updated as illustrated in Figure 2.


          +--------------SIP Traffic--------------+
          |                                       |
          v                                       v
       +-----+                                 +--+--+
       | SIP |                                 | SIP |
       |Stack|                                 |Stack|
   +---+-----+---+                         +---+-----+---+
   |    XCON     |                         |    XCON     |
   |   Control   |                         | Conference  |
   |   Client    |<----Control Channel---->|   System    |
   +-------------+                         +-------------+



                 Figure 2: Conference Control Architecture

   Editor's Note: The Overview section will be expanded in later
   versions of the document.



Boulton & Barnes        Expires January 17, 2013                [Page 5]

Internet-Draft         Conference Control Package              July 2012


5.  Control Package Detail

   The Media Control Channel Framework defines rules that Control
   Package extensions must provide mandatory information as described in
   section 10 of [RFC6230].  This section fulfils the obligation.

5.1.  Control Package Name

   The SIP Control Framework requires a Control Package definition to
   specify and register a unique package name.  The name and version of
   this Control Package is "xcon-conf-control/1.0".

5.2.  Framework Message Usage

   The Conference Control package uses the XML schema defined in CCMP
   [RFC6503].  To maintain the consistency with the design of the XML
   schema, the SIP Control Framework messages will be applied in a
   similar manner.  The CONTROL message will be used to contain requests
   that enable conference manipulation - as specified in Section 5.4 and
   can only travel from the client to a Conferencing System.  Responses,
   as specified in Section 5.5, can only travel from the Conferencing
   System to an expectant client.  Depending on the time it takes to
   process the request (as specified in [RFC6230]), responses can either
   be contained in a Control Framework 200 response or subsequent REPORT
   method.

5.3.  Common XML Support

   The Control Framework requires a Control Package definition to
   specify if the attributes for media dialog or conference references
   are required.

   This package requires that the XML Schema in Section 16.1 of
   [RFC6230] MUST NOT be supported for media dialogs and conferences.
   But rather this package SHOULD use the XML schema as defined in
   [RFC6501], which is the same schema upon which CCMP is based.

5.4.  Control Message Bodies

   A valid CONTROL body message MUST conform to the XML schema defined
   in [RFC6503] for the conference control.  To be precise, the CONTROL
   message body MUST comply only to the 'ccmp-request-type' complexType.

5.5.  REPORT Message Bodies

   A valid CONTROL body message MUST conform to the XML schema defined
   in [RFC6503].  To be precise, the REPORT message body MUST comply
   only to the 'ccmp-response-type' complexType.



Boulton & Barnes        Expires January 17, 2013                [Page 6]

Internet-Draft         Conference Control Package              July 2012


5.6.  Examples

   TODO


6.  IANA Considerations

6.1.  Control Package Registration

   This section registers a new Media Control Channel Framework package,
   per the instructions in Section 12.1 of [RFC6230].

   To: ietf-sip-control@iana.org Subject: Registration of new Media
   Control Channel Framework package Package Name: xcon-conf-control/1.0
   [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for
   this specification.]  Published Specification(s): RFCXXXX Person &
   email address to contact for further information: IETF, XCON working
   group, (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com).


7.  Security Considerations

   Access to conference control functionality needs to be tightly
   controlled to avoid attackers disrupting conferences, adding
   themselves to conferences or engaging in theft of services.

   The Framework for Centralized Conferencing [RFC5239] specifies that
   the protocols used for manipulation and retrieval of confidential
   information MUST support a confidentiality and integrity mechanism.
   To support the confidentiality and integrity requirements, all
   conference control information included in the package defined in
   this document SHOULD be carried over TLS.

   Additional information should be added to this section based on the
   final material in the Control Framework for SIP [RFC6230].

   There are also security issues associated with the authorization to
   perform actions on the conferencing system to invoke specific
   capabilities.  Implementers MUST deploy appropriate authentication
   and authorization mechanisms to ensure that only authorized entities
   are able to manipulate the data.


8.  Acknowledgments


9.  References




Boulton & Barnes        Expires January 17, 2013                [Page 7]

Internet-Draft         Conference Control Package              July 2012


9.1.  Normative References

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

   [RFC6501]  Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
              "Conference Information Data Model for Centralized
              Conferencing (XCON)", RFC 6501, March 2012.

   [RFC6230]  Boulton, C., Melanchuk, T., and S. McGlashan, "Media
              Control Channel Framework", RFC 6230, May 2011.

   [RFC6505]  McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer
              Control Package for the Media Control Channel Framework",
              RFC 6505, March 2012.

   [RFC6503]  Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
              "Centralized Conferencing Manipulation Protocol",
              RFC 6503, March 2012.

9.2.  Informative References

   [W3C.CR-wsdl20-20051215]
              Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
              "Web Services Description Language (WSDL) Version 2.0 Part
              1: Core Language", W3C CR CR-wsdl20-20051215,
              December 2005.

   [W3C.REC-soap12-part1-20030624]
              Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and
              M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework",
              World Wide Web Consortium FirstEdition REC-soap12-part1-
              20030624, June 2003,
              <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.

   [W3C.REC-soap12-part2-20030624]
              Hadley, M., Mendelsohn, N., Nielsen, H., Gudgin, M., and
              J. Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
              Web Consortium FirstEdition REC-soap12-part2-20030624,
              June 2003,
              <http://www.w3.org/TR/2003/REC-soap12-part2-20030624>.

   [RFC5239]  Barnes, M., Boulton, C., and O. Levin, "A Framework for
              Centralized Conferencing", RFC 5239, June 2008.







Boulton & Barnes        Expires January 17, 2013                [Page 8]

Internet-Draft         Conference Control Package              July 2012


Authors' Addresses

   Chris Boulton
   NS-Technologies

   Email: chris@ns-technologies.com


   Mary Barnes
   Polycom
   TX

   Email: mary.ietf.barnes@gmail.com






































Boulton & Barnes        Expires January 17, 2013                [Page 9]