XCON Working Group                                            C. Boulton
Internet-Draft                                                     Avaya
Intended status: Standards Track                               M. Barnes
Expires: February 21, 2009                                        Nortel
                                                         August 20, 2008


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

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 February 21, 2009.

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.





Boulton & Barnes        Expires February 21, 2009               [Page 1]

Internet-Draft         Conference Control Package            August 2008


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 . . . . . . . . . . . . . . . . . .  7
     5.5.  REPORT Message Bodies  . . . . . . . . . . . . . . . . . .  7
     5.6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10






























Boulton & Barnes        Expires February 21, 2009               [Page 2]

Internet-Draft         Conference Control Package            August 2008


1.  Introduction

   As part of the Centralized Conferencing (XCON) work group in the IETF
   a Data Model[I-D.ietf-xcon-common-data-model] has been created for
   the purpose of modeling conference based services in a standard way.
   The XCON group also requires a standards based mechanism that will
   enable third party conference clients participating to interoperate
   with conference servers and manipulate conference parameters.

   The Media Control (MEDIACTRL) Work Group within the IETF has the
   explicit goal of creating an architecture and framework for
   controlling Media Servers.  As part of this work a Control Channel
   Framework[I-D.boulton-sip-control-framework] has been created that is
   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.  The Control
   Framework provides an extension template for creating extensions that
   specify the semantic detail associated with the operations.  The
   extension documents are known as Control Packages and an example is
   the 'Basic IVR Control Package'[I-D.boulton-ivr-control-package].
   This document will specify a Control Package for Conference Control
   by participating clients using the SIP Control Framework.

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



Boulton & Barnes        Expires February 21, 2009               [Page 3]

Internet-Draft         Conference Control Package            August 2008


   the Control Channel Framework stack for receiving/sending the PDUs
   for multiple control packages in an XCON conference system.

   It should be noted that this mechanism is a complementary technology
   to that specified in the document 'A Centralized Conferencing
   Manipulation Protocol (CCMP)'[I-D.barnes-xcon-ccmp].  In fact this
   specification simply re-uses the SOAP bindings created in that
   document for a consistent view (so just the transport mechanism is
   different).  While the mechanism defined in [I-D.barnes-xcon-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.  Using the SIP Control
   Framework provides consistency across both XCON and MEDIACTRL work
   groups.


2.  Conventions

   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 [RFC2119] and indicate requirement
   levels for compliant implementations.


3.  Terminology

   This document reuses the terminology defined in the framework and
   data model for centralized conferencing [I-D.ietf-xcon-framework].
   In addition, the following acronyms and terms are used in this
   document:

   SOAP:  Simple Object Access Protocol.
   WSDL:  Web Services Description Language.  WSDL is an XML format for
      describing network services as a set of endpoints operating on
      messages containing either document-oriented or procedure-oriented
      information.


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 [I-D.ietf-xcon-framework], two distinct
   roles are defined - A 'Control Client' and a 'Control Server'.  Such



Boulton & Barnes        Expires February 21, 2009               [Page 4]

Internet-Draft         Conference Control Package            August 2008


   roles are interchangeable between entities within a session depending
   on package requirements.  A simple diagram is illustrated in Figure 1


          +--------------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 XCON
   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[I-D.barnes-xcon-ccmp].  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    |
   +-------------+                         +-------------+






Boulton & Barnes        Expires February 21, 2009               [Page 5]

Internet-Draft         Conference Control Package            August 2008


                 Figure 2: Conference Control Architecture

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


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 [I-D.boulton-sip-control-framework].  This section
   fulfills 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 SOAP WSDL
   [W3C.CR-wsdl20-20051215] defined in CCMP[I-D.barnes-xcon-ccmp].  To
   maintain the consistency with the design of the WSDL 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 [I-D.boulton-sip-control-framework]),
   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
   [I-D.boulton-sip-control-framework] MUST NOT be supported for media
   dialogs and conferences.

   EDITOR'S NOTE: This document could make use of the Conf common schema
   TBD.





Boulton & Barnes        Expires February 21, 2009               [Page 6]

Internet-Draft         Conference Control Package            August 2008


5.4.  Control Message Bodies

   A valid CONTROL body message MUST conform to the WSDL defined in
   [I-D.barnes-xcon-ccmp].  To be precise, the CONTROL message body MUST
   comply only to the 'input' element of the WSDL portType
   (CCMPPortType).

5.5.  REPORT Message Bodies

   A valid CONTROL body message MUST conform to the WSDL defined in
   [I-D.barnes-xcon-ccmp].  To be precise, the REPORT message body MUST
   comply only to the 'output' element of the WSDL portType
   (CCMPPortType).

5.6.  Examples

   TODO


6.  IANA Considerations

   TODO


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 [I-D.ietf-xcon-framework]
   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.

   Editor's Note: once the security requirements for the control
   packages are further specified in the Control Framework for SIP
   [I-D.boulton-sip-control-framework] additional information may be
   added to this section.

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




Boulton & Barnes        Expires February 21, 2009               [Page 7]

Internet-Draft         Conference Control Package            August 2008


8.  Acknowledgments


9.  References

9.1.  Normative References

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

   [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]
              Hadley, M., Gudgin, M., Nielsen, H., Mendelsohn, N., and
              J. Moreau, "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]
              Mendelsohn, N., Moreau, J., Nielsen, H., Hadley, M., and
              M. Gudgin, "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>.

9.2.  Informative References

   [I-D.ietf-xcon-common-data-model]
              Novo, O., Camarillo, G., Morgan, D., and R. Even,
              "Conference Information Data Model for Centralized
              Conferencing (XCON)", draft-ietf-xcon-common-data-model-11
              (work in progress), June 2008.

   [I-D.ietf-xcon-framework]
              Barnes, M., Boulton, C., and O. Levin, "A Framework for
              Centralized Conferencing", draft-ietf-xcon-framework-11
              (work in progress), April 2008.

   [I-D.boulton-sip-control-framework]
              Boulton, C., "A Control Framework for the Session
              Initiation Protocol (SIP)",
              draft-boulton-sip-control-framework-05 (work in progress),
              February 2007.



Boulton & Barnes        Expires February 21, 2009               [Page 8]

Internet-Draft         Conference Control Package            August 2008


   [I-D.boulton-ivr-control-package]
              Boulton, C., Melanchuk, T., and S. McGlashan, "A Basic
              Interactive Voice Response (IVR) Control Package for the
              Media  Control Channel Framework",
              draft-boulton-ivr-control-package-06 (work in progress),
              February 2008.

   [I-D.barnes-xcon-ccmp]
              Barnes, M., Boulton, C., and H. Schulzrinne, "Centralized
              Conferencing Manipulation Protocol",
              draft-barnes-xcon-ccmp-04 (work in progress),
              February 2008.


Authors' Addresses

   Chris Boulton
   Avaya
   Building 3
   Wern Fawr Lane
   St Mellons
   Cardiff, South Wales  CF3 5EA

   Email: cboulton@avaya.com


   Mary Barnes
   Nortel
   2380 Performance Drive
   Richardson, TX

   Email: mary.barnes@nortel.com



















Boulton & Barnes        Expires February 21, 2009               [Page 9]

Internet-Draft         Conference Control Package            August 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.











Boulton & Barnes        Expires February 21, 2009              [Page 10]