draft-ietf-xcon-common-data-model-05.txt   draft-ietf-xcon-common-data-model-06.txt 
XCON O. Novo XCON O. Novo
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: October 19, 2007 D. Morgan Expires: May 3, 2008 D. Morgan
Fidelity Investments Fidelity Investments
R. Even R. Even
Polycom Polycom
April 17, 2007 October 31, 2007
Conference Information Data Model for Centralized Conferencing (XCON) Conference Information Data Model for Centralized Conferencing (XCON)
draft-ietf-xcon-common-data-model-05.txt draft-ietf-xcon-common-data-model-06.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 38 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 October 19, 2007. This Internet-Draft will expire on May 3, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines an Extensible Markup Language (XML)-based This document defines an Extensible Markup Language (XML)-based
conference information data model for centralized conferencing conference information data model for centralized conferencing
(XCON). A conference object, which can be manipulated using a (XCON). A conference information data model is designed to convey
conference control protocol, at a conference server represents a information about the conference and about participation in the
particular instantiation of this data model. The conference conference. The conference information data model defined in this
information data model defined in this document is an extension of document constitutes an extension of the data format specified in the
(and thus, compatible with) the model specified in the Session Session Initiation Protocol (SIP) Event Package for Conference State.
Initiation Protocol (SIP) Event Package for Conference State.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Data Model Structure . . . . . . . . . . . . . . . . . . . 6 3.1. Data Model Format . . . . . . . . . . . . . . . . . . . . 6
3.2. Role Definitions . . . . . . . . . . . . . . . . . . . . . 7 3.2. Data Model Namespace . . . . . . . . . . . . . . . . . . . 6
3.2.1. Role in a Floor . . . . . . . . . . . . . . . . . . . 8 3.3. The Conference Object Identifier . . . . . . . . . . . . . 7
3.2.2. Changing Roles . . . . . . . . . . . . . . . . . . . . 8 3.4. Data Model Structure . . . . . . . . . . . . . . . . . . . 8
4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 8 4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 9
4.1. <conference-description> . . . . . . . . . . . . . . . . . 13 4.1. <conference-info> . . . . . . . . . . . . . . . . . . . . 12
4.1.1. <conference-time> . . . . . . . . . . . . . . . . . . 14 4.2. <conference-description> . . . . . . . . . . . . . . . . . 13
4.1.2. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. <display-text> . . . . . . . . . . . . . . . . . . . . 13
4.1.3. <service-uris> . . . . . . . . . . . . . . . . . . . . 16 4.2.2. <subject> . . . . . . . . . . . . . . . . . . . . . . 13
4.1.4. <maximum-user-count> . . . . . . . . . . . . . . . . . 16 4.2.3. <free-text> . . . . . . . . . . . . . . . . . . . . . 13
4.1.5. <available-media> . . . . . . . . . . . . . . . . . . 16 4.2.4. <keywords> . . . . . . . . . . . . . . . . . . . . . . 13
4.1.5.1. <controls> . . . . . . . . . . . . . . . . . . . . 17 4.2.5. <allow-sidebars> . . . . . . . . . . . . . . . . . . . 13
4.1.5.1.1. mute . . . . . . . . . . . . . . . . . . . . . 17 4.2.6. <conference-time> . . . . . . . . . . . . . . . . . . 14
4.1.5.1.2. pause-video . . . . . . . . . . . . . . . . . 17 4.2.7. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 15
4.1.5.1.3. gain . . . . . . . . . . . . . . . . . . . . . 18 4.2.8. <service-uris> . . . . . . . . . . . . . . . . . . . . 15
4.1.5.1.4. video-layout . . . . . . . . . . . . . . . . . 18 4.2.9. <maximum-user-count> . . . . . . . . . . . . . . . . . 15
4.2. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 19 4.2.10. <available-media> . . . . . . . . . . . . . . . . . . 15
4.3. <conference-state> . . . . . . . . . . . . . . . . . . . . 19 4.3. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 18
4.4. <floor-information> . . . . . . . . . . . . . . . . . . . 19 4.4. <conference-state> . . . . . . . . . . . . . . . . . . . . 18
4.5. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.1. <allow-conference-event-subscription> . . . . . . . . 18
4.5.1. <allowed-users-list> . . . . . . . . . . . . . . . . . 22 4.4.2. <user-count> . . . . . . . . . . . . . . . . . . . . . 18
4.5.2. <user> . . . . . . . . . . . . . . . . . . . . . . . . 22 4.4.3. <active> . . . . . . . . . . . . . . . . . . . . . . . 18
4.5.2.1. <from-mixer>, <to-mixer> . . . . . . . . . . . . . 24 4.4.4. <locked> . . . . . . . . . . . . . . . . . . . . . . . 19
4.5.2.1.1. <floor> . . . . . . . . . . . . . . . . . . . 24 4.5. <floor-information> . . . . . . . . . . . . . . . . . . . 19
4.5.3. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . 24 4.5.1. <conference-ID> . . . . . . . . . . . . . . . . . . . 19
4.5.4. <sidebars-by-val> . . . . . . . . . . . . . . . . . . 24 4.5.2. <allow-floor-events> . . . . . . . . . . . . . . . . . 19
5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 25 4.5.3. <floor-request-handling> . . . . . . . . . . . . . . . 19
6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 32 4.5.4. <conference-floor-policy> . . . . . . . . . . . . . . 20
4.6. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.1. <join-handling> . . . . . . . . . . . . . . . . . . . 21
4.6.2. <user-admission-policy> . . . . . . . . . . . . . . . 21
4.6.3. <allowed-users-list> . . . . . . . . . . . . . . . . . 22
4.6.4. <user> and Its <user> Sub-elements . . . . . . . . . . 22
4.6.4.1. <display-text> . . . . . . . . . . . . . . . . . . 23
4.6.4.2. <associated-aors> . . . . . . . . . . . . . . . . 23
4.6.4.3. <provide-anonymity> . . . . . . . . . . . . . . . 24
4.6.4.4. <roles> . . . . . . . . . . . . . . . . . . . . . 24
4.6.4.5. <languages> . . . . . . . . . . . . . . . . . . . 24
4.6.4.6. <cascaded-focus> . . . . . . . . . . . . . . . . . 24
4.6.4.7. <allow-refer-users-dynamically> . . . . . . . . . 24
4.6.4.8. <allow-invite-users-dynamically> . . . . . . . . . 24
4.6.4.9. <allow-remove-users-dynamically> . . . . . . . . . 25
4.6.4.10. <endpoint> . . . . . . . . . . . . . . . . . . . . 25
4.7. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . . . 26
4.8. <sidebars-by-val> . . . . . . . . . . . . . . . . . . . . 26
5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 26
6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 33
7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 33 7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 41
9.1. Conference Relax NG Schema Registration . . . . . . . . . 41 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 41
9.2. Conference Namespace Registration . . . . . . . . . . . . 41 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 42
9.3. Conference Object Identifier Registration . . . . . . . . 41 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
9.4. Conference User Identifier Registration . . . . . . . . . 42 9.1. Conference Relax NG Schema Registration . . . . . . . . . 42
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 9.2. Conference Namespace Registration . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 9.3. Conference Object Identifier Registration . . . . . . . . 42
11.1. Normative References . . . . . . . . . . . . . . . . . . . 42 9.4. Conference User Identifier Registration . . . . . . . . . 43
11.2. Informative References . . . . . . . . . . . . . . . . . . 42 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
11.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML
Syntax . . . . . . . . . . . . . . . . . . . . . . . 43 Syntax . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . . . . 68 Intellectual Property and Copyright Statements . . . . . . . . . . 65
1. Introduction 1. Introduction
There is a core data set of conference information that is utilized
in any conference, independent of the specific conference media.
This core data set called the 'conference information data model' is
defined in this document using an Extensible Markup Language (XML)-
based. The conference information data model defined in this
document is logically represented by the conference object.
Conference objects are a fundamental concept in Centralized Conference objects are a fundamental concept in Centralized
conferencing, as described in the XCON Conferencing Framework [4]. A Conferencing, as described in the Centralized Conferencing Framework
conference object contains data that represents a conference during [4]. A conference object contains data that represents a conference
each of its various stages (e.g., reserved, started, running, ended, during each of its various stages (e.g., created/creation, reserved/
etc.). Conference Objects are instantiations of the conference reservation, active/activation, completed/completion). A conference
information data model defined in this document. Consequently, object can be manipulated using a conference control protocol at a
conference server. The conference object represents a particular
instantiation of a conference information data model. Consequently,
conference objects follow the XML format defined in this document. conference objects follow the XML format defined in this document.
A conference object contains the core information of a conference A conference object contains the core information of a conference
(i.e., capabilities, membership, roles, call control signaling, (i.e., capabilities, membership, call control signaling, media, etc.)
media, etc.) and specifies who, and in which way, can manipulate that and specifies who, and in which way that information can be
information. manipulated.
Figure 1 shows logical functional elements of a conference server as Figure 1 shows the logical functional elements of a conference server
defined by the XCON Conferencing Framework [4]. They are a as defined by the Centralized Conferencing Framework [4]. They are a
Conference Control Server, a Floor Control Server, a number of Foci, Conference Control Server, a Floor Control Server, a number of Foci,
and a Notification Service. A conference control protocol provides and a Notification Service. A conference control protocol provides
the interface between a conference and media control client, and the the interface between a conference control client and the conference
conference control server. A floor control protocol (e.g., BFCP [5]) control server. A floor control protocol (e.g., BFCP [5]) provides
provides the interface between a floor control client and the floor the interface between a floor control client and the floor control
control server. A call signaling protocol (e.g., SIP, H.323, PSTN, server. A call signaling protocol (e.g., SIP, H.323, Q.931, ISUP,
etc.) provides the interface between a call signaling client and a etc.) provides the interface between a call signaling client and a
Focus. A notification protocol (e.g., SIP-based event notifications Focus. A notification protocol (e.g., SIP-based event notifications
[6]) provides the interface between the conferencing client and the [6]) provides the interface between the conferencing client and the
Notification Service. Within a conference, the conference control Notification Service. Within a conference, the conference control
server, floor control server, and focus can modify the information in server, floor control server, and focus can modify the information in
the conference object. the conference object.
............................................................... ...............................................................
. Conferencing Server . . Conferencing Server .
. +---------------------------------------------------+ . . +---------------------------------------------------+ .
skipping to change at page 5, line 28 skipping to change at page 5, line 28
. | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| .
. | | | Host information | |||| . . | | | Host information | |||| .
. | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| .
. | | | Conference state | |||| . . | | | Conference state | |||| .
. | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| .
. | | | Floor information | |||| . . | | | Floor information | |||| .
. | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| .
. | | | Membership (users, roles, capacity) | |||| . . | | | Membership (users, capacity) | |||| .
. | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| .
. | | | Sidebars, Etc. | |||| . . | | | Sidebars, Etc. | |||| .
. | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| . . | | +----------------------------------------------+ |||| .
. | | | Etc. | |||| . . | | | Etc. | |||| .
. | | +----------------------------------------------+ |||+ . . | | +----------------------------------------------+ |||+ .
. | +--------------------------------------------------+|+ . . | +--------------------------------------------------+|+ .
. +----^------------------^-------------^--------|------+ . . +----^------------------^-------------^--------|------+ .
. | | | | . . | | | | .
skipping to change at page 6, line 5 skipping to change at page 6, line 5
........|..............|..............|..........|............. ........|..............|..............|..........|.............
|Conference |Binary Floor |Call |Notification |Conference |Binary Floor |Call |Notification
|Control |Control |Signaling |Protocol |Control |Control |Signaling |Protocol
|Protocol |Protocol |Protocol | |Protocol |Protocol |Protocol |
........v..............v..............v..........v............. ........v..............v..............v..........v.............
. C o n f e r e n c i n g C l i e n t . . C o n f e r e n c i n g C l i e n t .
............................................................... ...............................................................
Figure 1: Conference Server Architecture Figure 1: Conference Server Architecture
The Session Initiation Protocol (SIP) Event Package for Conference The Session Initiation Protocol (SIP) Event Package for Conference
State, specified in RFC 4575 [1], already defines a data model for State, specified in RFC4575 [1], already defines a data format for
conferences. However, that model is SIP specific and lacks elements conferences. However, that model is SIP specific and lacks elements
related to some of the functionality defined by the XCON conferencing related to some of the functionality defined by the Centralized
framework [4] (e.g., floor control). The data model defined in this Conferencing Framework [4] (e.g., floor control). The data model
document extends the one defined in RFC 4575 [1]. The result is a defined in this document constitutes a superset of the data format
data model that supports more call signaling protocols besides SIP defined in RFC4575 [1]. The result is a data format that supports
and that covers all the functionality defined in the XCON more call signaling protocols besides SIP and that covers all the
conferencing framework [4]. functionality defined in the Centralized Conferencing Framework [4].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
This document uses the terminology defined in the XCON Conferencing This document uses the terminology defined in the Centralized
Framework [4], the SIP conferencing framework [7] and the BFCP Conferencing Framework [4], the SIPPING conferencing framework [7]
(Binary Floor Control Protocol) specification [5]. Readers of this and the BFCP (Binary Floor Control Protocol) specification [5].
document are supposed to be familiar with the terminology used in Readers of this document should be familiar with the terminology used
those documents. in those documents.
3. Overview 3. Overview
The data model defined in this document is the result of extending The data model specified in this document is the result of extending
the data model defined in RFC 4575 [1] with new elements, which carry the data format defined in RFC4575 [1] with new elements. Examples
information such as non-SIP URIs or floor-control-related parameters. of such extensions include scheduling elements, media control
This data model can be used by conference servers providing different elements, floor control elements, non-SIP URIs, and addition of
types of basic conferences. It is expected that this data model can localization extensions to text elements. This data model can be
be further extended with new elements in the future in order to used by conference servers providing different types of basic
implement advanced features. conferences. It is expected that this data model can be further
extended with new elements in the future in order to implement
3.1. Data Model Structure additional advanced features.
The information in this data model is structured in the following
manner. All the information related to a conference is contained in
a <conference-info> element. The <conference-info> element contains
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).
o The <conference-state> element informs the subscribers about the
changes in the overall conference information.
o The <floor-information> element contains information about the
status of the different floors in the conference.
o The <users> element describes the membership information as a
whole. The <users> element contains a set of <user> child
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.
3.2. 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. Role in a Floor
Floor control in centralized conferencing is described in the Binary
Floor Control Protocol (BFCP) [5]. 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, 3.1. Data Model Format
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 [5].
Users in a conference MAY assume different roles in different floors. A conference object document is an XML [8] document that MUST be well
They MAY also assume different roles in the same floor, as floor formed and SHOULD be valid. Conference object documents MUST be
transactions are processed. based on XML 1.0 and SHOULD be encoded using UTF-8.
3.2.2. Changing Roles 3.2. Data Model Namespace
Users can change roles during a conference. This can be done in two This specification defines a new namespace specification for
ways: First, the user can join a new floor in a different role. identifying the elements defined in the data model. This namespace
Second, an "administrator" or "creator" can dynamically change that is as follows:
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 urn:ietf:params:xml:ns:xcon-conference-info
A conference object document is an XML [8] document that MUST be well 3.3. The Conference Object Identifier
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 The conference object identifier (XCON-URI) can be viewed as a key to
<conference-info>, which is defined in [1]. The <conference-info> accessing a specific conference object. It can be used, for
element has an 'entity' attribute that contains a conference object instance, by the conference control protocol to access, manipulate
identifier (XCON-URI) that identifies the conference being described and delete a conference object. A conference object identifier is
in the document. provided to the conferencing client by the conference notification
service or through out-of-band mechanisms (e.g. E-Mail).
A conferencing system may maintain a relationship between the A conferencing system may maintain a relationship between the
conference object identifiers and the identifiers associated with conference object identifiers and the identifiers associated with
each of the complimentary centralized conferencing protocols (e.g., each of the complementary centralized conferencing protocols (e.g.,
call signaling protocols, BFCP, etc.). call signaling protocols, BFCP, etc.). To facilitate the maintenance
of these relationships, the conference object identifier acts as a
This implicit binding provides a structured mapping of the various top level identifier within the conferencing system for the purpose
of identifying the interfaces for these other protocols. This
implicit binding provides a structured mapping of the various
protocols with the associated conference object Identifier. Figure 2 protocols with the associated conference object Identifier. Figure 2
illustrates the relationship between the identifiers used for the illustrates the relationship between the identifiers used for the
protocols within the framework [4] and the general XCON-URI. protocols and the general conference object identifier (XCON-URI).
+--------------------------+ +--------------------------+
| Conference | | Conference |
| Object | | Object |
| Identifier | | Identifier |
+--------------------------+ +--------------------------+
| xcon:Ji092i@example.com | | xcon:Ji092i@example.com |
+------+-------------------+ +------+-------------------+
| |
| |
| |
+-----------------+---------------+ +-----------------+---------------+
| | | |
+-----------+-----------+ +-------+-------+ +-----------+-----------+ +----------+---------+
| CSP Conference IDs | | BFCP 'confid' | | CSP Conference IDs | |BFCP 'Conference ID'|
+-----------------------+ +---------------+ +-----------------------+ +--------------------+
|h323:Ji092i@example.com| | Ji092i | |h323:Ji092i@example.com| | Ji092i |
|tel:+44(0)2920930033 | +-------+-------+ |tel:+44(0)2920930033 | +----------+---------+
|sip:Ji092i@example.com | | |sip:Ji092i@example.com | |
+-----------------------+ +-------|-------+ +-----------------------+ +-------|--------+
| BFCP 'floorid | | BFCP 'Floor ID'|
+---------------+ +----------------+
| UEK78d | | 543 |
| 09cnJk | | 09cnJk |
+---------------+ +----------------+
Figure 2: Conference Object Mapping Figure 2: Conference Object Mapping
In Figure 2, the conference object identifier acts as the top level
key in the identification process. The call signaling protocols have
an associated conference user identifier, often represented in the
form of URIs. The binary floor control protocol, as defined in [5],
defines the 'conference ID' identifier which represents a conference
instance within floor control. When created within the conferencing
system, the 'conference ID' has a 1:1 mapping to the unique
conference object Identifier(XCON-URI). Operations associated with
the conference control protocols are directly associated with the
conference object, thus the primary identifier associated with these
protocols is the conference object identifier(XCON-URI). The
mappings between additional protocols/interface is not strictly 1:1
and does allow for multiple occurrences. For example, multiple call
signaling protocols will each have a representation that is
implicitly linked to the top level conference object identifier e.g.
H323 and SIP URIs that represent a conference instance. It should be
noted that a conferencing system is free to structure such
relationships as required and this information is just included as a
guideline that can be used.
Further elements can be added to the tree representation in Figure 2 Further elements can be added to the tree representation in Figure 2
to enable a complete representation of a conference instance within a to enable a complete representation of a conference instance within a
conferencing system. conferencing system.
The <conference-info> element contains the <conference-description>, 3.4. Data Model Structure
<host-info>, <conference-state>, <floor-information>, <users>,
<sidebars-by-ref>, <sidebars-by-val> child elements. All these The information in this data model is structured in the following
elements, except <floor-information>, are defined in [1]. A manner. All the information related to a conference is contained in
conference document MUST at least include the <conference- a <conference-info> element. The <conference-info> element contains
description>, <host-info>, <conference-state>, and <users> child 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).
o The <conference-state> element informs the subscribers about the
changes in the overall conference information.
o The <floor-information> element contains information about the
status of the different floors in the conference.
o The <users> element describes the membership information as a
whole. The <users> element contains a set of <user> child
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. elements.
Note that some of the elements described above such <conference-
info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by-
val> are not defined in the data model but are defined in the data
format of RFC 4575 [1]. We describe them here because they are part
of the basic structure of the data model.
4. Data Model Definition
The following non-normative diagram shows the structure of conference The following non-normative diagram shows the structure of conference
object documents. The operator "!" preceding an element indicates object documents. The operator "!" preceding an element indicates
that the element is mandatory in the data model. The operator "*" that the element is mandatory in the data model. The operator "*"
following an element indicates that the element is introduced and following an element indicates that the element is introduced and
defined in this document. That is, elements without a "*" have defined in this document. That is, elements without a "*" have
already been defined in RFC 4575 [1]. already been defined in RFC 4575 [1].
!<conference-info> !<conference-info>
| |
|--!<conference-description> |--!<conference-description>
| |--<display-text> | |--<display-text>
| |--<subject> | |--<subject>
| |--<free-text>* | |--<free-text>
| |--<keywords> | |--<keywords>
| |--<allow-sidebars>* | |--<allow-sidebars>*
| |--<conference-time>* | |--<conference-time>*
| | |--<entry>* | | |--<entry>*
| | | |--<base>* | | | |--<base>*
| | | |--<mixing-start-offset>* | | | |--<mixing-start-offset>*
| | | |--<mixing-end-offset>* | | | |--<mixing-end-offset>*
| | | |--<can-join-after-offset>* | | | |--<can-join-after-offset>*
| | | |--<must-join-before-offset>* | | | |--<must-join-before-offset>*
| | | |--<request-user>* | | | |--<request-user>*
| | | |--<notify-end-of-conference>* | | | |--<notify-end-of-conference>*
| | | |--<allowed-extend-mixing-end-offset>* | | | |--<allowed-extend-mixing-end-offset>*
| | ... | | ...
| |--<conf-uris> | |--<conf-uris>
| | |--<entry>* | | |--<entry>
| | | |--<uri> | | | |--<uri>
| | | |--<display-text> | | | |--<display-text>
| | | |--<purpose> | | | |--<purpose>
| | |--<H323>*
| | | |--<H.323-alias>*
| | | |--<H.323-URI>*
| | |--<PSTN-ISDN>*
| | | |--<phone number>*
| | ... | | ...
| |--<service-uris> | |--<service-uris>
| | |--<entry>* | | |--<entry>
| | | |--<uri> | | | |--<uri>
| | | |--<display-text> | | | |--<display-text>
| | | |--<purpose> | | | |--<purpose>
| | |--<H323>*
| | | |--<H.323-alias>*
| | | |--<H.323-URI>*
| | |--<PSTN-ISDN>*
| | | |--<phone number>*
| | ... | | ...
| |--<maximum-user-count> | |--<maximum-user-count>
| | ... | | ...
| |--!<available-media> | |--<available-media>
| | |--!<entry> | | |--!<entry>
| | | |--<type> | | | |--<type>
| | | |--<display-text> | | | |--<display-text>
| | | |--<status> | | | |--<status>
| | | |--<mixing-mode>* | | | |--<mixing-mode>*
| | | |--<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>*
| | | |--<codecs>* | | | |--<codecs>*
| | | | |--<entry>* | | | | |--<entry>*
| | | | |--<entry>* | | | | |--<entry>*
| | | | ... | | | | ...
| | | |--<controls>* | | | |--<controls>*
| | | | |--<pause-video>* | | | | |--<pause-video>*
| | | | |--<video-layout>* | | | | |--<video-layout>*
| | | | ... | | | | ...
| | ... | | ...
| |
|--<host-info> |--<host-info>
| |--<display-text> | |--<display-text>
| |--<web-page> | |--<web-page>
| |--!<uris> | |--<uris>
| | |--!<entry> | | |--<entry>
| | | |--!<uri> | | | |--<uri>
| | | |--<display-text> | | | |--<display-text>
| | |--<H323>*
| | | |--<H.323-alias>*
| | | |--<H.323-URI>*
| | |--<PSTN-ISDN>*
| | | |--<phone number>*
| ... | ...
|--<conference-state> |--<conference-state>
| |--<allow-conference-event-subscription>* | |--<allow-conference-event-subscription>*
| |--<user-count> | |--<user-count>
| |--!<active> | |--<active>
| |--<locked> | |--<locked>
| |
|--<floor-information>* |--<floor-information>*
| |--<conference-ID>* | |--<conference-ID>*
| |--<allow-floor-events>* | |--<allow-floor-events>*
| |--<floor-request-handling>* | |--<floor-request-handling>*
| |--<conference-floor-policy>* | |--<conference-floor-policy>*
| | |--<floor>* | | |--<floor>*
| | | |--<media-types>* | | | |--!<media-label>*
| | | |--<algorithm>* | | | |--!<algorithm>*
| | | |--<max-floor-users>* | | | |--<max-floor-users>*
| | | |--<chair-id>* | | | |--<moderator-id>*
| | | |--<chair-id>*
| | | ... | | | ...
| | ... | | ...
| |
|--!<users> |--!<users>
| |--<join-handling>* | |--<join-handling>*
| |--<user-admission-policy>* | |--<user-admission-policy>*
| |--<allowed-users-list>* | |--<allowed-users-list>*
| | |--<target>* | | |--<target>*
| | |-- ... | | |-- ...
| | | |
| | | |
| |--!<user> | |--<user>
| | |--<display-text> | | |--<display-text>
| | |--<associated-aors> | | |--<associated-aors>
| | |--<provide-anonymity>* | | |--<provide-anonymity>*
| | |--<roles> | | |--<roles>
| | | | | | | |
| | | ... | | | ...
| | |--<languages> | | |--<languages>
| | |--<cascaded-focus> | | |--<cascaded-focus>
| | |--<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>*
skipping to change at page 13, line 40 skipping to change at page 12, line 39
| | |-- <display-text> | | |-- <display-text>
| ... | ...
|--<sidebars-by-val> |--<sidebars-by-val>
| |--<entry> | |--<entry>
| | | | | |
| | ... | | ...
| |--<entry> | |--<entry>
| | | | | |
| ... ... | ... ...
Figure 3: Non-normative diagram
The following sections describe these elements in detail. The full The following sections describe these elements in detail. The full
Relax NG schema is provided Section 5. Relax NG schema is provided Section 5.
4.1. <conference-description> 4.1. <conference-info>
The <conference-description> element, which is defined in [1], A conference object document begins with the root element tag
describes the conference as a whole. It SHOULD have an extra <conference-info>, which is defined in RFC4575 [1]. The <conference-
attribute 'xml:lang' to specify the language used in the contents of info> attributes are described in RFC4575 [1]. Notice that the
this element as defined in Section 2.12 of [8]. It is comprised of <conference-info> element does not have the attributes 'state' and
<display-text>, <subject>, <free-text>, <keywords>, <allow-sidebars>, 'version' defined in RFC4575[1] for this element because this
<conference-time>, <conf-uris>, <service-uris>, <maximum-user-count>, attribute only applies to notifications mechanism. RFC4575 [1]
and <available-media>. defines as well an 'entity' attribute that contains the conference
object identifier (XCON-URI) that identifies the conference being
described in the document.
The <display-text>, <subject>, <free-text> and <keywords> elements The <conference-info> element contains the <conference-description>,
are defined in [1]. They are used to describe the conference's <host-info>, <conference-state>, <floor-information>, <users>,
content. <sidebars-by-ref>, and <sidebars-by-val> child elements. All these
elements, except <floor-information>, are defined in [1]. A
conference document MUST at least include the <conference-
description> and <users> child elements.
The child element <allow-sidebars> describes the capabilities of the 4.2. <conference-description>
conference.
The <conference-time> child element contains information related to The <conference-description> element, which is defined in RFC4575
conference time and duration of the conference. The <conf-uris> and [1], describes the conference as a whole. It should have an extra
<service-uris> are used to describe the conference-related attribute 'lang' to specify the language used in the contents of this
identifiers. The <maximum-user-count> child element indicates the element. It is comprised of <display-text>, <subject>, <free-text>,
number of users that can be invited to the conference. The <keywords>, <allow-sidebars>, <conference-time>, <conf-uris>,
<available-media> child element is used to describe the media <service-uris>, <maximum-user-count>, and <available-media>.
characteristics of the conference.
The following sections describe these elements in more detail. Other The following sections describe these elements in more detail. Other
child elements MAY be defined in the future to extend the child elements MAY be defined in the future to extend the
<conference-description> element. <conference-description> element.
4.1.1. <conference-time> 4.2.1. <display-text>
The <display-text> element is described in section 5.3 of RFC 4575
[1].
4.2.2. <subject>
The <subject> element is described in section 5.3 of RFC 4575 [1].
4.2.3. <free-text>
The <free-text> element is described in section 5.3 of RFC 4575 [1].
4.2.4. <keywords>
The <keywords> element is described in section 5.3 of RFC 4575 [1].
4.2.5. <allow-sidebars>
The <allow-sidebars> element represents a boolean action. If set to
TRUE, the conference is allowed to create sidebar conferences.
4.2.6. <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 specifying a single conference occurrence. information specifying a single conference occurrence.
Every <entry> element contains a <mixing-start-offset> child element Every <entry> element contains the following child elements:
that specifies when conference media mixing starts before the
conference starts, <mixing-end-offset> child element that specifies
the time a conference media mixing stops after the conference stops.
The <mixing-end-offset> child element expresses the offset as signed
integers representing seconds before/after DTEND field. The <mixing-
start-offset> child element expresses the offset as signed integers
representing seconds before/after DTSTART field. If the <mixing-
start-offset> element is not present, it indicates that the
conference media mixing starts immediately. If the <mixing-end-
offset> element is not present, it indicates that the conference
occurrence is not bounded. <mixing-start-offset> and <mixing-end-
offset> elements both have the mandatory 'require-participant'
attribute. This attribute has one of 4 values: "none",
"administrator", "moderator", and "participant". For <mixing-start-
offset>, this attribute allows a privileged user to define when media
mixing starts based on the latter of the mixing start time, and the
time the first participant, administrator, or moderator arrives. If
the value is set to "none'", mixing starts according to the mixing
start time. For <mixing-end-offset>, this attribute allows a
privileged user to define when media mixing ends based on the earlier
of the <mixing-end-offset>, and the time the last participant, or
moderator leaves. If the value is set to "none", mixing stops
according to the <mixing-end-offset>. If the conference policy was
modified so that last privileged user is now a normal conference
participant, and the conference requires a privileged user to
continue; that conference MUST terminate.
An administrator can indicate the time when users can join a
conference by populating the <can-join-after-offset> element.
Similarly, an administrator can define the time after which new users
are not allowed to join the conference anymore. This is done by
populating the <must-join-before-offset> element expressing the
offset as signed integers representing seconds before/after DTSTART
field.
The <base> child element specifies the iCalendar object of the
conference. The iCalendar object components are defined in [3].
The <entry> element also contains the <request-user> child element. o <base>: The <base> child element specifies the iCalendar object of
It is possible to define the time when users or resources on the the conference. The iCalendar object components are defined in
<allowed-users-list> is requested to join the conference by using the RFC 2445 [3].
<request-users> element. This element expresses the offset as signed o <mixing-start-offset>: The <mixing-start-offset> child element
integers representing seconds before/after DTSTART field. specifies when the conference media mixing starts before the
conference starts. The <mixing-start-offset> child element
expresses the offset as signed integers representing seconds
before/after the iCalendar DTSTART field [3]. If the <mixing-
start-offset> element is not present, it indicates that the
conference media mixing starts immediately. The <mixing-start-
offset> has the mandatory 'required-participant' attribute. This
attribute has one of 4 values: "none", "administrator",
"moderator", and "participant". This attribute allows a
privileged user to define when media mixing starts based on the
latter of the mixing start time, and the time the first
participant, administrator, or moderator arrives. If the value is
set to "none'", mixing starts according to the mixing start time.
o <mixing-end-offset>: The <mixing-end-offset> child element that
specifies the time a conference media mixing stops after the
conference stops. The <mixing-end-offset> child element expresses
the offset as signed integers representing seconds before/after
the iCalendar DTEND field [3]. If the <mixing-end-offset> element
is not present, it indicates that the conference occurrence is not
bounded. The <mixing-end-offset> elements both have the mandatory
'required-participant' attribute. This attribute has one of 4
values: "none", "administrator", "moderator", and "participant".
This attribute allows a privileged user to define when media
mixing ends based on the earlier of the <mixing-end-offset>, and
the time the last participant, or moderator leaves. If the value
is set to "none", mixing stops according to the <mixing-end-
offset>. If the conference policy was modified so that last
privileged user is now a normal conference participant, and the
conference requires a privileged user to continue; that conference
MUST terminate.
o <can-join-after-offset>: An administrator can indicate the time
when users can join a conference by populating the <can-join-
after-offset> element.
The <notify-end-of-conference> element defines in seconds when the o <must-join-before-offset>: An administrator can define the time
system has to send a notification when the end of the conference is after which new users are not allowed to join the conference
approaching. If the <notify-end-of-conference> element is not anymore. This is done by populating the <must-join-before-offset>
present, it indicates that the system does not notify the users when element expressing the offset as signed integers representing
the end of the conference is approaching. The <notify-end-of- seconds before/after DTSTART field.
conference> child element expresses the offset as signed integers o <request-user>: It is possible to define the time when users or
representing seconds before/after DTSTART field. The <allowed- resources on the <allowed-users-list> are requested to join the
extend-mixing-end-offset> refers to the possibility to extend the conference by using the <request-users> element. This element
conference. It has two values: "allowed", "denied". expresses the offset as signed integers representing seconds
before/after DTSTART field.
o <notify-end-of-conference>: The <notify-end-of-conference> element
defines in seconds when the system has to send a notification when
the end of the conference is approaching. If the <notify-end-of-
conference> element is not present, it indicates that the system
does not notify the users when the end of the conference is
approaching. The <notify-end-of-conference> child element
expresses the offset as signed integers representing seconds after
DTSTART field.
o <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing-
end-offset> refers to the possibility to extend the conference.
It has a boolean value.
4.1.2. <conf-uris> 4.2.7. <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. The <conf-uris>
sequence of child elements: <entry>, <H.323>, and <PSTN-ISDN>. The element is described in section 5.3.1 of RFC 4575[1]. Future
<entry> element refers to the SIP protocol. It keeps the same name extensions to this schema may define new values and register them
that is defined in [1] to maintain backwards compatibility with this with IANA.
RFC. The <entry> element contains the <uri>, <display-text>, and
<purpose> which are described in [1]. 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
describes to the user which phone number to use. The <PSTN-ISDN>
element may include one or more <phone number> child elements.
4.1.3. <service-uris> 4.2.8. <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: <entry>, conference. The <service-uris> element is described in section 5.3.2
<H.323>, and <PSTN-ISDN>. The <entry> child element contains <uri>, of RFC4575[1]. Future extensions to this schema may define new
<display-text>, and <purpose>. The purpose will be used to describe values and register them with IANA.
the service. The currently defined <purpose> values to be used with
the <service-uris> are:
o web-page: Indicates the web page containing the additional
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 [1]. <H.323>, and
<PSTN-ISDN> child elements are described in the <conf-uris> section.
4.1.4. <maximum-user-count> 4.2.9. <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. Note that this value is set by an to join the conference. Note that this value is set by an
administrator and can reflect any local policies such as network administrator and can reflect any local policies such as network
consumption, CPU processing power, and licensing rules. consumption, CPU processing power, and licensing rules.
4.1.5. <available-media> 4.2.10. <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. The attribute
contains a sequence of <entry> child elements of conference-medium- 'label' is described in RFC 4575 [1], section 5.3.4. The <available-
type. Each <entry> element contains the <type>, <display-text>, media> element contains a sequence of <entry> child elements. Each
<status>, <mixing-mode>, <mix-level>, <controls> and <codecs> child <entry> element contains the following child elements:
elements. The attribute 'label' and the <type>, <display-text>, and
<status> elements are described in [1]. The <codecs> element
specifies the allowed codecs in the conference. It has an attribute
'decision' that specifies if the focus decides the common codec
automatically or needs the approval of the moderator of the
conference ("automatic", "moderator-controlled"). The <codecs>
element contains <entry> elements. A <entry> element can have the
attribute 'name' and 'policy'. The 'name' attribute identifies a
codec, and the 'decision' attribute contains the policy for that
codec (allowed, or disallowed).
The child elements <mixing-mode> and <mix-level> describe a default
policy by which the mixer will build the outgoing stream from the
incoming streams. Notice that this policy is different than the
policy describing the floors for each media. The <mix-level> child
element describes the number of participants in audio media streams
or the number of sub-windows in video media streams (for instance, a
value of "4" in the <mix-level> element for video streams implies a
2x2 layout). The <mixing-mode> child element MUST contain one and
only one of the "Moderator-controlled", "FCFS", and "Automatic"
values indicating the default algorithm to be use with every media
stream. The next section explains the <controls> child element.
4.1.5.1. <controls>
The <controls> element contains the basic audio and video global
controls for a conference. It is expected that for the majority of
the basic conferences, these controls are sufficient. If the
conference server wants to support more advanced controls, then it is
recommended that an extension of the data model be used. In the
<controls> element the schema is extensible, hence new control types
can be added in the future. Similarly, controls that apply to a
specific user would appear under the <users>/<user>/<endpoint>
element. So moderator controls that affect all media output would go
under the <available-media> element.
4.1.5.1.1. mute
The 'mute' control is used in conjunction with an audio stream to
cease transmission of associated media. It has a "boolean" value.
If this control is not specified, access to the control is not
available to the client and media SHOULD NOT be transported for the
associated media stream.
4.1.5.1.2. pause-video
The 'pause-video' control is used in conjunction with a video stream
to cease transmission of associated media. It has a "boolean" value.
If this control is not specified, access to the control is not
available to the client and media SHOULD NOT be transported for the
associated media stream.
4.1.5.1.3. gain
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
"int" number value. If this control is not specified, access to the
control is not available to the client.
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 o The <type> element is described in section 5.3.4 of RFC 4575 [1].
participants in one panel. o The <display-text> element is described in section 5.3.4 of RFC
4575 [1].
o The <status> element is described in section 5.3.4 of RFC 4575
[1].
o The child element <mixing-mode> describes a default policy by
which the mixer will build the outgoing stream from the incoming
streams. Notice that this policy is different than the policy
describing the floors for each media. The <mixing-mode> child
element MUST contain one and only one of the "Moderator-
controlled", "FCFS", and "Automatic" values indicating the default
algorithm to use with every media stream. The "Moderator-
controlled" value indicates that the moderator of the conference,
controls the media stream policy. The "FCFS" value indicates a
'first-come-first-served' policy.
o The <codecs> element specifies the allowed codecs in the
conference. It has an attribute 'decision' that specifies if the
focus decides the common codec automatically or needs the approval
of the moderator of the conference ("automatic", "moderator-
controlled"). The <codecs> element contains <entry> elements. A
<entry> element can have the attribute 'name' and 'policy'. The
'name' attribute identifies a codec. The list of possible codecs
accepted as a 'name' attribute is defined by the IANA registry for
RTP Payload Types. The possible values of the attribute 'name'
are the values of the 'subtype' column of the RTP Payload Format
media types per RFC4855[9] defined in IANA [10]. The 'policy'
attribute contains the policy for that codec (allowed, or
disallowed).
o The <controls> element contains the basic audio and video global
control elements for a conference. It is expected that for the
majority of the basic conferences, these controls are sufficient.
If the conference server wants to support more advanced controls,
then it is recommended that an extension to the data model be
used. In the <controls> element the schema is extensible, hence
new control types can be added in the future. So moderator
controls that affect all media output would go under the
<available-media> element. The following controls elements are
defined for <controls>:
* The <mute> element is used in conjunction with an audio stream
to cease transmission of associated media. That means that for
the entire duration where mute is applicable, all current and
future participants of the conference are muted and will not
receive any audio. It has a "boolean" value. If this control
is not specified, access to the control is not available to the
client.
* The <pause-video> element is used in conjunction with a video
stream to cease transmission of associated media. It has a
"boolean" value. If this control is not specified, the access
to the control is not available to the client.
* The <gain> element is used in conjunction with a media output
stream to indicate the amount of amplification of an audio
stream. It has an "int" number value. This control has two
attributes that defines the minimum and maximum amplification
levels: 'min' and 'max'. If this control is not specified,
access to the control is not available to the client.
* The <video-layout> element is used in conjunction with a video
stream to specify how the video streams (of 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, although any number of custom layouts may be
specified in future extensions:
+ 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.
dual-view: This dual view option will present the video side-by-side + multiple-4x4: Sixteen equal-sized panels in a 4x4 layout is
in 2 panels and not alter the aspect ratio of the streams. This will presented by the focus to all participants. Typically the
require the focus to introduce blanking on parts of the overall image aspect ratio of the streams are preserved.
as viewed by the participants. + 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.
dual-view-crop: This side-by-side layout option instructs the focus 4.3. <host-info>
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 The <host-info> element contains information about the entity hosting
stream above the other, in essence with two rows and one column. In the conference. This information is set before conference
this option the aspect ratio is not altered and blanking is activation, and is rarely changed during the conference lifetime.
introduced. The <host-info> element and its child elements are described in
RFC4575[1], section 5.4. Future extensions to the <host-info>
element may define new values.
dual-view-2x1-crop: This layout option also instructs the focus to 4.4. <conference-state>
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 <conference-state> is introduced in RFC4575 [1]. The
the focus to all participants. Typically the aspect ratio of the <conference-state> element contains the <allow-conference-event-
streams are maintained (alter-aspect-ratio= FALSE). subscription>, <user-count>, <active>, and <locked> child elements.
multiple-3x3: Nine equal-sized panels in a 3x3 layout is presented by 4.4.1. <allow-conference-event-subscription>
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 The <allow-conference-event-subscription> element represents a
by the focus to all participants. Typically the aspect ratio of the boolean action. If set to TRUE, the focus is instructed to allow the
streams are preserved. subscription to conference state events, such as RFC4575 'SIP Event
Package for Conference State' [1]. If set to FALSE, the subscription
to conference state events would be rejected. If this element is
undefined it has a default value of TRUE, causing the subscription to
conference state events to be accepted.
multiple-5x1: This option refers to a 5x1 layout where one panel will 4.4.2. <user-count>
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 The <user-count> child element is explained in RFC 4575 [1], section
added up to a limit of "panels". 5.5.1.
4.2. <host-info> 4.4.3. <active>
The <host-info> element contains information about the entity hosting The <active> child element is explained in RFC 4575 [1], section
the conference. This information is set before the conference 5.5.2.
activation, and is rarely changed during the conference lifetime.
The <host-info> element contains the <display-text>, <web-page> and
<uris> child elements. The <display-text> and <web-page> child
elements are explained in [1]. 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 [1] to maintain backwards compatibility with this
RFC. Future extensions to the <uris> element may define new values.
4.3. <conference-state> 4.4.4. <locked>
The <conference-state> element and the <user-count>, <active>, and The <locked> child element is explained in RFC 4575 [1], section
<locked> child elements are explained in section 5.5 of [1]. The 5.5.3.
<allow-conference-event-subscription> element represents a boolean
action. If set to TRUE, the focus is instructed to allow the
subscription to conference state events, such as the SIP Event
Package for Conference State [1]. If set to FALSE, the subscription
to conference state events would be rejected. If this element is
undefined it has a default value of TRUE, causing the subscription to
conference state events to be accepted.
4.4. <floor-information> 4.5. <floor-information>
The <floor-information> element has the <conference-ID>, <allow- The <floor-information> element contains the <conference-ID>, <allow-
floor-events>, <floor-request-handling>, and <conference-floor- floor-events>, <floor-request-handling>, and <conference-floor-
policy> child elements. Other elements from different namespaces MAY policy> child elements. Other elements from different namespaces MAY
be present for the purposes of extensibility. This element has its be present for the purposes of extensibility. The absence of this
own XML namespace. The absence of this namespace and its elements element from an XML document indicates that the conference does not
from an XML document indicates that the conference does not have a have a floor.
floor.
The <conference-ID> is used by a floor control server to provide a 4.5.1. <conference-ID>
client with a conference ID.
The <conference-ID> is a 32-bit BFCP conference identifier defined in
RFC4582 [5] section 5.1. that identifies the BFCP conference the
message belongs to. This identifier represents a conference instance
within floor control. When created within the conferencing system,
the 'conference-ID' has a 1:1 mapping to the unique conference object
Identifier (XCON-URI).
4.5.2. <allow-floor-events>
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 default the subscription. If this element is undefined, it has a default
value of FALSE, causing the subscription to floor control events to value of FALSE, causing the subscription to floor control events to
be rejected. be rejected.
There are two methods which a conference participant subscribes
himself to a floor control event. One method is using an offer/
answer exchange mechanism (RFC3264 [11]) using SIP INVITE and BFCP
parameters in the SDP (RFC4583 [12]). The other method is a general
authorization mechanism described in section 9 of RFC4582 [5] and in
RFC5018 [13]. Future documentation may define additional connection
mechanisms.
4.5.3. <floor-request-handling>
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 o "block": This action instructs the focus to deny the floor
request. This action is the default action taken in the absence request. This action is the default action taken in the absence
of any 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
or 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 this section discusses floor control information,
guarantee that a participant is blocked from joining the conference. therefore, the value "block" in a <floor-request-handling> element is
Any other rule that might evaluate to TRUE for this participant that not related with the "block" value in the <join-handling> element
carried an action whose value was higher than "block" would (see Section 4.6).
automatically grant confirm/allow permission to that participant.
The <conference-floor-policy> element is mandatory and contains the 4.5.4. <conference-floor-policy>
required boolean attribute that indicates if the floor is moderator
controlled or not. One or more <floor> elements can appear in the
<conference-floor-policy> element. Every floor is defined using the
'label' attribute. If the <available-media> information is included
in the conference document, the value of this attribute MUST be equal
to the 'label' value of the corresponding media stream <entry> in the
<available-media> container. The number of those elements indicates
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
zero or more of the <video>, <audio>, <application>, <data>
,<control>, <message>, and <text> elements indicating the media of
the floor. One type of media can only appear once. Other media
types can be defined by extensions.
A floor can be controlled using many algorithms; the mandatory The <conference-floor-policy> element is mandatory. One or more
<algorithm> element MUST contain one and only one of the <moderator- <floor> elements can appear in the <conference-floor-policy> element.
controlled>, <FCFS>, and <random> elements indicating the algorithm.
The <max-floor-users> child element in the <floor> element is Each <floor> element has the following child elements:
optional and, if present, dictates the maximum number of users who
can have the floor at one time. The optional <chair-id> indicates
the BFCP UserID of the moderator. It MUST be set if the attribute
moderator-controlled is set to TRUE.
4.5. <users> o <media-label>: Every floor is identified for one or more mandatory
<media-label> element. If the <available-media> information is
included in the conference document, the value of this element
MUST be equal to the 'label' value of the corresponding media
stream <entry> in the <available-media> container. The number of
those elements indicates how many floors the conference can have.
A floor can be used for one or more media types;
o <algorithm>: A floor can be controlled using many algorithms; the
mandatory <algorithm> element MUST be set to any of the
"moderator-controlled", "FCFS" or "random" values indicating the
algorithm. The "Moderator-controlled" value indicates that the
moderator of the conference controls the floor. The "FCFS" value
states for 'first-come-first-served' floor control.
o <max-floor-users>: The <max-floor-users> child element in the
<floor> element is optional and, if present, dictates the maximum
number of users who can have the floor at one time.
o <moderator-id>: The optional <moderator-id> indicates the 'User
ID' of the moderator. The 'User ID' is a BFCP identifier defined
in RFC4582 [5] section 5.1. It MUST be set if the element
<algorithm> is set to "Moderator-controlled" value. Note that
RFC4582 [5] refers to the moderator role as a 'floor chair'.
The <users> element contains the <join-handling>, <user-admission- 4.6. <users>
policy>, <allowed-users-list>, and <user> child elements.
The <users> element is described in RFC4575 [1] and contains the
<join-handling>, <user-admission-policy>, and <allowed-users-list>
defined in this document and <user> child elements defined in
RFC4575[1]. Notice that the <users> element does not have the
attribute 'state' defined in RFC4575[1] for this element because this
attribute only applies to notifications mechanism. The following
sections describe these elements in more detail. Other child
elements and attributes can be used to extend <users> in the future.
4.6.1. <join-handling>
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 o "confirm": This action instructs the focus to place the
participant on a pending list (e.g., by parking the call on a participant on a pending list (e.g., by parking the call on a
music-on-hold server), awaiting moderator input for further music-on-hold server), awaiting moderator input for further
actions. actions.
o "allow": This action instructs the focus to accept the conference 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 o "authenticate": This action instructs the focus that the user has
provide the PIN code. to provide a combination of username/password.
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 4.6.2. <user-admission-policy>
guarantee that a participant is blocked from joining the conference.
Any other rule that might evaluate to TRUE for this participant that
carried an action whose value was higher than "block" would
automatically grant confirm/allow permission to that participant.
The <user-admission-policy> is an element that lets an organizer (or The <user-admission-policy> is an element that lets an organizer (or
a participant with appropriate rights) choose a policy for the a participant with appropriate rights) choose a policy for the
conference that controls how users are allowed into the conference. conference that controls how users are allowed into the conference.
A 'closedAuthenticated' policy requires each conference participant The list of possible values are:
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 o "closedAuthenticated": A 'closedAuthenticated' policy requires
detail. Other child elements can be used to extend <conference- each conference participant to be in the allowed users list
description> in the future. (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.
o "openAuthenticated": 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.
4.5.1. <allowed-users-list> o "anonymous": An 'anonymous' policy allows any join requests in and
is the least restrictive policy.
4.6.3. <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 be invited to uses to determine who can join the conference, who can be invited to
join a conference, or who the focus needs to "refer to" the join a conference, or who the focus needs to "refer to" the
conference. The <allowed-users-list> element includes zero or more conference. The <allowed-users-list> element includes zero or more
<target> child elements. This child element includes the mandatory <target> child elements. This child element includes the mandatory
'uri' attribute and the mandatory 'method' attribute. The same 'uri' 'uri' attribute and the mandatory 'method' attribute. The same 'uri'
attribute with different method values can appear in the list more attribute with different method values can appear in the list more
than once. The 'method' attribute is a list with the following than once.
values: "dial-in", "dial-out", and "refer". The value "dial-in" is
used by the focus to determine who can join the conference. The
value "refer" is used by the focus to determine the resources that
the focus needs to "refer to" the conference. In SIP, this is
achieved by the focus sending a REFER request to those potential
participants. In a different paradigm, this could also mean that the
focus sends an SMS or an email to the referred user. This list can
be updated during the conference lifetime so it can be used for mid-
conference refers as well.
The "refer" value differs from the "dial-out" in that the "dial-out" The 'method' attribute is a list with the following values:
contains a list of resources that the focus will initiate a session
with. The resources on the "refer" value, on the other hand, are
expected to initiate the session establishment toward the focus
themselves. It is also envisioned that difference users will have
different access rights to those lists and therefore a separation
between the two is needed.
4.5.2. <user> o "dial-in": The value "dial-in" is used by the focus to determine
who can join the conference.
o "dial-out": The value "dial-out" contains a list of resources that
the focus will initiate a session with.
o "refer": The value "refer" is used by the focus to determine the
resources that the focus needs to "refer to" the conference. In
SIP, this is achieved by the focus sending a REFER request to
those potential participants. In a different paradigm, this could
also mean that the focus sends an SMS or an email to the referred
user. This list can be updated during the conference lifetime so
it can be used for mid-conference refers as well.
The element <user> describes a single participant in the conference. The "refer" value differs from the "dial-out" in that the resources
on the "refer" value are expected to initiate the session
establishment toward the focus themselves. It is also envisioned
that different users will have different access rights to those lists
and therefore a separation between the two is needed.
The following elements of <user> are defined in [1], section 5.6: 4.6.4. <user> and Its <user> Sub-elements
<display-text>, <associated-aors>, <roles>, <languages>, <cascaded-
focus>, and <endpoint>. <user> has two attributes: 'entity' and The element <user> is described in RFC5475[1] and describes a single
'state'. The attribute 'state' is defined in [1], section 5.6. The participant in the conference. The <user> element has an attribute
attribute 'entity' contains a unique conference user identifier. 'entity'. Notice that the <user> element does not have the attribute
Other user identifiers can be associated with this conference user 'state' defined in RFC4575[1] for this element because this attribute
identifier and enable the conferencing system to correlate and map only applies to notifications mechanism.
these multiple authenticated user identities to a single global user
identifier. Figure 4 illustrates an example using the conference o The attribute 'entity' contains a unique conference user
user identifier in association with the user identity defined for identifier (XCON_USERID). Other user identifiers can be
BFCP, SIP, and H323 user identity. It should be noted that a 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.
Figure 4 illustrates an example using the conference user
identifier in association with the user identity defined for BFCP,
SIP, and H323 user identity. It should be noted that a
conferencing system is free to structure such relationships as conferencing system is free to structure such relationships as
required and this information is just included as a guideline that required and this information is just included as a guideline that
can be used. can be used.
+--------------+ +--------------+
| Conference | | Conference |
| User | | User |
| Identifier | | Identifier |
+--------------+ +--------------+
| John | | John |
skipping to change at page 23, line 33 skipping to change at page 23, line 32
+---------------------+---------------------+ +---------------------+---------------------+
| | | | | |
+-------+--------+ +-------+-------+ +--------+-------+ +-------+--------+ +-------+-------+ +--------+-------+
| BFCP User ID | | SIP User ID | | H323 User ID | | BFCP User ID | | SIP User ID | | H323 User ID |
+----------------+ +---------------+ +----------------+ +----------------+ +---------------+ +----------------+
| HK37ihdaj | | 123674 | | 928373 | | HK37ihdaj | | 123674 | | 928373 |
+----------------+ +---------------+ +----------------+ +----------------+ +---------------+ +----------------+
Figure 4: Conference Object Mapping Figure 4: Conference Object Mapping
The element <user> element contains the <display-text>, <associated-
aors>, <provide-anonymity>, <roles>, <languages>, <cascaded-focus>,
<allow-refer-users-dynamically>, <allow-invite-users-dynamically>,
<allow-remove-users-dynamically>, and <endpoint>. The following
sections describe these elements in more detail.
4.6.4.1. <display-text>
The <display-text> child element is explained in RFC 4575 [1],
section 5.6.1.
4.6.4.2. <associated-aors>
The <associated-aors> child element is explained in RFC 4575 [1],
section 5.6.2.
4.6.4.3. <provide-anonymity>
The <provide-anonymity> element provides anonymity to the user. In The <provide-anonymity> element provides anonymity to the user. In
this case, the focus provides to the rest of the participants an this case, the focus provides to the rest of the participants an
anonymous identity for that user, for example anonymousX. This anonymous identity for that user, for example anonymousX. This
element only affects the way the user information is shown to the element only affects the way the user information is provided to the
oher participants. The real information about the user is still other participants. The real information about the user is still
stored in the data model. This can be achieved by using the stored in the data model. This can be achieved by using the
<provide-anonymity> element. It is a boolean transformation. If set <provide-anonymity> element. It is a boolean transformation. If set
to TRUE, the conference participants will see an anonymous identity to TRUE, the conference participants will see an anonymous identity
for the user whose identity is present in the conditions. for the user.
The <endpoint> child element can provide the desired level of detail 4.6.4.4. <roles>
about the user's devices and their signaling sessions taking part in
the conference and has the following child elements defined in RFC
4575 [1]: <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.
4.5.2.1. <from-mixer>, <to-mixer> The <roles> child element is explained in RFC 4575 [1], section
5.6.3.
Similar to the controls defined in the <available-media> element, 4.6.4.5. <languages>
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.
Each of these elements have the <floor> and <controls> child The <languages> child element is explained in RFC 4575 [1], section
elements. 5.6.4.
4.5.2.1.1. <floor> 4.6.4.6. <cascaded-focus>
The <floor> element describes a floor that joins this participant in The <cascaded-focus> child element is explained in RFC 4575 [1],
the conference. If a participant, for instance, needs to talk in the section 5.6.5.
conference, it first needs to get the floor from the chair of the
conference.
The <floor> element has a "Boolean" value. A value of FALSE 4.6.4.7. <allow-refer-users-dynamically>
indicates that this user does not hold the floor in this moment. If
this control is not specified, this user SHOULD NOT specify the floor The <allow-refer-users-dynamically> element represents a boolean
action. If set to TRUE, a participant is allowed to instruct the
focus to refer a user to the conference without modifying the
<allowed-users-list> (in SIP terms, a participant is allowed to send
a REFER request to the focus which results in the focus sending a
REFER request to the user the referrer wishes to join the
conference). If set to FALSE, the refer request is rejected. If
this element is undefined it has a value of FALSE, causing the refer
to be rejected.
4.6.4.8. <allow-invite-users-dynamically>
The <allow-invite-users-dynamically> element represents a boolean
action. If set to TRUE, a participant is allowed to instruct the
focus to invite a user to the conference without modifying the
<allowed-users-list> list (in SIP terms, a participant 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.
4.6.4.9. <allow-remove-users-dynamically>
The <allow-remove-users-dynamically> element represents a boolean
action. If set to TRUE, a participant is allowed to instruct the
focus to remove a user from the conference without modifying the
ruleset (in SIP terms, a participant 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.
4.6.4.10. <endpoint>
The <endpoint> child element is defined in RFC4575[1]. It can
provide the desired level of detail about the user's devices and
their signaling sessions taking part in the conference and has the
following child elements defined in RFC4575 [1]: <display-text>,
<referred>, <status>, <joining-method>, <joining-info>,
<disconnection-method>, <disconnection-info>, <media>, and <call-
info>. Notice that the <endpoint> element does not have the
attribute 'state' defined in RFC4575[1] for this element because this
attribute only applies to notifications mechanism.
Besides the <endpoint>/<media> child elements defined in RFC 4575[1],
the <endpoint>/<media> element has two other child elements: <to-
mixer>, and <from-mixer> described in the following list:
o <from-mixer>, <to-mixer>: These are controls that apply to a
user's media stream being sent from the mixer to the participants
endpoint or to the mixer from the participants endpoint. The <to-
mixer> element details properties associated with the incoming
streams to the mixer (streams sent to the mixer from the
participant). The <from-mixer> element details properties
associated with the outgoing streams from the mixer (sent from the
mixer to the participant). 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. Each of these elements have the <floor> and
<controls> child elements:
* The <floor> element describes a floor that joins this
participant in the conference. If a participant, for instance,
needs to talk in the conference, it first needs to get the
floor from the chair of the conference. The <floor> element
has a "Boolean" value. A value of FALSE indicates that this
user does not hold the floor in this moment. If this control
is not specified, this user SHOULD NOT specify the floor
option. option.
* Controls that apply to a specific user would appear under the
<controls> element.
4.5.3. <sidebars-by-ref> 4.7. <sidebars-by-ref>
The <sidebars-by-ref> element contains a set of <entry> child The <sidebars-by-ref> element contains a set of <entry> child
elements. Each <entry> child element contains a <user> child element elements. This element is described in RFC4575 [1], 5.9.1. Notice
with a sidebar unique conference user identifier and a <display-text> that the <sidebars-by-ref> element does not have the attribute
child element. 'state' defined in RFC4575[1] for this element because this attribute
only applies to notifications mechanism.
4.5.4. <sidebars-by-val> 4.8. <sidebars-by-val>
The <sidebars-by-val> element contains a set of <entry> child The <sidebars-by-val> element contains a set of <entry> child
elements each containing information about a single sidebar. By elements each containing information about a single sidebar. This
using this element, the server can include a full or partial element is described in RFC4575 [1], 5.9.2. Notice that the
description of each sidebar (as a sub-conference) in the body of the <sidebars-by-val> element does not have the attribute 'state' defined
main conference document. in RFC4575[1] for this element because this attribute only applies to
notifications mechanism.
5. RELAX NG Schema 5. RELAX NG Schema
In accordance with the XCON framework document [4], the Conference In accordance with the Centralized Conferencing Framework document
Object is a logical representation of a conference instance. The [4], the Conference Object is a logical representation of a
conference information schema contains core information that is conference instance. The conference information schema contains core
utilized in any conference. It also contains the variable information that is utilized in any conference. It also contains the
information part of the Conference Object. variable information part of the Conference Object.
This specification defines some document fragments in RELAX NG This specification defines some document fragments in RELAX NG format
format. [14].
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace local = "" namespace local = ""
namespace ns1 = "urn:ietf:params:xml:ns:conference-info-urn" namespace ns2 = "urn:ietf:params:xml:ns:conference-info"
default namespace ns2 = "urn:ietf:params:xml:ns:conference-schema" default namespace ns1 = "urn:ietf:params:xml:ns:xcon-conference-info"
start = element conference-info { conference-type } start = element conference-info { conference-type }
# CONFERENCE TYPE # CONFERENCE TYPE
conference-type = conference-type =
attribute entity { text }, attribute entity { text },
attribute version { xsd:unsignedInt }?, anyAttribute,
attribute state { state-type }?,
conference-description-type, conference-description-type,
element host-info { host-type }?, element host-info { conference-info-urn* }?,
element conference-state { conference-state-type }?, element conference-state { conference-state-type }?,
element floor-information { floor-information-type }?, element floor-information { floor-information-type }?,
element users { users-type }, element users { users-type },
element sidebars-by-ref { sidebars-by-ref-type }?, element sidebars-by-ref { sidebars-by-ref-type }?,
element sidebars-by-val { sidebars-by-val-type }?, element sidebars-by-val { sidebars-by-val-type }?,
anyElement* anyElement*
# CONFERENCE DESCRIPTION TYPE # CONFERENCE DESCRIPTION TYPE
conference-description-type = conference-description-type =
element conference-description { element conference-description {
attribute xml:lang { xsd:language }?, attribute lang { xsd:language }?,
attribute state { state-type }?, anyAttribute,
element display-text { text }?, element display-text { text }?,
element subject { text }?, element subject { text }?,
element free-text { text }?, element free-text { text }?,
element keywords { element keywords {
list { xsd:string* } list { xsd:string* }
}?, }?,
element allow-sidebars { xsd:boolean }?, element allow-sidebars { xsd:boolean }?,
element conference-time { conferencetime-type }?, element conference-time { conferencetime-type }?,
element conf-uris { uris-type }?, element conf-uris { conference-info-urn* }?,
element service-uris { uris-type }?, element service-uris { conference-info-urn* }?,
element maximum-user-count { xsd:int }?, element maximum-user-count { xsd:int }?,
element available-media { conference-media-type }?, element available-media { conference-media-type }?,
anyElement* anyElement*
} }
# CONFERENCE TIME # CONFERENCE TIME
conferencetime-type = conferencetime-type =
anyAttribute,
element entry { element entry {
element base { text }?, element base { text }?,
element mixing-start-offset { element mixing-start-offset {
xsd:dateTime { pattern = ".+T.+Z.*" }, xsd:dateTime { pattern = ".+T.+Z.*" },
attribute required-participant { single-role-type }, attribute required-participant { single-role-type },
anyAttribute anyAttribute
}?, }?,
element mixing-end-offset { element mixing-end-offset {
xsd:dateTime { pattern = ".+T.+Z.*" }, xsd:dateTime { pattern = ".+T.+Z.*" },
attribute required-participant { single-role-type }, attribute required-participant { single-role-type },
anyAttribute anyAttribute
}?, }?,
element can-join-after-offset { element can-join-after-offset {
xsd:dateTime { pattern = ".+T.+Z.*" } xsd:dateTime { pattern = ".+T.+Z.*" }
}?, }?,
element must-join-before-offset { element must-join-before-offset {
xsd:dateTime { pattern = ".+T.+Z.*" } xsd:dateTime { pattern = ".+T.+Z.*" }
}?, }?,
element notify-end-of-conference { xsd:int }?, element notify-end-of-conference { xsd:int }?,
element allowed-extend-mixing-end-offset { element allowed-extend-mixing-end-offset { xsd:boolean }?,
allowed-extend-mixing-values
}?,
anyElement* anyElement*
}*, }*,
anyElement* anyElement*
# ALLOWED EXTEND MIXING VALUES
allowed-extend-mixing-values =
xsd:string "allowed" | xsd:string "denied"
# URIS TYPE
uris-type =
attribute state { state-type }?,
(element entry { uri-type }*
& element H323 { H323-type }*
& element PSTN-ISDN { PSTN-type }*),
anyElement*
# SIP TYPE
uri-type =
(element uri { xsd:anyURI },
element display-text { text }?,
element purpose { text }?,
anyElement*)*
# H323 TYPE
H323-type =
element H.323-alias { text }?,
element H.323-URI { xsd:anyURI }?,
anyElement*
# PSTN TYPE
PSTN-type =
attribute PIN-code { xsd:unsignedInt },
attribute purpose { xsd:unsignedInt },
(element phone-number { xsd:unsignedInt },
anyElement*)+
# CONFERENCE MEDIA TYPE # CONFERENCE MEDIA TYPE
conference-media-type = conference-media-type =
attribute state { state-type }?, anyAttribute,
element entry { conference-medium-type }*, element entry { conference-medium-type }*,
anyElement* anyElement*
# CONFERENCE MEDIUM TYPE # CONFERENCE MEDIUM TYPE
conference-medium-type = conference-medium-type =
attribute label { text }, attribute label { text },
anyAttribute,
element display-text { text }?, element display-text { text }?,
element type { text }?, element type { text }?,
element status { media-status-type }?, element status { media-status-type }?,
element mixing-mode { mix-mode-type }?, element mixing-mode { mix-mode-type }?,
element mix-level { xsd:unsignedInt }?,
element codecs { codecs-type }?, element codecs { codecs-type }?,
element controls { controls-type }?, element controls { controls-type }?,
anyElement* anyElement*
# CONTROLS TYPE # CONTROLS TYPE
controls-type = controls-type =
attribute state { state-type }?, anyAttribute,
element control { control-type }*, element control { control-type }*,
anyElement* anyElement*
# MIX MODE TYPE # MIX MODE TYPE
mix-mode-type = mix-mode-type =
xsd:string "moderator-controlled" xsd:string "moderator-controlled"
| xsd:string "FCFS" | xsd:string "FCFS"
| xsd:string "automatic" | xsd:string "automatic"
# CODECS TYPE # CODECS TYPE
codecs-type = codecs-type =
attribute decision { decision-type }, attribute decision { decision-type },
anyAttribute,
element codec { codec-type }*, element codec { codec-type }*,
anyElement* anyElement*
# CODEC TYPE # CODEC TYPE
codec-type = codec-type =
attribute name { text }, attribute name { text },
attribute policy { policy-type } attribute policy { policy-type },
anyAttribute
# DECISION TYPE # DECISION TYPE
decision-type = decision-type =
xsd:string "automatic" | xsd:string "moderator-controlled" xsd:string "automatic" | xsd:string "moderator-controlled"
# POLICY TYPE # POLICY TYPE
policy-type = xsd:string "allowed" | xsd:string "disallowed" policy-type = xsd:string "allowed" | xsd:string "disallowed"
# CONTROL TYPE # CONTROL TYPE
control-type = control-type =
element mute { xsd:boolean } anyAttribute,
(element mute { xsd:boolean }
| element pause-video { xsd:boolean } | element pause-video { xsd:boolean }
| element gain { | element gain {
xsd:int { minInclusive = "-127" maxInclusive = "127" } xsd:int { minInclusive = "-127" maxInclusive = "127" }
} }
| element video-layout { | element video-layout {
xsd:string "single-view" xsd:string "single-view"
| xsd:string "dual-view" | xsd:string "dual-view"
| xsd:string "dual-view-crop" | xsd:string "dual-view-crop"
| xsd:string "dual-view-2x1" | xsd:string "dual-view-2x1"
| xsd:string "dual-view-2x1-crop" | xsd:string "dual-view-2x1-crop"
| xsd:string "quad-view" | xsd:string "quad-view"
| xsd:string "multiple-3x3" | xsd:string "multiple-3x3"
| xsd:string "multiple-4x4" | xsd:string "multiple-4x4"
| xsd:string "multiple-5x1" | xsd:string "multiple-5x1"
| xsd:string "automatic" | xsd:string "automatic"
} }
| anyElement* | anyElement*)
# HOST TYPE
host-type =
(element display-text { text },
element web-page { xsd:anyURI },
element uris { uris-type },
anyElement*)*
# CONFERENCE STATE TYPE # CONFERENCE STATE TYPE
conference-state-type = conference-state-type =
anyAttribute,
element allow-conference-event-subscription { xsd:boolean }?, element allow-conference-event-subscription { xsd:boolean }?,
element user-count { xsd:unsignedInt }?, element user-count { xsd:unsignedInt }?,
element active { xsd:boolean }?, element active { xsd:boolean }?,
element locked { xsd:boolean }?, element locked { xsd:boolean }?,
anyElement* anyElement*
# FLOOR INFORMATION TYPE # FLOOR INFORMATION TYPE
floor-information-type = floor-information-type =
anyAttribute,
(element conference-ID { xsd:unsignedInt }, (element conference-ID { xsd:unsignedInt },
element allow-floor-events { xsd:boolean }, element allow-floor-events { xsd:boolean },
element floor-request-handling { floor-request-type }, element floor-request-handling { floor-request-type },
element conference-floor-policy { Conference-floor-policy }, element conference-floor-policy { Conference-floor-policy },
anyElement*)* anyElement*)*
# FLOOR REQUEST TYPE # FLOOR REQUEST TYPE
floor-request-type = xsd:string "block" | xsd:string "confirm" floor-request-type = xsd:string "block" | xsd:string "confirm"
# CONFERENCE FLOOR POLICY # CONFERENCE FLOOR POLICY
Conference-floor-policy = Conference-floor-policy =
anyAttribute,
element floor { element floor {
attribute moderator-controlled { xsd:boolean },
attribute label { text },
anyAttribute, anyAttribute,
(element media-types { element media-label { xsd:nonNegativeInteger }+,
xsd:string "video" (element algorithm {
| xsd:string "audio"
| xsd:string "application"
| xsd:string "data"
| xsd:string "control"
| xsd:string "message"
| xsd:string "text"
},
element algorithm {
xsd:string "moderator-controlled" xsd:string "moderator-controlled"
| xsd:string "FCFS" | xsd:string "FCFS"
| xsd:string "random" | xsd:string "random"
}, },
element max-floor-users { xsd:nonNegativeInteger }, element max-floor-users { xsd:nonNegativeInteger },
element chair-id { xsd:anyURI }, element moderator-id { text },
anyElement*)* anyElement*)*
}+ }+
# USERS TYPE # USERS TYPE
users-type = users-type =
attribute state { state-type }?, anyAttribute,
element join-handling { join-handling-type }?, element join-handling { join-handling-type }?,
element user-admission-policy { user-admission-policy-type }?, element user-admission-policy { user-admission-policy-type }?,
element user-must-be-specified { xsd:boolean }?, element user-must-be-specified { xsd:boolean }?,
element allowed-users-list { UserList }?, element allowed-users-list { UserList }?,
element user { user-type }*, element user { user-type }*,
anyElement* anyElement*
# USERS ADMISSION POLICY # USERS ADMISSION POLICY
user-admission-policy-type = user-admission-policy-type =
xsd:string "closedAuthenticated" xsd:string "closedAuthenticated"
| xsd:string "openAuthenticated" | xsd:string "openAuthenticated"
| xsd:string "anonymous" | xsd:string "anonymous"
# JOIN HANDLING TYPE # JOIN HANDLING TYPE
join-handling-type = join-handling-type =
xsd:string "block" xsd:string "block"
| xsd:string "allow"
| xsd:string "confirm" | xsd:string "confirm"
| xsd:string "IVR" | xsd:string "allow"
| xsd:string "authenticate"
| xsd:string "directed-operator" | xsd:string "directed-operator"
# USERLIST # USERLIST
UserList = UserList =
anyAttribute,
element target { target-type }*, element target { target-type }*,
anyElement* anyElement*
# TARGET TYPE # TARGET TYPE
target-type = target-type =
attribute uri { xsd:anyURI }, attribute uri { xsd:anyURI },
attribute method { method-type } attribute method { method-type },
anyAttribute
# METHOD TYPE # METHOD TYPE
method-type = method-type =
xsd:string "dial-in" | xsd:string "dial-out" | xsd:string "refer" xsd:string "dial-in" | xsd:string "dial-out" | xsd:string "refer"
# USER TYPE # USER TYPE
user-type = user-type =
attribute entity { xsd:anyURI }, attribute entity { xsd:anyURI },
attribute state { state-type }?, anyAttribute,
element display-text { text }?, element display-text { text }?,
element associated-aors { uris-type }?, element associated-aors { conference-info-urn* }?,
element provide-anonymity { xsd:boolean }?, element provide-anonymity { xsd:boolean }?,
element roles { roles-type }?, element roles { text }?,
element languages { element languages {
list { xsd:language } list { xsd:language }
}?, }?,
element cascaded-focus { xsd:anyURI }?, element cascaded-focus { xsd:anyURI }?,
element allow-refer-users-dynamically { xsd:boolean }?, element allow-refer-users-dynamically { xsd:boolean }?,
element allow-invite-users-dynamically { xsd:boolean }?, element allow-invite-users-dynamically { xsd:boolean }?,
element allow-remove-users-dynamically { xsd:boolean }?, element allow-remove-users-dynamically { xsd:boolean }?,
element endpoint { endpoint-type }*, element endpoint { endpoint-type }*,
anyElement* anyElement*
# ENDPOINT TYPE # ENDPOINT TYPE
endpoint-type = endpoint-type =
attribute entity { text }, attribute entity { text },
attribute state { state-type }?, anyAttribute,
element display-text { text }?, element display-text { text }?,
element referred { conference-info-urn* }?, element referred { conference-info-urn* }?,
element status { endpoint-status-type }?, element status { endpoint-status-type }?,
element joining-method { joining-type }?, element joining-method { joining-type }?,
element joining-info { conference-info-urn* }?, element joining-info { conference-info-urn* }?,
element disconnection-method { disconnection-type }?, element disconnection-method { disconnection-type }?,
element disconnection-info { conference-info-urn* }?, element disconnection-info { conference-info-urn* }?,
element media { media-type }*, element media { media-type }*,
element call-info { conference-info-urn* }?, element call-info { conference-info-urn* }?,
anyElement* anyElement*
# MEDIA TYPE # MEDIA TYPE
media-type = media-type =
attribute id { xsd:int }, attribute id { xsd:int },
attribute state { state-type }?,
anyAttribute, anyAttribute,
element display-text { text }?, element display-text { text }?,
element type { text }?, element type { text }?,
element label { text }?, element label { text }?,
element src-id { text }?, element src-id { text }?,
element status { media-status-type }?, element status { media-status-type }?,
element to-mixer { mixer-type }?, element to-mixer { mixer-type }?,
element from-mixer { mixer-type }?, element from-mixer { mixer-type }?,
anyElement* anyElement*
# MIXER TYPE # MIXER TYPE
mixer-type = mixer-type =
attribute state { state-type }?, anyAttribute,
(element floor { xsd:boolean }, (element floor { xsd:boolean },
element controls { controls-type })?, element controls { controls-type })?,
anyElement* anyElement*
# SIDEBARS-BY-REF TYPE # SIDEBARS-BY-REF TYPE
sidebars-by-ref-type = sidebars-by-ref-type =
attribute state { state-type }?, anyAttribute,
element entry { uri-type }*, element entry { conference-info-urn* }*,
anyElement* anyElement*
# SIDEBARS-BY-VAL TYPE # SIDEBARS-BY-VAL TYPE
sidebars-by-val-type = sidebars-by-val-type =
attribute state { state-type }?, anyAttribute,
element entry { conference-type }*, element entry { conference-type }*,
anyElement* anyElement*
# ROLES_TYPE
roles-type =
element entry { single-role-type }*,
anyElement*
# SINGLE ROLE TYPE # SINGLE ROLE TYPE
single-role-type = single-role-type =
xsd:string "administrator" xsd:string "administrator"
| xsd:string "creator"
| xsd:string "moderator" | xsd:string "moderator"
| xsd:string "participant" | xsd:string "participant"
| xsd:string "observer" | xsd:string "none"
# ********************************* # *********************************
# EXTENSIBILITY OF THE SCHEMA # EXTENSIBILITY OF THE SCHEMA
# ********************************* # *********************************
# EXTENSIBILITY ELEMENTS # EXTENSIBILITY ELEMENTS
anyElement = anyElement =
element * { element * {
(attribute * { text } (attribute * { text }
| text | text
| anyElement)* | anyElement)*
} }
# EXTENSIBILITY ATTRIBUTES # EXTENSIBILITY ATTRIBUTES
anyAttribute = anyAttribute =
attribute * - (entity attribute * - (entity
| version | lang
| state
| xml:lang
| required-participant | required-participant
| PIN-code
| purpose
| role
| type
| min
| max
| label | label
| decision | decision
| name | name
| policy | policy
| moderator-controlled
| uri | uri
| method | method
| id | id
| domain
| local:* | local:*
| ns2:*) { text }* | ns1:*) { text }*
# ************************************************************* # *************************************************************
# TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE # TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
# - RFC4575 -
# ************************************************************* # *************************************************************
# WILDCARD FOR EVENT-PACKAGE NAMESPACE # WILDCARD FOR EVENT-PACKAGE NAMESPACE
conference-info-urn = conference-info-urn =
element ns1:* { element * - (ns2:* | local:*) {
mixed {
(attribute * { text } (attribute * { text }
| conference-info-urn)* | conference-info-urn)*
} }
# DEFINITION OF STATE TYPE }
state-type = "full" | "partial" | "deleted"
# DEFINITION OF ENDPOINT STATUS TYPE # DEFINITION OF ENDPOINT STATUS TYPE
media-status-type = "recvonly" | "sendonly" | "sendrecv" | "inactive" media-status-type = "recvonly" | "sendonly" | "sendrecv" | "inactive"
# ENDPOINT STATUS TYPE # ENDPOINT STATUS TYPE
endpoint-status-type = endpoint-status-type =
"pending" "pending"
| "dialing-out" | "dialing-out"
| "dialing-in" | "dialing-in"
| "alerting" | "alerting"
| "on-hold" | "on-hold"
| "connected" | "connected"
skipping to change at page 33, line 7 skipping to change at page 33, line 30
disconnection-type = "departed" | "booted" | "failed" | "busy" disconnection-type = "departed" | "booted" | "failed" | "busy"
6. XML Schema Extensibility 6. XML Schema Extensibility
The Conference Information Data Model defined in this document is The Conference Information Data Model defined in this document is
meant to be extensible toward specific application domains. Such meant to be extensible toward specific application domains. Such
extensions are accomplished by defining elements, child elements and extensions are accomplished by defining elements, child elements and
attributes that are specific to the desired application domain. The attributes that are specific to the desired application domain. The
IETF MAY extend the data model schema with extension elements from IETF MAY extend the data model schema with extension elements from
the same namespace, but other instances are free to extend it from the same namespace, but other instances are free to extend it from
other than urn:ietf:params:xml:ns:conference-schema. other than urn:ietf:params:xml:ns:xcon-conference-info.
Elements or attributes from unknown namespaces MUST be ignored. Elements or attributes from unknown namespaces MUST be ignored.
7. XML Example 7. XML Example
The following is an example of a conference information document. The following is an example of a conference information document.
The conference starts on October 17, 2007, at 10:30 AM in New York The conference starts on October 17, 2007, at 10:30 AM in New York
City and finishes the same day at 12:30 PM every week. In this City and finishes the same day at 12:30 PM every week. In this
example, there are currently 3 participants in a conference, one example, there are currently 3 participants in a conference, one
administrator, one moderator, and one participant. Note that administrator, one moderator, and one participant. Note that
sidebars are allowed in this conference and there is one sidebar in sidebars are allowed in this conference and there is one sidebar in
the conference. Also note that there is one floor moderator for the the conference. Also note that there is one floor moderator for the
audio and a different floor moderator for the video. audio and a different floor moderator for the video.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<conference-info xmlns="urn:ietf:params:xml:ns:conference-schema" <conference-info xmlns="urn:ietf:params:xml:ns:xcon-conference-info"
entity="conference123@example.com" state="full"> entity="conference123@example.com">
<!-- <!--
CONFERENCE DESCRIPTION CONFERENCE DESCRIPTION
--> -->
<conference-description xml:lang="en-us"> <conference-description lang="en-us">
<display-text>Discussion of Formula-1 racing</display-text> <display-text>Discussion of Formula-1 racing</display-text>
<subject> Sports:Formula-1</subject> <subject> Sports:Formula-1</subject>
<free-text>This is a conference example</free-text> <free-text>This is a conference example</free-text>
<keywords>Formula-1, cars</keywords> <keywords>Formula-1, cars</keywords>
<webpage>http://www.example.com/users/formula-1</webpage> <webpage>http://www.example.com/users/formula-1</webpage>
<security-level>low</security-level>
<allow-sidebars>true</allow-sidebars> <allow-sidebars>true</allow-sidebars>
<conference-stage>running</conference-stage>
<!-- <!--
CONFERENCE TIME CONFERENCE TIME
--> -->
<conference-time> <conference-time>
<entry> <entry>
<base>BEGIN:VCALENDAR <base>BEGIN:VCALENDAR
PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
DTSTAMP:20061103T140728Z DTSTAMP:20061103T140728Z
skipping to change at page 34, line 19 skipping to change at page 34, line 41
> 2007-10-17T14:29:00Z</mixing-start-offset> > 2007-10-17T14:29:00Z</mixing-start-offset>
<mixing-end-offset required-participant="participant" <mixing-end-offset required-participant="participant"
> 2007-10-17T16:31:00Z</mixing-end-offset> > 2007-10-17T16:31:00Z</mixing-end-offset>
<must-join-before-offset <must-join-before-offset
> 2007-10-17T15:30:00Z</must-join-before-offset> > 2007-10-17T15:30:00Z</must-join-before-offset>
</entry> </entry>
</conference-time> </conference-time>
<!-- <!--
CONFERENCE UNIQUE IDENTIFIERS CONFERENCE UNIQUE IDENTIFIERS
--> -->
<conf-uris state="full"> <conf-uris>
<SIP> <entry>
<uri>tel:+3585671234</uri> <uri>tel:+3585671234</uri>
<display-text>Conference Bridge</display-text> <display-text>Conference Bridge</display-text>
<purpose>participation</purpose> <purpose>participation</purpose>
</SIP> </entry>
<SIP> <entry>
<uri>http://www.example.comlive.ram</uri> <uri>http://www.example.com/live.ram</uri>
<purpose>streaming</purpose> <purpose>streaming</purpose>
</SIP> </entry>
</conf-uris> </conf-uris>
<!-- <!--
SERVICE URIS SERVICE URIS
--> -->
<service-uris state="full"> <service-uris>
<SIP> <entry>
<uri>http://www.example.com/formula1/</uri> <uri>http://www.example.com/formula1/</uri>
<purpose>web-page</purpose> <purpose>web-page</purpose>
</SIP> </entry>
</service-uris> </service-uris>
<!-- <!--
MAXIMUM USER COUNT MAXIMUM USER COUNT
--> -->
<maximum-user-count> <maximum-user-count>
<entry role="administrator">2</entry> <entry role="administrator">2</entry>
<entry role="moderator">5</entry> <entry role="moderator">5</entry>
<entry role="participant">150</entry> <entry role="participant">150</entry>
</maximum-user-count> </maximum-user-count>
<!-- <!--
skipping to change at page 35, line 31 skipping to change at page 36, line 5
</codecs> </codecs>
</entry> </entry>
</available-media> </available-media>
</conference-description> </conference-description>
<!-- <!--
HOST INFO HOST INFO
--> -->
<host-info> <host-info>
<display-text>Formula1</display-text> <display-text>Formula1</display-text>
<web-page>http://www.example.com/formula1/</web-page> <web-page>http://www.example.com/formula1/</web-page>
<uris state="full"> <uris>
<SIP> <entry>
<uri>sip:alice@example.com</uri> <uri>sip:alice@example.com</uri>
</SIP> </entry>
<SIP> <entry>
<uri>sip:carol@example.com</uri> <uri>sip:carol@example.com</uri>
</SIP> </entry>
</uris> </uris>
</host-info> </host-info>
<!-- <!--
CONFERENCE STATE CONFERENCE STATE
--> -->
<conference-state> <conference-state>
<allow-conference-state>true</allow-conference-state> <allow-conference-state>true</allow-conference-state>
<user-count>3</user-count> <user-count>3</user-count>
<active>true</active> <active>true</active>
<locked>false</locked> <locked>false</locked>
</conference-state> </conference-state>
<!-- <!--
FLOOR INFORMATION FLOOR INFORMATION
--> -->
<floor-information> <floor-information>
<conference-ID>567</conference-ID> <conference-ID>567</conference-ID>
<allow-floor-events>true</allow-floor-events> <allow-floor-events>true</allow-floor-events>
<floor-request-handling>confirm</floor-request-handling> <floor-request-handling>confirm</floor-request-handling>
<conference-floor-policy> <conference-floor-policy>
<floor moderator-controlled="true" label="10234"> <floor>
<media-types>audio</media-types> <media-label>10234</media-label>
<algorithm>moderator-controlled</algorithm> <media-label>10235</media-label>
<max-floor-users>1</max-floor-users>
<chair-id>sip:alice@example.com</chair-id>
</floor>
<floor moderator-controlled="true" label="10235">
<media-types>video</media-types>
<algorithm>moderator-controlled</algorithm> <algorithm>moderator-controlled</algorithm>
<max-floor-users>1</max-floor-users> <max-floor-users>1</max-floor-users>
<chair-id>sip:carol@example.com</chair-id> <moderator-id>234</moderator-id>
</floor> </floor>
</conference-floor-policy> </conference-floor-policy>
</floor-information> </floor-information>
<!-- <!--
USERS USERS
--> -->
<users state="full"> <users>
<join-handling>allow</join-handling> <join-handling>allow</join-handling>
<user-admission-policy
>openAuthenticated</user-admission-policy>
<!-- <!--
ALLOWED USERS LIST ALLOWED USERS LIST
--> -->
<allowed-users-list> <allowed-users-list>
<target uri="sip:bob@example.com" method="dial-out"/> <target uri="sip:bob@example.com" method="dial-out"/>
<target uri="sip:alice@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:carol@example.com" method="dial-out"/>
<target uri="sip:john@example.com" method="refer"/> <target uri="sip:john@example.com" method="refer"/>
</allowed-users-list> </allowed-users-list>
<!-- <!--
USER BOB USER BOB
--> -->
<user entity="bob534" state="partial"> <user entity="bob534">
<display-text>Bob Hoskins</display-text> <display-text>Bob Hoskins</display-text>
<associated-aors state="full"> <associated-aors>
<SIP> <SIP>
<uri>mailto:bob@example.com</uri> <uri>mailto:bob@example.com</uri>
<display-text>email</display-text> <display-text>email</display-text>
</SIP> </SIP>
</associated-aors> </associated-aors>
<provide-anonymity>false</provide-anonymity> <provide-anonymity>false</provide-anonymity>
<roles> <roles>
<entry>participant</entry> <entry>participant</entry>
</roles> </roles>
<languages>en</languages> <languages>en</languages>
<sphere value="work"/>
<allow-refer-users-dynamically <allow-refer-users-dynamically
>false</allow-refer-users-dynamically> >false</allow-refer-users-dynamically>
<allow-invite-users-dynamically <allow-invite-users-dynamically
>false</allow-invite-users-dynamically> >false</allow-invite-users-dynamically>
<allow-remove-users-dynamically <allow-remove-users-dynamically
>false</allow-remove-users-dynamically> >false</allow-remove-users-dynamically>
<!-- <!--
ENDPOINTS ENDPOINTS
--> -->
<endpoint entity="sip:bob@example.com" state="full"> <endpoint entity="sip:bob@example.com">
<display-text>Bob's Laptop</display-text> <display-text>Bob's Laptop</display-text>
<referred> <referred>
<when>2006-10-17T14:00:00Z</when> <when>2006-10-17T14:00:00Z</when>
<reason>expert required</reason> <reason>expert required</reason>
<by>sip:alice@example.com</by> <by>sip:alice@example.com</by>
</referred> </referred>
<status>connected</status> <status>connected</status>
<joining-method>dialed-out</joining-method> <joining-method>dialed-out</joining-method>
<joining-info> <joining-info>
<when>2006-10-17T14:00:00Z</when> <when>2006-10-17T14:00:00Z</when>
skipping to change at page 38, line 7 skipping to change at page 38, line 25
<to-tag>8954jgjg8432</to-tag> <to-tag>8954jgjg8432</to-tag>
</sip> </sip>
</call-info> </call-info>
</endpoint> </endpoint>
</user> </user>
<!-- <!--
USER ALICE USER ALICE
--> -->
<user entity="alice334" state="full"> <user entity="alice334">
<display-text>Alice Kay</display-text> <display-text>Alice Kay</display-text>
<associated-aors state="full"> <associated-aors>
<SIP> <SIP>
<uri>mailto:alice@example.com</uri> <uri>mailto:alice@example.com</uri>
<display-text>email</display-text> <display-text>email</display-text>
</SIP> </SIP>
</associated-aors> </associated-aors>
<provide-anonymity>false</provide-anonymity> <provide-anonymity>false</provide-anonymity>
<roles> <roles>
<entry>moderator</entry> <entry>moderator</entry>
</roles> </roles>
<languages>en</languages> <languages>en</languages>
<sphere value="work"/>
<allow-refer-users-dynamically <allow-refer-users-dynamically
>true</allow-refer-users-dynamically> >true</allow-refer-users-dynamically>
<allow-invite-users-dynamically <allow-invite-users-dynamically
>true</allow-invite-users-dynamically> >true</allow-invite-users-dynamically>
<allow-remove-users-dynamically <allow-remove-users-dynamically
>true</allow-remove-users-dynamically> >true</allow-remove-users-dynamically>
<!-- <!--
ENDPOINTS ENDPOINTS
--> -->
<endpoint entity="sip:alice@example.com" state="full"> <endpoint entity="sip:alice@example.com">
<display-text>Alice's Desktop</display-text> <display-text>Alice's Desktop</display-text>
<status>connected</status> <status>connected</status>
<joining-method>dialed-in</joining-method> <joining-method>dialed-in</joining-method>
<joining-info> <joining-info>
<when>2006-10-17T13:35:08Z</when> <when>2006-10-17T13:35:08Z</when>
<reason>invitation</reason> <reason>invitation</reason>
<by>sip:conference@example.com</by> <by>sip:conference@example.com</by>
</joining-info> </joining-info>
<!-- <!--
MEDIA MEDIA
skipping to change at page 39, line 21 skipping to change at page 39, line 38
<from-tag>asd456cbgt</from-tag> <from-tag>asd456cbgt</from-tag>
<to-tag>3456jgjg1234</to-tag> <to-tag>3456jgjg1234</to-tag>
</sip> </sip>
</call-info> </call-info>
</endpoint> </endpoint>
</user> </user>
<!-- <!--
USER CAROL USER CAROL
--> -->
<user entity="carol233" state="full"> <user entity="carol233">
<display-text>Carol More</display-text> <display-text>Carol More</display-text>
<associated-aors state="full"> <associated-aors>
<SIP> <SIP>
<uri>mailto:carol@example.com</uri> <uri>mailto:carol@example.com</uri>
<display-text>email</display-text> <display-text>email</display-text>
</SIP> </SIP>
</associated-aors> </associated-aors>
<provide-anonymity>false</provide-anonymity> <provide-anonymity>false</provide-anonymity>
<roles> <roles>
<entry>administrator</entry> <entry>administrator</entry>
</roles> </roles>
<languages>en</languages> <languages>en</languages>
<sphere value="work"/>
<allow-refer-users-dynamically <allow-refer-users-dynamically
>true</allow-refer-users-dynamically> >true</allow-refer-users-dynamically>
<allow-invite-users-dynamically <allow-invite-users-dynamically
>true</allow-invite-users-dynamically> >true</allow-invite-users-dynamically>
<allow-remove-users-dynamically <allow-remove-users-dynamically
>true</allow-remove-users-dynamically> >true</allow-remove-users-dynamically>
<!-- <!--
ENDPOINTS ENDPOINTS
--> -->
<endpoint entity="sip:carol@example.com" state="full"> <endpoint entity="sip:carol@example.com">
<display-text>Carol's Computer</display-text> <display-text>Carol's Computer</display-text>
<status>connected</status> <status>connected</status>
<joining-method>dialed-in</joining-method> <joining-method>dialed-in</joining-method>
<joining-info> <joining-info>
<when>2006-10-17T13:30:05Z</when> <when>2006-10-17T13:30:05Z</when>
<reason>invitation</reason> <reason>invitation</reason>
<by>sip:conference@example.com</by> <by>sip:conference@example.com</by>
</joining-info> </joining-info>
<!-- <!--
MEDIA MEDIA
skipping to change at page 40, line 35 skipping to change at page 40, line 51
<from-tag>asw456wedf</from-tag> <from-tag>asw456wedf</from-tag>
<to-tag>2365dfrt3497</to-tag> <to-tag>2365dfrt3497</to-tag>
</sip> </sip>
</call-info> </call-info>
</endpoint> </endpoint>
</user> </user>
</users> </users>
<!-- <!--
SIDEBARS BY REFERENCE SIDEBARS BY REFERENCE
--> -->
<sidebars-by-ref state="full"> <sidebars-by-ref>
<entry> <entry>
<uri>sips:conference123;grid=40</uri> <uri>conf223</uri>
<display-text>private with Bob</display-text> <display-text>private with Bob</display-text>
</entry> </entry>
</sidebars-by-ref> </sidebars-by-ref>
<!-- <!--
SIDEBARS BY VALUE SIDEBARS BY VALUE
--> -->
<sidebars-by-val> <sidebars-by-val>
<entry entity="conference123;grid=40"> <entry entity="conf223">
<users> <users>
<user entity="bob534"/> <user entity="bob534"/>
<user entity="carol233"/> <user entity="carol233"/>
</users> </users>
</entry> </entry>
</sidebars-by-val> </sidebars-by-val>
</conference-info> </conference-info>
Note that due to RFC formatting conventions, this documents splits Note that due to RFC formatting conventions, this documents splits
lines whose content would exceed 72 characters. Two backslash lines whose content would exceed 72 characters. Two backslash
characters mark where line folding has taken place. These characters mark where line folding has taken place. These
backslashes would not appear in the actual XML data model. backslashes would not appear in the actual XML data model.
8. Security Considerations 8. Security Considerations
There are numerous security considerations for this document. This
section considers them.
8.1. Authentication
A malicious user can manipulate parts of the Conference Information A malicious user can manipulate parts of the Conference Information
Data Model privileges document giving themselves and others Data Model privileges document giving themselves and others
privileges to manipulate the data model. It is very important that privileges to manipulate the document. It is very important that
only authorized clients are able to manipulate the Conference only authorized clients are able to manipulate the Conference
Information Data Model document. Any conference control protocol Information Data Model document.
MUST provide authentication, confidentiality and integrity.
The security considerations for authentication (section 10.1)
described in the centralized conferencing framework [1] applies to
this document. The focus must ensure that only authorized entities
are able to manipulate the data to access the information.
8.2. Confidentiality
Participants of a conference may not want to reveal some private
information to other users. The Conference Information Data Model
contains sensitive data which should not be analyzed or given to
anyone. Confidentiality is provided through encryption. Strong end-
to-end authentication and encryption can be done using public keys,
and end-to-end encryption can be done using private keys. It is
RECOMMENDED that the protocols that manipulated the conference
information data model use a strong encryption for conference
information protection.
8.3. Integrity
It is important that the Conference Information Data Model can only
be accessed or modified by those authorized users. Without
integrity, the Conference Information Data Model could be modified,
fooling the user into believing incorrect information. Measures
taken to ensure integrity include maintaining rigorous authentication
practices.
9. IANA Considerations 9. IANA Considerations
9.1. Conference Relax NG Schema Registration 9.1. Conference Relax NG Schema Registration
URI: urn:ietf:params:xml:ns:conference-schema URI: urn:ietf:params:xml:ns:xcon-conference-info
Relax NG Schema: The Relax NG schema to be registered is contained Relax NG Schema: The Relax NG schema to be registered is contained
in Section 4. Its first line is in Section 5. Its first line is
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
and its last line is and its last line is
disconnection-type = "departed" | "booted" | "failed" | "busy" disconnection-type = "departed" | "booted" | "failed" | "busy"
9.2. Conference Namespace Registration 9.2. Conference Namespace Registration
URI: urn:ietf:params:xml:ns:conference-schema URI: urn:ietf:params:xml:ns:xcon-conference-info
9.3. Conference Object Identifier Registration 9.3. Conference Object Identifier Registration
XCON_URI = "xcon" ":" [conf-object-id "@"] hostport XCON_URI = "xcon" ":" [conf-object-id "@"] host [ ":" port ]
; hostport as defined in RFC3261
conf-object-id = 1*( unreserved / "+" / "=" / "/" ) conf-object-id = 1*( unreserved / "+" / "=" / "/" )
; unreserved as defined in RFC3986
host, port, and unreserved are defined in RFC3986[15]
9.4. Conference User Identifier Registration 9.4. Conference User Identifier Registration
XCON_USERID = "xcon_userid" ":" conf-object-id XCON_USERID = "xcon_userid" ":" conf-object-id
conf-object-id = 1*( unreserved / "+" / "=" / "/" ) conf-object-id = 1*( unreserved / "+" / "=" / "/" )
; unreserved as defined in RFC3986
unreserved is defined in RFC3986[15]
10. Acknowledgements 10. Acknowledgements
This document is really a distillation of many ideas discussed over a This document is really a distillation of many ideas discussed over a
long period of time. These ideas were contributed by many different long period of time. These ideas were contributed by many different
drafts in the XCON working group and the SIPPING working group. We drafts in the XCON working group and the SIPPING working group. We
would like to thank Orit Levin, Adam Roach, Mary Barnes, Chris would like to thank Orit Levin, Adam Roach, Mary Barnes, Chris
Boulton, Umesh Chandra, Hisham Khartabil, Petri Koskelainen, Aki Boulton, Umesh Chandra, Hisham Khartabil, Petri Koskelainen, Aki
Niemi, and Jari Urpilainen for their comments. Also, We would like Niemi, Jari Urpilainen, Rohan Mahy, and Henning Schulzrinne for their
to thank Mary Barnes, and Chris Boulton for letting us use the comments. Also, we would like to thank Mary Barnes, and Chris
conference and user identifier information of their xcon drafts. Boulton for letting us use the conference and user identifier
information of their xcon drafts. Last but not least, I would like
to express my gratitude to all those reviewers for their invaluable
contribution: Simon Pietro Romano, Lorenzo Miniero, Tobia Castaldi,
Miguel Garcia, Mary Barnes, Srivatsa Srinivasan, Avshalom Houri, and
Ben Campbell.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session [1] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State", Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006. RFC 4575, August 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Dawson, F. and Stenerson, D., "Internet Calendaring and [3] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445, Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998. November 1998.
11.2. Informative References 11.2. Informative References
[4] Barnes, M., "A Framework and Data Model for Centralized [4] Barnes, M., "A Framework for Centralized Conferencing",
Conferencing", draft-ietf-xcon-framework-07 (work in progress), draft-ietf-xcon-framework-09 (work in progress), August 2007.
January 2007.
[5] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control [5] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
Protocol (BFCP)", RFC 4582, November 2006. Protocol (BFCP)", RFC 4582, November 2006.
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[7] Rosenberg, J., "A Framework for Conferencing with the Session [7] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006. Initiation Protocol (SIP)", RFC 4353, February 2006.
[8] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, [8] Paoli, J., Maler, E., Sperberg-McQueen, C., and T. Bray,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World "Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, Wide Web Consortium FirstEdition REC-xml-20001006,
<http://www.w3.org/TR/2000/REC-xml-20001006>. October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[9] Casner, S., "Media Type Registration of RTP Payload Formats",
RFC 4855, February 2007.
[10] "IANA registry for RTP Payload Types"
"http://www.iana.org/assignments/rtp-parameters".
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[12] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", RFC 4583,
November 2006.
[13] Camarillo, G., "Connection Establishment in the Binary Floor
Control Protocol (BFCP)", RFC 5018, September 2007.
[14] "RELAX NG Home Page" "http://relaxng.org/".
[15] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML Syntax Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:conference-schema" <grammar ns="urn:ietf:params:xml:ns:xcon-conference-info"
xmlns="http://relaxng.org/ns/structure/1.0" xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/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"> <element name="conference-info">
<ref name="conference-type"/> <ref name="conference-type"/>
</element> </element>
</start> </start>
<!-- <!--
CONFERENCE TYPE CONFERENCE TYPE
--> -->
<define name="conference-type"> <define name="conference-type">
<attribute name="entity"> <attribute name="entity">
<text/> <text/>
</attribute> </attribute>
<optional> <ref name="anyAttribute"/>
<attribute name="version">
<data type="unsignedInt"/>
</attribute>
</optional>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<ref name="conference-description-type"/> <ref name="conference-description-type"/>
<optional> <optional>
<element name="host-info"> <element name="host-info">
<ref name="host-type"/> <zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="conference-state"> <element name="conference-state">
<ref name="conference-state-type"/> <ref name="conference-state-type"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="floor-information"> <element name="floor-information">
<ref name="floor-information-type"/> <ref name="floor-information-type"/>
skipping to change at page 44, line 35 skipping to change at page 46, line 6
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</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">
<optional> <optional>
<attribute name="xml:lang"> <attribute name="lang">
<data type="language"/> <data type="language"/>
</attribute> </attribute>
</optional> </optional>
<optional> <ref name="anyAttribute"/>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional> <optional>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="subject"> <element name="subject">
<text/> <text/>
</element> </element>
</optional> </optional>
skipping to change at page 45, line 32 skipping to change at page 46, line 47
<data type="boolean"/> <data type="boolean"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="conference-time"> <element name="conference-time">
<ref name="conferencetime-type"/> <ref name="conferencetime-type"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="conf-uris"> <element name="conf-uris">
<ref name="uris-type"/> <zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="service-uris"> <element name="service-uris">
<ref name="uris-type"/> <zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="maximum-user-count"> <element name="maximum-user-count">
<data type="int"/> <data type="int"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="available-media"> <element name="available-media">
<ref name="conference-media-type"/> <ref name="conference-media-type"/>
skipping to change at page 46, line 11 skipping to change at page 47, line 30
</optional> </optional>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</element> </element>
</define> </define>
<!-- <!--
CONFERENCE TIME CONFERENCE TIME
--> -->
<define name="conferencetime-type"> <define name="conferencetime-type">
<ref name="anyAttribute"/>
<zeroOrMore> <zeroOrMore>
<element name="entry"> <element name="entry">
<optional> <optional>
<element name="base"> <element name="base">
<text/> <text/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="mixing-start-offset"> <element name="mixing-start-offset">
<data type="dateTime"> <data type="dateTime">
skipping to change at page 47, line 13 skipping to change at page 48, line 33
</data> </data>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="notify-end-of-conference"> <element name="notify-end-of-conference">
<data type="int"/> <data type="int"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="allowed-extend-mixing-end-offset"> <element name="allowed-extend-mixing-end-offset">
<ref name="allowed-extend-mixing-values"/> <data type="boolean"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</element>
</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>
<!--
URIS TYPE
-->
<define name="uris-type">
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<interleave>
<zeroOrMore>
<element name="entry">
<ref name="uri-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<element name="H323">
<ref name="H323-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<element name="PSTN-ISDN">
<ref name="PSTN-type"/>
</element>
</zeroOrMore>
</interleave>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
SIP TYPE
-->
<define name="uri-type">
<zeroOrMore>
<element name="uri">
<data type="anyURI"/>
</element>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="purpose">
<text/>
</element> </element>
</optional> </optional>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</zeroOrMore>
</define>
<!--
H323 TYPE
-->
<define name="H323-type">
<optional>
<element name="H.323-alias">
<text/>
</element>
</optional>
<optional>
<element name="H.323-URI">
<data type="anyURI"/>
</element> </element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define>
<!--
PSTN TYPE
-->
<define name="PSTN-type">
<attribute name="PIN-code">
<data type="unsignedInt"/>
</attribute>
<attribute name="purpose">
<data type="unsignedInt"/>
</attribute>
<oneOrMore>
<element name="phone-number">
<data type="unsignedInt"/>
</element>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</oneOrMore>
</define> </define>
<!-- <!--
CONFERENCE MEDIA TYPE CONFERENCE MEDIA TYPE
--> -->
<define name="conference-media-type"> <define name="conference-media-type">
<optional> <ref name="anyAttribute"/>
<attribute name="state">
<ref name="state-type"/>
</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> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
CONFERENCE MEDIUM TYPE CONFERENCE MEDIUM TYPE
--> -->
<define name="conference-medium-type"> <define name="conference-medium-type">
<attribute name="label"> <attribute name="label">
<text/> <text/>
</attribute> </attribute>
<ref name="anyAttribute"/>
<optional> <optional>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="type"> <element name="type">
<text/> <text/>
</element> </element>
</optional> </optional>
skipping to change at page 50, line 27 skipping to change at page 49, line 41
<element name="status"> <element name="status">
<ref name="media-status-type"/> <ref name="media-status-type"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="mixing-mode"> <element name="mixing-mode">
<ref name="mix-mode-type"/> <ref name="mix-mode-type"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="mix-level">
<data type="unsignedInt"/>
</element>
</optional>
<optional>
<element name="codecs"> <element name="codecs">
<ref name="codecs-type"/> <ref name="codecs-type"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="controls"> <element name="controls">
<ref name="controls-type"/> <ref name="controls-type"/>
</element> </element>
</optional> </optional>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
CONTROLS TYPE CONTROLS TYPE
--> -->
<define name="controls-type"> <define name="controls-type">
<optional> <ref name="anyAttribute"/>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<zeroOrMore> <zeroOrMore>
<element name="control"> <element name="control">
<ref name="control-type"/> <ref name="control-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
skipping to change at page 51, line 32 skipping to change at page 50, line 37
<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">
<attribute name="decision"> <attribute name="decision">
<ref name="decision-type"/> <ref name="decision-type"/>
</attribute> </attribute>
<ref name="anyAttribute"/>
<zeroOrMore> <zeroOrMore>
<element name="codec"> <element name="codec">
<ref name="codec-type"/> <ref name="codec-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
CODEC TYPE CODEC TYPE
--> -->
<define name="codec-type"> <define name="codec-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>
<ref name="anyAttribute"/>
</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>
skipping to change at page 52, line 26 skipping to change at page 51, line 33
<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">
<ref name="anyAttribute"/>
<choice> <choice>
<element name="mute"> <element name="mute">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
<element name="pause-video"> <element name="pause-video">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
<element name="gain"> <element name="gain">
<data type="int"> <data type="int">
<param name="minInclusive">-127</param> <param name="minInclusive">-127</param>
skipping to change at page 53, line 11 skipping to change at page 52, line 19
<value type="string">multiple-5x1</value> <value type="string">multiple-5x1</value>
<value type="string">automatic</value> <value type="string">automatic</value>
</choice> </choice>
</element> </element>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</choice> </choice>
</define> </define>
<!-- <!--
HOST TYPE
-->
<define name="host-type">
<zeroOrMore>
<element name="display-text">
<text/>
</element>
<element name="web-page">
<data type="anyURI"/>
</element>
<element name="uris">
<ref name="uris-type"/>
</element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</zeroOrMore>
</define>
<!--
CONFERENCE STATE TYPE CONFERENCE STATE TYPE
--> -->
<define name="conference-state-type"> <define name="conference-state-type">
<ref name="anyAttribute"/>
<optional> <optional>
<element name="allow-conference-event-subscription"> <element name="allow-conference-event-subscription">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="user-count"> <element name="user-count">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> </element>
</optional> </optional>
skipping to change at page 54, line 13 skipping to change at page 52, line 51
</element> </element>
</optional> </optional>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <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="anyAttribute"/>
<zeroOrMore> <zeroOrMore>
<element name="conference-ID"> <element name="conference-ID">
<data type="unsignedInt"/> <data type="unsignedInt"/>
</element> </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>
skipping to change at page 54, line 44 skipping to change at page 53, line 35
<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="anyAttribute"/>
<oneOrMore> <oneOrMore>
<element name="floor"> <element name="floor">
<attribute name="moderator-controlled">
<data type="boolean"/>
</attribute>
<attribute name="label">
<text/>
</attribute>
<ref name="anyAttribute"/> <ref name="anyAttribute"/>
<zeroOrMore> <oneOrMore>
<element name="media-types"> <element name="media-label">
<choice> <data type="nonNegativeInteger"/>
<value type="string">video</value>
<value type="string">audio</value>
<value type="string">application</value>
<value type="string">data</value>
<value type="string">control</value>
<value type="string">message</value>
<value type="string">text</value>
</choice>
</element> </element>
</oneOrMore>
<zeroOrMore>
<element name="algorithm"> <element name="algorithm">
<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">random</value> <value type="string">random</value>
</choice> </choice>
</element> </element>
<element name="max-floor-users"> <element name="max-floor-users">
<data type="nonNegativeInteger"/> <data type="nonNegativeInteger"/>
</element> </element>
<element name="chair-id"> <element name="moderator-id">
<data type="anyURI"/> <text/>
</element> </element>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</zeroOrMore> </zeroOrMore>
</element> </element>
</oneOrMore> </oneOrMore>
</define> </define>
<!-- <!--
USERS TYPE USERS TYPE
--> -->
<define name="users-type"> <define name="users-type">
<optional> <ref name="anyAttribute"/>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional> <optional>
<element name="join-handling"> <element name="join-handling">
<ref name="join-handling-type"/> <ref name="join-handling-type"/>
</element> </element>
</optional> </optional>
<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>
skipping to change at page 56, line 43 skipping to change at page 55, line 19
<value type="string">openAuthenticated</value> <value type="string">openAuthenticated</value>
<value type="string">anonymous</value> <value type="string">anonymous</value>
</choice> </choice>
</define> </define>
<!-- <!--
JOIN HANDLING TYPE JOIN HANDLING TYPE
--> -->
<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">confirm</value> <value type="string">confirm</value>
<value type="string">IVR</value> <value type="string">allow</value>
<value type="string">authenticate</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="anyAttribute"/>
<zeroOrMore> <zeroOrMore>
<element name="target"> <element name="target">
<ref name="target-type"/> <ref name="target-type"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
TARGET TYPE TARGET TYPE
--> -->
<define name="target-type"> <define name="target-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>
<ref name="anyAttribute"/>
</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>
<!-- <!--
USER TYPE USER TYPE
--> -->
<define name="user-type"> <define name="user-type">
<attribute name="entity"> <attribute name="entity">
<data type="anyURI"/> <data type="anyURI"/>
</attribute> </attribute>
<optional> <ref name="anyAttribute"/>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional> <optional>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="associated-aors"> <element name="associated-aors">
<ref name="uris-type"/> <zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="provide-anonymity"> <element name="provide-anonymity">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="roles"> <element name="roles">
<ref name="roles-type"/> <text/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="languages"> <element name="languages">
<list> <list>
<data type="language"/> <data type="language"/>
</list> </list>
</element> </element>
</optional> </optional>
<optional> <optional>
skipping to change at page 59, line 14 skipping to change at page 57, line 38
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
ENDPOINT TYPE ENDPOINT TYPE
--> -->
<define name="endpoint-type"> <define name="endpoint-type">
<attribute name="entity"> <attribute name="entity">
<text/> <text/>
</attribute> </attribute>
<optional> <ref name="anyAttribute"/>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional> <optional>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="referred"> <element name="referred">
<zeroOrMore> <zeroOrMore>
<ref name="conference-info-urn"/> <ref name="conference-info-urn"/>
</zeroOrMore> </zeroOrMore>
skipping to change at page 60, line 35 skipping to change at page 59, line 7
<ref name="anyElement"/> <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">
<data type="int"/> <data type="int"/>
</attribute> </attribute>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<ref name="anyAttribute"/> <ref name="anyAttribute"/>
<optional> <optional>
<element name="display-text"> <element name="display-text">
<text/> <text/>
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="type"> <element name="type">
<text/> <text/>
</element> </element>
skipping to change at page 61, line 36 skipping to change at page 59, line 51
</element> </element>
</optional> </optional>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
MIXER TYPE MIXER TYPE
--> -->
<define name="mixer-type"> <define name="mixer-type">
<optional> <ref name="anyAttribute"/>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional> <optional>
<element name="floor"> <element name="floor">
<data type="boolean"/> <data type="boolean"/>
</element> </element>
<element name="controls"> <element name="controls">
<ref name="controls-type"/> <ref name="controls-type"/>
</element> </element>
</optional> </optional>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
SIDEBARS-BY-REF TYPE SIDEBARS-BY-REF TYPE
--> -->
<define name="sidebars-by-ref-type"> <define name="sidebars-by-ref-type">
<optional> <ref name="anyAttribute"/>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<zeroOrMore> <zeroOrMore>
<element name="entry"> <element name="entry">
<ref name="uri-type"/> <zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element> </element>
</zeroOrMore> </zeroOrMore>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
SIDEBARS-BY-VAL TYPE SIDEBARS-BY-VAL TYPE
--> -->
<define name="sidebars-by-val-type"> <define name="sidebars-by-val-type">
<optional> <ref name="anyAttribute"/>
<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>
<zeroOrMore> <zeroOrMore>
<ref name="anyElement"/> <ref name="anyElement"/>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
ROLES_TYPE
-->
<define name="roles-type">
<zeroOrMore>
<element name="entry">
<ref name="single-role-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</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">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">none</value>
</choice> </choice>
</define> </define>
<!-- <!--
********************************* *********************************
EXTENSIBILITY OF THE SCHEMA EXTENSIBILITY OF THE SCHEMA
********************************* *********************************
--> -->
<!-- <!--
EXTENSIBILITY ELEMENTS EXTENSIBILITY ELEMENTS
--> -->
skipping to change at page 63, line 49 skipping to change at page 61, line 40
</define> </define>
<!-- <!--
EXTENSIBILITY ATTRIBUTES EXTENSIBILITY ATTRIBUTES
--> -->
<define name="anyAttribute"> <define name="anyAttribute">
<zeroOrMore> <zeroOrMore>
<attribute> <attribute>
<anyName> <anyName>
<except> <except>
<name ns="">entity</name> <name ns="">entity</name>
<name ns="">version</name> <name ns="">lang</name>
<name ns="">state</name>
<name ns="">xml:lang</name>
<name ns="">required-participant</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="">label</name>
<name ns="">decision</name> <name ns="">decision</name>
<name ns="">name</name> <name ns="">name</name>
<name ns="">policy</name> <name ns="">policy</name>
<name ns="">moderator-controlled</name>
<name ns="">uri</name> <name ns="">uri</name>
<name ns="">method</name> <name ns="">method</name>
<name ns="">id</name> <name ns="">id</name>
<name ns="">domain</name>
<nsName ns=""/> <nsName ns=""/>
<nsName ns="urn:ietf:params:xml:ns:conference-schema"/> <nsName ns="urn:ietf:params:xml:ns:xcon-conference-info"/>
</except> </except>
</anyName> </anyName>
<text/> <text/>
</attribute> </attribute>
</zeroOrMore> </zeroOrMore>
</define> </define>
<!-- <!--
************************************************************* *************************************************************
TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
- RFC4575 -
************************************************************* *************************************************************
--> -->
<!-- <!--
WILDCARD FOR EVENT-PACKAGE NAMESPACE WILDCARD FOR EVENT-PACKAGE NAMESPACE
--> -->
<define name="conference-info-urn"> <define name="conference-info-urn">
<element> <element>
<nsName ns="urn:ietf:params:xml:ns:conference-info-urn"/> <anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:conference-info"/>
<nsName ns=""/>
</except>
</anyName>
<mixed>
<zeroOrMore> <zeroOrMore>
<choice> <choice>
<attribute> <attribute>
<anyName/> <anyName/>
</attribute> </attribute>
<ref name="conference-info-urn"/> <ref name="conference-info-urn"/>
</choice> </choice>
</zeroOrMore> </zeroOrMore>
</mixed>
</element> </element>
</define> </define>
<!--
DEFINITION OF STATE TYPE
-->
<define name="state-type">
<choice>
<value>full</value>
<value>partial</value>
<value>deleted</value>
</choice>
</define>
<!-- <!--
DEFINITION OF ENDPOINT STATUS TYPE DEFINITION OF ENDPOINT STATUS TYPE
--> -->
<define name="media-status-type"> <define name="media-status-type">
<choice> <choice>
<value>recvonly</value> <value>recvonly</value>
<value>sendonly</value> <value>sendonly</value>
<value>sendrecv</value> <value>sendrecv</value>
<value>inactive</value> <value>inactive</value>
</choice> </choice>
 End of changes. 264 change blocks. 
1022 lines changed or deleted 933 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/