Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6501

Conference Information Data Model for Centralized Conferencing (XCON)

Pages: 94
Proposed Standard
Part 2 of 4 – Pages 18 to 39
First   Prev   Next

Top   ToC   RFC6501 - Page 18   prevText

4.3. <host-info>

The <host-info> element and its child elements are described in [RFC4575], Section 5.4.

4.4. <conference-state>

The <conference-state> is introduced in [RFC4575]. The <conference- state> element contains the <allow-conference-event-subscription>, <user-count>, <active>, and <locked> child elements. The <user- count>, <active>, and <locked> child elements are defined in [RFC4575], Section 5.5.

4.4.1. <allow-conference-event-subscription>

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 'SIP event package for conference state' [RFC4575]. If set to FALSE, the subscription to conference state events MUST 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.5. <floor-information>

The <floor-information> element contains the <conference-ID>, <allow- floor-events>, <floor-request-handling>, and <conference-floor- policy> child elements. The absence of this element from an XML document indicates that the conference does not have a floor.
Top   ToC   RFC6501 - Page 19

4.5.1. <conference-ID>

The <conference-ID> represents a conference instance within floor control. When BFCP serves as the floor control protocol, the <conference-ID> is a 32-bit BFCP conference identifier defined in [RFC4582], Section 5.1. Note that when created within the conferencing system, there is a 1:1 mapping between this <conference-ID> and the unique conference object identifier (XCON- URI).

4.5.2. <allow-floor-events>

The <allow-floor-events> element represents a boolean action. If set to true, the focus is instructed to accept the subscription to floor control events. If set to FALSE, the focus is instructed to reject the subscription. If this element is undefined, it has a default value of FALSE, causing the subscription to floor control events to be rejected. A conference participant can subscribe himself to a floor control event in two different ways: one method is using an offer/answer exchange mechanism ([RFC3264]) using SIP INVITE and BFCP parameters in the SDP [RFC4583], the other method is a general authorization mechanism described in Section 9 of [RFC4582] and in [RFC5018]. Future documentation may define additional connection mechanisms.

4.5.3. <floor-request-handling>

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 the following: 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 this section discusses floor control information; therefore, the value "block" in a <floor-request-handling> element is not related with the "block" value in the <join-handling> element (see Section 4.6.1).
Top   ToC   RFC6501 - Page 20

4.5.4. <conference-floor-policy>

The <conference-floor-policy> element has one or more <floor> child elements. Every <floor> child elements has an attribute 'id', which uniquely identifies a floor within a conference. In the case of BFCP [RFC4582], the 'id' attribute corresponds to the floor-id identifier defined in [RFC4582], Section 5.2.2. o <media-label>: Every floor is identified for one or more mandatory <media-label> elements. If the <available-media> information is included in the conference document, the value of this element MUST be equal to the "label" value of the corresponding media stream <entry> in the <available-media> container. The number of those elements indicates how many floors the conference can have. A floor can be used for one or more media types; o <algorithm>: A floor can be controlled using many algorithms; the mandatory <algorithm> element MUST be set to any of the "moderator-controlled", "FCFS", or "random" values indicating the algorithm. The "moderator-controlled" value indicates that the moderator of the conference controls the floor. The "FCFS" value indicates a 'first-come-first-served' policy. o <max-floor-users>: The <max-floor-users> child element in the <floor> element is OPTIONAL and, if present, dictates the maximum number of users who can have the floor at one time. o <moderator-id>: The OPTIONAL <moderator-id> indicates the "User ID" of the moderator(s). It MUST be set if the element <algorithm> is set to the "moderator-controlled" value. When the floor is created within the conferencing system, the XCON-USERID MAY be used as the <moderator-id>. In the case where the BFCP is the floor control protocol, the <moderator-id> is defined in [RFC4582], Section 3. Note that [RFC4582] refers to the moderator role as a "floor chair".

4.6. <users>

The <users> element is described in [RFC4575] and contains the <join- handling>, <user-admission-policy>, <allowed-users-list>, and <deny- users-list> defined in this document and <user> child elements defined in [RFC4575]. When the <users> element is used in the context of the XCON Conference Information Model, the 'state' and 'version' attributes defined in [RFC4575] are not used, since they apply only to notification mechanisms. The following sections describe these elements in more detail. Other child elements and attributes can be used to extend <users> in the future.
Top   ToC   RFC6501 - Page 21

4.6.1. <join-handling>

The <join-handling> element defines the actions used by the conference focus to control conference participation. This element defines the action that the focus is to take when processing a particular request to join a conference. This element 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 "authenticate": This action instructs the focus that the user has to provide a combination of username/password. o "directed-operator": This action instructs the focus to direct the user to an operator.

4.6.2. <user-admission-policy>

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 authenticated into the conference, using a mechanism of the conference's choosing. Since a variety of signaling protocols are possible, a variety of authentication mechanisms -- determined by every individual conference server -- may need to be mapped from the different protocols. The specific types of authentication mechanisms are beyond the scope of this document. The list of possible values are as follows: o "closedAuthenticated": A 'closedAuthenticated' policy MUST have each conference participant in the allowed users list (listed under the <allowed-users-list> 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. A
Top   ToC   RFC6501 - Page 22
      'closedAuthenticated' policy MUST NOT include a <deny-users-list>.
      If <deny-users-list> appears in the data model, it MUST be
      ignored.

   o  "openAuthenticated": An 'openAuthenticated' policy requires each
      conferencing participant to be sufficiently authenticated.
      Typically, this implies that anyone capable of authenticating with
      the conferencing system may join the conference.  The
      'openAuthenticated' policy permits the specification of "banned"
      conferencing participants.  Such banned users are prevented from
      re-joining the conference until they have been un-banned.  An
      'openAuthenticated' policy SHOULD have a deny users list (listed
      under the <deny-users-list> XML element) to support the banning of
      conferencing participants from a conference.  An
      'openAuthenticated' policy MUST NOT include an <allowed-users-
      list>.  If <allowed-users-list> appears in the data model, it MUST
      be ignored.

   o  "anonymous": An 'anonymous' policy grants any join requests and is
      the least restrictive policy.  An 'anonymous' policy MUST NOT
      include either an <allowed-users-list> or a <deny-users-list>.  If
      any of these lists appear in the data model, they MUST be ignored.

   In all other cases, the appearance of an <allowed-users-list> and
   <deny-users-list> MUST be ignored, except as otherwise described in a
   future specification.  Future specifications describing the use of
   these lists must provide clear guidance on how to process the lists
   when they occur concurrently, especially when both lists contain the
   same user.  For example, such a specification could disallow both
   lists from appearing at the same time similar to <user-admission-
   policy> values defined in this document.

4.6.3. <allowed-users-list>

The <allowed-users-list> child element contains a list of user URIs (e.g., XCON-USERID, as defined in Section 4.6.5), roles (defined in Section 4.6.5.2), or domains (e.g., *@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.
Top   ToC   RFC6501 - Page 23
   The 'method' attribute is a list with the following values:

   o  "dial-in": The value "dial-in" is used by the focus to determine
      who can join the conference.

   o  "dial-out": The value "dial-out" contains a list of resources with
      which the focus will initiate a session.

   o  "refer": The value "refer" is used by the focus to determine the
      resources that the focus needs to "refer to" the conference.  In
      SIP, this is achieved by the focus sending a REFER request to
      those potential participants.  In a different paradigm, this could
      also mean that the focus sends an SMS or an email to the referred
      user.  This list can be updated during the conference lifetime so
      it can be used for mid-conference refers as well.

   The "refer" value differs from "dial-out" in that the resources on
   the "refer" value are expected to initiate the session establishment
   toward the focus themselves.  It is also envisioned that different
   users will have different access rights to those lists and therefore
   a separation between the two is needed.

   The <allowed-users-list> element has a <persistent-list> child
   element as well.  Some chat room systems allow -- and some require --
   registration of detailed information about a user before they are
   allowed to join a chat room.  The <persistent-list> child element
   stores persistent information about users who are not actively part
   of an ongoing chat room session.  The <persistent-list> element
   stores the following information:

   o  user: The <user> element stores the name, nickname, conference
      user identifier (XCON-USERID), and email address of a user.  It
      has three attributes: 'name', 'nickname', and 'id' and an <email>
      element.  Future extensions to this schema may define new elements
      for the <user> element.

   Future extensions to this schema may define new elements for the
   <target> element.

4.6.4. <deny-users-list>

The <deny-users-list> child element contains a list of user URIs (e.g., SIP URI, XCON-USERID defined in Section 4.6.5), roles (defined in Section 4.6.5.2), or domains (e.g.: *@example.com) that the focus uses to determine who has been 'banned' from the conference. Such banned users are prevented from re-joining the chat room until the ban has been lifted.
Top   ToC   RFC6501 - Page 24

4.6.5. <user> and Its <user> Sub-Elements

The element <user> is described in [RFC4575] and describes a single participant in the conference. The <user> element has an attribute 'entity'. However, when the <user> element is used in the context of the XCON Conference Information Model, the 'state' and 'version' attributes defined in [RFC4575] are not used, since they only apply to notification mechanisms. The attribute 'entity' contains a unique conference user identifier (XCON-USERID) within the scope of the conference. The URI format of this identifier is as follows (using ABNF [RFC5234]): XCON-USERID = "xcon-userid" ":" conf-user-id conf-user-id = 1*unreserved Note: unreserved is defined in RFC 3986. In order to facilitate the comparison of the XCON-USERID identifiers, all the components of the identifiers MUST be converted to lowercase. After normalizing the URI strings, the URIs comparison MUST be applied codepoint-by-codepoint after conversion to a common character encoding, as prescribed by [RFC3986], Section 6.2.1. Other user identifiers can be associated with this conference user identifier and enable the conferencing system to correlate and map these multiple authenticated user identities to a single global user identifier. Figure 2 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.
Top   ToC   RFC6501 - Page 25
                         +----------------+
                         |   Conference   |
                         |      User      |
                         |   Identifier   |
                         +----------------+
                         |XCON-USERID:John|
                         +-------+--------+
                                 |
                                 |
                                 |
          +----------------------+-------------------------+
          |                      |                         |
  +-------+--------+ +-----------+-----------+ +-----------+-----------+
  |  BFCP User ID  | |      SIP User URI     | |     H323 User URI     |
  +----------------+ +-----------------------+ +-----------------------+
  |      543       | |sip:851221@example.com | |h323:taeduk@example.com|
  +----------------+ +-----------------------+ +-----------------------+


                     Figure 2: Conference User Mapping

   The element <user> element contains the <display-text>, <associated-
   aors>, <provide-anonymity>, <roles>, <languages>, <cascaded-focus>,
   <allow-refer-users-dynamically>, <allow-invite-users-dynamically>,
   <allow-remove-users-dynamically>, and <endpoint>.  The following
   sections describe these elements in more detail.  The <display-text>,
   <associated-aors>, <languages>, and <cascaded-focus> are defined in
   [RFC4575], Section 5.6.

4.6.5.1. <provide-anonymity>
The <provide-anonymity> element specifies what level of anonymity the server should provide to the user. In this case, the focus provides the rest of the participants with an anonymous identity for that user, for example, anonymousX, or it does not provide any information for that user such that other users cannot see he is a participant in the conference. This element only affects the way the user information is provided to the other participants. The real user information is stored in the data model but SHOULD NOT be provided to the other participants of the conference. This can be achieved by using the <provide-anonymity> element. This element has three values: "private", "semi-private", and "hidden". The "private" value specifies that this user is completely anonymous in the conference. The "semi-private" value specifies that this user is anonymous to all users who have not been granted permission to see him. The "hidden" value specifies that other users cannot see this participant in the conference.
Top   ToC   RFC6501 - Page 26
4.6.5.2. <roles>
A <role> provides the context for the set of conference operations that a participant can perform. This element can contain one or more of the following values: "administrator", "moderator", "user", "participant", "observer", and "none". A role of "none" indicates that any role is assigned. The <roles> semantic definition is out of the scope of this document and is subject to future policy documents. This element can be extended with new roles in future documents.
4.6.5.3. <allow-refer-users-dynamically>
The <allow-refer-users-dynamically> element represents a boolean value. If set to true, a participant is allowed to instruct the focus to refer a user to the conference without modifying the <allowed-users-list> (in SIP terms, a participant is allowed to send a REFER request [RFC3515] to the focus, which results in the focus sending a REFER request to the user the referrer wishes to join the conference). If set to FALSE, the REFER request is rejected. If this element is undefined, it has a value of FALSE, causing the REFER request to be rejected.
4.6.5.4. <allow-invite-users-dynamically>
The <allow-invite-users-dynamically> element represents a boolean action. If set to true, a participant is allowed to instruct the focus to invite a user to the conference without modifying the <allowed-users-list> list (in SIP terms, a participant is allowed to send a REFER request [RFC3515] to the focus, which results in the focus sending an INVITE request to the user the referrer wishes to join the conference). If set to FALSE, the REFER request is rejected. If this element is undefined, it has a value of FALSE, causing the REFER request to be rejected.
4.6.5.5. <allow-remove-users-dynamically>
The <allow-remove-users-dynamically> element represents a boolean action. If set to true, a participant is allowed to instruct the focus to remove a user from the conference without modifying the ruleset (in SIP terms, a participant is allowed to send a REFER request [RFC3515] to the focus, which results in the focus sending a BYE request to the user the referrer wishes to leave the conference). If set to FALSE, the REFER request is rejected. If this element is undefined, it has a value of FALSE, causing the REFER request to be rejected.
Top   ToC   RFC6501 - Page 27
4.6.5.6. <endpoint>
The <endpoint> child element is identical to the element with the same name in [RFC4575] except that the 'state' attribute is not included. When the <endpoint> element is used in the context of the XCON Conference Information Model, the 'state' and 'version' attributes defined in [RFC4575] are not used, since they apply only to notification mechanisms. The <endpoint> element can provide the desired level of detail about the user's devices and their signaling sessions taking part in the conference. The <endpoint> element has the following child elements: <display- text>, <referred>, <status>, <joining-method>, <joining-info>, <disconnection-method>, <disconnection-info>, <media>, and <call- info>. All the <endpoint> child elements are defined in [RFC4575] with the exception of the <to-mixer> element and the <from-mixer> element. The <endpoint>/<media> element has two other child elements defined in this document: the <to-mixer> and the <from-mixer>: o <from-mixer>, <to-mixer>: These are controls that apply to a user's media stream being sent from the mixer to the participant's endpoint or to the mixer from the participant's endpoint. The <to-mixer> element details properties associated with the incoming streams to the mixer (streams sent to the mixer from the participant). The <from-mixer> element details properties associated with the outgoing streams from the mixer (sent from the mixer to the participant). Both of these elements have the attribute 'name'. The 'name' attribute has the values "VideoIn", "VideoOut", "AudioOut", and "AudioIn". The "VideoOut" and "AudioOut" media streams detail properties associated with the outgoing video and audio from the mixer. The "VideoIn" and "AudioIn" media stream details properties associated with the incoming video and audio to the mixer. Both of these elements can have the <floor> child element defined: * The <floor> element refers to the floor assigned to a certain 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 an attribute 'id', which uniquely identifies a floor within a conference. The 'id' attribute corresponds to the floor-id identifier defined in [RFC4582], Section 5.2.2. 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.
Top   ToC   RFC6501 - Page 28
      The <to-mixer> and <from-mixer> elements can have the <controls>
      child element:

      *  Controls that apply to a specific user would appear under the
         <controls> element.

   o  More values can be defined in the future.

4.7. <sidebars-by-ref>

The <sidebars-by-ref> element contains a set of <entry> child elements. This element is described in [RFC4575], Section 5.9.1. When the <sidebars-by-ref> element is used in the context of the XCON conference information model, the 'state' and 'version' attributes defined in [RFC4575] are not used, since they apply only to notification mechanisms.

4.8. <sidebars-by-val>

The <sidebars-by-val> element contains a set of <entry> child elements each containing information about a single sidebar. This element is described in [RFC4575], Section 5.9.2. When the <sidebars-by-val> element is used in the context of the XCON conference information model, the 'state' and 'version' attributes defined in [RFC4575] are not used, since they apply only to notification mechanisms.

5. RELAX NG Schema

In accordance with the centralized conferencing framework document [RFC5239], the conference object is a logical representation of a conference instance. The conference information schema contains core information that is utilized in any conference. It also contains the variable information part of the conference object. The normative schema is backwards compatible with [RFC5239], in other words, valid [RFC5239] instance documents are also valid according to this RELAX NG schema [RELAX]. In addition to approximately similar RELAX NG [RELAX] definitions of [RFC5239], this schema contains extension elements in the "urn:ietf:params:xml:ns:xcon-conference-info" namespace.
Top   ToC   RFC6501 - Page 29
default namespace = "urn:ietf:params:xml:ns:conference-info"
namespace xcon = "urn:ietf:params:xml:ns:xcon-conference-info"

start = element conference-info { conference-type }
# CONFERENCE TYPE
conference-type =
  attribute entity { text }
  & anyAttribute
  & conference-description-type?
  & element host-info { host-type }?
  & element conference-state { conference-state-type }?
  & element users { users-type }?
  & element sidebars-by-ref { uris-type }?
  & element sidebars-by-val { sidebars-by-val-type }?
  & element xcon:floor-information { floor-information-type }?
  & anyElement*
# CONFERENCE DESCRIPTION TYPE
conference-description-type =
  element conference-description {
    attribute xml:lang { xsd:language }?
    & anyAttribute
    & element display-text { text }?
    & element subject { text }?
    & element free-text { text }?
    & element keywords {
        list { xsd:string* }
      }?
    & element conf-uris { uris-type }?
    & element service-uris { uris-type }?
    & element maximum-user-count { xsd:int }?
    & element available-media { conference-media-type }?
    & element xcon:language { xsd:language }?
    & element xcon:allow-sidebars { xsd:boolean }?
    & element xcon:cloning-parent { xsd:anyURI }?
    & element xcon:sidebar-parent { xsd:anyURI }?
    & element xcon:conference-time { conferencetime-type }?
    & anyElement*
  }
# HOST TYPE
host-type =
  element display-text { text }?
  & element web-page { xsd:anyURI }?
  & element uris { uris-type }?
  & anyElement*
  & anyAttribute
# CONFERENCE STATE TYPE
conference-state-type =
  anyAttribute
Top   ToC   RFC6501 - Page 30
  & element user-count { xsd:unsignedInt }?
  & element active { xsd:boolean }?
  & element locked { xsd:boolean }?
  & element xcon:allow-conference-event-subscription { xsd:boolean }?
  & anyElement*
# CONFERENCE MEDIA TYPE
conference-media-type =
  anyAttribute
  & element entry { conference-medium-type }*
  & anyElement*
# CONFERENCE MEDIUM TYPE
conference-medium-type =
  attribute label { text }
  & anyAttribute
  & element display-text { text }?
  & element type { text }?
  & element status { media-status-type }?
  & element xcon:mixing-mode { mixing-mode-type }?
  & element xcon:codecs { codecs-type }?
  & element xcon:controls { control-type }?
  & anyElement*
# URIs TYPE
uris-type =
  anyAttribute
  & element entry { uri-type }*
  & anyElement*
# URI TYPE
uri-type =
  element uri { xsd:anyURI }
  & element display-text { text }?
  & element purpose { text }?
  & element modified { execution-type }?
  & element xcon:conference-password { text }*
  & anyElement*
  & anyAttribute
# USERS TYPE
users-type =
  anyAttribute
  & element user { user-type }*
  & element xcon:join-handling { join-handling-type }?
  & element xcon:user-admission-policy { user-admission-policy-type }?
  & element xcon:allowed-users-list { allowed-users-list-type }?
  & element xcon:deny-users-list { deny-user-list-type }?
  & anyElement*
# USER TYPE
user-type =
  attribute entity { xsd:anyURI }
  & anyAttribute
Top   ToC   RFC6501 - Page 31
  & element display-text { text }?
  & element associated-aors { uris-type }?
  & element roles {
      element entry { single-role-type }+
    }?
  & element languages {
      list { xsd:language }
    }?
  & element cascaded-focus { xsd:anyURI }?
  & element endpoint { endpoint-type }*
  & element xcon:provide-anonymity { provide-anonymity-type }?
  & element xcon:allow-refer-users-dynamically { xsd:boolean }?
  & element xcon:allow-invite-users-dynamically { xsd:boolean }?
  & element xcon:allow-remove-users-dynamically { xsd:boolean }?
  & anyElement*
# ENDPOINT TYPE
endpoint-type =
  attribute entity { text }
  & anyAttribute
  & element display-text { text }?
  & element referred { execution-type }?
  & element status { endpoint-status-type }?
  & element joining-method { joining-type }?
  & element joining-info { execution-type }?
  & element disconnection-method { disconnection-type }?
  & element disconnection-info { execution-type }?
  & element media { media-type }*
  & element call-info { call-type }?
  & anyElement*
# ENDPOINT STATUS TYPE
endpoint-status-type =
  "pending"
  | "dialing-out"
  | "dialing-in"
  | "alerting"
  | "on-hold"
  | "connected"
  | "muted-via-focus"
  | "disconnecting"
  | "disconnected"
  | free-text-extension
# JOINING TYPE
joining-type =
  "dialed-in" | "dialed-out" | "focus-owner" | free-text-extension
# DISCONNECTION TYPE
disconnection-type =
  "departed" | "booted" | "failed" | "busy" | free-text-extension
# EXECUTION TYPE
Top   ToC   RFC6501 - Page 32
execution-type =
  element when { xsd:dateTime }?
  & element reason { text }?
  & element by { xsd:anyURI }?
  & anyAttribute
# CALL TYPE
call-type =
  element sip { sip-dialog-id-type }
  & anyElement*
  & anyAttribute
# SIP DIALOG ID TYPE
sip-dialog-id-type =
  element display-text { text }?
  & element call-id { text }
  & element from-tag { text }
  & element to-tag { text }
  & anyElement*
  & anyAttribute
# MEDIA TYPE
media-type =
  attribute id { xsd:int }
  & anyAttribute
  & element display-text { text }?
  & element type { text }?
  & element label { text }?
  & element src-id { text }?
  & element status { media-status-type }?
  & element xcon:to-mixer { mixer-type }?
  & element xcon:from-mixer { mixer-type }?
  & anyElement*
# MEDIA STATUS TYPE
media-status-type =
  "recvonly"
  | "sendonly"
  | "sendrecv"
  | "inactive"
  | free-text-extension
# SIDEBARS-BY-VAL TYPE
sidebars-by-val-type =
  anyAttribute
  & element entry { conference-type }*
  & anyElement*
# CONFERENCE TIME
conferencetime-type =
  anyAttribute
  & element xcon:entry {
      element xcon:base { text },
      element xcon:mixing-start-offset {
Top   ToC   RFC6501 - Page 33
        time-type,
        attribute required-participant { single-role-type },
        anyAttribute
      }?,
      element xcon:mixing-end-offset {
        time-type,
        attribute required-participant { single-role-type },
        anyAttribute
      }?,
      element xcon:can-join-after-offset { time-type }?,
      element xcon:must-join-before-offset { time-type }?,
      element xcon:request-user { time-type }?,
      element xcon:notify-end-of-conference { xsd:nonNegativeInteger }?,
      element xcon:allowed-extend-mixing-end-offset { xsd:boolean }?,
      anyElement*
    }*
# TIME TYPE
time-type = xsd:dateTime { pattern = ".+T.+Z.*" }
# SINGLE ROLE TYPE
single-role-type =
  xsd:string "none"
  | xsd:string "administrator"
  | xsd:string "moderator"
  | xsd:string "user"
  | xsd:string "observer"
  | xsd:string "participant"
  | free-text-extension
# MIXING MODE TYPE
mixing-mode-type =
  xsd:string "moderator-controlled"
  | xsd:string "FCFS"
  | xsd:string "automatic"
  | free-text-extension
# CODECS TYPE
codecs-type =
  attribute decision { decision-type }
  & anyAttribute
  & element xcon:codec { codec-type }*
  & anyElement*
# CODEC TYPE
codec-type =
  attribute name { text }
  & attribute policy { policy-type }
  & anyAttribute
  & element xcon:subtype { text }?
  & anyElement*
# DECISION TYPE
decision-type =
Top   ToC   RFC6501 - Page 34
  xsd:string "automatic"
  | xsd:string "moderator-controlled"
  | free-text-extension
# POLICY TYPE
policy-type =
  xsd:string "allowed" | xsd:string "disallowed" | free-text-extension
# CONTROL TYPE
control-type =
  anyAttribute
  & element xcon:mute { xsd:boolean }?
  & element xcon:pause-video { xsd:boolean }?
  & element xcon:gain { gain-type }?
  & element xcon:video-layout { video-layout-type }?
  & anyElement*
# GAIN TYPE
gain-type = xsd:int { minInclusive = "-127" maxInclusive = "127" }
# VIDEO LAYOUT TYPE
video-layout-type =
  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"
  | free-text-extension
# FLOOR INFORMATION TYPE
floor-information-type =
  anyAttribute
  & element xcon:conference-ID { xsd:unsignedLong }?
  & element xcon:allow-floor-events { xsd:boolean }?
  & element xcon:floor-request-handling { floor-request-type }?
  & element xcon:conference-floor-policy { conference-floor-policy }?
  & anyElement*
# FLOOR REQUEST TYPE
floor-request-type =
  xsd:string "block" | xsd:string "confirm" | free-text-extension
# CONFERENCE FLOOR POLICY
conference-floor-policy =
  anyAttribute
  & element xcon:floor {
      attribute id { text }
      & anyAttribute
      & element xcon:media-label { xsd:nonNegativeInteger }+
      & element xcon:algorithm { algorithm-type }?
Top   ToC   RFC6501 - Page 35
      & element xcon:max-floor-users { xsd:nonNegativeInteger }?
      & element xcon:moderator-id { xsd:nonNegativeInteger }?
      & anyElement*
    }+
# ALGORITHM POLICY
algorithm-type =
  xsd:string "moderator-controlled"
  | xsd:string "FCFS"
  | xsd:string "random"
  | free-text-extension
# USERS ADMISSION POLICY
user-admission-policy-type =
  xsd:string "closedAuthenticated"
  | xsd:string "openAuthenticated"
  | xsd:string "anonymous"
  | free-text-extension
# JOIN HANDLING TYPE
join-handling-type =
  xsd:string "block"
  | xsd:string "confirm"
  | xsd:string "allow"
  | xsd:string "authenticate"
  | xsd:string "directed-operator"
  | free-text-extension
# DENY USERLIST
deny-user-list-type =
  anyAttribute
  & element xcon:target {
      attribute uri { xsd:anyURI },
      anyAttribute
    }*
  & anyElement*
# ALLOWED USERS LIST TYPE
allowed-users-list-type =
  anyAttribute
  & element xcon:target { target-type }*
  & element xcon:persistent-list { persistent-list-type }?
  & anyElement*
# PERSISTENT LIST TYPE
persistent-list-type =
  element xcon:user {
    attribute name { text }
    & attribute nickname { text }
    & attribute id { text }
    & anyAttribute
    & element xcon:e-mail { text }*
    & anyElement*
  }*
Top   ToC   RFC6501 - Page 36
  & anyElement*
# TARGET TYPE
target-type =
  attribute uri { xsd:anyURI },
  attribute method { method-type },
  anyAttribute
# METHOD TYPE
method-type =
  xsd:string "dial-in"
  | xsd:string "dial-out"
  | xsd:string "refer"
  | free-text-extension
# ANONYMITY TYPE
provide-anonymity-type =
  "private" | "semi-private" | "hidden" | free-text-extension
# MIXER TYPE
mixer-type =
  attribute name { mixer-name-type }
  & anyAttribute
  & element xcon:controls { control-type }*
  & element xcon:floor {
      attribute id { text },
      anyAttribute,
      xsd:boolean
    }*
  & anyElement*
# MIXER NAME TYPE
mixer-name-type =
  "VideoIn" | "VideoOut" | "AudioOut" | "AudioIn" | free-text-extension

# FREE TEXT EXTENSION
#

free-text-extension = text

# *********************************
# EXTENSIBILITY OF THE SCHEMA
# *********************************

# EXTENSIBILITY ELEMENTS
#

anyElement =
  element * - (conference-description
               | host-info
               | conference-state
               | users
               | sidebars-by-ref
Top   ToC   RFC6501 - Page 37
               | sidebars-by-val
               | display-text
               | subject
               | free-text
               | keywords
               | conf-uris
               | service-uris
               | maximum-user-count
               | available-media
               | web-page
               | uris
               | uri
               | user-count
               | active
               | locked
               | entry
               | type

               | status
               | purpose
               | modified
               | user
               | associated-aors
               | roles
               | languages
               | cascaded-focus
               | endpoint
               | referred
               | joining-method
               | joining-info
               | disconnection-method
               | disconnection-info
               | media
               | call-info
               | when
               | reason
               | by
               | sip
               | call-id
               | from-tag
               | to-tag
               | label
Top   ToC   RFC6501 - Page 38
               | src-id
               | xcon:conference-password
               | xcon:mixing-mode
               | xcon:codecs
               | xcon:controls
               | xcon:language
               | xcon:allow-sidebars
               | xcon:cloning-parent
               | xcon:sidebar-parent
               | xcon:allow-conference-event-subscription
               | xcon:to-mixer
               | xcon:provide-anonymity
               | xcon:allow-refer-users-dynamically
               | xcon:allow-invite-users-dynamically
               | xcon:allow-remove-users-dynamically
               | xcon:from-mixer
               | xcon:join-handling
               | xcon:user-admission-policy
               | xcon:allowed-users-list
               | xcon:deny-users-list
               | xcon:floor-information
               | xcon:conference-time
               | xcon:provide-anonymity
               | xcon:floor
               | xcon:entry
               | xcon:mixing-start-offset
               | xcon:mixing-end-offset
               | xcon:can-join-after-offset
               | xcon:must-join-before-offset
               | xcon:request-user
               | xcon:notify-end-of-conference
               | xcon:allowed-extend-mixing-end-offset
               | xcon:codec
               | xcon:subtype
               | xcon:mute
               | xcon:pause-video
               | xcon:gain
               | xcon:video-layout
               | xcon:conference-ID
               | xcon:allow-floor-events
               | xcon:floor-request-handling
               | xcon:conference-floor-policy
               | xcon:media-label
               | xcon:algorithm
               | xcon:max-floor-users
               | xcon:moderator-id
               | xcon:target
               | xcon:persistent-list
Top   ToC   RFC6501 - Page 39
               | xcon:e-mail
               | xcon:user) { anyExtension }
anyExtension =
  (attribute * { text }
   | any)*
any =
  element * {
    (attribute * { text }
     | text
     | any)*
  }

# EXTENSIBILITY ATTRIBUTES
#

anyAttribute =
  attribute * - (xml:lang
                 | entity
                 | required-participant
                 | label
                 | decision
                 | name
                 | policy
                 | uri
                 | method
                 | id
                 | nickname) { text }*



(page 39 continued on part 3)

Next Section