tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6501

Proposed STD
Pages: 94
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: XCON

Conference Information Data Model for Centralized Conferencing (XCON)

Part 1 of 4, p. 1 to 18
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                           O. Novo
Request for Comments: 6501                                  G. Camarillo
Category: Standards Track                                       Ericsson
ISSN: 2070-1721                                                D. Morgan
                                                    Fidelity Investments
                                                           J. Urpalainen
                                                                   Nokia
                                                              March 2012


                   Conference Information Data Model
                  for Centralized Conferencing (XCON)

Abstract

   RFC 5239 defines centralized conferencing (XCON) as an association of
   participants with a central focus.  The state of a conference is
   represented by a conference object.  This document defines an XML-
   based conference information data model to be used for conference
   objects.  A conference information data model is designed to convey
   information about the conference and about participation in the
   conference.  The conference information data model defined in this
   document constitutes an extension of the data format specified in the
   Session Initiation Protocol (SIP) event package for conference State.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6501.

Page 2 
Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1. Introduction ....................................................4
   2. Terminology .....................................................4
   3. Overview ........................................................4
      3.1. Data Model Format ..........................................5
      3.2. Data Model Namespace .......................................5
      3.3. The Conference Object Identifier ...........................5
           3.3.1. Conference Object URI Definition ....................7
           3.3.2. Normalization and Conference Object URI Comparison ..7
      3.4. Data Model Structure .......................................7
   4. Data Model Definition ...........................................8
      4.1. <conference-info> .........................................12
      4.2. <conference-description> ..................................12
           4.2.1. <language> .........................................13
           4.2.2. <allow-sidebars> ...................................13
           4.2.3. <cloning-parent> ...................................13
           4.2.4. <sidebar-parent> ...................................13
           4.2.5. <conference-time> ..................................13
           4.2.6. <conf-uris> ........................................15
           4.2.7. <available-media> ..................................15

Top      ToC       Page 3 
      4.3. <host-info> ...............................................18
      4.4. <conference-state> ........................................18
           4.4.1. <allow-conference-event-subscription> ..............18
      4.5. <floor-information> .......................................18
           4.5.1. <conference-ID> ....................................19
           4.5.2. <allow-floor-events> ...............................19
           4.5.3. <floor-request-handling> ...........................19
           4.5.4. <conference-floor-policy> ..........................20
      4.6. <users> ...................................................20
           4.6.1. <join-handling> ....................................21
           4.6.2. <user-admission-policy> ............................21
           4.6.3. <allowed-users-list> ...............................22
           4.6.4. <deny-users-list> ..................................23
           4.6.5. <user> and Its <user> Sub-Elements .................24
                  4.6.5.1. <provide-anonymity> .......................25
                  4.6.5.2. <roles> ...................................26
                  4.6.5.3. <allow-refer-users-dynamically> ...........26
                  4.6.5.4. <allow-invite-users-dynamically> ..........26
                  4.6.5.5. <allow-remove-users-dynamically> ..........26
                  4.6.5.6. <endpoint> ................................27
      4.7. <sidebars-by-ref> .........................................28
      4.8. <sidebars-by-val> .........................................28
   5. RELAX NG Schema ................................................28
   6. XML Schema Extensibility .......................................39
   7. XML Example ....................................................39
   8. Security Considerations ........................................49
   9. IANA Considerations ............................................51
      9.1. RELAX NG Schema Registration ..............................51
      9.2. XML Namespace Registration ................................52
      9.3. Conference Object Identifier Registration .................52
      9.4. Conference User Identifier Registration ...................53
   10. Acknowledgements ..............................................53
   11. References ....................................................53
      11.1. Normative References .....................................53
      11.2. Informative References ...................................54
   Appendix A.  Non-Normative RELAX NG Schema in XML Syntax ..........56
   Appendix B.  Non-Normative W3C XML Schema .........................84

Top      ToC       Page 4 
1.  Introduction

   There is a core data set of conference information that is utilized
   in any conference, independent of the specific conference media.
   This core data set, called the "conference information data model",
   is defined in this document using an XML-based format.  The
   conference information data model defined in this document is
   logically represented by the conference object.

   Conference objects are a fundamental concept in centralized
   conferencing, as described in the centralized conferencing framework
   [RFC5239].  The conference object represents a particular
   instantiation of a conference information data model.  Consequently,
   conference objects use the XML format defined in this document.

   The Session Initiation Protocol (SIP) event package for conference
   state, specified in [RFC4575], already defines a data format for
   conferences.  However, that model is SIP specific and lacks elements
   related to some of the functionality defined by the centralized
   conferencing framework [RFC5239] (e.g., floor control).  The data
   model defined in this document constitutes a superset of the data
   format defined in [RFC4575].  The result is a data format that
   supports more call signaling protocols (CSPs) besides SIP and that
   covers all the functionality defined in the centralized conferencing
   framework [RFC5239].

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 [RFC2119].

   This document uses the terminology defined in the centralized
   conferencing framework [RFC5239], the SIPPING conferencing framework
   [RFC4353], and the BFCP (Binary Floor Control Protocol) specification
   [RFC4582].  Readers of this document should be familiar with the
   terminology used in those documents.

3.  Overview

   The data model specified in this document is the result of extending
   the data format defined in [RFC4575] with new elements.  Examples of
   such extensions include scheduling elements, media control elements,
   floor control elements, non-SIP URIs, and the addition of
   localization extensions to text elements.  This data model can be
   used by conference servers providing different types of basic

Top      ToC       Page 5 
   conferences.  It is expected that this data model can be further
   extended with new elements in the future in order to implement
   additional advanced features.

3.1.  Data Model Format

   A conference object document is an XML [W3C.REC-xml-20081126]
   document.  Conference object documents MUST be based on XML 1.0 and
   MUST be encoded using UTF-8.

   The normative description of the syntax of the conference object
   document, for use by implementers of parsers and generators, is found
   in the RELAX NG schema provided in Section 5.  Compliant messages
   MUST meet the requirements of that schema.

3.2.  Data Model Namespace

   This specification defines a new namespace specification for
   identifying the elements defined in the data model.  This namespace
   is as follows:

   urn:ietf:params:xml:ns:xcon-conference-info

3.3.  The Conference Object Identifier

   The conference object identifier (XCON-URI) can be viewed as a key to
   accessing a specific conference object.  It can be used, for
   instance, by the conference control protocol to access, manipulate
   and delete a conference object.  A conference object identifier is
   provided to the conferencing client by the conference notification
   service or through out-of-band mechanisms (e.g., email).

   A conferencing system may maintain a relationship between the
   conference object identifiers and the identifiers associated with
   each of the complementary centralized conferencing protocols (e.g.,
   call signaling protocol, BFCP, etc.).  To facilitate the maintenance
   of these relationships, the conference object identifier acts as a
   top-level identifier within the conferencing system for the purpose
   of identifying the interfaces for these other protocols.  This
   implicit binding provides a structured mapping of the various
   protocols with the associated conference object identifier.  Figure 1
   illustrates the relationship between the identifiers used for the
   protocols and the general conference object identifier (XCON-URI).

Top      ToC       Page 6 
                            +--------------------------+
                            |       Conference         |
                            |         Object           |
                            |       Identifier         |
                            +--------------------------+
                            |  xcon:Ji092i@example.com |
                            +------+-------------------+
                                        |
                                        |
                                        |
                      +-----------------+---------------+
                      |                                 |
          +-----------+-----------+          +----------+---------+
          |   CSP Conference IDs  |          |BFCP 'Conference ID'|
          +-----------------------+          +--------------------+
          | h323:i092@example.com |          |        i092        |
          | tel:+44(0)2920930033  |          +----------+---------+
          | sip:i092@example.com  |                     |
          +-----------------------+             +-------+--------+
                                                | BFCP 'Floor ID'|
                                                +----------------+
                                                |      543       |
                                                |      236       |
                                                +----------------+

                    Figure 1: Conference Object Mapping

   In Figure 1, the conference object identifier acts as the top-level
   key in the identification process.  The call signaling protocols have
   an associated conference user identifier, often represented in the
   form of a URI.  The BFCP, as defined in [RFC4582], defines the
   'conference ID' identifier which represents a conference instance
   within floor control.  When created within the conferencing system,
   the 'conference ID' has a 1:1 mapping to the unique conference object
   identifier(XCON-URI).  Operations associated with the conference
   control protocols are directly associated with the conference object;
   thus, the primary identifier associated with these protocols is the
   conference object identifier(XCON-URI).  The mappings between
   additional protocols/interfaces is not strictly 1:1 and does allow
   for multiple occurrences.  For example, multiple call signaling
   protocols will each have a representation that is implicitly linked
   to the top-level conference object identifier, e.g., H323 and SIP
   URIs that represent a conference instance.  It should be noted that a
   conferencing system is free to structure such relationships as
   required, and this information is just included as a guideline that
   can be used.

Top      ToC       Page 7 
   Further elements can be added to the tree representation in Figure 1
   to enable a complete representation of a conference instance within a
   conferencing system.

3.3.1.  Conference Object URI Definition

   The syntax is defined by the following ABNF [RFC5234] rules.

      XCON-URI = "xcon" ":" [conf-object-id "@"] host

      conf-object-id = 1*( unreserved / "+" / "=" / "/" )

   Note: host and unreserved are defined in RFC 3986 [RFC3986].

   An XCON-URI is not designed to be resolved, and an application MUST
   NOT attempt to perform a standard DNS lookup on the host portion of
   such a URI in an attempt to discover an IP address or port at which
   to connect.

3.3.2.  Normalization and Conference Object URI Comparison

   In order to facilitate the comparison of the XCON-URI identifiers,
   all the components of the identifiers MUST be converted to lowercase.
   After normalizing the URI strings, the URI comparison MUST be applied
   on a character-by-character basis as prescribed by [RFC3986], Section
   6.2.1.

   The host construction, as defined in RFC 3986, can take the form of
   an IP address, which is not conventionally compared on a character-
   by-character basis.  The host part of an XCON-URI serves only as an
   identifier; that is, it is never used as an address.  The character-
   by-character comparison still applies.

3.4.  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).

Top      ToC       Page 8 
   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.

   Note that some of the elements described above such as <conference-
   info>, <conference-description>, <sidebars-by-ref>, or <sidebars-by-
   val> are not defined in the data model in this specification but are
   defined in the data format of [RFC4575].  We describe them here
   because they are part of the basic structure of the data model.

4.  Data Model Definition

   The following non-normative diagram shows the structure of conference
   object documents.  The symbol "!" preceding an element indicates that
   the element is REQUIRED in the data model.  The symbol "*" following
   an element indicates that the element is introduced and defined in
   this document.  That is, elements without a "*" have already been
   defined in [RFC4575].

   !<conference-info>
        |
        |--<conference-description>
        |     |--<language>*
        |     |--<display-text>
        |     |--<subject>
        |     |--<free-text>
        |     |--<keywords>
        |     |--<allow-sidebars>*
        |     |--<cloning-parent>*
        |     |--<sidebar-parent>*
        |     |--<conference-time>*
        |     |      |--<entry>*
        |     |      |    |--<base>*
        |     |      |    |--<mixing-start-offset>*
        |     |      |    |--<mixing-end-offset>*
        |     |      |    |--<can-join-after-offset>*
        |     |      |    |--<must-join-before-offset>*

Top      ToC       Page 9 
        |     |      |    |--<request-user>*
        |     |      |    |--<notify-end-of-conference>*
        |     |      |    |--<allowed-extend-mixing-end-offset>*
        |     |           ...
        |     |--<conf-uris>
        |     |      |--<entry>
        |     |      |    |--<uri>
        |     |      |    |--<display-text>
        |     |      |    |--<purpose>
        |     |      |    |--<conference-password>*
        |     |      ...
        |     |--<service-uris>
        |     |      |--<entry>
        |     |      |    |--<uri>
        |     |      |    |--<display-text>
        |     |      |    |--<purpose>
        |     |      ...
        |     |--<maximum-user-count>
        |     |      ...
        |     |--<available-media>
        |     |      |--<entry>
        |     |      |     |--<display-text>
        |     |      |     |--<type>
        |     |      |     |--<status>
        |     |      |     |--<mixing-mode>*
        |     |      |     |--<codecs>*
        |     |      |     |    |--<codec>*
        |     |      |     |    |    |--<subtype>*
        |     |      |     |    |--<codec>*
        |     |      |     |    |    |--<subtype>*
        |     |      |     |    ...
        |     |      |     |--<controls>*
        |     |      |     |    |--<mute>*
        |     |      |     |    |--<gain>*
        |     |      |     |   ...
        |     |      |--<entry>
        |     |      |     |--<display-text>
        |     |      |     |--<type>
        |     |      |     |--<status>
        |     |      |     |--<mixing-mode>*
        |     |      |     |--<codecs>*
        |     |      |     |    |--<codec>*
        |     |      |     |    |    |--<subtype>*
        |     |      |     |    |--<codec>*
        |     |      |     |    |    |--<subtype>*
        |     |      |     |    ...
        |     |      |     |--<controls>*
        |     |      |     |    |--<pause-video>*

Top      ToC       Page 10 
        |     |      |     |    |--<video-layout>*
        |     |      |     |   ...
        |     |      ...
        |
        |--<host-info>
        |     |--<display-text>
        |     |--<web-page>
        |     |--<uris>
        |     |     |--<entry>
        |     |     |    |--<uri>
        |     |     |    |--<display-text>
        |           ...
        |--<conference-state>
        |     |--<allow-conference-event-subscription>*
        |     |--<user-count>
        |     |--<active>
        |     |--<locked>
        |
        |--<floor-information>*
        |     |--<conference-ID>*
        |     |--<allow-floor-events>*
        |     |--<floor-request-handling>*
        |     |--<conference-floor-policy>*
        |     |     |--<floor>*
        |     |     |    |--!<media-label>*
        |     |     |    |--<algorithm>*
        |     |     |    |--<max-floor-users>*
        |     |     |    |--<moderator-id>*
        |     |     |   ...
        |     |     ...
        |
        |--<users>
        |     |--<join-handling>*
        |     |--<user-admission-policy>*
        |     |--<allowed-users-list>*
        |     |     |--<target>*
        |     |     |
        |     |     |--<persistent-list>*
        |     |     |     |--<user>*
        |     |     |     |     |-- <email>*
        |     |
        |     |--<deny-users-list>*
        |     |
        |     |--<user>
        |     |    |--<display-text>
        |     |    |--<associated-aors>
        |     |    |--<provide-anonymity>*
        |     |    |--<roles>

Top      ToC       Page 11 
        |     |    |    |
        |     |    |   ...
        |     |    |--<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>
        |     |    |      |    |--<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>
        |     ...

Top      ToC       Page 12 
        |--<sidebars-by-val>
        |     |--<entry>
        |     |     |
        |     |    ...
        |     |--<entry>
        |     |     |
        |     ...   ...


   The following sections describe these elements in detail.  The full
   RELAX NG schema is provided in Section 5.

4.1.  <conference-info>

   A conference object document begins with the root element
   <conference-info>, which is defined in [RFC4575].  The 'state' and
   'version' attributes of the <conference-info> element are defined in
   [RFC4575] and are not used in the context of the XCON Conference
   Information Model since they apply only to notification mechanisms.

   In addition, [RFC4575] defines an 'entity' attribute that contains
   the SIP URI identifier.  This specification extends the meaning of
   the 'entity' attribute to the conference object identifier (XCON-URI)
   explained in Section 3.3.

   This specification adds to the <conference-info> element the child
   elements of the <floor-information> element.

4.2.  <conference-description>

   The <conference-description> element, which is defined in [RFC4575],
   describes the conference as a whole.  It SHOULD have an attribute
   'lang' to specify the language used in the contents of this element.
   It is comprised of <language>, <display-text>, <subject>, <free-
   text>, <keywords>, <allow-sidebars>, <cloning-parent>, <sidebar-
   parent>, <conference-time>, <conf-uris>, <service-uris>, <maximum-
   user-count>, and <available-media>.  The <display-text>, <subject>,
   <free-text>, <keywords>, <service-uris>, and <maximum-user-count>
   elements are described in Section 5.3 of [RFC4575].

   The following sections describe these elements in more detail.  Other
   child elements MAY be defined in the future to extend the
   <conference-description> element.

Top      ToC       Page 13 
4.2.1.  <language>

   The <language> element indicates the predominant language that is
   expected to be employed within a conference.  This element contains
   only one language.  The possible values of this element are the
   values of the 'Subtag' column of the "Language Subtag Registry" at
   [IANA-Lan] originally defined in [RFC5646].  This element does not
   enforce the language of the conference: it only informs the
   participants about the desirable language that they should use in the
   conference.  Participants are free to switch to other languages if
   they like.

4.2.2.  <allow-sidebars>

   The <allow-sidebars> element represents a boolean value.  If set to
   true or "1", the conference is allowed to create sidebar conferences.
   If absent, or set to "false" or "0", the conference cannot create
   sidebar conferences.

4.2.3.  <cloning-parent>

   When the <cloning-parent> is present, it indicates that the
   conference object is a child of a parent conference.  The <cloning-
   parent> element contains the conference object identifier (XCON-URI)
   (different from the main XCON-URI) of the parent.

4.2.4.  <sidebar-parent>

   When the <sidebar-parent> is present, it indicates that the
   conference object represents a sidebar of another conference.  The
   <sidebar-parent> element contains the conference object identifier
   (XCON-URI) (different from the main XCON-URI) of the parent.

4.2.5.  <conference-time>

   The <conference-time> element contains the information related to
   time, policy, and duration of a conference.  The <conference-time>
   element contains one or more <entry> elements, each defining the time
   and policy information specifying a single conference occurrence.
   The <conference-time> element differs from the iCalendar objects
   [RFC5545] in that it has the ability to define different policies
   (<can-join-after-offset>, <must-join-before-offset>) for the same
   conference at different times.

Top      ToC       Page 14 
   Every <entry> element contains the following child elements:

   o  <base>: The <base> child element specifies the iCalendar object of
      the conference.  The iCalendar object components are defined in
      [RFC5545].

   o  <mixing-start-offset>: The <mixing-start-offset> child element
      specifies when the conference media mixing starts before the
      conference starts.  The <mixing-start-offset> element specifies an
      absolute value rather than an offset value.  If the <mixing-start-
      offset> element is not present, it indicates that the conference
      media mixing starts immediately.  The <mixing-start-offset> MUST
      include the 'required-participant' attribute.  This attribute
      contains one of the following values: "none", "administrator",
      "moderator", "user", "observer", and "participant".  The roles'
      semantic definitions are out of the scope of this document and are
      subject to future policy documents.  More values can be specified
      in the future.  The 'required-participant' 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
      arrives.  If the value is set to "none", mixing starts according
      to the mixing start time.

   o  <mixing-end-offset>: The <mixing-end-offset> child element
      specifies the time conference media mixing stops after the
      conference stops.  If the <mixing-end-offset> element is not
      present, it indicates that the conference occurrence is not
      bounded.  The <mixing-end-offset> element MUST include the
      'required-participant' attribute.  This attribute contains one of
      the following values: "none", "administrator", "moderator",
      "user", "observer", and "participant".  More values can be
      specified in the future.  The 'required-participant' attribute
      allows a privileged user to define when media mixing ends based on
      the earlier of the <mixing-end-offset> and the time the last
      participant leaves.  If the value is set to "none", mixing stops
      according to the <mixing-end-offset>.  If the conference policy
      was modified so that the last privileged user is now a normal
      conference participant, and the conference requires a privileged
      user to continue, that conference MUST terminate.

   o  <can-join-after-offset>: An administrator can indicate the time
      when users can join a conference by populating the <can-join-
      after-offset> element.

   o  <must-join-before-offset>: An administrator can define the time
      after which new users are not allowed to join the conference
      anymore.

Top      ToC       Page 15 
   o  <request-user>: This element defines the time when users or
      resources on the <allowed-users-list> are requested to join the
      conference by using the <request-users> element.

   o  <notify-end-of-conference>: The <notify-end-of-conference> element
      defines in seconds when the system MUST send a notification that
      the end of the conference is approaching.  If the <notify-end-of-
      conference> element is not present, this indicates that the system
      does not notify the users when the end of the conference is
      approaching.

   o  <allowed-extend-mixing-end-offset>: The <allowed-extend-mixing-
      end-offset> element indicates if the conference is allowed to be
      extended.  It has a boolean value.

4.2.6.  <conf-uris>

   The <conf-uris> contains a set of <entry> child elements -- each
   containing a new element: <conference-password>.  This element
   contains the password(s) of the conference, for instance, Public
   Switched Telephone Network (PSTN) conference will store the 'PIN
   code' in this element.  All the other <conf-uris> child elements are
   described in Section 5.3.1 of [RFC4575].

   The RELAX NG schema in Section 5 allows <conference-password> to
   appear anywhere uris-type is expanded.  This document only provides
   meaning for <conference-password> appearing as a descendant of the
   <conf-uris> element.  Future standardization may give meaning to
   <conference-password> appearing in other elements of type "uris-
   type".  In the absence of such standardization, <conference-password>
   MUST NOT appear in elements of type "uris-type" other than <conf-
   uris>.

4.2.7.  <available-media>

   The <available-media> element consists of a sequence of <entry> child
   elements.  Each <entry> element MAY contain the following child
   elements:

   o  The <display-text>, <type>, and <status> elements are described in
      Section 5.3.4 of [RFC4575].

   o  The child element <mixing-mode> describes a default scheduling
      policy by which the mixer will build the outgoing stream from the
      incoming streams.  Note that this policy is different than the
      policy describing the floors for each media.  The <mixing-mode>
      child element MUST contain one and only one of the "moderator-
      controlled", "FCFS", and "automatic" values, indicating the

Top      ToC       Page 16 
      default algorithm to use with every media stream.  The "moderator-
      controlled" value indicates that the moderator of the conference
      controls the media stream policy.  The "FCFS" value indicates a
      'first-come-first-served' policy.  The "automatic" value means the
      mixer must choose the best scheduling policy for the conference.

   o  The <codecs> element specifies the allowed codecs in the
      conference.  It has an attribute 'decision' that specifies if the
      focus decides the common codec automatically or needs the approval
      of the moderator of the conference ("automatic", "moderator-
      controlled").  The <codecs> element contains <codec> elements.  A
      <codec> element can have the attribute 'name' and 'policy'.  The
      'name' attribute is a codec identifier assigned by the
      conferencing server.  The 'policy' attribute contains the policy
      for that codec (allowed or disallowed).  The <codec> element has
      the child element <subtype>, which stores the codec's name.  The
      possible values of this element are the values of the 'subtype'
      column of the "RTP Payload Format media types" registry at [IANA]
      originally defined in [RFC4855].  It is expected that future
      conferencing specifications will define corresponding schema
      extensions, as appropriate.

   o  The <controls> element contains the basic audio and video global
      control elements for a conference.  These controls are sufficient
      for the majority of basic conferences.  If the conference server
      wants to support more-advanced controls, then it is RECOMMENDED
      that an extension to the data model be used.  In the <controls>
      element, the schema is extensible; hence, new control types can be
      added in the future.  So, moderator controls that affect all media
      output would go under the <available-media> element.  The
      following child elements are defined for <controls>:

      *  The <mute> element is used in conjunction with an audio stream
         to cease transmission of any audio from the associated stream.
         That means that for the entire duration where mute is
         applicable, all current and future participants of the
         conference are muted and will not send any audio.  It has a
         boolean value.  If this control is not specified, access to the
         control is not available to the client.

      *  The <pause-video> element is used in conjunction with a video
         stream to cease transmission of associated media.  It has a
         boolean value.  If this control is not specified, the access to
         the control is not available to the client.

Top      ToC       Page 17 
      *  The <gain> element is used in conjunction with a media output
         stream to indicate the amount of amplification of an audio
         stream.  The value is an integer number that ranges from -127
         to 127.  If this control is not specified, access to the
         control is not available to the client.

      *  The <video-layout> element is used in conjunction with a video
         stream to specify how the video streams (of participants) are
         viewed by each participant.  Only one layout type can be
         specified for each output stream.  If there are fewer
         participants than panels in the specified layout, then blanking
         (black screen) MAY be mixed into the stream on the behalf of
         the missing input streams.  If unspecified, the <video-layout>
         default type SHOULD be "single-view".  The <video-layout> types
         are as follows, although any number of custom layouts may be
         specified in future extensions:

         +  single-view: Only one stream is presented by the focus to
            all participants in one panel.

         +  dual-view: This dual-view option will present the video
            side-by-side in two 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 are
            presented by the focus to all participants.  Typically, the
            aspect ratio of the streams are maintained (alter-aspect-
            ratio= FALSE).

Top      ToC       Page 18 
         +  multiple-3x3: Nine equal-sized panels in a 3x3 layout are
            presented by the focus to all participants.  Typically, the
            aspect ratio of the streams are preserved.

         +  multiple-4x4: 16 equal-sized panels in a 4x4 layout are
            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.



(page 18 continued on part 2)

Next RFC Part