One document matched: draft-ietf-xcon-common-data-model-05.txt
Differences from draft-ietf-xcon-common-data-model-04.txt
XCON O. Novo
Internet-Draft G. Camarillo
Intended status: Standards Track Ericsson
Expires: October 19, 2007 D. Morgan
Fidelity Investments
R. Even
Polycom
April 17, 2007
Conference Information Data Model for Centralized Conferencing (XCON)
draft-ietf-xcon-common-data-model-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 19, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines an Extensible Markup Language (XML)-based
conference information data model for centralized conferencing
(XCON). A conference object, which can be manipulated using a
conference control protocol, at a conference server represents a
Novo, et al. Expires October 19, 2007 [Page 1]
Internet-Draft Data Model Schema April 2007
particular instantiation of this data model. The conference
information data model defined in this document is an extension of
(and thus, compatible with) the model specified in the Session
Initiation Protocol (SIP) Event Package for Conference State.
Novo, et al. Expires October 19, 2007 [Page 2]
Internet-Draft Data Model Schema April 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Data Model Structure . . . . . . . . . . . . . . . . . . . 6
3.2. Role Definitions . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Role in a Floor . . . . . . . . . . . . . . . . . . . 8
3.2.2. Changing Roles . . . . . . . . . . . . . . . . . . . . 8
4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 8
4.1. <conference-description> . . . . . . . . . . . . . . . . . 13
4.1.1. <conference-time> . . . . . . . . . . . . . . . . . . 14
4.1.2. <conf-uris> . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. <service-uris> . . . . . . . . . . . . . . . . . . . . 16
4.1.4. <maximum-user-count> . . . . . . . . . . . . . . . . . 16
4.1.5. <available-media> . . . . . . . . . . . . . . . . . . 16
4.1.5.1. <controls> . . . . . . . . . . . . . . . . . . . . 17
4.1.5.1.1. mute . . . . . . . . . . . . . . . . . . . . . 17
4.1.5.1.2. pause-video . . . . . . . . . . . . . . . . . 17
4.1.5.1.3. gain . . . . . . . . . . . . . . . . . . . . . 18
4.1.5.1.4. video-layout . . . . . . . . . . . . . . . . . 18
4.2. <host-info> . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. <conference-state> . . . . . . . . . . . . . . . . . . . . 19
4.4. <floor-information> . . . . . . . . . . . . . . . . . . . 19
4.5. <users> . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5.1. <allowed-users-list> . . . . . . . . . . . . . . . . . 22
4.5.2. <user> . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5.2.1. <from-mixer>, <to-mixer> . . . . . . . . . . . . . 24
4.5.2.1.1. <floor> . . . . . . . . . . . . . . . . . . . 24
4.5.3. <sidebars-by-ref> . . . . . . . . . . . . . . . . . . 24
4.5.4. <sidebars-by-val> . . . . . . . . . . . . . . . . . . 24
5. RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . . . 25
6. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 32
7. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
9.1. Conference Relax NG Schema Registration . . . . . . . . . 41
9.2. Conference Namespace Registration . . . . . . . . . . . . 41
9.3. Conference Object Identifier Registration . . . . . . . . 41
9.4. Conference User Identifier Registration . . . . . . . . . 42
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Normative References . . . . . . . . . . . . . . . . . . . 42
11.2. Informative References . . . . . . . . . . . . . . . . . . 42
Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML
Syntax . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
Intellectual Property and Copyright Statements . . . . . . . . . . 68
Novo, et al. Expires October 19, 2007 [Page 3]
Internet-Draft Data Model Schema April 2007
1. Introduction
Conference objects are a fundamental concept in Centralized
conferencing, as described in the XCON Conferencing Framework [4]. A
conference object contains data that represents a conference during
each of its various stages (e.g., reserved, started, running, ended,
etc.). Conference Objects are instantiations of the conference
information data model defined in this document. Consequently,
conference objects follow the XML format defined in this document.
A conference object contains the core information of a conference
(i.e., capabilities, membership, roles, call control signaling,
media, etc.) and specifies who, and in which way, can manipulate that
information.
Figure 1 shows logical functional elements of a conference server as
defined by the XCON Conferencing Framework [4]. They are a
Conference Control Server, a Floor Control Server, a number of Foci,
and a Notification Service. A conference control protocol provides
the interface between a conference and media control client, and the
conference control server. A floor control protocol (e.g., BFCP [5])
provides the interface between a floor control client and the floor
control server. A call signaling protocol (e.g., SIP, H.323, PSTN,
etc.) provides the interface between a call signaling client and a
Focus. A notification protocol (e.g., SIP-based event notifications
[6]) provides the interface between the conferencing client and the
Notification Service. Within a conference, the conference control
server, floor control server, and focus can modify the information in
the conference object.
Novo, et al. Expires October 19, 2007 [Page 4]
Internet-Draft Data Model Schema April 2007
...............................................................
. Conferencing Server .
. +---------------------------------------------------+ .
. | C o n f e r e n c e o b j e c t | .
. +-+--------------------------------------------------+| .
. | C o n f e r e n c e o b j e c t || .
. +-+---------------------------------------------------+|| .
. | C o n f e r e n c e o b j e c t ||| .
. | +--------------------------------------------------+||| .
. | | Conference Information Data Model |||| .
. | | +----------------------------------------------+ |||| .
. | | | Conference description (times, duration) | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Host information | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Conference state | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Floor information | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Membership (users, roles, capacity) | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Sidebars, Etc. | |||| .
. | | +----------------------------------------------+ |||| .
. | | +----------------------------------------------+ |||| .
. | | | Etc. | |||| .
. | | +----------------------------------------------+ |||+ .
. | +--------------------------------------------------+|+ .
. +----^------------------^-------------^--------|------+ .
. | | | | .
. +------v-------+ +--------v-----+ +-----v-+ +----v-------+ .
. | Conference | | Floor | | | | | .
. | Control | | Control | |Foci | |Notification| .
. | Server | | Server | | | |Service | .
. +-----^--------+ +---^----------+ +-^-----+ +------------+ .
........|..............|..............|..........|.............
|Conference |Binary Floor |Call |Notification
|Control |Control |Signaling |Protocol
|Protocol |Protocol |Protocol |
........v..............v..............v..........v.............
. C o n f e r e n c i n g C l i e n t .
...............................................................
Figure 1: Conference Server Architecture
Novo, et al. Expires October 19, 2007 [Page 5]
Internet-Draft Data Model Schema April 2007
The Session Initiation Protocol (SIP) Event Package for Conference
State, specified in RFC 4575 [1], already defines a data model for
conferences. However, that model is SIP specific and lacks elements
related to some of the functionality defined by the XCON conferencing
framework [4] (e.g., floor control). The data model defined in this
document extends the one defined in RFC 4575 [1]. The result is a
data model that supports more call signaling protocols besides SIP
and that covers all the functionality defined in the XCON
conferencing framework [4].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
This document uses the terminology defined in the XCON Conferencing
Framework [4], the SIP conferencing framework [7] and the BFCP
(Binary Floor Control Protocol) specification [5]. Readers of this
document are supposed to be familiar with the terminology used in
those documents.
3. Overview
The data model defined in this document is the result of extending
the data model defined in RFC 4575 [1] with new elements, which carry
information such as non-SIP URIs or floor-control-related parameters.
This data model can be used by conference servers providing different
types of basic conferences. It is expected that this data model can
be further extended with new elements in the future in order to
implement advanced features.
3.1. Data Model Structure
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).
Novo, et al. Expires October 19, 2007 [Page 6]
Internet-Draft Data Model Schema April 2007
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.
Novo, et al. Expires October 19, 2007 [Page 7]
Internet-Draft Data Model Schema April 2007
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,
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.
They MAY also assume different roles in the same floor, as floor
transactions are processed.
3.2.2. Changing Roles
Users can change roles during a conference. This can be done in two
ways: First, the user can join a new floor in a different role.
Second, an "administrator" or "creator" can dynamically change that
user's role. This can be accomplished before the conference is
instantiated, or during the conference, using an appropriate
conference control protocol. A logical entity whose role has been
changed will typically have access to the media streams associated
with that role.
4. Data Model Definition
A conference object document is an XML [8] document that MUST be well
formed and SHOULD be valid. Conference object data model documents
MUST be based on XML 1.0 and SHOULD be encoded using UTF-8.
A conference object document begins with the root element tag
<conference-info>, which is defined in [1]. The <conference-info>
element has an 'entity' attribute that contains a conference object
identifier (XCON-URI) that identifies the conference being described
in the document.
A conferencing system may maintain a relationship between the
conference object identifiers and the identifiers associated with
each of the complimentary centralized conferencing protocols (e.g.,
call signaling protocols, BFCP, etc.).
This implicit binding provides a structured mapping of the various
Novo, et al. Expires October 19, 2007 [Page 8]
Internet-Draft Data Model Schema April 2007
protocols with the associated conference object Identifier. Figure 2
illustrates the relationship between the identifiers used for the
protocols within the framework [4] and the general XCON-URI.
+--------------------------+
| Conference |
| Object |
| Identifier |
+--------------------------+
| xcon:Ji092i@example.com |
+------+-------------------+
|
|
|
+-----------------+---------------+
| |
+-----------+-----------+ +-------+-------+
| CSP Conference IDs | | BFCP 'confid' |
+-----------------------+ +---------------+
|h323:Ji092i@example.com| | Ji092i |
|tel:+44(0)2920930033 | +-------+-------+
|sip:Ji092i@example.com | |
+-----------------------+ +-------|-------+
| BFCP 'floorid |
+---------------+
| UEK78d |
| 09cnJk |
+---------------+
Figure 2: Conference Object Mapping
Further elements can be added to the tree representation in Figure 2
to enable a complete representation of a conference instance within a
conferencing system.
The <conference-info> element contains the <conference-description>,
<host-info>, <conference-state>, <floor-information>, <users>,
<sidebars-by-ref>, <sidebars-by-val> child elements. All these
elements, except <floor-information>, are defined in [1]. A
conference document MUST at least include the <conference-
description>, <host-info>, <conference-state>, and <users> child
elements.
The following non-normative diagram shows the structure of conference
object documents. The operator "!" preceding an element indicates
that the element is mandatory in the data model. The operator "*"
Novo, et al. Expires October 19, 2007 [Page 9]
Internet-Draft Data Model Schema April 2007
following an element indicates that the element is introduced and
defined in this document. That is, elements without a "*" have
already been defined in RFC 4575 [1].
!<conference-info>
|
|--!<conference-description>
| |--<display-text>
| |--<subject>
| |--<free-text>*
| |--<keywords>
| |--<allow-sidebars>*
| |--<conference-time>*
| | |--<entry>*
| | | |--<base>*
| | | |--<mixing-start-offset>*
| | | |--<mixing-end-offset>*
| | | |--<can-join-after-offset>*
| | | |--<must-join-before-offset>*
| | | |--<request-user>*
| | | |--<notify-end-of-conference>*
| | | |--<allowed-extend-mixing-end-offset>*
| | ...
| |--<conf-uris>
| | |--<entry>*
| | | |--<uri>
| | | |--<display-text>
| | | |--<purpose>
| | |--<H323>*
| | | |--<H.323-alias>*
| | | |--<H.323-URI>*
| | |--<PSTN-ISDN>*
| | | |--<phone number>*
| | ...
| |--<service-uris>
| | |--<entry>*
| | | |--<uri>
| | | |--<display-text>
| | | |--<purpose>
| | |--<H323>*
| | | |--<H.323-alias>*
| | | |--<H.323-URI>*
| | |--<PSTN-ISDN>*
| | | |--<phone number>*
| | ...
| |--<maximum-user-count>
| | ...
| |--!<available-media>
Novo, et al. Expires October 19, 2007 [Page 10]
Internet-Draft Data Model Schema April 2007
| | |--!<entry>
| | | |--<type>
| | | |--<display-text>
| | | |--<status>
| | | |--<mixing-mode>*
| | | |--<mix-level>*
| | | |--<codecs>*
| | | | |--<entry>*
| | | | |--<entry>*
| | | | ...
| | | |--<controls>*
| | | | |--<mute>*
| | | | |--<gain>*
| | | | ...
| | |--<entry>
| | | |--<type>
| | | |--<display-text>
| | | |--<status>
| | | |--<mixing-mode>*
| | | |--<mix-level>*
| | | |--<codecs>*
| | | | |--<entry>*
| | | | |--<entry>*
| | | | ...
| | | |--<controls>*
| | | | |--<pause-video>*
| | | | |--<video-layout>*
| | | | ...
| | ...
|
|--<host-info>
| |--<display-text>
| |--<web-page>
| |--!<uris>
| | |--!<entry>
| | | |--!<uri>
| | | |--<display-text>
| | |--<H323>*
| | | |--<H.323-alias>*
| | | |--<H.323-URI>*
| | |--<PSTN-ISDN>*
| | | |--<phone number>*
| ...
|--<conference-state>
| |--<allow-conference-event-subscription>*
| |--<user-count>
| |--!<active>
| |--<locked>
Novo, et al. Expires October 19, 2007 [Page 11]
Internet-Draft Data Model Schema April 2007
|
|--<floor-information>*
| |--<conference-ID>*
| |--<allow-floor-events>*
| |--<floor-request-handling>*
| |--<conference-floor-policy>*
| | |--<floor>*
| | | |--<media-types>*
| | | |--<algorithm>*
| | | |--<max-floor-users>*
| | | |--<chair-id>*
| | | |--<chair-id>*
| | | ...
| | ...
|
|--!<users>
| |--<join-handling>*
| |--<user-admission-policy>*
| |--<allowed-users-list>*
| | |--<target>*
| | |-- ...
| |
| |
| |--!<user>
| | |--<display-text>
| | |--<associated-aors>
| | |--<provide-anonymity>*
| | |--<roles>
| | | |
| | | ...
| | |--<languages>
| | |--<cascaded-focus>
| | |--<allow-refer-users-dynamically>*
| | |--<allow-invite-users-dynamically>*
| | |--<allow-remove-users-dynamically>*
| | |--!<endpoint>
| | | |--<display-text>
| | | |--<referred>
| | | |--<status>
| | | |--<joining-method>
| | | |--<joining-info>
| | | |--<disconnection-method>
| | | |--<disconnection-info>
| | | |--!<media>
| | | | |--<type>
| | | | |--<display-text>
| | | | |--<label>
| | | | |--<src-id>
Novo, et al. Expires October 19, 2007 [Page 12]
Internet-Draft Data Model Schema April 2007
| | | | |--<status>
| | | | |--<to-mixer>*
| | | | | |--<floor>*
| | | | | |--<controls>*
| | | | | | |--<mute>*
| | | | | | |--<gain>*
| | | | | | ...
| | | | |--<from-mixer>*
| | | | | |--<floor>*
| | | | | |--<controls>*
| | | | | | |--<pause-video>*
| | | | | | ...
| | | | ...
| | | |--<call-info>
| | | | |--<sip>
| | | | | |--<display-text>
| | | | | |--<call-id>
| | | | | |--<from-tag>
| | | | | |--<to-tag>
| ... ...
|--<sidebars-by-ref>
| |--<entry>
| | |-- <user>
| | |-- <display-text>
| |--<entry>
| | |-- <user>
| | |-- <display-text>
| ...
|--<sidebars-by-val>
| |--<entry>
| | |
| | ...
| |--<entry>
| | |
| ... ...
The following sections describe these elements in detail. The full
Relax NG schema is provided Section 5.
4.1. <conference-description>
The <conference-description> element, which is defined in [1],
describes the conference as a whole. It SHOULD have an extra
attribute 'xml:lang' to specify the language used in the contents of
this element as defined in Section 2.12 of [8]. It is comprised of
<display-text>, <subject>, <free-text>, <keywords>, <allow-sidebars>,
<conference-time>, <conf-uris>, <service-uris>, <maximum-user-count>,
Novo, et al. Expires October 19, 2007 [Page 13]
Internet-Draft Data Model Schema April 2007
and <available-media>.
The <display-text>, <subject>, <free-text> and <keywords> elements
are defined in [1]. They are used to describe the conference's
content.
The child element <allow-sidebars> describes the capabilities of the
conference.
The <conference-time> child element contains information related to
conference time and duration of the conference. The <conf-uris> and
<service-uris> are used to describe the conference-related
identifiers. The <maximum-user-count> child element indicates the
number of users that can be invited to the conference. The
<available-media> child element is used to describe the media
characteristics of the conference.
The following sections describe these elements in more detail. Other
child elements MAY be defined in the future to extend the
<conference-description> element.
4.1.1. <conference-time>
The <conference-time> element contains the information related to
conference time and duration of a conference. The <conference-time>
element contains one or more <entry> elements each defining the time
information specifying a single conference occurrence.
Every <entry> element contains a <mixing-start-offset> child element
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
Novo, et al. Expires October 19, 2007 [Page 14]
Internet-Draft Data Model Schema April 2007
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.
It is possible to define the time when users or resources on the
<allowed-users-list> is requested to join the conference by using the
<request-users> element. This element expresses the offset as signed
integers representing seconds before/after DTSTART field.
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 before/after DTSTART field. The <allowed-
extend-mixing-end-offset> refers to the possibility to extend the
conference. It has two values: "allowed", "denied".
4.1.2. <conf-uris>
The <conf-uris> contains the identifiers to be used in order to
access the conference by different signaling means. It 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. 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
Novo, et al. Expires October 19, 2007 [Page 15]
Internet-Draft Data Model Schema April 2007
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>
The <service-uris> describes auxiliary services available for the
conference. It contains a sequence of child elements: <entry>,
<H.323>, and <PSTN-ISDN>. The <entry> child element contains <uri>,
<display-text>, and <purpose>. The purpose will be used to describe
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>
The <maximum-user-count> contains the overall number of users allowed
to join the conference. Note that this value is set by an
administrator and can reflect any local policies such as network
consumption, CPU processing power, and licensing rules.
4.1.5. <available-media>
The <available-media> has the 'label' attribute that is the media
stream identifier assigned by the conferencing server. This element
contains a sequence of <entry> child elements of conference-medium-
type. Each <entry> element contains the <type>, <display-text>,
<status>, <mixing-mode>, <mix-level>, <controls> and <codecs> child
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
Novo, et al. Expires October 19, 2007 [Page 16]
Internet-Draft Data Model Schema April 2007
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.
Novo, et al. Expires October 19, 2007 [Page 17]
Internet-Draft Data Model Schema April 2007
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
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
Novo, et al. Expires October 19, 2007 [Page 18]
Internet-Draft Data Model Schema April 2007
streams are preserved.
multiple-4x4: Sixteen equal-sized panels in a 4x4 layout is presented
by the focus to all participants. Typically the aspect ratio of the
streams are preserved.
multiple-5x1: This option refers to a 5x1 layout where one panel will
occupy 4/9 of the mixed video stream while the others will each
occupy 1/9 of the stream. Typically the aspect ratio of the streams
is preserved.
automatic: This option allows the focus to add panels as streams are
added up to a limit of "panels".
4.2. <host-info>
The <host-info> element contains information about the entity hosting
the conference. This information is set before the conference
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>
The <conference-state> element and the <user-count>, <active>, and
<locked> child elements are explained in section 5.5 of [1]. The
<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>
The <floor-information> element has the <conference-ID>, <allow-
floor-events>, <floor-request-handling>, and <conference-floor-
policy> child elements. Other elements from different namespaces MAY
be present for the purposes of extensibility. This element has its
own XML namespace. The absence of this namespace and its elements
from an XML document indicates that the conference does not have a
floor.
Novo, et al. Expires October 19, 2007 [Page 19]
Internet-Draft Data Model Schema April 2007
The <conference-ID> is used by a floor control server to provide a
client with a conference ID.
The <allow-floor-events> element represents a boolean action. If set
to TRUE, the focus is instructed to accept the subscription to floor
control events. If set to FALSE, the focus is instructed to reject
the subscription. If this element is undefined, it has a default
value of FALSE, causing the subscription to floor control events to
be rejected.
The <floor-request-handling> element defines the actions used by the
conference focus to control floor requests. This element defines the
action that the focus is to take when processing a particular request
to a floor within a conference. This element defines values of:
o "block": This action instructs the focus to deny the floor
request. This action is the default action taken in the absence
of any other actions.
o "confirm": This action instructs the focus to allow the request.
The focus then uses the defined floor algorithm to further allow
or deny the floor. The algorithms used are outside the scope of
this document.
Note that placing a value of "block" for this element does not
guarantee that a participant is blocked from joining the conference.
Any other rule that might 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 <conference-floor-policy> element is mandatory and contains the
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
<algorithm> element MUST contain one and only one of the <moderator-
controlled>, <FCFS>, and <random> elements indicating the algorithm.
The <max-floor-users> child element in the <floor> element is
Novo, et al. Expires October 19, 2007 [Page 20]
Internet-Draft Data Model Schema April 2007
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>
The <users> element contains the <join-handling>, <user-admission-
policy>, <allowed-users-list>, and <user> child elements.
The <join-handling> element defines the actions used by the
conference focus to control conference participation. This element
defines the action that the focus is to take when processing a
particular request to join a conference. This element defines values
of:
o "block": This action instructs the focus to deny access to the
conference. This action is the default action taken in the
absence of any other actions.
o "confirm": This action instructs the focus to place the
participant on a pending list (e.g., by parking the call on a
music-on-hold server), awaiting moderator input for further
actions.
o "allow": This action instructs the focus to accept the conference
join request and grant access to the conference within the
instructions specified in the transformations of this rule.
o "IVR": This action instructs the focus that the user has to
provide the PIN code.
o "directed-operator": This action instructs the focus to direct the
user to an operator.
Note that placing a value of block for this element does not
guarantee that a participant is blocked from joining the conference.
Any other rule that might 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
a participant with appropriate rights) choose a policy for the
conference that controls how users are allowed into the conference.
A 'closedAuthenticated' policy requires each conference participant
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
Novo, et al. Expires October 19, 2007 [Page 21]
Internet-Draft Data Model Schema April 2007
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
detail. Other child elements can be used to extend <conference-
description> in the future.
4.5.1. <allowed-users-list>
The <allowed-users-list> child element contains a list of user URIs,
PSTN phone numbers, roles, or domains (*@example.com) that the focus
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
conference. The <allowed-users-list> element includes zero or more
<target> child elements. This child element includes the mandatory
'uri' attribute and the mandatory 'method' attribute. The same 'uri'
attribute with different method values can appear in the list more
than once. The 'method' attribute is a list with the following
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"
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>
The element <user> describes a single participant in the conference.
The following elements of <user> are defined in [1], section 5.6:
<display-text>, <associated-aors>, <roles>, <languages>, <cascaded-
focus>, and <endpoint>. <user> has two attributes: 'entity' and
'state'. The attribute 'state' is defined in [1], section 5.6. The
attribute 'entity' contains a unique conference user identifier.
Other user identifiers can be associated with this conference user
Novo, et al. Expires October 19, 2007 [Page 22]
Internet-Draft Data Model Schema April 2007
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
required and this information is just included as a guideline that
can be used.
+--------------+
| Conference |
| User |
| Identifier |
+--------------+
| John |
+------+-------+
|
|
|
+---------------------+---------------------+
| | |
+-------+--------+ +-------+-------+ +--------+-------+
| BFCP User ID | | SIP User ID | | H323 User ID |
+----------------+ +---------------+ +----------------+
| HK37ihdaj | | 123674 | | 928373 |
+----------------+ +---------------+ +----------------+
Figure 4: Conference Object Mapping
The <provide-anonymity> element provides anonymity to the user. In
this case, the focus provides to the rest of the participants an
anonymous identity for that user, for example anonymousX. This
element only affects the way the user information is shown to the
oher participants. The real information about the user is still
stored in the data model. This can be achieved by using the
<provide-anonymity> element. It is a boolean transformation. If set
to TRUE, the conference participants will see an anonymous identity
for the user whose identity is present in the conditions.
The <endpoint> child element 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 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
Novo, et al. Expires October 19, 2007 [Page 23]
Internet-Draft Data Model Schema April 2007
following section.
4.5.2.1. <from-mixer>, <to-mixer>
Similar to the controls defined in the <available-media> element,
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
elements.
4.5.2.1.1. <floor>
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.
4.5.3. <sidebars-by-ref>
The <sidebars-by-ref> element contains a set of <entry> child
elements. Each <entry> child element contains a <user> child element
with a sidebar unique conference user identifier and a <display-text>
child element.
4.5.4. <sidebars-by-val>
The <sidebars-by-val> element contains a set of <entry> child
elements each containing information about a single sidebar. By
using this element, the server can include a full or partial
description of each sidebar (as a sub-conference) in the body of the
main conference document.
Novo, et al. Expires October 19, 2007 [Page 24]
Internet-Draft Data Model Schema April 2007
5. RELAX NG Schema
In accordance with the XCON framework document [4], the Conference
Object is a logical representation of a conference instance. The
conference information schema contains core information that is
utilized in any conference. It also contains the variable
information part of the Conference Object.
This specification defines some document fragments in RELAX NG
format.
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace local = ""
namespace ns1 = "urn:ietf:params:xml:ns:conference-info-urn"
default namespace ns2 = "urn:ietf:params:xml:ns:conference-schema"
start = element conference-info { conference-type }
# CONFERENCE TYPE
conference-type =
attribute entity { text },
attribute version { xsd:unsignedInt }?,
attribute state { state-type }?,
conference-description-type,
element host-info { host-type }?,
element conference-state { conference-state-type }?,
element floor-information { floor-information-type }?,
element users { users-type },
element sidebars-by-ref { sidebars-by-ref-type }?,
element sidebars-by-val { sidebars-by-val-type }?,
anyElement*
# CONFERENCE DESCRIPTION TYPE
conference-description-type =
element conference-description {
attribute xml:lang { xsd:language }?,
attribute state { state-type }?,
element display-text { text }?,
element subject { text }?,
element free-text { text }?,
element keywords {
list { xsd:string* }
}?,
element allow-sidebars { xsd:boolean }?,
element conference-time { conferencetime-type }?,
element conf-uris { uris-type }?,
element service-uris { uris-type }?,
element maximum-user-count { xsd:int }?,
element available-media { conference-media-type }?,
anyElement*
Novo, et al. Expires October 19, 2007 [Page 25]
Internet-Draft Data Model Schema April 2007
}
# CONFERENCE TIME
conferencetime-type =
element entry {
element base { text }?,
element mixing-start-offset {
xsd:dateTime { pattern = ".+T.+Z.*" },
attribute required-participant { single-role-type },
anyAttribute
}?,
element mixing-end-offset {
xsd:dateTime { pattern = ".+T.+Z.*" },
attribute required-participant { single-role-type },
anyAttribute
}?,
element can-join-after-offset {
xsd:dateTime { pattern = ".+T.+Z.*" }
}?,
element must-join-before-offset {
xsd:dateTime { pattern = ".+T.+Z.*" }
}?,
element notify-end-of-conference { xsd:int }?,
element allowed-extend-mixing-end-offset {
allowed-extend-mixing-values
}?,
anyElement*
}*,
anyElement*
# ALLOWED EXTEND MIXING VALUES
allowed-extend-mixing-values =
xsd:string "allowed" | xsd:string "denied"
# URIS TYPE
uris-type =
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 }?,
Novo, et al. Expires October 19, 2007 [Page 26]
Internet-Draft Data Model Schema April 2007
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 =
attribute state { state-type }?,
element entry { conference-medium-type }*,
anyElement*
# CONFERENCE MEDIUM TYPE
conference-medium-type =
attribute label { text },
element display-text { text }?,
element type { text }?,
element status { media-status-type }?,
element mixing-mode { mix-mode-type }?,
element mix-level { xsd:unsignedInt }?,
element codecs { codecs-type }?,
element controls { controls-type }?,
anyElement*
# CONTROLS TYPE
controls-type =
attribute state { state-type }?,
element control { control-type }*,
anyElement*
# MIX MODE TYPE
mix-mode-type =
xsd:string "moderator-controlled"
| xsd:string "FCFS"
| xsd:string "automatic"
# CODECS TYPE
codecs-type =
attribute decision { decision-type },
element codec { codec-type }*,
anyElement*
# CODEC TYPE
codec-type =
attribute name { text },
attribute policy { policy-type }
# DECISION TYPE
decision-type =
xsd:string "automatic" | xsd:string "moderator-controlled"
# POLICY TYPE
policy-type = xsd:string "allowed" | xsd:string "disallowed"
# CONTROL TYPE
Novo, et al. Expires October 19, 2007 [Page 27]
Internet-Draft Data Model Schema April 2007
control-type =
element mute { xsd:boolean }
| element pause-video { xsd:boolean }
| element gain {
xsd:int { minInclusive = "-127" maxInclusive = "127" }
}
| element video-layout {
xsd:string "single-view"
| xsd:string "dual-view"
| xsd:string "dual-view-crop"
| xsd:string "dual-view-2x1"
| xsd:string "dual-view-2x1-crop"
| xsd:string "quad-view"
| xsd:string "multiple-3x3"
| xsd:string "multiple-4x4"
| xsd:string "multiple-5x1"
| xsd:string "automatic"
}
| anyElement*
# HOST TYPE
host-type =
(element display-text { text },
element web-page { xsd:anyURI },
element uris { uris-type },
anyElement*)*
# CONFERENCE STATE TYPE
conference-state-type =
element allow-conference-event-subscription { xsd:boolean }?,
element user-count { xsd:unsignedInt }?,
element active { xsd:boolean }?,
element locked { xsd:boolean }?,
anyElement*
# FLOOR INFORMATION TYPE
floor-information-type =
(element conference-ID { xsd:unsignedInt },
element allow-floor-events { xsd:boolean },
element floor-request-handling { floor-request-type },
element conference-floor-policy { Conference-floor-policy },
anyElement*)*
# FLOOR REQUEST TYPE
floor-request-type = xsd:string "block" | xsd:string "confirm"
# CONFERENCE FLOOR POLICY
Conference-floor-policy =
element floor {
attribute moderator-controlled { xsd:boolean },
attribute label { text },
anyAttribute,
(element media-types {
Novo, et al. Expires October 19, 2007 [Page 28]
Internet-Draft Data Model Schema April 2007
xsd:string "video"
| 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 "FCFS"
| xsd:string "random"
},
element max-floor-users { xsd:nonNegativeInteger },
element chair-id { xsd:anyURI },
anyElement*)*
}+
# USERS TYPE
users-type =
attribute state { state-type }?,
element join-handling { join-handling-type }?,
element user-admission-policy { user-admission-policy-type }?,
element user-must-be-specified { xsd:boolean }?,
element allowed-users-list { UserList }?,
element user { user-type }*,
anyElement*
# USERS ADMISSION POLICY
user-admission-policy-type =
xsd:string "closedAuthenticated"
| xsd:string "openAuthenticated"
| xsd:string "anonymous"
# JOIN HANDLING TYPE
join-handling-type =
xsd:string "block"
| xsd:string "allow"
| xsd:string "confirm"
| xsd:string "IVR"
| xsd:string "directed-operator"
# USERLIST
UserList =
element target { target-type }*,
anyElement*
# TARGET TYPE
target-type =
attribute uri { xsd:anyURI },
attribute method { method-type }
# METHOD TYPE
method-type =
Novo, et al. Expires October 19, 2007 [Page 29]
Internet-Draft Data Model Schema April 2007
xsd:string "dial-in" | xsd:string "dial-out" | xsd:string "refer"
# USER TYPE
user-type =
attribute entity { xsd:anyURI },
attribute state { state-type }?,
element display-text { text }?,
element associated-aors { uris-type }?,
element provide-anonymity { xsd:boolean }?,
element roles { roles-type }?,
element languages {
list { xsd:language }
}?,
element cascaded-focus { xsd:anyURI }?,
element allow-refer-users-dynamically { xsd:boolean }?,
element allow-invite-users-dynamically { xsd:boolean }?,
element allow-remove-users-dynamically { xsd:boolean }?,
element endpoint { endpoint-type }*,
anyElement*
# ENDPOINT TYPE
endpoint-type =
attribute entity { text },
attribute state { state-type }?,
element display-text { text }?,
element referred { conference-info-urn* }?,
element status { endpoint-status-type }?,
element joining-method { joining-type }?,
element joining-info { conference-info-urn* }?,
element disconnection-method { disconnection-type }?,
element disconnection-info { conference-info-urn* }?,
element media { media-type }*,
element call-info { conference-info-urn* }?,
anyElement*
# MEDIA TYPE
media-type =
attribute id { xsd:int },
attribute state { state-type }?,
anyAttribute,
element display-text { text }?,
element type { text }?,
element label { text }?,
element src-id { text }?,
element status { media-status-type }?,
element to-mixer { mixer-type }?,
element from-mixer { mixer-type }?,
anyElement*
# MIXER TYPE
mixer-type =
attribute state { state-type }?,
Novo, et al. Expires October 19, 2007 [Page 30]
Internet-Draft Data Model Schema April 2007
(element floor { xsd:boolean },
element controls { controls-type })?,
anyElement*
# SIDEBARS-BY-REF TYPE
sidebars-by-ref-type =
attribute state { state-type }?,
element entry { uri-type }*,
anyElement*
# SIDEBARS-BY-VAL TYPE
sidebars-by-val-type =
attribute state { state-type }?,
element entry { conference-type }*,
anyElement*
# ROLES_TYPE
roles-type =
element entry { single-role-type }*,
anyElement*
# SINGLE ROLE TYPE
single-role-type =
xsd:string "administrator"
| xsd:string "creator"
| xsd:string "moderator"
| xsd:string "participant"
| xsd:string "observer"
# *********************************
# EXTENSIBILITY OF THE SCHEMA
# *********************************
# EXTENSIBILITY ELEMENTS
anyElement =
element * {
(attribute * { text }
| text
| anyElement)*
}
# EXTENSIBILITY ATTRIBUTES
anyAttribute =
attribute * - (entity
| version
| state
| xml:lang
| required-participant
| PIN-code
| purpose
| role
| type
| min
| max
Novo, et al. Expires October 19, 2007 [Page 31]
Internet-Draft Data Model Schema April 2007
| label
| decision
| name
| policy
| moderator-controlled
| uri
| method
| id
| domain
| local:*
| ns2:*) { text }*
# *************************************************************
# TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
# *************************************************************
# WILDCARD FOR EVENT-PACKAGE NAMESPACE
conference-info-urn =
element ns1:* {
(attribute * { text }
| conference-info-urn)*
}
# DEFINITION OF STATE TYPE
state-type = "full" | "partial" | "deleted"
# DEFINITION OF ENDPOINT STATUS TYPE
media-status-type = "recvonly" | "sendonly" | "sendrecv" | "inactive"
# ENDPOINT STATUS TYPE
endpoint-status-type =
"pending"
| "dialing-out"
| "dialing-in"
| "alerting"
| "on-hold"
| "connected"
| "muted-via-focus"
| "disconnecting"
| "disconnected"
# JOINING TYPE
joining-type = "dialed-in" | "dialed-out" | "focus-owner"
# DISCONNECTION TYPE
disconnection-type = "departed" | "booted" | "failed" | "busy"
6. XML Schema Extensibility
The Conference Information Data Model defined in this document is
meant to be extensible toward specific application domains. Such
extensions are accomplished by defining elements, child elements and
Novo, et al. Expires October 19, 2007 [Page 32]
Internet-Draft Data Model Schema April 2007
attributes that are specific to the desired application domain. The
IETF MAY extend the data model schema with extension elements from
the same namespace, but other instances are free to extend it from
other than urn:ietf:params:xml:ns:conference-schema.
Elements or attributes from unknown namespaces MUST be ignored.
7. XML Example
The following is an example of a conference information document.
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
example, there are currently 3 participants in a conference, one
administrator, one moderator, and one participant. Note that
sidebars are allowed in this conference and there is one sidebar in
the conference. Also note that there is one floor moderator for the
audio and a different floor moderator for the video.
<?xml version="1.0" encoding="UTF-8"?>
<conference-info xmlns="urn:ietf:params:xml:ns:conference-schema"
entity="conference123@example.com" state="full">
<!--
CONFERENCE DESCRIPTION
-->
<conference-description xml:lang="en-us">
<display-text>Discussion of Formula-1 racing</display-text>
<subject> Sports:Formula-1</subject>
<free-text>This is a conference example</free-text>
<keywords>Formula-1, cars</keywords>
<webpage>http://www.example.com/users/formula-1</webpage>
<security-level>low</security-level>
<allow-sidebars>true</allow-sidebars>
<conference-stage>running</conference-stage>
<!--
CONFERENCE TIME
-->
<conference-time>
<entry>
<base>BEGIN:VCALENDAR
PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20061103T140728Z
UID:20061103T140728Z-345FDA-carol@example.com
ORGANIZER:MAILTO:carol@example.com
DTSTART:20071017T143000Z
Novo, et al. Expires October 19, 2007 [Page 33]
Internet-Draft Data Model Schema April 2007
RRULE:FREQ=WEEKLY
DTEND:20071217T163000Z
END:VEVENT
END:VCALENDAR</base>
<mixing-start-offset required-participant="moderator"
> 2007-10-17T14:29:00Z</mixing-start-offset>
<mixing-end-offset required-participant="participant"
> 2007-10-17T16:31:00Z</mixing-end-offset>
<must-join-before-offset
> 2007-10-17T15:30:00Z</must-join-before-offset>
</entry>
</conference-time>
<!--
CONFERENCE UNIQUE IDENTIFIERS
-->
<conf-uris state="full">
<SIP>
<uri>tel:+3585671234</uri>
<display-text>Conference Bridge</display-text>
<purpose>participation</purpose>
</SIP>
<SIP>
<uri>http://www.example.comlive.ram</uri>
<purpose>streaming</purpose>
</SIP>
</conf-uris>
<!--
SERVICE URIS
-->
<service-uris state="full">
<SIP>
<uri>http://www.example.com/formula1/</uri>
<purpose>web-page</purpose>
</SIP>
</service-uris>
<!--
MAXIMUM USER COUNT
-->
<maximum-user-count>
<entry role="administrator">2</entry>
<entry role="moderator">5</entry>
<entry role="participant">150</entry>
</maximum-user-count>
<!--
AVAILABLE MEDIA
-->
<available-media>
<entry label="10234">
Novo, et al. Expires October 19, 2007 [Page 34]
Internet-Draft Data Model Schema April 2007
<display-text>main audio</display-text>
<type>audio</type>
<status>sendrecv</status>
<mixing-mode>automatic</mixing-mode>
<mix-level>3</mix-level>
<codecs decision="automatic">
<codec name="PCMU" policy="allowed"/>
</codecs>
</entry>
<entry label="10235">
<display-text>main video</display-text>
<type>video</type>
<status>sendrecv</status>
<mixing-mode>automatic</mixing-mode>
<mix-level>4</mix-level>
<codecs decision="automatic">
<codec name="H.263" policy="allowed"/>
</codecs>
</entry>
</available-media>
</conference-description>
<!--
HOST INFO
-->
<host-info>
<display-text>Formula1</display-text>
<web-page>http://www.example.com/formula1/</web-page>
<uris state="full">
<SIP>
<uri>sip:alice@example.com</uri>
</SIP>
<SIP>
<uri>sip:carol@example.com</uri>
</SIP>
</uris>
</host-info>
<!--
CONFERENCE STATE
-->
<conference-state>
<allow-conference-state>true</allow-conference-state>
<user-count>3</user-count>
<active>true</active>
<locked>false</locked>
</conference-state>
<!--
FLOOR INFORMATION
-->
Novo, et al. Expires October 19, 2007 [Page 35]
Internet-Draft Data Model Schema April 2007
<floor-information>
<conference-ID>567</conference-ID>
<allow-floor-events>true</allow-floor-events>
<floor-request-handling>confirm</floor-request-handling>
<conference-floor-policy>
<floor moderator-controlled="true" label="10234">
<media-types>audio</media-types>
<algorithm>moderator-controlled</algorithm>
<max-floor-users>1</max-floor-users>
<chair-id>sip:alice@example.com</chair-id>
</floor>
<floor moderator-controlled="true" label="10235">
<media-types>video</media-types>
<algorithm>moderator-controlled</algorithm>
<max-floor-users>1</max-floor-users>
<chair-id>sip:carol@example.com</chair-id>
</floor>
</conference-floor-policy>
</floor-information>
<!--
USERS
-->
<users state="full">
<join-handling>allow</join-handling>
<!--
ALLOWED USERS LIST
-->
<allowed-users-list>
<target uri="sip:bob@example.com" method="dial-out"/>
<target uri="sip:alice@example.com" method="dial-out"/>
<target uri="sip:carol@example.com" method="dial-out"/>
<target uri="sip:john@example.com" method="refer"/>
</allowed-users-list>
<!--
USER BOB
-->
<user entity="bob534" state="partial">
<display-text>Bob Hoskins</display-text>
<associated-aors state="full">
<SIP>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</SIP>
</associated-aors>
<provide-anonymity>false</provide-anonymity>
<roles>
<entry>participant</entry>
</roles>
Novo, et al. Expires October 19, 2007 [Page 36]
Internet-Draft Data Model Schema April 2007
<languages>en</languages>
<sphere value="work"/>
<allow-refer-users-dynamically
>false</allow-refer-users-dynamically>
<allow-invite-users-dynamically
>false</allow-invite-users-dynamically>
<allow-remove-users-dynamically
>false</allow-remove-users-dynamically>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@example.com" state="full">
<display-text>Bob's Laptop</display-text>
<referred>
<when>2006-10-17T14:00:00Z</when>
<reason>expert required</reason>
<by>sip:alice@example.com</by>
</referred>
<status>connected</status>
<joining-method>dialed-out</joining-method>
<joining-info>
<when>2006-10-17T14:00:00Z</when>
<reason>invitation</reason>
<by>sip:alice@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<label>10235</label>
<src-id>432424</src-id>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>hsjh8980vhsb78</call-id>
<from-tag>vav738dvbs</from-tag>
<to-tag>8954jgjg8432</to-tag>
</sip>
</call-info>
</endpoint>
</user>
<!--
Novo, et al. Expires October 19, 2007 [Page 37]
Internet-Draft Data Model Schema April 2007
USER ALICE
-->
<user entity="alice334" state="full">
<display-text>Alice Kay</display-text>
<associated-aors state="full">
<SIP>
<uri>mailto:alice@example.com</uri>
<display-text>email</display-text>
</SIP>
</associated-aors>
<provide-anonymity>false</provide-anonymity>
<roles>
<entry>moderator</entry>
</roles>
<languages>en</languages>
<sphere value="work"/>
<allow-refer-users-dynamically
>true</allow-refer-users-dynamically>
<allow-invite-users-dynamically
>true</allow-invite-users-dynamically>
<allow-remove-users-dynamically
>true</allow-remove-users-dynamically>
<!--
ENDPOINTS
-->
<endpoint entity="sip:alice@example.com" state="full">
<display-text>Alice's Desktop</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2006-10-17T13:35:08Z</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
</joining-info>
<!--
MEDIA
-->
<media id="1">
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
</media>
Novo, et al. Expires October 19, 2007 [Page 38]
Internet-Draft Data Model Schema April 2007
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>truy45469123478</call-id>
<from-tag>asd456cbgt</from-tag>
<to-tag>3456jgjg1234</to-tag>
</sip>
</call-info>
</endpoint>
</user>
<!--
USER CAROL
-->
<user entity="carol233" state="full">
<display-text>Carol More</display-text>
<associated-aors state="full">
<SIP>
<uri>mailto:carol@example.com</uri>
<display-text>email</display-text>
</SIP>
</associated-aors>
<provide-anonymity>false</provide-anonymity>
<roles>
<entry>administrator</entry>
</roles>
<languages>en</languages>
<sphere value="work"/>
<allow-refer-users-dynamically
>true</allow-refer-users-dynamically>
<allow-invite-users-dynamically
>true</allow-invite-users-dynamically>
<allow-remove-users-dynamically
>true</allow-remove-users-dynamically>
<!--
ENDPOINTS
-->
<endpoint entity="sip:carol@example.com" state="full">
<display-text>Carol's Computer</display-text>
<status>connected</status>
<joining-method>dialed-in</joining-method>
<joining-info>
<when>2006-10-17T13:30:05Z</when>
<reason>invitation</reason>
<by>sip:conference@example.com</by>
Novo, et al. Expires October 19, 2007 [Page 39]
Internet-Draft Data Model Schema April 2007
</joining-info>
<!--
MEDIA
-->
<media id="1">
<label>10235</label>
<src-id>432424</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<label>10234</label>
<src-id>532535</src-id>
<status>sendrecv</status>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>wevb12562321894</call-id>
<from-tag>asw456wedf</from-tag>
<to-tag>2365dfrt3497</to-tag>
</sip>
</call-info>
</endpoint>
</user>
</users>
<!--
SIDEBARS BY REFERENCE
-->
<sidebars-by-ref state="full">
<entry>
<uri>sips:conference123;grid=40</uri>
<display-text>private with Bob</display-text>
</entry>
</sidebars-by-ref>
<!--
SIDEBARS BY VALUE
-->
<sidebars-by-val>
<entry entity="conference123;grid=40">
<users>
<user entity="bob534"/>
<user entity="carol233"/>
</users>
</entry>
</sidebars-by-val>
Novo, et al. Expires October 19, 2007 [Page 40]
Internet-Draft Data Model Schema April 2007
</conference-info>
Note that due to RFC formatting conventions, this documents splits
lines whose content would exceed 72 characters. Two backslash
characters mark where line folding has taken place. These
backslashes would not appear in the actual XML data model.
8. Security Considerations
A malicious user can manipulate parts of the Conference Information
Data Model privileges document giving themselves and others
privileges to manipulate the data model. It is very important that
only authorized clients are able to manipulate the Conference
Information Data Model document. Any conference control protocol
MUST provide authentication, confidentiality and integrity.
9. IANA Considerations
9.1. Conference Relax NG Schema Registration
URI: urn:ietf:params:xml:ns:conference-schema
Relax NG Schema: The Relax NG schema to be registered is contained
in Section 4. Its first line is
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
and its last line is
disconnection-type = "departed" | "booted" | "failed" | "busy"
9.2. Conference Namespace Registration
URI: urn:ietf:params:xml:ns:conference-schema
9.3. Conference Object Identifier Registration
XCON_URI = "xcon" ":" [conf-object-id "@"] hostport
; hostport as defined in RFC3261
conf-object-id = 1*( unreserved / "+" / "=" / "/" )
; unreserved as defined in RFC3986
Novo, et al. Expires October 19, 2007 [Page 41]
Internet-Draft Data Model Schema April 2007
9.4. Conference User Identifier Registration
XCON_USERID = "xcon_userid" ":" conf-object-id
conf-object-id = 1*( unreserved / "+" / "=" / "/" )
; unreserved as defined in RFC3986
10. Acknowledgements
This document is really a distillation of many ideas discussed over a
long period of time. These ideas were contributed by many different
drafts in the XCON working group and the SIPPING working group. We
would like to thank Orit Levin, Adam Roach, Mary Barnes, Chris
Boulton, Umesh Chandra, Hisham Khartabil, Petri Koskelainen, Aki
Niemi, and Jari Urpilainen for their comments. Also, We would like
to thank Mary Barnes, and Chris Boulton for letting us use the
conference and user identifier information of their xcon drafts.
11. References
11.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
11.2. Informative References
[4] Barnes, M., "A Framework and Data Model for Centralized
Conferencing", draft-ietf-xcon-framework-07 (work in progress),
January 2007.
[5] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
Protocol (BFCP)", RFC 4582, November 2006.
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Novo, et al. Expires October 19, 2007 [Page 42]
Internet-Draft Data Model Schema April 2007
Notification", RFC 3265, June 2002.
[7] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
[8] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", World
Wide Web Consortium FirstEdition REC-xml-20001006, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
Appendix A. Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:conference-schema"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<element name="conference-info">
<ref name="conference-type"/>
</element>
</start>
<!--
CONFERENCE TYPE
-->
<define name="conference-type">
<attribute name="entity">
<text/>
</attribute>
<optional>
<attribute name="version">
<data type="unsignedInt"/>
</attribute>
</optional>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<ref name="conference-description-type"/>
<optional>
<element name="host-info">
<ref name="host-type"/>
</element>
</optional>
<optional>
<element name="conference-state">
Novo, et al. Expires October 19, 2007 [Page 43]
Internet-Draft Data Model Schema April 2007
<ref name="conference-state-type"/>
</element>
</optional>
<optional>
<element name="floor-information">
<ref name="floor-information-type"/>
</element>
</optional>
<element name="users">
<ref name="users-type"/>
</element>
<optional>
<element name="sidebars-by-ref">
<ref name="sidebars-by-ref-type"/>
</element>
</optional>
<optional>
<element name="sidebars-by-val">
<ref name="sidebars-by-val-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
CONFERENCE DESCRIPTION TYPE
-->
<define name="conference-description-type">
<element name="conference-description">
<optional>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</optional>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="subject">
<text/>
Novo, et al. Expires October 19, 2007 [Page 44]
Internet-Draft Data Model Schema April 2007
</element>
</optional>
<optional>
<element name="free-text">
<text/>
</element>
</optional>
<optional>
<element name="keywords">
<list>
<zeroOrMore>
<data type="string"/>
</zeroOrMore>
</list>
</element>
</optional>
<optional>
<element name="allow-sidebars">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="conference-time">
<ref name="conferencetime-type"/>
</element>
</optional>
<optional>
<element name="conf-uris">
<ref name="uris-type"/>
</element>
</optional>
<optional>
<element name="service-uris">
<ref name="uris-type"/>
</element>
</optional>
<optional>
<element name="maximum-user-count">
<data type="int"/>
</element>
</optional>
<optional>
<element name="available-media">
<ref name="conference-media-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
Novo, et al. Expires October 19, 2007 [Page 45]
Internet-Draft Data Model Schema April 2007
</zeroOrMore>
</element>
</define>
<!--
CONFERENCE TIME
-->
<define name="conferencetime-type">
<zeroOrMore>
<element name="entry">
<optional>
<element name="base">
<text/>
</element>
</optional>
<optional>
<element name="mixing-start-offset">
<data type="dateTime">
<param name="pattern">.+T.+Z.*</param>
</data>
<attribute name="required-participant">
<ref name="single-role-type"/>
</attribute>
<ref name="anyAttribute"/>
</element>
</optional>
<optional>
<element name="mixing-end-offset">
<data type="dateTime">
<param name="pattern">.+T.+Z.*</param>
</data>
<attribute name="required-participant">
<ref name="single-role-type"/>
</attribute>
<ref name="anyAttribute"/>
</element>
</optional>
<optional>
<element name="can-join-after-offset">
<data type="dateTime">
<param name="pattern">.+T.+Z.*</param>
</data>
</element>
</optional>
<optional>
<element name="must-join-before-offset">
<data type="dateTime">
<param name="pattern">.+T.+Z.*</param>
</data>
Novo, et al. Expires October 19, 2007 [Page 46]
Internet-Draft Data Model Schema April 2007
</element>
</optional>
<optional>
<element name="notify-end-of-conference">
<data type="int"/>
</element>
</optional>
<optional>
<element name="allowed-extend-mixing-end-offset">
<ref name="allowed-extend-mixing-values"/>
</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"/>
Novo, et al. Expires October 19, 2007 [Page 47]
Internet-Draft Data Model Schema April 2007
</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>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</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>
Novo, et al. Expires October 19, 2007 [Page 48]
Internet-Draft Data Model Schema April 2007
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</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>
<ref name="anyElement"/>
</zeroOrMore>
</oneOrMore>
</define>
<!--
CONFERENCE MEDIA TYPE
-->
<define name="conference-media-type">
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<zeroOrMore>
<element name="entry">
<ref name="conference-medium-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
CONFERENCE MEDIUM TYPE
-->
<define name="conference-medium-type">
<attribute name="label">
Novo, et al. Expires October 19, 2007 [Page 49]
Internet-Draft Data Model Schema April 2007
<text/>
</attribute>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="type">
<text/>
</element>
</optional>
<optional>
<element name="status">
<ref name="media-status-type"/>
</element>
</optional>
<optional>
<element name="mixing-mode">
<ref name="mix-mode-type"/>
</element>
</optional>
<optional>
<element name="mix-level">
<data type="unsignedInt"/>
</element>
</optional>
<optional>
<element name="codecs">
<ref name="codecs-type"/>
</element>
</optional>
<optional>
<element name="controls">
<ref name="controls-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
CONTROLS TYPE
-->
<define name="controls-type">
<optional>
<attribute name="state">
<ref name="state-type"/>
Novo, et al. Expires October 19, 2007 [Page 50]
Internet-Draft Data Model Schema April 2007
</attribute>
</optional>
<zeroOrMore>
<element name="control">
<ref name="control-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
MIX MODE TYPE
-->
<define name="mix-mode-type">
<choice>
<value type="string">moderator-controlled</value>
<value type="string">FCFS</value>
<value type="string">automatic</value>
</choice>
</define>
<!--
CODECS TYPE
-->
<define name="codecs-type">
<attribute name="decision">
<ref name="decision-type"/>
</attribute>
<zeroOrMore>
<element name="codec">
<ref name="codec-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
CODEC TYPE
-->
<define name="codec-type">
<attribute name="name">
<text/>
</attribute>
<attribute name="policy">
<ref name="policy-type"/>
</attribute>
</define>
Novo, et al. Expires October 19, 2007 [Page 51]
Internet-Draft Data Model Schema April 2007
<!--
DECISION TYPE
-->
<define name="decision-type">
<choice>
<value type="string">automatic</value>
<value type="string">moderator-controlled</value>
</choice>
</define>
<!--
POLICY TYPE
-->
<define name="policy-type">
<choice>
<value type="string">allowed</value>
<value type="string">disallowed</value>
</choice>
</define>
<!--
CONTROL TYPE
-->
<define name="control-type">
<choice>
<element name="mute">
<data type="boolean"/>
</element>
<element name="pause-video">
<data type="boolean"/>
</element>
<element name="gain">
<data type="int">
<param name="minInclusive">-127</param>
<param name="maxInclusive">127</param>
</data>
</element>
<element name="video-layout">
<choice>
<value type="string">single-view</value>
<value type="string">dual-view</value>
<value type="string">dual-view-crop</value>
<value type="string">dual-view-2x1</value>
<value type="string">dual-view-2x1-crop</value>
<value type="string">quad-view</value>
<value type="string">multiple-3x3</value>
<value type="string">multiple-4x4</value>
<value type="string">multiple-5x1</value>
<value type="string">automatic</value>
</choice>
Novo, et al. Expires October 19, 2007 [Page 52]
Internet-Draft Data Model Schema April 2007
</element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</choice>
</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
-->
<define name="conference-state-type">
<optional>
<element name="allow-conference-event-subscription">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="user-count">
<data type="unsignedInt"/>
</element>
</optional>
<optional>
<element name="active">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="locked">
<data type="boolean"/>
</element>
Novo, et al. Expires October 19, 2007 [Page 53]
Internet-Draft Data Model Schema April 2007
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
FLOOR INFORMATION TYPE
-->
<define name="floor-information-type">
<zeroOrMore>
<element name="conference-ID">
<data type="unsignedInt"/>
</element>
<element name="allow-floor-events">
<data type="boolean"/>
</element>
<element name="floor-request-handling">
<ref name="floor-request-type"/>
</element>
<element name="conference-floor-policy">
<ref name="Conference-floor-policy"/>
</element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</zeroOrMore>
</define>
<!--
FLOOR REQUEST TYPE
-->
<define name="floor-request-type">
<choice>
<value type="string">block</value>
<value type="string">confirm</value>
</choice>
</define>
<!--
CONFERENCE FLOOR POLICY
-->
<define name="Conference-floor-policy">
<oneOrMore>
<element name="floor">
<attribute name="moderator-controlled">
<data type="boolean"/>
</attribute>
<attribute name="label">
<text/>
</attribute>
Novo, et al. Expires October 19, 2007 [Page 54]
Internet-Draft Data Model Schema April 2007
<ref name="anyAttribute"/>
<zeroOrMore>
<element name="media-types">
<choice>
<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 name="algorithm">
<choice>
<value type="string">moderator-controlled</value>
<value type="string">FCFS</value>
<value type="string">random</value>
</choice>
</element>
<element name="max-floor-users">
<data type="nonNegativeInteger"/>
</element>
<element name="chair-id">
<data type="anyURI"/>
</element>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</zeroOrMore>
</element>
</oneOrMore>
</define>
<!--
USERS TYPE
-->
<define name="users-type">
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional>
<element name="join-handling">
<ref name="join-handling-type"/>
</element>
</optional>
<optional>
Novo, et al. Expires October 19, 2007 [Page 55]
Internet-Draft Data Model Schema April 2007
<element name="user-admission-policy">
<ref name="user-admission-policy-type"/>
</element>
</optional>
<optional>
<element name="user-must-be-specified">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="allowed-users-list">
<ref name="UserList"/>
</element>
</optional>
<zeroOrMore>
<element name="user">
<ref name="user-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
USERS ADMISSION POLICY
-->
<define name="user-admission-policy-type">
<choice>
<value type="string">closedAuthenticated</value>
<value type="string">openAuthenticated</value>
<value type="string">anonymous</value>
</choice>
</define>
<!--
JOIN HANDLING TYPE
-->
<define name="join-handling-type">
<choice>
<value type="string">block</value>
<value type="string">allow</value>
<value type="string">confirm</value>
<value type="string">IVR</value>
<value type="string">directed-operator</value>
</choice>
</define>
<!--
USERLIST
-->
Novo, et al. Expires October 19, 2007 [Page 56]
Internet-Draft Data Model Schema April 2007
<define name="UserList">
<zeroOrMore>
<element name="target">
<ref name="target-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
TARGET TYPE
-->
<define name="target-type">
<attribute name="uri">
<data type="anyURI"/>
</attribute>
<attribute name="method">
<ref name="method-type"/>
</attribute>
</define>
<!--
METHOD TYPE
-->
<define name="method-type">
<choice>
<value type="string">dial-in</value>
<value type="string">dial-out</value>
<value type="string">refer</value>
</choice>
</define>
<!--
USER TYPE
-->
<define name="user-type">
<attribute name="entity">
<data type="anyURI"/>
</attribute>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
Novo, et al. Expires October 19, 2007 [Page 57]
Internet-Draft Data Model Schema April 2007
<optional>
<element name="associated-aors">
<ref name="uris-type"/>
</element>
</optional>
<optional>
<element name="provide-anonymity">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="roles">
<ref name="roles-type"/>
</element>
</optional>
<optional>
<element name="languages">
<list>
<data type="language"/>
</list>
</element>
</optional>
<optional>
<element name="cascaded-focus">
<data type="anyURI"/>
</element>
</optional>
<optional>
<element name="allow-refer-users-dynamically">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="allow-invite-users-dynamically">
<data type="boolean"/>
</element>
</optional>
<optional>
<element name="allow-remove-users-dynamically">
<data type="boolean"/>
</element>
</optional>
<zeroOrMore>
<element name="endpoint">
<ref name="endpoint-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
Novo, et al. Expires October 19, 2007 [Page 58]
Internet-Draft Data Model Schema April 2007
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
ENDPOINT TYPE
-->
<define name="endpoint-type">
<attribute name="entity">
<text/>
</attribute>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="referred">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</optional>
<optional>
<element name="status">
<ref name="endpoint-status-type"/>
</element>
</optional>
<optional>
<element name="joining-method">
<ref name="joining-type"/>
</element>
</optional>
<optional>
<element name="joining-info">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</optional>
<optional>
<element name="disconnection-method">
<ref name="disconnection-type"/>
</element>
Novo, et al. Expires October 19, 2007 [Page 59]
Internet-Draft Data Model Schema April 2007
</optional>
<optional>
<element name="disconnection-info">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</optional>
<zeroOrMore>
<element name="media">
<ref name="media-type"/>
</element>
</zeroOrMore>
<optional>
<element name="call-info">
<zeroOrMore>
<ref name="conference-info-urn"/>
</zeroOrMore>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
MEDIA TYPE
-->
<define name="media-type">
<attribute name="id">
<data type="int"/>
</attribute>
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<ref name="anyAttribute"/>
<optional>
<element name="display-text">
<text/>
</element>
</optional>
<optional>
<element name="type">
<text/>
</element>
</optional>
<optional>
Novo, et al. Expires October 19, 2007 [Page 60]
Internet-Draft Data Model Schema April 2007
<element name="label">
<text/>
</element>
</optional>
<optional>
<element name="src-id">
<text/>
</element>
</optional>
<optional>
<element name="status">
<ref name="media-status-type"/>
</element>
</optional>
<optional>
<element name="to-mixer">
<ref name="mixer-type"/>
</element>
</optional>
<optional>
<element name="from-mixer">
<ref name="mixer-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
MIXER TYPE
-->
<define name="mixer-type">
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<optional>
<element name="floor">
<data type="boolean"/>
</element>
<element name="controls">
<ref name="controls-type"/>
</element>
</optional>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
Novo, et al. Expires October 19, 2007 [Page 61]
Internet-Draft Data Model Schema April 2007
</define>
<!--
SIDEBARS-BY-REF TYPE
-->
<define name="sidebars-by-ref-type">
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<zeroOrMore>
<element name="entry">
<ref name="uri-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
SIDEBARS-BY-VAL TYPE
-->
<define name="sidebars-by-val-type">
<optional>
<attribute name="state">
<ref name="state-type"/>
</attribute>
</optional>
<zeroOrMore>
<element name="entry">
<ref name="conference-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</define>
<!--
ROLES_TYPE
-->
<define name="roles-type">
<zeroOrMore>
<element name="entry">
<ref name="single-role-type"/>
</element>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement"/>
Novo, et al. Expires October 19, 2007 [Page 62]
Internet-Draft Data Model Schema April 2007
</zeroOrMore>
</define>
<!--
SINGLE ROLE TYPE
-->
<define name="single-role-type">
<choice>
<value type="string">administrator</value>
<value type="string">creator</value>
<value type="string">moderator</value>
<value type="string">participant</value>
<value type="string">observer</value>
</choice>
</define>
<!--
*********************************
EXTENSIBILITY OF THE SCHEMA
*********************************
-->
<!--
EXTENSIBILITY ELEMENTS
-->
<define name="anyElement">
<element>
<anyName/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="anyElement"/>
</choice>
</zeroOrMore>
</element>
</define>
<!--
EXTENSIBILITY ATTRIBUTES
-->
<define name="anyAttribute">
<zeroOrMore>
<attribute>
<anyName>
<except>
<name ns="">entity</name>
<name ns="">version</name>
<name ns="">state</name>
<name ns="">xml:lang</name>
Novo, et al. Expires October 19, 2007 [Page 63]
Internet-Draft Data Model Schema April 2007
<name ns="">required-participant</name>
<name ns="">PIN-code</name>
<name ns="">purpose</name>
<name ns="">role</name>
<name ns="">type</name>
<name ns="">min</name>
<name ns="">max</name>
<name ns="">label</name>
<name ns="">decision</name>
<name ns="">name</name>
<name ns="">policy</name>
<name ns="">moderator-controlled</name>
<name ns="">uri</name>
<name ns="">method</name>
<name ns="">id</name>
<name ns="">domain</name>
<nsName ns=""/>
<nsName ns="urn:ietf:params:xml:ns:conference-schema"/>
</except>
</anyName>
<text/>
</attribute>
</zeroOrMore>
</define>
<!--
*************************************************************
TYPES DEFINED IN THE EVENT PACKAGE FOR CONFERENCE STATE
*************************************************************
-->
<!--
WILDCARD FOR EVENT-PACKAGE NAMESPACE
-->
<define name="conference-info-urn">
<element>
<nsName ns="urn:ietf:params:xml:ns:conference-info-urn"/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<ref name="conference-info-urn"/>
</choice>
</zeroOrMore>
</element>
</define>
<!--
DEFINITION OF STATE TYPE
-->
Novo, et al. Expires October 19, 2007 [Page 64]
Internet-Draft Data Model Schema April 2007
<define name="state-type">
<choice>
<value>full</value>
<value>partial</value>
<value>deleted</value>
</choice>
</define>
<!--
DEFINITION OF ENDPOINT STATUS TYPE
-->
<define name="media-status-type">
<choice>
<value>recvonly</value>
<value>sendonly</value>
<value>sendrecv</value>
<value>inactive</value>
</choice>
</define>
<!--
ENDPOINT STATUS TYPE
-->
<define name="endpoint-status-type">
<choice>
<value>pending</value>
<value>dialing-out</value>
<value>dialing-in</value>
<value>alerting</value>
<value>on-hold</value>
<value>connected</value>
<value>muted-via-focus</value>
<value>disconnecting</value>
<value>disconnected</value>
</choice>
</define>
<!--
JOINING TYPE
-->
<define name="joining-type">
<choice>
<value>dialed-in</value>
<value>dialed-out</value>
<value>focus-owner</value>
</choice>
</define>
<!--
DISCONNECTION TYPE
-->
<define name="disconnection-type">
Novo, et al. Expires October 19, 2007 [Page 65]
Internet-Draft Data Model Schema April 2007
<choice>
<value>departed</value>
<value>booted</value>
<value>failed</value>
<value>busy</value>
</choice>
</define>
</grammar>
Authors' Addresses
Oscar Novo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Oscar.Novo@ericsson.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
David P. Morgan
Fidelity Investments
82 Devonshire St, MZ V3C
Boston, MA 02109-3614
USA
Email: Dave.Morgan@fmr.com
Novo, et al. Expires October 19, 2007 [Page 66]
Internet-Draft Data Model Schema April 2007
Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva 49130
Israel
Email: roni.even@polycom.co.il
Novo, et al. Expires October 19, 2007 [Page 67]
Internet-Draft Data Model Schema April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Novo, et al. Expires October 19, 2007 [Page 68]
| PAFTECH AB 2003-2026 | 2026-04-22 22:46:22 |