draft-ietf-xcon-cpcp-xcap-00.txt   draft-ietf-xcon-cpcp-xcap-01.txt 
XCON H. Khartabil XCON H. Khartabil
Internet-Draft P. Koskelainen Internet-Draft P. Koskelainen
Expires: October 18, 2004 Nokia Expires: January 14, 2005 A. Niemi
April 19, 2004 Nokia
July 16, 2004
The Conference Policy Control Protocol (CPCP) The Conference Policy Control Protocol (CPCP)
draft-ietf-xcon-cpcp-xcap-00 draft-ietf-xcon-cpcp-xcap-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 18, 2004. This Internet-Draft will expire on January 14, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes the Conference Policy Control Protocol This document describes the Conference Policy Control Protocol
(CPCP). It specifies an Extensible Markup Language (XML) Schema that (CPCP). It specifies an Extensible Markup Language (XML) Schema that
enumerates the conference policy data elements that enable a user to enumerates the conference policy data elements that enable a user to
define a conference policy. It also defines an XML Configuration define a conference policy. It also defines an XML Configuration
Access Protocol (XCAP) application usage that is needed to store and Access Protocol (XCAP) application usage that may be used to store
manipulate a conference policy. and manipulate a conference policy.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Structure of a Conference Policy document . . . . . . . . 4 4. Structure of a Conference Policy document . . . . . . . . . . 6
4.1 MIME Type for CPCP XML Document . . . . . . . . . . . . . 6 4.1 MIME Type for CPCP XML Document . . . . . . . . . . . . . 6
4.2 XML Document Description . . . . . . . . . . . . . . . . . 6 4.2 Conference Root . . . . . . . . . . . . . . . . . . . . . 6
4.2.1 <Conference-settings> element . . . . . . . . . . . . . . 6 4.3 XML Document Description . . . . . . . . . . . . . . . . . 7
4.2.2 <Conference-info> element . . . . . . . . . . . . . . . . 6 4.3.1 Conference Settings . . . . . . . . . . . . . . . . . 7
4.2.3 <Conference-time> element . . . . . . . . . . . . . . . . 7 4.3.2 Conference Information . . . . . . . . . . . . . . . . 8
4.2.4 <ACL> (Access Control List) element . . . . . . . . . . . 8 4.3.3 Conference Time . . . . . . . . . . . . . . . . . . . 9
4.2.5 <PCL> (Privilege Control List) element . . . . . . . . . . 9 4.3.4 Conference Authorization Rules . . . . . . . . . . . . 10
4.2.6 <DL> (Dial-Out List) element . . . . . . . . . . . . . . . 10 4.3.5 Conference Dial-Out List . . . . . . . . . . . . . . . 21
4.2.7 <SC> (Security Control) element . . . . . . . . . . . . . 10 4.3.6 Conference Refer List . . . . . . . . . . . . . . . . 22
4.2.8 <Conference-floor-policy> element . . . . . . . . . . . . 11 4.3.7 Conference Security Control . . . . . . . . . . . . . 22
4.2.9 <Conference-media-Policy> element . . . . . . . . . . . . 12 4.3.8 Conference Floor Policy . . . . . . . . . . . . . . . 22
4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.9 Conference Media Streams . . . . . . . . . . . . . . . 23
5. Floor Control Policy vs. Floor Control Protocol . . . . . 19 4.4 XML Schema Extensibility . . . . . . . . . . . . . . . . . 24
6. An XCAP Usage for Conference Policy Manipulation . . . . . 19 4.5 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1 Application Unique ID . . . . . . . . . . . . . . . . . . 19 5. Conference Policy Manipulation and Conference Entity
6.2 Resource Interdependencies . . . . . . . . . . . . . . . . 19 Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3 Additional Constraints . . . . . . . . . . . . . . . . . . 20 5.1 Overview of Operation . . . . . . . . . . . . . . . . . . 30
6.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 20 5.2 Use of External Lists . . . . . . . . . . . . . . . . . . 31
6.5 Authorization Policies . . . . . . . . . . . . . . . . . . 20 5.3 Communication Between Conference Entities . . . . . . . . 31
6.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 20 5.4 Manipulating Participant Lists . . . . . . . . . . . . . . 31
6.7 Overview of Operation . . . . . . . . . . . . . . . . . . 20 5.4.1 Expelling a Participant . . . . . . . . . . . . . . . 32
6.8 Communication Between Conference Entities . . . . . . . . 21 5.5 Re-joining a Conference . . . . . . . . . . . . . . . . . 33
6.9 Conference Creation and Termination . . . . . . . . . . . 21 5.6 Floor Control Policy vs. Floor Control Protocol . . . . . 33
6.10 Manipulating the Participant Lists . . . . . . . . . . . . 21 6. An XCAP Usage for Conference Policy Manipulation . . . . . . . 34
6.10.1 Expelling a Participant . . . . . . . . . . . . . . . . . 22 6.1 Application Unique ID . . . . . . . . . . . . . . . . . . 34
6.11 Privileges: Who can modify the conference policy . . . . . 22 6.2 Resource Interdependencies . . . . . . . . . . . . . . . . 34
6.12 Conference URI(s) . . . . . . . . . . . . . . . . . . . . 23 6.3 Additional Constraints . . . . . . . . . . . . . . . . . . 34
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.4 Naming Conventions . . . . . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . 26 6.5 Authorization Policies . . . . . . . . . . . . . . . . . . 34
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 26 6.6 MIME Type for CPCP XML Document . . . . . . . . . . . . . 35
9.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . 26 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.2 application/conference-policy+xml mime TYPE . . . . . . . 26 7.1 An Example CPCP Document . . . . . . . . . . . . . . . . . 35
7.2 CPCP Manipulations Using XCAP . . . . . . . . . . . . . . 38
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
9.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . 41
9.2 application/conference-policy+xml MIME TYPE . . . . . . . 41
9.3 URN Sub-Namespace Registration for 9.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-policy . . . . . . . . . 27 urn:ietf:params:xml:ns:conference-policy . . . . . . . . . 42
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . 28 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 43
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
Normative References . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 29 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . 31 12.2 Informative References . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . 46
1. Introduction 1. Introduction
SIP conferencing framework [11] defines the mechanisms for The SIP conferencing framework [13] defines the mechanisms for
multi-party centralized conferencing in a SIP environment. Existing multi-party centralized conferencing in a SIP environment.
SIP mechanisms allow users, for example, to join and leave a
conference. A centralized serve, called focus, can expel and invite
users, and may have proprietary access control lists and user
privilege definitions. However, in many cases it is useful to have a
standardised conference policy elements such as access control lists
and a standardised protocol means to manipulate them. The
requirements for such protocol are defined in [7]. This document
provides an XML Schema Section 4.3 that enumerates the conference
policy data elements that enable a user to define a conference
policy. It also defines an XML Configuration Access Protocol (XCAP)
[8] application usage that is needed to store and manipulate a
conference policy.
Other mechanisms, such as web page or voice response system can also Existing SIP mechanisms allow users, for example, to join and leave a
be used to manipulate conference policy data. conference, as described in [9]. A centralised server, called focus,
can expel and invite users, and may have proprietary access control
lists and user privilege definitions. This document defines an XML
Schema in Section 4 that enumerates the conference policy data
elements that enable a user to define a conference policy. In some
cases, such as some ad-hoc scenarios described in [9], there is a
static conference policy which is not changed or manipulated during a
conference. This policy document may be given to a focus using a
number of transports. Mechanisms such as a web page or a voice
response system can also be used to manipulate conference policy
data.
However, in many cases it is useful to have standardised means to
manipulate conference policy elements such as access control lists.
The requirements for such protocol are defined in [8].
Section 6 of this document describes one such protocol for the
real-time manipulation of conference policy. An XML Configuration
Access Protocol (XCAP) [10] application usage is defined which meets
the requirements in [8] to store and manipulate a conference policy
object.
XCAP has many advantages in its use for conference policy control XCAP has many advantages in its use for conference policy control
protocol. It is a HTTP 1.1 based protocol that allows clients to protocol. It is a HTTP 1.1 based protocol that allows clients to
read, write, modify and delete application data stored in XML format read, write, modify and delete application data stored in XML format
at a server. XCAP maps XML document elements and attributes to HTTP at a server. XCAP maps XML document elements and attributes to HTTP
URIs that can be directly accessed by HTTP. One application area URIs that can be directly accessed by HTTP. One application area
which has already adopted XCAP is the manipulation of event lists which has already adopted XCAP is the manipulation of event lists
[9]. [11].
A focus conforming to this specification MUST support the XML object
defined in Section 4 . For manipulation of the the XML object, the
system MAY support the XCAP usage defined in Section 6.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
3. Terminology 3. Terminology
This document uses terminology from [11]. Some additional definitions This document uses terminology from [13]. Some additional
are introduced here. definitions are introduced here.
ACL Conference authorization policy (CAP)
Access control list (ACL) defines users who can join to a Conference authorization policy consists of an unordered set of
conference. Users may have allowed, blocked, pending or rules, which control the permissions and privileges that are
expelled status in the list. Each conference has its own ACL. given to conference participants.
CPS Conference Policy Server (CPS)
Conference Policy Server. See [13]
Conference Policy Server. See [11]
Conference participant Conference participant
Conference participant is a user who has on-going session (e.g. Conference participant is a user who has an on-going session
SIP dialog) with the conference focus. (e.g. SIP dialog) with the conference focus.
Floor control Floor control
Floor control is a mechanism that enables applications or users Floor control is a mechanism that enables applications or users
to gain safe and mutually exclusive or non-exclusive access to to gain safe and mutually exclusive or non-exclusive access to
the shared object or resource in a conference. the shared object or resource in a conference.
Dial-Out List (DL) Dial-Out List (DL)
Dial-out list (DL) is a list of users who the focus needs to Dial-out list (DL) is a list of users who the focus needs to
invite to the conference. invite to the conference.
PCL
Privilege control control (PCL) defines privileges for a user.
Each user in a conference may have different list of privileges
and each conference has its own PCL.
Privileged user Privileged user
In this document, a privileged user is the creator. Defining A privileged user is a user that has the right manipulate parts
privileges to modify certain parts of a conference policy is or all of the conference policy settings.
outside the scope of this document.
CPS XCAP URI CPS XCAP URI
The URI of the XCAP server that is used to create the The URI of the XCAP server that is used to create the
conference. The URI contsruction is specified in [8]. It is conference. The URI construction is specified in [10]. It is
refered to in XCAP as the host part. referred to in XCAP as the host part.
Conference Policy URI Conference Policy URI
The URI of conference policy. In XCAP, it is the CPS XCAP URI The URI of conference policy. In XCAP, it is the CPS XCAP URI
along with the abs_path. It identifies the XML document. The along with the abs_path. It identifies the XML document. The
URI contsruction is specified in [8]. URI construction is specified in [10].
4. Structure of a Conference Policy document 4. Structure of a Conference Policy document
The conference policy document is an XML [5] document that MUST be The conference policy document is an XML [6] document that MUST be
well-formed and MUST be valid. Conference policy documents MUST be well-formed and MUST be valid. Conference policy documents MUST be
based on XML 1.0 and MUST be encoded using UTF-8. This specification based on XML 1.0 and MUST be encoded using UTF-8. This specification
makes use of XML namespaces for identifying conference policy makes use of XML namespaces for identifying conference policy
documents and document fragments. The namespace URI for elements documents and document fragments. The namespace URI for elements
defined by this specification is a URN [2], using the namespace defined by this specification is a URN [3], using the namespace
identifier 'ietf' defined by [3] and extended by [13]. This URN is: identifier 'ietf' defined by [4] and extended by [15]. This URN is:
urn:ietf:params:xml:ns:conference-policy urn:ietf:params:xml:ns:conference-policy
4.1 MIME Type for CPCP XML Document
The MIME type for the CPCP XML document is "application/
conference-policy+xml".
4.2 Conference Root
A conference policy document begins with the root element tag A conference policy document begins with the root element tag
"conference-policy". Other elements from different namespaces MAY be <conference>. Other elements from different namespaces MAY be
present for the purposes of extensibility. Elements or attributes present for the purposes of extensibility. Elements or attributes
from unknown namespaces MUST be ignored. The conference policy is from unknown namespaces MUST be ignored. The conference policy is
build up using multiple namespaces: build up using the following:
o "urn:ietf:params:xml:ns:conference-settings": This namespace o The <settings> element: This element is mandatory and contains
defines elements for conference setting. The inclusion of this various conference settings. It contains the conference URI(s)
namespace is optional. It contains the mandatory element and the maximum number of participants. It can occur only once
<Conference-settings>. This element contains the conference URI(s) in the document.
and maximum number of participants. It can occur only once in the
document.
o "urn:ietf:params:xml:ns:conference-info": This namespace defines o The <info> element: This element is optional and includes
elements to carry conference information. The inclusion of this information describing the conference, e.g. for search purposes.
namespace is optional. It contains the mandatory element This information can also be used in the session description when
<Conference-info>. This element includes informational describing the focus is sending invitations. It can occur only once in the
the conference, e.g. for search purposes. This information can document.
also be used in the session description when the focus is sending
invitations. It can occur only once in the document.
o "urn:ietf:params:xml:ns:conference-time": This optional namespace o The <time> element: This optional element defines conference time
defines conference time information. It defines the mandatory information, namely elements defining start and stop times for a
<Conference-time> element that includes elements defining start conference.
and stop times for a conference.
o "urn:ietf:params:xml:ns:conference-acl": This optional namespace o The <authorization> element: This optional element is the
is for the access control list. It defines the mandatory <ACL> conference authorisation rules. It contains rules for users who
element that contains URIs for users who can dial into the can dial into the conference, users who are blocked from dialling
conference, users who are blocked from dialling in, and expelled in, amongst others.
users.
o "urn:ietf:params:xml:ns:conference-pcl": This optional namespace o The <dialout-list> element: This optional element is for the
is for the privilege control list. It defines the mandatory <PCL> dial-out list. It contains URIs for users that the focus will
element that contains privileges and URIs for users who have those invite to the conference.
privileges.
o "urn:ietf:params:xml:ns:conference-dl": This optional namespace is o The <refer-list> element: This optional element is for the refer
for the dial-out list. It defines the mandatory <DL> element that list. It contains URIs for users that the focus will refer to
contains URIs for users that the focus will invite to the the conference.
conference.
o "urn:ietf:params:xml:ns:conference-sc": This optional namespace is o The <security-control> element: This optional element is for
for security control. It defines the <SC> element that contains security control. It contains conference security level and
conference security level and passwords. passwords.
o "urn:ietf:params:xml:ns:conference-mp": This optional namespace is o The <ms> element: This optional element contains the media streams
for the media policy for a conference. It defines the to be used in the conference.
<Conference-media-policy> element that contains the media types to
be used in the conference.
o "urn:ietf:params:xml:ns:conference-fp": This optional namespace is o The <fp> element: This optional element is for the floor control
for the floor control policy. It defines the policy.
<Conference-floor-policy> element.
The elements are described in more detail in the forthcoming The elements are described in more detail in the forthcoming
sections. sections.
4.1 MIME Type for CPCP XML Document A user may create a new conference at the CPS by placing a new
conference policy document at the CPS. Depending on server policy
The MIME type for the CPCP XML document is "application/ and user privileges, the CPS may accept the creation.
conference-policy+xml".
4.2 XML Document Description A conference can be deleted permanently by removing the conference
policy from the CPS, which consequently frees the resources. When
the user deletes a conference, the CPS MUST also delete all its
sub-conferences ("sidebars") at a server. Conference sidebars have
unique URIs at the server.
4.2.1 <Conference-settings> element 4.3 XML Document Description
The mandatory <Conference-settings> element contains 2 sub-elements; 4.3.1 Conference Settings
the <Conference-URI> element and the <Max-participant-count> element.
<Conference-URI> is an optional element. It can occur more than once The mandatory <settings> element contains 2 sub-elements; the
to accommodate multiple signaling protocols. Once a conference URI is <conference-uri> element and the <max-participant-count> element.
set, it MUST NOT be changed or removed for the duration of the
conference. Only one URI per protocol MUST be set. URIs can be added
at any time.
This is in its own XML namespace, so it is separated from other <conference-uri> is a mandatory element. It can occur more than once
elements and hence relevant modification rights (privileges) can be to accommodate multiple signaling protocols. Once a conference URI
given more easily to other namespaces. is set, it MUST NOT be changed or removed for the duration of the
conference. Only one URI per protocol MUST be set. URIs can be
added at any time.
<Max-participant-count> is an optional. It carries the maximum number <max-participant-count> is optional. It carries the maximum number
of participants allowed in the conference. When the maximum number of of participants allowed in the conference. When the maximum number
participants threshold is reached, no new users are not allowed to of participants threshold is reached, no new users are not allowed to
join until the number of participants decreases again. If using SIP, join until the number of participants decreases again. If using SIP,
the server can reject a request to join (INVITE) with a "480 the server can reject a request to join (INVITE) with a "480
Temporarily Unavailable" response. Alternatively, the sever may Temporarily Unavailable" response. Alternatively, the sever may
implement a waiting queue. implement a waiting queue.
4.2.2 <Conference-info> element <allow-sidebars> is an optional element with a boolean value
indicating if sidebars are allowed in this conference or not. The
default value, if omitted, is "true" indicating that sidebars are
allowed.
Mandatory <Conference-info> element has its own namespace and it can <sidebar> is an element identifying a side bar. Multiple <sidebar>
occur only once in a document. It includes informative conference elements can occur indicating multiple sidebars. No <sidebar>
elements appearing in a conference policy indicates that there are no
sidebars currently for this conference. A <sidebar> element contains
a mandatory 'id' attribute that uniquely identifies the sidebar. It
also contains an <uri> element that hold the sidebar URI. It can
occur more than once to accommodate multiple signaling protocols.
Once a sidebar URI is set, it MUST NOT be changed or removed for the
duration of the conference. Only one URI per protocol MUST be set.
URIs can be added at any time.
A sidebar MAY have its own policy. This policy is created exactly in
the same manner as any other conference. The <policy> element in the
<sidebar> element points to such policy. If the <policy> element is
omitted, the sidebar inherits the policy of the conference it is a
sidebar of.
A conference is identified by one or more conference URIs, one for
each call signaling protocol that is supported. There must be at
least one URI for a conference. Conference URIs can be proposed by
the creator of the conference policy, as it may be useful to have
human-friendly name in some cases, or can be assigned by the CPS. If
the creator has proposed a conference URI, the server needs to decide
whether it accept the name proposed by the client or not. It does
this determination by examining if the conference URI already exists
or not. If it exists, the CPS rejects the request to create the
conference with that conference URI. Similarly, the CPS rejects the
request to create a conference with a conference URI for a signalling
protocol it does not support.
A Conference URI can be SIP, SIPS, TEL, or any supported URI scheme.
The CPS MAY assign multiple conference URIs to a conference, one for
each call signaling protocol that it supports.
Sidebar URIs are subject to the same behaviour.
4.3.2 Conference Information
The optional <info> element includes informative conference
parameters which may be helpful describing the purpose of a parameters which may be helpful describing the purpose of a
conference, e.g. for search purposes or for providing host contact conference, e.g. for search purposes or for providing host contact
information. The <Conference-info element MUST have a special information. The <info> element MUST have a special attribute
attribute 'xml:lang' to specify the language used in the contents of 'xml:lang' to specify the language used in the contents of this
this element as defined Section 2.12 of [5]. element as defined Section 2.12 of [6].
Each conference has an optional <Subject> element, which describes Each conference has an optional <subject> element, which describes
the current topic in a conference. The optional <Display-name> the current topic in a conference. The optional <display-name>
element is the display name of the conference, which usually does not element is the display name of the conference, which usually does not
change over time. change over time.
<Free-text> and <Keywords> are optional elements. They provide <free-text> and <keywords> are optional elements. They provide
additional textual information about the conference. This information additional textual information about the conference. This
can be made available to potential conference participants by means information can be made available to potential conference
outside the scope of this document. Examples of usage could be participants by means outside the scope of this document. Examples
searching for a conference based on some keywords. The optional of usage could be searching for a conference based on some keywords.
<Web-page> element points to a URI where additional information about The optional <web-page> element points to a URI where additional
the conference can be found. information about the conference can be found.
The optional <Host-info> element contains several elements. It gives The optional <host-info> element contains several elements. It gives
additional information about the user hosting the conference. This additional information about the user hosting the conference. This
information can, for example, be included into the SDP fields of the information can, for example, be included into the SDP fields of the
SIP INVITEs sent by the focus. The <URI> element is optional and can SIP INVITE requests sent by the focus. The <uri> element is optional
occur more than once. and can occur more than once.
4.2.3 <Conference-time> element 4.3.3 Conference Time
The information related to conference time and lifetime is contained The information related to conference time and lifetime is contained
in the <Conference-time> element. The conference may occur for a in the <time> element. The conference may occur for a limited period
limited period of time (i.e. bounded), or the conference may be of time (i.e. bounded), or the conference may be unbounded (i.e. it
unbounded (i.e. it does not have a specified end time). Bounded does not have a specified end time). Bounded conferences may occur
conferences may occur multiple times(e.g. on weekly basis). multiple times(e.g. on weekly basis).
<Conference-Time> has its own XML namespace. It contains one or more The <time> element contains one or more <occurrence> elements each
<Conference-occurrence> elements each defining the time information defining the time information of a single conference occurrence.
of a single conference occurrence. Multiple <Conference-occurrence> Multiple <occurrence> elements MAY be used if a conference is active
elements MAY be used if a conference is active at multiple at multiple times; each additional <occurrence> element contains time
irregularly spaced times; each additional <Conference-occurrence> information for a specific occurrence.
element contains time information for a specific occurrence.
For each occurrence, the <Start-time> element specifies when a For each occurrence, the <mixing-start-time> element specifies when a
conference starts. the <Stop-time> element specifies the time a conference media mixing starts. the <mixing-stop-time> element
conference stops. If the <Start-time> element is not present, it specifies the time a conference media mixing stops. If the
indicates that the conference starts immediately. If the <Stop-time> <mixing-start-time> element is not present, it indicates that the
is set to zero, then conference occurrence is not bounded, i.e. conference media mixing starts immediately. If the
permanent, though it will not become active until the <Start-time>. <mixing-stop-time> element is not present, it indicates that the
If the <Stop-time> element is not present, it indicates that the conference occurrence is not bounded, i.e. permanent, though media
conference terminates as soon as the last participant leaves the mixing will not become active until the <mixing-start-time>.
conference. The focus might wait a small period of time before <mixing-start-time> and <mixing-stop-time> elements both have the
terminating the conference, in case a participant joins straight mandatory 'require-participant' attribute. This attribute has one of
after the last participant leaves. 3 values: "none", "key-participant", and "participant". For mixing
start time, this attribute allows a privileged user to define when
media mixing starts based on the latter of the mixing start time, and
the time the first participant or key participant arrives. If the
value is set to "none", mixing starts according to the mixing start
time. For mixing stop time, this attribute allows a privileged user
to define when media mixing stops based on the earlier of the mixing
stop time, and the time the last participant or key participant
leaves. If the value is set to "none", mixing stops according to the
mixing stop time.
When saying that a conference starts, or becomes active (start-time), Users can be allowed to join a conference before the media mixing
it means that the mixing starts. A focus will most likely allow time starts and after a certain time. A conference privileged user
participants to connect shortly before start time, but may put them can indicate the time when users can join by populating the
on hold until the start time. Participants on the Dial out list may <can-join-after> element. Similarly, a conference privileged user
also be dialled to shortly before start time. can define the time after which new users are not allowed to join the
conference anymore. This is done by populating the
<must-join-before> element.
A conference terminates with stop-time. The creator is free to set It is possible to define the time when users or resources on the
the stop-time to be the time s/he leaves (and therefore the dial-out list and on the refer-list are requested to join the
conference terminates when s/he leaves), terminate the conference as conference by using the <request-users> element. It is also possible
s/he leaves (modifying stop-time), or leave before the stop-time and to define that the users and resources on the dial-out list and the
therefore the conference continues. The stop-time can be changed by refer-list are requested to join the conference only after the first
the conference creator, during the conference, to allow the extension a participant or key participant has joined. This is achieved with
of the conference based on best effort. A conference always the 'require-participant' attribute. A value of "none" indicates
terminates when the conference policy is removed, regardless of the that the focus sends the requests immediately after the specified
stop time. time has lapsed.
The absence of this conference time information indicates that a The absence of this conference time information indicates that a
conference starts immediately and terminates when the conference conference starts immediately and terminates when the conference
policy is removed. See Section 6.9 for more details policy is removed. See Section 4.2 for more details.
4.2.4 <ACL> (Access Control List) element A running conference instance can be extended or stopped by modifying
the conference time information. Note that those conference times do
not guarantee resources for the conference to occur.
ACL has its own XML namespace. If a conference is in progress when deleted or stopped, the focus
issues signalling requests to terminate all conference related
sessions it has with participants. In SIP, the focus issues BYE
requests.
The purpose of Access Control List (ACL) is to control who can join 4.3.4 Conference Authorization Rules
the conference.A conference has one <ACL> consisting of one or more
<ACL-target-URI> elements and the <Access-type> parameter for those
URIs. Access-Types are one of Allowed/Blocked/Pending/Expelled.
Allowed means that the target is allowed to join the conference.
Blocked means that the target is not allowed to join the conference.
This can be used in the where the allowed URIs are wild-carded and
the user wants to explicitly block one potential participant, whose
URI falls within the wildcarded URIs, from joining. The other way
around is also possible where the blocked URIs are wildcarded and
the user wants to explicitly allow one potential participant, whose
URI falls within the wildcarded URIs, to join. Pending means that
authorisation for the target is not granted and while further
processing is required - such as consulting the moderator. Expelled
means that user is expelled from current conference and is not
allowed to join or be dialled-out (even if dial-out list includes
user's URI).
Wildcards are allowed in ACL as follows. The domain part is allowed One of the key components of conference policy is the set of
to be wildcard only if the username is a wildcard. Wildcard in the authorization rules that specify who is allowed to join a conference,
domain part MUST be immediately after the @-sign. A wildcard in the see floors and request/grant them, subscribe to
domain is interpreted as multiple zones. For example: conference-information notifications and so on. The unordered list
sip:*@*.example.com includes sip:*@engineering.example.com as well as of authorization rules together define the conference authorization
sip:*@tester.engineering.example.com. The use of wildcarding has been policy
restricted to avoid ambiguous entries in the access control list.
Examples of allowed wildcards are - sip:*@example.com, *@*.com, *@*. The conference authorization rules are enclosed in the
<authorization-rules> element and are formatted according to the XML
schema defined in the common policy framework [1]. In
<authorization-rules> element, there can be multiple rules, each rule
is represented by the <rule> element, each of which consist of three
parts: conditions, actions and transformations. Conditions determine
whether a particular rule applies to a request. Each action or
transformation in the applied rule is a positive grant of permission
to the conference participant. The details of each specific element
and attribute is described in [1].
Examples are not allowed wildcards are - sip:bob@example.*, Asking the focus to allow certain users to join the conference is
sip:bob@*.com, sip:*@example.*.com. achieved by modifying an existing authorization rule or creating a
new one. The CPS then informs the focus of such change.
"Most-specific expression wins" policy is used if overlapping rules If the conference is long-lasting, it is possible that new rules are
are found. Basically, this means that user specific rule is searched added all the time but old rules are almost never removed (some of
first and if it is not found, then most specific wildcard rule is them are overwritten, though). This leads easily to the situation
utilized. that the conference policy contains many unnecessary rules which are
not really needed anymore. Therefore, there is a need to delete
rules. This can be achieved by removing that portion of the policy.
There is a need for the ACL to contain an entry that defines the Conflicting rules may exist (for example, both allowed and blocked
default access types for users not explicitly allowed nor blocked action is defined for same target). The common policy directives [1]
from joining the conference, i.e. everybody else. For example: dictate the behaviour in such situations.
"Pending" action for *@*. If that entry is missing, the focus local
policy dictates the behaviour.
Sip: and sips: schemes are treated as equivalent in the ACL since it This section outlines the new conditions, actions and transformations
defines users and not the security used by users. for conference authorization policy.
It is also possible to ask the focus to refer users to the 4.3.4.1 Conditions
conference. An optional Boolean attribute "refer" exists in the
<ACL-target-URI> that indicates to the server that the creator of the
conference wishes for the focus to refer the identified potential
participants to the conference when a conference occurrence has
started. In SIP, this is achieved by the focus sending a REFER
request to those potential participants. The default value for the
"refer" attribute is "false".
4.2.5 <PCL> (Privilege Control List) element 4.3.4.1.1 Identity
Advanced privilege models can be applied in conferencing context 4.3.4.1.1.1 Interpreting the <id> Element
(e.g. who is allowed to modify ACL, who is allowed to expel users
etc). This document defines only one privilege and leaves the
definition of additional privileges (e.g. who can modify ACL) as a
separate standardisation effort.
The <PCL> element is mandatory and has its own XML namespace. It The <identity> element is already defined in the common policy
defines which users has what privileges. The <PCL> element may framework [1]. However, the rules for interpreting the identities in
contain one or more <PCL-target> elements. The <PCL-target> element <id> elements are left for each application to define separately.
carries 2 pieces of information: the target URI, <PCL-target-URI> and This document, however, does not define the rules for interpreting
the privileges for that URI, <Privileges>. All mandatory elements. identities in <id> elements in conferencing applications since those
interpretation rules are signalling protocol specific.
The target URI can be wildcarded as described for the ACL in Section OPEN ISSUE: Do we need to state more than this? How are identities
4.2.4. derived from users that join using POTS, H.323, etc.?
Example URIs are: 4.3.4.1.1.2 Matching Any Identity
sip:bob@company.com The <any> element is used to match any participant. This allows a
conference to be open to anyone.
sip:*@example.com 4.3.4.1.1.3 Matching Unauthenticated Identities
The only privilege defined in this document is The <unauthenticated> element is used to match unauthenticated
RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE. It defines which users are participants. That is, participants that have provided no
allowed to subscribe to the conference state event package [12]and authenticated identity to the conference focus.
be notified.
4.2.6 <DL> (Dial-Out List) element 4.3.4.1.1.4 Matching AnonymousIdentities
The <anonymous> element is used to match participants that have
provided an authenticated identity to the conference focus, but have
requested anonymity in the conference itself.
4.3.4.1.1.5 Matching Referred Identities
The <has-been-referred> element can be used to match those
participants that the focus has referred to the conference.
4.3.4.1.1.6 Matching Invited Identities
The <has-been-invited> element can be used to match those
participants that the focus has invited into the conference.
4.3.4.1.1.7 Matching Identities of Former Conference Participants
The <has-been-in-conference> element can be used to match those
participants that have joined the conference in the past.
4.3.4.1.1.8 Matching Identities Currently in the Conference
The <is-in-conference> element can be used to match those
participants that are currently participating in the conference.
4.3.4.1.1.9 Matching Key Participant Identities
The <key-participant> element can be used to match those participants
that are key participants of a conference.
4.3.4.1.1.10 Matching Identities on the Dial-out List
The <is-on-dialout-list> element can be used to match those
participants that are on the dial-out list.
4.3.4.1.1.11 Matching Identities on the Refer List
The <is-on-refer-list> element can be used to match those
participants that are on the refer list.
4.3.4.1.1.12 Floor ID
The <floor-id> element can be used to assign users as floor
moderators. It MUST be used in conjunction with the <id> element
that identifies the floor moderator. The <floor-id> element carries
the floor ID of the floor that the user is a moderator of. The
transformation <is-floor-moderator> is used to assert that the user
identified using the <id> condition is the floor moderator of the
floor identified in the <floor-id> condition.
4.3.4.1.1.13 Matching PIN Codes
The <pin> element can be used to match those participants that are
have knowledge on a PIN code for the conference. For example:
<rule id="1">
<conditions>
<pin>12345</pin>
</conditions>
<actions>
<join-handling>allow</join-handling>
</actions>
<transformations/>
</rule>
So the condition is the PIN. If any user knows the PIN, ignoring
their identity, the user is allowed to join.
A combination of the <identity> condition and the <pin> condition
creates the possibility of assigning users personal PIN codes to
enable them to join a conference. For example:
<rule id="2">
<conditions>
<identity>
<id>358401234567</id>
</identity>
<pin>67890</pin>
</conditions>
<actions>
<join-handling>allow</join-handling>
</actions>
<transformations/>
</rule>
4.3.4.1.1.14 Matching Passwords
The <password> element can be used to match those participants that
are have knowledge on a password for the conference. For example:
<rule id="3">
<conditions>
<password>pass1</password>
</conditions>
<actions>
<join-handling>allow</join-handling>
</actions>
<transformations/>
</rule>
So the condition is the password. If any user knows the password,
ignoring their identity, the user is allowed to join.
A combination of the <identity> condition and the <password>
condition creates the possibility of assigning users personal
passwords to enable them to join a conference. For example:
<rule id="4">
<conditions>
<identity>
<id>alice@example.com</id>
</identity>
<password>pass2</password>
</conditions>
<actions>
<join-handling>allow</join-handling>
</actions>
<transformations/>
</rule>
4.3.4.2 Actions
4.3.4.2.1 Conference State Events
The <allow-conference-state> element represents a boolean action. If
set to TRUE, the focus is instructed to allow the subscription to
conference state events, such as the SIP Event Package for Conference
State [14]. If set to FALSE, the subscription to conference state
events would be rejected.
If this element is undefined it has a value of TRUE, causing the
subscription to conference state events to be accepted.
OPEN ISSUE: Is a simple block/allow sufficient here, or should the
subscription handling be similar to e.g. presence, and have three
states (block, confirm, allow), or possibly even four states
(block, confirm, polite-block, allow)?
4.3.4.2.2 Floor Control Events
The <allow-floor-events> element represents a boolean action. If set
to TRUE, the focus is instructed to accept the subscription to floor
control events. If set to FALSE, the focus is instructed to reject
the subscription.
If this element is undefined, it has a value of FALSE, causing the
subscription to floor control events to be rejected.
OPEN ISSUE: Is a simple block/allow sufficient here, or should the
subscription handling be similar to e.g. presence, and have three
states (block, confirm, allow), or possibly even four states
(block, confirm, polite-block, allow)?
4.3.4.2.3 Conference Join Handling
The "join-handling" element defines the actions used by the
conference focus to control conference participation. This element
defines the action that the focus is to take when processing a
particular request to join a conference. This element is an
enumerated integer type, with defined values of:
block: This action instructs the focus to deny access to the
conference. This action has a value of zero and it is the lowest
value of the "join-handling" element. This action is the default
action taken in the absence of any other actions.
confirm: This action instructs the focus to place the participant on
a pending list (e.g., by parking the call on a music-on-hold
server), awaiting moderator input for further actions. This
action has a value of one.
allow: This action instructs the focus to accept the conference join
request and grant access to the conference within the instructions
specified in the transformations of this rule. This action has a
value of two.
Note that placing a value of block for this element doesn't guarantee
that a participant is blocked from joining the conference. Any other
rule that might evaluate to true for this participant that carried an
action whose value was higher than block would automatically grant
confirm/allow permission to that participant.
4.3.4.2.4 Dynamically Referring Users
The <allow-refer-users-dynamically> element represents a boolean
action. If set to TRUE, the identity is allowed to instruct the
focus to refer a user to the conference without modifying the
refer-list (in SIP terms, the identity is allowed to send a REFER
request to the focus which results in the focus sending a REFER
request to the user the referrer wishes to join the conference). If
set to FALSE, the refer request is rejected.
If this element is undefined it has a value of FALSE, causing the
refer to be rejected.
4.3.4.2.5 Dynamically Inviting Users
The <allow-invite-users-dynamically> element represents a boolean
action. If set to TRUE, the identity is allowed to instruct the
focus to invite a user to the conference without modifying the
dial-out list (in SIP terms, the identity is allowed to send a REFER
request to the focus which results in the focus sending an INVITE
requested to the user the referrer wishes to join the conference).
If set to FALSE, the refer request is rejected.
If this element is undefined it has a value of FALSE, causing the
refer to be rejected.
4.3.4.2.6 Modifying Conference setting
The <allow-modify-settings> element represents a boolean action. If
set to TRUE, the identity is allowed to modify the conference
settings in the conference policy. If set to FALSE, any
modifications to the conference settings are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.4.2.7 Modifying Conference Information
The <allow-modify-information> element represents a boolean action.
If set to TRUE, the identity is allowed to modify the conference
information in the conference policy. If set to FALSE, any
modifications to the conference information are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.4.2.8 Modifying Conference Time
The <allow-modify-time> element represents a boolean action. If set
to TRUE, the identity is allowed to modify the conference time in
the conference policy. If set to FALSE, any modifications to the
conference time are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.4.2.9 Modifying Authorization rules
The <allow-modify-authorization-rules> element represents a boolean
action. If set to TRUE, the identity is allowed to modify the
authorization rules of a conference in the conference policy. If set
to FALSE, any modifications to the rules are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.4.2.10 Modifying Conference Dial-out List
The <allow-modify-dol> element represents a boolean action. If set
to TRUE, the identity is allowed to modify the conference dial-out
list in the conference policy. If set to FALSE, any modifications to
the dial-out list are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.4.2.11 Modifying Conference Refer List
The <allow-modify-rl> element represents a boolean action. If set to
TRUE, the identity is allowed to modify the conference refer list in
the conference policy. If set to FALSE, any modifications to the
refer list are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.4.2.12 Modifying Conference Security Control
The <allow-modify-sc> element represents a boolean action. If set to
TRUE, the identity is allowed to modify the conference security
control settings in the conference policy. If set to FALSE, any
modifications to the security control settings are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.4.2.13 Modifying Conference Floor Policy
The <allow-modify-fp> element represents a boolean action. If set to
TRUE, the identity is allowed to modify the conference floor policy
in the conference policy. If set to FALSE, any modifications to the
floor policy are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.4.2.14 Modifying Conference media streams
The <allow-modify-ms> element represents a boolean action. If set to
TRUE, the identity is allowed to modify the conference media streams
in the conference policy. If set to FALSE, any modifications to the
media streams are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.4.2.15 Creating Sidebars
The <allow-sidebar> element represents a boolean action. If set to
TRUE, the identity is allowed to create and manipulate a sidebar by
creating and modifying a <sidebar> element in a conference policy.
If set to FALSE, any sidebar creation and manipulation is rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.4.2.16 Modifying Conference Dial-in List
The conference dial-in list is virtual and is not represented by a
physical list in the conference policy. It is rather a collection of
authorization rules that allow users to join a conference. The
<allow-modify-dil> element represents a boolean action. If set to
TRUE, the identity is allowed to create an authorization rule in the
conference policy that give a user a join handling of "allow" (See
Section 4.3.4.2.3. If set to FALSE, any modifications to
authorization rules are rejected.
If this element is undefined it has a value of FALSE, causing the
modifications to be rejected.
4.3.4.2.17 Authenticating a User
The <authenticate> element defines the mechanism used by the
conference focus to authenticate a user. This element is an
enumerated integer type, with defined values of:
none: This action instructs the focus not to authenticate the user.
This action has a value of zero and it is the lowest value of the
<authenticate-user> element. This action is the default action
taken in the absence of any other actions.
asserted-id: This action instructs the focus to authenticate the
user by asserting their identity using means outside the scope of
this document (for example, using digest-AKA). This action has a
value of one.
shared-secret: This action instructs the focus to authenticate the
user using a shared secret (for example, using digest). This
action has a value of two.
certificate: This action instructs the focus to authenticate the
user using a certificate (for example, using PGP). This action
has a value of three.
4.3.4.3 Transformations
4.3.4.3.1 Key Participant
When the <is-key-participant> element is set to TRUE, the joining
participant is denoted as a key participant. If set to FALSE, the
participant is not denoted as a key participant.
If this element is undefined, it has a value of FALSE, causing no key
participant status to be given to the participant.
4.3.4.3.2 Floor Moderator
When the <is-floor-moderator> element is set to TRUE, the joining
conference participant is denoted as floor moderator, meaning that
they are privileged to control the floor in the conference. If set
to FALSE, floor moderator privileges are not given to the conference
participant.
If this element is undefined, it has a value of FALSE, causing no
floor moderator privileges to being granted.
4.3.4.3.3 Conference Information
The <show-conference-info> element is of type boolean transformation.
If set to TRUE, conference information is shown to the conference
participant. If set to FALSE, conference information is not shown to
the participant.
The <show-conference-info> element controls whether information in
the <settings>, <time> and <info> elements may be made available
publicly. For example, an application at a conference server might
list the ongoing conferences on web page, or it may allow searching
for conferences based on the keywords listed in the <Conference-info>
element. Not setting this transformation to any users instructs the
application not to reveal any such information to any user. However,
information in other elements, such as <dialout-list>, should not be
seen by anyone else other than a privileged user, even with this
transformation enabled for a user.
If this element is undefined, it has a value of FALSE, causing no
conference information to being shown.
OPEN ISSUE: Do we require more granularity for this element?
Perhaps an enumerated integer type, with defined levels of
information about the conference, or a set of boolean
transformations, each granting a single piece of conference
information, like the ability to see "sidebar" elements?
4.3.4.3.4 Floor Holder
The <show-floor-holder> element is of type boolean transformation.
If set to TRUE, the conference participant is able to see who is
currently holding the floor. If set to FALSE, the participant is not
able to see the floor holder.
If this element is undefined, it has a value of FALSE, causing the
floor holder not be shown to the participant.
4.3.4.3.5 Floor Requests
The <show-floor-requests> element is of type boolean transformation.
If set to TRUE, the conference participant is able to see the floor
requests. If set to FALSE, the conference participant is not able to
see floor requests.
If this element is undefined, it has a value of FALSE, causing the
floor requests to not being seen by the conference participant.
4.3.5 Conference Dial-Out List
The dial-out list (DL) is a list of user URIs that the focus uses to The dial-out list (DL) is a list of user URIs that the focus uses to
learn who to invite to join a conference. This list can be updated learn who to invite to join a conference. This list can be created
during the conference lifetime so it can be used for mid-conference at conference policy creation time or updated during the conference
invites (and mass-invites) as well. lifetime so it can be used for mid-conference invites (and
mass-invites) as well.
DL has its own XML namespace. Asking the focus to invite (add) a user into the conference is
achieved by adding that user's URI to the Dial-Out List (DL). The
CPS then triggers the focus to send the conference invitation, eg:
SIP INVITE as needed. Similarly, a user can be removed from the
Dial-out list by removing the URI from the dial-out list.
The <DL> element includes a mandatory <DL-target> element. The The <dialout-list> element is optional and includes zero or more
<DL-target> element includes the mandatory <DL-target-URI> element. <target> elements. The <target> element includes the mandatory 'uri'
This elements carries the URI of the user to be invited. attribute. The <target> element can be extended.
4.2.7 <SC> (Security Control) element 4.3.6 Conference Refer List
The conference security encompasses three aspects: controlling the The refer list (RL) contains a list of resources that the focus needs
visibility of a conference, securing the SIP messages, and performing to refer to the conference. In SIP, this is achieved by the focus
authentication for individual users. sending a REFER request to those potential participants. This list
can be updated during the conference lifetime so it can be used for
mid-conference refers as well.
This element has its own XML namespace. The <refer-list> element is optional and identical to the
<dialout-list> element in Section 4.3.5.
The conference security settings start with the mandatory >SC> 4.3.7 Conference Security Control
element. It contains the mandatory <Visibility> element. This element
can hold one of two values: visible or invisible. The <Visibility> The conference security currently encompasses one aspects: the
element controls whether information in the <Conference-URI>, integrity and confidentiality of the signalling messages.
<Conference-time> and <Conference-info> elements may be made
available publicly. For example, an application at a conference The conference security settings start with the optional
server might list the ongoing conferences on web page, or it may <security-control> element.
allow searching for conferences based on the keywords listed in the
<Conference-info> element. Setting <Visibility> to "invisible"
instructs the application not to reveal any such information.
However, information in other elements, such as <ACL>, should not be
seen by anyone else other than a privileged user, even with the
<Visibility> element set to "visible".
We define two mechanisms for securing the signaling between users and We define two mechanisms for securing the signaling between users and
the focus: TLS and S/MIME. TLS is used to provide transport layer the focus: TLS and S/MIME. TLS is used to provide transport layer
security on a hop-by-hop basis. According to SIP [6], using SIPS URI security on a hop-by-hop basis. According to SIP [5], using SIPS URI
scheme in a request signifies that TLS must be used to secure each scheme in a request signifies that TLS must be used to secure each
hop over which the request is forwarded until the request reaches the hop over which the request is forwarded until the request reaches the
SIP entity responsible for the domain portion of the Request-URI. SIP entity responsible for the domain portion of the Request-URI.
The <Security-mechanism>element inside the <SC> element has 2 boolean The <security-mechanism> element inside the <security-control>
parameter: TLS and S/MIME. When in TLS parameter is set to "true" element has 2 boolean attributes: 'tls' and 's-mime'. When the 'tls'
(thus implying the use of SIPS URI scheme, if SIP is used as the attribute is set to "true" (thus implying the use of SIPS URI scheme,
signaling protocol), it is required that TLS is used end-to-end. In if SIP is used as the signaling protocol), it is required that TLS is
other words, TLS must be used also on the last hop between the entity used end-to-end. In other words, TLS must be used also on the last
responsible for the domain portion of the Request-URI and the hop between the entity responsible for the domain portion of the
conference policy server. Request-URI and the conference policy server.
If end-to-end confidentiality of entire SIP messages is not required If end-to-end confidentiality of entire signalling protocol messages
by the conference policy, but it is required that the message bodies is not required by the conference policy, but it is required that the
within SIP are encrypted, the S/MIME attribute must have a value message bodies within the signalling protocol messages are encrypted,
"true". the 's-mime' attribute must have a value "true".
TLS and S/MIME may be required independent of each other. In other TLS and S/MIME may be required independent of each other. In other
words, it may be required to use neither, one, or both depending on words, it may be required to use neither, one, or both depending on
the settings of these parameters. the settings of these attributes.
The conference creator can define an authentication policy for the
participants. This is done with the optional <SC-target> element.
If the <SC-target> element is present, then at least one
<SC-target-URI> inside the <SC-target> element must be present, each
identifies a user or a set of users for which the authentication
mechanism apply. The target URI can be wildcarded as described for
the ACL in Section 4.2.4.
The authentication policy defined in the optional 4.3.8 Conference Floor Policy
<Authorization-mechanism> element defines how the participants should
be authenticated. Two authentication mechanisms are defined in this
document: Digest and Digest-AKA. The authentication policy can also
be set to none. The password associated with each user in the Digest
authentication is included in the optional <Password> attribute. This
attribute is ignored if authentication is set to "none".
4.2.8 <Conference-floor-policy> element The absence of the <floor-policy> element from an XML document
indicates that the conference does not have a floor.
This element has its own XML namespace. The absence of this namespace One or more <floor> elements can appear in the <floor-policy>
and its elements from an XML document indicates that the conference element. The number of those elements indicates how many floors the
does not have a floor. conference can have. The <floor> element contains the required
'floor-control' attribute that uniquely identifies a floor and
indicates the floor control protocol URI. It also contains the
required boolean attribute 'moderator-controlled' that indicates if
the floor is moderator controlled or not.
The <Conference-floor-policy> is mandatory and contains the required A floor can be used for one or more media streams; the mandatory
boolean attribute that indicates if the floor is moderator controlled <media-streams> element can contain zero or more of the <video>,
or not. One or more <Floor> elements can appear in the <audio>, <application>, <data> ,<control>, <message>, and <text>
<Conference-floor-policy> element. The number of those elements elements indicating the media of the floor. Other media types can be
indicates how many floors the conference can have. A floor can be defined by extensions. Each media stream is identified with the
used for one or more media types; the mandatory <Media-types> element 'media-id' attribute. This attribute is mandatory and MUST be unique
can contain zero or more of the <Video>, <Audio>, <Application>, for all media streams in a conference. It is used to correlate the
<Data> ,<Control>, <Message>, and <text> elements indicating the conference media stream in Section 4.3.9 with the ones for a floor.
media of the floor. One type of media can only appear once. Other It is also used to correlate the media streams used in the signalling
media types can be defined by extensions. protocols with those in the conference policy, used, for example, in
SDP "i" field [19].
A floor can be controlled using many algorithms; the mandatory A floor can be controlled using many algorithms; the mandatory
<Algorithm> element MUST contain one and only of the <algorithm> element MUST contain one and only of the
<Moderator-controlled>, <FCFS>, and <Random> elements indicating the <moderator-controlled>, <fcfs>, and <random> elements indicating the
algorithm. algorithm.
The <Max-floor-users> element in the <Floor> element is optional and, The <max-floor-users> element in the <floor> element is optional and,
if present, dictates the maximum number of users who can have the if present, dictates the maximum number of users who can have the
floor at one time. The optional <Moderator-URI> indicates the URI of floor at one time. The optional <moderator-uri> indicates the URI of
the moderator. It MUST be set if the attribute moderator-controlled the moderator. It MUST be set if the attribute moderator-controlled
is set to "true". is set to "true".
4.2.9 <Conference-media-Policy> element 4.3.9 Conference Media Streams
Media policy is an integral part of the conference policy. It defines Media policy is an integral part of the conference policy. It
e.g. what kind of media topologies exist in the conference. This defines e.g. what kind of media topologies exist in the conference.
document defines a very basic media policy that states the media Media policy is documented in [18].This document does not define
types a conference has. This is used by the focus to know what media media policy, but instead enables the user to specify the media
types to invite users with and what media types it should accept from streams a conference has. This is used by the focus to know what
dialling in users. The details of media manipulation are defined media streams to invite users with and what media streams it should
elsewhere. User with sufficient privileges is allowed to create, accept from dialling in users. The details of media manipulation are
modify and delete the media policy (e.g. add new media types). defined elsewhere. User with sufficient privileges is allowed to
create, modify and delete the media policy (e.g. add new media
types).
This element has its own XML namespace. The definition starts with the optional <media-streams> element.
This element lists the media streams allowed for this conference.
The format of this mirrors that of the <media-streams> element in
floor policy in Section 4.3.8. The absence of this element indicates
that the conference will use media according to the focus local
policy.
The definition starts with the mandatory <Conference-media-policy> 4.4 XML Schema Extensibility
element. This element contains a mandatory <Media-types> element that
lists the media types allowed for this conference. The format of this
mirrors that of the same element in floor policy.
4.3 XML Schema The schema as be extended at multiple places:
o The <conference> element to enable more conference policy
information to be added
o The <settings> element to allow for future conference settings to
be defined
o The <info> element to allow further conference and host
information to be conveyed
o The <occurrence> element to allow further conference timing
information
o The <target> element in <dialout-list> and <refer-list> to allow
extensions on the behaviour of the focus. For example, how many
times to retry inviting a user
o The <security-control> element to allow new security setting for a
conference to be introduced into
o The <algorithm> element in <floor-policy> to allow new algorithms
to be introduced into how a floor is granted
o The <floor> element in <floor-policy> to allow extensions to floor
policy for a floor
o The <media-streams> element to allow introduction of new media
streams
o The <sidebar> element to allow introduction of new sidebar
information
4.5 XML Schema
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-policy" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:conference-policy" elementFormDefault="qualified">
targetNamespace="urn:ietf:params:xml:ns:conference-policy" <!-- This import brings in the XML language attribute xml:lang-->
xmlns:conference-mp="urn:ietf:params:xml:ns:conference-mp" <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
xmlns:conference-fp="urn:ietf:params:xml:ns:conference-fp" <!-- The root Conference Element -->
xmlns:conference-sc="urn:ietf:params:xml:ns:conference-sc" <xs:element name="conference">
xmlns:conference-dl="urn:ietf:params:xml:ns:conference-dl"
xmlns:conference-pcl="urn:ietf:params:xml:ns:conference-pcl"
xmlns:conference-acl="urn:ietf:params:xml:ns:conference-acl"
xmlns:conference-time="urn:ietf:params:xml:ns:conference-time"
xmlns:conference-info="urn:ietf:params:xml:ns:conference-info"
xmlns:conference-settings="urn:ietf:params:xml:ns:conference-settings"
elementFormDefault="qualified">
<xs:import namespace="urn:ietf:params:xml:ns:conference-settings" schemaLocation="conference-settings.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-info" schemaLocation="conference-info.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-time" schemaLocation="conference-time.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-acl" schemaLocation="conference-acl.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-pcl" schemaLocation="conference-pcl.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-dl" schemaLocation="conference-dl.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-sc" schemaLocation="conference-sc.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-fp" schemaLocation="conference-fp.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:conference-mp" schemaLocation="conference-mp.xsd"/>
<xs:element name="Conference">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="Conference-Settings" type="conference-settings:conference-settings"/> <xs:element name="settings" type="ConferenceSettings"/>
<xs:element name="Conference-Info" type="conference-info:Conference-Info"/> <xs:element name="info" type="ConferenceInfo" minOccurs="0"/>
<xs:element name="Conference-Time" type="conference-time:Conference-Time"/> <xs:element name="time" type="ConferenceTime" minOccurs="0"/>
<xs:element name="ACL" type="conference-acl:Conference-ACL"/> <xs:element name="authorization-rules" type="ConferenceAuthorizationRules" minOccurs="0"/>
<xs:element name="PCL" type="conference-pcl:Conference-PCL"/> <xs:element name="dailout-list" type="Target" minOccurs="0"/>
<xs:element name="DL" type="conference-dl:Conference-DL"/> <xs:element name="refer-list" type="Target" minOccurs="0"/>
<xs:element name="SC" type="conference-sc:Conference-SC"/> <xs:element name="security-control" type="ConferenceSC" minOccurs="0"/>
<xs:element name="Conference-floor-policy" type="conference-fp:Conference-Floor-Policy"/> <xs:element name="floor-policy" type="ConferenceFloorPolicy" minOccurs="0"/>
<xs:element name="Conference-media-policy" type="conference-mp:Conference-Media-Policy"/> <xs:element name="media-streams" type="ConferenceMediaStreams" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> <!-- Conference Settings -->
<xs:complexType name="ConferenceSettings">
<!-- Conference settings -->
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-settings"
xmlns="urn:ietf:params:xml:ns:conference-settings"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:complexType name="Conference-settings">
<xs:sequence> <xs:sequence>
<xs:element name="Conference-uri" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="conference-uri" type="xs:anyURI" minOccurs="1" maxOccurs="unbounded"/>
<xs:element name="Max-participant-count" type="xs:nonNegativeInteger" minOccurs="0"/> <xs:element name="max-participant-count" type="xs:nonNegativeInteger" minOccurs="0"/>
<xs:element name="allow-sidebars" type="xs:boolean" default="true" minOccurs="0"/>
<xs:element name="sidebar" type="Sidebar" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema>
<!-- Conference Info --> <!-- Conference Info -->
<xs:complexType name="ConferenceInfo">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:complexType name="Conference-info">
<xs:sequence> <xs:sequence>
<xs:element name="Subject" type="xs:string" minOccurs="0"/> <xs:element name="subject" type="xs:string" minOccurs="0"/>
<xs:element name="Display-name" type="xs:string" minOccurs="0"/> <xs:element name="display-name" type="xs:string" minOccurs="0"/>
<xs:element name="Free-text" type="xs:string" minOccurs="0"/> <xs:element name="free-text" type="xs:string" minOccurs="0"/>
<xs:element name="Keywords" minOccurs="0"> <xs:element name="keywords" minOccurs="0">
<xs:simpleType> <xs:simpleType>
<xs:list itemType="xs:string"/> <xs:list itemType="xs:string"/>
</xs:simpleType> </xs:simpleType>
</xs:element> </xs:element>
<xs:element name="Web-page" type="xs:anyURI" minOccurs="0"/> <xs:element name="web-page" type="xs:anyURI" minOccurs="0"/>
<xs:element name="Host-info" minOccurs="0"> <xs:element name="host-info" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="URI" type="xs:anyURI" minOccurs="0"/> <xs:element name="uri" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="E-mail" type="xs:anyURI" minOccurs="0"/> <xs:element name="e-mail" type="xs:anyURI" minOccurs="0"/>
<xs:element name="Web-page" type="xs:anyURI" minOccurs="0"/> <xs:element name="web-page" type="xs:anyURI" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute ref="xml:lang"/> <xs:attribute ref="xml:lang"/>
</xs:complexType> </xs:complexType>
</xs:schema>
<!-- Conference time --> <!-- Conference time -->
<xs:complexType name="ConferenceTime">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-time"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:complexType name="Conference-Time">
<xs:sequence> <xs:sequence>
<xs:element name="Conference-occurrence" minOccurs="0" maxOccurs="unbounded"> <xs:element name="occurrence" minOccurs="0" maxOccurs="unbounded">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="Start-time" type="xs:dateTime" minOccurs="0"/> <xs:element name="mixing-start-time" type="StartStopTime" minOccurs="0"/>
<xs:element name="Stop-time" type="xs:dateTime" minOccurs="0"/> <xs:element name="mixing-stop-time" type="StartStopTime" minOccurs="0"/>
<xs:element name="can-join-after" type="xs:dateTime" minOccurs="0"/>
<xs:element name="must-join-before" type="xs:dateTime" minOccurs="0"/>
<xs:element name="request-users" type="StartStopTime" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> <!-- Conferenece Authorisation -->
<xs:complexType name="ConferenceAuthorizationRules">
<!-- Access Control List ACL -->
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-acl"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:complexType name="Conference-ACL">
<xs:sequence> <xs:sequence>
<xs:element name="ACL-target-URI" maxOccurs="unbounded"> <xs:element name="rule" type="ruleType" minOccurs="0" maxOccurs="unbounded"/>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="Refer" type="xs:boolean" default="false"/>
<xs:attribute name="Access-type" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Allowed"/>
<xs:enumeration value="Blocked"/>
<xs:enumeration value="Pending"/>
<xs:enumeration value="Expelled"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> <xs:complexType name="ruleType">
<!-- Privilege Control List (PCL) -->
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:conference-pcl"
elementFormDefault="qualified">
<xs:complexType name="Conference-PCL">
<xs:sequence> <xs:sequence>
<xs:element name="PCL-target" minOccurs="1" maxOccurs="unbounded"> <xs:element name="conditions" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="PCL-target-uri" type="xs:anyURI" minOccurs="1"/> <xs:element ref="condition" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Privileges">
<xs:simpleType>
<xs:list>
<!-- Define the privileges as data type with all possible values -->
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
</xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="actions" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="action" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:element>
<xs:element name="transformations" minOccurs="0">
<!-- Dial-Out List (DL) -->
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-dl"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:complexType name="Conference-DL">
<xs:sequence>
<xs:element name="DL-target" maxOccurs="unbounded">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="DL-target-URI" type="xs:anyURI"/> <xs:element ref="transformation" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType> </xs:complexType>
</xs:schema> <xs:element name="condition" abstract="true"/>
<xs:element name="action" abstract="true"/>
<!-- Security Control (SC) --> <xs:element name="transformation" abstract="true"/>
<xs:element name="identity" substitutionGroup="condition">
<?xml version="1.0" encoding="UTF-8"?> <xs:complexType>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-sc" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:choice>
<xs:complexType name="Conference-SC"> <xs:element name="id" type="xs:anyURI"/>
<xs:sequence> <xs:sequence>
<xs:element name="Visibility"> <xs:element name="domain" type="xs:string"/>
<xs:sequence minOccurs="0">
<xs:element name="except" type="xs:anyURI" maxOccurs="unbounded"/>
</xs:sequence>
</xs:sequence>
<xs:sequence>
<xs:element name="any" type="xs:string"/>
<xs:sequence minOccurs="0">
<xs:element name="except" type="xs:anyURI" maxOccurs="unbounded"/>
</xs:sequence>
</xs:sequence>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="unauthenticated" type="xs:string" substitutionGroup="condition"/>
<xs:element name="anonymous" type="xs:string" substitutionGroup="condition"/>
<xs:element name="has-been-referred" type="xs:string" substitutionGroup="condition"/>
<xs:element name="has-been-invited" type="xs:string" substitutionGroup="condition"/>
<xs:element name="has-been-in-conference" type="xs:string" substitutionGroup="condition"/>
<xs:element name="is-in-conference" type="xs:string" substitutionGroup="condition"/>
<xs:element name="key-participant" type="xs:string" substitutionGroup="condition"/>
<xs:element name="is-on-dialout-list" type="xs:string" substitutionGroup="condition"/>
<xs:element name="is-on-refer-list" type="xs:string" substitutionGroup="condition"/>
<xs:element name="floor-id" type="xs:anyURI" substitutionGroup="condition"/>
<xs:element name="pin" type="xs:anyURI" substitutionGroup="condition"/>
<xs:element name="password" type="xs:anyURI" substitutionGroup="condition"/>
<xs:element name="allow-conference-state" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="allow-floor-events" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="join-handling" substitutionGroup="action">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="visible"/> <xs:enumeration value="block"/>
<xs:enumeration value="invisible"/> <xs:enumeration value="allow"/>
<xs:enumeration value="confirm"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:element> </xs:element>
<xs:element name="Security-mechanism"> <xs:element name="allow-refer-users-dynamically" type="xs:boolean" substitutionGroup="action"/>
<xs:complexType> <xs:element name="allow-invite-users-dynamically" type="xs:boolean" substitutionGroup="action"/>
<xs:attribute name="TLS" type="xs:boolean" default="false"/> <xs:element name="allow-modify-settings" type="xs:boolean" substitutionGroup="action"/>
<xs:attribute name="S-MIME" type="xs:boolean" default="false"/> <xs:element name="allow-modify-information" type="xs:boolean" substitutionGroup="action"/>
</xs:complexType> <xs:element name="allow-modify-time" type="xs:boolean" substitutionGroup="action"/>
</xs:element> <xs:element name="allow-modify-authorization-rules" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="SC-target" minOccurs="0" maxOccurs="unbounded"> <xs:element name="allow-modify-dol" type="xs:boolean" substitutionGroup="action"/>
<xs:complexType> <xs:element name="allow-modify-rl" type="xs:boolean" substitutionGroup="action"/>
<xs:sequence> <xs:element name="allow-modify-sc" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="SC-target-URI" type="xs:anyURI"/> <xs:element name="allow-modify-fp" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="Authorization-mechanism"> <xs:element name="allow-modify-ms" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="allow-sidebar" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="allow-modify-dil" type="xs:boolean" substitutionGroup="action"/>
<xs:element name="authenticate" substitutionGroup="action">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="Digest"/> <xs:enumeration value="none"/>
<xs:enumeration value="Digest-AKA"/> <xs:enumeration value="digest-aka"/>
<xs:enumeration value="None"/> <xs:enumeration value="digest"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:element> </xs:element>
<xs:element name="is-key-participant" type="xs:boolean" substitutionGroup="transformation"/>
<xs:element name="is-floor-moderator" type="xs:boolean" substitutionGroup="transformation"/>
<xs:element name="show-conference-info" type="xs:boolean" substitutionGroup="transformation"/>
<xs:element name="show-floor-holder" type="xs:boolean" substitutionGroup="transformation"/>
<xs:element name="show-floor-requests" type="xs:boolean" substitutionGroup="transformation"/>
<!-- Target -->
<xs:complexType name="Target">
<xs:sequence>
<xs:element name="target" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Password" type="xs:string"/> <xs:attribute name="uri" type="xs:anyURI" use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> <!-- Security Control (SC) -->
<xs:complexType name="ConferenceSC">
<!-- Floor policy -->
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-fp" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:complexType name="Conference-floor-policy">
<xs:sequence>
<xs:element name="Floor" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="Media-types"> <xs:element name="security-mechanism">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:attribute name="tls" type="xs:boolean" default="false"/>
<xs:element name="Video" minOccurs="0"/> <xs:attribute name="s-mime" type="xs:boolean" default="false"/>
<xs:element name="Audio" minOccurs="0"/> </xs:complexType>
<xs:element name="Application" minOccurs="0"/> </xs:element>
<xs:element name="Data" minOccurs="0"/>
<xs:element name="Control" minOccurs="0"/>
<xs:element name="Message" minOccurs="0"/>
<xs:element name="Text" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> <!-- Conference Floor Control Policy -->
<xs:element name="Algorithm"> <xs:complexType name="ConferenceFloorPolicy">
<xs:sequence>
<xs:element name="floor" maxOccurs="unbounded">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="Moderator-controlled" minOccurs="0"/> <xs:element name="media-streams" type="ConferenceMediaStreams"/>
<xs:element name="FCFS" minOccurs="0"/> <xs:element name="algorithm">
<xs:element name="Random" minOccurs="0"/> <xs:complexType>
<xs:sequence>
<xs:element name="moderator-controlled" minOccurs="0"/>
<xs:element name="fcfs" minOccurs="0"/>
<xs:element name="random" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="Max-floor-users" type="xs:nonNegativeInteger" minOccurs="0"/> <xs:element name="max-floor-users" type="xs:nonNegativeInteger" minOccurs="0" default="1"/>
<xs:element name="Moderator-URI" type="xs:anyURI" minOccurs="0"/> <xs:element name="moderator-URI" type="xs:anyURI" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="floor-control" type="xs:anyURI"/>
<xs:attribute name="moderator-controlled" type="xs:boolean" default="false"/> <xs:attribute name="moderator-controlled" type="xs:boolean" default="false"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> <!-- Conference Media Streams -->
<xs:complexType name="ConferenceMediaStreams">
<!-- Media policy-->
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:conference-mp" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="Conference-Media-Policy">
<xs:complexType>
<xs:sequence>
<xs:element name="Media-types">
<xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="Video" minOccurs="0"/> <xs:element name="video" type="Media" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Audio" minOccurs="0"/> <xs:element name="audio" type="Media" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Application" minOccurs="0"/> <xs:element name="application" type="Media" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Data" minOccurs="0"/> <xs:element name="data" type="Media" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Control" minOccurs="0"/> <xs:element name="control" type="Media" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Message" minOccurs="0"/> <xs:element name="message" type="Media" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Text" minOccurs="0"/> <xs:element name="text" type="Media" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> <!-- Start/Stop time -->
<xs:complexType name="StartStopTime">
<xs:simpleContent>
<xs:extension base="xs:dateTime">
<xs:attribute name="required-participant" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="key-participant"/>
<xs:enumeration value="participant"/>
<xs:enumeration value="none"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- Sidebar -->
<xs:complexType name="Sidebar">
<xs:sequence>
<xs:element name="uri" type="xs:anyURI" minOccurs="1" maxOccurs="unbounded"/>
<xs:element name="policy" type="xs:anyURI" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
<!-- Media -->
<xs:complexType name="Media">
<xs:attribute name="media-id" type="xs:string" use="required"/>
</xs:complexType> </xs:complexType>
</xs:element>
</xs:schema> </xs:schema>
5. Floor Control Policy vs. Floor Control Protocol 5. Conference Policy Manipulation and Conference Entity Behaviour
5.1 Overview of Operation
This document assumes that the user knows the location of conference
policy serve, the details of that discovery are beyond the scope of
this document.
CPCP allows clients to manipulate the conference policy at conference
policy server (CPS). CPS is able to inform the focus about changes
in conference policy, if necessary. For example, if new users are
added to the dial-out list, then conference policy server informs the
focus which makes the invitations as requested.
Some assumptions about the conferencing architecture are made.
Clients always connect to the conference policy server (CPS) when
they perform manipulation operations. It is assumed that the CPS
informs other conferencing entities, such as focus, the floor control
server and the mixer directly or via the focus. For example, if user
A wants to expel user B from an ongoing conference, user A must first
manipulate the conference policy data. The CPS then communicates
that change to the focus to perform the operation.
5.2 Use of External Lists
External lists MAY be used in a conference policy. They can be used
in the dial-out list, the refer-list and the authorization policy.
An external list is a list of resources created by means outside the
scope of this document.
A privileged user of the conference policy uses an external list by
placing its manipulation URI in an element that carries a URI. At
the time the focus needs to activate the policy surrounding the URI,
the focus fetches the URIs for the members of the external list using
the list URI. For example, a conference creator creates a conference
and places the URI of an external list in the dial-out list. At some
point, the focus needs to invite using on the dial-out list to join
the conference. It is at that moment that the focus retrieves the
members of the external list. It then sends INVITE (in SIP terms) to
the members of that external list. This results in all participants
connected to one focus.
In can happen that the external list is not accessible at the time
the focus requires it. In this case, the external list is ignored,
and in the case of an authorization rule, that rule fails.
There are also cases where the external list has been manipulated.
It is outside the scope of this document how the focus can learn of
such manipulation. But if is does, it reacts in a similar manner as
it would have if the list was local and has been modified.
If an external list contains a reference to yet another list, that
reference is ignored.
5.3 Communication Between Conference Entities
The communication between different (logical) conferencing elements
is beyond the scope of this document. It can be expected that in
most cases CPS includes also those logical functions.
5.4 Manipulating Participant Lists
A user with sufficient privileges is allowed to perform user
management operations, such as adding a new user to the conference or
expelling a user from the conference. These operations are performed
by modifying the conference policy at the conference policy server.
After authorising the user to do such manipulations, the conference
policy server communicates the change to the focus. The focus reacts
by performing singlling operations such as sending SIP INVITE, BYE or
REFER.
5.4.1 Expelling a Participant
Expelling a user is performed by a privileged user creating or
manipulating an existing authorization rule and setting that user's
<join-handling> action to "block>. The focus reacts by terminating
the session with that participant, such as a sending SIP BYE request.
Care must be taken since if one rules allows a user to join and one
blocks a user from joining, the result in that the user is allowed to
join. For example, Bob can join a conference since an authorization
rule has been defined to allow everyone at example.com:
<rule id="1">
<conditions>
<identity>
<domain>example.com</domain>
</identity>
</conditions>
<actions>
<join-handling>allow</join-handling>
</actions>
<transformations/>
</rule>
Setting the following rule will not block Bob from joining nor will
it expel him since the above rule overrides it:
<rule id="2">
<conditions>
<identity>
<uri>bob@example.com</uri>
</identity>
</conditions>
<actions>
<join-handling>block</join-handling>
</actions>
<transformations/>
</rule>
So, in order to expel Bob, the original rule has to be modified using
the <except> element:
<rule id="1">
<conditions>
<identity>
<domain>example.com</domain>
<except>bob@domain.com</except>
</identity>
</conditions>
<actions>
<join-handling>allow</join-handling>
</actions>
<transformations/>
</rule>
5.5 Re-joining a Conference
Participants can drop out of a conference for many reasons including:
client crash, out of coverage, had to leave for a while. It might be
of interest to enable that user to re-join the conference. To allow
that, participants that have departed the conference gracefully can
only re-join if a privileged user has added an authorization rule
allowing them to join. Participants that have departed the
conference ungracefully (eg: crash) require a special behaviour from
the focus . The focus is aware when a user has not gracefully
departed a conference (for example; it did not receive a SIP BYE
request and media is no longer being received). If this is the case,
the focus is required to re-issue the invitation or referral to that
user after a pre-configured unit of time.
5.6 Floor Control Policy vs. Floor Control Protocol
Conference floor control is an optional feature provided by a Conference floor control is an optional feature provided by a
separate floor control protocol (FCP). However, creating a floor and separate floor control protocol (FCP). However, creating a floor and
defining a floor policy belongs to CPCP. Moreover, setting some key defining a floor policy belongs to CPCP. Moreover, setting some key
floor parameters, such as floor moderator in moderator controlled floor parameters, such as floor moderator in moderator controlled
floor policy, belongs to CPCP. FCP only defines how to request, floor policy, belongs to CPCP. FCP only defines how to request,
grant, deny and revoke a floor within given floor policy. grant, deny and revoke a floor within given floor policy.
For example, in a typical conference the privileged conference user For example, in a typical conference the privileged conference user
(creator) uses CPCP for creating a floor for audio plane, defining uses CPCP for creating a floor for audio plane, defining the floor
the floor policy as "moderator-controlled" and appointing one user - policy as "moderator-controlled" and appointing one user - possibly
possibly himself - to act as a floor moderator governing the access himself - to act as a floor moderator governing the access to the
to the floor. floor.
When the floor has been created and possible floor moderator has been When the floor has been created and a floor moderator has been
assigned, the floor moderator gets notifications from the focus and assigned, the floor moderator gets notifications from the focus and
is able to accept or deny floor requests from the conference users. is able to accept or deny floor requests from the conference users.
Note that FCP does not create media streams (just the virtual floor Note that FCP does not create media streams (just the virtual floor
attached to media), as media streams are created using CPCP. The attached to media), as media streams are created using CPCP. The
details of FCP are beyond the scope of this draft. details of FCP are beyond the scope of this draft.
6. An XCAP Usage for Conference Policy Manipulation 6. An XCAP Usage for Conference Policy Manipulation
6.1 Application Unique ID 6.1 Application Unique ID
XCAP requires application usages to define a unique application usage XCAP requires application usages to define a unique application usage
ID (AUID) in either the IETF tree or a vendor tree. This ID (AUID) in either the IETF tree or a vendor tree. This
specification defines the "conference-policy" AUID within the IETF specification defines the "conference-policy" AUID within the IETF
tree, via the IANA registration in Section 9. tree, via the IANA registration in Section 9.
6.2 Resource Interdependencies 6.2 Resource Interdependencies
The conference policy server must fill the conference URI(s), if a The conference policy server MAY fill the conference URI(s), but the
conference URI was not proposed by the client. The client then needs client MUST propose a conference URI. If the CPS does not allow
to perform a HTTP GET to retrieve the modified policy containing the assignments of URIs by the client, it rejects the request with a
assigned conference URI(s). The CPS MAY assign multiple conference "409" response and SHOULD include a body in the response detailing
the error. XCAP Base document [10] section 7.2.1 explains how such a
response body is constructed. The CPS MAY assign multiple conference
URIs to a conference, one for each call signaling protocol that it URIs to a conference, one for each call signaling protocol that it
supports. Section 6.12 and Section 4.2.1 discuss this is more detail. supports. Section 4.3.1 discusses this is more detail.
Sidebar URIs are subject to the same behaviour.
6.3 Additional Constraints 6.3 Additional Constraints
These are defined within the XML structure definition. These are defined within the XML structure definition.
6.4 Naming Conventions 6.4 Naming Conventions
There are no naming conventions that need to be defined for this There are no naming conventions that need to be defined for this
application usage. application usage.
6.5 Authorization Policies 6.5 Authorization Policies
This application usage does not modify the default XCAP authorization A server can allow privileged users to modify documents that they
policy, which is that only a user can read, write or modify their own don't own. The establishment and indication of such policies is done
documents. A server can allow privileged users to modify documents by setting the authorization rules as described in Section 4.3.4.
that they don't own, but the establishment and indication of such
policies is outside the scope of this document. It is anticipated
that a future application usage will define which users are allowed
to modify a list resource.
6.6 MIME Type for CPCP XML Document 6.6 MIME Type for CPCP XML Document
The MIME type for the CPCP XML document is defined in Section 4.1 The MIME type for the CPCP XML document is defined in Section 4.1
6.7 Overview of Operation 7. Examples
This document assumes that the user knows the location of conference
policy server (the XCAP URI), the details of that discovery are
beyond the scope of this document.
CPCP is implemented as an XCAP application usage [8].
CPCP allows clients to manipulate the conference policy at conference The following is an example of a document compliant to the schema:
policy server (CPS). CPS is able to inform the focus about changes in
conference policy, if necessary. For example, if new users are
added to the dial-out list, then conference policy server informs the
focus which makes the invitations as requested.
Some assumptions about the conferencing architecture are made. Below is an example how to create a conference:
Clients always connect to the conference policy server (CPS) when
they perform XCAP operations. It is assumed that CPS informs other
conferencing entities, such as focus, floor control server and mixer
directly or via focus. For example, if user A wants to expel user B
from an ongoing conference, user A must first manipulate the
conference policy data. CPS then communicates that change to the
focus to perform the operation.
6.8 Communication Between Conference Entities 7.1 An Example CPCP Document
The communication between different (logical) conferencing elements Alice creates a conference with the follows policy:
is beyond the scope of this document. It can be expected that in most
cases CPS includes also those logical functions. If the focus is not
co-located with CPS, one way for the CPS to communicate changes to
the conference policy is for the focus to subscribe to the XCAP
event package [10].
6.9 Conference Creation and Termination o Conference URIs are suggested to be sip:myconference@example.com
and tel:+3581234567.
Conference is identified by one or more conference URIs. Conference o Maximum number of participants in the conference is 10.
URI assignment is discussed in Section 6.12 and Section 4.2.1.
A user may create a new conference at the CPS by using HTTP PUT and o The conference allows side-bars
sending it to the CPS XCAP URI. Depending on server policy and user
privileges, the CPS may accept the creation.
A conference can be deleted permanently using HTTP DELETE, which o Media mixing starts at the latter of 9:30 am and the first
consequently frees the resources. When the user deletes a conference, participant arrives
CPS MUST also delete all its sub-conferences ("side bars") at a
server. Conference side bars are separate (independent) URIs at the
server.
A running conference instance can be also stopped by modifying the o Media mixing sends at 12:30 pm. The conference does not need a
conference time information. This leaves conference ACLs and key participant to continue.
privileges intact but stops the conference.
If a conference is in progress when deleted or stopped, the focus o Users can join 5 minutes before media mixing starts and cannot
issues signalling requests to terminate all conference related join half an hour before media mixing ends.
sessions it has with clients. In SIP, the focus issues BYE requests.
6.10 Manipulating the Participant Lists o Users are requested to join a conference (invited and referred) 5
minutes before the conference starts and no participant nor
key-participant is needed for this action to take place.
A user with sufficient privileges is allowed to perform user o Everyone at the domain example.com is allowed to join and can
management operations, such as adding a new user to the conference or subscribe to the conference state event package.
expelling a user from the conference. These operations are performed
by modifying the conference policy at the conference policy server.
After authorising the user to do such manipulations, the conference
policy server communicates the change to the focus. The focus reacts
by performing operations such as sending SIP INVITE, BYE or REFER.
Asking the focus to invite a user into the conference is achieved by o Alice is a key participant
sending a HTTP PUT request to the CPS that modifies the Dial-Out List
(DL) adding URIs to it. The CPS then triggers the focus to send the
conference invitation, eg: SIP INVITE(s) as needed. Similarly, a user
can be removed from the Dial-out list by issuing a HTTP DELETE
removing the URIs.
Asking the focus to allow certain users to join the conference is o Alice will be invited to join the conference while Sarah will be
done by sending a HTTP PUT request to the CPS that modifies the ACL referred to the conference.
by adding URIs with access type of "Allowed". The CPS then informs
the focus of such change to the ACL.
If the conference is long-lasting, it is possible that new rules are o No TLS, will be used but S/MIME is required.
added all the time but old rules are almost never removed (some of
them are overwritten, though). This leads easily to the situation
that the ACL contains many unnecessary rules which are not really
needed anymore. Therefore, there is a need to delete ACL rule. This
can be achieved with the HTTP DELETE.
Conflicting rules MUST NOT exist (e.g. both allowed and blocked o PIN code is set to 13579 and password is set to abcd1234.
action is defined for same target). It is the responsibly of the CPS
to ensure such restriction. If a conflict occurs, the CPS can ...
6.10.1 Expelling a Participant o One floor is created for audio and a first-come-first-serve
policy.
Expel operation uses the HTTP PUT request as well, as the user is put o Two media are made available in the conference:audio and video.
on the ACL list with an access type of "Expelled". This also triggers
the CPS to inform the focus about the need to issue a terminating
request, such as a SIP BYE.
A participant cannot be expelled by placing him in the ACL list with The resulting CPCP document looks like
an action to block. This is because the focus interprets a user
placed on the block list as a user who is not allowed to dial into
the conference, but does not prohibit the focus from inviting that
user to join, if that user is on the Dial-out list. Having the user
on an Expel list explicitly informs the focus not to invite that
user, even if s/he is on the Dial-out list.
6.11 Privileges: Who can modify the conference policy <?xml version="1.0" encoding="UTF-8"?>
<conference xmlns="urn:ietf:params:xml:ns:conference-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<settings>
<conference-uri>sip:myconference@example.com</conference-uri>
<max-participant-count>10</max-participant-count>
<allow-sidebars>true</allow-sidebars>
</settings>
<info xml:lang="en-us">
<subject>What's happening tonight</subject>
<display-name>Party Goer's</display-name>
<free-text>John and Peter will join the conference soon</free-text>
<keywords>party nightclub beer</keywords>
<host-info>
<uri>sip:Alice@example.com</uri>
<uri>tel:+3581234567</uri>
<e-mail>mailto:Alice@example.com</e-mail>
<web-page>http://www.example.com/users/Alice</web-page>
</host-info>
</info>
<time>
<occurrence>
<mixing-start-time required-participant="participant">2004-12-17T09:30:00-05:00</mixing-start-time>
<mixing-stop-time required-participant="none">2004-12-17T12:30:00-05:00</mixing-stop-time>
<can-join-after>2001-12-17T09:25:00-05:00</can-join-after>
<must-join-before>2004-12-17T12:00:00-05:00</must-join-before>
<request-users required-participant="none">2001-12-17T09:30:00-05:00</request-users>
</occurrence>
</time>
<authorization-rules>
<rule id="1">
<conditions>
<identity>
<domain>example.com</domain>
</identity>
</conditions>
<actions>
<allow-conference-state>true</allow-conference-state>
<join-handling>allow</join-handling>
</actions>
<transformations/>
</rule>
<rule id="2">
<conditions>
<identity>
<id>alice@example.com</id>
</identity>
</conditions>
<actions>
<allow-sidebar>true</allow-sidebar>
</actions>
<transformations>
<is-key-participant>true</is-key-participant>
</transformations>
</rule>
</authorization-rules>
<dailout-list>
<target uri="sip:bob@example.com"/>
</dailout-list>
<refer-list >
<target uri="sip:sarah@example.com"/>
</refer-list >
<security-control>
<security-mechanism tls="false" s-mime="true"/>
<pin>13579</pin>
<password>abcd1234</password>
</security-control>
<floor-policy>
<floor floor-control="fcp://example.com/floorabc" moderator-controlled="false">
<media-streams>
<audio media-id="2"/>
</media-streams>
<algorithm>
<fcfs/>
</algorithm>
<max-floor-users>1</max-floor-users>
</floor>
</floor-policy>
<media-streams>
<video media-id="1"/>
<audio media-id="2"/>
</media-streams>
</conference>
There is a need for different privileges to exist where users can 7.2 CPCP Manipulations Using XCAP
modify certain parts of the conference policy XML document. This
specification does not specify such privileges and relies on other
XCAP usage documents to define those privileges. If no such XCAP
usage document exists, the base XCAP document defines the default
privileges so that only the creator of the document is the sole user
with write access.
This specification, however, makes ready the CPCP XML document to 1. Creating a Conference
allow an external usage document to define which parts of such an XML
document a user can modify (which parts of an XML document a user
has read/write access to) by dividing the CPCP XML document into
sections, each with a separate namespace. It is envisioned that the
XCAP usage document for read/write access of another XCAP XML
document uses namespaces as the key to allow/disallow users from
reading and/or modifying that XCAP usage document.
6.12 Conference URI(s) Continuing with the example from Section 7.1, Alice's client uses
XCAP to transport the conference policy to the conference policy
server
A conference is identified by one or more conference URIs. Conference PUT
URIs can be proposed by the creator of the conference policy, as it http://xcap.example.com/services/conferences/users/Alice/conference.xml HTTP/1.1 Content-Type:application/conference-policy+xml
may be useful to have human-friendly name in some cases, or can be
assigned by the CPS. If the creator has proposed a conference URI,
the server needs to decide whether it accept the name proposed by
the client or not. It does this determination by examining if the
conference URI already exists or not. If it exists, the server ...
A Conference URI can be SIP, SIPS, TEL, or any supported URI scheme. Content-Type: application/conference-policy+xml
There must be at least one URI for a conference. The CPS MAY assign
multiple conference URIs to a conference, one for each call
signaling protocol that it supports. If the creator of the conference
policy proposed a conference URI for a protocol that the server does
not support, the server ...
7. Examples [conference policy from Section 7.1 goes here.
The following is an example of a document compliant to the schema: At exactly 2004-12-17T09:30:00-05:00, the focus sends SIP INVITE
request to Alice and a SIP REFER request to Sarah. At
2004-12-17T09:25:00-05:00, SIP INVITE requests can be accepted from
anyone at domain example.com. Any attempts to join the conference by
users in other domains are rejected.
Below is an example how to create a conference: 2. Expelling a User
1. Creating a Conference After the conference has started, Alice decides to expel Bob who has
joined the conference. So she modifies the authorization rule that
allows everyone at example.com to join:
Alice creates a conference as follows: PUT
http://xcap.example.com/services/conferences/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id=""]/conditions/identity/ HTTP/1.1
PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml HTTP/1.1 Content-Type:text/plain
Content-Type:application/conference-policy+xml
<?xml version="1.0" encoding="US-ASCII"?> <identity>
<Conference xmlns="urn:ietf:params:xml:ns:conference-policy" <domain>example.com</domain>
xmlns:conference-mp="urn:ietf:params:xml:ns:conference-mp" <except>bob@example.com</except>
xmlns:conference-fp="urn:ietf:params:xml:ns:conference-fp" </identity>
xmlns:conference-sc="urn:ietf:params:xml:ns:conference-sc"
xmlns:conference-dl="urn:ietf:params:xml:ns:conference-dl"
xmlns:conference-pcl="urn:ietf:params:xml:ns:conference-pcl"
xmlns:conference-acl="urn:ietf:params:xml:ns:conference-acl"
xmlns:conference-time="urn:ietf:params:xml:ns:conference-time"
xmlns:conference-info="urn:ietf:params:xml:ns:conference-info"
xmlns:conference-settings="urn:ietf:params:xml:ns:conference-settings">
<conference-settings:Conference-settings>
<conference-uri:Conference-URI></conference-uri:Conference-URI>
<Max-participant-count>50</Max-participant-count>
</conference-settings:Conference-settings>
<conference-info:Conference-info lang="en">
<Subject>What's happening tonight</Subject>
<Display-name>Party Goer's</Display-name>
<Free-text>John and Peter will join the conference soon</Free-text>
<Keywords>party nightclub beer</Keywords>
<Host-info>
<SIP-URI>sip:Alice@example.com</SIP-URI>
<TEL-URI>tel:+358401111111</TEL-URI>
<E-mail>mailto:Alice@example.com</E-mail>
<Web-page>http://www.example.com/users/Alice</Web-page>
</Host-info>
</conference-info:Conference-info>
<conference-time:Conference-time>
<Conference-occurrence>
<Start-time>2003-06-16T10:00:00Z</Start-time>
<Stop-time>2003-06-16T12:00:00Z</Stop-time>
</Conference-occurrence>
</conference-time:Conference-time>
<conference-acl:ACL>
<ACL-target-URI Access-type="Allowed">sip:*@example.com</ACL-target-URI>
<ACL-target-URI Access-type="Blocked">sip:*@*</ACL-target-URI>
</conference-acl:ACL>
<conference-pcl:PCL>
<PCL-target>
<PCL-target-URI>sip:Alice@example.com</PCL-target-URI>
<Privileges>RIGHT_TO_SUBSCRIBE_TO_CONF_EVENT_PACKAGE</Privileges>
</PCL-target>
</conference-pcl:PCL>
<conference-dl:DL>
<DL-target>
<DL-target-URI>sip:alice@operator.com</DL-target-URI>
</DL-target>
<DL-target>
<DL-target-URI>sip:sarah@operator.com</DL-target-URI>
</DL-target>
</conference-dl:DL>
<conference-sc:SC>
<Visibility>visible</Visibility>
<Security-mechanism TLS="false" S-MIME="true"/>
<SC-target>
<SC-target-URI>sip:*@example.com</SC-target-URI>
<Authorization-mechanism password="1a2b3c4d">Digest</Authorization-mechanism>
</SC-target>
</conference-sc:SC>
<conference-fp:Conference-floor-policy>
<Floor moderator-controlled="true">
<Media-types>
<Audio/>
</Media-types>
<Algorithm>
<Moderator-controlled/>
</Algorithm>
<Max-floor-users>1</Max-floor-users>
<Moderator-URI>sip:Alice@example.com</Moderator-URI>
</Floor>
</conference-fp:Conference-floor-policy>
<conference-mp:Conference-media-policy>
<Media-types>
<Audio/>
</Media-types>
</conference-mp:Conference-media-policy>
</Conference>
At exactly 2003-06-16T10:00:00Z, the conference server creates a focus and At this point, the focus sends a SIP BYE request to Bob ending Bob's
sends SIP INVITE requests to Alice and Sarah. After the focus is created, participation in the conference. This also guarantees that Bob
SIP INVITE requests can be accepted from anyone at domain example.com. cannot rejoin the conference since he is explicitly blocked. Any
Any attempts to join the conference by users in other domains are rejected. attempt Bob makes in rejoining the conference will fail.
2. Expelling a User 3. Allowing An Expelled Participant To Join Again
Continuing with the above example: aftar the conference has started, Continuing with the example above, Alice now decides to allow Bob to
Alice decides to expel Bob who has joined the conference. So she adds him to join again after a period of time. She does so by rewriting parts of
the ACL list with Access-type of value "Blocked". the rule that blocks him from joining.
The XCAP request looks like: PUT
http://xcap.example.com/services/conferences/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id=""]/conditions/identity/ HTTP/1.1
PUT http://xcap.example.com/services/conferences/users/Alice/conference.xml?
Conference/ACL/ACL-target-URI HTTP/1.1
Content-Type:text/plain Content-Type:text/plain
<ACL-target-URI Access-type="Explelled">sip:bob@example.com</ACL-target-URI> <identity>
<domain>example.com</domain>
</identity>
At this point, the focus sends a SIP BYE request to Bob ending Bob's participation Bob can now rejoin the conference by sending a SIP INVITE request.
in the conference. This also guarantees that Bob cannot rejoin the conference since
he is expilictly expelled until his URI is removed from the ACL Expelled list.
Any attempt Bob makes in rejoining the conference will fail.
3. Allowing An Expelled Participant To Join Again 4. Allowing Sarah to Refer Users
Continuing with the example above, Alice now decides to allow Bob to join Alice now decides that Sarah can ask the focus to refer users to the
again after a period of time. She does so by removing his entry in the conference:
ACL that identifies him as "Expelled".
DELETE http://xcap.example.com/services/conferences/users/Alice/conference.xml? PUT
Conference/ACL/ACL-target-URI/ACL-target-URI="sip:bob@example.com" HTTP/1.1 http://xcap.example.com/services/conferences/users/Alice/conference.xml/~~/conference/authorization-rules/rule[@id="3"] HTTP/1.1
Bob can now rejoin the conference by sending a SIP INVITE request. Content-Type:text/plain
4. Removing A Conference <rule id="3">
<conditions>
<identity>
<uri>sarah@example.com</uri>
</identity>
</conditions>
<actions>
<allow-refer-users-dynamically>true</allow-refer-users-dynamically>
</actions>
<transformations/>
</rule>
5. Removing A Conference
Alice now decides she no longer wants this conference to exist and therefore Alice now decides she no longer wants this conference to exist and
deletes the conference: therefore deletes the conference:
DELETE http://xcap.example.com/services/conferences/users/Alice/conference.xml DELETE
http://xcap.example.com/services/conferences/users/Alice/conference.xml
As a result of this action, the focus sends SIP BYE requests to all current As a result of this action, the focus sends SIP BYE requests to all
participants in the conference. The conference server terminates the focus thereafter. current participants in the conference. The conference server
terminates the focus thereafter.
8. Security Considerations 8. Security Considerations
See section Section 4.2.7. A conference document may contain information that is highly
sensitive. Its delivery to the conference server needs to happen
strictly, paying special attention to integrity and confidentiality.
Reading the document is also a security concern since the conference
policy contains sensitive information like the PIN code, password of
the conference, the topic of the conference, who is allowed to join
and the URIs of the users that can participate.
Manipulations of the conference policy have similar security issues.
Users with relevant privileges can manipulate parts of the conference
policy giving themselves and others privileges to manipulate the
conference policy, including the dial-out list and the security
control settings for a conference. This can happen because the
conference policy it self carries the identities and the
authorization rules that apply to those identities. Those
authorization rules carry the privileges that certain identities
have. If an unauthorized user gets access to this document
(pretending to be someone else), s/he can manipulate those rules
giving himself and other unauthorized users access to the conference
policy. S/he can also manipulate other parts of the conference
policy under a false identity. Some of the things that a malicious
user can do include: denying users certain privileges, giving himself
floor moderation, removing users from lists, removing rules for
certain identities, giving privileges to other malicious users,
changing the media streams and changing conference time. Therefore,
it is very important that only authorized clients are able to
manipulate the conference policy. Any conference policy transport
protocol MUST provide authentication, confidentiality and integrity.
In the case that XCAP is used to create and manipulate a conference
policy, the XCAP base specification mandates that all XCAP servers
MUST implement HTTP Authentication: Basic and Digest Access
Authentication [16]. Furthermore, XCAP servers MUST implement HTTP
over TLS [17]. It is recommended that administrators of XCAP servers
use an HTTPS URI as the XCAP root services URI, so that the digest
client authentication occurs over TLS. By using these means, XCAP
client and server can ensure the confidentiality and integrity of the
XCAP created conference policy document and its manipulation
operations, and that only authorized clients are allowed to perform
them.
9. IANA Considerations 9. IANA Considerations
9.1 XCAP Application Usage ID 9.1 XCAP Application Usage ID
This section registers a new XCAP Application Usage ID (AUID) This section registers a new XCAP Application Usage ID (AUID)
according to the IANA procedures defined in.. according to the IANA procedures defined in..
Name of the AUID: conference-policy Name of the AUID: conference-policy
Description: Conference policy application manipulates conference Description: Conference policy application manipulates conference
policy at a server. policy at a server.
9.2 application/conference-policy+xml mime TYPE 9.2 application/conference-policy+xml MIME TYPE
MIME media type: application MIME media type: application
MIME subtype name: conference-policy+xml MIME subtype name: conference-policy+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter applicatioN/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [6]. specified in RFC 3023 [7].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [6]. application/xml as specified in RFC 3023 [7].
Security considerations: See section 10 of RFC 3023 [6] and section Security considerations: See section 10 of RFC 3023 [7] and section
Section 9 of this document. Section 9 of this document.
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: This document.
Applications which use this media type: This document type has been Applications which use this media type: This document type has been
used to support conference policy manipulation for SIP based used to support conference policy manipulation for SIP based
conferencing. conferencing.
skipping to change at page 27, line 38 skipping to change at page 42, line 22
(petri.koskelainen@nokia.com) (petri.koskelainen@nokia.com)
Intended Usage: COMMON Intended Usage: COMMON
Author/change controller: The IETF Author/change controller: The IETF
9.3 URN Sub-Namespace Registration for 9.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-policy urn:ietf:params:xml:ns:conference-policy
This section registers a new XML namespace, as per guidelines in URN This section registers a new XML namespace, as per guidelines in URN
document [13]. document [15].
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:conference-policy. urn:ietf:params:xml:ns:conference-policy.
Registrant Contact: IETF, XCON working group, Petri Koskelainen Registrant Contact: IETF, XCON working group, Petri Koskelainen
(petri.koskelainen@nokia.com) (petri.koskelainen@nokia.com)
XML: XML:
BEGIN BEGIN
skipping to change at page 28, line 33 skipping to change at page 43, line 15
10. Contributors 10. Contributors
Jose Costa-Requena Jose Costa-Requena
Simo Veikkolainen Simo Veikkolainen
Teemu Jalava Teemu Jalava
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Markus Isomaki, Eunsook Kim and IETF The authors would like to thank Markus Isomaki, Adam Roach, Eunsook
conferencing design team for their feedback. Kim, Roni Evan and the IETF XCON working group for their feedback and
suggestions.
Normative References 12. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 12.1 Normative References
[1] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J. and J.
Rosenberg, "Common Policy", Internet-Draft
I-D.ietf-geopriv-common-policy, February 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCD 14, March 1997. Levels", RFC 2119, BCD 14, March 1997.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997. [3] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[4] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston, [5] Rosenberg, J., Shulzrinne, H., Camarillo, G., Johnston, A.,
A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
"SIP: Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[5] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, [6] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
REC REC-xml-20001006, October 2000. REC REC-xml-20001006, October 2000.
[6] Murata, M., Laurent, S. and D. Kohn, "XML Media Types", RFC [7] Murata, M., Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001. 3023, January 2001.
[7] Koskelainen, P. and H. Khartabil, "Requirements for conference [8] Koskelainen, P. and H. Khartabil, "Requirements for conference
policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in policy control protocol", draft-ietf-xcon-cpcp-req-01 (work in
progress), January 2004. progress), January 2004.
[8] Rosenberg, J., "The Extensible Markup Language (XML) [9] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-03 (work in progress),
February 2004.
[10] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-02 (work in progress), February 2004. draft-ietf-simple-xcap-02 (work in progress), February 2004.
[9] Rosenberg, J., "An Extensible Markup Language (XML) [11] Rosenberg, J., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usage for Presence Lists", Configuration Access Protocol (XCAP) Usage for Presence Lists",
draft-ietf-simple-xcap-list-usage-02 (work in progress), draft-ietf-simple-xcap-list-usage-02 (work in progress),
February 2004. February 2004.
[10] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Modification Events for the Extensible Markup Package for Modification Events for the Extensible Markup
Language (XML) Configuration Access Protocol (XCAP) Managed Language (XML) Configuration Access Protocol (XCAP) Managed
Documents", draft-ietf-simple-xcap-package-01 (work in Documents", draft-ietf-simple-xcap-package-01 (work in
progress), February 2004. progress), February 2004.
[11] Rosenberg, J., "A Framework for Conferencing with the Session [13] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-01 (work in draft-ietf-sipping-conferencing-framework-01 (work in
progress), October 2003. progress), October 2003.
[12] Rosenberg, J., Shulzrinne, H. and O. Levin, "A Session [14] Rosenberg, J., Shulzrinne, H. and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State", Initiation Protocol (SIP) Event Package for Conference State",
draft-ietf-sipping-conference-package-03, February 2004. draft-ietf-sipping-conference-package-03, February 2004.
[13] Mealling, M., "The IETF XML Registry", [15] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
draft-mealling-iana-xmlns-registry-05 (work in progress), June
2003. [16] Franks, J., "HTTP Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999.
[17] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
12.2 Informative References
[18] Jennings, C. and B. Rosen, "Media Mixer Control for XCON",
draft-jennings-xcon-media-control-00 (work in progress),
February 2004.
[19] Handly, M., Eriksson, G., Jacobson, V. and C. Perkins,
"Grouping of Media Lines in SDP", draft-ietf-mmusic-sdp-new-18
(work in progress), June 2004.
Authors' Addresses Authors' Addresses
Hisham Khartabil Hisham Khartabil
Nokia Nokia
P.O. Box 321 P.O. Box 321
Helsinki FIN-00045 Helsinki FIN-00045
Finland Finland
EMail: hisham.khartabil@nokia.com EMail: hisham.khartabil@nokia.com
skipping to change at page 30, line 4 skipping to change at page 45, line 14
Authors' Addresses Authors' Addresses
Hisham Khartabil Hisham Khartabil
Nokia Nokia
P.O. Box 321 P.O. Box 321
Helsinki FIN-00045 Helsinki FIN-00045
Finland Finland
EMail: hisham.khartabil@nokia.com EMail: hisham.khartabil@nokia.com
Petri Koskelainen Petri Koskelainen
Nokia Nokia
P.O. Box 100 (Visiokatu 1) P.O. Box 100 (Visiokatu 1)
Tampere FIN-33721 Tampere FIN-33721
Finland Finland
EMail: petri.koskelainen@nokia.com EMail: petri.koskelainen@nokia.com
Aki Niemi
Nokia
P.O. Box 100
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/