Internet Engineering Task Force (IETF) S. McGlashan Request for Comments: 6505 Hewlett-Packard Category: Standards Track T. Melanchuk ISSN: 2070-1721 Rainwillow

                                                          C. Boulton
                                                     NS-Technologies
                                                          March 2012

A Mixer Control Package for the Media Control Channel Framework

Abstract

This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers.

Status of This Memo

This is an Internet Standards Track document.

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

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

Copyright Notice

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

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

   6.1.1.  Creating a Conference Mixer and Joining a

 8.4.  MIME Media Type Registration for

1 Introduction
2 Conventions and Terminology
3 Control Package Definition
4 Formal Syntax
5 Examples
- 5.1 AS-MS Framework Interaction Examples
6 Security Considerations
7 IANA Considerations
- 7.1 Control Package Registration
- 7.2 URN Sub-Namespace Registration
8 Namespace for Media Control Channel Framework Mixer Package attributes
- 8.1 urn:ietf:params:xml:ns:msc-mixer
- 8.2 Contributors

Introduction

The Media Control Channel Framework RFC6230 provides a generic approach for establishment and reporting capabilities of remotely initiated commands. The Control Framework -- an equivalent term for the Media Control Channel Framework -- utilizes many functions provided by the Session Initiation Protocol (SIP) RFC3261 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 media-mixing requirements documented in the Media Server Control Protocol Requirements document RFC5167; more specifically REQ-MCP-22, REQ-MCP-23, REQ-MCP-24, REQ-MCP-25, REQ-MCP-26, and REQ-MCP-27.

The package provides the major conferencing functionality of SIP media server languages such as MSCML RFC5022 and MSML RFC5707. 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 can be addressed by extensions to this package (through addition of foreign elements or attributes from another namespace) or use of other Control Packages that could build upon this package.

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

The document is organized as follows. Section 3 describes how this Control Package fulfills the requirements for a Media Control Channel Framework Control Package. Section 4 describes the syntax and

semantics of defined elements, including mixer management (Section 4.2) and audit elements (Section 4.3). Section 5 describes an XML schema for these elements and provides extensibility by allowing attributes and elements from other namespaces. Section 6 provides examples of package usage. Section 7 describes important security considerations for use of this Control Package. Section 8 provides information on IANA registration of this Control Package, including its name, XML namespace, and MIME media type.

Conventions and Terminology

In this document, BCP 14 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 an MS, which the AS can 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: An MS Conference provides the media-related mixing

  resources and services for conferences.  In this document, an MS
  Conference is often referred to simply as a conference.

MS Connection: An MS 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 can be audio or
  video and can be bidirectional or unidirectional.

Control Package Definition

This section fulfills the mandatory requirement for information that MUST be specified during the definition of a Control Framework Package, as detailed in Section 8 of RFC6230.

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 8.1.

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

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 4, where the message bodies have the MIME media type defined in Section 8.4. These elements describe requests, responses, and notifications, and all are contained within a root <mscmixer> element (Section 4.1).

In this package, the MS operates as a Control Server in receiving requests from, and sending responses to, the AS (operating as a Control Client). Mixer management requests and responses are defined in Section 4.2. Audit requests and responses are defined in Section 4.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 4.6.

Note that package responses are different from framework response codes. Framework error response codes (see Section 7 of RFC6230) 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 Client in sending event notification to the AS (Control Server). Event notifications (Section 4.2.4) are carried in CONTROL message bodies. The AS MUST respond with a Control Framework 200 response.

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 Appendix A.1 of RFC6230 MUST be supported for media dialogs and conferences.

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

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 a Control Server, the MS receives CONTROL messages with the MIME media type defined in Section 8.4 and a body containing a <mscmixer> element (Section 4.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 4.2.1.1), <modifyconference> (Section 4.2.1.2), <destroyconference> (Section 4.2.1.3), <join> (Section 4.2.2.2), <modifyjoin> (Section 4.2.2.3), and <unjoin> (Section 4.2.2.4) elements.

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

When operating as a Control Client, the MS sends CONTROL messages with the MIME media type defined in Section 8.4 and a body containing a <mscmixer> element (Section 4.1) with a notification </mscmixer>

Audit Elements

The audit elements defined in this section allow the MS to be 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 conference mixer or joins connections and conferences. The AS can then use this information 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 could be used when one AS takes over management of mixers if the AS that created the mixers fails or is no longer available (see the security considerations in Section 7).

<audit>

The <audit> request element is sent to the MS to request information about the capabilities of, and mixers currently managed with, this Control Package. Capabilities include supported conference codecs and video 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 be

  audited.  A valid value is a boolean (see Section 4.7.1).  A value
  of "true" indicates that capability information is to be reported.
  A value of "false" indicates that capability information is not to
  be reported.  The attribute is optional.  The default value is
  "true".

mixers: indicates whether mixers currently managed by the package

  are to be audited.  A valid value is a boolean (see
  Section 4.7.1).  A value of "true" indicates that mixer
  information is 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 identifying a specific conference mixer to

  audit.  It is an error (406) 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 the specified conference mixer is reported. If the 'mixers' attribute has the value "false", then no mixer audit information is reported even if a 'conferenceid' attribute is specified.

The <audit> element has no child elements.

When the MS receives an <audit> request, it MUST reply with a <auditresponse> element (Section 4.3.2) that includes a mandatory attribute describing the status in terms of a numeric code. Response status codes are defined in Section 4.6. If the request is successful, the <auditresponse> contains (depending on attribute values) a <capabilities> element (Section 4.3.2.1) reporting package

capabilities and a <mixers> element (Section 4.3.2.2) reporting managed mixer information. If the MS is 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 specified for a class of error within this section, implementations follow Section 4.6 in determining the appropriate status code for the response.

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

 <audit/>

</mscmixer>

In this example, only capabilities are to be audited:

 <audit mixers="false"/>

</mscmixer>

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

 <audit capabilities="false" conferenceid="conf4"/>

</mscmixer>

<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 4.6.

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

  optional.

desclang: specifies the language used in the value of the 'reason'

  attribute.  A valid value is a language identifier
  (Section 4.7.7).  The attribute is optional.  If not specified,
  the value of the 'desclang' attribute on <mscmixer> (Section 4.1)
  applies.

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

<capabilities>: element describing capabilities of the package (see

  Section 4.3.2.1).  The element is optional.

<mixers>: element describing information about managed mixers (see

  Section 4.3.2.2).  The element is optional.

For example, a successful response to an <audit> request for capabilities and mixer information is as follows:

<auditresponse status="200">
 <capabilities>
  <codecs>
   <codec name="video">
    <subtype>H263</subtype>
   </codec>
   <codec name="video">
    <subtype>H264</subtype>
   </codec>
   <codec name="audio">
    <subtype>PCMU</subtype>
   </codec>
   <codec name="audio">
    <subtype>PCMA</subtype>
   </codec>
  </codecs>
 </capabilities>
 <mixers>
  <conferenceaudit conferenceid="conf1">
   <codecs>
    <codec name="audio">
     <subtype>PCMA</subtype>
    </codec>
   </codecs>
   <participants>
    <participant id="1536067209:913cd14c"/>
   </participants>
  </conferenceaudit>
  <joinaudit id1="1536067209:913cd14c" id2="conf1"/>
  <joinaudit id1="1636067209:113cd14c" id2="1836067209:313cd14c"/>
  <joinaudit id1="1736067209:213cd14c" id2="1936067209:413cd14c"/>
 </mixers>
</auditresponse>

</mscmixer>

<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 4.4) describing codecs available to the

  package.  The element is mandatory.

For example, a fragment describing capabilities is as follows:

 <capabilities>
  <codecs>
   <codec name="video">
    <subtype>H263</subtype>
   </codec>
   <codec name="video">
    <subtype>H264</subtype>
   </codec>
   <codec name="audio">
    <subtype>PCMU</subtype>
   </codec>
   <codec name="audio">
    <subtype>PCMA</subtype>
   </codec>
  </codecs>
 </capabilities>

<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 (zero or more occurrences, any order):

<conferenceaudit>: audit information for a conference mixer

  (Section 4.3.2.2.1).  The element is optional.

<joinaudit>: audit information for a join mixer (Section 4.3.2.2.2).

  The element is optional.

4.3.2.2.1. <conferenceaudit>

The <conferenceaudit> element has the following attribute:

conferenceid: string identifying the conference (see Appendix A.1 of

  RFC6230).  The attribute is mandatory.

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

<codecs> element describing codecs used in the conference. See

  Section 4.4.  The element is optional.

<participants> element listing connections or conferences joined to

  the conference.  See Section 4.3.2.2.1.1.  The element is
  optional.

<video-layout> element describing the active video layout for the

  conference.  See Section 4.2.1.4.2.1.  The element is optional.

For example, a fragment describing a conference that has been created but has no participants is as follows:

A fragment when the same conference has three participants (two connections and another conference) joined to it is as follows:

<codecs>
 <codec name="audio">
  <subtype>PCMU</subtype>
 </codec>
</codecs>
<participants>
  <participant id="connection1"/>
  <participant id="connection2"/>
  <participant id="conference2"/>
</participants>

</conferenceaudit>

4.3.2.2.1.1. <participants>

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

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

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

4.3.2.2.1.1.1. <participant>

The <participant> element describes a participant.

The <participant> element has the following attribute:

id: an identifier for either a connection or a conference. The

  identifier MUST conform to the syntax defined in Appendix A.1 of
  RFC6230.  The attribute is mandatory.

The <participant> element has no children.

4.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 Appendix A.1 of
  RFC6230.  The attribute is mandatory.

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

  identifier MUST conform to the syntax defined in Appendix A.1 of
  RFC6230.  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, is as follows:

<joinaudit id1="1536067209:913cd14" id2="1636067209:413cd14"/>
<joinaudit id1="conference1" id2="conference2"/>

</mixers>

<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 (zero or more occurrences):

<codec>: defines a codec and optionally its policy (Section 4.4.1).

  The element is optional.

For example, a fragment describing two codecs is as follows:

 <codec name="audio">
  <subtype>PCMA</subtype>
 </codec>
 <codec name="video">
   <subtype>H263</subtype>
 </codec>

</codecs>

<codec>

The <codec> element describes a codec. The element is modeled on the <codec> element in the XCON conference information data model (RFC6501) and allows additional information (e.g., rate, speed, etc.) to be specified.

The <codec> element has the following attribute:

name: indicates the type name of the codec's media format as defined

  in [IANA].  A valid value is a "type-name" as defined in Section
  4.2 of RFC4288.  The attribute is mandatory.

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

<subtype>: element whose content model describes the subtype of the

  codec's media format as defined in [IANA].  A valid value is a
  "subtype-name" as defined in Section 4.2 of RFC4288.  The
  element is mandatory.

<params>: element (Section 4.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 is as follows:

<subtype>H263</subtype>

</codec>

A fragment where the <codec> element describes the H264 video codec with additional information about the profile level and packetization mode is as follows:

<subtype>H264</subtype>
<params>
 <param name="profile-level-id">42A01E</param>
 <param name="packetization-mode">0</param>
</params>

</codec>

<params>

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

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

<param>: specifies a parameter name and value (Section 4.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 in-line value of the

  parameter is to be interpreted.  A valid value is a MIME media
  type (see Section 4.7.6).  The attribute is optional.  The default
  value is "text/plain".

encoding: specifies a content-transfer-encoding schema applied to

  the in-line value of the parameter on top of the MIME media type
  specified with the 'type' attribute.  A valid value is a content-
  transfer-encoding schema as defined by the "mechanism" token in
  Section 6.1 of RFC2045.  The attribute is optional.  There is no
  default value.

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

Response Status Codes

This section describes the response codes in Table 1 for the 'status' attribute of mixer management <response> (Section 4.2.3) and <auditresponse> (Section 4.3.2). The MS MUST support the status response codes defined here. All other valid but undefined values are reserved for future use, where new status codes are assigned using the Standards Action process defined in RFC5226. 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.

                       Table 1: Status Codes

Type Definitions

This section defines types referenced in attribute definitions.

Boolean

The value space of boolean is the set {true, false, 1, 0} as defined in Section 3.2.2 of [XMLSchema:Part2]. In accordance with this definition, the concept of false can be lexically represented by the strings "0" and "false" and the concept of true by the strings "1" and "true"; implementations MUST support both styles of lexical representation.

Non-Negative Integer

The value space of non-negative integer is the infinite set {0,1,2,...} as defined in Section 3.3.20 of [XMLSchema:Part2].

Positive Integer

The value space of positive integer is the infinite set {1,2,...} as defined in Section 3.3.25 of [XMLSchema:Part2].

String

A string in the character encoding associated with the XML element as defined in Section 3.2.1 of [XMLSchema:Part2].

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".

MIME Media Type

A string formatted as an IANA MIME media type [MIME.mediatypes]. The ABNF (RFC5234) production for the string is:

media-type = type-name "/" subtype-name *(";" parameter)

parameter = parameter-name "=" value

where "type-name" and "subtype-name" are defined in Section 4.2 of RFC4288, "parameter-name" is defined in Section 4.3 of RFC4288, and "value" is defined in Section 5.1 of RFC2045.

Language Identifier

A language identifier labels information content as being of a particular human language variant. Following the XML specification for language identification [XML], a legal language identifier is identified by a RFC5646 code and matched according to RFC4647.

Formal Syntax

This section defines the XML schema for the Mixer Control Package. The schema is normative.

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 Appendix A.1 of the Control Framework RFC6230.

<?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 (20110104)

  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>

<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>

<xsd:complexType name="Tcore">
 <xsd:annotation>
  <xsd:documentation>
   This type is extended by other (non-mixed) component types to
   allow attributes from other namespaces.
  </xsd:documentation>
 </xsd:annotation>
 <xsd:sequence/>
 <xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType>

<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:attribute name="version" type="version.datatype"
    use="required" />

   <xsd:attribute name="desclang" type="xsd:language"
    default="i-default" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

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

<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" />

<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" />

<xsd:complexType name="destroyconferenceType">
<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:extension>
  </xsd:complexContent>
</xsd:complexType>

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

<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" />

<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="xsd:nonNegativeInteger"
     use="required" />
   <xsd:attribute name="reason" type="xsd:string" />
     <xsd:attribute name="desclang" type="xsd:language"/>
   <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" />

<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:attribute name="desclang" type="xsd:language"/>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

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

<xsd:complexType name="responseType">
 <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="desclang" type="xsd:language"/>
   <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"
    default="1 2 3 4 5 6 7 8 9 0 * # A B C D"/>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

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

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

<xsd:element name="region" type="regionType" />

<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:sequence>
    <xsd:any namespace="##other" minOccurs="0"
     maxOccurs="unbounded" processContents="lax" />
   </xsd:sequence>
   <xsd:attribute name="type" type="audiomix.datatype"
    default="nbest" />
   <xsd:attribute name="n" type="xsd:nonNegativeInteger"
    default="0" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

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

<xsd:complexType name="videoswitchType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
     <xsd:choice>
      <xsd:element name="vas" type="Tcore"/>
      <xsd:element name="controller" type="Tcore"/>
      <xsd:any namespace="##other" processContents="lax" />
    </xsd:choice>
   </xsd:sequence>
   <xsd:attribute name="interval"
    type="xsd:nonNegativeInteger" default="3" />
   <xsd:attribute name="activespeakermix"
    type="xsd:boolean" default="false" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

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

<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" />

<xsd:complexType name="videolayoutType">
<xsd:complexContent>
  <xsd:extension base="Tcore">
   <xsd:sequence>
    <xsd:choice>
      <xsd:element name="single-view" type="Tcore"/>
      <xsd:element name="dual-view" type="Tcore"/>
      <xsd:element name="dual-view-crop" type="Tcore"/>
      <xsd:element name="dual-view-2x1" type="Tcore"/>
      <xsd:element name="dual-view-2x1-crop" type="Tcore"/>
      <xsd:element name="quad-view" type="Tcore"/>
      <xsd:element name="multiple-3x3" type="Tcore"/>
      <xsd:element name="multiple-4x4" type="Tcore"/>
      <xsd:element name="multiple-5x1" type="Tcore"/>
      <xsd:any namespace="##other" processContents="lax" />
    </xsd:choice>
   </xsd:sequence>
  <xsd:attribute name="min-participants"
    type="xsd:positiveInteger" default="1" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

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

<xsd:complexType name="auditType">
 <xsd:complexContent>
  <xsd:extension base="Tcore">
  <xsd:sequence>
  <xsd:any namespace="##other" minOccurs="0"
   maxOccurs="unbounded" processContents="lax" />
  </xsd:sequence>
   <xsd:attribute name="capabilities"

    type="xsd:boolean" default="true" />
   <xsd:attribute name="mixers" type="xsd:boolean"
    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:attribute name="desclang" type="xsd:language"/>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

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

<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" />

<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" />

<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" />

<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" />

<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" />

<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" />

<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" />

<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:attribute name="name" type="xsd:string"
    use="required" />
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

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

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

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

<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" />

<xsd:complexType name="paramType" mixed="true">
 <xsd:sequence/>
 <xsd:attribute name="name" type="xsd:string" use="required" />
 <xsd:attribute name="type" type="mime.datatype"
 default="text/plain" />
    <xsd:attribute name="encoding" type="xsd:string"/>
</xsd:complexType>

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

<xsd:simpleType name="version.datatype">

 <xsd:restriction base="xsd:NMTOKEN">
  <xsd:enumeration value="1.0" />
 </xsd:restriction>
</xsd:simpleType>

<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="mime.datatype">
 <xsd:restriction base="xsd:string" />
</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 10: Mixer Package XML Schema

Examples

This section provides examples of the Mixer Control Package.

AS-MS Framework Interaction Examples

The following example assumes a Control Channel has been established and synced as described in the Media Control Channel Framework (RFC6230).

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

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                               |
            |  ---------------------------------------->  |

Receiving Active Talker Notifications

An active talker notification event is sent by the MS.

         Application Server (AS)                   Media Server (MS)
            |                                             |
            |       (1) CONTROL:

</mscmixer>

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

<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:

<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:

<destroyconference conferenceid="conf1"/>

</mscmixer>

If the MS is able to destroy the conference conf1, it sends a 200 response:

<response status="200" conferenceid="conf1"/>

</mscmixer>

For each participant attached to the conference when it is destroyed, the MS sends an unjoin notification event:

</mscmixer>

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

</mscmixer>

Bridging Connections

The mixer package can 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 bidirectional audio:

<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:

<response status="200"/>

</mscmixer>

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

<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:

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

Video Conferencing

In this example, an audio-video conference is created where the loudest participant has the most prominent region in the video layout.

The AS sends a request to create an audio-video conference:

<createconference conferenceid="conf2">
 <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-layout min-participants="5"><multiple-5x1/></video-layout>
 </video-layouts>
 <video-switch><vas/></video-switch>
</createconference>

</mscmixer>

In this configuration, the conference uses a nbest audio mixing policy and a <vas/> video-switching policy, so that the loudest speaker receives the most prominent region in the layout. Multiple video layouts are specified and the 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 joins, the video layout automatically switches to a multiple-5x1 layout (Figure 9), again with the most active speaker in region 1.

The AS can manipulate which participants are displayed in the remaining regions. For example, it could force an existing conference participant to be displayed in region 2:

<modifyjoin id1="1536067209:913cd14c" id2="conf2">
 <stream media="video">
  <region>2</region>
 </stream>
</modifyjoin>

</mscmixer>

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 12 of the Media Control Channel Framework (RFC6230), including transport- level protection, Control Channel policy management, and session establishment. In addition, implementations MUST address security,

confidentiality, and integrity of User Agent sessions with the MS, both in terms of SIP signaling and the associated RTP media flow; see RFC6230 for further details on this topic.

Adequate transport protection and authentication are critical, especially when the implementation is deployed in open networks. If the implementation fails to correctly address these issues, it risks exposure to malicious attacks, including (but not limited to):

Denial of Service: An attacker could insert a request message into

  the transport stream causing specific conferences or join mixers
  on the MS to be destroyed.  For example, <destroyconference
  conferenceid="XXXX">, where the value of "XXXX" could be guessed
  or discovered by auditing active mixers on the MS using an <audit>
  request.  Likewise, an attacker could impersonate the MS and
  insert error responses into the transport stream thereby denying
  the AS access to package capabilities.

Resource Exhaustion: An attacker could insert into the Control

  Channel new request messages (or modify existing ones) with, for
  instance, <createconference> elements causing large numbers of
  conference mixer resources to be allocated.  At some point, this
  will exhaust the number of conference mixers that the MS is able
  to allocate.

The Media Control Channel Framework permits additional policy management (beyond that specified for the Media Control Channel Framework), including resource access and Control Channel usage, to be specified at the Control Package level. (See Section 12.3 of RFC6230.)

Since creation of conference and join mixers is associated with media-mixing resources on the MS, the security policy for this Control Package needs to address how such mixers are securely managed across more than one Control Channel. Such a security policy is only useful for secure, confidential, and integrity-protected channels. The identity of Control Channels is determined by the channel identifier, i.e., the value of the 'cfw-id' attribute in the SDP and Dialog-ID header in the channel protocol (see RFC6230). Channels are the same if they have the same identifier; otherwise, they are different. This Control Package imposes the following additional security policies:

Responses: The MS MUST only send a response to a mixer management or

  audit request using the same Control Channel as the one used to
  send the request.

Notifications: The MS MUST only send notification events for

  conference and join mixers using the same Control Channel as it
  received the request creating the mixer.

Auditing: The MS MUST only provide audit information about

  conference and join mixers that have been created on the same
  Control Channel as the one upon which the <audit> request is sent.
  For example, if a join between two connections has been created on
  one channel, then a request on another channel to audit all mixers
  -- <audit mixers="true"/> -- would not report on this join mixer.

Rejection: The MS SHOULD reject requests to audit or manipulate an

  existing conference or join mixer on the MS if the channel is not
  the same as the one used when the mixer was created.  The MS
  rejects a request by sending a Control Framework 403 response (see
  Sections 7.4 and 12.3 of RFC6230).  For example, if a channel
  with identifier 'cfw1234' has been used to send a request to
  create a particular conference and the MS receives on channel
  'cfw98969' a request to audit or destroy this particular
  conference, then the MS sends a Control Framework 403 response.

There can be valid reasons why an implementation does not reject an audit or mixer manipulation request on a different channel from the one that created the mixer. For example, a system administrator might require a separate channel to audit mixer resources created by system users and to terminate mixers consuming excessive system resources. Alternatively, a system monitor or resource broker might require a separate channel to audit mixers managed by this package on a MS. However, the full implications need to be understood by the implementation and carefully weighed before accepting these reasons as valid. If the reasons are not valid in their particular circumstances, the MS rejects such requests.

There can also be valid reasons for 'channel handover' including high availability support or when one AS needs to take over management of mixers after the AS that created them has failed. This could be achieved by the Control Channels using the same channel identifier, one after another. For example, assume a channel is created with the identifier 'cfw1234', and the channel is used to create mixers on the MS. This channel (and associated SIP dialog) then terminates due to a failure on the AS. As permitted by the Control Framework, the channel identifier 'cfw1234' could then be reused so that another channel is created with the same identifier 'cfw1234', allowing it to 'take over' management of the mixers on the MS. Again, the implementation needs to understand the full implications and carefully weigh them before accepting these reasons as valid. If the reasons are not valid for their particular circumstances, the MS uses

the appropriate SIP mechanisms to prevent session establishment when the same channel identifier is used in setting up another Control Channel (see Section 4 of RFC6230).

IANA Considerations

Per this specification, IANA has registered a new Media Control Channel Framework Package, a new XML namespace, a new XML schema, and a new MIME type.

IANA has further created a new registry for the response codes for the MEDIACTRL Mixer Control Package, RFC 6505.

Control Package Registration

This section registers a new Media Control Channel Framework package, per the instructions in Section 13.1 of RFC6230.

  To: [email protected]
  Subject: Registration of new Channel Framework package
  Package Name: msc-mixer/1.0
  Published Specification(s): RFC 6505
  Person & email address to contact for further information:
     IETF MEDIACTRL working group ([email protected]),
     Scott McGlashan ([email protected]).

URN Sub-Namespace Registration

This section registers a new XML namespace, "urn:ietf:params:xml:ns:msc-mixer", per the guidelines in RFC 3688 RFC3688.

     URI: urn:ietf:params:xml:ns:msc-mixer
     Registrant Contact:
        IETF MEDIACTRL working group ([email protected]),
        Scott McGlashan ([email protected]).

     XML:
        BEGIN
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
            "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
         <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
           <title>Media Control Channel Framework Mixer
                  Package attributes</title>
          </head>
          <body>

Namespace for Media Control Channel Framework Mixer Package attributes

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

See <a href="http://www.rfc-editor.org/rfc/rfc6505.txt"> RFC 6505</a>.

          </body>
         </html>
        END

XML Schema Registration

This section registers an XML schema as per the guidelines in RFC 3688 RFC3688.

  URI:  urn:ietf:params:xml:schema:msc-mixer
  Registrant Contact:
     IETF MEDIACTRL working group ([email protected]),
     Scott McGlashan ([email protected]).
  Schema:  The XML for this schema can be found in
     Section 5 of this document.

MIME Media Type Registration for 'application/msc-mixer+xml'

This section registers the "application/msc-mixer+xml" MIME type.

To: [email protected] Subject: Registration of MIME media type

         application/msc-mixer+xml

MIME media type name: application MIME subtype name: msc-mixer+xml Required parameters: (none) Optional parameters: charset

  Indicates the character encoding of enclosed XML.  Default is
  UTF-8.

Encoding considerations: Uses XML, which can employ 8-bit

  characters, depending on the character encoding used.  See RFC
  3023 RFC3023, Section 3.2.

Security considerations: No known security considerations outside

  of those provided by the Media Control Channel Framework Mixer
  Package.

Interoperability considerations: This content type provides

  constructs for the Media Control Channel Framework Mixer Package.

Published specification: RFC 6505 Applications that use this media type: Implementations of

  the Media Control Channel Framework Mixer package.

Additional Information:

  Magic Number(s): (none)
  File extension(s): (none)
  Macintosh File Type Code(s): (none)

Person & email address to contact for further information:

  Scott McGlashan <[email protected]>

Intended usage: LIMITED USE Author/Change controller: The IETF Other information: None.

Mixer Control Package Status Code Registration

This section creates an IANA registry for the response codes for the MEDIACTRL Mixer Control Package. New status codes are assigned using the Standards Action process defined in RFC 5226 RFC5226. The initial population of the registry is defined in Section 4.6.

The format of this registry is as follows:

  Table 2: Fields for Mixer Control Package Status Code Registry

Contributors

Asher Shiratzky provided valuable support and contributions to early draft 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, diagrams, and text to this document.

10. Acknowledgments

The authors would like to thank Steve Buko and Stephane Bastien for expert reviews of this work.

Shawn Emery carried out a thorough security review.

11. References

11.1. Normative References

RFC2045 Freed, N. and N. Borenstein, "Multipurpose

                  Internet Mail Extensions (MIME) Part One: Format
                  of Internet Message Bodies", RFC 2045,
                  November 1996.

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.

RFC3688 Mealling, M., "The IETF XML Registry", BCP 81,

                  RFC 3688, January 2004.

RFC4288 Freed, N. and J. Klensin, "Media Type

                  Specifications and Registration Procedures",
                  BCP 13, RFC 4288, December 2005.

RFC4574 Levin, O. and G. Camarillo, "The Session

                  Description Protocol (SDP) Label Attribute",
                  RFC 4574, August 2006.

RFC4647 Phillips, A. and M. Davis, "Matching of Language

                  Tags", BCP 47, RFC 4647, September 2006.

RFC5226 Narten, T. and H. Alvestrand, "Guidelines for

                  Writing an IANA Considerations Section in RFCs",
                  BCP 26, RFC 5226, May 2008.

RFC5234 Crocker, D. and P. Overell, "Augmented BNF for

                  Syntax Specifications: ABNF", STD 68, RFC 5234,
                  January 2008.

RFC5646 Phillips, A. and M. Davis, "Tags for Identifying

                  Languages", BCP 47, RFC 5646, September 2009.

RFC6230 Boulton, C., Melanchuk, T., and S. McGlashan,

                  "Media Control Channel Framework", RFC 6230,
                  May 2011.

RFC6501 Novo, O., Camarillo, G., Morgan, D., and J.

                  Urpalainen, "Conference Information Data Model for
                  Centralized Conferencing (XCON)", RFC 6501,
                  March 2012.

[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler,

                  E., and F. Yergeau, "Extensible Markup Language
                  (XML) 1.0 (Fifth Edition)", World Wide Web
                  Consortium Recommendation REC-xml-20081126,
                  November 2008,
                  <http://www.w3.org/TR/2008/REC-xml-20081126>.

[XMLSchema:Part2] Biron, P. and A. Malhotra, "XML Schema Part 2:

                  Datatypes Second Edition", W3C Recommendation,
                  October 2004.

11.2. Informative References

[IANA] IANA, "RTP Payload Types",

                  <http://www.iana.org/assignments/rtp-parameters>.

[MIME.mediatypes] IANA, "MIME Media Types",

                  <http://www.iana.org/assignments/media-types>.

RFC2277 Alvestrand, H., "IETF Policy on Character Sets and

                  Languages", BCP 18, RFC 2277, January 1998.

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.

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.

RFC5707 Saleem, A., Xin, Y., and G. Sharratt, "Media

                  Server Markup Language (MSML)", RFC 5707,
                  February 2010.

Authors' Addresses

Scott McGlashan Hewlett-Packard

EMail: [email protected]

Tim Melanchuk Rainwillow

EMail: [email protected]

Chris Boulton NS-Technologies

EMail: [email protected]

Anonymous

Search

RFC6505

Contents

Introduction

Conventions and Terminology

Control Package Definition

Control Package Name

Framework Message Usage

Common XML Support

CONTROL Message Body

Audit Elements

<audit>

<auditresponse>

<capabilities>

<mixers>

<codecs>

<codec>

<params>

<param>

Response Status Codes

Type Definitions

Boolean

Non-Negative Integer

Positive Integer

String

Time Designation

MIME Media Type

Language Identifier

Formal Syntax

Examples

AS-MS Framework Interaction Examples

Creating a Conference Mixer and Joining a Participant

Receiving Active Talker Notifications

Bridging Connections

Video Conferencing

Security Considerations

IANA Considerations

Control Package Registration

URN Sub-Namespace Registration

Namespace for Media Control Channel Framework Mixer Package attributes

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

XML Schema Registration

MIME Media Type Registration for 'application/msc-mixer+xml'

Mixer Control Package Status Code Registration

Contributors

Navigation

Wiki tools

Page tools

Categories