draft-ietf-xcon-common-data-model-03.txt   draft-ietf-xcon-common-data-model-04.txt 
XCON O. Novo XCON O. Novo
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: April 13, 2007 D. Morgan Expires: September 4, 2007 D. Morgan
Fidelity Investments Fidelity Investments
R. Even R. Even
Polycom Polycom
October 10, 2006 March 3, 2007
A Common Conference Information Data Model for Centralized Conferencing Conference Information Data Model for Centralized Conferencing (XCON)
(XCON) draft-ietf-xcon-common-data-model-04.txt
draft-ietf-xcon-common-data-model-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 38
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 The list of current Internet-Drafts can be accessed at
http://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 April 13, 2007. This Internet-Draft will expire on September 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document collects, organizes, and describes the conference This document defines an Extensible Markup Language (XML)-based
variables that have been introduced in various protocol drafts of the conference information data model for centralized conferencing
XCON and SIPPING working groups. The goal of this document is to (XCON). A conference object, which can be manipulated using a
allow the conference control protocols to use a unified common conference control protocol, at a conference server represents a
conference information data model for XCON. This document formally particular instantiation of this data model. The conference
defines an Extensible Markup Language (XML) Schema that represents information data model defined in this document is an extension of
the common conference information in a conferencing server. The (and thus, compatible with) the model specified in the Session
information is modeled as a series of elements, each of which Initiation Protocol (SIP) Event Package for Conference State.
contains a set of children and attributes.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Common Conference Data . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Data Model Structure . . . . . . . . . . . . . . . . . . . 6
3.2. Common Conference Policies . . . . . . . . . . . . . . . . 9 3.2. Conference Policies . . . . . . . . . . . . . . . . . . . 7
3.3. <conference-description> . . . . . . . . . . . . . . . . . 10 3.2.1. Role Definitions . . . . . . . . . . . . . . . . . . . 8
3.3.1. <conference-time> . . . . . . . . . . . . . . . . . . 11 3.2.1.1. Role in a Floor . . . . . . . . . . . . . . . . . 8
3.3.2. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 13 3.2.1.2. Changing Roles . . . . . . . . . . . . . . . . . . 9
3.3.3. <service-uris> . . . . . . . . . . . . . . . . . . . . 13 4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 9
3.3.4. <maximum-user-count> . . . . . . . . . . . . . . . . . 13 4.1. <conference-description> . . . . . . . . . . . . . . . . . 13
3.3.5. <maximum-streams> . . . . . . . . . . . . . . . . . . 13 4.1.1. <conference-time> . . . . . . . . . . . . . . . . . . 14
3.3.6. <available-media> . . . . . . . . . . . . . . . . . . 13 4.1.2. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 15
3.3.7. <controls> . . . . . . . . . . . . . . . . . . . . . . 14 4.1.3. <service-uris> . . . . . . . . . . . . . . . . . . . . 16
3.3.7.1. mute . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.4. <maximum-user-count> . . . . . . . . . . . . . . . . . 16
3.3.7.2. pause-video . . . . . . . . . . . . . . . . . . . 14 4.1.5. <available-media> . . . . . . . . . . . . . . . . . . 16
3.3.7.3. gain . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.5.1. <controls> . . . . . . . . . . . . . . . . . . . . 17
3.4. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.5.1.1. mute . . . . . . . . . . . . . . . . . . . . . 17
3.5. <conference-state> . . . . . . . . . . . . . . . . . . . . 15 4.1.5.1.2. pause-video . . . . . . . . . . . . . . . . . 17
3.6. <floor-information> . . . . . . . . . . . . . . . . . . . 15 4.1.5.1.3. gain . . . . . . . . . . . . . . . . . . . . . 18
3.7. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.5.1.4. video-layout . . . . . . . . . . . . . . . . . 18
3.7.1. <allowed-users-list> . . . . . . . . . . . . . . . . . 17 4.2. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 19
3.7.2. <privileges-control-list> . . . . . . . . . . . . . . 18 4.3. <conference-state> . . . . . . . . . . . . . . . . . . . . 19
3.7.2.1. <conference-rules> . . . . . . . . . . . . . . . . 18 4.4. <floor-information> . . . . . . . . . . . . . . . . . . . 19
3.7.2.1.1. <condition> . . . . . . . . . . . . . . . . . 18 4.5. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7.2.1.2. <pseudonymous> . . . . . . . . . . . . . . . . 19 4.5.1. <allowed-users-list> . . . . . . . . . . . . . . . . . 22
3.7.2.1.3. <has-been-referred> . . . . . . . . . . . . . 19 4.5.2. <user> . . . . . . . . . . . . . . . . . . . . . . . . 22
3.7.2.1.4. <has-been-invited> . . . . . . . . . . . . . . 19 4.5.2.1. <from-mixer>, <to-mixer> . . . . . . . . . . . . . 23
3.7.2.1.5. <has-been-in-conference> . . . . . . . . . . . 19 4.5.2.1.1. <floor> . . . . . . . . . . . . . . . . . . . 23
3.7.2.1.6. <is-in-conference> . . . . . . . . . . . . . . 19 4.5.3. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . 24
3.7.2.1.7. <administrator> . . . . . . . . . . . . . . . 19 4.5.4. <sidebars-by-val> . . . . . . . . . . . . . . . . . . 24
3.7.2.1.8. <is-on-allowed-users-list-dial-out> . . . . . 20 5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 24
3.7.2.1.9. <is-on-allowed-users-list-refer> . . . . . . . 20 6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 33
3.7.2.1.10. <participant-passcode> . . . . . . . . . . . . 20 7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7.2.1.11. <administrators-passcode> . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
3.7.2.2. <actions> . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
3.8. <user> . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Conference Relax NG Schema Registration . . . . . . . . . 42
3.8.1. from-mixer, to-mixer . . . . . . . . . . . . . . . . . 23 9.2. Conference Namespace Registration . . . . . . . . . . . . 43
3.8.1.1. <floor> . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
3.9. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.10. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
4. RELAX NG schema . . . . . . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 43
5. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 48 Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML
6. XML example . . . . . . . . . . . . . . . . . . . . . . . . . 49 Syntax . . . . . . . . . . . . . . . . . . . . . . . 44
7. Security Considerations . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 Intellectual Property and Copyright Statements . . . . . . . . . . 71
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
10.1. Normative References . . . . . . . . . . . . . . . . . . . 58
10.2. Informative References . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
Intellectual Property and Copyright Statements . . . . . . . . . . 61
1. Introduction 1. Introduction
This document defines an Extensible Markup Language (XML) Schema that Conference objects are a fundamental concept in Centralized
represents the conference object in a conferencing server. The conferencing, as described in the XCON Conferencing Framework [1]. A
information is modeled as a series of elements, each of which conference object contains data that represents a conference during
contains children and attributes. each of its various stages (e.g., reserved, started, running, ended,
etc.). Conference Objects are instantiations of the conference
information data model defined in this document. Consequently,
conference objects follow the XML format defined in this document.
The Conference Object contains the XML schema, which is used to A conference object contains the core information of a conference
represent the core information that is utilized in any conference (i.e., capabilities, membership, roles, call control signaling,
(capabilities, membership, roles, call control signalling, media, media, etc.) and specifies who, and in which way, can manipulate that
etc...) and specifies the set of rights, permissions and limitations information.
pertaining to operations being performed on a certain Conference
Object.
This document gives an overview of the conference variables that have Figure 1 shows logical functional elements of a conference server as
been introduced in various protocol drafts of the XCON working group defined by the XCON Conferencing Framework [1]. They are a
to date and proposes to create a unified common conference Conference Control Server, a Floor Control Server, a number of Foci,
information data model for XCON. and a Notification Service. A conference control protocol provides
the interface between a conference and media control client, and the
conference control server. A floor control protocol (e.g., BFCP [7])
provides the interface between a floor control client and the floor
control server. A call signaling protocol (e.g., SIP, H.323, PSTN,
etc.) provides the interface between a call signaling client and a
Focus. A notification protocol (e.g., SIP-based event notifications
[8]) provides the interface between the conferencing client and the
Notification Service. Within a conference, the conference control
server, floor control server, and focus can modify the information in
the conference object.
This document has been constructed in compliance with the XCON ...............................................................
Framework [1] and the Session Initiation Protocol (SIP) Event Package . Conferencing Server .
for Conference State [2]. It also incorporates data elements . +---------------------------------------------------+ .
proposed in several XCON WG and SIPPING WG drafts. . | C o n f e r e n c e o b j e c t | .
. +-+--------------------------------------------------+| .
. | C o n f e r e n c e o b j e c t || .
. +-+---------------------------------------------------+|| .
. | C o n f e r e n c e o b j e c t ||| .
. | +--------------------------------------------------+||| .
. | | Conference Information Data Model |||| .
. | | +----------------------------------------------+ |||| .
. | | | Conference description (times, duration) | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Host information | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Conference state | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Floor information | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Membership (users, roles, capacity) | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Sidebars, Etc. | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Etc. | |||| .
. | | +----------------------------------------------+ |||+ .
. | +--------------------------------------------------+|+ .
. +----^------------------^-------------^--------|------+ .
. | | | | .
. +------v-------+ +--------v-----+ +-----v-+ +----v-------+ .
. | Conference | | Floor | | | | | .
. | Control | | Control | |Foci | |Notification| .
. | Server | | Server | | | |Service | .
. +-----^--------+ +---^----------+ +-^-----+ +------------+ .
........|..............|..............|..........|.............
|Conference |Binary Floor |Call |Notification
|Control |Control |Signaling |Protocol
|Protocol |Protocol |Protocol |
........v..............v..............v..........v.............
. C o n f e r e n c i n g C l i e n t .
...............................................................
Figure 1: Conference Server Architecture
The Session Initiation Protocol (SIP) Event Package for Conference
State, specified in RFC 4575 [2], already defines a data model for
conferences. However, that model is SIP specific and lacks elements
related to some of the functionality defined by the XCON conferencing
framework [1] (e.g., floor control). The data model defined in this
document extends the one defined in RFC 4575 [2]. The result is a
data model that supports more call signaling protocols besides SIP
and that covers all the functionality defined in the XCON
conferencing framework [1].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC-2119 [3]. document are to be interpreted as described in RFC 2119 [3].
This document uses the terminology defined in the XCON Conferencing This document uses the terminology defined in the XCON Conferencing
Framework [1] and the SIPPING Conferencing Framework [4]. In Framework [1], the SIP conferencing framework [4] and the BFCP
addition, it uses definitions from The Binary Floor Control Protocol (Binary Floor Control Protocol) specification [7]. Readers of this
[7]. document are supposed to be familiar with the terminology used in
those documents.
3. Common Conference Data 3. Overview
3.1. General The data model defined in this document is the result of extending
the data model defined in RFC 4575 [2] with new elements, which carry
information such as non-SIP URIs or floor-control-related parameters.
This data model can be used by conference servers providing different
types of basic conferences. It is expected that this data model can
be further extended with new elements in the future in order to
implement advanced features.
The conference object data model document is an XML [5] document that 3.1. Data Model Structure
MUST be well formed and SHOULD be valid. Conference object data
model documents MUST be based on XML 1.0 and SHOULD be encoded using
UTF-8.
A Common Conference information document begins with the root element The information in this data model is structured in the following
tag <conference-info> of conference-type. The <conference-info> has manner. All the information related to a conference is contained in
the attribute 'entity' that contains the conference unique identifier a <conference-info> element. The <conference-info> element contains
that identifies the conference being described in the document. the following child elements:
o The <conference-description> element describes the conference as a
whole. It has, for instance, information about the URI of the
conference, maximum users allowed in the conference, media
available in the conference, or the time the conference will
start.
o The <host-info> element contains information about the entity
hosting the conference (e.g., its URI).
The <conference-info> element is comprised of <conference- o The <conference-state> element informs the subscribers about the
description>, <host-info>, <conference-state>, <floor-information>, changes in the overall conference information.
<users>, <sidebars-by-ref>, <sidebars-by-val>, child elements. A o The <floor-information> element contains information about the
common conference document must at least include the <conference- status of the different floors in the conference.
description>, <host-info>, <conference-state>, and <users> child o The <users> element describes the membership information as a
elements. Some of this information can be represented using the whole. The <users> element contains a set of <user> child
conference-info-type schema as defined in [2]. elements, each describing a single participant in the conference.
o If a participant in the main conference joins a sidebar, a new
element is created in the conference referenced from the
<sidebars-by-ref> element or under one of the <sidebars-by-val>
elements.
Changes in the state of the conference should be communicated to the 3.2. Conference Policies
subscribers using a conference package subscribers (ex. A Session
Initiation Protocol (SIP) Event Package for Conference State).
Critical changes should be communicated to specific subscribers,
perhaps those with unique roles. The conference policy control
protocol msy be used to retrieve the conference state at any time.
The following non-normative diagram gives an example of the overall Conference policies specify who, and in which way, information in a
hierarchy used in this format. The operator "!" preceding an element conference object can be manipulate. This data model has no strict
indicates that this element is MANDATORY in the data model. The separation between conference membership and media information, and
operator "*" preceding an element indicates that this element is its related policies. Policy-related elements and attributes appear
introduced/proposed in this draft. with the element they apply to.
[Editor's Note: The Policies section is still under discussion. For
more details refer to the XCON mailing list. ]
The set of rights describes the read/write access privileges for the
conference object data model as a whole. Every element of the data
model SHOULD define two attributes: the attribute 'read-only', and
the attribute 'read-write'. These attributes describes the read/
write access privileges for accessing the Conference Object as a
whole. This is partially described in [1]. When the conferencing
server receives a request to access privacy-sensitive data it needs
to match it against the 'read-only' and the 'read-write' attributes.
Each attribute of each individual element is evaluated and as a
result it is determined if the requestor can access that element.
The attributes specify the minimum requestor's role that can access
or modify the element of the conference. Requestors with a role with
lower privileges as defined in Section 3.2.1 cannot access or modify
the element.
If an attribute is not defined in some element, the 'read-only'
attribute MUST be interpreted as a "participant" role and the 'read-
write' attribute MUST be interpreted as an "administrator" role by
default. It is possible to defined only one of the attributes of the
element, the other attribute SHOULD be interpreted by default. The
next section defines conferencing roles that are used to represent
participants within a Conference Object. Additional roles may be
defined in the future, as necessary, with their corresponding schema
extensions, as appropriate.
However, it can also be the case that conflicts can occur given a
hierarchy of elements. In that case, the lower-level element
privileges predominate over the upper-level privileges element.
The policies and rights are an integral part of the data model, with
elements containing the allowed ranges for other elements (e.g.,
maximum number of participants) and lists of end-points allowed to
perform certain operations on a conference object.
3.2.1. Role Definitions
This section defines five logical roles for a Conference System to
represent participants within a Conference Object. In hierarchical
order they are: "administrator", "creator", "moderator",
"participant", and "observer". A set of semantics associated with
each role is out of the scope of this document. A Conference System
MAY choose not to support a particular role. As well, additional
roles may be defined in the future, as necessary, with their
corresponding schema extensions.
These five roles have an intrinsic hierarchical order within a
specific conference. By hierarchical order, it is implied that the
"administrator" by default SHOULD have higher privileges than a
"creator", which by default SHOULD have higher privileges than a
"moderator" and so on. For example, the "administrator" SHOULD have
the ability to make changes to all conference variables during
instantiation and full lifecycle of the Conference Object. The
"creator" is the 'owner' of the conference and has various privileges
which SHOULD allow them to modify the conference variables up to the
time the conference is instantiated. The "moderator" is a logical
entity that will manage the conference. The "participant" is a
logical entity with generic privileges that will be attending a
conference. The "observer" is a logical entity which can only
receive media streams from the conference. All Conference Systems
MUST have a role defined as "participant".
Each user participating in a conference instance is an entity that
can assume one or more roles. Any entity can be allocated to an
appropriate logical role. A role can also be assumed in conjunction
with the users identity within the Conference System as a result of
an identity assertion transaction on the Conference System. If no
roles are defined for an entity, they SHOULD by default be a
"participant" but local policy MAY define an alternative.
3.2.1.1. Role in a Floor
Floor control in centralized conferencing is described in the Binary
Floor Control Protocol (BFCP) [7]. Floors can be specified in the
Conference System or created dynamically. Users can be added or
deleted from a floor when the conference is active.
A floor chair is a logical entity that manages a floor (grants,
denies, or revokes a floor). The floor chair is usually in an
"administrator", "moderator", or "creator" role. A floor participant
is a logical entity that requests floors, and possibly information
about them from a floor control server. They are usually in a
"participant" or even a "moderator" role [7].
Users in a conference MAY assume different roles in different floors.
They MAY also assume different roles in the same floor, as floor
transactions are processed.
3.2.1.2. Changing Roles
Users can change roles during a conference. This can be done in two
ways: First, the user can join a new floor in a different role.
Second, an "administrator" or "creator" can dynamically change that
user's role. This can be accomplished before the conference is
instantiated, or during the conference, using an appropriate
conference control protocol. A logical entity whose role has been
changed will typically have access to the media streams associated
with that role.
4. Data Model Definition
A conference object document is an XML [5] document that MUST be well
formed and SHOULD be valid. Conference object data model documents
MUST be based on XML 1.0 and SHOULD be encoded using UTF-8.
A conference object document begins with the root element tag
<conference-info>, which is defined in [2]. The <conference-info>
element has an 'entity' attribute that contains a conference object
identifier (ID) that identifies the conference being described in the
document.
The <conference-info> element contains the <conference-description>,
<host-info>, <conference-state>, <floor-information>, <users>,
<sidebars-by-ref>, <sidebars-by-val> child elements. All these
elements, except <floor-information>, are defined in [2]. A
conference document MUST at least include the <conference-
description>, <host-info>, <conference-state>, and <users> child
elements.
The following non-normative diagram shows the structure of conference
object documents. The operator "!" preceding an element indicates
that the element is mandatory in the data model. The operator "*"
following an element indicates that the element is introduced and
defined in this document. That is, elements without a "*" have
already been defined in RFC 4575 [2].
!<conference-info> !<conference-info>
| |
|--!<conference-description> |--!<conference-description>
| |--<display-text> | |--<display-text>
| |--<subject> | |--<subject>
| |--<free-text> | |--<free-text>*
| |--<keywords> | |--<keywords>
| |--<web-page> | |--<allow-sidebars>*
| |--<security-level> | |--<conference-time>*
| |--<allow-sidebars> | | |--<entry>*
| |--<conference-stage> | | | |--<base>*
| |--<conference-time> | | | |--<mixing-start-offset>*
| | |--<entry> | | | |--<mixing-end-offset>*
| | | |--<base> | | | |--<can-join-after-offset>*
| | | |--<mixing-start-offset> | | | |--<must-join-before-offset>*
| | | |--<mixing-end-offset> | | | |--<request-user>*
| | | |--<can-join-after-offset> | | | |--<notify-end-of-conference>*
| | | |--<must-join-before-offset> | | | |--<allowed-extend-mixing-end-offset>*
| | | |--<request-user>
| | | |--<notify-end-of-conference>
| | | |--<allowed-extend-mixing-end-offset>
| | ... | | ...
| |--<conf-uris> | |--<conf-uris>
| | |--<SIP> | | |--<entry>*
| | | |--<uri> | | | |--<uri>
| | | |--<display-text> | | | |--<display-text>
| | | |--<purpose> | | | |--<purpose>
| | |--<H323> | | |--<H323>*
| | | |--<H.323-alias> | | | |--<H.323-alias>*
| | | |--<H.323-URI> | | | |--<H.323-URI>*
| | |--<PSTN/ISDN> | | |--<PSTN-ISDN>*
| | | |--<phone number> | | | |--<phone number>*
| | | |--<PIN-code>
| | | |--<purpose>
| | | |--<rate>
| | ... | | ...
| |--<service-uris> | |--<service-uris>
| | |--<SIP> | | |--<entry>*
| | | |--<uri> | | | |--<uri>
| | | |--<display-text> | | | |--<display-text>
| | | |--<purpose> | | | |--<purpose>
| | |--<H323> | | |--<H323>*
| | | |--<H.323-alias> | | | |--<H.323-alias>*
| | | |--<H.323-URI> | | | |--<H.323-URI>*
| | |--<PSTN/ISDN> | | |--<PSTN-ISDN>*
| | | |--<phone number> | | | |--<phone number>*
| | |--<BFCP>
| | | |--<conference-ID>
| | ... | | ...
| |--<maximum-user-count> | |--<maximum-user-count>
| | |--<entry>
| | |--<entry>
| | ...
| |--<maximum-streams>
| | |--<entry>
| | |--<entry>
| | ... | | ...
| |--!<available-media> | |--!<available-media>
| | |--!<entry> | | |--!<entry>
| | | |--<type> | | | |--<type>
| | | |--<display-text> | | | |--<display-text>
| | | |--<status> | | | |--<status>
| | | |--<mixing-mode> | | | |--<mixing-mode>*
| | | |--<mix-level> | | | |--<mix-level>*
| | | |--<codecs> | | | |--<codecs>*
| | | | |--<entry> | | | | |--<entry>*
| | | | |--<entry> | | | | |--<entry>*
| | | | ... | | | | ...
| | | |--<controls> | | | |--<controls>*
| | | | |--<mute> | | | | |--<mute>*
| | | | |--<gain> | | | | |--<gain>*
| | | | ... | | | | ...
| | |--<entry> | | |--<entry>
| | | |--<type> | | | |--<type>
| | | |--<display-text> | | | |--<display-text>
| | | |--<status> | | | |--<status>
| | | |--<mixing-mode> | | | |--<mixing-mode>*
| | | |--<mix-level> | | | |--<mix-level>*
| | | |--<codecs> | | | |--<codecs>*
| | | | |--<entry> | | | | |--<entry>*
| | | | |--<entry> | | | | |--<entry>*
| | | | ... | | | | ...
| | | |--<controls> | | | |--<controls>*
| | | | |--<pause-video> | | | | |--<pause-video>*
| | | | |--<video-layout>*
| | | | ... | | | | ...
| | ... | | ...
| |
|--!<host-info> |--<host-info>
| |--<display-text> | |--<display-text>
| |--<web-page> | |--<web-page>
| |--!<uris> | |--!<uris>
| | |--!<SIP> | | |--!<entry>
| | | |--!<uri> | | | |--!<uri>
| | | |--<display-text> | | | |--<display-text>
| | | |--<purpose> | | |--<H323>*
| | |--<H323> | | | |--<H.323-alias>*
| | | |--<H.323-alias> | | | |--<H.323-URI>*
| | | |--<H.323-URI> | | |--<PSTN-ISDN>*
| | |--<PSTN/ISDN> | | | |--<phone number>*
| | | |--<phone number>
| ... | ...
|--!<conference-state> |--<conference-state>
| |--<allow-conference-state> | |--<allow-conference-event-subscription>*
| |--<user-count> | |--<user-count>
| |--!<active> | |--!<active>
| |--<locked> | |--<locked>
| |
|--<floor-information> |--<floor-information>*
| |--<allow-floor-events> | |--<allow-floor-events>*
| |--<floor-request-handling> | |--<floor-request-handling>*
| |--<conference-floor-policy> | |--<conference-floor-policy>*
| | |--<floor> | | |--<floor>*
| | | |--<media-types> | | | |--<media-types>*
| | | |--<algorithm> | | | |--<algorithm>*
| | | |--<max-floor-users> | | | |--<max-floor-users>*
| | | |--<moderator-uri> | | | |--<chair-id>*
| | | |--<moderator-uri> | | | |--<chair-id>*
| | | ... | | | ...
| | ... | | ...
| |
|--!<users> |--!<users>
| |--<join-handling> | |--<join-handling>*
| |--<user-admission-policy> | |--<user-admission-policy>*
| |--<allowed-users-list> | |--<allowed-users-list>*
| | |--<target> | | |--<target>*
| | |-- ... | | |-- ...
| | | |
| |--<privileges-control-list>
| | |--<conference-rules>
| | | |--<entry>
| | | | |--<condition>
| | | | | |--<identity>
| | | | | | |
| | | | | | ...
| | | | | |
| | | | | |--<validity>
| | | | | | |--<from>
| | | | | | |--<until>
| | | | |
| | | | |--<actions>
| | | | | |
| | | | | ...
| | | ...
| | | |
| |--!<user> | |--!<user>
| | |--<display-text> | | |--<display-text>
| | |--<associated-aors> | | |--<associated-aors>
| | |--<provide-anonymity> | | |--<provide-anonymity>*
| | |--<roles> | | |--<roles>
| | | | | | | |
| | | ... | | | ...
| | |--<languages> | | |--<languages>
| | |--<cascaded-focus> | | |--<cascaded-focus>
| | |--<sphere> | | |--<allow-refer-users-dynamically>*
| | |--<allow-refer-users-dynamically> | | |--<allow-invite-users-dynamically>*
| | |--<allow-invite-users-dynamically> | | |--<allow-remove-users-dynamically>*
| | |--<allow-remove-users-dynamically>
| | |--!<endpoint> | | |--!<endpoint>
| | | |--<display-text> | | | |--<display-text>
| | | |--<referred> | | | |--<referred>
| | | |--<status> | | | |--<status>
| | | |--<joining-method> | | | |--<joining-method>
| | | |--<joining-info> | | | |--<joining-info>
| | | |--<disconnection-method> | | | |--<disconnection-method>
| | | |--<disconnection-info> | | | |--<disconnection-info>
| | | |--!<media> | | | |--!<media>
| | | | |--<type> | | | | |--<type>
| | | | |--<display-text> | | | | |--<display-text>
| | | | |--<label> | | | | |--<label>
| | | | |--<src-id> | | | | |--<src-id>
| | | | |--<status> | | | | |--<status>
| | | | |--<to-mixer> | | | | |--<to-mixer>*
| | | | | |--<floor> | | | | | |--<floor>*
| | | | | |--<controls> | | | | | |--<controls>*
| | | | | | |--<mute> | | | | | | |--<mute>*
| | | | | | |--<gain> | | | | | | |--<gain>*
| | | | | | ... | | | | | | ...
| | | | |--<from-mixer> | | | | |--<from-mixer>*
| | | | | |--<floor> | | | | | |--<floor>*
| | | | | |--<controls> | | | | | |--<controls>*
| | | | | | |--<pause-video> | | | | | | |--<pause-video>*
| | | | | | ... | | | | | | ...
| | | | ... | | | | ...
| | | |--<call-info> | | | |--<call-info>
| | | | |--<sip> | | | | |--<sip>
| | | | | |--<display-text> | | | | | |--<display-text>
| | | | | |--<call-id> | | | | | |--<call-id>
| | | | | |--<from-tag> | | | | | |--<from-tag>
| | | | | |--<to-tag> | | | | | |--<to-tag>
| ... ... | ... ...
|--<sidebars-by-ref> |--<sidebars-by-ref>
skipping to change at page 9, line 42 skipping to change at page 13, line 40
| | |-- <display-text> | | |-- <display-text>
| ... | ...
|--<sidebars-by-val> |--<sidebars-by-val>
| |--<entry> | |--<entry>
| | | | | |
| | ... | | ...
| |--<entry> | |--<entry>
| | | | | |
| ... ... | ... ...
Following sections describe these elements in detail. The full XML The following sections describe these elements in detail. The full
schema is provided in Section 4. Relax NG schema is provided Section 5.
3.2. Common Conference Policies
Conference policies collectively refers to a set of rights,
permissions and limitations pertaining to operations being performed
on a certain conference object data model.
The set of rights describes the read/write access privileges for the
conference object data model as a whole. Every element of the data
model SHOULD has defined two attributes: the attribute 'read-only',
and the attribute 'read-write'. These attributes describes the read/
write access privileges for accessing the Conference Object as a
whole. It is partially described in [1]. When the conferencing
server receives a request for access privacy-sensitive data it needs
to match it against the 'read-only' and the 'read-write' attributes.
Each attribute of each individual element is evaluated and as a
result it is determined if the user can access that element. The
attributes specify the minimum subscriber's role that can access or
modify the element of the conference. Subscribers with a lower role
cannot access or modify the element. If an attribute is not defined
in some element, the 'read-only' attribute MUST be interpreted as a
"participant" and the 'read-write' attribute MUST be interpreted as
an "administrator" by default. It is possible to defined only one of
the attributes of the element, the other attribute SHOULD be
interpreted by default. This draft does not define the set of
possible conferencing roles.
However, it can also be the case that conflicts can occur given a
hierarchy of elements. In that case, the lower-level element
privileges predominate over the upper-level privileges element.
This document defines a more specific right mechanism in Section
3.7.2, beyond the 'read-only' and 'read-write' attributes.
The permissions and limits are specified as an integral part of the
data model, with elements containing the allowed ranges for other
elements (e.g., maximum number of participants) and lists of clients
allowed to perform certain operations on a conference object.
3.3. <conference-description>
The <conference-description> element describes the conference in its 4.1. <conference-description>
entirely. It SHOULD have an extra attribute 'xml:lang' to specify
the language used in the contents of this element as defined Section
2.12 of [5]. It is comprised of <display-text>, <subject>, <free-
text>, <keywords>, <web-page>, <security-level>, <allow-sidebars>,
<conference-stage>, <conference-time>, <conf-uris>, <service-uris>,
<maximum-user-count>, <maximum-streams>, and <available-media>.
The child elements <display-text>, <subject>, <free-text> and The <conference-description> element, which is defined in [2],
<keywords> are used to describe the conference content. These describes the conference as a whole. It SHOULD have an extra
elements are defined in [2]. attribute 'xml:lang' to specify the language used in the contents of
this element as defined in Section 2.12 of [5]. It is comprised of
<display-text>, <subject>, <free-text>, <keywords>, <allow-sidebars>,
<conference-time>, <conf-uris>, <service-uris>, <maximum-user-count>,
and <available-media>.
The child element <web-page> is an optional element that points to a The <display-text>, <subject>, <free-text> and <keywords> elements
URI with additional information about the conference. The child are defined in [2]. They are used to describe the conference's
elements <security-level> and <allow-sidebars> describe the content.
capabilities of the conference.
The <conference-stage> is a mandatory element that give the stage of The child element <allow-sidebars> describes the capabilities of the
the conference. This element can have 4 values: reserved, started, conference.
running, and ended. At the reserved stage the conference exists only
in the conference control server. There is no running focus and
there are no subscribers or notifications. The information is
accessible only via the conference control protocol. At the started
stage, there are no users yet in the conference, still it is possible
to subscribe to the conference state. The running stage starts when
the first user joins the conference. In the ended stage, there are
no users connected to the conference, the conference information is
only in the conference server for recurring conference or for CDR.
At this stage a user can get information only from the conference
control protocol. For instance, The Session Initiation Protocol
(SIP) Event Package for Conference State [2] is only applicable in
the start and running stage.
The <conference-time> child element has information related to The <conference-time> child element contains information related to
conference time and duration of the conference. Other elements from conference time and duration of the conference. The <conf-uris> and
different namespaces MAY be present for the purposes of <service-uris> are used to describe the conference-related
extensibility. The <conf-uris> and <service-uris> are used to identifiers. The <maximum-user-count> child element indicates the
describe the conference-related identifiers. The <maximum-user- number of users that can be invited to the conference. The
count> child element indicates the number of users that can be <available-media> child element is used to describe the media
invited to the conference. The <maximum-streams> child element
indicates the number of streams that can be for every media type.
The <available-media> child element is used to describe the media
characteristics of the conference. characteristics of the conference.
The following sections describe the remaining elements in more The following sections describe these elements in more detail. Other
detail. Other child elements can be used to extend <conference- child elements MAY be defined in the future to extend the
description> in the future. <conference-description> element.
3.3.1. <conference-time> 4.1.1. <conference-time>
The <conference-time> element contains the information related to The <conference-time> element contains the information related to
conference time and duration of a conference. The <conference-time> conference time and duration of a conference. The <conference-time>
element contains one or more <entry> elements each defining the time element contains one or more <entry> elements each defining the time
information of a single conference occurrence. information specifying a single conference occurrence.
Every <entry> element contains a <mixing-start-offset> child element Every <entry> element contains a <mixing-start-offset> child element
that specifies when conference media mixing starts before the that specifies when conference media mixing starts before the
conference starts, <mixing-end-offset> child element that specifies conference starts, <mixing-end-offset> child element that specifies
the time a conference media mixing stops after the conference stops. the time a conference media mixing stops after the conference stops.
The <mixing-end-offset> child element expresses the offset as signed The <mixing-end-offset> child element expresses the offset as signed
integers representing seconds before/after DTEND field. The <mixing- integers representing seconds before/after DTEND field. The <mixing-
start-offset> child element expresses the offset as signed integers start-offset> child element expresses the offset as signed integers
representing seconds before/after DTSTART field. If the <mixing- representing seconds before/after DTSTART field. If the <mixing-
start-offset> element is not present, it indicates that the start-offset> element is not present, it indicates that the
conference media mixing starts immediately. If the <mixing-end- conference media mixing starts immediately. If the <mixing-end-
offset> element is not present, it indicates that the conference offset> element is not present, it indicates that the conference
occurrence is not bounded. <mixing-start-offset> and <mixing-end- occurrence is not bounded. <mixing-start-offset> and <mixing-end-
offset> elements both have the mandatory 'require-participant' offset> elements both have the mandatory 'require-participant'
attribute. This attribute has one of 4 values: 'none', attribute. This attribute has one of 4 values: "none",
'administrator', 'moderator', and 'participant'. For mixing start "administrator", "moderator", and "participant". For <mixing-start-
offset, this attribute allows a privileged user to define when media offset>, this attribute allows a privileged user to define when media
mixing starts based on the latter of the mixing start time, and the mixing starts based on the latter of the mixing start time, and the
time the first participant, administrator, or moderator arrives. If time the first participant, administrator, or moderator arrives. If
the value is set to 'none', mixing starts according to the mixing the value is set to "none'", mixing starts according to the mixing
start time. For mixing end offset, this attribute allows a start time. For <mixing-end-offset>, this attribute allows a
privileged user to define when media mixing ends based on the earlier privileged user to define when media mixing ends based on the earlier
of the mixing end offset, and the time the last participant, or of the <mixing-end-offset>, and the time the last participant, or
moderator leaves. If the value is set to 'none', mixing stops moderator leaves. If the value is set to "none", mixing stops
according to the mixing end offset. If the conference policy was according to the <mixing-end-offset>. If the conference policy was
modified so that last privileged user is now a normal conference modified so that last privileged user is now a normal conference
participant, and the conference requires a privileged user to participant, and the conference requires a privileged user to
continue; that conference MUST terminate. continue; that conference MUST terminate.
An administrator can indicate the time when users can join a An administrator can indicate the time when users can join a
conference by populating the <can-join-after-offset> element. conference by populating the <can-join-after-offset> element.
Similarly, an administrator can define the time after which new users Similarly, an administrator can define the time after which new users
are not allowed to join the conference anymore. This is done by are not allowed to join the conference anymore. This is done by
populating the <must-join-before-offset> element expressing the populating the <must-join-before-offset> element expressing the
offset as signed integers representing seconds before/after DTSTART offset as signed integers representing seconds before/after DTSTART
field. field.
The <base> child element specifies the iCalendar object of the The <base> child element specifies the iCalendar object of the
conference. The iCalendar object components are defined in [6]. conference. The iCalendar object components are defined in [6].
The <entry> element also contains the <request-user> child element. The <entry> element also contains the <request-user> child element.
It is possible to define the time when users or resources on the It is possible to define the time when users or resources on the
allowed-users-list is requested to join the conference by using the <allowed-users-list> is requested to join the conference by using the
<request-users> element. This element expresses the offset as signed <request-users> element. This element expresses the offset as signed
integers representing seconds before/after DTSTART field. integers representing seconds before/after DTSTART field.
The <notify-end-of-conference> element defines in seconds when the The <notify-end-of-conference> element defines in seconds when the
system has to send a notification when the end of the conference is system has to send a notification when the end of the conference is
near. If the <notify-end-of-conference> element is not present, it approaching. If the <notify-end-of-conference> element is not
indicates that the system does not notify the users when the end of present, it indicates that the system does not notify the users when
the conference is near. The <notify-end-of-conference> child element the end of the conference is approaching. The <notify-end-of-
expresses the offset as signed integers representing seconds before/ conference> child element expresses the offset as signed integers
after DTSTART field. The <allowed-extend-mixing-end-offset> refers representing seconds before/after DTSTART field. The <allowed-
to the possibility to extend the conference. It has two values: extend-mixing-end-offset> refers to the possibility to extend the
allowed, denied. conference. It has two values: "allowed", "denied".
3.3.2. <conf-uris> 4.1.2. <conf-uris>
The <conf-uris> contains the identifiers to be used in order to The <conf-uris> contains the identifiers to be used in order to
access the conference by different signaling means. It contains a access the conference by different signaling means. It contains a
sequence of child elements: <SIP>, <H.323>, and <PSTN/ISDN>. The sequence of child elements: <entry>, <H.323>, and <PSTN-ISDN>. The
<SIP> element contains the <uri>, <display-text>, and <purpose>. <entry> element refers to the SIP protocol. It keeps the same name
<uri>, <display-text>, and <purpose> are described in [2]. The that is defined in [2] to maintain backwards compatibility with this
<H.323> element includes either a <H.323-alias> or a <H.323-URI> RFC. The <entry> element contains the <uri>, <display-text>, and
child elements. The <PSTN/ISDN> has an attribute 'PIN code' with the <purpose> which are described in [2]. The currently defined
<purpose> values to be used with the <conf-uris> are:
o participation: Accessing a URI with this <purpose> will bring the
party into the conference
o streaming: Accessing a URI with this <purpose> will commence
streaming the conference, but not allow active participation
The <H.323> element includes either a <H.323-alias> or a <H.323-URI>
child elements. The <PSTN-ISDN> has an attribute 'PIN code' with the
PIN code of the conference if used and a 'purpose' attribute that PIN code of the conference if used and a 'purpose' attribute that
describes to the user which phone number to use. <PSTN/ISDN> element describes to the user which phone number to use. The <PSTN-ISDN>
may include 1 or more <phone number> child elements and the call rate element may include one or more <phone number> child elements.
as well.
3.3.3. <service-uris> 4.1.3. <service-uris>
The <service-uris> describes auxiliary services available for the The <service-uris> describes auxiliary services available for the
conference. It contains a sequence of child elements: <SIP>, conference. It contains a sequence of child elements: <entry>,
<H.323>, <PSTN/ISDN>, and <BFCP>. <SIP> child element contains <uri>, <H.323>, <PSTN-ISDN>, and <BFCP>. The <entry> child element contains
<display-text>, and <purpose>. The purpose will be used to describe <uri>, <display-text>, and <purpose>. The purpose will be used to
the service. These elements are described in [2]. <H.323>, and describe the service. The currently defined <purpose> values to be
<PSTN/ISDN> child elements are described in <conf-uris> section. The used with the <service-uris> are:
<BFCP> has a sub-element <conference-ID> that are used by a floor o web-page: Indicates the web page containing the additional
control server to provide a client with a conference ID. information about the conference
o recording: Indicates the link at which the recorded conference
context can be retrieved
o event: Indicates the URI at which a subscription to the conference
event package may be requested. This would typically be the
conference URI of the main conference
Future extensions to this schema may define new values and register
them with IANA. These elements are described in [2]. <H.323>, and
<PSTN-ISDN> child elements are described in the <conf-uris> section.
3.3.4. <maximum-user-count> 4.1.4. <maximum-user-count>
The <maximum-user-count> contains the overall number of users allowed The <maximum-user-count> contains the overall number of users allowed
to join the conference. It contains a sequence of <entry> child to join the conference. Note that this value is set by an
elements. An <entry> element MAY contain the number of users with a administrator and can reflect any local policies such as network
specific role allowed to join the conference. consumption, CPU processing power, and licensing rules.
3.3.5. <maximum-streams>
The <maximum-streams> contains the maximum number of streams that are
permitted to be involved in a conference. It contains a sequence of
<entry> child elements. An <entry> element MAY contain the number of
streams of every specific type of stream, for instance, audio or
video. The minimum value permitted is "1" and the maximum value
permitted is "128". This element is optional.
3.3.6. <available-media> 4.1.5. <available-media>
The <available-media> has the 'label' attribute that is the media The <available-media> has the 'label' attribute that is the media
stream identifier assigned by the conferencing server. This element stream identifier assigned by the conferencing server. This element
contains a sequence of <entry> child elements of conference-medium- contains a sequence of <entry> child elements of conference-medium-
type. Each <entry> element contains the <type>, <display-text>, type. Each <entry> element contains the <type>, <display-text>,
<status>, <mixing-mode>, <mix-level>, <controls> and <codecs> child <status>, <mixing-mode>, <mix-level>, <controls> and <codecs> child
elements. The attribute 'label' and the <type>, <display-text>, and elements. The attribute 'label' and the <type>, <display-text>, and
<status> elements are described in [2]. The <codecs> element <status> elements are described in [2]. The <codecs> element
specifies the allowed codecs in the conference. It has an attribute specifies the allowed codecs in the conference. It has an attribute
'decision' that specifies if the focus decides the common codec 'decision' that specifies if the focus decides the common codec
automatically or needs the approvement of the moderator of the automatically or needs the approval of the moderator of the
conference (automatic, moderator-controlled). The <codecs> element conference ("automatic", "moderator-controlled"). The <codecs>
contains a <entry> elements. A <entry> element can have the element contains <entry> elements. A <entry> element can have the
attribute 'name' and 'policy'. The 'name' attribute identifies a attribute 'name' and 'policy'. The 'name' attribute identifies a
codec, and the 'decision' attribute and the policy attribute contains codec, and the 'decision' attribute contains the policy for that
the policy for that codec (allowed, or disallowed). codec (allowed, or disallowed).
The child elements <mixing-mode>, <mix-level> describe a default The child elements <mixing-mode> and <mix-level> describe a default
policy by which the mixer will build the outgoing stream from the policy by which the mixer will build the outgoing stream from the
incoming streams. Notice that this policy is different that the incoming streams. Notice that this policy is different than the
policy describe for the floors for each media. The <mix-level> child policy describing the floors for each media. The <mix-level> child
element describes the number of participants in audio media streams element describes the number of participants in audio media streams
or the number of sub-windows in video media streams (for instance, a or the number of sub-windows in video media streams (for instance, a
value of 4 in the <mix-level> element for video stremas means 2x2 value of "4" in the <mix-level> element for video streams implies a
layout). The <mixing-mode> child element MUST contain one and only 2x2 layout). The <mixing-mode> child element MUST contain one and
one of the "Moderator-controlled", "FCFS", and "Automatic" values only one of the "Moderator-controlled", "FCFS", and "Automatic"
indicating the default algorithm to be use with every media stream. values indicating the default algorithm to be use with every media
Next section explains the <controls> child element. stream. The next section explains the <controls> child element.
3.3.7. <controls> 4.1.5.1. <controls>
The <controls> element contains the basic audio and video global The <controls> element contains the basic audio and video global
controls for a conferencing. It is expected that for most of the controls for a conference. It is expected that for the majority of
basic conferencing, these controls are sufficient. If the conference the basic conferences, these controls are sufficient. If the
server wants to support more advanced control, then it is recommended conference server wants to support more advanced controls, then it is
extension of the data model to be used. In the <controls> element recommended that an extension of the data model be used. In the
the schema is extensible, hence new control types can be added in a <controls> element the schema is extensible, hence new control types
future. Similarly, controls that apply to a especific users would can be added in the future. Similarly, controls that apply to a
appear under the <users>/<user>/<endpoint> element. So, moderator specific user would appear under the <users>/<user>/<endpoint>
controls that affect all media output would go under the <available- element. So moderator controls that affect all media output would go
media> element. under the <available-media> element.
3.3.7.1. mute 4.1.5.1.1. mute
The 'mute' control is used in conjunction with a audio stream to The 'mute' control is used in conjunction with an audio stream to
cease transmission of associated media. It has a 'Boolean' value. cease transmission of associated media. It has a "boolean" value.
If this control is not specify, the access to the control is not If this control is not specified, access to the control is not
available to the client and media SHOULD not be transported for the available to the client and media SHOULD NOT be transported for the
associated media stream. associated media stream.
3.3.7.2. pause-video 4.1.5.1.2. pause-video
The 'pause-video' control is used in conjunction with a video stream The 'pause-video' control is used in conjunction with a video stream
to cease transmission of associated media. It has a 'Boolena' value. to cease transmission of associated media. It has a "boolean" value.
If this control is not specified, access to the control is not
If this control is not specify, the access to the control is not available to the client and media SHOULD NOT be transported for the
available to the client and media SHOULD not be transported for the
associated media stream. associated media stream.
3.3.7.3. gain 4.1.5.1.3. gain
The 'gain' control is used in conjunction with a media output stream The 'gain' control is used in conjunction with a media output stream
to indicate the amount of amplification of an audio stream. It has a to indicate the amount of amplification of an audio stream. It has a
'Int' number value from -127 to 127. If this control is not specify, "int" number value. If this control is not specified, access to the
the access to the control is not available to the client. control is not available to the client.
3.4. <host-info> 4.1.5.1.4. video-layout
The 'video-layout' control is used in conjunction with a video stream
to specify how the video streams (participants) are viewed by each
participant. Only one layout type can be specified for each output
stream. If there are fewer participants than panels in the specified
layout, then blanking (black screen) MAY be mixed into the stream on
the behalf of the missing input streams. If unspecified, the <video-
layout> default type SHOULD be "single-view".
The <layout> types are as follows:
single-view: Only one stream is presented by the focus to all
participants in one panel.
dual-view: This dual view option will present the video side-by-side
in 2 panels and not alter the aspect ratio of the streams. This will
require the focus to introduce blanking on parts of the overall image
as viewed by the participants.
dual-view-crop: This side-by-side layout option instructs the focus
to alter the aspect ratio of the streams (alter-aspect-ratio=TRUE) so
that blanking is not necessary. The focus handles the cropping of
the streams.
dual-view-2x1: This layout option instructs the focus to place one
stream above the other, in essence with two rows and one column. In
this option the aspect ratio is not altered and blanking is
introduced.
dual-view-2x1-crop: This layout option also instructs the focus to
place one stream above the other, in essence with two rows and one
column. In this option the aspect ratio is altered and the video
streams are cropped.
quad-view: Four equal-sized panels in a 2x2 layout is presented by
the focus to all participants. Typically the aspect ratio of the
streams are maintained (alter-aspect-ratio= FALSE).
multiple-3x3: Nine equal-sized panels in a 3x3 layout is presented by
the focus to all participants. Typically the aspect ratio of the
streams are preserved.
multiple-4x4: Sixteen equal-sized panels in a 4x4 layout is presented
by the focus to all participants. Typically the aspect ratio of the
streams are preserved.
multiple-5x1: This option refers to a 5x1 layout where one panel will
occupy 4/9 of the mixed video stream while the others will each
occupy 1/9 of the stream. Typically the aspect ratio of the streams
is preserved.
automatic: This option allows the focus to add panels as streams are
added up to a limit of "panels".
4.2. <host-info>
The <host-info> element contains information about the entity hosting The <host-info> element contains information about the entity hosting
the conference. It contains the <display-text>, <web-page> child the conference. This information is set before the conference
elements. These child elements are explained in [2]. <host-info> activation, and is rarely changed during the conference lifetime.
contains the <uris> child element as well. <uris> contains a sequence The <host-info> element contains the <display-text>, <web-page> and
of child elements: <SIP>, <H.323>, and <PSTN/ISDN>. The child <uris> child elements. The <display-text> and <web-page> child
elements of <uris> are described in <conf-uris> section. elements are explained in [2]. The <uris> child element contains a
sequence of child elements: <entry>, <H.323>, and <PSTN-ISDN>. The
<entry> element refers to the SIP protocol. It keeps the same name
that is defined in [2] to maintain backwards compatibility with this
RFC. Future extensions to the <uris> element may define new values.
3.5. <conference-state> 4.3. <conference-state>
The <conference-state> element and the <user-count>, <active>, and The <conference-state> element and the <user-count>, <active>, and
<locked> child element are explained in section 5.5 of [2]. The <locked> child elements are explained in section 5.5 of [2]. The
<allow-conference-state> element represents a boolean action. If set <allow-conference-event-subscription> element represents a boolean
to TRUE, the focus is instructed to allow the subscription to action. If set to TRUE, the focus is instructed to allow the
conference state events, such as the SIP Event Package for Conference subscription to conference state events, such as the SIP Event
State [2]. If set to FALSE, the subscription to conference state Package for Conference State [2]. If set to FALSE, the subscription
events would be rejected. If this element is undefined it has a to conference state events would be rejected. If this element is
value of TRUE, causing the subscription to conference state events to undefined it has a default value of TRUE, causing the subscription to
be accepted. conference state events to be accepted.
3.6. <floor-information> 4.4. <floor-information>
The <floor-information> element has the <allow-floor-events>, <floor- The <floor-information> element has the <conference-ID>, <allow-
request-handling>, and the <conference-floor-policy> child elements. floor-events>, <floor-request-handling>, and <conference-floor-
Other elements from different namespaces MAY be present for the policy> child elements. Other elements from different namespaces MAY
purposes of extensibility. This element has its own XML namespace. be present for the purposes of extensibility. This element has its
The absence of this namespace and its elements from an XML document own XML namespace. The absence of this namespace and its elements
indicates that the conference does not have a floor. from an XML document indicates that the conference does not have a
floor.
The <conference-ID> is used by a floor control server to provide a
client with a conference ID.
The <allow-floor-events> element represents a boolean action. If set The <allow-floor-events> element represents a boolean action. If set
to TRUE, the focus is instructed to accept the subscription to floor to TRUE, the focus is instructed to accept the subscription to floor
control events. If set to FALSE, the focus is instructed to reject control events. If set to FALSE, the focus is instructed to reject
the subscription. If this element is undefined, it has a value of the subscription. If this element is undefined, it has a default
FALSE, causing the subscription to floor control events to be value of FALSE, causing the subscription to floor control events to
rejected. be rejected.
The <floor-request-handling> element defines the actions used by the The <floor-request-handling> element defines the actions used by the
conference focus to control floor requests. This element defines the conference focus to control floor requests. This element defines the
action that the focus is to take when processing a particular request action that the focus is to take when processing a particular request
to a floor within a conference. This element defines values of: to a floor within a conference. This element defines values of:
o block: This action instructs the focus to deny the floor request. o "block": This action instructs the focus to deny the floor
This action is the default action taken in the absence of any request. This action is the default action taken in the absence
other actions. of any other actions.
o confirm: This action instructs the focus to allow the request. o "confirm": This action instructs the focus to allow the request.
The focus then uses the defined floor algorithm to further allow The focus then uses the defined floor algorithm to further allow
of deny the floor. The algorithms used are outside the scope of or deny the floor. The algorithms used are outside the scope of
this document. this document.
Note that placing a value of block for this element does not Note that placing a value of "block" for this element does not
guarantee that a participant is blocked from joining the conference. guarantee that a participant is blocked from joining the conference.
Any other rule that might evaluate to true for this participant that Any other rule that might evaluate to TRUE for this participant that
carried an action whose value was higher than block would carried an action whose value was higher than "block" would
automatically grant confirm/allow permission to that participant. automatically grant confirm/allow permission to that participant.
The <conference-floor-policy> element is mandatory and contains the The <conference-floor-policy> element is mandatory and contains the
required boolean attribute that indicates if the floor is moderator required boolean attribute that indicates if the floor is moderator
controlled or not. One or more <Floor> elements can appear in the controlled or not. One or more <floor> elements can appear in the
<conference-floor-policy> element. Every floor is defined using the <conference-floor-policy> element. Every floor is defined using the
'label' attribute. If the <available-media> information is included 'label' attribute. If the <available-media> information is included
in the conference document, the value of this attribute MUST be equal in the conference document, the value of this attribute MUST be equal
to the 'label' value of the corresponding media stream <entry> in the to the 'label' value of the corresponding media stream <entry> in the
<available-media> container. The number of those elements indicates <available-media> container. The number of those elements indicates
how many floors the conference can have. A floor can be used for one how many floors the conference can have. A floor can be used for one
or more media types; the mandatory <Media-types> element can contain or more media types; the mandatory <media-types> element can contain
zero or more of the <Video>, <Audio>, <Application>, <Data> zero or more of the <video>, <audio>, <application>, <data>
,<Control>, <Message>, and <text> elements indicating the media of ,<control>, <message>, and <text> elements indicating the media of
the floor. One type of media can only appear once. Other media the floor. One type of media can only appear once. Other media
types can be defined by extensions. types can be defined by extensions.
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 <Moderator- <algorithm> element MUST contain one and only one of the <moderator-
controlled>, <FCFS>, and <Random> elements indicating the algorithm. controlled>, <FCFS>, and <random> elements indicating the algorithm.
The <Max-floor-users> element in the <Floor> element is optional and, The <max-floor-users> child element in the <floor> element is
if present, dictates the maximum number of users who can have the optional and, if present, dictates the maximum number of users who
floor at one time. The optional <Moderator-URI> indicates the URI of can have the floor at one time. The optional <chair-id> indicates
the moderator. It MUST be set if the attribute moderator-controlled the BFCP UserID of the moderator. It MUST be set if the attribute
is set to "true". moderator-controlled is set to TRUE.
3.7. <users> 4.5. <users>
The <users> element contains the <join-handling>, <user-admission- The <users> element contains the <join-handling>, <user-admission-
policy>, <allowed-users-list>, <privileges-control-list> and <user> policy>, <allowed-users-list>, and <user> child elements.
child elements.
The <join-handling> element defines the actions used by the The <join-handling> element defines the actions used by the
conference focus to control conference participation. This element conference focus to control conference participation. This element
defines the action that the focus is to take when processing a defines the action that the focus is to take when processing a
particular request to join a conference. This element defines values particular request to join a conference. This element defines values
of: of:
o block: This action instructs the focus to deny access to the o "block": This action instructs the focus to deny access to the
conference. This action is the default action taken in the conference. This action is the default action taken in the
absence of any other actions. absence of any other actions.
o confirm: This action instructs the focus to place the participant o "confirm": This action instructs the focus to place the
on a pending list (e.g., by parking the call on a music-on-hold participant on a pending list (e.g., by parking the call on a
server), awaiting moderator input for further actions. music-on-hold server), awaiting moderator input for further
o allow: This action instructs the focus to accept the conference actions.
o "allow": This action instructs the focus to accept the conference
join request and grant access to the conference within the join request and grant access to the conference within the
instructions specified in the transformations of this rule. instructions specified in the transformations of this rule.
o IVR: This action instructs the focus that the user has to define o "IVR": This action instructs the focus that the user has to
the PIN code. provide the PIN code.
o directed-operator: This action instructs the focus to direct the o "directed-operator": This action instructs the focus to direct the
user to an operator. user to an operator.
Note that placing a value of block for this element does not Note that placing a value of block for this element does not
guarantee that a participant is blocked from joining the conference. guarantee that a participant is blocked from joining the conference.
Any other rule that might evaluate to true for this participant that Any other rule that might evaluate to TRUE for this participant that
carried an action whose value was higher than block would carried an action whose value was higher than "block" would
automatically grant confirm/allow permission to that participant. automatically grant confirm/allow permission to that participant.
The <user-admission-policy> element is a list of three elements: The <user-admission-policy> is an element that lets an organizer (or
'closedAuthenticated', 'openAuthenticated', and 'anonymous'. If the a participant with appropriate rights) choose a policy for the
<user-admission-policy> element is set to 'closedAuthenticated', conference that controls how users are allowed into the conference.
users must be specified (and authenticate). If the attribute is set A 'closedAuthenticated' policy requires each conference participant
to 'openAuthenticated', users can be add after conference activation. to be in the allowed users list (listed under the <allowed-users-
list> XML element) with each participant being sufficiently (up to
local policy) authenticated. Conference join requests for users not
in the allowed users list or participants not authenticated should be
rejected unless a <join-handling> action of 'confirm' is selected in
which case the user is placed on a pending list as indicated earlier.
An 'openAuthenticated' policy requires each conferencing participant
to be sufficiently authenticated (as before) but does not restrict
which participants can join the conference. Typically this implies
that anyone capable of authenticating with the conferencing system
may join the conference. An 'anonymous' policy allows any join
requests in and is the least restrictive in policies.
The following sections describe the remaining elements in more The following sections describe the remaining elements in more
detail. Other child elements can be used to extend <conference- detail. Other child elements can be used to extend <conference-
description> in the future. description> in the future.
3.7.1. <allowed-users-list> 4.5.1. <allowed-users-list>
The <allowed-users-list> child element contains a list of user URIs, The <allowed-users-list> child element contains a list of user URIs,
PSTN phone numbers, roles, or domains (*@example.com) that the focus PSTN phone numbers, roles, or domains (*@example.com) that the focus
uses to determine who can join the conference, who can invite to join uses to determine who can join the conference, who can be invited to
a conference, or who the focus needs to "refer to" the conference. join a conference, or who the focus needs to "refer to" the
The <allowed-users-list> element includes zero or more <target> child conference. The <allowed-users-list> element includes zero or more
element. This child element includes the mandatory 'uri' attribute <target> child elements. This child element includes the mandatory
and the mandatory 'method' attribute. The same 'uri' attribute with 'uri' attribute and the mandatory 'method' attribute. The same 'uri'
different method values can appear in the list more than once. The attribute with different method values can appear in the list more
'method' attribute is a list with the following values: "dial-in", than once. The 'method' attribute is a list with the following
"dial-out, and "refer". The value "dial-in" is used by the focus to values: "dial-in", "dial-out", and "refer". The value "dial-in" is
determine who can join the conference. Value "refer" is used by the used by the focus to determine who can join the conference. The
focus to determine the resources that the focus needs to "refer to" value "refer" is used by the focus to determine the resources that
the conference. In SIP, this is achieved by the focus sending a the focus needs to "refer to" the conference. In SIP, this is
REFER request to those potential participants. In a different achieved by the focus sending a REFER request to those potential
paradigm, this could also mean that the focus sends an SMS or an participants. In a different paradigm, this could also mean that the
email to the referred user. This list can be updated during the focus sends an SMS or an email to the referred user. This list can
conference lifetime so it can be used for mid-conference refers as be updated during the conference lifetime so it can be used for mid-
well. conference refers as well.
The "refer" value differs from the "dial-out" in that the dial-out The "refer" value differs from the "dial-out" in that the "dial-out"
contains a list of resources that the focus will initiate a session contains a list of resources that the focus will initiate a session
with. The resources on the "refer" value, on the other hand, are with. The resources on the "refer" value, on the other hand, are
expected to initiate the session establishment towards the focus expected to initiate the session establishment toward the focus
themselves. It is also envisioned that difference users will have themselves. It is also envisioned that difference users will have
different access rights to those lists and therefore a separation different access rights to those lists and therefore a separation
between the two is needed. between the two is needed.
3.7.2. <privileges-control-list> 4.5.2. <user>
The <privileges-control-list> refers to a virtual set of rights The element <user> describes a single participant in the conference.
pertaining to operations. This element contains the <conference-
rules> element.
3.7.2.1. <conference-rules> The following elements of <user> are defined in [2], section 5.6:
<display-text>, <associated-aors>, <roles>, <languages>, <cascaded-
focus>, and <endpoint>. <user> has two attributes: 'entity' and
'state'. The attribute 'state' is defined in [2], section 5.6. The
attribute 'entity' contains a unique conference user identifier.
Other user identifiers can be associated with this conference user
identifier and enable the conferencing system to correlate and map
these multiple authenticated user identities to a single global user
identifier.
The <conference-rules> element is a set of <entry> child elements The <provide-anonymity> element provides anonymity to the user. In
with specific authorization rules that indicate who is allowed to this case, the focus provides to the rest of the participants an
subscribe to conference-information notifications, see floors, anonymous identity for that user, for example anonymousX. This can
request/grant floors, and so on. be achieved by using the <provide-anonymity> element. It is a
boolean transformation. If set to TRUE, the conference participants
will see an anonymous identity for the user whose identity is present
in the conditions.
Every <entry> element is represent by the 'id' attribute, each of The <endpoint> child element can provide the desired level of detail
which identifies a rule inside the conference. It contains the about the user's devices and their signaling sessions taking part in
<condition> and <actions> sub elements. the conference and has the following child elements defined in RFC
4575 [2]: <display-text>, <referred>, <status>, <joining-method>,
<joining-info>, <disconnection-method>, <disconnection-info>,
<media>, and <call-info>. The <endpoint>/<media> element has two
other child elements: <to-mixer>, and <from-mixer> described in the
following section.
3.7.2.1.1. <condition> 4.5.2.1. <from-mixer>, <to-mixer>
The <condition> element determines whether a particular privilege Similar to the controls defined in the <available-media> element,
applies to a user, a role, or domain. controls that apply to a particular user appear at this place in the
data structure. The <to-mixer> element details properties associated
with the incoming streams to the mixer. The <from-mixer> element
details properties associated with the outgoing streams from the
mixer. Both of these elements have the attribute 'name'. The 'name'
attribute has the values "VideoIn", "VideoOut", "AudioOut", and
"AudioIn". The "VideoOut" and "AudioOut" media streams detail
properties associated with the outgoing video and audio from the
mixer. The "VideoIn" and "AudioIn" media stream details properties
associated with the incoming video and audio to the mixer. More
values can be defined in the future.
The <condition> element has the <identity> and the <validity> child Each of these elements have the <floor> and <controls> child
element. These elements MUST NOT appear more than once in the elements.
condition part of a single rule.
The <identity> element restricts matching of a rule either to a 4.5.2.1.1. <floor>
single entity or a group of entities. The <identity> element has the
<one> and <many> child elements defined in Section 7.1 of [8]. The
absence of the <identity> element in a <condition> element indicates
that the privilege applies to all unauthenticated identities.
The <identity> element has other child elements. These child The <floor> element describes a floor that joins this participant in
elements are <pseudonymous>, <has-been-referred>, <has-been-invited>, the conference. If a participant, for instance, needs to talk in the
<has-been-in-conference>, <is-in-conference>, <administrator>, <is- conference, it first needs to get the floor from the chair of the
on-allowed-users-list-dial-out>, <is-on-allowed-users-list-refer>, conference.
<participant-passcode>, and <administrator-passcode>.
The <validity> element expresses the validity period of the rule with The <floor> element has a "Boolean" value. A value of FALSE
a starting and an ending time. The <validity> element and its child indicates that this user does not hold the floor in this moment. If
elements ,<from> and <until>, are defined in section 7.3 of [8]. this control is not specified, this user SHOULD NOT specify the floor
option.
3.7.2.1.2. <pseudonymous> 4.5.3. <sidebars-by-ref>
The <pseudonymous> element is used to match participants that have The <sidebars-by-ref> element contains a set of <entry> child
provided an authenticated identity to the conference focus, but have elements. Each <entry> child element contains a <user> child element
requested pseudonymity in the conference itself. A user requests with a sidebar unique conference user identifier and a <display-text>
pseudonymity by authenticating himself to the conference focus and child element.
providing a pseudonym in the signalling protocol (for example, using
the From-header of a SIP request).
The <pseudonymous> element can be combined with the <identity> 4.5.4. <sidebars-by-val>
element to provide the focus with a rule on what to do when a
specific identity is authenticated and that identity is requesting
pseudonymity through the signalling protocol.
3.7.2.1.3. <has-been-referred> The <sidebars-by-val> element contains a set of <entry> child
elements each containing information about a single sidebar. By
using this element, the server can include a full or partial
description of each sidebar (as a sub-conference) in the body of the
main conference document.
The <has-been-referred> element can be used to match those 5. RELAX NG Schema
participants that the focus has referred to the conference.
3.7.2.1.4. <has-been-invited> In accordance with the XCON framework document [1], the Conference
Object is a logical representation of a conference instance. The
conference information schema contains core information that is
utilized in any conference. It also contains the variable
information part of the Conference Object.
The <has-been-invited> element can be used to match those This specification defines some document fragments in RELAX NG
participants that the focus has invited into the conference. format.
3.7.2.1.5. <has-been-in-conference> namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace ns1 = "urn:ietf:params:xml:ns:conference-info-urn"
namespace ns2 = "urn:ietf:params:xml:ns:common-policy"
default namespace ns3 = "urn:ietf:params:xml:ns:conference-schema"
The <has-been-in-conference> element can be used to match those start = element conference-info { conference-type }
participants that have joined the conference in the past. # CONFERENCE TYPE
conference-type =
attribute entity { text },
attribute version { xsd:unsignedInt }?,
attribute state { state-type }?,
role-type,
conference-description-type,
element host-info { host-type }?,
element conference-state { conference-state-type }?,
element floor-information { floor-information-type }?,
element users { users-type },
element sidebars-by-ref { sidebars-by-ref-type }?,
element sidebars-by-val { sidebars-by-val-type }?,
anyElement*
# CONFERENCE DESCRIPTION TYPE
conference-description-type =
element conference-description {
role-type,
attribute xml:lang { xsd:language }?,
attribute state { state-type }?,
element display-text { text }?,
element subject { text }?,
element free-text { text }?,
element keywords {
list { xsd:string* }
}?,
element allow-sidebars { xsd:boolean }?,
element conference-time { conferencetime-type }?,
element conf-uris { uris-type }?,
element service-uris { uris-type }?,
element maximum-user-count { xsd:int }?,
element available-media { conference-media-type }?,
anyElement*
}
# CONFERENCE TIME
conferencetime-type =
role-type,
element entry {
element base { text }?,
element mixing-start-offset {
xsd:dateTime { pattern = ".+T.+Z.*" },
attribute required-participant { single-role-type },
anyAttribute
}?,
element mixing-end-offset {
xsd:dateTime { pattern = ".+T.+Z.*" },
attribute required-participant { single-role-type },
anyAttribute
}?,
element can-join-after-offset {
xsd:dateTime { pattern = ".+T.+Z.*" }
}?,
element must-join-before-offset {
xsd:dateTime { pattern = ".+T.+Z.*" }
}?,
element notify-end-of-conference { xsd:int }?,
element allowed-extend-mixing-end-offset {
allowed-extend-mixing-values
}?,
anyElement*
}*,
anyElement*
# ALLOWED EXTEND MIXING VALUES
allowed-extend-mixing-values =
xsd:string "allowed" | xsd:string "denied"
# URIS TYPE
uris-type =
role-type,
attribute state { state-type }?,
(element entry { uri-type }*
& element H323 { H323-type }*
& element PSTN-ISDN { PSTN-type }*),
anyElement*
# SIP TYPE
uri-type =
role-type,
(element uri { xsd:anyURI },
element display-text { text }?,
element purpose { text }?,
anyElement*)*
# H323 TYPE
H323-type =
role-type,
element H.323-alias { text }?,
element H.323-URI { xsd:anyURI }?,
anyElement*
# PSTN TYPE
PSTN-type =
role-type,
attribute PIN-code { xsd:unsignedInt },
attribute purpose { xsd:unsignedInt },
(element phone-number { xsd:unsignedInt },
anyElement*)+
# BFCP TYPE
BFCP-type =
role-type,
(element conference-ID { xsd:unsignedInt },
anyElement*)*
# MAXIMUM USER TYPE
maximum-user-count-type =
role-type,
anyAttribute,
(element entry {
xsd:unsignedInt,
attribute role { single-role-type }
},
anyElement*)+
# CONFERENCE MEDIA TYPE
conference-media-type =
role-type,
attribute state { state-type }?,
element entry { conference-medium-type }*,
anyElement*
# CONFERENCE MEDIUM TYPE
conference-medium-type =
role-type,
attribute label { text },
element display-text { text }?,
element type { text }?,
element status { media-status-type }?,
element mixing-mode { mix-mode-type }?,
element mix-level { xsd:unsignedInt }?,
element codecs { codecs-type }?,
element controls { controls-type }?,
anyElement*
# CONTROLS TYPE
controls-type =
role-type,
attribute state { state-type }?,
element control { control-type }*,
anyElement*
# MIX MODE TYPE
mix-mode-type =
xsd:string "moderator-controlled"
| xsd:string "FCFS"
| xsd:string "automatic"
# CODECS TYPE
codecs-type =
role-type,
attribute decision { decision-type },
element codec { codec-type }*,
anyElement*
# CODEC TYPE
codec-type =
role-type,
attribute name { text },
attribute policy { policy-type }
# DECISION TYPE
decision-type =
xsd:string "automatic" | xsd:string "moderator-controlled"
# POLICY TYPE
policy-type = xsd:string "allowed" | xsd:string "disallowed"
# CONTROL TYPE
control-type =
element mute { xsd:boolean }
| element pause-video { xsd:boolean }
| element gain {
xsd:int { minInclusive = "-127" maxInclusive = "127" }
}
| element video-layout {
xsd:string "single-view"
| xsd:string "dual-view"
| xsd:string "dual-view-crop"
| xsd:string "dual-view-2x1"
| xsd:string "dual-view-2x1-crop"
| xsd:string "quad-view"
| xsd:string "multiple-3x3"
| xsd:string "multiple-4x4"
| xsd:string "multiple-5x1"
| xsd:string "automatic"
}
| anyElement*
# HOST TYPE
host-type =
role-type,
(element display-text { text },
element web-page { xsd:anyURI },
element uris { uris-type },
anyElement*)*
# CONFERENCE STATE TYPE
conference-state-type =
role-type,
element allow-conference-event-subscription { xsd:boolean }?,
element user-count { xsd:unsignedInt }?,
element active { xsd:boolean }?,
element locked { xsd:boolean }?,
anyElement*
# FLOOR INFORMATION TYPE
floor-information-type =
role-type,
(element conference-ID { BFCP-type },
element allow-floor-events { xsd:boolean },
element floor-request-handling { floor-request-type },
element conference-floor-policy { Conference-floor-policy },
anyElement*)*
# FLOOR REQUEST TYPE
floor-request-type = xsd:string "block" | xsd:string "confirm"
# CONFERENCE FLOOR POLICY
Conference-floor-policy =
role-type,
element floor {
attribute moderator-controlled { xsd:boolean },
attribute label { text },
anyAttribute,
(element media-types {
role-type,
(xsd:string "video"
| xsd:string "audio"
| xsd:string "application"
| xsd:string "data"
| xsd:string "control"
| xsd:string "message"
| xsd:string "text")
},
element algorithm {
role-type,
(xsd:string "moderator-controlled"
| xsd:string "FCFS"
| xsd:string "random")
},
element max-floor-users { xsd:nonNegativeInteger },
element chair-id { xsd:anyURI },
anyElement*)*
}+
# USERS TYPE
users-type =
attribute state { state-type }?,
role-type,
element join-handling { join-handling-type }?,
element user-admission-policy { user-admission-policy-type }?,
element user-must-be-specified { xsd:boolean }?,
element allowed-users-list { UserList }?,
element user { user-type }*,
anyElement*
# USERS ADMISSION POLICY
user-admission-policy-type =
xsd:string "closedAuthenticated"
| xsd:string "openAuthenticated"
| xsd:string "anonymous"
# JOIN HANDLING TYPE
join-handling-type =
xsd:string "block"
| xsd:string "allow"
| xsd:string "confirm"
| xsd:string "IVR"
| xsd:string "directed-operator"
# USERLIST
UserList =
role-type,
element target { target-type }*,
anyElement*
# TARGET TYPE
target-type =
role-type,
attribute uri { xsd:anyURI },
attribute method { method-type }
# METHOD TYPE
method-type =
xsd:string "dial-in" | xsd:string "dial-out" | xsd:string "refer"
# USER TYPE
user-type =
role-type,
attribute entity { xsd:anyURI },
attribute state { state-type }?,
element display-text { text }?,
element associated-aors { uris-type }?,
element provide-anonymity { xsd:boolean }?,
element roles { roles-type }?,
element languages {
list { xsd:language }
}?,
element cascaded-focus { xsd:anyURI }?,
element allow-refer-users-dynamically { xsd:boolean }?,
element allow-invite-users-dynamically { xsd:boolean }?,
element allow-remove-users-dynamically { xsd:boolean }?,
element endpoint { endpoint-type }*,
anyElement*
# ENDPOINT TYPE
endpoint-type =
role-type,
attribute entity { text },
attribute state { state-type }?,
element display-text { text }?,
element referred { conference-info-urn* }?,
element status { endpoint-status-type }?,
element joining-method { joining-type }?,
element joining-info { conference-info-urn* }?,
element disconnection-method { disconnection-type }?,
element disconnection-info { conference-info-urn* }?,
element media { media-type }*,
element call-info { conference-info-urn* }?,
anyElement*
# MEDIA TYPE
media-type =
attribute id { xsd:int },
attribute state { state-type }?,
anyAttribute,
element display-text { text }?,
element type { text }?,
element label { text }?,
element src-id { text }?,
element status { media-status-type }?,
element to-mixer { mixer-type }?,
element from-mixer { mixer-type }?,
anyElement*
# MIXER TYPE
mixer-type =
role-type,
attribute state { state-type }?,
(element floor { xsd:boolean },
element controls { controls-type })?,
anyElement*
# SIDEBARS-BY-REF TYPE
sidebars-by-ref-type =
role-type,
attribute state { state-type }?,
element entry { uri-type }*,
anyElement*
# SIDEBARS-BY-VAL TYPE
sidebars-by-val-type =
role-type,
attribute state { state-type }?,
element entry { conference-type }*,
anyElement*
# ROLES_TYPE
roles-type =
element entry { single-role-type }*,
anyElement*
# ROLE TYPE
role-type =
attribute read-only { single-role-type }?,
attribute write-only { single-role-type }?,
anyAttribute
# SINGLE ROLE TYPE
single-role-type =
xsd:string "administrator"
| xsd:string "creator"
| xsd:string "moderator"
| xsd:string "participant"
| xsd:string "observer"
# *********************************
# EXTENSIBILITY OF THE SCHEMA
# *********************************
3.7.2.1.6. <is-in-conference> # EXTENSIBILITY ELEMENTS
anyElement =
element * {
(attribute * { text }
| text
| anyElement)*
}
# EXTENSIBILITY ATTRIBUTES
anyAttribute =
attribute * - (entity
| version
| state
| xml:lang
| required-participant
| PIN-code
| purpose
| role
| type
| min
| max
| label
| decision
| name
| policy
| moderator-controlled
| uri
| method
| id
| domain
| read-only
| write-only
| ns3:*) { text }*
# *************************************************************
# TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
# *************************************************************
The <is-in-conference> element can be used to match those # WILDCARD FOR EVENT-PACKAGE NAMESPACE
participants that are currently participating in the conference. conference-info-urn =
element * - ns1:* {
mixed {
(attribute * { text }
| conference-info-urn)*
}
}
# DEFINITION OF STATE TYPE
state-type = "full" | "partial" | "deleted"
# DEFINITION OF ENDPOINT STATUS TYPE
media-status-type = "recvonly" | "sendonly" | "sendrecv" | "inactive"
# ENDPOINT STATUS TYPE
endpoint-status-type =
"pending"
| "dialing-out"
| "dialing-in"
| "alerting"
| "on-hold"
| "connected"
| "muted-via-focus"
| "disconnecting"
| "disconnected"
# JOINING TYPE
joining-type = "dialed-in" | "dialed-out" | "focus-owner"
# DISCONNECTION TYPE
disconnection-type = "departed" | "booted" | "failed" | "busy"
# ******************************************
# TYPE DEFINED IN THE COMMON POLICY DOCUMENT
# ******************************************
3.7.2.1.7. <administrator> # WILDCARD FOR COMMON-POLICY NAMESPACE
common-policy =
element * - ns2:* {
mixed {
(attribute * { text }
| common-policy)*
}
}
The <administrator> element can be used to match those participants 6. XML Schema Extensibility
that are administrators of a conference.
3.7.2.1.8. <is-on-allowed-users-list-dial-out> The Conference Information Data Model defined in this document is
meant to be extensible toward specific application domains. Such
extensions are accomplished by defining elements, child elements and
attributes that are specific to the desired application domain. The
IETF MAY extend the data model schema with extension elements from
the same namespace, but other instances are free to extend it from
other than urn:ietf:params:xml:ns:conference-schema.
The <is-on-allowed-users-list-dial-out> element can be used to match Elements or attributes from unknown namespaces MUST be ignored.
those participants that are on the allowed-users-list with the method
dial-out.
3.7.2.1.9. <is-on-allowed-users-list-refer> 7. XML Example
The <is-on-allowed-users-list-refer> element can be used to match The following is an example of a conference information document.
those participants that are on the allowed-users-list with the method The conference starts on October 17, 2006, at 10:30 AM in New York
refer. City and finishes the same day at 12:30 PM every week. In this
example, there are currently 3 participants in a conference, one
administrator, one moderator, and one participant. Note that
sidebars are allowed in this conference and there is one sidebar in
the conference. Also note that there is one floor moderator for the
audio and a different floor moderator for the video.
3.7.2.1.10. <participant-passcode> <?xml version="1.0" encoding="UTF-8"?>
<conference-info xmlns="urn:ietf:params:xml:ns:conference-schema"
entity="conference123" state="full">
<!--
CONFERENCE DESCRIPTION
-->
The <participant-passcode> element can be used to match those <conference-description xml:lang="en-us">
participants that have knowledge of a passcode for the conference <display-text>Discussion of Formula-1 racing</display-text>
(PIN code). <subject> Sports:Formula-1</subject>
<free-text>This is a conference example</free-text>
<keywords>Formula-1, cars</keywords>
<webpage>http://www.example.com/users/formula-1</webpage>
<security-level>low</security-level>
<allow-sidebars>true</allow-sidebars>
<conference-stage>running</conference-stage>
<!--
CONFERENCE TIME
-->
<conference-time>
<entry>
<base>BEGIN:VCALENDAR
PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20051103T140728Z
UID:carol at example.com
ORGANIZER:MAILTO:carol at example.com
DTSTART:20061017T143000Z
RRULE:FREQ=WEEKLY
DTEND:20061017T163000Z</base>
A focus need not care if a user using a passcode to join is calling <mixing-start-offset required-participant="moderator"
from a PSTN or an IP phone. For example: Using a SIP phone, a SIP > 2006-10-17T14:29:00Z</mixing-start-offset>
INVITE request arrives directly at the focus. The focus examines the <mixing-end-offset required-participant="participant"
identity and discovers that there are no rules allowing this identity > 2006-10-17T16:31:00Z</mixing-end-offset>
to join. The focus also determines that there are no rules <must-join-before-offset
explicitly prohibiting this identity from joining. The focus in this > 2006-10-17T15:30:00Z</must-join-before-offset>
case decides to challenge the identity for a passcode, if there is a </entry>
rule that allows users with a passcode knowledge to join. If no such </conference-time>
rule exists, the focus would not challenge for a passcode. <!--
CONFERENCE UNIQUE IDENTIFIERS
-->
<conf-uris state="full">
<SIP>
<uri>tel:+3585671234</uri>
<display-text>Conference Bridge</display-text>
<purpose>participation</purpose>
</SIP>
<SIP>
<uri>http://www.example.comlive.ram</uri>
<purpose>streaming</purpose>
</SIP>
</conf-uris>
<!--
SERVICE URIS
-->
<service-uris state="full">
<SIP>
<uri>http://www.example.com/formula1/</uri>
<purpose>web-page</purpose>
</SIP>
</service-uris>
<!--
MAXIMUM USER COUNT
-->
<maximum-user-count>
<entry role="administrator">2</entry>
<entry role="moderator">5</entry>
<entry role="participant">150</entry>
</maximum-user-count>
<!--
AVAILABLE MEDIA
-->
<available-media>
<entry label="10234">
<display-text>main audio</display-text>
<type>audio</type>
<status>sendrecv</status>
<mixing-mode>automatic</mixing-mode>
<mix-level>3</mix-level>
<codecs decision="automatic">
<codec name="PCMU" policy="allowed"/>
</codecs>
</entry>
<entry label="10235">
<display-text>main video</display-text>
<type>video</type>
<status>sendrecv</status>
<mixing-mode>automatic</mixing-mode>
<mix-level>4</mix-level>
<codecs decision="automatic">
<codec name="H.263" policy="allowed"/>
</codecs>
</entry>
</available-media>
</conference-description>
<!--
HOST INFO
-->
<host-info>
<display-text>Formula1</display-text>
<web-page>http://www.example.com/formula1/</web-page>
<uris state="full">
<SIP>
<uri>sip:alice@example.com</uri>
</SIP>
<SIP>
<uri>sip:carol@example.com</uri>
</SIP>
</uris>
</host-info>
<!--
CONFERENCE STATE
-->
<conference-state>
<allow-conference-state>true</allow-conference-state>
<user-count>3</user-count>
<active>true</active>
<locked>false</locked>
</conference-state>
<!--
FLOOR INFORMATION
-->
<floor-information>
<allow-floor-events>true</allow-floor-events>
<floor-request-handling>confirm</floor-request-handling>
<conference-floor-policy>
<floor moderator-controlled="true" label="10234">
<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>
<floor moderator-controlled="true" label="10235">
<media-types>video</media-types>
<algorithm>moderator-controlled</algorithm>
<max-floor-users>1</max-floor-users>
<moderator-uri>sip:carol@example.com</moderator-uri>
</floor>
</conference-floor-policy>
</floor-information>
<!--
USERS
-->
<users state="full">
<join-handling>allow</join-handling>
<!--
ALLOWED USERS LIST
-->
<allowed-users-list>
<target uri="sip:bob@example.com" method="dial-out"/>
<target uri="sip:alice@example.com" method="dial-out"/>
<target uri="sip:carol@example.com" method="dial-out"/>
<target uri="sip:john@example.com" method="refer"/>
</allowed-users-list>
<!--
PRIVILEGES CONTROL LIST
-->
<privileges-control-list>
<conference-rules>
<entry id="1">
<condition>
<identity>
<many domain="example.com"/>
</identity>
<validity>
<to>2006-10-17T16:30:00Z</to>
<from>2006-10-17T14:30:00Z</from>
</validity>
</condition>
<action>
<allow-invite-users-dynamically
>true</allow-invite-users-dynamically>
</action>
</entry>
<entry id="2">
<condition>
<identity>
<one id="bob@example.com"/>
</identity>
</condition>
<action>
<show-floor-holder>block</show-floor-holder>
</action>
</entry>
</conference-rules>
</privileges-control-list>
<!--
USER
-->
<user entity="bob534" state="partial">
<display-text>Bob Hoskins</display-text>
<associated-aors state="full">
<SIP>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</SIP>
</associated-aors>
<provide-anonymity>false</provide-anonymity>
<roles>
<entry>participant</entry>
</roles>
<languages>en</languages>
<sphere value="work"/>
<allow-refer-users-dynamically
>false</allow-refer-users-dynamically>
<allow-invite-users-dynamically
>false</allow-invite-users-dynamically>
<allow-remove-users-dynamically
>false</allow-remove-users-dynamically>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@example.com" state="full">
<display-text>Bob's Laptop</display-text>
<referred>
<when>2006-10-17T14:00:00Z</when>
<reason>expert required</reason>
<by>sip:alice@example.com</by>
</referred>
<status>connected</status>
<joining-method>dialed-out</joining-method>
<joining-info>
<when>2006-10-17T14:00:00Z</when>
<reason>invitation</reason>
<by>sip:alice@example.com</by>
</joining-info>
For PSTN users, the system can be set up for an IVR system to prompt <!--
the user for a passcode before forwarding the request to the focus. MEDIA
The focus does not need to care if there is an IVR system or not. It -->
can apply the same procedure as above. It checks if there are any <media id="1">
the rules allowing or denying the identity access. In this case, the <label>10235</label>
identity is the GW. If no rules exist for that identity but a <src-id>432424</src-id>
general passcode rule does, then the focus would challenge the GW/IVR </media>
for the passcode. <!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>hsjh8980vhsb78</call-id>
<from-tag>vav738dvbs</from-tag>
<to-tag>8954jgjg8432</to-tag>
</sip>
</call-info>
</endpoint>
</user>
A focus can challenge for the passcode using, for example, a HTTP <!--
Digest challenge. The username, passcode and realm need to be USER
assigned and distributed is a manner that is outside the scope of -->
this document. Mutliple passcodes can be assigned to multiple users.
3.7.2.1.11. <administrators-passcode> <user entity="alice334" state="full">
<display-text>Alice Kay</display-text>
<associated-aors state="full">
<SIP>
<uri>mailto:alice@example.com</uri>
<display-text>email</display-text>
</SIP>
</associated-aors>
<provide-anonymity>false</provide-anonymity>
<roles>
<entry>moderator</entry>
</roles>
<languages>en</languages>
<sphere value="work"/>
<allow-refer-users-dynamically
>true</allow-refer-users-dynamically>
<allow-invite-users-dynamically
>true</allow-invite-users-dynamically>
<allow-remove-users-dynamically
>true</allow-remove-users-dynamically>
<!--
ENDPOINTS
-->
<endpoint entity="sip:alice@example.com" state="full">
<display-text>Alice's Desktop</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2006-10-17T13:35:08Z</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>truy45469123478</call-id>
<from-tag>asd456cbgt</from-tag>
<to-tag>3456jgjg1234</to-tag>
</sip>
</call-info>
</endpoint>
</user>
In some cases, administrators of the conference are assigned a <!--
different passcode than normal participants. The <administrator- -->
passcode> element can be used to match those key participants that <user entity="carol233" state="full">
have knowledge on a key participant passcode for the conference. <display-text>Carol More</display-text>
<associated-aors state="full">
<SIP>
<uri>mailto:carol@example.com</uri>
<display-text>email</display-text>
</SIP>
</associated-aors>
<provide-anonymity>false</provide-anonymity>
<roles>
<entry>administrator</entry>
</roles>
<languages>en</languages>
<sphere value="work"/>
<allow-refer-users-dynamically
>true</allow-refer-users-dynamically>
<allow-invite-users-dynamically
>true</allow-invite-users-dynamically>
<allow-remove-users-dynamically
>true</allow-remove-users-dynamically>
<!--
ENDPOINTS
-->
<endpoint entity="sip:carol@example.com" state="full">
<display-text>Carol's Computer</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2006-10-17T13:30:05Z</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>wevb12562321894</call-id>
<from-tag>asw456wedf</from-tag>
<to-tag>2365dfrt3497</to-tag>
</sip>
</call-info>
</endpoint>
</user>
</users>
<!--
SIDEBARS BY REFERENCE
-->
<sidebars-by-ref state="full">
<entry>
<uri>sips:conference123;grid=40</uri>
<display-text>private with Bob</display-text>
</entry>
</sidebars-by-ref>
<!--
SIDEBARS BY VALUE
-->
<sidebars-by-val>
<entry entity="conference123;grid=40">
<users>
<user entity="bob534"/>
<user entity="carol233"/>
</users>
</entry>
</sidebars-by-val>
</conference-info>
Again, a focus need not care if a user using a passcode to join is Note that due to RFC formatting conventions, this documents splits
calling from a PSTN or an IP phone. It is important that the focus lines whose content would exceed 72 characters. Two backslash
has a unique identity for each user joining from a PSTN phone via a characters mark where line folding has taken place. These
gateway. It is not enough that one identity to be assigned to all backslashes would not appear in the actual XML data model.
users joining from the same gateway since administrators have more
control over conference duration. It might be required that a
gateway maps the telephone number of the PSTN phone into the IP
signalling protocol header that usually carries the asserted identity
or a user.
3.7.2.2. <actions> 8. Security Considerations
The <actions> element in the applied rule is a positive grant of A malicious user can manipulate parts of the Conference Information
permission to the conference data model or the conferencing system. Data Model privileges document giving themselves and others
The <actions> element has the following operations: privileges to manipulate the data model. It is very important that
o The <allow-refer-users-dynamically> element represents a boolean only authorized clients are able to manipulate the Conference
action. If set to TRUE, the identity is allowed to instruct the Information Data Model document. Any conference control protocol
focus to refer a user to the conference without modifying the MUST provide authentication, confidentiality and integrity.
allowed-users-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.
o 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
allowed-users-list list (in SIP terms, the identity is allowed to
send a REFER request to the focus which results in the focus
sending an INVITE 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.
o The <allow-remove-users-dynamically> element represents a boolean
action. If set to TRUE, the identity is allowed to instruct the
focus to remove a user from the conference without modifying the
ruleset (in SIP terms, the identity is allowed to send a REFER
request to the focus which results in the focus sending an BYE
request to the user the referrer wishes to leave 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.
o The <show-floor-holder> element defines the actions used by the
conference focus to control floor requests. This element defines
the action that the focus is to take when processing a particular
request to a floor within a conference. This element has defined
values of:
* block: This action instructs the focus to deny the floor 9. IANA Considerations
request. This action is the default action taken in the
absence of any other actions.
* confirm: This action instructs the focus to allow the request.
The focus then uses the defined floor algorithm to further
allow of deny the floor. The algorithms used are outside the
scope of this document.
o Note that placing a value of block for this element does not
guarantee that a participant is blocked from joining the
conference. Any other rule that might resolve to true for this
participant that carried an action whose value was higher than
block would automatically grant confirm/allow permission to that
participant.
o 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.
o A rule can be set that provides anonymity to a specific identity.
In this case, the focus provides to the rest of the participants
an anonymous identity for that user, for example anonymous1. This
can be achieved by using the <provide-anonymity> element. It is a
boolean transformation. If set to TRUE, the conference
participants will see an anonymous identity for the user whose
identity is present in the conditions.
o The <read-write> element represents a boolean action. If set to
TRUE, the identity is allowed to modify the element described
inside the 'element' attribute in the conference policy. If set
to FALSE, any modifications to the element are rejected.
o The <read-only> element represents a boolean action. If set to
TRUE, the identity is allowed to read the element described inside
the 'element' attribute in the conference policy. If set to
FALSE, any attempts to read the element are rejected.
3.8. <user> 9.1. Conference Relax NG Schema Registration
The element <user> describes a single participant in the conference. URI: urn:ietf:params:xml:ns:conference-schema
The following elements as well as the attributes of <user> are Relax NG Schema: The Relax NG schema to be registered is contained
defined in [2], section 5.6: <display-text>, <associated-aors>, in Section 4. Its first line is
<roles>, <languages>, <cascaded-focus>, and <endpoint>.
The <provide-anonymity> provides anonymity to the user. When a user namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
is defined then the role must be defined or set to "participant" by
default. This specification does not define the set of possible
conferencing roles nor the semantics associated with each.
The <sphere> element can be used to indicate the state (e.g., 'work', and its last line is
'home', 'meeting', 'travel') the user is currently in. It is defined
in section 7.2 of [8].
The <allow-refer-users-dynamically>, <allow-invite-users-dynamically> }
and <allow-remove-users-dynamically> elements are defined in the
previous section.
The <endpoint> element is under a <user> parent. This element can 9.2. Conference Namespace Registration
provide the desired level of detail about the user's devices and
signaling sessions taking part in the conference and has the
following child elements defined in [2]: <display-text>, <referred>,
<status>, <joining-method>, <joining-info>, <disconnection-method>,
<disconnection-info>, <media>, and <call-info>. The <endpoint>
element has as well two other child elements: <to-mixer>, and <from-
mixer> child element described in the following section.
3.8.1. from-mixer, to-mixer URI: urn:ietf:params:xml:ns:conference-schema
Similarly that the controls defined in the <available-media> element, 10. Acknowledgements
controls that apply to a particular user appear at this place in the
document. The <to-mixer> element details properties associated with
the incoming streams to the mixer. <from-mixer> element details
properties associated with the outgoing streams from the mixer. Both
of these elements have the attribute 'name'. 'Name' attribute has
the values "VideoIn", "VideoOut", "AudioOut", and "AudioIn". The
"VideoOut" and "AudioOut" media streams detail properties associated
with the outgoing video and audio from the mixer. The "VideoIn" and
"AudioIn" media stream details properties associated with the
incoming video and audio to the mixer. More values can be defined in
the future.
Every of these elements have the <floor> and <controls> child This document is really a distillation of many ideas discussed over a
elements. long period of time. These ideas were contributed by many different
drafts in the XCON working group and the SIPPING working group. We
would like to thank Orit Levin, Adam Roach, Mary Barnes, Chris
Boulton, Umesh Chandra, and Jari Urpilainen for their comments.
Also, We would like to thank Hisham Khartabil, Petri Koskelainen, and
Aki Niemi for letting us use the policy information of their cpcp
drafts in this document.
3.8.1.1. <floor> 11. References
The <floors> element describes a floor that joins this participant in 11.1. Normative References
the conference. If a participant, for instance, needs to talk in the
conference, it first needs to get a floor from the moderator of the
conference.
The <floor> element has a 'Boolen' value. A value of 'false' [1] Barnes, M., "A Framework and Data Model for Centralized
indicates that this user does not hold the floor in this moment. If Conferencing", draft-ietf-xcon-framework-07 (work in progress),
this control is not specify, this user SHOULD not specify the floor January 2007.
option.
3.9. <sidebars-by-ref> [2] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
The <sidebars-by-ref> element contains a set of <entry> child [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
elements. Each <entry> child element contains a <user> child element Levels", BCP 14, RFC 2119, March 1997.
with a sidebar conference unique identifier and a <display-text>
child element. The <sidebars-by-ref> element is described in Section
5.9.1 of [2].
Notice that the <sidebars-by-ref> child element does not include the [4] Rosenberg, J., "A Framework for Conferencing with the Session
attribute 'state' defined in [2]. Initiation Protocol (SIP)", RFC 4353, February 2006.
3.10. <sidebars-by-val> [5] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium FirstEdition REC-xml-20001006, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
The <sidebars-by-val> element contains a set of <entry> child [6] Dawson, F. and Stenerson, D., "Internet Calendaring and
elements each containing information about a single sidebar. Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
Notice as well that the <sidebars-by-val> and the <entry> child 11.2. Informative References
element do not include the attribute 'state' defined in [2].
4. RELAX NG schema [7] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
Protocol (BFCP)", RFC 4582, November 2006.
In accordance with the XCON framework document [1], the Conference [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Object is a logical representation of a conference instance. The Notification", RFC 3265, June 2002.
common conference information schema contains core information that
is utilized in any conference. It also contains the variable
information part of the Conference Object.
This specification defines some document fragments in RELAX NG Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML Syntax
format.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0" <grammar ns="urn:ietf:params:xml:ns:conference-schema"
xmlns:xs="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start> <start>
<element name="conference-info">
<ref name="conference-type"/> <ref name="conference-type"/>
</element>
</start> </start>
<!-- <!--
CONFERENCE TYPE CONFERENCE TYPE
--> -->
<define name="conference-type"> <define name="conference-type">
<element name="conference-info"> <attribute name="entity">
<text/>
</attribute>
<optional>
<attribute name="version">
<data type="unsignedInt"/>
</attribute>
</optional>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<ref name="role-type"/> <ref name="role-type"/>
<zeroOrMore>
<ref name="conference-description-type"/> <ref name="conference-description-type"/>
<optional>
<element name="host-info"> <element name="host-info">
<ref name="host-type"/> <ref name="host-type"/>
</element> </element>
</optional>
<optional>
<element name="conference-state"> <element name="conference-state">
<ref name="conference-state-type"/> <ref name="conference-state-type"/>
</element> </element>
</optional>
<optional>
<element name="floor-information"> <element name="floor-information">
<ref name="floor-information-type"/> <ref name="floor-information-type"/>
</element> </element>
</optional>
<element name="users"> <element name="users">
<ref name="user-type"/> <ref name="users-type"/>
</element> </element>
<optional>
<element name="sidebars-by-ref"> <element name="sidebars-by-ref">
<ref name="sidebars-by-ref-type"/> <ref name="sidebars-by-ref-type"/>
</element> </element>
</optional>
<optional>
<element name="sidebars-by-val"> <element name="sidebars-by-val">
<ref name="sidebars-by-val-type"/> <ref name="sidebars-by-val-type"/>
</element> </element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</element>
</define> </define>
<!-- <!--
CONFERENCE DESCRIPTION TYPE CONFERENCE DESCRIPTION TYPE
--> -->
<define name="conference-description-type"> <define name="conference-description-type">
<element name="conference-description"> <element name="conference-description">
<ref name="role-type"/> <ref name="role-type"/>
<optional> <optional>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</optional>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="subject"> <element name="subject">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="free-text"> <element name="free-text">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="keywords"> <element name="keywords">
<list> <list>
<zeroOrMore>
<data type="string"/> <data type="string"/>
</zeroOrMore>
</list> </list>
</element> </element>
<element name="webpage"> </optional>
<data type="anyURI"/> <optional>
</element>
<element name="security-level">
<ref name="SecurityLevel"/>
</element>
<element name="allow-sidebars"> <element name="allow-sidebars">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
<element name="conference-stage"> </optional>
<ref name="conference-stage-type"/> <optional>
</element>
<element name="conference-time"> <element name="conference-time">
<ref name="conferencetime-type"/> <ref name="conferencetime-type"/>
</element> </element>
</optional>
<optional>
<element name="conf-uris"> <element name="conf-uris">
<ref name="uris-type"/> <ref name="uris-type"/>
</element> </element>
</optional>
<optional>
<element name="service-uris"> <element name="service-uris">
<ref name="uris-type"/> <ref name="uris-type"/>
</element> </element>
</optional>
<optional>
<element name="maximum-user-count"> <element name="maximum-user-count">
<ref name="maximum-user-count-type"/> <data type="int"/>
</element>
<element name="maximum-streams">
<ref name="maximum-streams-type"/>
</element> </element>
</optional>
<optional>
<element name="available-media"> <element name="available-media">
<ref name="conference-media-type"/> <ref name="conference-media-type"/>
</element> </element>
</optional> </optional>
<xs:any/> <zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</element> </element>
</define> </define>
<!--
SECURITY LEVEL
-->
<define name="SecurityLevel">
<choice>
<value type="string">none</value>
<value type="string">low</value>
<value type="string">medium</value>
<value type="string">high</value>
</choice>
</define>
<!--
CONFERENCE STAGE
-->
<define name="conference-stage-type">
<choice>
<value type="string">reserved</value>
<value type="string">started</value>
<value type="string">running</value>
<value type="string">ended</value>
</choice>
</define>
<!-- <!--
CONFERENCE TIME CONFERENCE TIME
--> -->
<define name="conferencetime-type"> <define name="conferencetime-type">
<ref name="role-type"/> <ref name="role-type"/>
<zeroOrMore> <zeroOrMore>
<element name="entry"> <element name="entry">
<optional> <optional>
<element name="base"> <element name="base">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="mixing-start-offset"> <element name="mixing-start-offset">
<data type="int"/> <data type="dateTime">
<param name="pattern">.+T.+Z.*</param>
</data>
<attribute name="required-participant">
<ref name="single-role-type"/>
</attribute>
<ref name="anyAttribute"/>
</element> </element>
<element name="mixing-stop-offset"> </optional>
<data type="int"/> <optional>
<element name="mixing-end-offset">
<data type="dateTime">
<param name="pattern">.+T.+Z.*</param>
</data>
<attribute name="required-participant">
<ref name="single-role-type"/>
</attribute>
<ref name="anyAttribute"/>
</element> </element>
</optional>
<optional>
<element name="can-join-after-offset"> <element name="can-join-after-offset">
<data type="int"/> <data type="dateTime">
<param name="pattern">.+T.+Z.*</param>
</data>
</element> </element>
</optional>
<optional>
<element name="must-join-before-offset"> <element name="must-join-before-offset">
<data type="int"/> <data type="dateTime">
</element> <param name="pattern">.+T.+Z.*</param>
<element name="request-users"> </data>
<data type="int"/>
</element> </element>
</optional>
<optional>
<element name="notify-end-of-conference"> <element name="notify-end-of-conference">
<data type="int"/> <data type="int"/>
</element> </element>
</optional>
<optional>
<element name="allowed-extend-mixing-end-offset"> <element name="allowed-extend-mixing-end-offset">
<data type="boolean"/> <ref name="allowed-extend-mixing-values"/>
</element> </element>
</optional> </optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
ALLOWED EXTEND MIXING VALUES
-->
<define name="allowed-extend-mixing-values">
<choice>
<value type="string">allowed</value>
<value type="string">denied</value>
</choice>
</define> </define>
<!-- <!--
URIS TYPE URIS TYPE
--> -->
<define name="uris-type"> <define name="uris-type">
<ref name="role-type"/> <ref name="role-type"/>
<oneOrMore> <optional>
<element name="SIP"> <attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<interleave>
<zeroOrMore>
<element name="entry">
<ref name="uri-type"/> <ref name="uri-type"/>
</element> </element>
</zeroOrMore>
<zeroOrMore>
<element name="H323"> <element name="H323">
<ref name="H323-type"/> <ref name="H323-type"/>
</element> </element>
</zeroOrMore>
<zeroOrMore>
<element name="PSTN-ISDN"> <element name="PSTN-ISDN">
<ref name="PSTN-type"/> <ref name="PSTN-type"/>
</element> </element>
<element name="BFCP"> </zeroOrMore>
<ref name="BFCP-type"/> </interleave>
</element> <zeroOrMore>
</oneOrMore> <ref name="anyElement"/>
</zeroOrMore>
</define> </define>
<!-- <!--
SIP TYPE SIP TYPE
--> -->
<define name="uri-type"> <define name="uri-type">
<ref name="role-type"/> <ref name="role-type"/>
<oneOrMore> <zeroOrMore>
<element name="uri"> <element name="uri">
<data type="anyURI"/> <data type="anyURI"/>
</element> </element>
<zeroOrMore> <optional>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="purpose"> <element name="purpose">
<text/> <text/>
</element> </element>
<element name="PIN-code"> </optional>
<data type="int"/> <zeroOrMore>
</element> <ref name="anyElement"/>
</zeroOrMore>
</zeroOrMore> </zeroOrMore>
</oneOrMore>
</define> </define>
<!-- <!--
H323 TYPE H323 TYPE
--> -->
<define name="H323-type"> <define name="H323-type">
<ref name="role-type"/> <ref name="role-type"/>
<zeroOrMore> <optional>
<element name="H.323-alias"> <element name="H.323-alias">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="H.323-URI"> <element name="H.323-URI">
<data type="anyURI"/> <data type="anyURI"/>
</element> </element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
PSTN TYPE PSTN TYPE
--> -->
<define name="PSTN-type"> <define name="PSTN-type">
<ref name="role-type"/> <ref name="role-type"/>
<attribute name="PIN-code"> <attribute name="PIN-code">
<text/> <data type="unsignedInt"/>
</attribute> </attribute>
<attribute name="purpose"> <attribute name="purpose">
<text/> <data type="unsignedInt"/>
</attribute> </attribute>
<zeroOrMore> <oneOrMore>
<element name="phone-number"> <element name="phone-number">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> </element>
<element name="rate"> <zeroOrMore>
<data type="unsignedInt"/> <ref name="anyElement"/>
</element>
</zeroOrMore> </zeroOrMore>
</oneOrMore>
</define> </define>
<!-- <!--
BFCP TYPE BFCP TYPE
--> -->
<define name="BFCP-type"> <define name="BFCP-type">
<ref name="role-type"/> <ref name="role-type"/>
<zeroOrMore> <zeroOrMore>
<element name="conference-id"> <element name="conference-ID">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> </element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
MAXIMUM USER TYPE MAXIMUM USER TYPE
--> -->
<define name="maximum-user-count-type"> <define name="maximum-user-count-type">
<ref name="role-type"/> <ref name="role-type"/>
<xs:attribute name="role"> <ref name="anyAttribute"/>
<ref name="single-role-type"/> <oneOrMore>
</xs:attribute>
<zeroOrMore>
<element name="entry"> <element name="entry">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> <attribute name="role">
</zeroOrMore> <ref name="single-role-type"/>
</define>
<!--
MAXIMUM STREAM TYPE
-->
<define name="maximum-streams-type">
<ref name="role-type"/>
<zeroOrMore>
<element name="entry">
<ref name="role-type"/>
<attribute name="type">
<ref name="media-stream-type"/>
</attribute>
<attribute name="min">
<data type="positiveInteger"/>
</attribute>
<attribute name="max">
<data type="positiveInteger"/>
</attribute> </attribute>
</element> </element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</oneOrMore>
</define> </define>
<!--
MEDIA TYPES
-->
<define name="media-stream-type">
<choice>
<value type="string">audio</value>
<value type="string">video</value>
</choice>
</define>
<!-- <!--
CONFERENCE MEDIA TYPE CONFERENCE MEDIA TYPE
--> -->
<define name="conference-media-type"> <define name="conference-media-type">
<ref name="role-type"/> <ref name="role-type"/>
<attribute name="label"> <optional>
<text/> <attribute name="state">
<ref name="state-type"/>
</attribute> </attribute>
</optional>
<zeroOrMore> <zeroOrMore>
<element name="entry"> <element name="entry">
<ref name="conference-medium-type"/> <ref name="conference-medium-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define> </define>
<!-- <!--
CONFERENCE MEDIUM TYPE CONFERENCE MEDIUM TYPE
--> -->
<define name="conference-medium-type"> <define name="conference-medium-type">
<ref name="role-type"/> <ref name="role-type"/>
<attribute name="label"> <attribute name="label">
<text/> <text/>
</attribute> </attribute>
<zeroOrMore> <optional>
<element name="type"> <element name="display-text">
<text/> <text/>
</element> </element>
<element name="display-text"> </optional>
<optional>
<element name="type">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="status"> <element name="status">
<ref name="media-status-type"/> <ref name="media-status-type"/>
</element> </element>
</optional>
<optional>
<element name="mixing-mode"> <element name="mixing-mode">
<ref name="mix-mode-type"/> <ref name="mix-mode-type"/>
</element> </element>
</optional>
<optional>
<element name="mix-level"> <element name="mix-level">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> </element>
</optional>
<optional>
<element name="codecs"> <element name="codecs">
<ref name="codecs-type"/> <ref name="codecs-type"/>
</element> </element>
</optional>
<optional>
<element name="controls"> <element name="controls">
<ref name="controls-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
CONTROLS TYPE
-->
<define name="controls-type">
<ref name="role-type"/>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<zeroOrMore>
<element name="control">
<ref name="control-type"/> <ref name="control-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define> </define>
<!-- <!--
MIX MODE TYPE MIX MODE TYPE
--> -->
<define name="mix-mode-type"> <define name="mix-mode-type">
<choice> <choice>
<value type="string">Moderator-controlled</value> <value type="string">moderator-controlled</value>
<value type="string">FCFS</value> <value type="string">FCFS</value>
<value type="string">"Automatic</value> <value type="string">automatic</value>
</choice> </choice>
</define> </define>
<!-- <!--
CODECS TYPE CODECS TYPE
--> -->
<define name="codecs-type"> <define name="codecs-type">
<ref name="role-type"/> <ref name="role-type"/>
<attribute name="decision"> <attribute name="decision">
<ref name="decision-type"/> <ref name="decision-type"/>
</attribute> </attribute>
<zeroOrMore> <zeroOrMore>
<element name="entry"> <element name="codec">
<ref name="codec-type"/> <ref name="codec-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define> </define>
<!-- <!--
CODEC TYPE CODEC TYPE
--> -->
<define name="codec-type"> <define name="codec-type">
<ref name="role-type"/> <ref name="role-type"/>
<attribute name="name"> <attribute name="name">
<text/> <text/>
</attribute> </attribute>
<attribute name="policy"> <attribute name="policy">
<ref name="policy-type"/> <ref name="policy-type"/>
skipping to change at page 32, line 31 skipping to change at page 53, line 40
--> -->
<define name="codec-type"> <define name="codec-type">
<ref name="role-type"/> <ref name="role-type"/>
<attribute name="name"> <attribute name="name">
<text/> <text/>
</attribute> </attribute>
<attribute name="policy"> <attribute name="policy">
<ref name="policy-type"/> <ref name="policy-type"/>
</attribute> </attribute>
</define> </define>
<!-- <!--
DECISION TYPE DECISION TYPE
--> -->
<define name="decision-type"> <define name="decision-type">
<choice> <choice>
<value type="string">Automatic</value> <value type="string">automatic</value>
<value type="string">Moderator-controlled</value> <value type="string">moderator-controlled</value>
</choice> </choice>
</define> </define>
<!-- <!--
POLICY TYPE POLICY TYPE
--> -->
<define name="policy-type"> <define name="policy-type">
<choice> <choice>
<value type="string">Allowed</value> <value type="string">allowed</value>
<value type="string">Disallowed</value> <value type="string">disallowed</value>
</choice> </choice>
</define> </define>
<!-- <!--
CONTROL TYPE CONTROL TYPE
--> -->
<define name="control-type"> <define name="control-type">
<choice> <choice>
<value type="string">integer</value> <element name="mute">
<value type="string">real</value> <data type="boolean"/>
<value type="string">boolean</value> </element>
<element name="pause-video">
<data type="boolean"/>
</element>
<element name="gain">
<data type="int">
<param name="minInclusive">-127</param>
<param name="maxInclusive">127</param>
</data>
</element>
<element name="video-layout">
<choice>
<value type="string">single-view</value>
<value type="string">dual-view</value>
<value type="string">dual-view-crop</value>
<value type="string">dual-view-2x1</value>
<value type="string">dual-view-2x1-crop</value>
<value type="string">quad-view</value>
<value type="string">multiple-3x3</value>
<value type="string">multiple-4x4</value>
<value type="string">multiple-5x1</value>
<value type="string">automatic</value>
</choice>
</element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</choice> </choice>
</define> </define>
<!-- <!--
HOST TYPE HOST TYPE
--> -->
<define name="host-type"> <define name="host-type">
<ref name="role-type"/> <ref name="role-type"/>
<zeroOrMore> <zeroOrMore>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
<element name="web-page"> <element name="web-page">
skipping to change at page 33, line 30 skipping to change at page 55, line 13
<zeroOrMore> <zeroOrMore>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
<element name="web-page"> <element name="web-page">
<data type="anyURI"/> <data type="anyURI"/>
</element> </element>
<element name="uris"> <element name="uris">
<ref name="uris-type"/> <ref name="uris-type"/>
</element> </element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
CONFERENCE STATE TYPE CONFERENCE STATE TYPE
--> -->
<define name="conference-state-type"> <define name="conference-state-type">
<ref name="role-type"/> <ref name="role-type"/>
<zeroOrMore> <optional>
<element name="allow-conference-state"> <element name="allow-conference-event-subscription">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
</optional>
<optional>
<element name="user-count"> <element name="user-count">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> </element>
</optional>
<optional>
<element name="active"> <element name="active">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
</optional>
<optional>
<element name="locked"> <element name="locked">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
FLOOR INFORMATION TYPE FLOOR INFORMATION TYPE
--> -->
<define name="floor-information-type"> <define name="floor-information-type">
<ref name="role-type"/> <ref name="role-type"/>
<zeroOrMore> <zeroOrMore>
<element name="conference-ID">
<ref name="BFCP-type"/>
</element>
<element name="allow-floor-events"> <element name="allow-floor-events">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
<element name="floor-request-handling"> <element name="floor-request-handling">
<ref name="floor-request-type"/> <ref name="floor-request-type"/>
</element> </element>
<element name="conference-floor-policy"> <element name="conference-floor-policy">
<ref name="Conference-floor-policy"/> <ref name="Conference-floor-policy"/>
</element> </element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
FLOOR REQUEST TYPE FLOOR REQUEST TYPE
--> -->
<define name="floor-request-type"> <define name="floor-request-type">
<choice> <choice>
<value type="string">block</value> <value type="string">block</value>
<value type="string">confirm</value> <value type="string">confirm</value>
</choice> </choice>
</define> </define>
<!-- <!--
CONFERENCE FLOOR POLICY CONFERENCE FLOOR POLICY
--> -->
<define name="Conference-floor-policy"> <define name="Conference-floor-policy">
<ref name="role-type"/> <ref name="role-type"/>
<oneOrMore>
<element name="floor">
<attribute name="moderator-controlled"> <attribute name="moderator-controlled">
<data type="boolean"/> <data type="boolean"/>
</attribute> </attribute>
<attribute name="label"> <attribute name="label">
<text/> <text/>
</attribute> </attribute>
<oneOrMore> <ref name="anyAttribute"/>
<element name="Floor">
<zeroOrMore> <zeroOrMore>
<element name="Media-types"> <element name="media-types">
<ref name="role-type"/> <ref name="role-type"/>
<zeroOrMore> <choice>
<element name="Video"> <value type="string">video</value>
<empty/> <value type="string">audio</value>
</element> <value type="string">application</value>
<element name="Audio"> <value type="string">data</value>
<empty/> <value type="string">control</value>
</element> <value type="string">message</value>
<element name="Application"> <value type="string">text</value>
<empty/> </choice>
</element>
<element name="Data">
<empty/>
</element>
<element name="Control">
<empty/>
</element>
<element name="Message">
<empty/>
</element>
<element name="Text">
<empty/>
</element>
</zeroOrMore>
</element> </element>
<element name="Algorithm"> <element name="algorithm">
<ref name="role-type"/> <ref name="role-type"/>
<zeroOrMore> <choice>
<element name="Moderator-controlled"> <value type="string">moderator-controlled</value>
<empty/> <value type="string">FCFS</value>
</element> <value type="string">random</value>
<element name="FCFS"> </choice>
<empty/>
</element>
<element name="Random">
<empty/>
</element>
</zeroOrMore>
</element> </element>
<element name="Max-floor-users"> <element name="max-floor-users">
<data type="nonNegativeInteger"/> <data type="nonNegativeInteger"/>
</element> </element>
<element name="Moderator-URI"> <element name="chair-id">
<data type="anyURI"/> <data type="anyURI"/>
</element> </element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</zeroOrMore> </zeroOrMore>
</element> </element>
</oneOrMore> </oneOrMore>
</define> </define>
<!-- <!--
USERS TYPE USERS TYPE
--> -->
<define name="users-type"> <define name="users-type">
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<ref name="role-type"/> <ref name="role-type"/>
<zeroOrMore> <optional>
<element name="join-handling"> <element name="join-handling">
<ref name="join-handling-type"/> <ref name="join-handling-type"/>
</element> </element>
</optional>
<optional>
<element name="user-admission-policy"> <element name="user-admission-policy">
<ref name="user-admission-policy-type"/> <ref name="user-admission-policy-type"/>
</element> </element>
</optional>
<optional>
<element name="user-must-be-specified"> <element name="user-must-be-specified">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
</optional>
<optional>
<element name="allowed-users-list"> <element name="allowed-users-list">
<ref name="UserList"/> <ref name="UserList"/>
</element> </element>
<element name="privileges-control-list"> </optional>
<ref name="privileges-control-list-type"/> <zeroOrMore>
</element>
<element name="user"> <element name="user">
<ref name="user-type"/> <ref name="user-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define> </define>
<!-- <!--
USERS ADMISSION POLICY USERS ADMISSION POLICY
--> -->
<define name="user-admission-policy-type"> <define name="user-admission-policy-type">
<choice> <choice>
<value type="string">closedAuthenticated</value> <value type="string">closedAuthenticated</value>
<value type="string">openAuthenticated</value> <value type="string">openAuthenticated</value>
<value type="string">anonymous</value> <value type="string">anonymous</value>
</choice> </choice>
skipping to change at page 37, line 6 skipping to change at page 58, line 44
--> -->
<define name="join-handling-type"> <define name="join-handling-type">
<choice> <choice>
<value type="string">block</value> <value type="string">block</value>
<value type="string">allow</value> <value type="string">allow</value>
<value type="string">confirm</value> <value type="string">confirm</value>
<value type="string">IVR</value> <value type="string">IVR</value>
<value type="string">directed-operator</value> <value type="string">directed-operator</value>
</choice> </choice>
</define> </define>
<!-- <!--
USERLIST USERLIST
--> -->
<define name="UserList"> <define name="UserList">
<ref name="role-type"/> <ref name="role-type"/>
<zeroOrMore> <zeroOrMore>
<element name="target"> <element name="target">
<ref name="Target"/> <ref name="target-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define> </define>
<!-- <!--
TARGET TARGET TYPE
--> -->
<define name="Target"> <define name="target-type">
<ref name="role-type"/> <ref name="role-type"/>
<attribute name="uri"> <attribute name="uri">
<data type="anyURI"/> <data type="anyURI"/>
</attribute> </attribute>
<attribute name="method"> <attribute name="method">
<ref name="method-type"/> <ref name="method-type"/>
</attribute> </attribute>
</define> </define>
<!-- <!--
METHOD TYPE METHOD TYPE
--> -->
<define name="method-type"> <define name="method-type">
<choice> <choice>
<value type="string">dial-in</value> <value type="string">dial-in</value>
<value type="string">dial-out</value> <value type="string">dial-out</value>
<value type="string">refer</value> <value type="string">refer</value>
</choice> </choice>
</define> </define>
<!-- <!--
PRIVILEGES CONTROL LIST TYPE
-->
<define name="privileges-control-list-type">
<ref name="role-type"/>
<oneOrMore>
<element name="conference-rules">
<ref name="conference-rules-type"/>
</element>
</oneOrMore>
</define>
<!--
CONFERENCE RULES TYPE
-->
<define name="conference-rules-type">
<ref name="role-type"/>
<attribute name="id">
<text/>
</attribute>
<zeroOrMore>
<element name="entry">
<ref name="conference-rule-type"/>
</element>
</zeroOrMore>
</define>
<!--
CONFERENCE RULE TYPE
-->
<define name="conference-rule-type">
<ref name="role-type"/>
<zeroOrMore>
<element name="condition">
<ref name="condition-type"/>
</element>
<element name="action">
<ref name="action-type"/>
</element>
</zeroOrMore>
</define>
<!--
CONDITION TYPE
-->
<define name="condition-type">
<ref name="role-type"/>
<element name="identity">
<ref name="identity-type"/>
</element>
<element name="validity">
<ref name="validityType"/>
</element>
</define>
<!--
IDENTITY TYPE
-->
<define name="identity-type">
<ref name="role-type"/>
<element name="identity">
<ref name="identityType"/>
</element>
<element name="validity">
<ref name="validityType"/>
</element>
</define>
<!--
ROLES IDENTITY TYPE
-->
<define name="identityType">
<choice>
<element name="one">
<ref name="oneType"/>
</element>
<element name="many">
<ref name="manyType"/>
</element>
<element name="pseudonymous">
<text/>
</element>
<element name="has-been-referred">
<text/>
</element>
<element name="has-been-invited">
<text/>
</element>
<element name="has-been-in-conference">
<text/>
</element>
<element name="is-in-conference">
<text/>
</element>
<element name="administrator">
<text/>
</element>
<element name="is-on-allowed-users-list-dial-out">
<text/>
</element>
<element name="is-on-allowed-users-list-refer">
<text/>
</element>
<element name="participant-passcode">
<text/>
</element>
<element name="administrator-passcode">
<text/>
</element>
</choice>
</define>
<!--
ACTION TYPE
-->
<define name="action-type">
<choice>
<element name="allow-refer-users-dynamically">
<data type="boolean"/>
</element>
<element name="allow-invite-users-dynamically">
<data type="boolean"/>
</element>
<element name="allow-remove-users-dynamically">
<data type="boolean"/>
</element>
<element name="show-floor-holder">
<ref name="floor-request-type"/>
</element>
<element name="show-floor-request">
<data type="boolean"/>
</element>
<element name="provide-anonymity">
<data type="boolean"/>
</element>
<element name="read-only">
<ref name="single-role-type"/>
</element>
<element name="read-write">
<ref name="single-role-type"/>
</element>
</choice>
</define>
<!--
USER TYPE USER TYPE
--> -->
<define name="user-type"> <define name="user-type">
<ref name="role-type"/> <ref name="role-type"/>
<attribute name="state">
<ref name="state-type"/>
</attribute>
<zeroOrMore>
<element name="user">
<ref name="one-user-type"/>
</element>
</zeroOrMore>
</define>
<!--
ONE USER TYPE
-->
<define name="one-user-type">
<ref name="role-type"/>
<attribute name="entity"> <attribute name="entity">
<data type="anyURI"/> <data type="anyURI"/>
</attribute> </attribute>
<optional>
<attribute name="state"> <attribute name="state">
<ref name="state-type"/> <ref name="state-type"/>
</attribute> </attribute>
<zeroOrMore> </optional>
<optional>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="associated-aors"> <element name="associated-aors">
<ref name="uris-type"/> <ref name="uris-type"/>
</element> </element>
</optional>
<optional>
<element name="provide-anonymity"> <element name="provide-anonymity">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
</optional>
<optional>
<element name="roles"> <element name="roles">
<ref name="single-role-type"/> <ref name="roles-type"/>
</element> </element>
</optional>
<optional>
<element name="languages"> <element name="languages">
<list> <list>
<data type="language"/> <data type="language"/>
</list> </list>
</element> </element>
</optional>
<optional>
<element name="cascaded-focus"> <element name="cascaded-focus">
<data type="anyURI"/> <data type="anyURI"/>
</element> </element>
<element name="sphere"> </optional>
<ref name="sphereType"/> <optional>
</element>
<element name="allow-refer-users-dynamically"> <element name="allow-refer-users-dynamically">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
</optional>
<optional>
<element name="allow-invite-users-dynamically"> <element name="allow-invite-users-dynamically">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
</optional>
<optional>
<element name="allow-remove-users-dynamically"> <element name="allow-remove-users-dynamically">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
</optional>
<zeroOrMore>
<element name="endpoint"> <element name="endpoint">
<ref name="endpoint-type"/> <ref name="endpoint-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define> </define>
<!-- <!--
ENDPOINT TYPE ENDPOINT TYPE
--> -->
<define name="endpoint-type"> <define name="endpoint-type">
<ref name="role-type"/> <ref name="role-type"/>
<attribute name="entity"> <attribute name="entity">
<text/> <text/>
</attribute> </attribute>
<zeroOrMore> <optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="referred"> <element name="referred">
<ref name="execution-type"/> <zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element> </element>
</optional>
<optional>
<element name="status"> <element name="status">
<ref name="endpoint-status-type"/> <ref name="endpoint-status-type"/>
</element> </element>
</optional>
<optional>
<element name="joining-method"> <element name="joining-method">
<ref name="joining-type"/> <ref name="joining-type"/>
</element> </element>
</optional>
<optional>
<element name="joining-info"> <element name="joining-info">
<ref name="execution-type"/> <zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element> </element>
</optional>
<optional>
<element name="disconnection-method"> <element name="disconnection-method">
<ref name="disconnection-type"/> <ref name="disconnection-type"/>
</element> </element>
</optional>
<optional>
<element name="disconnection-info"> <element name="disconnection-info">
<ref name="execution-type"/> <zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element> </element>
</optional>
<zeroOrMore>
<element name="media"> <element name="media">
<ref name="media-type"/> <ref name="media-type"/>
</element> </element>
</zeroOrMore>
<optional>
<element name="call-info"> <element name="call-info">
<ref name="call-type"/> <zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element> </element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
MEDIA TYPE MEDIA TYPE
--> -->
<define name="media-type"> <define name="media-type">
<attribute name="id"> <attribute name="id">
<text/> <data type="int"/>
</attribute> </attribute>
<zeroOrMore> <optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<ref name="anyAttribute"/>
<optional>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="type"> <element name="type">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="label"> <element name="label">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="src-id"> <element name="src-id">
<text/> <text/>
</element> </element>
</optional>
<optional>
<element name="status"> <element name="status">
<ref name="media-status-type"/> <ref name="media-status-type"/>
</element> </element>
</optional>
<optional>
<element name="to-mixer"> <element name="to-mixer">
<ref name="mixer-type"/> <ref name="mixer-type"/>
</element> </element>
</optional>
<optional>
<element name="from-mixer"> <element name="from-mixer">
<ref name="mixer-type"/> <ref name="mixer-type"/>
</element> </element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
MIXER TYPE MIXER TYPE
--> -->
<define name="mixer-type"> <define name="mixer-type">
<ref name="role-type"/> <ref name="role-type"/>
<optional> <optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional>
<element name="floor"> <element name="floor">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
<element name="controls"> <element name="controls">
<ref name="control-type"/> <ref name="controls-type"/>
</element> </element>
</optional> </optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define> </define>
<!-- <!--
SIDEBARS-BY-REF TYPE SIDEBARS-BY-REF TYPE
--> -->
<define name="sidebars-by-ref-type"> <define name="sidebars-by-ref-type">
<ref name="role-type"/> <ref name="role-type"/>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<zeroOrMore> <zeroOrMore>
<element name="entry"> <element name="entry">
<ref name="uri-type"/> <ref name="uri-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define> </define>
<!-- <!--
SIDEBARS-BY-VAL TYPE SIDEBARS-BY-VAL TYPE
--> -->
<define name="sidebars-by-val-type"> <define name="sidebars-by-val-type">
<ref name="role-type"/> <ref name="role-type"/>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<zeroOrMore> <zeroOrMore>
<element name="entry"> <element name="entry">
<ref name="conference-type"/> <ref name="conference-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
</define>
<!--
********************************************************************************
TYPES DEFINED IN THE EVENT PACKAGES FOR CONFERENCE STATE
********************************************************************************
-->
<!--
MEDIA STATUS TYPE
-->
<define name="media-status-type">
<choice>
<value type="string">recvonly</value>
<value type="string">sendonly</value>
<value type="string">sendrecv</value>
<value type="string">inactive</value>
</choice>
</define>
<!--
EXECUTION TYPE
-->
<define name="execution-type">
<zeroOrMore> <zeroOrMore>
<element name="when"> <ref name="anyElement"/>
<data type="int"/>
</element>
<element name="reason">
<data type="string"/>
</element>
<element name="by">
<data type="anyURI"/>
</element>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
CALL TYPE ROLES_TYPE
--> -->
<define name="roles-type">
<define name="call-type">
<zeroOrMore> <zeroOrMore>
<element name="sip"> <element name="entry">
<ref name="sip-dialog-id-type"/> <ref name="single-role-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
</define>
<!--
SIP DIALOG ID TYPE
-->
<define name="sip-dialog-id-type">
<zeroOrMore> <zeroOrMore>
<element name="display-text"> <ref name="anyElement"/>
<text/>
</element>
<element name="call-id">
<text/>
</element>
<element name="from-tag">
<text/>
</element>
<element name="to-tag">
<text/>
</element>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!--
DISCONNECTION TYPE
-->
<define name="disconnection-type">
<choice>
<value type="string">departed</value>
<value type="string">booted</value>
<value type="string">failed</value>
<value type="string">busy</value>
</choice>
</define>
<!--
JOINING TYPE
-->
<define name="joining-type">
<choice>
<value type="string">dialed-in</value>
<value type="string">dialed-out</value>
<value type="string">focus-owner</value>
</choice>
</define>
<!--
ENDPOINT STATUS TYPE
-->
<define name="endpoint-status-type">
<choice>
<value type="string">pending</value>
<value type="string">dialing-out</value>
<value type="string">dialing-in</value>
<value type="string">alerting</value>
<value type="string">on-hold</value>
<value type="string">connected</value>
<value type="string">muted-via-focus</value>
<value type="string">disconnecting</value>
<value type="string">disconnected</value>
</choice>
</define>
<!--
STATE TYPE
-->
<define name="state-type">
<choice>
<value type="string">full</value>
<value type="string">partial</value>
<value type="string">deleted</value>
</choice>
</define>
<!--
***********************************************
TYPE DEFINED IN THE ROLE DOCUMENT
***********************************************
-->
<!-- <!--
ROLE TYPE ROLE TYPE
--> -->
<define name="role-type"> <define name="role-type">
<optional>
<attribute name="read-only"> <attribute name="read-only">
<ref name="single-role-type"/> <ref name="single-role-type"/>
</attribute> </attribute>
</optional>
<optional>
<attribute name="write-only"> <attribute name="write-only">
<ref name="single-role-type"/> <ref name="single-role-type"/>
</attribute> </attribute>
</optional>
<ref name="anyAttribute"/>
</define> </define>
<!-- <!--
SINGLE ROLE TYPE SINGLE ROLE TYPE
--> -->
<define name="single-role-type"> <define name="single-role-type">
<choice> <choice>
<value type="string">Administrator</value> <value type="string">administrator</value>
<value type="string">Creator</value> <value type="string">creator</value>
<value type="string">Moderator</value> <value type="string">moderator</value>
<value type="string">Participant</value> <value type="string">participant</value>
<value type="string">Observer</value> <value type="string">observer</value>
</choice>
</define>
<!--
************************************************************
TYPE DEFINED IN THE COMMON POLICY DOCUMENT
************************************************************
-->
<!--
VALIDITY TYPE
-->
<define name="validityType">
<choice>
<element name="from">
<data type="int"/>
</element>
<element name="until">
<data type="int"/>
</element>
</choice> </choice>
</define> </define>
<!-- <!--
ONE TYPE *********************************
EXTENSIBILITY OF THE SCHEMA
*********************************
--> -->
<define name="oneType">
<attribute name="id">
<data type="anyURI"/>
</attribute>
</define>
<!-- <!--
MANY TYPE EXTENSIBILITY ELEMENTS
--> -->
<define name="manyType"> <define name="anyElement">
<element>
<anyName/>
<zeroOrMore>
<choice> <choice>
<element name="except"> <attribute>
<ref name="exceptType"/> <anyName/>
</element>
</choice>
<attribute name="domain">
<text/>
</attribute> </attribute>
</define>
<define name="exceptType">
<attribute name="domain">
<text/> <text/>
</attribute> <ref name="anyElement"/>
<attribute name="id"> </choice>
<data type="anyURI"/> </zeroOrMore>
</attribute> </element>
</define> </define>
<!-- <!--
SPHERE TYPE EXTENSIBILITY ATTRIBUTES
--> -->
<define name="sphereType"> <define name="anyAttribute">
<attribute name="value"> <zeroOrMore>
<attribute>
<anyName>
<except>
<name ns="">entity</name>
<name ns="">version</name>
<name ns="">state</name>
<name ns="">xml:lang</name>
<name ns="">required-participant</name>
<name ns="">PIN-code</name>
<name ns="">purpose</name>
<name ns="">role</name>
<name ns="">type</name>
<name ns="">min</name>
<name ns="">max</name>
<name ns="">label</name>
<name ns="">decision</name>
<name ns="">name</name>
<name ns="">policy</name>
<name ns="">moderator-controlled</name>
<name ns="">uri</name>
<name ns="">method</name>
<name ns="">id</name>
<name ns="">domain</name>
<name ns="">read-only</name>
<name ns="">write-only</name>
<nsName ns=""/>
<nsName ns="urn:ietf:params:xml:ns:conference-schema"/>
</except>
</anyName>
<text/> <text/>
</attribute> </attribute>
</zeroOrMore>
</define> </define>
</grammar>
5. XML Schema Extensibility
The Common Conference Information Data Model defined in this document
is meant to be extensible toward specific application domains. Such
an extension is accomplished by defining elements, child elements and
attributes that are specific to the desired application domain. Each
extension MUST define its own namespace. Points of extension MUST be
defined in the schema, and SHOULD be done using the <anyName>/
<except> construct.
Elements or attributes from unknown namespaces MUST be ignored.
6. XML example
The following is an example of a common conference information
document. The conference starts on October 17, 2006, at 10:30 AM in
New York City and finishes the same day at 12:30 PM every week. In
this example, there are currently 3 participants in a conference, one
administrator, one moderator, and one participant. Note that
sidebars are allowed in this conference and there is one sidebar in
the conference. Also note that there is one floor moderator for the
audio and a different floor moderator for the video.
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:common-conference-schema"
xmlns:info="urn:ietf:params:xml:ns:conference-info"
xmlns:sesspol="urn:ietf:params:xml:ns:sessionpolicy"
xmlns:compol="urn:ietf:params:xml:ns:common-policy"
entity="sips:conference@example.com">
<!-- <!--
CONFERENCE DESCRIPTION *************************************************************
--> TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
<info:conference-description xml:lang="en-us"> *************************************************************
<info:display-text>Discussion of Formula-1 racing<
/info:display-text>
<info:subject> Sports:Formula-1</info:subject>
<info:free-text>This is a conference example</info:free-text>
<info:keywords>Formula-1, cars</info:keywords>
<web-page>http://www.example.com/users/alice/formula-1<
/web-page>
<security-level>low</security-level>
<allow-sidebars>true</allow-sidebars>
<conference-stage>running</conference-stage>
<!--
CONFERENCE TIME
-->
<conference-time>
<entry>
<base>BEGIN:VCALENDAR
PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20051103T140728Z
UID:carol at example.com
ORGANIZER:MAILTO:carol at example.com
DTSTART:20061017T143000Z
RRULE:FREQ=WEEKLY
DTEND:20061017T163000Z</base>
<mixing-start-offset required-participant="moderator">
20061017T142900Z</mixing-start-offset>
<mixing-end-offset required-participant="participant">
20061017T163100Z</mixing-end-offset>
<must-join-before-offset>
20061017T15300Z</must-join-before-offset>
</entry>
</conference-time>
<!--
CONFERENCE UNIQUE IDENTIFIERS
-->
<info:conf-uris>
<info:SIP>
<info:uri>tel:+3585671234</info:uri>
<info:display-text>Conference Bridge</info:display-text>
<info:purpose>participation</info:purpose>
</info:SIP>
<info:SIP>
<info:uri>http://www.example.com/54634/live.ram</info:uri>
<info:purpose>streaming</info:purpose>
</info:SIP>
</info:conf-uris>
<!--
SERVICE URIS
-->
<info:service-uris>
<info:SIP>
<info:uri>http://www.example.com/formula1/</info:uri>
<info:purpose>web-page</info:purpose>
</info:SIP>
</info:service-uris>
<!--
MAXIMUM USER COUNT
-->
<maximum-user-count>
<entry role = "administrator">2</entry>
<entry role = "moderator">5</entry>
<entry role = "participant">150</entry>
</maximum-user-count>
<!--
AVAILABLE MEDIA
-->
<info:available-media>
<info:entry label="10234">
<info:display-text>main audio</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
<mixing-mode>automatic</mixing-mode>
<mix-level>3</mix-level>
<codecs decision="automatic">
<codec name="PCMU" policy="allowed"/>
</codecs>
</info:entry>
<info:entry label="10235">
<info:display-text>main video</info:display-text>
<info:type>video</info:type>
<mixing-mode>automatic</mixing-mode>
<mix-level>4</mix-level>
<info:status>sendrecv</info:status>
<sesspol:codecs decision="automatic">
<sesspol:codec name="H.263" policy="allowed"/>
</sesspol:codecs>
</info:entry>
</info:available-media>
</info:conference-description>
<!--
HOST INFO
-->
<info:host-info>
<info:display-text>Formula1</info:display-text>
<info:web-page>http://www.example.com/formula-1/<
/info:web-page>
<info:uris>
<info:SIP>
<info:uri>sip:alice@example.com</info:uri>
</info:SIP>
<info:SIP>
<info:uri>sip:carol@example.com</info:uri>
</info:SIP>
</info:uris>
</info:host-info>
<!--
CONFERENCE STATE
-->
<info:conference-state>
<allow-conference-state>true<
/allow-conference-state>
<info:user-count>3</info:user-count>
<info:active>true</info:active>
<info:locked>false</info:locked>
</info:conference-state>
<!--
FLOOR INFORMATION
-->
<floor-information>
<allow-floor-events>true</allow-floor-events>
<floor-request-handling>1 </floor-request-handling>
<conference-floor-policy>
<floor moderator-controlled="true" label="10234">
<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>
<floor moderator-controlled="true" label="10235">
<media-types>video</media-types>
<algorithm>Moderator-controlled</algorithm>
<max-floor-users>1</max-floor-users>
<moderator-uri>sip:carol@example.com<
/moderator-uri>
</floor>
</conference-floor-policy>
</floor-information>
<!--
USERS
-->
<users>
<join-handling>allow</join-handling>
<!--
ALLOWED USERS LIST
-->
<allowed-users-list>
<target uri="sip:bob@example.com" method="dial-out"/>
<target uri="sip:alice@example.com" method="dial-out"/>
<target uri="sip:carol@example.com" method="dial-out"/>
<target uri="sip:john@example.com" method="refer"/>
</allowed-users-list>
<!--
PRIVILEGES CONTROL LIST
-->
<privileges-control-list>
<conference-rules>
<entry id="1">
<conditions>
<compol:identity>
<compol:domain>example.com</compol:domain>
</compol:identity>
<compol:validity>
<compol:from>20061017T143000Z</compol:from>
<compol:to>20061017T163000Z</compol:to>
</compol:validity>
</conditions>
<compol:actions>
<compol:allow-conference-state>true<
/compol:allow-conference-state>
</compol:actions>
</entry>
<entry id="2">
<conditions>
<compol:identity>
<compol:uri>bob@example.com</compol:uri>
</compol:identity>
</conditions>
<compol:actions>
<join-handling>block</join-handling>
</compol:actions>
</entry>
</conference-rules>
</privileges-control-list>
<!--
USER
-->
<info:user entity="sip:bob@example.com">
<info:display-text>Bob Hoskins</display-text>
<info:associated-aors>
<info:entry>
<info:uri>mailto:bob@example.com</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<provide-anonymity>false</provide-anonymity>
<info:roles>
<info:entry>participant</info:entry>
</info:roles>
<info:languages>en</info:languages>
<sphere value="work"/>
<allow-refer-users-dynamically>false<
/allow-refer-users-dynamically>
<allow-invite-users-dynamically>false<
/allow-invite-users-dynamically>
<allow-remove-users-dynamically>false<
/allow-remove-users-dynamically>
<!--
ENDPOINTS
-->
<info:endpoint entity="sip:bob@example.com">
<info:display-text>Bob's Laptop</info:display-text>
<info:referred>
<info:when>20061017T140000Z</info:when>
<info:reason>expert required</info:reason>
<info:by>sip:alice@example.com</info:by>
</info:referred>
<info:status>connected</info:status>
<info:joining-method>dialed-out</info:joining-method>
<info:joining-info>
<info:when>20061017T140000Z</info:when>
<info:reason>invitation</info:reason>
<info:by>sip:alice@example.com</info:by>
</info:joining-info>
<!--
MEDIA
-->
<info:media id="1">
<info:label>10235</info:label>
<info:src-id>432424</info:src-id>
</info:media>
<!--
CALL INFO
-->
<info:call-info>
<info:sip>
<info:display-text>full info</info:display-text>
<info:call-id>hsjh8980vhsb78</info:call-id>
<info:from-tag>vav738dvbs</info:from-tag>
<info:to-tag>8954jgjg8432</info:to-tag>
</info:sip>
</info:call-info>
</info:endpoint>
</info:user>
<!--
USER
--> -->
<info:user entity="sip:alice@example.com">
<info:display-text>Alice Kay</info:display-text>
<info:associated-aors>
<info:entry>
<info:uri>mailto:alice@example.com</info:uri>
<info:display-text>email</info:display-text>
</info:entry>
</info:associated-aors>
<provide-anonymity>false</provide-anonymity>
<info:roles>
<info:entry>moderator</info:entry>
</info:roles>
<info:languages>en</info:languages>
<sphere value="work"/>
<allow-refer-users-dynamically>true<
/allow-refer-users-dynamically>
<allow-invite-users-dynamically>true<
/allow-invite-users-dynamically>
<allow-remove-users-dynamically>true<
/allow-remove-users-dynamically>
<!-- <!--
ENDPOINTS WILDCARD FOR EVENT-PACKAGE NAMESPACE
-->
<info:endpoint entity="sip:alice@example.com">
<info:display-text>Alice's Desktop</info:display-text>
<info:status>connected</info:status>
<info:joining-method>dialed-in</info:joining-method>
<info:joining-info>
<info:when>20061017T133508Z</info:when>
<info:reason>invitation</info:reason>
<info:by>sip:conference@example.com</info:by>
</info:joining-info>
<!--
MEDIA
--> -->
<info:media id="1"> <define name="conference-info-urn">
<info:label>10235</info:label> <element>
<info:src-id>432424</info:src-id> <anyName>
<info:status>sendrecv</info:status> <except>
</info:media> <nsName ns="urn:ietf:params:xml:ns:conference-info-urn"/>
<info:media id="2"> <nsName ns=""/>
<info:label>10234</info:label> </except>
<info:src-id>532535</info:src-id> </anyName>
<info:status>sendrecv</info:status> <mixed>
</info:media> <zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<ref name="conference-info-urn"/>
</choice>
</zeroOrMore>
</mixed>
</element>
</define>
<!-- <!--
CALL INFO DEFINITION OF STATE TYPE
--> -->
<info:call-info> <define name="state-type">
<info:sip> <choice>
<info:display-text>full info</info:display-text> <value>full</value>
<info:call-id>truy45469123478</info:call-id> <value>partial</value>
<info:from-tag>asd456cbgt</info:from-tag> <value>deleted</value>
<info:to-tag>3456jgjg1234</info:to-tag> </choice>
</info:sip> </define>
</info:call-info>
</info:endpoint>
</info:user>
<!-- <!--
USER DEFINITION OF ENDPOINT STATUS TYPE
--> -->
<info:user entity="sip:carol@example.com"> <define name="media-status-type">
<info:display-text>Carol More</info:display-text> <choice>
<info:associated-aors> <value>recvonly</value>
<info:entry> <value>sendonly</value>
<info:uri>mailto:carol@example.com</info:uri> <value>sendrecv</value>
<info:display-text>email</info:display-text> <value>inactive</value>
</info:entry> </choice>
</info:associated-aors> </define>
<provide-anonymity>false</provide-anonymity>
<info:roles>
</info:entry>administrator</info:entry>
</info:roles>
<info:languages>en</info:languages>
<sphere value="work"/>
<allow-refer-users-dynamically>true<
/allow-refer-users-dynamically>
<allow-invite-users-dynamically>true<
/allow-invite-users-dynamically>
<allow-remove-users-dynamically>true<
/allow-remove-users-dynamically>
<!-- <!--
ENDPOINTS ENDPOINT STATUS TYPE
--> -->
<info:endpoint entity="sip:carol@example.com"> <define name="endpoint-status-type">
<info:display-text>Carol's Computer</info:display-text> <choice>
<info:status>connected</info:status> <value>pending</value>
<info:joining-method>dialed-in</info:joining-method> <value>dialing-out</value>
<info:joining-info> <value>dialing-in</value>
<info:when>20061017T133005Z</info:when> <value>alerting</value>
<info:reason>invitation</info:reason> <value>on-hold</value>
<info:by>sip:conference@example.com</info:by> <value>connected</value>
</info:joining-info> <value>muted-via-focus</value>
<value>disconnecting</value>
<value>disconnected</value>
</choice>
</define>
<!-- <!--
MEDIA JOINING TYPE
--> -->
<info:media id="1"> <define name="joining-type">
<info:label>10235</info:label> <choice>
<info:src-id>432424</info:src-id> <value>dialed-in</value>
<info:status>sendrecv</info:status> <value>dialed-out</value>
</info:media> <value>focus-owner</value>
<info:media id="2"> </choice>
<info:label>10234</info:label> </define>
<info:src-id>532535</info:src-id>
<info:status>sendrecv</info:status>
</info:media>
<!-- <!--
CALL INFO DISCONNECTION TYPE
--> -->
<info:call-info> <define name="disconnection-type">
<info:sip> <choice>
<info:display-text>full info</info:display-text> <value>departed</value>
<info:call-id>wevb12562321894</info:call-id> <value>booted</value>
<info:from-tag>asw456wedf</info:from-tag> <value>failed</value>
<info:to-tag>2365dfrt3497</info:to-tag> <value>busy</value>
</info:sip> </choice>
</info:call-info> </define>
</info:endpoint>
</info:user>
</users>
<!-- <!--
SIDEBARS BY REFERENCE ******************************************
TYPE DEFINED IN THE COMMON POLICY DOCUMENT
******************************************
--> -->
<info:sidebars-by-ref>
<info:entry>
<info:uri>sips:conference@example.com;grid=40</info:uri>
<info:display-text>private with Bob</info:display-text>
</info:entry>
</info:sidebars-by-ref>
<!-- <!--
SIDEBARS BY VALUE WILDCARD FOR COMMON-POLICY NAMESPACE
--> -->
<info:sidebars-by-val> <define name="common-policy">
<info:entry entity="sips:conference@example.com;grid=40"> <element>
<info:users> <anyName>
<info:user entity="sip:bob@example.com"/> <except>
<info:user entity="sip:carol@example.com"/> <nsName ns="urn:ietf:params:xml:ns:common-policy"/>
</info:users> <nsName ns=""/>
</info:entry> </except>
</info:sidebars-by-val> </anyName>
</info:conference-info> <mixed>
<zeroOrMore>
Note that due to RFC formatting conventions, this documents splits <choice>
lines whose content would exceed 72 characters. Two backslash <attribute>
characters mark where the lines folding has taken place. These <anyName/>
backslash would not appear in the actual XML data model. </attribute>
<ref name="common-policy"/>
7. Security Considerations </choice>
</zeroOrMore>
A malicious user can manipulate parts of the Conference Information </mixed>
Data Model privileges document giving themselves and others </element>
privileges to manipulate the data model. It is very important that </define>
only authorized clients are able to manipulate the Conference </grammar>
Information Data Model document. Any conference control protocol
MUST provide authentication, confidentiality and integrity.
8. IANA Considerations
9. Acknowledgements
This document is really a distillation of many ideas discussed over a
long period of time. These ideas were contributed by many different
drafts in the XCON working group and the SIPPING working group. I
would like to thanks Orit Levin, Adam Roach, Mary Barnes, Chris
Boulton, Umesh Chandra, Orit Levin, Jari Urpilainen, and Srivatsa
Srinivasan for their comments. Also, I would like to thanks Hisham
Khartabil, Petri Koskelainen, and Aki Niemi to let us use the policy
information of their cpcp drafts in this document.
10. References
10.1. Normative References
[1] Barnes, M., "A Framework and Data Model for Centralized
Conferencing", draft-ietf-xcon-framework-05 (work in progress),
September 2006.
[2] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
[5] Paoli, J., Maler, E., Sperberg-McQueen, C., and T. Bray,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium FirstEdition REC-xml-20001006, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[6] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
10.2. Informative References
[7] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-06 (work in progress), December 2005.
[8] Schulzrinne, H., "Common Policy: A Document Format for
Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-11 (work in progress),
August 2006.
[9] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams",
draft-ietf-mmusic-sdp-bfcp-03 (work in progress), December 2005.
Authors' Addresses Authors' Addresses
Oscar Novo Oscar Novo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Oscar.Novo@ericsson.com Email: Oscar.Novo@ericsson.com
skipping to change at page 59, line 43 skipping to change at page 69, line 40
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
David P. Morgan David P. Morgan
Fidelity Investments Fidelity Investments
82 Devonshire St, MZ V8C 82 Devonshire St, MZ V3C
Boston, MA 02109-3614 Boston, MA 02109-3614
USA USA
Email: Dave.Morgan@fmr.com Email: Dave.Morgan@fmr.com
Roni Even Roni Even
Polycom Polycom
94 Derech Em Hamoshavot 94 Derech Em Hamoshavot
Petach Tikva 49130 Petach Tikva 49130
Israel Israel
Email: roni.even@polycom.co.il Email: roni.even@polycom.co.il
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
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 Rights 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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 395 change blocks. 
1741 lines changed or deleted 2194 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/