diff options
Diffstat (limited to 'doc/rfc/rfc6505.txt')
| -rw-r--r-- | doc/rfc/rfc6505.txt | 4987 |
1 files changed, 4987 insertions, 0 deletions
diff --git a/doc/rfc/rfc6505.txt b/doc/rfc/rfc6505.txt new file mode 100644 index 0000000..229d20b --- /dev/null +++ b/doc/rfc/rfc6505.txt @@ -0,0 +1,4987 @@ + + + + + + +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 + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +McGlashan, et al. Standards Track [Page 1] + +RFC 6505 Mixer Control Package March 2012 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 + 3. Control Package Definition . . . . . . . . . . . . . . . . . . 6 + 3.1. Control Package Name . . . . . . . . . . . . . . . . . . . 6 + 3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 6 + 3.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 7 + 3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 7 + 3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 7 + 3.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. <mscmixer> . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.2. Mixer Elements . . . . . . . . . . . . . . . . . . . . . . 11 + 4.2.1. Conference Elements . . . . . . . . . . . . . . . . . 12 + 4.2.1.1. <createconference> . . . . . . . . . . . . . . . . 12 + 4.2.1.2. <modifyconference> . . . . . . . . . . . . . . . . 14 + 4.2.1.3. <destroyconference> . . . . . . . . . . . . . . . 16 + 4.2.1.4. Conference Configuration . . . . . . . . . . . . . 16 + 4.2.1.4.1. <audio-mixing> . . . . . . . . . . . . . . . . 16 + 4.2.1.4.2. <video-layouts> . . . . . . . . . . . . . . . 17 + 4.2.1.4.2.1. <video-layout> . . . . . . . . . . . . . . 18 + 4.2.1.4.3. <video-switch> . . . . . . . . . . . . . . . . 24 + 4.2.1.4.3.1. Priority Assignment . . . . . . . . . . . 26 + 4.2.1.4.4. <subscribe> . . . . . . . . . . . . . . . . . 27 + 4.2.1.4.4.1. <active-talkers-sub> . . . . . . . . . . . 27 + 4.2.2. Joining Elements . . . . . . . . . . . . . . . . . . . 28 + 4.2.2.1. Joining Model . . . . . . . . . . . . . . . . . . 28 + 4.2.2.2. <join> . . . . . . . . . . . . . . . . . . . . . . 29 + 4.2.2.3. <modifyjoin> . . . . . . . . . . . . . . . . . . . 32 + 4.2.2.4. <unjoin> . . . . . . . . . . . . . . . . . . . . . 34 + 4.2.2.5. <stream> . . . . . . . . . . . . . . . . . . . . . 35 + 4.2.2.5.1. <volume> . . . . . . . . . . . . . . . . . . . 37 + 4.2.2.5.2. <clamp> . . . . . . . . . . . . . . . . . . . 38 + 4.2.2.5.3. <region> . . . . . . . . . . . . . . . . . . . 38 + + + +McGlashan, et al. Standards Track [Page 2] + +RFC 6505 Mixer Control Package March 2012 + + + 4.2.2.5.4. <priority> . . . . . . . . . . . . . . . . . . 38 + 4.2.3. <response> . . . . . . . . . . . . . . . . . . . . . . 38 + 4.2.4. <event> . . . . . . . . . . . . . . . . . . . . . . . 39 + 4.2.4.1. <active-talkers-notify> . . . . . . . . . . . . . 39 + 4.2.4.1.1. <active-talker> . . . . . . . . . . . . . . . 40 + 4.2.4.2. <unjoin-notify> . . . . . . . . . . . . . . . . . 40 + 4.2.4.3. <conferenceexit> . . . . . . . . . . . . . . . . . 41 + 4.3. Audit Elements . . . . . . . . . . . . . . . . . . . . . . 42 + 4.3.1. <audit> . . . . . . . . . . . . . . . . . . . . . . . 43 + 4.3.2. <auditresponse> . . . . . . . . . . . . . . . . . . . 44 + 4.3.2.1. <capabilities> . . . . . . . . . . . . . . . . . . 46 + 4.3.2.2. <mixers> . . . . . . . . . . . . . . . . . . . . . 46 + 4.3.2.2.1. <conferenceaudit> . . . . . . . . . . . . . . 47 + 4.3.2.2.1.1. <participants> . . . . . . . . . . . . . . 47 + 4.3.2.2.1.1.1. <participant> . . . . . . . . . . . . 48 + 4.3.2.2.2. <joinaudit> . . . . . . . . . . . . . . . . . 48 + 4.4. <codecs> . . . . . . . . . . . . . . . . . . . . . . . . . 48 + 4.4.1. <codec> . . . . . . . . . . . . . . . . . . . . . . . 49 + 4.5. <params> . . . . . . . . . . . . . . . . . . . . . . . . . 50 + 4.5.1. <param> . . . . . . . . . . . . . . . . . . . . . . . 50 + 4.6. Response Status Codes . . . . . . . . . . . . . . . . . . 51 + 4.7. Type Definitions . . . . . . . . . . . . . . . . . . . . . 55 + 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 56 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 + 6.1. AS-MS Framework Interaction Examples . . . . . . . . . . . 75 + 6.1.1. Creating a Conference Mixer and Joining a + Participant . . . . . . . . . . . . . . . . . . . . . 75 + 6.1.2. Receiving Active Talker Notifications . . . . . . . . 76 + 6.1.3. Conference Termination . . . . . . . . . . . . . . . . 76 + 6.2. Mixing Examples . . . . . . . . . . . . . . . . . . . . . 76 + 6.2.1. Audio Conferencing . . . . . . . . . . . . . . . . . . 77 + 6.2.2. Bridging Connections . . . . . . . . . . . . . . . . . 79 + 6.2.3. Video Conferencing . . . . . . . . . . . . . . . . . . 80 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 81 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 + 8.1. Control Package Registration . . . . . . . . . . . . . . . 84 + 8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 84 + 8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 85 + 8.4. MIME Media Type Registration for + 'application/msc-mixer+xml' . . . . . . . . . . . . . . . 85 + 8.5. Mixer Control Package Status Code Registration . . . . . . 86 + 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 86 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 87 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 87 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 87 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 88 + + + + + +McGlashan, et al. Standards Track [Page 3] + +RFC 6505 Mixer Control Package March 2012 + + +1. 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 + + + +McGlashan, et al. Standards Track [Page 4] + +RFC 6505 Mixer Control Package March 2012 + + + 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. + +2. 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. + + + + + +McGlashan, et al. Standards Track [Page 5] + +RFC 6505 Mixer Control Package March 2012 + + +3. 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]. + +3.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 8.1. + + Since this is the initial ("1.0") version of the Control Package, + there are no backwards compatibility issues to address. + +3.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 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. + + + + + +McGlashan, et al. Standards Track [Page 6] + +RFC 6505 Mixer Control Package March 2012 + + +3.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 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. + +3.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 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 <event> child + element (Section 4.2.4). + +3.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 to indicate that no report package body is required. + This section indicates the location of detailed syntax definitions + and semantics for the appropriate body types. + + + + +McGlashan, et al. Standards Track [Page 7] + +RFC 6505 Mixer Control Package March 2012 + + + When operating as a Control Server, the MS sends REPORT bodies with + the MIME media type defined in Section 8.4 and a <mscmixer> element + with a response child element. The response element for mixer + management requests is a <response> element (Section 4.2.3). The + response element for an audit request is a <auditresponse> element + (Section 4.3.2). + +3.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 Package supports auditing of package capabilities and + mixers on the MS. An audit request is carried in a CONTROL message + and an audit response in a REPORT message (or a 200 response to the + CONTROL if it can execute the audit in time). + + The syntax and semantics of audit request and response elements are + defined in Section 4.3. + +3.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 6. + +4. Element Definitions + + This section defines the XML elements for this package. The elements + are defined in the XML namespace specified in Section 8.2. + + The root element is <mscmixer> (Section 4.1). All other XML elements + (requests, responses, and notification elements) are contained within + it. Child elements describe mixer management (Section 4.2) and audit + (Section 4.3) functionality. Response status codes are defined in + Section 4.6 and type definitions in Section 4.7. + + Implementation of this Control Package MUST address the security + considerations described in Section 7. + + Implementation of this Control Package MUST adhere to the syntax and + semantics of XML elements defined in this section and the schema + (Section 5). The XML schema supports extensibility by allowing + attributes and elements from other namespaces. Implementations MAY + + + +McGlashan, et al. Standards Track [Page 8] + +RFC 6505 Mixer Control Package March 2012 + + + 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 sends a 428 response (Section 4.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. + + Some elements in this Control Package contain attributes whose value + is descriptive text primarily for diagnostic use. The implementation + can indicated the language used in the descriptive text by means of a + 'desclang' attribute [RFC2277]. The 'desclang' attribute can appear + on the root element as well as selected subordinate elements (see + Section 4.1). The 'desclang' attribute value on the root element + applies to all 'desclang' attributes in subordinate elements unless + the subordinate element has an explicit 'desclang' attribute that + overrides it. + + Usage examples are provided in Section 6. + +4.1. <mscmixer> + + The <mscmixer> element has the following attributes (in addition to + standard XML 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. + + desclang: specifies the language used in descriptive text attributes + of subordinate elements (unless the subordinate element provides a + 'desclang' attribute that overrides the value for its descriptive + text attributes). The descriptive text attributes on subordinate + elements include: the 'reason' attribute on <response> + (Section 4.2.3), <unjoin-notify> (Section 4.2.4.2), + <conferenceexit> (Section 4.2.4.3), and <auditresponse> + (Section 4.3.2). A valid value is a language identifier + (Section 4.7.7). The attribute is optional. The default value is + "i-default" (BCP 47 [RFC5646]). + + + + + + + + + + +McGlashan, et al. Standards Track [Page 9] + +RFC 6505 Mixer Control Package March 2012 + + + The <mscmixer> element has the following defined child elements, only + one of which can occur: + + 1. mixer management elements defined in Section 4.2: + + <createconference>: create and configure a new conference mixer. + See Section 4.2.1.1 + + <modifyconference>: modify the configuration of an existing + conference mixer. See Section 4.2.1.2 + + <destroyconference>: destroy an existing conference mixer. See + Section 4.2.1.3 + + <join>: create and configure media streams between connections + and/or conferences (for example, add a participant to a + conference). See Section 4.2.2.2 + + <modifyjoin>: modify the configuration of joined media streams. + See Section 4.2.2.3 + + <unjoin>: delete a media stream (for example, remove a + participant from a conference). See Section 4.2.2.4 + + <response>: response to a mixer request. See Section 4.2.3 + + <event>: mixer or subscription notification. See Section 4.2.4 + + 2. audit elements defined in Section 4.3: + + <audit>: audit package capabilities and managed mixers. See + Section 4.3.1 + + <auditresponse>: response to an audit request. See + Section 4.3.2 + + For example, a request to the MS to create a conference mixer is as + follows: + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <createconference/> + </mscmixer> + + And a response from the MS that the conference was successfully + created is as follows: + + + + + + +McGlashan, et al. Standards Track [Page 10] + +RFC 6505 Mixer Control Package March 2012 + + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer" + desclang="en"> + <response status="200" conferenceid="conference1" + reason="conference created"/> + </mscmixer> + +4.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 4.2.1.1 + + <modifyconference>: modify the configuration of an existing + conference mixer. See Section 4.2.1.2 + + <destroyconference>: destroy an existing conference mixer. See + Section 4.2.1.3 + + <join>: create and configure media streams between connections + and/or conferences (for example, add a participant to a + conference). See Section 4.2.2.2 + + <modifyjoin>: modify the configuration of joined media streams. See + Section 4.2.2.3 + + <unjoin>: delete a media stream (for example, remove a participant + from a conference). See Section 4.2.2.4 + + Responses from the MS describe the status of the requested operation. + Responses are specified in a <response> element (Section 4.2.3) that + includes a mandatory attribute describing the status in terms of a + numeric code. Response status codes are defined in Section 4.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 mixer + operation (in whole or in part), then the request has failed: the MS + MUST ensure that no part of the requested mixer operation is carried + out, 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. + + + +McGlashan, et al. Standards Track [Page 11] + +RFC 6505 Mixer Control Package March 2012 + + + 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 4.2.4). + +4.2.1. Conference Elements + +4.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 4.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 4.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 4.4). If codecs are specified, then they + impose limitations on media capability when the MS attempts to + join the conference to other entities (see Sections 4.2.2.2 and + 4.2.2.3). The element is optional. + + <audio-mixing>: an element to configure the audio mixing + characteristics of a conference (see Section 4.2.1.4.1). The + element is optional. + + <video-layouts>: an element to configure the video layouts of a + conference (see Section 4.2.1.4.2). The element is optional. + + + + + + +McGlashan, et al. Standards Track [Page 12] + +RFC 6505 Mixer Control Package March 2012 + + + <video-switch>: an element to configure the video switch policy for + the layout of a conference (see Section 4.2.1.4.3). The element + is optional. + + <subscribe>: an element to request subscription to conference + events. (see Section 4.2.1.4.4). The element is optional. + + If the 'conferenceid' attribute specifies a value that is already + used by an existing conference, the MS reports an error (405) and + MUST NOT create a new conference and MUST NOT affect the existing + conference. + + If the MS is unable to configure the conference according to + specified 'reserved-talkers' or 'reserved-listeners' attributes, the + MS reports an error (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 reports an error (421) and + MUST NOT create the conference. + + If the MS is unable to configure the conference according to a + specified <video-layouts> element, the MS reports an error (423) and + MUST NOT create the conference. + + If the MS is unable to configure the conference according to a + specified <video-switch> element, the MS reports an error (424) and + MUST NOT create the conference. + + If the MS is unable to configure the conference according to a + specified <codecs> element, the MS reports an error (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 4.2.3). + + For example, a request to create an audio video conference mixer with + specified codecs, video layout, video switch, and subscription is as + follows: + + + + + + + + + + + + + +McGlashan, et al. Standards Track [Page 13] + +RFC 6505 Mixer Control Package March 2012 + + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <createconference conferenceid="conference1" + reserved-talkers="1" reserved-listeners="10"> + <codecs> + <codec name="video"> + <subtype>H264</subtype> + </codec> + <codec name="audio"> + <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 interval="5"><vas/></video-switch> + <subscribe> + <active-talkers-sub interval="4"/> + </subscribe> + </createconference> + </mscmixer> + + A response from the MS if the conference was successfully created is + as follows: + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <response status="200" conferenceid="conference1"/> + </mscmixer> + + Alternatively, a response if the MS could not create the conference + due to a lack of support for the H264 codec is as follows: + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <response status="425" conferenceid="conference1" + reason="H264 codec not supported"/> + </mscmixer> + +4.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 attribute: + + conferenceid: string indicating the name of the conference to + modify. This attribute is mandatory. + + + +McGlashan, et al. Standards Track [Page 14] + +RFC 6505 Mixer Control Package March 2012 + + + The <modifyconference> element has the following sequence of child + elements (one or more): + + <codecs>: an element to configure the codecs supported by the + conference (see Section 4.4). If codecs are specified, then they + impose limitations in media capability when the MS attempts to + join the conference to other entities (see Sections 4.2.2.2 and + 4.2.2.3). Existing conference participants are unaffected by any + policy change. The element is optional. + + <audio-mixing>: an element to configure the audio mixing + characteristics of a conference (see Section 4.2.1.4.1). The + element is optional. + + <video-layouts>: an element to configure the video layouts of a + conference (see Section 4.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 4.2.1.4.3). The element + is optional. + + <subscribe>: an element to request subscription to conference + events. (see Section 4.2.1.4.4). The element is optional. + + If the 'conferenceid' attribute specifies the name of a conference + that does not exist, the MS reports an error (406). + + If the MS is unable to configure the conference according to a + specified <audio-mixing> element, the MS reports an error (421) and + MUST NOT modify the conference in any way. + + If the MS is unable to configure the conference according to a + specified <video-layouts> element, the MS reports an error (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 reports an error (424) and + MUST NOT modify the conference in any way. + + If the MS is unable to configure the conference according to a + specified <codecs> element, the MS reports an error (425) and MUST + NOT modify the conference. + + When a MS has finished processing a <modifyconference> request, it + MUST reply with an appropriate <response> element (Section 4.2.3). + + + + + + +McGlashan, et al. Standards Track [Page 15] + +RFC 6505 Mixer Control Package March 2012 + + +4.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 attribute: + + 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 + that does not exist, the MS reports an error (406). + + When a MS has finished processing a <destroyconference> request, it + MUST reply with an appropriate <response> element (Section 4.2.3). + + Successfully destroying the conference (status code 200) will result + in all connection or conference participants being removed from the + conference mixer, <unjoin-notify> notification events + (Section 4.2.4.2) being sent for each conference participant, and a + <conferenceexit> notification event (Section 4.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. + +4.2.1.4. Conference Configuration + + The elements in this section are used to establish and modify the + configuration of conferences. + +4.2.1.4.1. <audio-mixing> + + The <audio-mixing> element defines the configuration of the + conference audio mix. + + The <audio-mixing> element has the following attributes: + + type: is a string indicating the audio stream mixing policy. + Defined values are: "nbest" (where the N best (loudest) + 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 attribute is + optional. The default value is "nbest". + + + + + + +McGlashan, et al. Standards Track [Page 16] + +RFC 6505 Mixer Control Package March 2012 + + + n: indicates the number of eligible participants included in the + conference audio mix. An eligible participant is a participant + who contributes audio to the conference. Inclusion is based on + having the greatest audio energy. A valid value is a non-negative + integer (see Section 4.7.2). A value of 0 indicates that all + participants contributing audio to the conference are included in + the audio mix. The default value is 0. The element is optional. + + If the 'type' attribute does not have the value "nbest", the MS + ignores the 'n' attribute. + + The <audio-mixing> element has no child elements. + + For example, a fragment where the audio-mixing policy is set to + "nbest" with 3 participants to be included is as follows: + + <audio-mixing type="nbest" n="3"/> + + If the conference had 200 participants of whom 30 contributed audio, + then there would be 30 eligible participants for the audio mix. Of + these, the 3 loudest participants would have their audio included in + the conference. + +4.2.1.4.2. <video-layouts> + + The <video-layouts> element describes 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 (one or more): + + <video-layout>: element describing a video layout + (Section 4.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 reports an 423 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 + + + +McGlashan, et al. Standards Track [Page 17] + +RFC 6505 Mixer Control Package March 2012 + + + value of the 'min-participants' attribute for any other <video- + layout> element. An MS reports an error (400) 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 4.2.1.4.3). + + For example, a fragment describing a single layout is as follows: + + <video-layouts> + <video-layout><single-view/></video-layout> + </video-layouts> + + A fragment describing a sequence of layouts is as follows: + + <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-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 participants, the quad- + view layout is used. When the conference has five or more + participants, the multiple-3x3 layout is used. + +4.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 streams are displayed. + + The <video-layout> element has the following attribute: + + 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 4.7.3). The attribute is optional. + The default value is 1. + + The <video-layout> element has one child element specifying the video + layout. An MS MAY support the predefined video layouts defined in + the conference information data model for centralized conferencing + + + +McGlashan, et al. Standards Track [Page 18] + +RFC 6505 Mixer Control Package March 2012 + + + (XCON) [RFC6501]: <single-view>, <dual-view>, <dual-view-crop>, + <dual-view-2x1>, <dual-view-2x1-crop>, <quad-view>, <multiple-3x3>, + <multiple-4x4>, and <multiple-5x1>. + + The MS MAY support other video layouts. Non-XCON layouts MUST be + specified using an element from a namespace other than the one used + in this specification, for example: + + <video-layout> + <mylayout xmlns='http://example.com/foo'>my-single-view</mylayout> + </video-layout> + + If the MS does not support the specified video layout configuration, + then the MS reports a 423 error (Section 4.6) in the response to the + request element containing the <video-layout> element. + + Each video layout has associated with it one or more regions. The + XCON layouts are associated with the following named regions: + + <single-view/>: layout with one stream in a single region as shown + in Figure 1. + + +-----------+ + | | + | | + | 1 | + | | + | | + +-----------+ + + Figure 1: single-view video layout + + <dual-view/>: layout presenting two streams side-by-side in two + regions as shown in Figure 2. The MS MUST NOT alter the aspect + ratio of each stream to fit the region, and hence the MS might + need to blank out part of each region. + + +-----------+-----------+ + | | | + | | | + | 1 | 2 | + | | | + | | | + +-----------+-----------+ + + Figure 2: dual-view video layout + + + + + +McGlashan, et al. Standards Track [Page 19] + +RFC 6505 Mixer Control Package March 2012 + + + <dual-view-crop/>: layout presenting two streams side-by-side in two + regions as shown in Figure 3. The MS MUST alter the aspect ratio + of each stream to fit its region so that no blanking is required. + + +-----------+-----------+ + | | | + | | | + | 1 | 2 | + | | | + | | | + +-----------+-----------+ + + Figure 3: dual-view-crop video layout + + <dual-view-2x1/>: layout presenting two streams, one above the + other, in two regions as shown in Figure 4. The MS MUST NOT alter + the aspect ratio of each stream to fit its region, and hence the + MS might need to blank out part of each region. + + +-----------+ + | | + | | + | 1 | + | | + | | + +-----------+ + | | + | | + | 2 | + | | + | | + +-----------+ + + Figure 4: dual-view-2x1 video layout + + + + + + + + + + + + + + + + + +McGlashan, et al. Standards Track [Page 20] + +RFC 6505 Mixer Control Package March 2012 + + + <dual-view-2x1-crop/>: layout presenting two streams one above the + other in two regions as shown in Figure 5. The MS MUST alter the + aspect ratio of each stream to fit its region so that no blanking + is required. + + +-----------+ + | | + | | + | 1 | + | | + | | + +-----------+ + | | + | | + | 2 | + | | + | | + +-----------+ + + Figure 5: dual-view-2x1-crop video layout + + <quad-view/>: layout presenting four equal-sized regions in a 2x2 + layout as shown in Figure 6. Typically, the aspect ratio of the + streams is preserved, so blanking is required. + + +-----------+-----------+ + | | | + | | | + | 1 | 2 | + | | | + | | | + +-----------+-----------+ + | | | + | | | + | 3 | 4 | + | | | + | | | + +-----------+-----------+ + + Figure 6: quad-view video layout + + + + + + + + + + + +McGlashan, et al. Standards Track [Page 21] + +RFC 6505 Mixer Control Package March 2012 + + + <multiple-3x3/>: layout presenting nine equal-sized regions in a 3x3 + layout as shown in Figure 7. Typically, the aspect ratio of the + streams is preserved, so blanking is required. + + +-----------+-----------+-----------+ + | | | | + | | | | + | 1 | 2 | 3 | + | | | | + | | | | + +-----------+-----------+-----------+ + | | | | + | | | | + | 4 | 5 | 6 | + | | | | + | | | | + +-----------+-----------+-----------+ + | | | | + | | | | + | 7 | 8 | 9 | + | | | | + | | | | + +-----------+-----------+-----------+ + + Figure 7: multiple-3x3 video layout + + + + + + + + + + + + + + + + + + + + + + + + + + +McGlashan, et al. Standards Track [Page 22] + +RFC 6505 Mixer Control Package March 2012 + + + <multiple-4x4/>: layout presenting 16 equal-sized regions in a 4x4 + layout as shown in Figure 8. Typically, the aspect ratio of the + streams is preserved, so blanking is required. + + +-----------+-----------+-----------+-----------+ + | | | | | + | | | | | + | 1 | 2 | 3 | 4 | + | | | | | + | | | | | + +-----------+-----------+-----------+-----------+ + | | | | | + | | | | | + | 5 | 6 | 7 | 8 | + | | | | | + | | | | | + +-----------+-----------+-----------+-----------+ + | | | | | + | | | | | + | 9 | 10 | 11 | 12 | + | | | | | + | | | | | + +-----------+-----------+-----------+-----------+ + | | | | | + | | | | | + | 13 | 14 | 15 | 16 | + | | | | | + | | | | | + +-----------+-----------+-----------+-----------+ + + Figure 8: multiple-4x4 video layout + + + + + + + + + + + + + + + + + + + + +McGlashan, et al. Standards Track [Page 23] + +RFC 6505 Mixer Control Package March 2012 + + + <multiple-5x1/>: layout presents a 5x1 layout as shown in Figure 9 + where one region will occupy 4/9 of the mixed video stream, while + the others will each occupy 1/9 of the stream. Typically, the + aspect ratio of the streams is preserved, so blanking is required. + + +-----------------------+-----------+ + | | | + | | | + | | 2 | + | | | + | | | + | 1 +-----------+ + | | | + | | | + | | 3 | + | | | + | | | + +-----------+-----------+-----------+ + | | | | + | | | | + | 4 | 5 | 6 | + | | | | + | | | | + +-----------+-----------+-----------+ + + Figure 9: multiple-5x1 video layout + +4.2.1.4.3. <video-switch> + + The <video-switch> element describes the configuration of the + conference policy for how participants' input video streams are + assigned to regions within the active video layout. + + The <video-switch> element has the following child elements defined + (one child occurrence only) to indicate the video-switching policy of + the conference: + + <vas/>: (Voice-Activated Switching) enables automatic display of the + loudest speaker participant that is contributing both audio and + video to the conference mix. 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 region in the layout, then the loudest speaker is displayed + there. If more than one region is available, then the loudest + speaker is displayed in the largest region (if any), and then in + + + +McGlashan, et al. Standards Track [Page 24] + +RFC 6505 Mixer Control Package March 2012 + + + the first region from the top-left corner of the layout. The MS + assigns the remaining regions based on the priority mechanism + described in Section 4.2.1.4.3.1. + + <controller/>: enables manual control over video switching. The + controller AS determines how the regions are assigned based on an + external floor control policy. The MS receives <join>, + <modifyjoin>, and <unjoin> commands with a <stream> element + (Section 4.2.2.5) indicating the region where the stream is + displayed. If no explicit region is specified, the MS assigns the + region based on the priority mechanism described in + Section 4.2.1.4.3.1. + + An MS MAY support other video-switching policies. Other policies + MUST be specified using an element from a namespace other than the + one used in this specification. For example: + + <video-switch> + <mypolicy xmlns='http://example.com/foo'/> + </video-switch> + + The <video-switch> element has the following attributes: + + interval: specifies the period between video switches as a number of + seconds. In the case of <vas/> policy, a speaker needs to be the + loudest speaker for the interval before the switch takes place. A + valid value is a non-negative integer (see Section 4.7.2). A + value of 0 indicates that switching is applied immediately. The + attribute is optional. The default value is 3 (seconds). + + activespeakermix: indicates whether or not the active (loudest) + speaker participant receives a video stream without themselves + displayed 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 layout are implementation- + specific) and one for other participants (as described in the + <vas/> switching policy above). A valid value is a boolean (see + Section 4.7.1). A value of "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 "false". If the 'type' attribute is not set to + <vas/>, the MS ignores this attribute. + + + + + + + +McGlashan, et al. Standards Track [Page 25] + +RFC 6505 Mixer Control Package March 2012 + + + If the MS does not support the specified video-switching policy or + other configuration parameters (including separate active speaker + video mixes), then the MS reports a 424 error (Section 4.6) in the + response to the request element containing the <video-switch> + element. + + If the MS receives a <join> or <modifyjoin> request containing a + <stream> element (Section 4.2.2.5) that specifies a region and the + conference video-switching policy is set to <vas/>, then the MS + ignores the region (i.e., conference-switching policy takes + precedence). + + If the MS receives a <join> or <modifyjoin> request containing a + <stream> element (Section 4.2.2.5) specifying a region that is not + defined for the currently active video layout, the MS MUST NOT report + an error. Even though the participant is not currently visible, the + MS displays the participant if the layout changes to one that defines + the specified region. + + For example, a fragment specifying a <vas/> video-switching policy + with an interval of 2s + + <video-switch interval="2"><vas/></video-switch> + + For example, a fragment specifying a <controller/> video-switching + policy where video switching takes place immediately is as follows: + + <video-switch interval="0"><controller/></video-switch> + +4.2.1.4.3.1. Priority Assignment + + In cases where the video-switching policy does not explicitly + determine the region to which a participant is assigned, the + following priority assignment mechanism applies: + + 1. Each participant has a (positive integer) priority value: the + lower the value, the higher the priority. The priority value is + determined by the <priority> child element (Section 4.2.2.5.4) of + <stream>. If not explicitly specified, the default priority + value is 100. + + 2. The MS uses priority values to assign participants to regions in + the video layout which remain unfilled after application of the + video-switching policy. The MS MUST dedicate larger and/or more + prominent portions of the layout to participants with higher + priority values first (e.g., first, all participants with + priority 1, then those with 2, 3, etc.). + + + + +McGlashan, et al. Standards Track [Page 26] + +RFC 6505 Mixer Control Package March 2012 + + + 3. The policy for displaying participants with the same priority is + implementation-specific. + + The MS applies this priority policy each time the video layout is + changed or updated. It is RECOMMENDED that the MS does not move a + participant from one region to another unless required by the video- + switching policy when an active video layout is updated. + + This model allows the MS to apply default video layouts after + applying the video-switching policy. For example, region 2 is + statically assigned to Bob, so the priority mechanism only applies to + regions 1, 3, 4, etc. + +4.2.1.4.4. <subscribe> + + The <subscribe> element is a container for specifying conference + notification events to which a controlling entity subscribes. + Notifications of conference events are delivered using the <event> + element (see Section 4.2.4). + + The <subscribe> element has no attributes, but has the following + child element: + + <active-talkers-sub>: subscription to active talker events + (Section 4.2.1.4.4.1). The element is optional. + + The MS MUST support a <active-talkers-sub> subscription. It MAY + support other event subscriptions (specified using attributes and + child elements from a foreign namespace). If the MS does not support + a subscription specified in a foreign namespace, it sends a + <response> with a 428 status code (see Section 4.6). + +4.2.1.4.4.1. <active-talkers-sub> + + The <active-talkers-sub> element has the following attribute: + + interval: the minimum amount of time (in seconds) that elapses + before further active talker events can be generated. A valid + value is a non-negative integer (see Section 4.7.2). A value of 0 + suppresses further notifications. The attribute is optional. The + default value is 3 (seconds). + + The <active-talkers-sub> element has no child elements. + + Active talker notifications are delivered in the <active-talkers- + notify> element (Section 4.2.4.1). + + + + + +McGlashan, et al. Standards Track [Page 27] + +RFC 6505 Mixer Control Package March 2012 + + +4.2.2. Joining Elements + + This section contains definitions of the joining model + (Section 4.2.2.1) as well as the <join> (Section 4.2.2.2), + <modifyjoin> (Section 4.2.2.3), <unjoin> (Section 4.2.2.4) and + <stream> (Section 4.2.2.5) elements. + +4.2.2.1. Joining Model + + The <join> operation creates a media stream between a connection and + a conference, between connections, or between conferences. This + section describes the model of conferences and connections and + specifies the behavior for join requests to targets that already have + an 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 streams. A simple audio mixer simply sums its input + audio signals 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 the + summed input signals, creating a unique output for each contributing + participant. Each <join> operation to a conference uses one of the + conference's available inputs and/or outputs, to the maximum number + of supported participants. + + A connection is the termination of one or more RTP sessions on a + media server. It has a single input and output for each media + session established by its SIP dialog. The output of a connection + can feed several different inputs such as both a conference mixer and + a recording of that participant's audio. + + Joining two connections that are not joined to anything else simply + creates a media stream from the outputs(s) of one connection to the + corresponding inputs(s) of the other connection. It 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 to a connection is needed. + + In the first case, a connection can be receiving media from one + source (for example, a conference), and it is necessary to play an + announcement to the connection so that both the conference audio and + announcement can be heard by the conference participant. This is + sometimes referred to as a "whisper announcement". An alternative to + a whisper announcement is to have the announcement preempt the + conference media. + + + + +McGlashan, et al. Standards Track [Page 28] + +RFC 6505 Mixer Control Package March 2012 + + + Another common case is the call-center coaching scenario where a + supervisor can listen to the conversation between an agent and a + customer, and provide hints to the agent that are not heard by the + customer. + + Both of these cases can be solved by having the controlling AS create + one or more conferences for audio mixing, and then join and unjoin + the media streams as required. A better solution is to have the + media server automatically mix media streams that are requested to be + joined to a 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 straightforward 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 a media server be able + to automatically mix at least two audio streams where only the simple + summing of signals is required. + + When a media server receives a <join> request, it MUST automatically + mix all of the media streams included in the request with any streams + already joined to one of the entities identified in the request, or + it MUST fail the request and MUST NOT join any of the streams (and + MUST NOT change existing streams of the entities). A controlling AS + uses the <createconference> request for generic conferences where the + complex mixing algorithm is required. + + Specifications that extend this package to handle additional media + types such as text MUST define the semantics of the join operation + when multiple streams are requested to be joined to a single input, + such as that for a connection with a single RTP session per media + type. + +4.2.2.2. <join> + + The <join> element is sent to the MS to request creation of one or + more media streams either between a connection and a conference, + between connections, or between conferences. The two entities to + join are specified by the attributes of <join>. + + Streams can be of any media type and can be bidirectional or + unidirectional. A bidirectional stream is implicitly composed of two + unidirectional streams that can be manipulated independently. The + streams to be established are specified by child <stream> elements + (see Section 4.2.2.5). + + + + +McGlashan, et al. Standards Track [Page 29] + +RFC 6505 Mixer Control Package March 2012 + + + 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 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. + + Note: Appendix A.1 of [RFC6230] 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. + + If id1 or id2 specify a conference identifier and the conference does + not exist on the MS, the MS reports an error (406). If id1 or id2 + specify a connection identifier and the connection does not exist on + the MS, the MS reports an error (412). + + The <join> element has the following child element (zero or more): + + <stream>: an element that both identifies the media streams to join + and defines the way that they are to be joined (see + Section 4.2.2.5). The element is optional. + + If no <stream> elements are specified, then the default is to join + all streams between the entities according to the media configuration + of the connection or conference. + + One or more <stream> elements can be specified so that individual + media streams can be controlled independently. For example, if a + connection supports both audio and video streams, a <stream> element + could be used to indicate that only the audio stream is used in + receive mode. In cases where there are multiple media streams of the + same type for a connection or conference, the configuration MUST be + explicitly specified using <stream> elements. + + Multiple <stream> elements can be specified for precise control over + the media flow in different directions within the same media stream. + One <stream> element can be specified for the receiving media flow + and another element for the sending media flow, where each + independently controls features such as volume (see child element of + <stream> in Section 4.2.2.5). If there is only one <stream> element + for a given media specifying a 'sendonly' or 'recvonly' direction, + then the media flow in the opposite direction is inactive + (established but there's no actual flow of media) unless this leads + to a stream conflict. + + + +McGlashan, et al. Standards Track [Page 30] + +RFC 6505 Mixer Control Package March 2012 + + + If the MS is unable to execute the join as specified in <stream> + because a <stream> element is in conflict with (a) another <stream> + element, (b) specified connection or conference media capabilities + (including supported or available codec information), or (c) an + Session Description Protocol (SDP) label value as part of the + connection-id (see Appendix A.1 of [RFC6230]), then the MS reports an + error (407) and MUST NOT join the entities and MUST NOT change + existing streams of the entities. + + If the MS is unable to execute the join as specified in <stream> + elements because the MS does not support the media stream + configuration, the MS reports an error (422) and MUST NOT join the + entities and MUST NOT change existing streams of the entities. + + If the MS is unable to join an entity to a conference because it is + full, then the MS reports an error (410). + + If the specified entities are already joined, then the MS reports an + error (408). + + If the MS does not support joining two specified connections + together, the MS reports an error (426). + + If the MS does not support joining two specified conferences + together, the MS reports an error (427). + + If the MS is unable to join the specified entities for any other + reason, the MS reports an error (411). + + When the MS has finished processing a <join> request, it MUST reply + with an <response> element (Section 4.2.3). + + For example, a request to join two connections together is as + follows: + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <join id1="1536067209:913cd14c" id2="1536067209:913cd14c"/> + </mscmixer> + + The response if the MS doesn't support joining media streams between + connections is as follows: + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <response status="426" reason="mixing connections not supported"/> + </mscmixer> + + + + + + +McGlashan, et al. Standards Track [Page 31] + +RFC 6505 Mixer Control Package March 2012 + + +4.2.2.3. <modifyjoin> + + The <modifyjoin> element is sent to the MS to request changes in the + configuration of media stream(s) that were previously established + between a connection and a conference, between two connections, or + between two conferences. + + The <modifyjoin> 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 <modifyjoin> element has the following child elements (one or + more): + + <stream>: an element that both identifies the media streams to + modify and defines the way that each stream is to be configured + from this point forward (see Section 4.2.2.5). + + The MS MUST support <modifyjoin> for any stream that was established + using <join>. + + The MS MUST configure the streams that are included within + <modifyjoin> to that stated by the child elements. + + If the MS is unable to modify the join as specified in <stream> + elements because a <stream> element is in conflict with (a) another + <stream> element, (b) specified connection or conference media + capabilities (including supported or available codec information), or + (c) a SDP label value as part of the connection-id (see Appendix A.1 + of [RFC6230]), then the MS reports an error (407) and MUST NOT modify + the join between the entities and MUST NOT change existing streams of + the entities. + + If the MS is unable to modify the join as specified in <stream> + elements because the MS does not support the media stream + configuration, the MS reports an error (422) and MUST NOT modify the + join between the entities and MUST NOT change existing streams of the + entities. + + If the specified entities are not already joined, then the MS reports + an error (409). + + + + +McGlashan, et al. Standards Track [Page 32] + +RFC 6505 Mixer Control Package March 2012 + + + If the MS is unable to modify the join between the specified entities + for any other reason, the MS reports an error (411). + + When an MS has finished processing a <modifyjoin> request, it MUST + reply with an appropriate <response> element (Section 4.2.3). + + In cases where stream characteristics are controlled independently + for each direction, then a <modifyjoin> request needs to specify a + child element for each direction in order to retain the original + stream directionality. For the example, if a <join> request + establishes independent control for each direction of an audio stream + (see Section 4.2.2.5): + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <join id1="1536067209:913cd14c" id2="conference1"> + <stream media="audio" direction="sendonly"> + <volume controltype="setgain" value="-3"/> + </stream> + <stream media="audio" direction="recvonly"> + <volume controltype="setgain" value="+3"/> + </stream> + </join> + </mscmixer> + + then the following <modifyjoin> request + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <modifyjoin id1="1536067209:913cd14c" id2="conference1"> + <stream media="audio" direction="sendonly"> + <volume controltype="setgain" value="0"/> + </stream> + </modifyjoin> + </mscmixer> + + would cause, in addition to the modification of the sendonly volume, + the overall stream directionality to change from sendrecv to sendonly + since there is no <stream> element in this <modifyjoin> request for + the recvonly direction. The following would change the sendonly + volume and retain the recvonly stream together with its original + characteristics such as volume: + + + + + + + + + + + +McGlashan, et al. Standards Track [Page 33] + +RFC 6505 Mixer Control Package March 2012 + + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <modifyjoin id1="1536067209:913cd14c" id2="conference1"> + <stream media="audio" direction="sendonly"> + <volume controltype="setgain" value="0"/> + </stream> + <stream media="audio" direction="recvonly"/> + </modifyjoin> + </mscmixer> + +4.2.2.4. <unjoin> + + The <unjoin> element is sent to the MS to request removal of + previously established media stream(s) from between a connection and + a conference, between two connections, or between two conferences. + + The <unjoin> 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 Section 15.1 of + [RFC6230]. The attribute is mandatory. + + The <unjoin> element has the following child element (zero or more + occurrences): + + <stream>: an element that identifies the media stream(s) to remove + (see Section 4.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> and that has not already been removed by a previous + <unjoin> on the same stream. + + If the MS is unable to terminate the join as specified in <stream> + elements because a <stream> element is in conflict with (a) another + <stream> element, (b) specified connection or conference media + capabilities, or (c) a SDP label value as part of the connection-id + (see Appendix A.1 of [RFC6230]), then the MS reports an error (407) + and MUST NOT terminate the join between the entities and MUST NOT + change existing streams of the entities. + + + + + + + +McGlashan, et al. Standards Track [Page 34] + +RFC 6505 Mixer Control Package March 2012 + + + If the MS is unable to terminate the join as specified in <stream> + elements because the MS does not support the media stream + configuration, the MS reports an error (422) and MUST NOT terminate + the join between the entities and MUST NOT change existing streams of + the entities. + + If the specified entities are not already joined, then the MS reports + an error (409). + + If the MS is unable to terminate the join between the specified + entities for any other reason, the MS reports an error (411). + + When an MS has successfully processed a <unjoin> request, it MUST + reply with a successful <response> element (Section 4.2.3). + +4.2.2.5. <stream> + + <join>, <modifyjoin>, and <unjoin> require the identification and + manipulation of media streams. Media streams represent the flow of + media between a participant connection and a conference, between two + connections, or between two conferences. The <stream> element is + used (as a 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 <stream> element has the following attributes: + + media: a string indicating the type of media associated with the + stream. A valid value is a MIME type name as defined in Section + 4.2 of [RFC4288]. The following values MUST be used for common + types of media: "audio" for audio media, and "video" for video + media. See [IANA] for registered MIME type names. The attribute + is mandatory. + + label: a string indicating the SDP label associated with a media + stream [RFC4574]. The attribute is optional. + + direction: a string indicating the allowed media flow of the stream + relative to the value of the 'id1' attribute of 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 established but no + media flow). The default value is "sendrecv". The attribute is + optional. + + + + + + + +McGlashan, et al. Standards Track [Page 35] + +RFC 6505 Mixer Control Package March 2012 + + + The <stream> element has the following sequence of child elements: + + <volume>: an element (Section 4.2.2.5.1) to configure the volume or + gain of the media stream. The element is optional. + + <clamp>: an element (Section 4.2.2.5.2) to configure filtering and + removal of tones from the media stream. The element is optional. + + <region>: an element (Section 4.2.2.5.3) to configure a region + within a video layout where the media stream is displayed. The + element is optional. + + <priority>: an element (Section 4.2.2.5.4) to configure priority + associated with the stream in the media mix. The element is + optional. + + In each child element, the media stream affected is indicated by the + value of the 'direction' attribute of the parent element. + + If the 'media' attribute does not have the value of "audio", then the + MS ignores <volume> and <clamp> elements. + + If the 'media' attribute does not have the value of "video", then the + MS ignores a <region> element. + + For example, a request to join a connection to conference in both + directions with volume control is as follows: + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <join id1="1536067209:913cd14c" id2="conference1"> + <stream media="audio" direction="sendrecv"> + <volume controltype="setgain" value="-3"/> + </stream> + </join> + </mscmixer> + + where audio flow from the connection (id1) to the conference (id2) + has the volume lowered by 3 dB, and likewise the volume of the audio + flow from the conference to the connection is lowered by 3 dB. + + In this example, the volume is independently controlled for each + direction. + + + + + + + + + +McGlashan, et al. Standards Track [Page 36] + +RFC 6505 Mixer Control Package March 2012 + + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <join id1="1536067209:913cd14c" id2="conference1"> + <stream media="audio" direction="sendonly"> + <volume controltype="setgain" value="-3"/> + </stream> + <stream media="audio" direction="recvonly"> + <volume controltype="setgain" value="+3"/> + </stream> + </join> + </mscmixer> + + where audio flow from the connection (id1) to the conference (id2) + has the volume lowered by 3 dB, but the volume of the audio flow from + the conference to the connection is raised by 3 dB. + +4.2.2.5.1. <volume> + + The <volume> element is used to configure the volume of an audio + media stream. It can be set to a specific gain amount, to + automatically adjust the gain to a desired target level, or to mute + the volume. + + The <volume> element has no child elements but has the following + attributes: + + controltype: a string indicating the type of volume control to use + 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 a + specific gain measured in dB to apply), and "setstate" (set the + state of the stream to "mute" or "unmute" as specified by the + value of the 'value' attribute). The attribute is mandatory. + + value: a string specifying the amount or state for the volume + control defined by the value of the 'controltype' attribute. The + attribute is optional. There is no default value. + + If the audio media stream is in a muted state, then the MS also + changes automatically the state to unmuted with an "automatic" or + "setgain" volume control. For example, assume an audio stream has + been muted with <volume controltype="setstate" value="mute"/>. If + the gain on the same stream is changed with <volume + controltype="setgain" value="+3"/>, then the volume is increased and + stream state is also changed to unmuted. + + + + + + + +McGlashan, et al. Standards Track [Page 37] + +RFC 6505 Mixer Control Package March 2012 + + +4.2.2.5.2. <clamp> + + The <clamp> element is used to configure whether tones are filtered + and removed from a media stream. + + The <clamp> element has no child elements but has the following + attribute: + + tones: A space-separated list of the tones to remove. The attribute + is optional. The default value is "1 2 3 4 5 6 7 8 9 0 * # A B C + D" (i.e., all DTMF (Dual-Tone Multi-Frequency) tones are removed). + +4.2.2.5.3. <region> + + As described in Section 4.2.1.4.2.1, each <video-layout> is composed + of one or more named regions (or areas) in which video media can be + presented. For example, the XCON layout <dual-view> has two regions + named "1" and "2", respectively. + + The <region> element is used to explicitly specify the name of the + area within a video layout where a video media stream is displayed. + + The <region> element has no attributes, and its content model + specifies the name of the region. + +4.2.2.5.4. <priority> + + The <priority> element is used to explicitly specify the priority of + a participant. The MS uses this priority to determine where the + media stream is displayed within a video layout + (Section 4.2.1.4.3.1). + + The <priority> element has no attributes, and its content model + specifies a positive integer (see Section 4.7.3). The lower the + value, the higher the priority. + +4.2.3. <response> + + Responses to requests are indicated by a <response> element. + + The <response> element has following attributes: + + status: numeric code indicating the response status. Valid values + are defined in Section 4.6. The attribute is mandatory. + + reason: string specifying a reason for the response status. The + attribute is optional. + + + + +McGlashan, et al. Standards Track [Page 38] + +RFC 6505 Mixer Control Package March 2012 + + + 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. + + conferenceid: string identifying the conference (see Appendix A.1 of + [RFC6230]). The attribute is optional. + + connectionid: string identifying the SIP dialog connection (see + Appendix A.1 of [RFC6230]). The attribute is optional. + + For example, a response when a conference was created successfully is + as follows: + + <response code="200"/> + + If conference creation failed due to the requested conference ID + already existing, the response is: + + <response code="405" reason="Conference already exists"/> + +4.2.4. <event> + + When a mixer generates a notification event, the MS sends the event + using an <event> element. + + The <event> element has no attributes, but has the following sequence + of child elements (zero or more instances of each child): + + <active-talkers-notify>: specifies an active talkers notification + (Section 4.2.4.1). + + <unjoin-notify>: notifies that a connection or conference has been + completely unjoined (Section 4.2.4.2). + + <conferenceexit>: notifies that a conference has exited + (Section 4.2.4.3). + +4.2.4.1. <active-talkers-notify> + + The <active-talkers-notify> element describes zero or more speakers + that have been active in a conference during the specified interval + (see Section 4.2.1.4.4.1). + + + + + + + +McGlashan, et al. Standards Track [Page 39] + +RFC 6505 Mixer Control Package March 2012 + + + The <active-talkers-notify> element has the following attribute: + + conferenceid: string indicating the name of the conference from + which the event originated. This attribute is mandatory. + + The <active-talkers-notify> element has the following sequence of + child elements (zero or more occurrences): + + <active-talker>: element describing an active talker + (Section 4.2.4.1.1). + +4.2.4.1.1. <active-talker> + + The <active-talker> element describes an active talker, associated + with either a connection or conference participant in a conference. + + The <active-talker> element has the following attributes: + + connectionid: string indicating the connectionid of the active + talker. This attribute is optional. There is no default value. + + conferenceid: string indicating the conferenceid of the active + talker. This attribute is optional. There is no default value. + + Note that the element does not describe an active talker if both the + 'connectionid' and 'conferenceid' attributes are specified, or if + neither attribute is specified. + + The <active-talker> element has no child elements. + +4.2.4.2. <unjoin-notify> + + The <unjoin-notify> element describes a notification event where a + connection and/or conference have been completely unjoined. + + The <unjoin-notify> element has the following attributes: + + status: a status code indicating why the unjoin occurred. A valid + value is a non-negative integer (see Section 4.7.2). The MS MUST + support the following values: + + 0 indicates the join has been terminated by a <unjoin> request. + + 1 indicates the join terminated due to an execution error. + + 2 indicates that the join terminated because a connection or + conference has terminated. + + + + +McGlashan, et al. Standards Track [Page 40] + +RFC 6505 Mixer Control Package March 2012 + + + 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 status code + it does not recognize as being equivalent to 1 (join execution + error). The attribute is mandatory. + + reason: a textual description providing a reason for the status + code, e.g., details about an error. A valid value is a string + (see Section 4.7.4). The attribute is optional. There is no + default value. + + 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. + + 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 <unjoin-notify> element has no child elements. + +4.2.4.3. <conferenceexit> + + The <conferenceexit> element indicates that a conference has exited + because it has been terminated or because a error occurred (for + example, a hardware error in the conference mixing unit). This event + MUST be sent by the MS whenever a successfully created conference + exits. + + The <conferenceexit> element has the following attributes: + + conferenceid: string indicating the name of the conference. This + attribute is mandatory. + + status: a status code indicating why the conference exited. A valid + value is a non-negative integer (see Section 4.7.2). The MS MUST + support the following values: + + 0 indicates the conference has been terminated by a + <destroyconference> request. + + 1 indicates the conference terminated due to an execution error. + + + +McGlashan, et al. Standards Track [Page 41] + +RFC 6505 Mixer Control Package March 2012 + + + 2 indicates the conference terminated due to exceeding the + maximum duration for a conference. + + 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 status code + it does not recognize as being equivalent to 1 (conference + execution error). The attribute is mandatory. + + reason: a textual description providing a reason for the status + code, e.g., details about an error. A valid value is a string + (see Section 4.7.4). The attribute is optional. There is no + default value. + + 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 <conferenceexit> element has no child elements. + + When a MS sends a <conferenceexit> event, the identifier for the + conference ('conferenceid' attribute) is no longer valid on the MS + and can be reused for another conference. + + For example, the following notification event would be sent from the + MS when the conference with identifier "conference99" exits due to a + successful <destroyconference/>: + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <event> + <conferenceexit conferenceid="conference99" + status="0"/> + </event> + </mscmixer> + +4.3. 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 + + + +McGlashan, et al. Standards Track [Page 42] + +RFC 6505 Mixer Control Package March 2012 + + + 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). + +4.3.1. <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 + + + +McGlashan, et al. Standards Track [Page 43] + +RFC 6505 Mixer Control Package March 2012 + + + 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: + + <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> + +4.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 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. + + + + + +McGlashan, et al. Standards Track [Page 44] + +RFC 6505 Mixer Control Package March 2012 + + + 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: + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <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> + + + + +McGlashan, et al. Standards Track [Page 45] + +RFC 6505 Mixer Control Package March 2012 + + +4.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 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> + +4.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 + (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. + + + + + +McGlashan, et al. Standards Track [Page 46] + +RFC 6505 Mixer Control Package March 2012 + + +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: + + <conferenceaudit conferenceid="conference1"/> + + A fragment when the same conference has three participants (two + connections and another conference) joined to it is as follows: + + <conferenceaudit conferenceid="conference1"> + <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): + + + +McGlashan, et al. Standards Track [Page 47] + +RFC 6505 Mixer Control Package March 2012 + + + <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: + + <mixers> + <joinaudit id1="1536067209:913cd14" id2="1636067209:413cd14"/> + <joinaudit id1="conference1" id2="conference2"/> + </mixers> + +4.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. + + + + +McGlashan, et al. Standards Track [Page 48] + +RFC 6505 Mixer Control Package March 2012 + + + 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: + + <codecs> + <codec name="audio"> + <subtype>PCMA</subtype> + </codec> + <codec name="video"> + <subtype>H263</subtype> + </codec> + </codecs> + +4.4.1. <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: + + <codec name="video"> + <subtype>H263</subtype> + </codec> + + + +McGlashan, et al. Standards Track [Page 49] + +RFC 6505 Mixer Control Package March 2012 + + + A fragment where the <codec> element describes the H264 video codec + with additional information about the profile level and packetization + mode is as follows: + + <codec name="video"> + <subtype>H264</subtype> + <params> + <param name="profile-level-id">42A01E</param> + <param name="packetization-mode">0</param> + </params> + </codec> + +4.5. <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). + +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. + + + + + +McGlashan, et al. Standards Track [Page 50] + +RFC 6505 Mixer Control Package March 2012 + + +4.6. 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. + + + + + + + + + + + + + + + +McGlashan, et al. Standards Track [Page 51] + +RFC 6505 Mixer Control Package March 2012 + + + +-------+---------------+----------------------+--------------------+ + | 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 5 or it | | + | | | violates a | | + | | | co-occurrence | | + | | | constraint for a | | + | | | request element | | + | | | defined in | | + | | | Section 4. | | + | | | | | + | 405 | Conference | request uses an | Send an <audit> | + | | already | identifier to create | request | + | | exists | a new conference | (Section 4.3.1) | + | | | (Section 4.2.1.1) | requesting the | + | | | that is already used | list of conference | + | | | by another | mixer identifiers | + | | | conference on the | already used by | + | | | MS. | the MS and then | + | | | | use a conference | + | | | | identifier that is | + | | | | not listed. | + | | | | | + | 406 | Conference | request uses an | Send an <audit> | + | | does not | identifier for a | request | + | | exist | conference that does | (Section 4.3.1) | + | | | not exist on the MS. | requesting the | + | | | | list of conference | + | | | | mixer identifiers | + | | | | used by the MS and | + | | | | then use a | + | | | | conference | + | | | | identifier that is | + | | | | listed. | + | | | | | + + + + + +McGlashan, et al. Standards Track [Page 52] + +RFC 6505 Mixer Control Package March 2012 + + + | 407 | Incompatible | request specifies a | Change the media | + | | stream | media stream | stream | + | | configuration | configuration that | configuration to | + | | | is in conflict with | match the | + | | | itself, the | capabilities of | + | | | connection, or | the connection or | + | | | conference | conference. | + | | | capabilities (see | | + | | | Section 4.2.2.2). | | + | | | | | + | 408 | Joining | request attempts to | Send an <audit> | + | | entities | create a join mixer | request | + | | already | (Section 4.2.2.2) | (Section 4.3.1) | + | | joined | where the entities | requesting the | + | | | are already joined. | list of join | + | | | | mixers on the MS | + | | | | and then use | + | | | | entities that are | + | | | | not listed. | + | | | | | + | 409 | Joining | request attempts to | Send an <audit> | + | | entities not | manipulate a join | request | + | | joined | mixer where the | (Section 4.3.1) | + | | | entities are not | requesting the | + | | | joined. | list of join | + | | | | mixers on the MS | + | | | | and then use | + | | | | entities that are | + | | | | listed. | + | | | | | + | 410 | Unable to | request attempts to | | + | | join - | join a participant | | + | | conference | to a conference | | + | | full | (Section 4.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 | Connection | request uses an | | + | | does not | identifier for a | | + | | exist | connection that does | | + | | | not exist on the MS. | | + | | | | | + + + +McGlashan, et al. Standards Track [Page 53] + +RFC 6505 Mixer Control Package March 2012 + + + | 419 | Other | requested operation | | + | | execution | cannot be executed | | + | | error | by the MS. | | + | | | | | + | 420 | Conference | request to create a | | + | | reservation | new conference | | + | | failed | (Section 4.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 | Unsupported | request contains one | | + | | media stream | or more <stream> | | + | | configuration | elements | | + | | | (Section 4.2.2.5) | | + | | | whose configuration | | + | | | is not supported by | | + | | | the MS. | | + | | | | | + | 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. | | + | | | | | + + + + + +McGlashan, et al. Standards Track [Page 54] + +RFC 6505 Mixer Control Package March 2012 + + + | 426 | Unable to | request to join | | + | | join - mixing | connection entities | | + | | connections | (Section 4.2.2.2) | | + | | not supported | failed due to lack | | + | | | of support for | | + | | | mixing connections. | | + | | | | | + | 427 | Unable to | request to join | | + | | join - mixing | conference entities | | + | | conferences | (Section 4.2.2.2) | | + | | not supported | failed due to lack | | + | | | of support for | | + | | | mixing conferences. | | + | | | | | + | 428 | Unsupported | the request contains | | + | | foreign | attributes or | | + | | namespace | elements from | | + | | attribute or | another namespace | | + | | element | that the MS does not | | + | | | support. | | + | | | | | + | 435 | Other | request requires | | + | | unsupported | another capability | | + | | capability | not supported by the | | + | | | MS. | | + +-------+---------------+----------------------+--------------------+ + + Table 1: Status Codes + +4.7. Type Definitions + + This section defines types referenced in attribute definitions. + +4.7.1. 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. + +4.7.2. 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]. + + + + + +McGlashan, et al. Standards Track [Page 55] + +RFC 6505 Mixer Control Package March 2012 + + +4.7.3. Positive Integer + + The value space of positive integer is the infinite set {1,2,...} as + defined in Section 3.3.25 of [XMLSchema:Part2]. + +4.7.4. String + + A string in the character encoding associated with the XML element as + defined in Section 3.2.1 of [XMLSchema:Part2]. + +4.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". + +4.7.6. 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]. + +4.7.7. 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]. + +5. 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. + + + +McGlashan, et al. Standards Track [Page 56] + +RFC 6505 Mixer Control Package March 2012 + + + 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> + + <!-- + ############################################################# + + 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> + + <!-- + + + +McGlashan, et al. Standards Track [Page 57] + +RFC 6505 Mixer Control Package March 2012 + + + ##################################################### + + Extensible core type + + ##################################################### + --> + + + <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> + + <!-- + ##################################################### + + 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:attribute name="version" type="version.datatype" + use="required" /> + + + +McGlashan, et al. Standards Track [Page 58] + +RFC 6505 Mixer Control Package March 2012 + + + <xsd:attribute name="desclang" type="xsd:language" + default="i-default" /> + </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 --> + + + +McGlashan, et al. Standards Track [Page 59] + +RFC 6505 Mixer Control Package March 2012 + + + <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: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" /> + + <!-- + ##################################################### + + JOIN TYPES + + + + +McGlashan, et al. Standards Track [Page 60] + +RFC 6505 Mixer Control Package March 2012 + + + ##################################################### + --> + + <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" /> + + + +McGlashan, et al. Standards Track [Page 61] + +RFC 6505 Mixer Control Package March 2012 + + + <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" /> + + + +McGlashan, et al. Standards Track [Page 62] + +RFC 6505 Mixer Control Package March 2012 + + + <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" /> + + + +McGlashan, et al. Standards Track [Page 63] + +RFC 6505 Mixer Control Package March 2012 + + + <!-- 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: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" + + + +McGlashan, et al. Standards Track [Page 64] + +RFC 6505 Mixer Control Package March 2012 + + + 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> + + + +McGlashan, et al. Standards Track [Page 65] + +RFC 6505 Mixer Control Package March 2012 + + + </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" /> + + + <!-- region --> + <xsd:simpleType name="regionType"> + <xsd:restriction base="xsd:NMTOKEN" /> + </xsd:simpleType> + + <xsd:element name="region" type="regionType" /> + + + <!-- priority --> + <xsd:simpleType name="priorityType"> + + + +McGlashan, et al. Standards Track [Page 66] + +RFC 6505 Mixer Control Package March 2012 + + + <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" /> + + <!-- video-switch --> + + <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" /> + + <!-- video-layouts --> + + <xsd:complexType name="videolayoutsType"> + <xsd:complexContent> + + + +McGlashan, et al. Standards Track [Page 67] + +RFC 6505 Mixer Control Package March 2012 + + + <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 --> + <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" + + + +McGlashan, et al. Standards Track [Page 68] + +RFC 6505 Mixer Control Package March 2012 + + + 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" /> + + <!-- 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> + + + +McGlashan, et al. Standards Track [Page 69] + +RFC 6505 Mixer Control Package March 2012 + + + <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"> + + + +McGlashan, et al. Standards Track [Page 70] + +RFC 6505 Mixer Control Package March 2012 + + + <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" /> + + + + +McGlashan, et al. Standards Track [Page 71] + +RFC 6505 Mixer Control Package March 2012 + + + <!-- 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:attribute name="name" type="xsd:string" + use="required" /> + </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 --> + + + +McGlashan, et al. Standards Track [Page 72] + +RFC 6505 Mixer Control Package March 2012 + + + <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: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" /> + + + <!-- + #################################################### + + DATATYPES + + #################################################### + --> + + <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> + + + +McGlashan, et al. Standards Track [Page 73] + +RFC 6505 Mixer Control Package March 2012 + + + <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 + + + +McGlashan, et al. Standards Track [Page 74] + +RFC 6505 Mixer Control Package March 2012 + + +6. Examples + + This section provides examples of the Mixer Control Package. + +6.1. 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. + +6.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 | + | ----------------------------------------> | + + + +McGlashan, et al. Standards Track [Page 75] + +RFC 6505 Mixer Control Package March 2012 + + +6.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 | + | ----------------------------------------> | + | | + +6.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 | + | ----------------------------------------> | + +6.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. + + + + + +McGlashan, et al. Standards Track [Page 76] + +RFC 6505 Mixer Control Package March 2012 + + +6.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 a 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: + + + + +McGlashan, et al. Standards Track [Page 77] + +RFC 6505 Mixer Control Package March 2012 + + + <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-talkers-notify conferenceid="conf1"> + <active-talker connectionid="1536067209:913cd14c"/> + </active-talkers-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> + + + +McGlashan, et al. Standards Track [Page 78] + +RFC 6505 Mixer Control Package March 2012 + + + 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 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="2" 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="0" conferenceid="conf1"/> + </event> + </mscmixer> + +6.2.2. 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: + + <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> + + + + + +McGlashan, et al. Standards Track [Page 79] + +RFC 6505 Mixer Control Package March 2012 + + + 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: + + <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. + +6.2.3. 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: + + + + + + + + + + + + + + + +McGlashan, et al. Standards Track [Page 80] + +RFC 6505 Mixer Control Package March 2012 + + + <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> + <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: + + <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> + +7. 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, + + + +McGlashan, et al. Standards Track [Page 81] + +RFC 6505 Mixer Control Package March 2012 + + + 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. + + + + + +McGlashan, et al. Standards Track [Page 82] + +RFC 6505 Mixer Control Package March 2012 + + + 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 + + + + +McGlashan, et al. Standards Track [Page 83] + +RFC 6505 Mixer Control Package March 2012 + + + 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]). + +8. 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. + +8.1. Control Package Registration + + This section registers a new Media Control Channel Framework package, + per the instructions in Section 13.1 of [RFC6230]. + + To: ietf-sip-control@iana.org + 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 (mediactrl@ietf.org), + Scott McGlashan (smcg.stds01@mcglashan.org). + +8.2. 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 (mediactrl@ietf.org), + Scott McGlashan (smcg.stds01@mcglashan.org). + + + + + + + + + + + + + + + +McGlashan, et al. Standards Track [Page 84] + +RFC 6505 Mixer Control Package March 2012 + + + 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> + <h1>Namespace for Media Control Channel + Framework Mixer Package attributes</h1> + <h2>urn:ietf:params:xml:ns:msc-mixer</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc6505.txt"> + RFC 6505</a>.</p> + </body> + </html> + END + +8.3. 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 (mediactrl@ietf.org), + Scott McGlashan (smcg.stds01@mcglashan.org). + Schema: The XML for this schema can be found in + Section 5 of this document. + +8.4. MIME Media Type Registration for 'application/msc-mixer+xml' + + This section registers the "application/msc-mixer+xml" MIME type. + + To: ietf-types@iana.org + 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. + + + +McGlashan, et al. Standards Track [Page 85] + +RFC 6505 Mixer Control Package March 2012 + + + 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 <smcg.stds01@mcglashan.org> + Intended usage: LIMITED USE + Author/Change controller: The IETF + Other information: None. + +8.5. 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: + + +----------+----------------+----------------+----------------------+ + | Code | Summary | Description | Reference | + +----------+----------------+----------------+----------------------+ + | status | brief summary | full | reference document | + | code | of the status | description of | defining the status | + | number | code | the status | code | + | | | code | | + +----------+----------------+----------------+----------------------+ + + Table 2: Fields for Mixer Control Package Status Code Registry + +9. 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. + + + + +McGlashan, et al. Standards Track [Page 86] + +RFC 6505 Mixer Control Package March 2012 + + +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. + + + + +McGlashan, et al. Standards Track [Page 87] + +RFC 6505 Mixer Control Package March 2012 + + + [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. + + + + + +McGlashan, et al. Standards Track [Page 88] + +RFC 6505 Mixer Control Package March 2012 + + + [RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media + Server Markup Language (MSML)", RFC 5707, + February 2010. + +Authors' Addresses + + Scott McGlashan + Hewlett-Packard + + EMail: smcg.stds01@mcglashan.org + + + Tim Melanchuk + Rainwillow + + EMail: timm@rainwillow.com + + + Chris Boulton + NS-Technologies + + EMail: chris@ns-technologies.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGlashan, et al. Standards Track [Page 89] + |