Network Working Group                                       T. Melanchuk
Internet-Draft                                Rain Willow Communications
Intended status: Standards Track                            S. McGlashan
Expires: April 17, May 7, 2009                                     Hewlett-Packard
                                                              C. Boulton
                                                                   Avaya
                                                        October 14,
                                                        November 3, 2008

    A Mixer Control Package for the Media Control Channel Framework
             draft-ietf-mediactrl-mixer-control-package-01
             draft-ietf-mediactrl-mixer-control-package-02

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 April 17, May 7, 2009.

Abstract

   This document defines a Mixer Control Package for the Media Control
   Channel Framework.  This Control Package aims to fulfill Conferencing
   requirements using the SIP Control Framework.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  5
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Control Package Definition . . . . . . . . . . . . . . . . . .  8
     4.1.  Control Package Name . . . . . . . . . . . . . . . . . . .  8
     4.2.  Framework Message Usage  . . . . . . . . . . . . . . . . .  8
     4.3.  Common XML Support . . . . . . . . . . . . . . . . . . . .  9
     4.4.  CONTROL Message Body . . . . . . . . . . . . . . . . . . .  9
     4.5.  REPORT Message Body  . . . . . . . . . . . . . . . . . . .  9
     4.6.  Audit  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Element Definitions  . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  <mscmixer> . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Mixer Elements . . . . . . . . . . . . . . . . . . . . . . 12
       5.2.1.  Conference Elements  . . . . . . . . . . . . . . . . . 13
         5.2.1.1.  <createconference> . . . . . . . . . . . . . . . . 13
         5.2.1.2.  <modifyconference> . . . . . . . . . . . . . . . . 16
         5.2.1.3.  <destroyconference>  . . . . . . . . . . . . . . . 17
         5.2.1.4.  Conference Configuration . . . . . . . . . . . . . 17
           5.2.1.4.1.  <audio-mixing> . . . . . . . . . . . . . . . . 18
           5.2.1.4.2.  <video-layouts>  . . . . . . . . . . . . . . . 18
             5.2.1.4.2.1.  <video-layout> . . . . . . . . . . . . . . 19
           5.2.1.4.3.  <video-switch> . . . . . . . . . . . . . . . . 20 24
             5.2.1.4.3.1.  Priority assignment  . . . . . . . . . . . 22 26
           5.2.1.4.4.  <subscribe>  . . . . . . . . . . . . . . . . . 22 27
             5.2.1.4.4.1.  <active-talkers-sub> . . . . . . . . . . . 23 27
       5.2.2.  Joining Elements . . . . . . . . . . . . . . . . . . . 23 27
         5.2.2.1.  Joining Model  . . . . . . . . . . . . . . . . . . 23 27
         5.2.2.2.  <join> . . . . . . . . . . . . . . . . . . . . . . 25 29
         5.2.2.3.  <modifyjoin> . . . . . . . . . . . . . . . . . . . 27 31
         5.2.2.4.  <unjoin> . . . . . . . . . . . . . . . . . . . . . 28 32
         5.2.2.5.  <stream> . . . . . . . . . . . . . . . . . . . . . 29 33
           5.2.2.5.1.  <volume> . . . . . . . . . . . . . . . . . . . 30 34
           5.2.2.5.2.  <clamp>  . . . . . . . . . . . . . . . . . . . 30 34
           5.2.2.5.3.  <region> . . . . . . . . . . . . . . . . . . . 31 35
           5.2.2.5.4.  <priority> . . . . . . . . . . . . . . . . . . 31 35
       5.2.3.  <response> . . . . . . . . . . . . . . . . . . . . . . 31 35
       5.2.4.  <event>  . . . . . . . . . . . . . . . . . . . . . . . 32 36
         5.2.4.1.  <active-talkers-notify>  . . . . . . . . . . . . . 32 36
           5.2.4.1.1.  <active-talker>  . . . . . . . . . . . . . . . 33 36
         5.2.4.2.  <unjoin-notify>  . . . . . . . . . . . . . . . . . 33 37
         5.2.4.3.  <conferenceexit> . . . . . . . . . . . . . . . . . 34 37
     5.3.  Audit Elements . . . . . . . . . . . . . . . . . . . . . . 34 38
       5.3.1.  <audit>  . . . . . . . . . . . . . . . . . . . . . . . 35 39
       5.3.2.  <auditresponse>  . . . . . . . . . . . . . . . . . . . 36 40
         5.3.2.1.  <capabilities> . . . . . . . . . . . . . . . . . . 37 41
         5.3.2.2.  <mixers> . . . . . . . . . . . . . . . . . . . . . 38 42
           5.3.2.2.1.  <conferenceaudit>  . . . . . . . . . . . . . . 38 42
             5.3.2.2.1.1.  <participants> . . . . . . . . . . . . . . 39 43
               5.3.2.2.1.1.1.  <participant>  . . . . . . . . . . . . 39 44
           5.3.2.2.2.  <joinaudit>  . . . . . . . . . . . . . . . . . 40 44
     5.4.  <codecs> . . . . . . . . . . . . . . . . . . . . . . . . . 40 44
       5.4.1.  <codec>  . . . . . . . . . . . . . . . . . . . . . . . 41 45
     5.5.  <params> . . . . . . . . . . . . . . . . . . . . . . . . . 41 46
       5.5.1.  <param>  . . . . . . . . . . . . . . . . . . . . . . . 42 46
     5.6.  Response Status Codes  . . . . . . . . . . . . . . . . . . 42 46
     5.7.  Type Definitions . . . . . . . . . . . . . . . . . . . . . 43 51
   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 45 53
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 71
     7.1.  AS-MS Dialog Framework Interaction Examples . . . . . . . . . . . . 63 71
       7.1.1.  Creating a conference mixer and joining a
               participant  . . . . . . . . . . . . . . . . . . . . . 63 71
       7.1.2.  Receiving active talker notifications  . . . . . . . . 64 72
       7.1.3.  Conference termination . . . . . . . . . . . . . . . . 72
     7.2.  Mixing Examples  . . . . . . . . . . . . . . . . . . . . . 72
       7.2.1.  Audio conferencing . . . . . . . . . . . . . . . . . . 73
       7.2.2.  Bridging connections . . . . . . . . . . . . . . . . . 75
       7.2.3.  Video conferencing . . . . . . . . . . . . . . . . . . 76
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 65 78
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 66 79
     9.1.  Control Package Registration . . . . . . . . . . . . . . . 66 79
     9.2.  URN Sub-Namespace Registration . . . . . . . . . . . . . . 66 79
     9.3.  MIME Registration  . . . . . . . . . . . . . . . . . . . . 66 79
   10. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 67 80
   11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 70 84
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 71 85
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 86
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 72 86
     13.2. Informative References . . . . . . . . . . . . . . . . . . 72 86
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74 88
   Intellectual Property and Copyright Statements . . . . . . . . . . 75 89

1.  Introduction

   This document defines a Media Control Channel Framework Package for
   conference mixers and connection mixers.  The package defines mixer
   management elements for creating, modifying and deleting conference
   mixers, elements for joining, modifying and unjoining media streams
   between connections and conferences (including mixers between
   connections), as well as associated responses and notifications.  The
   package also defines elements for auditing package capabilities and
   mixers.

2.  Conventions and Terminology

   In this document, BCP 14/RFC 2119 [RFC2119] defines the key words
   "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL".  In addition, BCP 15 indicates requirement levels for
   compliant implementations.

   The following additional terms are defined for use in this document:

   Application server:  A SIP [RFC3261] application server (AS) is a
      control client that hosts and executes services such as
      interactive media and conferencing in an operator's network.  An
      AS controls the media server (MS), influencing and impacting the
      SIP sessions terminating on a media server, which the AS may have
      established for example using SIP third party call control.

   Media Server:  A media server (MS) processes media streams on behalf
      of an AS by offering functionality such as interactive media,
      conferencing, and transcoding to the end user.  Interactive media
      functionality is realized by way of dialogs, which are identified
      by a URI and initiated by the application server.

   MS Conference:  A MS Conference provides the media related mixing
      resources and services for conferences.  In this document, A MS
      Conference is often referred to simply as a conference.

   MS Connection:  A Media Server connection represents the termination
      on a media server of one or more RTP [RFC3550] sessions that are
      associated to a single SIP dialog.  A media server receives media
      from the output(s) of a connection and it transmits media on the
      input(s) of a connection.

   Media Stream:  A media stream on a media server represents a media
      flow between either a connection and a conference, between two
      connections, or between two conferences.  Streams may be audio or
      video and may be bi-directional or uni-directional.

3.  Overview

   The SIP Control Framework [I-D.ietf-mediactrl-sip-control-framework]
   provides a generic approach for establishment and reporting
   capabilities of remotely initiated commands.  The Framework utilizes
   many functions provided by the Session Initiation Protocol [RFC3261]
   (SIP) for the rendezvous and establishment of a reliable channel for
   control interactions.  The Control Framework also introduces the
   concept of a Control Package.  A Control Package is an explicit usage
   of the Control Framework for a particular interaction set.  This
   specification defines a package for media conference mixers and media
   connection mixers.

   This package defines mixer management elements for creating,
   modifying and deleting conference mixers, elements for joining,
   modifying and unjoining media streams between connections and
   conferences (including mixers between connections), as well as
   associated responses and notifications.  The package also defines
   elements for auditing package capabilities and mixers.

   This package has been designed to satisfy the IETF MediaCtrl
   requirements ([RFC5167]).  The package provides the major
   conferencing functionality of SIP Media Server languages such as
   MSCML ([RFC5022]) and MSML ([MSML]).  A key differentiator is that
   this package provides such functionality using the Media Control
   Channel Framework.

   Out of scope for this mixer package are more advanced functions
   including personalized video mixes for conference participants,
   support for floor control protocols, as well as support for video
   overlays and text insertion.  Such functionality may be addressed by
   extensions to this package (through addition of foreign elements or
   attributes from another namespace) or use of other control packages
   which could build upon this package.

   The functionality of this package is defined by messages, containing
   XML [XML] elements, transported using the Media Control Channel
   Framework.  The XML elements can be divided into two types: mixer
   management elements; and elements for auditing package capabilities
   as well as mixers managed by the package.

   The document is organized as follows.  Section 4 descibes describes how this
   control package fulfills the requirements for a Media Control Channel
   Framework control package.  Section 5 describes the syntax and
   semantics of defined elements, including mixer management
   (Section 5.2) and audit elements (Section 5.3).  Section 6 describes
   an XML schema for these elements and provides extensibility by
   allowing attributes and elements from other namespaces.  Section 7
   provides examples of package usage.

4.  Control Package Definition

   This section fulfils fulfills the mandatory requirement for information that
   MUST be specified during the definition of a Control Framework
   Package, as detailed in Section 8 of
   [I-D.ietf-mediactrl-sip-control-framework].

4.1.  Control Package Name

   The Control Framework requires a Control Package definition to
   specify and register a unique name.  The name and version of this
   Control Package is "msc-mixer/1.0" (Media Server Control - Mixer -
   version 1.0).  Its IANA registration is specified in Section 9.1.

   Since this is the initial ("1.0") version of the control package,
   there are no backwards compatibility issues to address.

4.2.  Framework Message Usage

   The Control Framework requires a Control Package to explicitly detail
   the control messages that can be used as well as provide an
   indication of directionality between entities.  This will include
   which role type is allowed to initiate a request type.

   This package specifies CONTROL and response messages in terms of XML
   elements defined in Section 5. 5, where the message bodies have the MIME
   media type defined in Section 9.3.  These elements describe requests,
   response and notifications and all are contained within a root
   <mscmixer> element (Section 5.1).

   In this package, the MS operates as a Control Framework Server in receiving
   requests from, and sending responses to, the AS (operating as Control Framework
   Client).  Mixer management requests and responses are defined in
   Section 5.2.  Audit requests and responses are defined in
   Section 5.3.  Mixer management and audit responses are carried in a
   framework 200 response or REPORT message bodies.  This package's
   response codes are defined in Section 5.6.

   Note that package responses are different from framework response
   codes.  Framework error response codes (see Section 8 of
   [I-D.ietf-mediactrl-sip-control-framework]) are used when the request
   or event notification is invalid; for example, a request is invalid
   XML (400), or not understood (500).

   The MS also operates as a Control Framework Client in sending event
   notification to the AS (Control Framework Server).  Event notifications
   (Section 5.2.4) are carried in CONTROL message bodies.  The AS MUST
   respond with a Control Framework 200 response.

4.3.  Common XML Support

   The Control Framework requires a Control Package definition to
   specify if the attributes for media dialog or conference references
   are required.

   This package requires that the XML Schema in Section 17.1 of
   [I-D.ietf-mediactrl-sip-control-framework] MUST be supported for
   media dialogs and conferences.

   The package uses "connectionid" and "conferenceid" attributes for
   various element definitions (Section 5).  The XML schema (Section 6)
   imports the definitions of these attributes from the framework
   schema.

4.4.  CONTROL Message Body

   The Control Framework requires a Control Package to define the
   control body that can be contained within a CONTROL command request
   and to indicate the location of detailed syntax definitions and
   semantics for the appropriate body types.

   When operating as Control Framework Server, the MS receives CONTROL messages
   with the MIME media type defined in Section 9.3 and a body containing an
   a <mscmixer> element (Section 5.1) with either a mixer management or
   audit request child element.

   The following mixer management request elements are carried in
   CONTROL message bodies to MS: <createconference> (Section 5.2.1.1),
   <modifyconference> (Section 5.2.1.2), <destroyconference>
   (Section 5.2.1.3), <join> (Section 5.2.2.2), <modifyjoin>
   (Section 5.2.2.3) and <unjoin> (Section 5.2.2.4) elements.

   The <audit> request element (Section 5.3.1) is also carried in
   CONTROL message bodies.

   When operating as Control Framework Client, the MS sends CONTROL messages with
   the MIME media type defined in Section 9.3 and a body containing a
   <mscmixer> element (Section 5.1) with a notification <event> child
   element (Section 5.2.4).

4.5.  REPORT Message Body

   The Control Framework requires a control package definition to define
   the REPORT body that can be contained within a REPORT command
   request, or that no report package body is required.  This section
   should indicate the location of detailed syntax definitions and
   semantics for the appropriate body types.

   When operating as Control Framework Server, the MS sends REPORT bodies containing a with the
   MIME media type defined in Section 9.3 and a <mscmixer> element with
   a response child element.  The response element for mixer management
   requests is a <response> element (Section 5.2.3).  The response
   element for an audit request is a <auditresponse> element
   (Section 5.3.2).

4.6.  Audit

   The Control Framework encourages Control Packages to specify whether
   auditing is available, how it is triggered as well as the query/
   response formats.

   This Control Packages supports auditing of package capabilities and
   mixers on the MS.  An audit request is carried in a CONTROL messages message
   and an audit response in a REPORT message (or a 200 reponse response to the
   CONTROL if it can execute the audit in time).

   The syntax and semantics of audit request and response elements is
   defined in Section 5.3.

4.7.  Examples

   The Control Framework recommends Control Packages to provide a range
   of message flows that represent common flows using the package and
   this framework document.

   This Control Package provides examples of such message flows in
   Section 7.

5.  Element Definitions

   This section defines the XML elements for this package.  The elements
   are defined in the XML namespace specified in Section 9.2.

   The root element is <mscmixer> (Section 5.1).  All other XML elements
   (requests, responses and notification elements) are contained within
   it.  Child elements describe mixer management (Section 5.2) and audit
   (Section 5.3) functionality.  Response status codes are defined in
   Section 5.6 and type definitions in Section 5.7.

   Implementation of this control package MUST adhere to the syntax and
   semantics of XML elements defined in this section and the schema
   (Section 6).  The XML schema supports extensibility by allowing
   attributes and elements from other namespaces.  Implementations MAY
   support attributes and elements from other (foreign) namespaces.  If
   an MS implementation receives a <mscmixer> element containing
   attributes or elements from another namespace which it does not
   support, the MS MUST send a 427 428 response (Section 5.6).

   Extensible attributes and elements are not described in this section.
   In all other cases where there is a difference in constraints between
   the XML schema and the textual description of elements in this
   section, the textual definition takes priority.

   Usage examples are provided in Section 7.

5.1.  <mscmixer>

   The <mscmixer> element has the following attributes (in addition to
   standard XML namspace namespace attributes such as xmlns):

   version:  a string specifying the mscmixer package version.  The
      value is fixed as '1.0' for this version of the package.  The
      attribute is mandatory.

   The <mscmixer> element has the following defined child elements, only
   one of which can occur:

   1.  mixer management elements defined in Section 5.2:

       <createconference>  create and configure a new a conference mixer.
          See Section 5.2.1.1

       <modifyconference>  modify the configuration of an existing
          conference mixer.  See Section 5.2.1.2
       <destroyconference>  destroy an existing conference mixer.  See
          Section 5.2.1.3

       <join>  create and configure media streams between connections
          and/or conferences (for example, add a participant to a
          conference).  See Section 5.2.2.2

       <modifyjoin>  modify the configuration of joined media streams.
          See Section 5.2.2.3

       <unjoin>  delete a media stream (for example, remove a
          participant from a conference).  See Section 5.2.2.4

       <response>  response to a mixer request.  See Section 5.2.3

       <event>  mixer or subscription notification.  See Section 5.2.4

   2.  audit elements defined in Section 5.3:

       <audit>  audit package capabilities and managed mixers.  See
          Section 5.3.1

       <auditresponse>  response to an audit request.  See Section 5.3.2

   For example, a request to the MS to create a conference mixer:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <createconference/>
   </mscmixer>

   and a response from the MS that the conference was sucessfully successfully
   created:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="200" conferenceid="conference1"/>
   </mscmixer>

5.2.  Mixer Elements

   This section defines the mixer management XML elements for this
   control package.  These elements are divided into requests, responses
   and notifications.

   Request elements are sent to the MS to request a specific mixer
   operation to be executed.  The following request elements are
   defined:

   <createconference>  create and configure a new a conference mixer.
      See Section 5.2.1.1

   <modifyconference>  modify the configuration of an existing
      conference mixer.  See Section 5.2.1.2

   <destroyconference>  destroy an existing conference mixer.  See
      Section 5.2.1.3

   <join>  create and configure media streams between connections and/or
      conferences (for example, add a participant to a conference).  See
      Section 5.2.2.2

   <modifyjoin>  modify the configuration of joined media streams.  See
      Section 5.2.2.3

   <unjoin>  delete a media stream (for example, remove a participant
      from a conference).  See Section 5.2.2.4

   Responses from the MS describe the status of the requested operation.
   Responses are specified in a <response> element (Section 5.2.3). 5.2.3) which
   includes a mandatory attribute describing the status in terms of a
   numeric code.  Response status codes are defined in Section 5.6.  The
   MS MUST respond to a request message with a response message.  If the
   MS is not able to process the request and carry out the requested mixer
   operation, it is an
   error the request has failed and the MS MUST indicate the class
   of failure using an appropriate 4xx response code.  Unless an error
   response code is mandated for a specific class of error within this
   section, implementations follow Section 5.6 in determining the
   appropriate status code of for the response.

   Notifications are sent from the MS to provide updates on the status
   of a mixer operation or subscription.  Notifications are specified in
   an <event> element (Section 5.2.4).

5.2.1.  Conference Elements

5.2.1.1.  <createconference>

   The <createconference> element is sent to the MS to request creation
   of a new conference (multiparty) mixer.

   The <createconference> element has the following attributes:

   conferenceid:  string indicating a unique name for the new
      conference.  If this attribute is not specified, the MS MUST
      create a unique name for the conference.  The value is used in
      subsequent references to the conference (e.g. as conferenceid in a
      <response>).  The attribute is optional.  There is no default
      value.

   reserved-talkers:  indicates the requested number of guaranteed
      speaker slots to be reserved for the conference.  A valid value is
      a non-negative integer (see Section 5.7.2).  The attribute is
      optional.  The default value is 0.

   reserved-listeners:  indicates the requested number of guaranteed
      listener slots to be reserved for the conference.  A valid value
      is a non-negative integer (see Section 5.7.2).  The attribute is
      optional.  The default value is 0.

   The <createconference> element has the following sequence of child
   elements:

   <codecs>:  an element to configure the codecs supported by the
      conference (see Section 5.4).  The element is optional.

   <audio-mixing>:  an element to configure the audio mixing
      characteristics of a conference (see Section 5.2.1.4.1).  The
      element is optional.

   <video-layouts>:  an element to configure the video layouts of a
      conference (see Section 5.2.1.4.2).  The element is optional.

   <video-switch>:  an element to configure the video switch policy for
      the layout of a conference (see Section 5.2.1.4.3).  The element
      is optional.

   <subscribe>:  an element to request subscription to conference
      events. (see Section 5.2.1.4.4).  The element is optional.

   If the conferenceid attribute specifies the name of a conference
   which already exists, the MS MUST report an error (403) (405) and MUST NOT
   create the conference.

   If the MS is unable to configure the conference according to a
   specified <codecs> element, reserved-talkers or reserved-listeners attributes, the MS
   MUST report an error (410) (420) and MUST NOT create the conference.

   If the MS is unable to configure the conference according to a
   specified <audio-mixing> element, the MS MUST report an error (405) (421)
   and MUST NOT create the conference.

   If the MS is unable to configure the conference according to a for any specified <video-layouts>
   conference event specified in the <subscribe> element, the MS MUST
   report an error (408) (422) and MUST NOT create the conference.

   If the MS is unable to configure the conference according to a
   specified <video-switch> <video-layouts> element, the MS MUST report an error (409) (423)
   and MUST NOT create the conference.

   If the MS is unable to configure the conference according to a
   specified reserved-talkers or reserved-listeners attributes, <video-switch> element, the MS MUST report an error (407) (424)
   and MUST NOT create the conference.

   If the MS is unable to configure the conference for any specified
   conference event according to a
   specified in the <subscribe> <codecs> element, the MS MUST report an error (406) (425) and
   MUST NOT create the conference.

   When a MS has finished processing a <createconference> request, it
   MUST reply with an appropriate <response> element (Section 5.2.3).

   For example, a request to create an audio video conference mixer with
   specified codecs, video layout, video switch and subscription:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <createconference conferenceid="conference1"
          reserved-talkers="1" reserved-listeners="10">
      <codecs>
       <codec>
        <subtype>H264</subtype>
       </codec>
       <codec>
        <subtype>PCMA</subtype>
       </codec>
      </codecs>
      <audio-mixing type="nbest"/>
      <video-layouts>
       <video-layout min-participants="1">single-view</video-layout>
       <video-layout min-participants="2">dual-view</video-layout>
       <video-layout min-participants="3">quad-view</video-layout>
      </video-layouts>
      <video-switch type="vas" interval="5"/>
      <subscribe>
       <active-talkers-sub interval="4"/>
      </subscribe>
    </createconference>
   </mscmixer>

   and a response from the MS if the conference was sucessfully successfully
   created:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="200" conferenceid="conference1"/>
   </mscmixer>
   alternatively, a response if MS could not create the conference due
   to a lack of support for the H264 codec:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="410" status="425" conferenceid="conference1"
              reason="H264 codec not supported"/>
   </mscmixer>

5.2.1.2.  <modifyconference>

   The <modifyconference> element is sent to the MS to request
   modification of an existing conference.

   The <modifyconference> element has the following attributes:

   conferenceid:  string indicating the name of the conference to
      modify.  This attribute is mandatory.

   The <modifyconference> element has the following sequence of child
   elements (1 or more):

   <codecs>:  an element to configure the codecs supported by the
      conference (see Section 5.4).  Existing participants are
      unaffected by any policy chage. change.  The element is optional.

   <audio-mixing>:  an element to configure the audio mixing
      characteristics of a conference (see Section 5.2.1.4.1).  The
      element is optional.

   <video-layouts>:  an element to configure the video layouts of a
      conference (see Section 5.2.1.4.2).  The element is optional.

   <video-switch>:  an element to configure the video switch policy for
      the layout of a conference (see Section 5.2.1.4.3).  The element
      is optional.

   <subscribe>:  an element to request subscription to conference
      events. (see Section 5.2.1.4.4).  The element is optional.

   If the conferenceid attribute specifies the name of a conference
   which does not exist, the MS MUST report an error (404). (406).

   If the MS is unable to configure the conference according to a
   specified <codecs> <audio-mixing> element, the MS MUST report an error (410) (421)
   and MUST NOT modify the conference. conference in any way.

   If the MS is unable to configure the conference according to a for any specified <audio-mixing>
   conference event specified in the <subscribe> element, the MS MUST
   report an error (405) (422) and MUST NOT modify the conference in any way. anyway.

   If the MS is unable to configure the conference according to a
   specified <video-layouts> element, the MS MUST report an error (408) (423)
   and MUST NOT modify the conference in any way.

   If the MS is unable to configure the conference according to a
   specified <video-switch> element, the MS MUST report an error (409) (424)
   and MUST NOT modify the conference in any way.

   If the MS is unable to configure the conference for any specified
   conference event according to a
   specified in the <subscribe> <codecs> element, the MS MUST report an error (406) (425) and
   MUST NOT modify the conference in anyway. conference.

   When a MS has finished processing a <modifyconference> request, it
   MUST reply with an appropriate <response> element (Section 5.2.3).

5.2.1.3.  <destroyconference>

   The <destroyconference> element is sent to the MS to request
   destruction of an existing conference.

   The <destroyconference> element has the following attributes:

   conferenceid:  string indicating the name of the conference to
      destroy.  This attribute is mandatory.

   The <destroyconference> element does not specify any child elements.

   If the conferenceid attribute specifies the name of a conference
   which does not exist, the MS MUST report an error (404). (406).

   When a MS has finished processing a <destroyconference> request, it
   MUST reply with an appropriate <response> element (Section 5.2.3).

   Successfully destroying the conference (status code 200) will result
   in all connection or conference particpants participants being removed from the
   conference mixer, <unjoin-notify> notification events
   (Section 5.2.4.2) being sent for each conference participant and a
   <conferenceexit> notification event (Section 5.2.4.3) indicating that
   conference has exited.  A <response> with any other status code
   indicates that the conference mixer still exists and participants are
   still joined to the mixer.

5.2.1.4.  Conference Configuration

   The elements in this section are used to establish and modify the
   configuration of conferences.

5.2.1.4.1.  <audio-mixing>

   The <audio-mixing> element defines the configuration of the
   conference audio mix.  It has no child elements and has the following
   attributes:

   type:  is a string indicating the audio stream mixing policy.
      Defined values are: "nbest" (where the N best participant signals
      are mixed) and "controller" (where the contributing participant(s)
      is/are selected by the controlling AS via an external floor
      control protocol).  The default value is "nbest".  The attribute
      is optional.

5.2.1.4.2.  <video-layouts>

   The <video-layouts> element describe the video presentation layout
   configuration for participants providing a video input stream to the
   conference.  This element allows multiple video layouts to be
   specified so that the MS automatically changes layout depending on
   the number of video-enabled participants.

   The <video-layouts> element has no attributes.

   The <video-layouts> element has the following sequence of child
   elements (1 or more):

   <video-layout>:  element describing a video layout
      (Section 5.2.1.4.2.1).

   If the MS does not support video conferencing at all, or does not
   support multiple video layouts, or does not support a specific video
   layout, the MS MUST report an 408 error in the response to the
   request element containing the <video-layouts> element.

   An MS MAY support more than one <video-layout> element, although only
   one layout can be active at a time.  A <video-layout> is active if
   the number of participants in the conference is equal to or greater
   than the value of its "min-participants" attribute, but less than the
   value of the "min-participants" attribute for any other <video-
   layout> element.  An MS MUST report an error if more than one <video-
   layout> has the same value for the "min-participants" attribute.
   When the number of regions within the active layout is greater than
   the number of participants in the conference, the display of
   unassigned regions is implementation-specific.

   The assignment of participant video streams to regions within the
   layout is according to the video switch policy specified by the
   <video-switch> element (Section 5.2.1.4.3).

   For example, a fragment describing a single layout:

   <video-layouts>
     <video-layout>single-view</video-layout>
   </video-layouts>

   And a fragment describing a sequence of layouts:

   <video-layouts>
     <video-layout min-participants="1" >single-view</video-layout> min-participants="1">single-view</video-layout>
     <video-layout min-participants="2">dual-view</video-layout>
     <video-layout min-participants="3">quad-view</video-layout>
     <video-layout min-participants="5">multiple-3x3</video-layout>
   </video-layouts>

   When the conference has one participant providing a video input
   stream to the conference, then the single-view format is used.  When
   the conference has two such participants, the dual-view layout is
   used.  When the conference has three or four particpants, participants, the quad-
   view layout is used.  When the conference has five or more
   particpants,
   participants, the multiple-3x3 layout is used.

5.2.1.4.2.1.  <video-layout>

   The <video-layout> element describes a video layout containing one or
   more regions in which participant video input stream streams are displayed.

   The <video-layout> element has the following attributes:

   min-participants:  the minimum number of conference participants
      needed to allow this layout to be active.  A valid value is a
      positive integer (see Section 5.7.3).  The attribute is optional.
      The default value is 1.

   The <video-layout> element has a content model specifying the name of
   the video layout.

   It is RECOMMENDED that an MS support the predefined video layouts
   defined in the XCON conference information data model
   ([I-D.ietf-xcon-common-data-model]).  The MS MAY support other video
   layouts.  It is RECOMMENDED that non-XCON layouts are prefixed with a
   label; for example, <video-layout>mylayout:single-view<video-layout>.

   Each video layout has associated with it one or more regions.  The
   XCON layouts have associated the following named regions:

   single-view  layout with one stream in a single region with name "region1" as shown in
      Figure 1.

                               +-----------+
                               |           |
                               |           |
                               |     1     |
                               |           |
                               |           |
                               +-----------+

                      Figure 1: single-view video layout

   dual-view  layout presenting two regions: left named "region1", right "region2"

   XXX  etc

   [Editors Note: MIXER-003.  ASCII art help required streams side-by-side in two regions
      as shown in Figure 2.  The MS MUST NOT alter the aspect ratio of
      each stream to draw fit the layout region and name the regions for the remaining XCON layouts. ]

5.2.1.4.3.  <video-switch>

   The <video-switch> element describe hence the configuration MS MAY have to blank
      part of the
   conference policy for how participant's input each region.

                         +-----------+-----------+
                         |           |           |
                         |           |           |
                         |     1     |     2     |
                         |           |           |
                         |           |           |
                         +-----------+-----------+

                       Figure 2: dual-view video layout

   dual-view-crop  layout presenting two streams are
   assigned to side-by-side in two
      regions within the active video layout. as shown in Figure 3.  The <video-switch> element has the following attributes:

   type:  a string indicating the video switching policy of MS MUST alter the
      conference.  Defined values are:

      vas  (Voice Activated Switching) enables automatic display aspect ratio
      of the
         most active speaker participant also providing a video input each stream to the conference.  Participants who do not provide an
         audio stream are not considered for automatic display.  If a
         participant provides more than one audio stream, then the
         policy for inclusion of such a participant in the VAS is
         implementation-specific; an MS could select one stream, sum
         audio streams or ignore the participant for VAS consideration.
         If there is only one fit its region in the layout, then the most active
         speaker so that no blanking is displayed there.  If more than required.

                         +-----------+-----------+
                         |           |           |
                         |           |           |
                         |     1     |     2     |
                         |           |           |
                         |           |           |
                         +-----------+-----------+

                    Figure 3: dual-view-crop video layout
   dual-view-2x1  layout presenting two streams one region is
         available, then above the most active speaker is displayed other in the
         largest region, if any, and then
      two regions as shown in the first region from the
         top-left corner of the layout. Figure 4.  The MS assigns MUST NOT alter the remaining
         regions based on
      aspect ratio of each stream to fit its region and hence the priority mechanism described in
         Section 5.2.1.4.3.1.

      controller  enables manual control over MS MAY
      have to blank part of each region.

                               +-----------+
                               |           |
                               |           |
                               |     1     |
                               |           |
                               |           |
                               +-----------+
                               |           |
                               |           |
                               |     2     |
                               |           |
                               |           |
                               +-----------+

                     Figure 4: dual-view-2x1 video switching.  The
         controller AS determines how layout

   dual-view-2x1-crop  layout presenting two streams one above the other
      in two regions are assigned based on
         an external floor control policy. as shown in Figure 5.  The MS receives <join>,
         <modifyjoin> and <join> commands with a <stream> element
         (Section 5.2.2.5) indicating the region where MUST alter the aspect
      ratio of each stream is
         displayed.  If no explicit to fit its region so that no blanking is specified, the MS assigns
         the region based on the priority mechanism described in
         Section 5.2.1.4.3.1.

      An MS MAY support other
      required.

                               +-----------+
                               |           |
                               |           |
                               |     1     |
                               |           |
                               |           |
                               +-----------+
                               |           |
                               |           |
                               |     2     |
                               |           |
                               |           |
                               +-----------+

                  Figure 5: dual-view-2x1-crop video switching policies.  It is
      RECOMMENDED that other policy names are prefixed with layout
   quad-view  layout presenting four equal-sized regions in a label;
      e.g. "mypolicies:policy1".  The attribute 2x2 layout
      as shown in Figure 6.  Typically the aspect ratio of the streams
      is optional.  The
      default value preserved, so blanking is 'vas'.

   interval:  specifies the period between required.

                         +-----------+-----------+
                         |           |           |
                         |           |           |
                         |     1     |     2     |
                         |           |           |
                         |           |           |
                         +-----------+-----------+
                         |           |           |
                         |           |           |
                         |     3     |     4     |
                         |           |           |
                         |           |           |
                         +-----------+-----------+

                       Figure 6: quad-view video switches as layout

   multiple-3x3  layout presenting nine equal-sized regions in a number of
      seconds.  In 3x3
      layout as shown in Figure 7.  Typically the case aspect ratio of 'vas' policy, a speaker needs to be the
      most active speaker for the interval before the switch takes
      place.  A valid value
      streams is a non-negative integer (see
      Section 5.7.2).  A value of 0 indicates that switching is applied
      immediately.  The attribute is optional.  The default value preserved, so blanking is required.

                   +-----------+-----------+-----------+
                   |           |           |           |
                   |           |           |           |
                   |     1     |     2     |     3
      (seconds).

   activespeakermix:  indicates whether or not the active speaker
      participant receives a     |
                   |           |           |           |
                   |           |           |           |
                   +-----------+-----------+-----------+
                   |           |           |           |
                   |           |           |           |
                   |     4     |     5     |     6     |
                   |           |           |           |
                   |           |           |           |
                   +-----------+-----------+-----------+
                   |           |           |           |
                   |           |           |           |
                   |    7      |     8     |     9     |
                   |           |           |           |
                   |           |           |           |
                   +-----------+-----------+-----------+
                     Figure 7: multiple-3x3 video stream without themselves displayed layout

   multiple-4x4  layout presenting sixteen equal-sized regions in the case of the 'vas' switching policy.  If enabled, the MS
      needs to generate two video streams for each conference mix: one
      for the active speaker participant without themselves displayed -
      details of this video a 4x4
      layout are implementation-specific; and one
      for other participants as described shown in Figure 8.  Typically the 'vas' switch policy
      above.  A valid value is a boolean (see Section 5.7.1).  A value
      of true indicates that a separate video mix is generated for the
      active speaker without themselves being displayed.  A value aspect ratio of
      false indicates that all participants receive the same video mix.
      The attribute is optional.  The default value
      streams is false.  If the
      type attribute preserved, so blanking is not set to 'vas', the MS MUST ignore this
      attribute.

   If the MS does not support the specified video switching policy or
   other configuration parameters (including separate active speaker
   video mixes), then MS MUST report a 409 error (Section 5.6) required.

             +-----------+-----------+-----------+-----------+
             |           |           |           |           |
             |           |           |           |           |
             |     1     |     2     |     3     |     4     |
             |           |           |           |           |
             |           |           |           |           |
             +-----------+-----------+-----------+-----------+
             |           |           |           |           |
             |           |           |           |           |
             |     5     |     6     |     7     |     8     |
             |           |           |           |           |
             |           |           |           |           |
             +-----------+-----------+-----------+-----------+
             |           |           |           |           |
             |           |           |           |           |
             |     9     |    10     |    11     |    12     |
             |           |           |           |           |
             |           |           |           |           |
             +-----------+-----------+-----------+-----------+
             |           |           |           |           |
             |           |           |           |           |
             |    13     |    14     |    15     |    16     |
             |           |           |           |           |
             |           |           |           |           |
             +-----------+-----------+-----------+-----------+

                     Figure 8: multiple-4x4 video layout

   multiple-5x1  layout presents a 5x1 layout as shown in Figure 9 where
      one region will occupy 4/9 of the
   response to mixed video stream while the request element containing
      others will each occupy 1/9 of the <video-switch>
   element.

   If stream.  Typically the MS receives a <join> or <modifyjoin> request containing a a
   <stream> element (Section 5.2.2.5) specifying a region and aspect
      ratio of the
   conference video switching policy streams is set to 'vas', then preserved, so blanking is required.

                   +-----------------------+-----------+
                   |                       |           |
                   |                       |           |
                   |                       |     2     |
                   |                       |           |
                   |                       |           |
                   |           1           +-----------+
                   |                       |           |
                   |                       |           |
                   |                       |     3     |
                   |                       |           |
                   |                       |           |
                   +-----------+-----------+-----------+
                   |           |           |           |
                   |           |           |           |
                   |    4      |     5     |     6     |
                   |           |           |           |
                   |           |           |           |
                   +-----------+-----------+-----------+

                     Figure 9: multiple-5x1 video layout

5.2.1.4.3.  <video-switch>

   The <video-switch> element describe the MS MUST
   ignore configuration of the region (i.e.
   conference switching policy takes
   precedence).

   The <video-switch> element for how participant's input video streams are
   assigned to regions within the active video layout.

   The <video-switch> element has no child elements.

   For example, a fragment specifying the following attributes:

   type:  a 'vas' string indicating the video switching policy
   with an interval of 2s

    <video-switch type="vas" interval="2"/>

   For example, a fragment specifying the
      conference.  Defined values are:

      vas  (Voice Activated Switching) enables automatic display of the
         most active speaker participant also providing a 'controller' video switching
   policy where video switching takes place immediately:

    <video-switch type="controller" interval="0"/>

5.2.1.4.3.1.  Priority assignment

   In cases where input
         stream to the video switching policy does conference.  Participants who do not explicitly
   determine the region to which provide an
         audio stream are not considered for automatic display.  If a
         participant is assigned, provides more than one audio stream, then the
   following priority assignment mechanism applies:

   1.  Each
         policy for inclusion of such a participant has an (positive integer) priority value: in the
       lower VAS is
         implementation-specific; an MS could select one stream, sum
         audio streams or ignore the value, participant for VAS consideration.
         If there is only one region in the higher layout, then the priority.  The priority value most active
         speaker is
       determined by the <priority> child element (Section 5.2.2.5.4) of
       <stream>. displayed there.  If not explicitly specified, more than one region is
         available, then the default priority
       value most active speaker is 100.

   2.  The MS uses priority values to assign participants to regions displayed in the video layout which remain unfilled after application
         largest region, if any, and then in the first region from the
         top-left corner of the
       video switching policy. layout.  The MS MUST dedicate larger and/or more
       prominent portions of assigns the remaining
         regions based on the layout to participants with higher
       priority values first (e.g. first all participants with priority
       1, then those with 2, 3, etc).

   3. mechanism described in
         Section 5.2.1.4.3.1.

      controller  enables manual control over video switching.  The policy for displaying participants with
         controller AS determines how the same priority is
       implementation-specific. regions are assigned based on
         an external floor control policy.  The MS applies this priority policy each time receives <join>,
         <modifyjoin> and <join> commands with a <stream> element
         (Section 5.2.2.5) indicating the video layout region where the stream is
   changed or updated.  It
         displayed.  If no explicit region is RECOMMENDED that specified, the MS does not move a
   participant from one assigns
         the region to another unless required by based on the priority mechanism described in
         Section 5.2.1.4.3.1.

      An MS MAY support other video switching policies.  It is
      RECOMMENDED that other policy when an active video layout names are prefixed with a label;
      e.g. "mypolicies:policy1".  The attribute is updated.

   This model allows the MS to apply optional.  The
      default video layouts after
   applying value is 'vas'.

   interval:  specifies the period between video switch policy.  For example, region 2 is
   statically assigned to Bob, so switches as a number of
      seconds.  In the priority mechanism only applies to
   regions 1, 3, 4, etc.

5.2.1.4.4.  <subscribe>

   The <subscribe> element is case of 'vas' policy, a container for specifying conference
   notification events speaker needs to which a controlling entity subscribes.
   Notifications of conference events are delivered using be the <event>
   element
      most active speaker for the interval before the switch takes
      place.  A valid value is a non-negative integer (see
      Section 5.2.4). 5.7.2).  A value of 0 indicates that switching is applied
      immediately.  The <subscribe> element has no attributes, but has the following
   child element:

   <active-talkers-sub>:  subscription to active talker events
      (Section 5.2.1.4.4.1).  The element attribute is optional.  The MS SHOULD support default value is 3
      (seconds).

   activespeakermix:  indicates whether or not the active speaker
      participant receives a <active-talkers-sub> subscription.  It MAY
   support other event subscriptions. video stream without themselves displayed
      in the case of the 'vas' switching policy.  If enabled, the MS does not support a
   requested subscription, it MUST send a <response> with a 406 status
   code.

5.2.1.4.4.1.  <active-talkers-sub>

   The <active-talkers-sub> element has the following attributes:

   interval:
      needs to generate two video streams for each conference mix: one
      for the minimum amount of time (in seconds) that must elapse
      before further active talker events can be generated. speaker participant without themselves displayed -
      details of this video layout are implementation-specific; and one
      for other participants as described in the 'vas' switch policy
      above.  A valid value is a non-negative integer boolean (see Section 5.7.2). 5.7.1).  A value
      of 0
      suppresses further notifications. true indicates that a separate video mix is generated for the
      active speaker without themselves being displayed.  A value of
      false indicates that all participants receive the same video mix.
      The attribute is optional.  The default value is 3 (seconds).

   The <active-talker-sub> element has no child elements.

   Active talker notifications are delivered in false.  If the <active-talker-
   notify> element (Section 5.2.4.1).

5.2.2.  Joining Elements

5.2.2.1.  Joining Model

   The <join> operation creates a media stream between a connection and
   a conference, between connections, or between conferences.  This sub-
   section describes
      type attribute is not set to 'vas', the model of conferences and connections and
   specifies MS MUST ignore this
      attribute.

   If the behaviour for join requests to targets that already
   have an associated media stream.

   Conferences MS does not support multiple inputs and have resources to mix them
   together.  A media server conference in essence is the specified video switching policy or
   other configuration parameters (including separate active speaker
   video mixes), then MS MUST report a mixer that
   combines media streams.  A simple audio mix simply sums its input
   audio signals 409 error (Section 5.6) in the
   response to create a single common output.  Conferences however
   use a more complex algorithm so that participants do not hear
   themselves as part of the mix.  That algorithm, sometimes called an
   n-minus mix, subtracts each participants input signal from request element containing the summed
   input signals, creating <video-switch>
   element.

   If the MS receives a unique output for each contributing
   participant.  Each <join> operation to or <modifyjoin> request containing a conference uses one of a
   <stream> element (Section 5.2.2.5) specifying a region and the
   conferences available inputs and/or outputs,
   conference video switching policy is set to 'vas', then the maximum number of
   supported participants.

   A connection is MS MUST
   ignore the termination of a RTP session(s) on a media
   server.  It has a single input and output for each media session
   established by its SIP dialog.  The output of region (i.e. conference switching policy takes
   precedence).

   If the MS receives a connection may feed
   several different inputs such as both <join> or <modifyjoin> request containing a conference mix and
   <stream> element (Section 5.2.2.5) specifying a
   recording of that participants audio.

   Joining two connections region which are are is not joined to anything else
   simply creates a media stream from
   defined for the outputs(s) of one connection
   to currently active video layout, the corresponding inputs(s) of MS MUST NOT report
   an error.  Even though the other connection.  It participant is not
   necessary to combine media from multiple sources in this case.  There
   are however several common scenarios where combining media from
   several sources to create a single input currently visible, the
   MS MUST display the participant if the layout changes to a connection is needed.

   In one which
   defines the first case, specified region.

   The <video-switch> element has no child elements.

   For example, a connection may be receiving media from one
   source, for example fragment specifying a conference, and it is necessary to play 'vas' video switching policy
   with an
   announcement to the connection so that both interval of 2s

    <video-switch type="vas" interval="2"/>

   For example, a fragment specifying a 'controller' video switching
   policy where video switching takes place immediately:

    <video-switch type="controller" interval="0"/>

5.2.1.4.3.1.  Priority assignment

   In cases where the conference audio and
   announcement can be heard by video switching policy does not explicitly
   determine the conference participant.  This is
   sometimes referred to as a whisper announcement.  An alternative region to which a
   whisper announcement participant is to have assigned, the announcement pre-empt
   following priority assignment mechanism applies:

   1.  Each participant has an (positive integer) priority value: the
   conference media.

   Another common case is
       lower the call centre coaching scenario where a
   supervisor can listen to value, the conversation between an agent and a
   customer, and provide hints to higher the agent, which are not heard priority.  The priority value is
       determined by the
   customer.

   Both <priority> child element (Section 5.2.2.5.4) of these cases can be solved by having
       <stream>.  If not explicitly specified, the controlling AS create
   one or more conferences for audio mixing and to join and unjoin the
   media streams as required.  A better solution default priority
       value is 100.

   2.  The MS uses priority values to have the media
   server automatically mix media streams that are requested to be
   joined assign participants to a common input when only regions in
       the simple summing video layout which remain unfilled after application of audio
   signals as described above is required.  This is the case for both
   the use cases presented above.

   Automatically mixing streams has several benefits.  Conceptually, it
   is straight forward and simple, requiring no indirect requests on the
   part
       video switching policy.  The MS MUST dedicate larger and/or more
       prominent portions of the controlling AS.  This increases transport efficiency and
   reduces the coordination complexity and layout to participants with higher
       priority values first (e.g. first all participants with priority
       1, then those with 2, 3, etc).

   3.  The policy for displaying participants with the latency of same priority is
       implementation-specific.

   The MS applies this priority policy each time the overall
   operation.  Therefore, it video layout is
   changed or updated.  It is RECOMMENDED that the MS does not move a media server be able
   participant from one region to automatically mix at least two audio streams where only another unless required by the simple
   summing of signals video
   switching policy when an active video layout is required.

   When a media server receives a <join> request, it MUST automatically
   mix all of the media streams included in updated.

   This model allows the request with any streams
   already joined MS to one of the entities identified in apply default video layouts after
   applying the request, or
   it MUST fail the request and MUST NOT join any of the streams.  A
   controlling AS MUST use the <createconference> request for generic
   conferences where the complex mixing algorithm video switch policy.  For example, region 2 is required.

   Specifications which extend this package
   statically assigned to handle additional media
   types such as text or video, MUST define the semantics of Bob, so the join
   operation when multiple streams are requested to be joined priority mechanism only applies to a
   single input, such as that for a connection with a single RTP session
   per media type.

5.2.2.2.  <join>
   regions 1, 3, 4, etc.

5.2.1.4.4.  <subscribe>

   The <join> <subscribe> element is sent to the MS to request creation one or more
   media streams either between a connection and a conference, between
   connections, or between conferences.  The two entities container for specifying conference
   notification events to join are
   specified by the attributes of <join>.

   Streams may be of any media type, and may be bi-directional or uni-
   directional.  A bi-directional stream is implicitly composed which a controlling entity subscribes.
   Notifications of two
   uni-directional streams that can be manipulated independently.  The
   streams to be established conference events are specified by child <stream> elements delivered using the <event>
   element (see Section 5.2.2.5). 5.2.4).

   The <join> <subscribe> element has no attributes, but has the following attributes:

   id1:  an identifier for either a connection or a conference.  The
      identifier MUST conform
   child element:

   <active-talkers-sub>:  subscription to the syntax defined in Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework] active talker events
      (Section 5.2.1.4.4.1).  The attribute element is
      mandatory.

   id2:  an identifier for either a connection or a conference. optional.

   The
      identifier MUST conform to the syntax defined in Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is
      mandatory.

   Note: Section 17.1 of [I-D.ietf-mediactrl-sip-control-framework]
   defines the semantics for MS SHOULD support a conference identifier but not its syntax.
   Media server implementations need to distinguish between conferences
   and connections based upon the values of <active-talkers-sub> subscription.  It MAY
   support other event subscriptions.  If the "id1" and "id2"
   attributes. MS does not support a
   requested subscription, it MUST send a <response> with a 422 status
   code.

5.2.1.4.4.1.  <active-talkers-sub>

   The <join> <active-talkers-sub> element has the following child element (0 or more):

   <stream>:   an element that both identifies the media streams to join
      and defines attributes:

   interval:  the way minimum amount of time (in seconds) that they are to must elapse
      before further active talker events can be joined generated.  A valid
      value is a non-negative integer (see Section 5.2.2.5). 5.7.2).  A value of 0
      suppresses further notifications.  The element attribute is optional.

   If no <stream> elements are specified, then the  The
      default value is to join
   all streams between the entities according to the media configuration
   of 3 (seconds).

   The <active-talker-sub> element has no child elements.

   Active talker notifications are delivered in the connection or conference.

   One or more <stream> elements may be specified so that individual <active-talker-
   notify> element (Section 5.2.4.1).

5.2.2.  Joining Elements

5.2.2.1.  Joining Model

   The <join> operation creates a media streams can be controlled independently.  For example, if stream between a connection supports both audio and video streams,
   a <stream> element
   could be used to indicate that only conference, between connections, or between conferences.  This sub-
   section describes the audio stream is used in
   receive mode.  In cases where there are multiple media streams model of conferences and connections and
   specifies the
   same type behavior for a connection or conference, it is RECOMMENDED join requests to targets that the
   configuration is explicitly specified using <stream> elements.

   It is already have
   an error if a <stream> element is in conflict with (a) another
   <stream> element, (b) with specified connection or associated media stream.

   Conferences support multiple inputs and have resources to mix them
   together.  A media server conference in essence is a mixer that
   combines media
   capabilities, (c) with streams.  A simple audio mix simply sums its input
   audio signals to create a SDP label value single common output.  Conferences however
   use a more complex algorithm so that participants do not hear
   themselves as part of the connection-id
   (see Section 17.1 of [I-D.ietf-mediactrl-sip-control-framework]) or
   (d) if the media stream configuration is not supported by the MS.

   If the MS is unable to execute the join as specified in <stream>
   elements, the MS MUST report mix.  That algorithm, sometimes called an error (424) and MUST NOT join the
   entities.

   If
   n-minus mix, subtracts each participants input signal from the MS is unable to join an entity summed
   input signals, creating a unique output for each contributing
   participant.  Each <join> operation to a conference because it is
   full, then the MS MUST report an error (421).

   If the specified entities are already joined, then the MS MUST report
   an error (425).

   If the MS does not support joining two specified connections
   together, the MS MUST report an error (422).

   If uses one of the MS does not support joining two specified
   conferences
   together, the MS MUST report an error (423).

   If the MS is unable available inputs and/or outputs, to join the specified entities for any other
   reason, the MS MUST report an error (420).

   When the MS has finished processing a <join> request, it MUST reply
   with an <response> element (Section 5.2.3).

   [Editors Note: MIXER-008.  Should the draft allow multiple joins maximum number of
   supported participants.

   A connection is the same user to the same conference? termination of a (maybe silly) use case RTP session(s) on a media
   server.  It has a single input and output for
   this might be having each media session
   established by its SIP dialog.  The output of a user's video appear in 2 connection may feed
   several different regions inputs such as both a conference mix and a
   recording of
   the same conference.  With the current specification an "already
   joined" 425 error would be generated, considering that the same
   connection/conference can only be attached once participants audio.

   Joining two connections which are are not joined to each other.
   (Lorenzo) ]

   [Editors Note: MIXER-009.  The package isn't clear on anything else
   simply creates a media stream from the behavior outputs(s) of
   connectionid with a label part (i.e. from~to~label) permitted in
   Section 17.1 one connection
   to the corresponding inputs(s) of the Control Framework.  Connection identity: how other connection.  It is
   from1~to1 related to from1~to1~label1 related not
   necessary to one another?  If
   from1~to1 is unjoined, then is from1~to1~label1 also unjoined?  Some
   possible approaches: (a) remove connectionids with label part combine media from
   the Control Framework? (like multiple sources in this package, other packages can use case.  There
   are however several common scenarios where combining media from
   several sources to create a
   <stream> element single input to control the behavior). (b) explicitly specify
   this package does not support the label part of connection (or make a
   'special' feature in connection is needed.

   In the Control Framework.  Or (c) clarify usage in
   Control Framework and this package.  (Lorenzo) ]
   For example, first case, a request to join two connection together:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join id1="connnection1" id2="connection2"/>
   </mscmixer>

   and the response if the MS doesn't support joining may be receiving media streams
   between connections:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="422" reason="mixing connections not supported"/>
   </mscmixer>

5.2.2.3.  <modifyjoin>

   The <modifyjoin> element from one
   source, for example a conference, and it is sent necessary to the MS play an
   announcement to request changes in the
   configuration of media stream(s) that were previously established
   between a connection so that both the conference audio and a conference, between two connections, or
   between two conferences.

   The <modifyjoin> element has
   announcement can be heard by the following attributes:

   id1:  an identifier for either conference participant.  This is
   sometimes referred to as a connection or whisper announcement.  An alternative to a conference.  The
      identifier MUST conform
   whisper announcement is to have the syntax defined in Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework] The attribute announcement pre-empt the
   conference media.

   Another common case is
      mandatory.

   id2:  an identifier for either the call center coaching scenario where a connection or
   supervisor can listen to the conversation between an agent and a conference.  The
      identifier MUST conform
   customer, and provide hints to the syntax defined in Section 17.1 agent, which are not heard by the
   customer.

   Both of
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is
      mandatory.

   The <modifyjoin> element has these cases can be solved by having the following child elements (1 controlling AS create
   one or
   more):

   <stream>:   an element that both identifies more conferences for audio mixing and to join and unjoin the
   media streams as required.  A better solution is to
      modify and defines have the way media
   server automatically mix media streams that each stream should now are requested to be
      configured (see Section 5.2.2.5).

   The MS MUST support <modifyjoin> for any stream that was established
   using <join> or modified by
   joined to a previous <modifyjoin> operation.

   The media server MUST configure common input when only the simple summing of audio
   signals as described above is required.  This is the case for both
   the use cases presented above.

   Automatically mixing streams has several benefits.  Conceptually, it
   is straight forward and simple, requiring no indirect requests on the
   part of the controlling AS.  This increases transport efficiency and
   reduces the coordination complexity and the latency of the overall
   operation.  Therefore, it is RECOMMENDED that are included within
   <modifyjoin> a media server be able
   to that stated by automatically mix at least two audio streams where only the child elements.  It simple
   summing of signals is required.

   When a media server receives a <join> request, it MUST NOT
   change the configuration automatically
   mix all of any the media streams not included as child
   elements.

   If in the MS is unable request with any streams
   already joined to modify one of the join as specified entities identified in <stream>
   elements, the MS request, or
   it MUST report an error (424) fail the request and MUST NOT modify the join between the entities.

   If the specified entities are not already joined, then any of the MS streams.  A
   controlling AS MUST
   report an error (426).

   If use the MS <createconference> request for generic
   conferences where the complex mixing algorithm is unable required.

   Specifications which extend this package to modify handle additional media
   types such as text or video, MUST define the join between semantics of the specified entities join
   operation when multiple streams are requested to be joined to a
   single input, such as that for any other reason, the MS MUST report an error (420).

   When an MS has finished processing a <modifyjoin> request, it MUST
   reply connection with an appropriate <response> element (Section 5.2.3).

5.2.2.4.  <unjoin> a single RTP session
   per media type.

5.2.2.2.  <join>

   The <unjoin> <join> element is sent to the MS to request removal of
   previously established creation one or more
   media stream(s) from streams either between a connection and a conference, between two
   connections, or between two conferences.  The <unjoin> two entities to join are
   specified by the attributes of <join>.

   Streams may be of any media type, and may be bi-directional or uni-
   directional.  A bi-directional stream is implicitly composed of two
   uni-directional streams that can be manipulated independently.  The
   streams to be established are specified by child <stream> elements
   (see Section 5.2.2.5).

   The <join> element has the following attributes:

   id1:  an identifier for either a connection or a conference.  The
      identifier MUST conform to the syntax defined in Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is
      mandatory.

   id2:  an identifier for either a connection or a conference.  The
      identifier MUST conform to the syntax defined in Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is
      mandatory.

   Note: Section 17.1 of [I-D.ietf-mediactrl-sip-control-framework]
   defines the semantics for a conference identifier but not its syntax.
   Media server implementations need to distinguish between conferences
   and connections based upon the values of the "id1" and "id2"
   attributes.

   The <unjoin> <join> element has the following child element (0 or more
   occurrences): more):

   <stream>:   an element that both identifies the media stream(s) streams to remove join
      and defines the way that they are to be joined (see
      Section 5.2.2.5).  The element is optional.  When not
      present, all currently established streams between "id1" and "id2"
      are removed.

   The MS MUST support <unjoin> for any stream that was established
   using <join> or modified using <modifyjoin> and have not already been
   removed.

   If the MS is unable to terminate any join as specified in no <stream>
   elements, the MS MUST report an error (424) and MUST NOT terminate
   the join between the entities.

   If the specified entities elements are not already joined, specified, then the MS MUST
   report an error (426).

   If the MS default is unable to terminate the join
   all streams between the specified entities for any other reason, according to the MS MUST report an error (420).

   When an MS has successfully processed a <unjoin> request, it MUST
   reply with a successful <response> element (Section 5.2.3).

5.2.2.5.  <stream>

   <join>, <modifyjoin> and <unjoin> require the identification and
   manipulations of media streams.  Media streams represent the flow configuration
   of the connection or conference.

   One or more <stream> elements may be specified so that individual
   media between streams can be controlled independently.  For example, if a participant
   connection supports both audio and video streams, a conference, between two
   connections, or between two conferences.  The <stream> element is
   could be used (as a child to <join>, <modifyjoin> and <unjoin) to identify indicate that only the audio stream is used in
   receive mode.  In cases where there are multiple media stream(s) for the request and to specify the configuration streams of the media stream.

   The <stream> element has the following attributes:

   media:  a string indicating the
   same type of media associated with the
      stream.  It for a connection or conference, it is strongly recommended RECOMMENDED that the following values are
      used for common types of media: "audio" for audio media, and
      "video" for video media.  The attribute
   configuration is mandatory.

   label: explicitly specified using <stream> elements.

   It is an error if a string indicating the SDP label associated <stream> element is in conflict with a (a) another
   <stream> element, (b) with specified connection or conference media
      stream ([RFC4574]).  The attribute is optional.

   direction:
   capabilities, (c) with a string indicating SDP label value as part of the allowed media flow connection-id
   (see Section 17.1 of [I-D.ietf-mediactrl-sip-control-framework]) or
   (d) if the media stream
      relative to configuration is not supported by the value of MS.

   If the "id1" attribute of MS is unable to execute the parent
      element.  Defined values are: "sendrecv" (media can be sent and
      received), "sendonly" (media can only be sent), "recvonly" (media
      can only be received) and "inactive" (stream is not to be used).
      The default value is "sendrecv".  The attribute is optional.

   [Editors Note: MIXER-010. "inactive" value: clarify that this value
   means the stream is not established.  Alternative: it is established
   but no send/receive media flow.  This has an impact when a
   <modifyjoin> makes an established stream inactive (removed?), or a
   previously inactive stream is made active join as specified in sendrecv direction, for
   example. ].

   The <stream> element has
   elements, the following sequence of child elements:

   <volume>: MS MUST report an element to configure error (407) and MUST NOT join the volume or gain of
   entities.

   If the media
      stream (Section 5.2.2.5.1).  The element MS is optional.

   <clamp>:  an element unable to configure filtering and removal of tones from
      a media stream (Section 5.2.2.5.2).  The element is optional.

   <region>: join an element entity to configure region within a video layout where
      the media stream is displayed (Section 5.2.2.5.3).  The element conference because it is
      optional.

   <priority>:
   full, then the MS MUST report an element to configure priority associated with error (410).

   If the
      stream in specified entities are already joined, then the media mix (Section 5.2.2.5.4).  The element is
      optional. MS MUST report
   an error (408).

   If the "media" attribute MS does not have the value of "audio", then support joining two specified connections
   together, the MS MUST ignored <volume> and <clamp> elements. report an error (426).

   If the "media" attribute MS does not have the value of "video", then support joining two specified conferences
   together, the MS MUST ignored <region> element.

5.2.2.5.1.  <volume>

   The <volume> element report an error (427).

   If the MS is used unable to configure join the volume of specified entities for any other
   reason, the MS MUST report an audio
   media stream.  It may be set to error (411).

   When the MS has finished processing a specific gain amount, <join> request, it MUST reply
   with an <response> element (Section 5.2.3).

   For example, a request to
   automatically adjust join two connection together:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join id1="connnection1" id2="connection2"/>
   </mscmixer>

   and the gain response if the MS doesn't support joining media streams
   between connections:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="426" reason="mixing connections not supported"/>
   </mscmixer>

5.2.2.3.  <modifyjoin>

   The <modifyjoin> element is sent to a desired target level, or the MS to mute request changes in the volume.
   configuration of media stream(s) that were previously established
   between a connection and a conference, between two connections, or
   between two conferences.

   The <volume> <modifyjoin> element has no child elements but has the following attributes:

   controltype:  a string indicating the type of volume control to use

   id1:  an identifier for the stream.  Defined values are: "automatic" (the volume will
      be adjusted automatically to the level specified by the "value"
      attribute), "setgain" (use the value of the "value" attribute as either a
      specific gain measured in dB to apply), "setstate" (set the state
      of the stream to "mute" connection or "unmute" as specified by a conference.  The
      identifier MUST conform to the value syntax defined in Section 17.1 of
      the "value" attribute).
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is
      mandatory.

   value:

   id2:  an identifier for either a string specifying the amount connection or state for a conference.  The
      identifier MUST conform to the volume
      control syntax defined by the value in Section 17.1 of the "controltype" attribute.
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is optional.  There is no default value.

5.2.2.5.2.  <clamp>
      mandatory.

   The <clamp> <modifyjoin> element is used to configure whether tones should be
   filtered and removed from a media stream.

   The <clamp> element has no child elements but has the following
   attributes:

   tones:  A list of child elements (1 or
   more):

   <stream>:   an element that both identifies the tones media streams to remove.
      modify and defines the way that each stream should now be
      configured (see Section 5.2.2.5).

   The attribute is manadatory.

5.2.2.5.3.  <region> MS MUST support <modifyjoin> for any stream that was established
   using <join>.

   The <region> element is used to explicitly specify media server MUST configure the region streams that are included within
   a video layout where
   <modifyjoin> to that stated by the media stream child elements.  It MUST NOT
   change the configuration of any streams not included as child
   elements.

   If the MS is displayed.

   The <region> element has no attributes unable to modify the join as specified in <stream>
   elements, the MS MUST report an error (407) and its content model
   specifies MUST NOT modify the name of
   join between the region layout. entities.

   If the region name is invalid, specified entities are not already joined, then the MS MUST
   report an 428 error
   in (408).

   If the response MS is unable to modify the request element containing join between the <region>
   element.

5.2.2.5.4.  <priority> specified entities
   for any other reason, the MS MUST report an error (411).

   When an MS has finished processing a <modifyjoin> request, it MUST
   reply with an appropriate <response> element (Section 5.2.3).

5.2.2.4.  <unjoin>

   The <priority> <unjoin> element is used sent to explicitly specify the priority of
   a participant.  The MS uses this priority to determine where the request removal of
   previously established media stream is displayed within stream(s) from between a video layout
   (Section 5.2.1.4.3.1). connection and
   a conference, between two connections, or between two conferences.

   The <priority> <unjoin> element has no attributes and its content model
   specifies a positive integer (see Section 5.7.3).  The lower the
   value, the higher the priority.

5.2.3.  <response>

   Reponses to requests are indicated by a <response> element.

   The <response> element has following attributes:

   status:  numeric code indicating

   id1:  an identifier for either a connection or a conference.  The
      identifier MUST conform to the response status.  Valid valies
      are syntax defined in Section 5.6. 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is
      mandatory.

   reason:  string specifying a reason

   id2:  an identifier for the response status.  The
      attribute is optional.

   conferenceid:  string identifying the conference (see Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework]). either a connection or a conference.  The attribute is
      optional.

   connectionid:  string identifying
      identifier MUST conform to the SIP dialog connection (see syntax defined in Section 17.1 of [I-D.ietf-mediactrl-sip-control-framework]).
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is optional.

   For example, a response when a conference was created successfully:

   <response code="200">
    <reason>Success</reason>
   </response>

   The response if conference creation failed due to the requested
   conference id already existing:

   <response code="403">
    <reason>Conf already exists</reason>
   </response>

5.2.4.  <event>

   When a mixer generates a notification event, the MS sends the event
   using an <event> element.
      mandatory.

   The <event> <unjoin> element has no attributes, but has the following sequence
   of child elements element (0 or more instances of each child):

   <active-talkers-notify>  specifies
   occurrences):

   <stream>:   an active talkers notification
      (Section 5.2.4.1).

   <unjoin-notify>  notifies that a connection or conference has been
      completely unjoined (Section 5.2.4.2).

   <conferenceexit>  notifies that a conference has exited
      (Section 5.2.4.3).

5.2.4.1.  <active-talkers-notify>

   The <active-talkers-notify> element describes zero or more speakers that have been active in a conference during identifies the specified interval media stream(s) to remove
      (see Section 5.2.1.4.4.1). 5.2.2.5).  The <active-talkers-notify> element has the following attributes:

   conferenceid:  string indicating the name of the conference from
      which the event orginated.  This attribute is mandatory.

   The <active-talkers-notify> element has the following sequence of
   child elements (0 or more occurences):

   <active-talker>  element describing an active talker
      (Section 5.2.4.1.1).

5.2.4.1.1.  <active-talker> optional.  When not
      present, all currently established streams between "id1" and "id2"
      are removed.

   The <active-talker> element describes MS MUST support <unjoin> for any stream that was established
   using <join> and has not already been removed by a previous <unjoin>
   on the same stream.

   If the MS is unable to terminate any join as specified in <stream>
   elements, the MS MUST report an active talker, associated error (407) and MUST NOT terminate
   the join between the entities.

   If the specified entities are not already joined, then the MS MUST
   report an error (409).

   If the MS is unable to terminate the join between the specified
   entities for any other reason, the MS MUST report an error (411).

   When an MS has successfully processed a <unjoin> request, it MUST
   reply with either a successful <response> element (Section 5.2.3).

5.2.2.5.  <stream>

   <join>, <modifyjoin> and <unjoin> require the identification and
   manipulations of media streams.  Media streams represent the flow of
   media between a participant connection and a conference, between two
   connections, or conference participant in between two conferences.  The <stream> element is
   used (as a conference. child to <join>, <modifyjoin> and <unjoin) to identify the
   media stream(s) for the request and to specify the configuration of
   the media stream.

   The <active-talker> <stream> element has the following attributes:

   connectionid:

   media:  a string indicating the connectionid type of media associated with the active
      talker.  This attribute is optional.  There
      stream.  It is no default value.

   conferenceid:  string indicating strongly recommended that the conferenceid following values are
      used for common types of the active
      talker.  This attribute is optional.  There is no default value.

   It is an error (429) if both the connectionid media: "audio" for audio media, and conferenceid
   attributes are specified.

   The <active-talker> element has no child elements.

5.2.4.2.  <unjoin-notify>

   The <unjoin-notify> element describes a notification event where a
   connection and/or conference have been completely unjoined.
      "video" for video media.  The <unjoin-notify> element has the following attributes:

   status: attribute is mandatory.

   label:  a status code string indicating why the unjoin occurred.  A valid
      value SDP label associated with a media
      stream ([RFC4574]).  The attribute is optional.

   direction:  a non-negative integer (see Section 5.7.2).  A value of 1
      indicates that string indicating the join has been terminated by a <unjoin> request.
      A value allowed media flow of 2 indicates that the unjoin occured because stream
      relative to the a
      connection or conference has terminated.  A value of 3 indicates
      the join terminated due to an internal error.  Any other value
      indicates an error defined by the MS.  The "id1" attribute is mandatory.

   reason:  a textual description providing a reason for of the status
      code; e.g. details about an error.  A valid parent
      element.  Defined values are: "sendrecv" (media can be sent and
      received), "sendonly" (media can only be sent), "recvonly" (media
      can only be received) and "inactive" (stream established but no
      media flow).  The default value is a string (see
      Section 5.7.4). "sendrecv".  The attribute is
      optional.  There is no default
      value.

   id1:  an identifier for either a connection or a conference.

   The
      identifier MUST conform <stream> element has the following sequence of child elements:

   <volume>:  an element (Section 5.2.2.5.1) to configure the syntax defined in Section 17.1 volume or
      gain of
      [I-D.ietf-mediactrl-sip-control-framework] the media stream.  The attribute element is
      mandatory.

   id2: optional.

   <clamp>:  an identifier for either element (Section 5.2.2.5.2) to configure filtering and
      removal of tones from the media stream.  The element is optional.

   <region>:  an element (Section 5.2.2.5.3) to configure a connection or region
      within a conference. video layout where the media stream is displayed.  The
      identifier MUST conform
      element is optional.

   <priority>:  an element (Section 5.2.2.5.4) to configure priority
      associated with the syntax defined stream in Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is
      mandatory. the media mix.  The <unjoin-notify> element has no is
      optional.

   In each child element, the media stream affected is from the value of
   the "id1" attribute of the parent element.

   If the "media" attribute does not have the value of "audio", then the
   MS MUST ignored <volume> and <clamp> elements.

5.2.4.3.  <conferenceexit>

   If the "media" attribute does not have the value of "video", then the
   MS MUST ignored <region> element.

5.2.2.5.1.  <volume>

   The <conferenceexit> <volume> element indicates that a conference has exited
   because it has been terminated or because a error occurred (for
   example, a hardware error in is used to configure the conference mixing unit).  This event
   MUST volume of an audio
   media stream.  It may be sent by set to a specific gain amount, to
   automatically adjust the MS whenever gain to a successfully created conference
   exits. desired target level, or to mute
   the volume.

   The <conferenceexit> <volume> element has no child elements but has the following
   attributes:

   conferenceid:

   controltype:  a string indicating the name type of volume control to use
      for the conference.  This
      attribute is mandatory.

   status:  a status code indicating why stream.  Defined values are: "automatic" (the volume will
      be adjusted automatically to the level specified by the "value"
      attribute), "setgain" (use the conference exited.  A valid
      value is a non-negative integer (see Section 5.7.2).  A value of 1
      indicates that the conference has been terminated by "value" attribute as a
      <destroyconference> request.  Any other value indicates an error
      defined
      specific gain measured in dB to apply), "setstate" (set the state
      of the stream to "mute" or "unmute" as specified by the MS. value of
      the "value" attribute).  The attribute is mandatory.

   reason:  a textual description providing

   value:  a reason string specifying the amount or state for the status
      code; e.g. details about an error.  A valid volume
      control defined by the value is a string (see
      Section 5.7.4). of the "controltype" attribute.  The
      attribute is optional.  There is no default value.

5.2.2.5.2.  <clamp>

   The <conferenceexit> <clamp> element is used to configure whether tones should be
   filtered and removed from a media stream.

   The <clamp> element has no child elements.

   When a MS sends a <conferenceexit> event, elements but has the identifier for following
   attributes:

   tones:  A space-separated list of the
   conference (conferenceid attribute) tones to remove.  The attribute
      is no longer valid on mandatory.

5.2.2.5.3.  <region>

   The <region> element is used to explicitly specify the MS and
   can be reused for another conference.

   For example, region within
   a video layout where the following notification event would be sent from media stream is displayed.

   The <region> element has no attributes and its content model
   specifies the
   MS when name of the conference with identifier "conference99" exits due region layout.

5.2.2.5.4.  <priority>

   The <priority> element is used to explicitly specify the priority of
   a
   successful <destroyconference/>:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <event>
     <conferenceexit conferenceid="conference99"
        status="1"/>
    </event>
   </mscmixer>

5.3.  Audit Elements participant.  The audit elements defined in this section allow the MS uses this priority to be audited
   for package capabilities as well as mixers managed by determine where the package.
   Auditing is particularly important for two use cases.  First, it
   enables discovery of package capabilities supported on an MS before
   an AS creates
   media stream is displayed within a conference mixer or joins connections and
   conferences. video layout
   (Section 5.2.1.4.3.1).

   The AS may then use this informaton to create request
   elements using supported capabilities and, in the case of codecs, to
   negotiate an appropriate SDP for a user agent's connection.  Second,
   auditing enables discovery of the existence and status of mixers
   currently managed by the package on the MS.  This allows one AS to
   take over management of mixers when the AS which initiated the mixers
   fails or is <priority> element has no longer available.

5.3.1.  <audit> attributes and its content model
   specifies a positive integer (see Section 5.7.3).  The <audit> request element is sent to lower the MS to request information
   about
   value, the capabilities of, and mixers currently managed with, this
   control package.  Capabilities include supported conference codecs
   and video layouts.  Mixer information includes higher the status of managed
   mixers as well as codecs. priority.

5.2.3.  <response>

   Responses to requests are indicated by a <response> element.

   The <audit> <response> element has the following attributes:

   capabilities:  indicates whether package capabilities

   status:  numeric code indicating the response status.  Valid values
      are to be
      audited.  A valid value defined in Section 5.6.  The attribute is mandatory.

   reason:  string specifying a boolean reason for the response status.  The
      attribute is optional.

   conferenceid:  string identifying the conference (see Section 5.7.1).  A value
      of true indicates that capability information is to be reported.
      A value 17.1 of false indicates that capability information is not to
      be reported.
      [I-D.ietf-mediactrl-sip-control-framework]).  The attribute is
      optional.  The default value is
      true.

   mixers:  indicates whether mixers currently managed by

   connectionid:  string identifying the package
      are to be audited.  A valid value is a boolean SIP dialog connection (see
      Section 5.7.1).  A value of true indicates that mixer information
      is to be reported.  A value 17.1 of false indicates that mixer
      information is not to be reported. [I-D.ietf-mediactrl-sip-control-framework]).  The
      attribute is optional.
      The default value is true.

   conferenceid:  string identifying

   For example, a response when a specific conference mixer to
      audit.  It is an error (404) was created successfully:

   <response code="200">
    <reason>Success</reason>
   </response>

   The response if the conferenceid attribute is
      specified and the conference identifier is not valid.  The
      attribute is optional.  There is no default value.

   If the mixers attribute has the value true and conferenceid attribute
   is specified, then only audit information about creation failed due to the specified requested
   conference id already existing:

   <response code="403">
    <reason>Conf already exists</reason>
   </response>

5.2.4.  <event>

   When a mixer is reported.  If generates a notification event, the mixers attribute has MS sends the value
   false, then no mixer audit information is reported even if a
   conferenceid attribute is specified. event
   using an <event> element.

   The <audit> <event> element has no child elements.

   When attributes, but has the MS receives a <audit> request, it MUST reply with a
   <auditresponse> element following sequence
   of child elements (0 or more instances of each child):

   <active-talkers-notify>  specifies an active talkers notification
      (Section 5.3.2).  If the request is
   successful, <auditresponse> contains (depending on atrribute values) 5.2.4.1).

   <unjoin-notify>  notifies that a <capabilities> element connection or conference has been
      completely unjoined (Section 5.3.2.1) reporting package
   capabilities and 5.2.4.2).

   <conferenceexit>  notifies that a <mixers> element conference has exited
      (Section 5.3.2.2) reporting
   managed mixer information.

   For example, a request to audit capabilities and mixers managed by
   the package:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <audit/>
   </mscmixer>

   In this example, only capabilities are to be audited:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <audit mixers="false"/>
   </mscmixer>

   With this example, only a specific conference mixer is to be audited:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <audit capabilities="false" conferenceid="conf4"/>
   </mscmixer>

5.3.2.  <auditresponse> 5.2.4.3).

5.2.4.1.  <active-talkers-notify>

   The <auditresponse> <active-talkers-notify> element describes zero or more speakers
   that have been active in a response to a <audit>
   request. conference during the specified interval
   (see Section 5.2.1.4.4.1).

   The <auditresponse> <active-talkers-notify> element has the following attributes:

   status:  numeric code

   conferenceid:  string indicating the audit response status.  The
      attribute is mandatory.  Valid values are defined in Section 5.6.

   reason:  string specifying a reason for name of the status.  The conference from
      which the event originated.  This attribute is
      optional. mandatory.

   The <auditresponse> <active-talkers-notify> element has the following sequence of
   child
   elements:

   <capabilities> elements (0 or more occurrence's):

   <active-talker>  element (Section 5.3.2.1) describing capabilities of
      the package.  The element is optional.

   <mixers>  element an active talker
      (Section 5.3.2.2) describing information about
      managed mixers. 5.2.4.1.1).

5.2.4.1.1.  <active-talker>

   The <active-talker> element is optional.

   For example, describes an active talker, associated
   with either a successful response to connection or conference participant in a <audit> request requesting
   capabilities and mixer information:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <auditresponse status="200">
     <capabilities>
      <codecs>
       <codec>
        <subtype>H263</subtype>
       </codec>
       <codec>
        <subtype>H264</subtype>
       </codec>
       <codec>
        <subtype>PCMU</subtype>
       </codec>
       <codec>
        <subtype>PCMA</subtype>
       </codec>
      </codecs>
     </capabilities>
     <mixers>
      <conferenceaudit conferenceid="conf1">
       <codecs>
        <codec>
         <subtype>PCMA</subtype>
        </codec>
       </codecs>
       <participants>
        <participant id="connection1"/>
       </participants>
      </conferenceaudit>
      <joinaudit id1="connection1" id2="conf1"/>
      <joinaudit id1="connection2" id2="connection3"/>
      <joinaudit id1="connection4" id2="connection5"/>
     </mixers>
    </auditresponse>
   </mscmixer>

5.3.2.1.  <capabilities>

   The <capabilities> element provides audit information about package
   capabilities.

   The <capabilities> element has no attributes. conference.

   The <capabilities> <active-talker> element has the following sequence attributes:

   connectionid:  string indicating the connectionid of child
   elements:

   <codecs>:  element (Section 5.4) describing codecs available to the
      package.  The element active
      talker.  This attribute is optional.  There is mandatory.

   For example, a fragment describing capabilities:

     <capabilities>
      <codecs>
       <codec>
        <subtype>H263</subtype>
       </codec>
       <codec>
        <subtype>H264</subtype>
       </codec>
       <codec>
        <subtype>PCMU</subtype>
       </codec>
       <codec>
        <subtype>PCMA</subtype>
       </codec>
      </codecs>
     </capabilities>

5.3.2.2.  <mixers>

   The <mixers> element provides audit information about mixers.

   The <mixers> element has no attributes. default value.

   conferenceid:  string indicating the conferenceid of the active
      talker.  This attribute is optional.  There is no default value.

   It is an error (400) if both the connectionid and conferenceid
   attributes are specified.

   The <mixers> <active-talker> element has the following sequence of no child elements (0
   or more occurences, any order):

   <conferenceaudit>:  audit information for a conference mixer
      (Section 5.3.2.2.1). elements.

5.2.4.2.  <unjoin-notify>

   The <unjoin-notify> element is optional.

   <joinaudit>:  audit information for describes a join mixer (Section 5.3.2.2.2).
      The element is optional.

5.3.2.2.1.  <conferenceaudit> notification event where a
   connection and/or conference have been completely unjoined.

   The <conferenceaudit> <unjoin-notify> element has the following attributes:

   conferenceid:  string identifying

   status:  a status code indicating why the conference unjoin occurred.  A valid
      value is a non-negative integer (see Section 17.1 5.7.2).  A value of
      [I-D.ietf-mediactrl-sip-control-framework]).  The attribute is
      mandatory.

   The <conferenceaudit> element has 1
      indicates that the following sequence join has been terminated by a <unjoin> request.
      A value of child
   elements:

   <codecs>  element describing codecs used in 2 indicates that the conference.  See
      Section 5.4.  The element is optional.

   <participants>  element listing connections unjoin occurred because the a
      connection or conferences joined conference has terminated.  A value of 3 indicates
      the join terminated due to an internal error.  Any other value
      indicates an error defined by the conference.  See Section 5.3.2.2.1.1. MS.  The element attribute is
      optional.

   <video-layout>  element describing the active video layout for the
      conference.  See Section 5.2.1.4.2.1.  The element is optional.

   For example, a fragment describing a conference which has been
   created but has no participants:

   <conferenceaudit conferenceid="conference1"/>

   And mandatory.

   reason:  a fragment when the same conference has three participants (two
   connections and another conference) joined to it:

   <conferenceaudit conferenceid="conference1">
    <codecs>
     <codec>
      <subtype>PCMU</subtype>
     </codec>
    </codecs>
    <participants>
      <participant id="connection1"/>
      <participant id="connection2"/>
      <participant id="conference2"/>
    </participants>
   </conferenceaudit>

5.3.2.2.1.1.  <participants>

   The <participants> element is textual description providing a container reason for <participant> elements
   (Section 5.3.2.2.1.1.1).

   The <participants> element has no attributes, but the following child
   elements are defined (0 or more):

   <participant>:  specifies a participant (Section 5.3.2.2.1.1.1).

5.3.2.2.1.1.1.  <participant>

   The <participant> element describes a participant.

   The <participant> element has the following attributes:

   id: status
      code; e.g. details about an identifier for either a connection or error.  A valid value is a conference.  The
      identifier MUST conform to the syntax defined in string (see
      Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework]. 5.7.4).  The attribute is
      mandatory.

   The <participant> element has optional.  There is no children.

5.3.2.2.2.  <joinaudit>

   The <joinaudit> element has the following attributes: default
      value.

   id1:  an identifier for either a connection or a conference.  The
      identifier MUST conform to the syntax defined in Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is
      mandatory.

   id2:  an identifier for either a connection or a conference.  The
      identifier MUST conform to the syntax defined in Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is
      mandatory.

   The <joinaudit> <unjoin-notify> element has no children.

   [Editors Note: MIXER-006.  Do we need to specify stream information
   associated with the join?]

   For example, a fragment describing an audit of two join mixers, one
   between connections and the second between conferences:

   <mixers>
    <joinaudit id1="connection1" id2="connection2"/>
    <joinaudit id1="conference1" id2="conference2"/>
   </mixers>

5.4.  <codecs> child elements.

5.2.4.3.  <conferenceexit>

   The <codecs> <conferenceexit> element is indicates that a container for one conference has exited
   because it has been terminated or more codec
   definitions.  Codec definitions are used by an AS to specify the
   codecs allowed for because a conference (e.g. when used as error occurred (for
   example, a child of
   <createconference> or <modifyconference).  Codec definitions are used
   by an MS to provide audit information about hardware error in the codecs supported conference mixing unit).  This event
   MUST be sent by
   an MS and used in specific conferences.

   The <codecs> element has no attributes.

   The <codecs> element has the following sequence of child elements (0
   or more occurences):

   <codec>:  defines a codec and optionally its policy(Section 5.4.1).
      The element is optional.

   For example, a fragment describing two codecs:

   <codecs>
     <codec>
      <subtype>PCMA</subtype>
     </codec>
     <codec>
       <subtype>H263</subtype>
     </codec>
   </codecs>

5.4.1.  <codec>

   The <codec> element describes MS whenever a codec.  The element is modeled on the
   <codec> element in the XCON successfully created conference information data model
   ([I-D.ietf-xcon-common-data-model]) and allows addition information
   (e.g. rate, speed, etc) to be specified.

   The <codecs> element has no attributes.
   exits.

   The <codecs> <conferenceexit> element has the following sequence of child elements:

   <subtype>:  element describing the codec's name.  The possible values
      of this element are the values of attributes:

   conferenceid:  string indicating the 'subtype' column name of the RTP
      Payload Format media types per [RFC4855] defined in IANA ([IANA]).
      The element conference.  This
      attribute is mandatory.

   <params>:  element (Section 5.5) describing additional information
      about

   status:  a status code indicating why the codec.  This package conference exited.  A valid
      value is agnostic to the names and values a non-negative integer (see Section 5.7.2).  A value of 1
      indicates that the codec parameters supported conference has been terminated by a
      <destroyconference> request.  Any other value indicates an implementation. error
      defined by the MS.  The
      element attribute is optional.

   For example, mandatory.

   reason:  a fragment with textual description providing a <codec> element describing reason for the H263
   codec:

   <codec>
    <subtype>H263</subtype>
   </codec>

5.5.  <params>

   The <params> element status
      code; e.g. details about an error.  A valid value is a container for <param> elements
   (Section 5.5.1). string (see
      Section 5.7.4).  The <params> attribute is optional.  There is no default
      value.

   The <conferenceexit> element has no attributes, but the following child
   elements are defined (0 or more):

   <param>:  specifies elements.

   When a parameter name and value (Section 5.5.1).

5.5.1.  <param>

   The <param> element describes MS sends a parameter name <conferenceexit> event, the identifier for the
   conference (conferenceid attribute) is no longer valid on the MS and value.

   The <param> element has
   can be reused for another conference.

   For example, the following attributes:

   name:  a string indicating notification event would be sent from the name of
   MS when the parameter.  The attribute
      is mandatory.

   type:  specifies conference with identifier "conference99" exits due to a type indicating how the inline value of
   successful <destroyconference/>:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <event>
     <conferenceexit conferenceid="conference99"
        status="1"/>
    </event>
   </mscmixer>

5.3.  Audit Elements

   The audit elements defined in this section allow the
      parameter is MS to be interpreted.  A valid value audited
   for package capabilities as well as mixers managed by the package.
   Auditing is particularly important for two use cases.  First, it
   enables discovery of package capabilities supported on an MS before
   an AS creates a MIME media
      type (see Section 5.7.6).  The attribute is optional.  The default
      value is "text/plain". conference mixer or joins connections and
   conferences.  The <param> element content model is AS may then use this information to create request
   elements using supported capabilities and, in the value case of the parameter.
   Note that a value which contains XML characters (e.g. "<") needs codecs, to
   be escaped following standard XML conventions.

5.6.  Response Status Codes

   The following status codes
   negotiate an appropriate SDP for mixer management reponses
   (Section 5.2.3) a user agent's connection.  Second,
   auditing enables discovery of the existence and audit responses Section 5.3.2) responses are
   defined.

   +-----------+-------------------------------------------------------+
   | code      | description                                           |
   +-----------+-------------------------------------------------------+
   | 200       | OK                                                    |
   |           |                                                       |
   | 403       | Conference already exists                             |
   |           |                                                       |
   | 404       | Conference does not exist                             |
   |           |                                                       |
   | 405       | Unable status of mixers
   currently managed by the package on the MS.  This allows one AS to configure audio mix                         |
   |           |                                                       |
   | 406       | Unable
   take over management of mixers when the AS which initiated the mixers
   fails or is no longer available.

5.3.1.  <audit>

   The <audit> request element is sent to create subscription                         |
   |           |                                                       |
   | 407       | Conference reservation failed                         |
   |           |                                                       |
   | 408       | Unable the MS to configure request information
   about the capabilities of, and mixers currently managed with, this
   control package.  Capabilities include supported conference codecs
   and video layouts                     |
   |           |                                                       |
   | 409       | Unable layouts.  Mixer information includes the status of managed
   mixers as well as codecs.

   The <audit> element has the following attributes:

   capabilities:  indicates whether package capabilities are to configure video switch                      |
   |           |                                                       |
   | 410       | Unable be
      audited.  A valid value is a boolean (see Section 5.7.1).  A value
      of true indicates that capability information is to configure codecs                            |
   | 420       | Unable be reported.
      A value of false indicates that capability information is not to join requested entities                     |
   |           |                                                       |
   | 421       | Unable to join - conference full                      |
   |           |                                                       |
   | 422       | Unable to join - mixing connections not supported     |
   |           |                                                       |
   | 423       | Unable to join - mixing conferences not supported     |
   |           |                                                       |
   | 424       | invalid joining stream configuration                  |
   |           |                                                       |
   | 425       | joining already joined                                |
   |           |                                                       |
   | 426       | joining entities not joined                           |
   |           |                                                       |
   | 427       | Unsupported foreign namespace attribute or element    |
   |           |                                                       |
   | 428       | Invalid region identifier                             |
   |           |                                                       |
   | 429       | Syntax constraint violation                           |
   |           |                                                       |
   | 450       | Unknown or unsupported element                        |
   |           |                                                       |
   | 451       | Element required                                      |
   |           |                                                       |
   | 452       | Unknown or unsupported attribute                      |
   |           |                                                       |
   | 453       | Attribute required                                    |
   +-----------+-------------------------------------------------------+

                      Table 1: response status codes

5.7.  Type Definitions

   This section defines types referenced in
      be reported.  The attribute definitions.

5.7.1.  Boolean is optional.  The default value space of boolean is
      true.

   mixers:  indicates whether mixers currently managed by the set {true, false}.

5.7.2.  Non-Negative Integer

   The package
      are to be audited.  A valid value space of non-negative integer is the infinite set
   {0,1,2,...}.

5.7.3.  Positive Integer

   The a boolean (see
      Section 5.7.1).  A value space of positive integer true indicates that mixer information
      is the infinite set {1,2,...}.

5.7.4.  String to be reported.  A value of false indicates that mixer
      information is not to be reported.  The attribute is optional.
      The default value is true.

   conferenceid:  string in identifying a specific conference mixer to
      audit.  It is an error (406) if the character encoding associated with conferenceid attribute is
      specified and the XML element.

5.7.5.  Time Designation

   A time designation consists of a non-negative real number followed by
   a time unit identifier. conference identifier is not valid.  The time unit identifiers are: "ms" (milliseconds) and "s" (seconds).

   Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s".

5.7.6.  MIME Media Type

   A string formated as a IANA MIME media type ([MIME.mediatypes]).

6.  Formal Syntax

   This section defines
      attribute is optional.  There is no default value.

   If the XML schema for mixers attribute has the Mixer Control Package.

   The schema defines datatypes, attributes, value true and conferenceid attribute
   is specified, then only audit information about the specified
   conference mixer elements in is reported.  If the
   urn:ietf:params:xml:ns:msc-mixer namespace.  In most elements mixers attribute has the
   order of child elements value
   false, then no mixer audit information is significant.  The schema reported even if a
   conferenceid attribute is extensible:
   elements allow attributes and child elements from other namespaces.
   Elements from outside this package's namespace can occur after
   elements defined in this package. specified.

   The schema is dependent upon <audit> element has no child elements.

   When the schema (framework.xsd) MS receives an <audit> request, it MUST reply with a
   <auditresponse> element (Section 5.3.2) which includes a mandatory
   attribute describing the status in terms of a numeric code.  Response
   status codes are defined in Section 17.1 of 5.6.  If the Control Framework
   [I-D.ietf-mediactrl-sip-control-framework].

   <?xml version="1.0" encoding="UTF-8"?>
   <xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-mixer"
    xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
    elementFormDefault="qualified"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns="urn:ietf:params:xml:ns:msc-mixer"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <xsd:annotation>
     <xsd:documentation>
      IETF MediaCtrl Mixer 1.0 (20081010)

      This request is
   successful, the schema of the Mixer control package. It
      defines request, response and notification elements for
      mixing.

      The schema namespace <auditresponse> contains (depending on attribute
   values) a <capabilities> element (Section 5.3.2.1) reporting package
   capabilities and a <mixers> element (Section 5.3.2.2) reporting
   managed mixer information.  If the MS is urn:ietf:params:xml:ns:msc-mixer

     </xsd:documentation>
    </xsd:annotation>

    <!--
     #############################################################

     SCHEMA IMPORTS

     #############################################################
    -->

    <xsd:import
     namespace="urn:ietf:params:xml:ns:control:framework-attributes"
     schemaLocation="framework.xsd">
     <xsd:annotation>
      <xsd:documentation>
       This import brings not able to process the
   request and carry out the audit operation, the audit request has
   failed and the MS MUST indicate the class of failure using an
   appropriate 4xx response code.  Unless an error response code is
   mandated for a specific class of error within this section,
   implementations follow Section 5.6 in determining the framework attributes appropriate
   status code for
       conferenceid the response.

   For example, a request to audit capabilities and connectionid.
      </xsd:documentation>
     </xsd:annotation>
    </xsd:import>

    <!--
     #####################################################

     Extensible core type

     #####################################################
    -->

    <xsd:complexType name="Tcore">
     <xsd:annotation>
      <xsd:documentation>
       This type is extended mixers managed by other component types
   the package:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <audit/>
   </mscmixer>

   In this example, only capabilities are to
       allow elements and attributes from other namespaces be audited:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <audit mixers="false"/>
   </mscmixer>

   With this example, only a specific conference mixer is to be added.
      </xsd:documentation>
     </xsd:annotation>
     <xsd:sequence>
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:sequence>
     <xsd:anyAttribute namespace="##other" processContents="lax" />
    </xsd:complexType>

    <!--
     #####################################################

     TOP LEVEL ELEMENT: mscmixer

     #####################################################
    -->

    <xsd:complexType name="mscmixerType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:choice>
         <xsd:element ref="createconference" />
         <xsd:element ref="modifyconference" />
         <xsd:element ref="destroyconference" />
         <xsd:element ref="join" />
         <xsd:element ref="unjoin" />
         <xsd:element ref="modifyjoin" />
         <xsd:element ref="response" />
         <xsd:element ref="event" />
         <xsd:element ref="audit" />
         <xsd:element ref="auditresponse" />
         <xsd:any namespace="##other" minOccurs="0"
          maxOccurs="unbounded" processContents="lax" />
        </xsd:choice>
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="mscmixer" type="mscmixerType" />

    <!--
     #####################################################

     CONFERENCE MANAGEMENT TYPES

     #####################################################
    -->

    <!--  createconference -->

    <xsd:complexType name="createconferenceType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence> audited:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
     <audit capabilities="false" conferenceid="conf4"/>
   </mscmixer>

5.3.2.  <auditresponse>

   The <auditresponse> element describes a response to a <audit>
   request.

   The <auditresponse> element has the following attributes:

   status:  numeric code indicating the audit response status.  The
      attribute is mandatory.  Valid values are defined in Section 5.6.

   reason:  string specifying a reason for the status.  The attribute is
      optional.

   The <auditresponse> element has the following sequence of child
   elements:

   <capabilities>  element (Section 5.3.2.1) describing capabilities of
      the package.  The element is optional.

   <mixers>  element (Section 5.3.2.2) describing information about
      managed mixers.  The element is optional.

   For example, a successful response to a <audit> request requesting
   capabilities and mixer information:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <auditresponse status="200">
     <capabilities>
      <codecs>
       <codec>
        <subtype>H263</subtype>
       </codec>
       <codec>
        <subtype>H264</subtype>
       </codec>
       <codec>
        <subtype>PCMU</subtype>
       </codec>
       <codec>
        <subtype>PCMA</subtype>
       </codec>
      </codecs>
     </capabilities>
     <mixers>
      <conferenceaudit conferenceid="conf1">
       <codecs>
        <codec>
         <subtype>PCMA</subtype>
        </codec>
       </codecs>
       <participants>
        <participant id="connection1"/>
       </participants>
      </conferenceaudit>
      <joinaudit id1="connection1" id2="conf1"/>
      <joinaudit id1="connection2" id2="connection3"/>
      <joinaudit id1="connection4" id2="connection5"/>
     </mixers>
    </auditresponse>
   </mscmixer>

5.3.2.1.  <capabilities>

   The <capabilities> element provides audit information about package
   capabilities.

   The <capabilities> element has no attributes.

   The <capabilities> element has the following sequence of child
   elements:

   <codecs>:  element (Section 5.4) describing codecs available to the
      package.  The element is mandatory.

   For example, a fragment describing capabilities:

     <capabilities>
      <codecs>
       <codec>
        <subtype>H263</subtype>
       </codec>
       <codec>
        <subtype>H264</subtype>
       </codec>
       <codec>
        <subtype>PCMU</subtype>
       </codec>
       <codec>
        <subtype>PCMA</subtype>
       </codec>
      </codecs>
     </capabilities>

5.3.2.2.  <mixers>

   The <mixers> element provides audit information about mixers.

   The <mixers> element has no attributes.

   The <mixers> element has the following sequence of child elements (0
   or more occurrences, any order):

   <conferenceaudit>:  audit information for a conference mixer
      (Section 5.3.2.2.1).  The element is optional.

   <joinaudit>:  audit information for a join mixer (Section 5.3.2.2.2).
      The element is optional.

5.3.2.2.1.  <conferenceaudit>

   The <conferenceaudit> element has the following attributes:

   conferenceid:  string identifying the conference (see Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework]).  The attribute is
      mandatory.

   The <conferenceaudit> element has the following sequence of child
   elements:

   <codecs>  element describing codecs used in the conference.  See
      Section 5.4.  The element is optional.

   <participants>  element listing connections or conferences joined to
      the conference.  See Section 5.3.2.2.1.1.  The element is
      optional.

   <video-layout>  element describing the active video layout for the
      conference.  See Section 5.2.1.4.2.1.  The element is optional.

   For example, a fragment describing a conference which has been
   created but has no participants:

   <conferenceaudit conferenceid="conference1"/>

   And a fragment when the same conference has three participants (two
   connections and another conference) joined to it:

   <conferenceaudit conferenceid="conference1">
    <codecs>
     <codec>
      <subtype>PCMU</subtype>
     </codec>
    </codecs>
    <participants>
      <participant id="connection1"/>
      <participant id="connection2"/>
      <participant id="conference2"/>
    </participants>
   </conferenceaudit>

5.3.2.2.1.1.  <participants>

   The <participants> element is a container for <participant> elements
   (Section 5.3.2.2.1.1.1).

   The <participants> element has no attributes, but the following child
   elements are defined (0 or more):

   <participant>:  specifies a participant (Section 5.3.2.2.1.1.1).

5.3.2.2.1.1.1.  <participant>

   The <participant> element describes a participant.

   The <participant> element has the following attributes:

   id:  an identifier for either a connection or a conference.  The
      identifier MUST conform to the syntax defined in Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework].  The attribute is
      mandatory.

   The <participant> element has no children.

5.3.2.2.2.  <joinaudit>

   The <joinaudit> element has the following attributes:

   id1:  an identifier for either a connection or a conference.  The
      identifier MUST conform to the syntax defined in Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is
      mandatory.

   id2:  an identifier for either a connection or a conference.  The
      identifier MUST conform to the syntax defined in Section 17.1 of
      [I-D.ietf-mediactrl-sip-control-framework] The attribute is
      mandatory.

   The <joinaudit> element has no children.

   For example, a fragment describing an audit of two join mixers, one
   between connections and the second between conferences:

   <mixers>
    <joinaudit id1="connection1" id2="connection2"/>
    <joinaudit id1="conference1" id2="conference2"/>
   </mixers>

5.4.  <codecs>

   The <codecs> element is a container for one or more codec
   definitions.  Codec definitions are used by an AS to specify the
   codecs allowed for a conference (e.g. when used as a child of
   <createconference> or <modifyconference).  Codec definitions are used
   by an MS to provide audit information about the codecs supported by
   an MS and used in specific conferences.

   The <codecs> element has no attributes.

   The <codecs> element has the following sequence of child elements (0
   or more occurrences):

   <codec>:  defines a codec and optionally its policy(Section 5.4.1).
      The element is optional.

   For example, a fragment describing two codecs:

   <codecs>
     <codec>
      <subtype>PCMA</subtype>
     </codec>
     <codec>
       <subtype>H263</subtype>
     </codec>
   </codecs>

5.4.1.  <codec>

   The <codec> element describes a codec.  The element is modeled on the
   <codec> element in the XCON conference information data model
   ([I-D.ietf-xcon-common-data-model]) and allows addition information
   (e.g. rate, speed, etc) to be specified.

   The <codecs> element has no attributes.

   The <codecs> element has the following sequence of child elements:

   <subtype>:  element describing the codec's name.  The possible values
      of this element are the values of the 'subtype' column of the RTP
      Payload Format media types per [RFC4855] defined in IANA ([IANA]).
      The element is mandatory.

   <params>:  element (Section 5.5) describing additional information
      about the codec.  This package is agnostic to the names and values
      of the codec parameters supported by an implementation.  The
      element is optional.

   For example, a fragment with a <codec> element describing the H263
   codec:

   <codec>
    <subtype>H263</subtype>
   </codec>

5.5.  <params>

   The <params> element is a container for <param> elements
   (Section 5.5.1).

   The <params> element has no attributes, but the following child
   elements are defined (0 or more):

   <param>:  specifies a parameter name and value (Section 5.5.1).

5.5.1.  <param>

   The <param> element describes a parameter name and value.

   The <param> element has the following attributes:

   name:  a string indicating the name of the parameter.  The attribute
      is mandatory.

   type:  specifies a type indicating how the inline value of the
      parameter is to be interpreted.  A valid value is a MIME media
      type (see Section 5.7.6).  The attribute is optional.  The default
      value is "text/plain".

   The <param> element content model is the value of the parameter.
   Note that a value which contains XML characters (e.g. "<") needs to
   be escaped following standard XML conventions.

5.6.  Response Status Codes

   This section describes the response codes in Table 1 for the status
   attribute of mixer management <response> (Section 5.2.3) and audit
   <auditresponse> (Section 5.3.2) responses.  The MS MUST support these
   status response codes.  The MS MAY support other response codes.  The
   AS MUST treat any responses it does not recognize as being equivalent
   to the x00 response code for all classes.  For example, if an AS
   receives an unrecognized response code of 499, it can safely assume
   that there was something wrong with its request and treat the
   response as if it had received a 400 (Syntax error) response code.

   4xx responses are definite failure responses from a particular MS.
   The reason attribute in the response SHOULD identify the failure in
   more detail, for example, "Mandatory attribute missing: id2 join
   element" for a 400 (Syntax error) response code.

   The AS SHOULD NOT retry the same request without modification (for
   example, correcting a syntax error or changing the conferenceid to
   use one available on the MS).  However, the same request to a
   different MS might be successful; for example, if another MS supports
   a capability required in the request.

   4xx failure responses can be grouped into three classes: failure due
   to a syntax error in the request (400); failure due to an error
   executing the request on the MS (405-419); and failure due to the
   request requiring a capability not supported by the MS (420-435).

   In cases where more than one request code could be reported for a
   failure, the MS SHOULD use the most specific error code of the
   failure class for the detected error.  For example, if the MS detects
   that the conference identifier in the request is invalid, then it
   uses a 406 status code.  However, if the MS merely detects that an
   execution error occurred, then 419 is used.

   +-------+---------------+----------------------+--------------------+
   | Code  | Summary       | Description          | Informational: AS  |
   |       |               |                      | Possible Recovery  |
   |       |               |                      | Action             |
   +-------+---------------+----------------------+--------------------+
   | 200   | OK            | request has          |                    |
   |       |               | succeeded            |                    |
   |       |               |                      |                    |
   | 400   | Syntax error  | request is           | Change the request |
   |       |               | syntactically        | so that it is      |
   |       |               | invalid: it is not   | syntactically      |
   |       |               | valid with respect   | valid.             |
   |       |               | to the XML schema    |                    |
   |       |               | specified in         |                    |
   |       |               | Section 6 or it      |                    |
   |       |               | violates a           |                    |
   |       |               | co-occurrence        |                    |
   |       |               | constraint for a     |                    |
   |       |               | request element      |                    |
   |       |               | defined in           |                    |
   |       |               | Section 5.           |                    |
   |       |               |                      |                    |
   | 401   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 402   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 403   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 404   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   | 405   | Conference    | request uses an      | Send an <audit>    |
   |       | already       | identifier to create | request            |
   |       | exists        | a new conference     | (Section 5.3.1)    |
   |       |               | (Section 5.2.1.1)    | requesting the     |
   |       |               | which is already     | list of conference |
   |       |               | used by another      | mixer identifiers  |
   |       |               | conference on the    | already used by    |
   |       |               | MS.                  | the MS and then    |
   |       |               |                      | use a conference   |
   |       |               |                      | identifier which   |
   |       |               |                      | is not listed.     |
   |       |               |                      |                    |
   | 406   | Conference    | request uses an      | Send an <audit>    |
   |       | does not      | identifier for a     | request            |
   |       | exist         | conference which     | (Section 5.3.1)    |
   |       |               | does not exist on    | requesting the     |
   |       |               | the MS.              | list of conference |
   |       |               |                      | mixer identifiers  |
   |       |               |                      | used by the MS and |
   |       |               |                      | then use a         |
   |       |               |                      | conference         |
   |       |               |                      | identifier which   |
   |       |               |                      | is listed.         |
   |       |               |                      |                    |
   | 407   | Incompatible  | request specifies a  | Change the media   |
   |       | stream        | media stream         | stream             |
   |       | configuration | configuration which  | configuration to   |
   |       |               | is in conflict with  | match the          |
   |       |               | itself, or the       | capabilities of    |
   |       |               | connection or        | the connection or  |
   |       |               | conference           | conference         |
   |       |               | capabilities (see    |                    |
   |       |               | Section 5.2.2.2)     |                    |
   |       |               |                      |                    |
   | 408   | joining       | request attempts to  | Send an <audit>    |
   |       | entities      | create a join mixer  | request            |
   |       | already       | (Section 5.2.2.2)    | (Section 5.3.1)    |
   |       | joined        | where the entities   | requesting the     |
   |       |               | are already joined   | list of join       |
   |       |               |                      | mixers on the MS   |
   |       |               |                      | and then use       |
   |       |               |                      | entities which are |
   |       |               |                      | not listed.        |
   |       |               |                      |                    |
   | 409   | joining       | request attempts to  | Send an <audit>    |
   |       | entities not  | manipulate a join    | request            |
   |       | joined        | mixer where entities | (Section 5.3.1)    |
   |       |               | which are not joined | requesting the     |
   |       |               |                      | list of join       |
   |       |               |                      | mixers on the MS   |
   |       |               |                      | and then use       |
   |       |               |                      | entities which are |
   |       |               |                      | listed.            |
   |       |               |                      |                    |
   | 410   | Unable to     | request attempts to  |                    |
   |       | join -        | join a participant   |                    |
   |       | conference    | to a conference      |                    |
   |       | full          | (Section 5.2.2.2)    |                    |
   |       |               | but the conference   |                    |
   |       |               | is already full      |                    |
   |       |               |                      |                    |
   | 411   | Unable to     | request attempts to  |                    |
   |       | perform join  | create, modify or    |                    |
   |       | mixer         | delete a join        |                    |
   |       | operation     | between entities but |                    |
   |       |               | fails                |                    |
   |       |               |                      |                    |
   | 412   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 413   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 414   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 415   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 416   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 417   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 418   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 419   | Other         | requested operation  |                    |
   |       | execution     | cannot be executed   |                    |
   |       | error         | by the MS.           |                    |
   |       |               |                      |                    |
   | 420   | Conference    | request to create a  |                    |
   |       | reservation   | new conference       |                    |
   |       | failed        | (Section 5.2.1.1)    |                    |
   |       |               | failed due to        |                    |
   |       |               | unsupported          |                    |
   |       |               | reservation of       |                    |
   |       |               | talkers or           |                    |
   |       |               | listeners.           |                    |
   |       |               |                      |                    |
   | 421   | Unable to     | request to create or |                    |
   |       | configure     | modify a conference  |                    |
   |       | audio mix     | failed due to        |                    |
   |       |               | unsupported audio    |                    |
   |       |               | mix.                 |                    |
   |       |               |                      |                    |
   | 422   | Unable to     | request to create or |                    |
   |       | create        | modify a conference  |                    |
   |       | subscription  | failed due to        |                    |
   |       |               | unsupported          |                    |
   |       |               | subscription.        |                    |
   |       |               |                      |                    |
   | 423   | Unable to     | request to create or |                    |
   |       | configure     | modify a conference  |                    |
   |       | video layouts | failed due to        |                    |
   |       |               | unsupported video    |                    |
   |       |               | layout               |                    |
   |       |               | configuration.       |                    |
   |       |               |                      |                    |
   | 424   | Unable to     | request to create or |                    |
   |       | configure     | modify a conference  |                    |
   |       | video switch  | failed due to        |                    |
   |       |               | unsupported video    |                    |
   |       |               | switch               |                    |
   |       |               | configuration.       |                    |
   |       |               |                      |                    |
   | 425   | Unable to     | request to create or |                    |
   |       | configure     | modify a conference  |                    |
   |       | codecs        | failed due to        |                    |
   |       |               | unsupported codec.   |                    |
   |       |               |                      |                    |
   | 426   | Unable to     | request to join      |                    |
   |       | join - mixing | connection entities  |                    |
   |       | connections   | (Section 5.2.2.2)    |                    |
   |       | not supported | failed due lack of   |                    |
   |       |               | support for mixing   |                    |
   |       |               | connections.         |                    |
   |       |               |                      |                    |
   | 427   | Unable to     | request to join      |                    |
   |       | join - mixing | conference entities  |                    |
   |       | conferences   | (Section 5.2.2.2)    |                    |
   |       | not supported | failed due lack of   |                    |
   |       |               | support for mixing   |                    |
   |       |               | conferences.         |                    |
   |       |               |                      |                    |
   | 428   | Unsupported   | the request contains |                    |
   |       | foreign       | attributes or        |                    |
   |       | namespace     | elements from        |                    |
   |       | attribute or  | another namespace    |                    |
   |       | element       | which the MS does    |                    |
   |       |               | not support          |                    |
   |       |               |                      |                    |
   | 429   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 430   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 431   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 432   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 433   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 434   | Reserved for  |                      |                    |
   |       | future use    |                      |                    |
   |       |               |                      |                    |
   | 435   | Other         | request requires     |                    |
   |       | unsupported   | another capability   |                    |
   |       | capability    | not supported by the |                    |
   |       |               | MS                   |                    |
   +-------+---------------+----------------------+--------------------+

                           Table 1: status codes

5.7.  Type Definitions

   This section defines types referenced in attribute definitions.

5.7.1.  Boolean

   The value space of boolean is the set {true, false}.

5.7.2.  Non-Negative Integer

   The value space of non-negative integer is the infinite set
   {0,1,2,...}.

5.7.3.  Positive Integer

   The value space of positive integer is the infinite set {1,2,...}.

5.7.4.  String

   A string in the character encoding associated with the XML element.

5.7.5.  Time Designation

   A time designation consists of a non-negative real number followed by
   a time unit identifier.

   The time unit identifiers are: "ms" (milliseconds) and "s" (seconds).

   Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s".

5.7.6.  MIME Media Type

   A string formated as a IANA MIME media type ([MIME.mediatypes]).

6.  Formal Syntax

   This section defines the XML schema for the Mixer Control Package.

   The schema defines datatypes, attributes, and mixer elements in the
   urn:ietf:params:xml:ns:msc-mixer namespace.  In most elements the
   order of child elements is significant.  The schema is extensible:
   elements allow attributes and child elements from other namespaces.
   Elements from outside this package's namespace can occur after
   elements defined in this package.

   The schema is dependent upon the schema (framework.xsd) defined in
   Section 17.1 of the Control Framework
   [I-D.ietf-mediactrl-sip-control-framework].

   <?xml version="1.0" encoding="UTF-8"?>
   <xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-mixer"
    xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
    elementFormDefault="qualified"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns="urn:ietf:params:xml:ns:msc-mixer"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <xsd:annotation>
     <xsd:documentation>
      IETF MediaCtrl Mixer 1.0 (20081010)

      This is the schema of the Mixer control package. It
      defines request, response and notification elements for
      mixing.

      The schema namespace is urn:ietf:params:xml:ns:msc-mixer

     </xsd:documentation>
    </xsd:annotation>

    <!--
     #############################################################

     SCHEMA IMPORTS

     #############################################################
    -->

    <xsd:import
     namespace="urn:ietf:params:xml:ns:control:framework-attributes"
     schemaLocation="framework.xsd">
     <xsd:annotation>
      <xsd:documentation>
       This import brings in the framework attributes for
       conferenceid and connectionid.
      </xsd:documentation>
     </xsd:annotation>
    </xsd:import>

    <!--
     #####################################################

     Extensible core type

     #####################################################
    -->

    <xsd:complexType name="Tcore">
     <xsd:annotation>
      <xsd:documentation>
       This type is extended by other component types to
       allow elements and attributes from other namespaces
       to be added.
      </xsd:documentation>
     </xsd:annotation>
     <xsd:sequence>
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:sequence>
     <xsd:anyAttribute namespace="##other" processContents="lax" />
    </xsd:complexType>

    <!--
     #####################################################

     TOP LEVEL ELEMENT: mscmixer

     #####################################################
    -->

    <xsd:complexType name="mscmixerType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:choice>
         <xsd:element ref="createconference" />
         <xsd:element ref="modifyconference" />
         <xsd:element ref="destroyconference" />
         <xsd:element ref="join" />
         <xsd:element ref="unjoin" />
         <xsd:element ref="modifyjoin" />
         <xsd:element ref="response" />
         <xsd:element ref="event" />
         <xsd:element ref="audit" />
         <xsd:element ref="auditresponse" />
         <xsd:any namespace="##other" minOccurs="0"
          maxOccurs="unbounded" processContents="lax" />
        </xsd:choice>
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="mscmixer" type="mscmixerType" />

    <!--
     #####################################################

     CONFERENCE MANAGEMENT TYPES

     #####################################################
    -->

    <!--  createconference -->

    <xsd:complexType name="createconferenceType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="codecs" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="audio-mixing" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="video-layouts" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="video-switch" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="subscribe" minOccurs="0"
         maxOccurs="1" />
        <xsd:any namespace="##other"
         processContents="lax" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attribute name="conferenceid" type="xsd:string" />
       <xsd:attribute name="reserved-talkers"
        type="xsd:nonNegativeInteger" default="0" />
       <xsd:attribute name="reserved-listeners"
        type="xsd:nonNegativeInteger" default="0" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="createconference" type="createconferenceType" />

    <!--  modifyconference -->

    <xsd:complexType name="modifyconferenceType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="codecs" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="audio-mixing" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="video-layouts" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="video-switch" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="subscribe" />
        <xsd:any namespace="##other"
         processContents="lax" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attribute name="conferenceid" type="xsd:string"
        use="required" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="modifyconference" type="modifyconferenceType" />

    <!--  destroyconference -->

    <xsd:complexType name="destroyconferenceType">
     <xsd:attribute name="conferenceid" type="xsd:string"
      use="required" />
    </xsd:complexType>

    <xsd:element name="destroyconference"
     type="destroyconferenceType" />
    <!--
     #####################################################

     JOIN TYPES

     #####################################################
    -->

    <xsd:complexType name="joinType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="stream" minOccurs="0"
         maxOccurs="unbounded" />
        <xsd:any namespace="##other"
         processContents="lax" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attribute name="id1" type="xsd:string"
        use="required" />
       <xsd:attribute name="id2" type="xsd:string"
        use="required" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="join" type="joinType" />

    <xsd:complexType name="modifyjoinType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="stream" minOccurs="0"
         maxOccurs="unbounded" />
        <xsd:any namespace="##other"
         processContents="lax" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attribute name="id1" type="xsd:string"
        use="required" />
       <xsd:attribute name="id2" type="xsd:string"
        use="required" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="modifyjoin" type="modifyjoinType" />

    <xsd:complexType name="unjoinType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="stream" minOccurs="0"
         maxOccurs="unbounded" />
        <xsd:any namespace="##other"
         processContents="lax" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attribute name="id1" type="xsd:string"
        use="required" />
       <xsd:attribute name="id2" type="xsd:string"
        use="required" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="unjoin" type="unjoinType" />

    <!--
     #####################################################

     OTHER TYPES

     #####################################################
    -->

    <xsd:complexType name="eventType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:choice>
         <xsd:element ref="active-talkers-notify"
          minOccurs="0" maxOccurs="1" />
         <xsd:element ref="unjoin-notify"
          minOccurs="0" maxOccurs="1" />
         <xsd:element ref="conferenceexit"
          minOccurs="0" maxOccurs="1" />
         <xsd:any namespace="##other" minOccurs="0"
          maxOccurs="unbounded" processContents="lax" />
        </xsd:choice>
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="event" type="eventType" />

    <xsd:complexType name="activetalkersnotifyType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="active-talker" minOccurs="0"
         maxOccurs="unbounded" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attribute name="conferenceid" type="xsd:string"
        use="required" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="active-talkers-notify"
     type="activetalkersnotifyType" />

    <xsd:complexType name="activetalkerType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attributeGroup ref="fw:framework-attributes" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="active-talker" type="activetalkerType" />

    <xsd:complexType name="unjoinnotifyType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attribute name="status" type="status.datatype"
        use="required" />
       <xsd:attribute name="reason" type="xsd:string" />
       <xsd:attribute name="id1" type="xsd:string"
        use="required" />
       <xsd:attribute name="id2" type="xsd:string"
        use="required" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="unjoin-notify" type="unjoinnotifyType" />

    <!--  conferenceexit-->

    <xsd:complexType name="conferenceexitType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attribute name="conferenceid" type="xsd:string"
        use="required" />
       <xsd:attribute name="status"
        type="xsd:nonNegativeInteger" use="required" />
       <xsd:attribute name="reason" type="xsd:string" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="conferenceexit" type="conferenceexitType" />

    <xsd:complexType name="responseType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:attribute name="status" type="status.datatype"
        use="required" />
       <xsd:attribute name="reason" type="xsd:string" />

       <xsd:attributeGroup ref="fw:framework-attributes" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="response" type="responseType" />

    <xsd:complexType name="subscribeType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="active-talkers-sub"
         minOccurs="0" maxOccurs="1" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="subscribe" type="subscribeType" />

    <xsd:complexType name="activetalkerssubType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attribute name="interval"
        type="xsd:nonNegativeInteger" default="3" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="active-talkers-sub"
     type="activetalkerssubType" />

    <xsd:complexType name="streamType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="volume" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="clamp" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="region" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="priority" minOccurs="0"
         maxOccurs="1" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attribute name="media" type="media.datatype"
        use="required" />
       <xsd:attribute name="label" type="label.datatype" />
       <xsd:attribute name="direction"
        type="direction.datatype" default="sendrecv" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="stream" type="streamType" />

    <xsd:complexType name="volumeType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attribute name="controltype"
        type="volumecontroltype.datatype" use="required" />
       <xsd:attribute name="value" type="xsd:string" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="volume" type="volumeType" />

    <xsd:complexType name="clampType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attribute name="tones" type="xsd:string"
        use="required" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="clamp" type="clampType" />

    <!--  region  -->
    <xsd:simpleType name="regionType">
     <xsd:restriction base="xsd:NMTOKEN" />
    </xsd:simpleType>

    <xsd:element name="region" type="regionType" />
    <!--  priority  -->
    <xsd:simpleType name="priorityType">
     <xsd:restriction base="xsd:positiveInteger" />
    </xsd:simpleType>

    <xsd:element name="priority" type="priorityType" />

    <xsd:complexType name="audiomixingType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:attribute name="type" type="audiomix.datatype"
        default="nbest" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="audio-mixing" type="audiomixingType" />

    <!-- video-switch -->

    <xsd:complexType name="videoswitchType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attribute name="type"
        type="videoswitchtype.datatype" default="vas" />
       <xsd:attribute name="interval"
        type="xsd:nonNegativeInteger" default="3" />
       <xsd:attribute name="activespeakermix"
        type="boolean.datatype" default="false" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="video-switch" type="videoswitchType" />

    <!-- video-layouts -->

    <xsd:complexType name="videolayoutsType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="video-layout" minOccurs="0"
         maxOccurs="unbounded" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="video-layouts" type="videolayoutsType" />

    <!-- video-layout -->
    <!--  doesn't extend tCore since its content model is mixed -->

    <xsd:complexType name="videolayoutType" mixed="true">
     <xsd:sequence>
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:sequence>
     <xsd:attribute name="min-participants"
      type="xsd:positiveInteger" default="1" />
    </xsd:complexType>

    <xsd:element name="video-layout" type="videolayoutType" />

    <xsd:complexType name="auditType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:attribute name="capabilities"
        type="boolean.datatype" default="true" />
       <xsd:attribute name="mixers" type="boolean.datatype"
        default="true" />
       <xsd:attribute name="conferenceid" type="xsd:string" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="audit" type="auditType" />

    <xsd:complexType name="auditresponseType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="capabilities" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="mixers" minOccurs="0"
         maxOccurs="1" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attribute name="status" type="status.datatype"
        use="required" />
       <xsd:attribute name="reason" type="xsd:string" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="auditresponse" type="auditresponseType" />

    <!-- mixers -->

    <xsd:complexType name="mixersType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="conferenceaudit" minOccurs="0"
         maxOccurs="unbounded" />
        <xsd:element ref="joinaudit" minOccurs="0"
         maxOccurs="unbounded" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="mixers" type="mixersType" />

    <!--  joinaudit -->

    <xsd:complexType name="joinauditType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:any namespace="##other"
         processContents="lax" minOccurs="0" maxOccurs="unbounded" />
       </xsd:sequence>
       <xsd:attribute name="id1" type="xsd:string"
        use="required" />
       <xsd:attribute name="id2" type="xsd:string"
        use="required" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="joinaudit" type="joinauditType" />
    <!-- conferenceaudit -->

    <xsd:complexType name="conferenceauditType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="codecs" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="participants" minOccurs="0"
         maxOccurs="1" />
        <xsd:element ref="video-layout" minOccurs="0"
         maxOccurs="1" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attribute name="conferenceid" type="xsd:string"
        use="required" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="conferenceaudit" type="conferenceauditType" />

    <!-- participants -->

    <xsd:complexType name="participantsType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="participant" minOccurs="0"
         maxOccurs="unbounded" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="participants" type="participantsType" />

    <!-- participant -->

    <xsd:complexType name="participantType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
       <xsd:attribute name="id" type="xsd:string"
        use="required" />
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="participant" type="participantType" />

    <!-- capabilities -->

    <xsd:complexType name="capabilitiesType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="codecs" minOccurs="1"
         maxOccurs="1" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="capabilities" type="capabilitiesType" />

    <!-- codecs -->

    <xsd:complexType name="codecsType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="codec" minOccurs="0"
         maxOccurs="unbounded" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="codecs" type="codecsType" />

    <!-- codec -->

    <xsd:complexType name="codecType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="subtype" minOccurs="1"
         maxOccurs="1" />
        <xsd:element ref="params" minOccurs="0"
         maxOccurs="1" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="codec" type="codecType" />

    <!-- subtype -->

    <xsd:simpleType name="subtypeType">
     <xsd:restriction base="xsd:string" />
    </xsd:simpleType>

    <xsd:element name="subtype" type="subtypeType" />

    <!-- params -->
    <xsd:complexType name="paramsType">
     <xsd:complexContent>
      <xsd:extension base="Tcore">
       <xsd:sequence>
        <xsd:element ref="param" minOccurs="0"
         maxOccurs="unbounded" />
        <xsd:any namespace="##other" minOccurs="0"
         maxOccurs="unbounded" processContents="lax" />
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>

    <xsd:element name="params" type="paramsType" />

    <!--  param -->
    <!--  doesn't extend tCore since its content model is mixed -->
    <xsd:complexType name="paramType" mixed="true">
     <xsd:sequence>
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:sequence>
     <xsd:attribute name="name" type="xsd:string" use="required" />
     <xsd:attribute name="type" type="mime.datatype"
      default="text/plain" />
     <xsd:anyAttribute namespace="##other" processContents="lax" />
    </xsd:complexType>

    <xsd:element name="param" type="paramType" />

    <!--
     ####################################################

     DATATYPES

     ####################################################
    -->

    <xsd:simpleType name="eventname.datatype">
     <xsd:restriction base="xsd:NMTOKEN">
      <xsd:pattern value="[a-zA-Z0-9\.]+" />
     </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="audiomix.datatype">
     <xsd:restriction base="xsd:NMTOKEN">
      <xsd:enumeration value="nbest" />
      <xsd:enumeration value="controller" />
     </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="media.datatype">
     <xsd:restriction base="xsd:string" />
    </xsd:simpleType>

    <xsd:simpleType name="label.datatype">
     <xsd:restriction base="xsd:string" />
    </xsd:simpleType>

    <xsd:simpleType name="status.datatype">
     <xsd:restriction base="xsd:positiveInteger">
      <xsd:pattern value="[0-9][0-9][0-9]" />
     </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="direction.datatype">
     <xsd:restriction base="xsd:NMTOKEN">
      <xsd:enumeration value="sendonly" />
      <xsd:enumeration value="recvonly" />
      <xsd:enumeration value="sendrecv" />
      <xsd:enumeration value="inactive" />
     </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="boolean.datatype">
     <xsd:restriction base="xsd:NMTOKEN">
      <xsd:enumeration value="true" />
      <xsd:enumeration value="false" />
     </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="mime.datatype">
     <xsd:restriction base="xsd:string" />
    </xsd:simpleType>

    <xsd:simpleType name="videoswitchtype.datatype">
     <xsd:restriction base="xsd:NMTOKEN">
      <xsd:enumeration value="vas" />
      <xsd:enumeration value="controller" />
     </xsd:restriction>
    </xsd:simpleType>

    <xsd:simpleType name="volumecontroltype.datatype">
     <xsd:restriction base="xsd:NMTOKEN">
      <xsd:enumeration value="automatic" />
      <xsd:enumeration value="setgain" />
      <xsd:enumeration value="setstate" />
     </xsd:restriction>
    </xsd:simpleType>

   </xsd:schema>

                    Figure 1: 10: Mixer Package XML Schema

7.  Examples

   This section provides

   This section provides examples of the Mixer Control package.

7.1.  AS-MS Framework Interaction Examples

   The following example assume a control channel has been established
   and synced as described in the Media Control Channel Framework
   ([I-D.ietf-mediactrl-sip-control-framework]).

   The XML messages are in angled brackets (with the root <mscmixer> and
   other details omitted for clarity); the REPORT status is in round
   brackets.  Other aspects of the protocol are omitted for readability.

7.1.1.  Creating a conference mixer and joining a participant

   A conference mixer is created successfully and a participant is
   joined.

             Application Server (AS)                   Media Server (MS)
                |                                             |
                |       (1) CONTROL: <createconference>       |
                |  ---------------------------------------->  |
                |                                             |
                |       (2) 202                               |
                |  <---------------------------------------   |
                |                                             |
                |                                             |
                |       (3) REPORT: <response status="200"/>  |
                |                   (terminate)               |
                |  <----------------------------------------  |
                |                                             |
                |       (4) 200                               |
                |  ---------------------------------------->  |
                |                                             |
                |       (5) CONTROL: <join id1=.. id2=..>     |
                |  ---------------------------------------->  |
                |                                             |
                |       (6) 202                               |
                |  <---------------------------------------   |
                |                                             |
                |       (7) REPORT: <response status="200"/>  |
                |                   (terminate)               |
                |  <----------------------------------------  |
                |                                             |
                |       (8) 200                               |
                |  ---------------------------------------->  |

7.1.2.  Receiving active talker notifications

   An active talker notification event is sent by the MS.

             Application Server (AS)                   Media Server (MS)
                |                                             |
                |       (1) CONTROL: <event ...>              |
                |  <---------------------------------------   |
                |                                             |
                |       (4) 200                               |
                |  ---------------------------------------->  |
                |                                             |

7.1.3.  Conference termination

   The MS receives a request to terminate the conference, resulting in
   conferenceexit and participant unjoined notifications.

             Application Server (AS)                   Media Server (MS)
                |                                             |
                |       (1) CONTROL: <destroyconference>      |
                |  ---------------------------------------->  |
                |                                             |
                |       (2) 200: <response status="200"/>     |
                |  <---------------------------------------   |
                |                                             |
                |       (3) CONTROL: <event ..>               |
                |                   (unjoin-notify)           |
                |  <----------------------------------------  |
                |                                             |
                |       (4) 200                               |
                |  ---------------------------------------->  |
                |                                             |
                |       (5) CONTROL:  <event ..>              |
                |                   (conferenceexit)          |
                |  <----------------------------------------  |
                |                                             |
                |       (6) 200                               |
                |  ---------------------------------------->  |

7.2.  Mixing Examples

   The following examples show how the mixing package can be used to
   create audio conferences, bridge connections and video conferences.

   The examples do not specify all messages between the AS and MS.

7.2.1.  Audio conferencing

   The AS sends a request to create a conference mixer:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <createconference conferenceid="conf1"
     reserved-talkers="2" reserved-listeners="3">
     <audio-mixing type="nbest"/>
     <subscribe>
      <active-talkers-sub interval="5"/>
     </subscribe>
    </createconference>
   </mscmixer>

   The request specifies that the conference is assigned the conference
   id "conf1" and is configured with 2 reserved talkers, 3 reserved
   listener slots, audio mixing policy set to nbest and with active
   talkers notifications set to 5 seconds.

   If the MS is able to create this conference mixer, it sends 200
   response:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="200" reason="conference created"
              conferenceid="conf1"/>
   </mscmixer>

   The AS is now able to join connections to the conference as
   participants.  A participant able to contribute to the audio mix
   would be joined as follows:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join id1="1536067209~913cd14c" id2="conf1">
     <stream media="audio" direction="sendrecv"/>
    </join>
   </mscmixer>

   If the MS can join the participant 1536067209~913cd14c to the
   conference conf1 with audio in both directions, then it sends a
   successful response:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="200" reason="join successful"/>
   </mscmixer>

   The AS could also join listener-only participants to the conference
   by setting the stream direction to receive only:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join id1="9936067209~914cd14c" id2="conf1">
     <stream media="audio" direction="recvonly"/>
    </join>
   </mscmixer>

   If the MS can join the participant 9936067209~914cd14c to the
   conference conf1 then it would send a successful response (not
   shown).

   As the active talker changes, the MS sends an active talker
   notification to the AS:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <event>
     <active-talker-notify conferenceid="conf1">
      <active-talker connectionid="1536067209~913cd14c"/>
     </active-talker-notify>
    </event>
   </mscmixer>

   The AS could decide to change the status of a talker connection so
   that they can only listen:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <modifyjoin id1="1536067209~913cd14c" id2="conf1">
     <stream media="audio" direction="recvonly"/>
    </modifyjoin>
   </mscmixer>

   Where the participant 1536067209~913cd14c is no longer able to
   contribute to the audio mix on the conference.  If the MS is able to
   execute this request, it would send a 200 response.

   The AS could decide to remove this participant from the conference:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <unjoin id1="1536067209~913cd14c" id2="conf1"/>
   </mscmixer>

   Again, if the MS can execute this request, a 200 response would be
   sent.

   Finally, the AS terminates the conference:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <destroyconference conferenceid="conf1"/>
   </mscmixer>
   If the MS is able to destroy the conference conf1, it sends a 200
   response:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="200" conferenceid="conf1"/>
   </mscmixer>

   For each participant attached to the Mixer Control package.

7.1.  AS-MS Dialog Interaction Examples conference when it is destroyed,
   the MS sends an unjoin notification event:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <event>
     <unjoin-notify status="1" id1="9936067209~914cd14c"
         id2="conf1"/>
    </event>
   </mscmixer>

   And the MS sends a conferenceexit notification event when the
   conference finally exits:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <event>
     <conferenceexit status="1" conferenceid="conf1"/>
    </event>
   </mscmixer>

7.2.2.  Bridging connections

   The following example mixer package may be used to join connections to one another.  In
   a call center scenario, for example, this package can be used to set
   up and modify connections between a caller, agent and supervisor.

   A caller is joined to an agent with bi-directional audio:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join id1="caller~001" id2="agent~002">
     <stream media="audio" direction="sendrecv"/>
    </join>
   </mscmixer>

   If the MS is able to establish this connection, then it would send a
   200 response:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <response status="200"/>
   </mscmixer>

   Now assume that the AS wants a control channel supervisor to listen into the agent
   conversation with the caller and provide whsipered guidance to the
   agent.  First the AS would send a request to join the supervisor and
   the caller connections:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join  id1="supervisor~003" id2="caller~001">
     <stream media="audio" direction="recvonly"/>
    </join>
   </mscmixer>

   If this request was successful, audio output from the caller
   connection would now be sent to both the agent and the supervisor.

   Second, the AS would send a request to join the supervisor and the
   agent connections:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <join id1="supervisor~001" id2="agent~002">
     <stream media="audio" direction="sendrecv"/>
    </join>
   </mscmixer>

   If this request was successful, the audio mixing would occur on both
   the agent and supervisor connections: the agent would hear the caller
   and supervisor, and the supervisor would hear the agent and caller.
   The caller would only hear the agent.  If the MS is unable to join
   and mix connections in this way, it would send a 426 response.

7.2.3.  Video conferencing

   In this example, an audio video-conference is created with the
   loudest participant has been established
   and synced as described the most prominent region in the Media Control Channel Framework
   ([I-D.ietf-mediactrl-sip-control-framework]). video
   layout.

   The XML messages are in angled brackets (with AS sends a request to create an audio-video conference:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <createconference conferenceid="conf2">
     <audio-mixing type="nbest"/>
     <video-switch type="vas"/>
     <video-layouts>
      <video-layout min-participants="1">single-view</video-layout>
      <video-layout min-participants="2">dual-view</video-layout>
      <video-layout min-participants="3">quad-view</video-layout>
      <video-layout min-participants="5">multiple-5x1</video-layout>
     </video-layouts>
    </createconference>
   </mscmixer>
   In this configuration, the root <mscmixer>
   omitted); conference uses a nbest audio mixing
   policy and a vas video switch policy, so that the REPORT status is loudest speaker
   receives the most prominent region in round brackets.  Other aspects of the protocol layout.  Multiple video
   layouts are omitted for readability.

7.1.1.  Creating a conference mixer specified and joining active one depends on the number of
   participants.

   Assume that 4 participants are already joined to the conference.  In
   that case, the video layout will be quad-view (Figure 6) with the
   most active speaker displayed in region 1.  When a fifth participant

   A conference mixer is created successfully and
   joins, the video layout automatically switches to a participant is
   joined.

             Application Server (AS)                   Media Server (MS)
                |                                             |
                |       (1) CONTROL: <createconference>       |
                |  ---------------------------------------->  |
                |                                             |
                |       (2) 202                               |
                |  <---------------------------------------   |
                |                                             |
                |                                             |
                |       (3) REPORT: <response status="200"/>  |
                |                   (terminate)               |
                |  <----------------------------------------  |
                |                                             |
                |       (4) 200                               |
                |  ---------------------------------------->  |
                |                                             |
                |       (5) CONTROL: <join id1=.. id2=..>     |
                |  ---------------------------------------->  |
                |                                             |
                |       (6) 202                               |
                |  <---------------------------------------   |
                |                                             |
                |       (7) REPORT: <response status="200"/>  |
                |                   (terminate)               |
                |  <----------------------------------------  |
                |                                             |
                |       (8) 200                               |
                |  ---------------------------------------->  |

7.1.2.  Receiving active talker notifications

   An multiple-5x1
   layout (Figure 9), again with the most active talker notification event is sent by speaker in region 1.

   The AS can manipulate which participants are displayed in the MS.

             Application Server (AS)                   Media Server (MS)
                |                                             |
                |       (1) CONTROL: <event ...>              |
                |  <---------------------------------------   |
                |                                             |
                |       (4) 200                               |
                |  ---------------------------------------->  |
                |                                             |
   remaining regions.  For example, it could force an existing
   conference participant to be displayed in region 2:

   <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
    <modifyjoin id1="1536067209~913cd14c" id2="conf2">
     <stream media="video">
      <region>2</region>
     </stream>
    </modifyjoin>
   </mscmixer>

8.  Security Considerations

   As this control package processes XML markup, implementations MUST
   address the security considerations of [RFC3023].

   As a Control Package of the Media Control Channel Framework,
   security, confidentiality and integrity of messages transported over
   the control channel MUST be addressed as described in Section 11 of
   the Media Control channel Framework
   ([I-D.ietf-mediactrl-sip-control-framework]), including Session
   Establishment, Transport Level Protection and Control Channel Policy
   Management.

   The Media Control Channel Framework permits additional policy
   management, including resource access and control channel usage, to
   be specified at the control package level beyond that specified for
   the Media Control Channel Framework (see Section 11.3 of
   [I-D.ietf-mediactrl-sip-control-framework]).

   Since creation of conferences and other mixers is associated with
   media mixing resources on the MS, policy management for this control
   package MUST address how such mixers are managed across multiple
   control channels.  This includes which channels are used to deliver
   mixer event notifications, and whether channels are permitted to
   originate requests managing a mixer which was not created through
   that channel (e.g. a conference mixer has been created via channel X
   and a request to terminate the conference, or join a participant,
   originates from channel Y).

9.  IANA Considerations

   This specification instructs IANA to register a new Media Control
   Channel Framework Package, a new XML namespace and a new mime MIME type.

9.1.  Control Package Registration

   Control Package name: msc-mixer/1.0

9.2.  URN Sub-Namespace Registration

   XML namspace: urn:ietf:params:xml:ns:msc-mixer

9.3.  MIME Registration

   Mime type: application/msc-mixer+xml

10.  Change Summary

   Note to RFC Editor: Please remove this whole section.

   The following are the major changes between the -02 and -01 versions.

   o  Section 4: Aligned Control Package definitions with requirements
      in Section 8 of the Control Framework.

   o  Following October Interim meeting discussion on response codes,
      generally clarified usage of error status codes, modified some
      codes and re-organized the response codes section (Section 5.6)
      with more guidance and details.

   o  MIXER-006.  No action required following October 2008 interim
      discussion.

   o  MIXER-008.  No action required following October 2008 interim
      discussion.

   o  MIXER-009.  No action required for control package - addressed in
      -05 framework draft following interim October 2008 discussion.

   o  MIXER-010/5.2.2.5: Clarified that in the <stream> element, an
      "inactive" direction value indicates the stream is established but
      there is no media flow.  Such a stream can be manipulated by
      <modifyjoin> and <unjoin>.

   o  5.2.2.5: <stream>: Clarified that the media stream specified in
      child elements <volume>, <clamp>, <region> and <priority> is the
      stream originating from the entity identified as id1.

   o  5.2.1.4.3: <video-switch>: Clarified that it is not an error if a
      <stream> specifies a region which is not defined for the currently
      active video layout.

   o  5.2.1.4.2.1: <video-layout>: Added descriptions and ASCII art for
      layout and regions of XCON video layouts.

   o  Added examples of audio conferencing, connection bridging and
      video conferencing.

   The following are the major changes between the -01 and -00 versions.

   o  [MIXER-001]/5.2.4.3: Added <conferenceexit> notification event.

   o  [MIXER-003]/5.2.1.4.2.1: Added ASCII diagrams for video layouts.

   o  [MIXER-004]/5.3.2.2.1: Added active <video-layout> information to
      <conferenceaudit>.

   o  [MIXER-007]/5.4.1: Added <params> inside <codec> so additional
      codec information can be specified.

   o  5.2.1.1: Fixed <createconference> example with missing min-
      participants attributes.

   o  5: Changed handling of unsupported foreign namespace elements and
      attributes.  The MS send a 427 error response if it encounters
      foreign elements and attributes it does not support.

   o  5.2.1.4.3: <video-switch>.  Clarified that the VAS policy is
      implementation-specific if a participant provides more than one
      audio stream.

   o  5.2.2.2/5.2.2.3/5.2.2.4: Clarified that joining behavior so that
      streams which have previously been <modifiedjoin>ed or <unjoin>ed
      are not affected by a general <unjoin>.

   o  5.2.1.4.3: <video-switch>: Added support for whether active
      speaker is displayed on their video layout ('activespeakermix'
      attribute) and clarified that personal video mixes are out of
      scope for this package.

   o  5.2.1.4.3/5.2.2.5.4: <video-switch>: Added support for a priority
      mechanism in video switching policy and a <priority child element
      on <stream>.

   o  8:Updated security section

   o  13:Updated references

   o  5.2.1.4.4.1: Added default of 3 seconds for <active-talkers-sub>
      interval.

   o  5.2.2.5.1: <volume> controltype attribute set to mandatory.

   o  Updated schema

   The following are the major changes between the -00 of this work
   group item draft and the individual submission -04 version.

   o  Control package name is now 'msc-mixer/1.0'.  Namespace is now
      'urn:ietf:params:xml:ns:msc-mixer'.  Mime type is now
      'application/msc-mixer+xml'.

   o  Added XML root element <mscmixer>.

   o  Editorial tidy up of sections.

   o  Added audit request/response elements.

   o  Added video layout and switching conference configuration.

   o  <audio-mixing>: changed 'mix-type' attribute to 'type'
      (consistency with video-switch)

   o  Added "inactive" as value of <stream>'s direction attribute.

   o  Added <region> child to <stream> element.

   o  <createconference>: <audio-mixing> element is no longer mandatory;
      added <video-layouts> and <video-switch> child elements. reserved-
      talkers and reserved-listeners as attributes.

   o  replaced conf-id attribute with conferenceid attribute.

   o  Removed <data> element.  Active talkers subscription and
      notifications used dedicated elements now.

   o  Added <unjoin-notif> <unjoin-notify> notification event to indicate when
      (un)expected joins occur.  Use case: connection or conference
      joined to a conference and conference exits (either by request or
      runtime error.

   The following are the major changes between the -04 of the draft and
   the -03 version.

   o  Updated reference for Media Control Channel Framework

   The following are the major changes between the -03 of the draft and
   the -02 version.

   o  None

   The following are the major changes between the -02 of the draft and
   the -01 version.

   o  clarified the model for join operations and introduced several new
      package error codes

   o  added definition for MS connection

   The following are the major changes between the -01 of the draft and
   the -00 version.

   o  restructured into single request response model for non-trival non-trivial
      operations

   o  aligned with XML structure of other control framework packages

11.  Contributors

   Asher Shiratzky from Radvision provided valuable support and
   contributions to early versions of this document.

   The authors would like to thank the Mixer design team consisting of
   Roni Even, Lorenzo Miniero, Adnan Saleem, Diego Besprosvan and Mary
   Barnes who provided valuable feedback, input input, diagrams and text to
   this document.

12.  Acknowledgments

   The authors would like to thank Roni Even, Lorenzo Miniero and Steve
   Buko for expert reviews of this work.

13.  References

13.1.  Normative References

   [I-D.ietf-mediactrl-sip-control-framework]
              Boulton, C., Melanchuk, T., and S. McGlashan, "Media
              Control Channel Framework",
              draft-ietf-mediactrl-sip-control-framework-04
              draft-ietf-mediactrl-sip-control-framework-06 (work in
              progress), August October 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC4574]  Levin, O. and G. Camarillo, "The Session Description
              Protocol (SDP) Label Attribute", RFC 4574, August 2006.

   [XML]      Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E.,
              and F. Yergeau, "Extensible Markup Language (XML) 1.0
              (Third Edition)", W3C Recommendation, February 2004.

13.2.  Informative References

   [I-D.ietf-xcon-common-data-model]
              Novo, O., Camarillo, G., Morgan, D., and R. Even, R., and J.
              Urpalainen, "Conference Information Data Model for
              Centralized Conferencing (XCON)", draft-ietf-xcon-common-data-model-11
              draft-ietf-xcon-common-data-model-12 (work in progress), June
              October 2008.

   [IANA]     "IANA registry for RTP Payload Types",
              <http://www.iana.org/assignments/rtp-parameters>.

   [MIME.mediatypes]
              "IANA registry for MIME Media Types",
              <http://www.iana.org/assignments/media-types/>.

   [MSML]     Saleem, A., Xin, Y., and G. Sharratt, "Media Session
              Markup Language (MSML)", draft-saleem-msml-07 (work in
              progress), August 2008.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
              Formats", RFC 4855, February 2007.

   [RFC5022]  Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
              Control Markup Language (MSCML) and Protocol", RFC 5022,
              September 2007.

   [RFC5167]  Dolly, M. and R. Even, "Media Server Control Protocol
              Requirements", RFC 5167, March 2008.

Authors' Addresses

   Tim Melanchuk
   Rain Willow Communications

   Email: tim.melanchuk@gmail.com

   Scott McGlashan
   Hewlett-Packard
   Gustav III:s boulevard 36
   SE-16985 Stockholm, Sweden

   Email: scott.mcglashan@hp.com

   Chris Boulton
   Avaya
   Building 3
   Wern Fawr Lane
   St Mellons
   Cardiff, South Wales  CF3 5EA

   Email: cboulton@avaya.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.