One document matched: draft-boulton-xcon-conference-control-package-01.txt
Differences from draft-boulton-xcon-conference-control-package-00.txt
XCON Working Group C. Boulton
Internet-Draft Avaya
Intended status: Standards Track M. Barnes
Expires: May 15, 2008 Nortel
November 12, 2007
A Conference Control Package for the Session Initiation Protocol (SIP)
draft-boulton-xcon-conference-control-package-01
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 May 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 Session Initiation (SIP) Control Package for
Conference Control for these client interactions. The SIP Control
Package is based on the SIP Control Framework, which is also used for
media control, thus optimizing the implementation for some clients.
Boulton & Barnes Expires May 15, 2008 [Page 1]
Internet-Draft Conference Control Package November 2007
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
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Boulton & Barnes Expires May 15, 2008 [Page 2]
Internet-Draft Conference Control Package November 2007
1. Introduction
As part of the Centralized Conferencing (XCON) work group in the IETF
a Data Model[5] 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
Framework[7] 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'[8]. This
document will specify a Control Package for Conference Control by
participating clients using the SIP Control Framework.
The SIP Control 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 SIP Control 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 Framework stack for receiving/sending the PDUs for
Boulton & Barnes Expires May 15, 2008 [Page 3]
Internet-Draft Conference Control Package November 2007
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)'[9]. 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 [9] 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 [1] and indicate requirement levels for
compliant implementations.
3. Terminology
This document reuses the terminology defined in the framework and
data model for centralized conferencing [6]. 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 SIP Control Framework offers an ideal mechanism for
creating, deleting and manipulating XCON conference instances by
participating clients. As the Control Framework is a generic
mechanism, this section provides non-normative detail showing how the
Control Framework can be applied to this particular use-case. In
[6], 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 May 15, 2008 [Page 4]
Internet-Draft Conference Control Package November 2007
+--------------SIP Traffic--------------+
| |
v v
+-----+ +--+--+
| SIP | | SIP |
|Stack| |Stack|
+---+-----+---+ +---+-----+---+
| Control | | Control |
| Client |<----Control Channel---->| Server |
+-------------+ +-------------+
Figure 1: Basic Architecture
The 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[9]. 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 May 15, 2008 [Page 5]
Internet-Draft Conference Control Package November 2007
5. Control Package Detail
The SIP Control Framework defines rules that Control Package
extensions must provide mandatory information as described in section
10 of [7]. 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".
5.2. Framework Message Usage
The Conference Control package uses the SOAP WSDL [2] defined in
CCMP[9]. 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 [7]), 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 [7] MUST
NOT be supported for media dialogs and conferences.
EDITOR'S NOTE: This document could make use of the Conf common schema
TBD.
5.4. Control Message Bodies
A valid CONTROL body message MUST conform to the WSDL defined in [9].
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 [9].
To be precise, the REPORT message body MUST comply only to the
Boulton & Barnes Expires May 15, 2008 [Page 6]
Internet-Draft Conference Control Package November 2007
'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 [6] 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 [7] 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. Implementors SHOULD deploy standard SOAP
authentication and authorization mechanisms to ensure that only
authorized entities are able to manipulate the data.
8. Acknowledgments
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] 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.
Boulton & Barnes Expires May 15, 2008 [Page 7]
Internet-Draft Conference Control Package November 2007
[3] Gudgin, M., Nielsen, H., Moreau, J., Mendelsohn, N., 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>.
[4] Mendelsohn, N., Gudgin, M., Hadley, M., Nielsen, H., 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>.
9.2. Informative References
[5] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference
Information Data Model for Centralized Conferencing (XCON)",
draft-ietf-xcon-common-data-model-06 (work in progress),
October 2007.
[6] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", draft-ietf-xcon-framework-10 (work in
progress), November 2007.
[7] Boulton, C., "A Control Framework for the Session Initiation
Protocol (SIP)", draft-boulton-sip-control-framework-05 (work in
progress), February 2007.
[8] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A
Basic Interactive Voice Response (IVR) Control Package for the
Session Initiation Protocol (SIP)",
draft-boulton-ivr-control-package-04 (work in progress),
November 2007.
[9] Barnes, M., "Centralized Conferencing Manipulation Protocol",
draft-barnes-xcon-ccmp-02 (work in progress), February 2007.
Authors' Addresses
Chris Boulton
Avaya
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@avaya.com
Boulton & Barnes Expires May 15, 2008 [Page 8]
Internet-Draft Conference Control Package November 2007
Mary Barnes
Nortel
2380 Performance Drive
Richardson, TX
Email: mary.barnes@nortel.com
Boulton & Barnes Expires May 15, 2008 [Page 9]
Internet-Draft Conference Control Package November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Boulton & Barnes Expires May 15, 2008 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 03:05:29 |