RFC 6505
A Mixer Control Package for the Media Control Channel Framework
Title Block 🎀
RFC 6505: A Mixer Control Package for the Media Control Channel Framework 💖
- Authors: S. McGlashan (Hewlett-Packard), T. Melanchuk (Rainwillow), and C. Boulton (NS-Technologies) 👯♀️
- Category: Standards Track 🔥
- Status: This is an Internet Standards Track document, from the IETF (Internet Engineering Task Force) 🦋
- Date: March 2012 📅
- ISSN: 2070-1721
- Obsoletes / Updates: The title block doesn't list anything it obsoletes or updates 🙈
Abstract 💖
okay so this doc defines a Media Control Channel Framework package for managing mixers in media conferences and connections 🎧 The package has request elements for managing conference mixers and for managing mixers between conferences and/or connections. It also comes with responses and notifications for those requests. And it's giving auditing too, with elements for checking what the package can do and what mixers exist ✨
Status of This Memo 📜
This is an Internet Standards Track document, so it's an official spec, not just a vibe 💅
It's a product of the IETF, which means it reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 🧚
For the current status, any errata, and how to give feedback, go to 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, at http://trustee.ietf.org/license-info, as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 🫶 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as the Simplified BSD License describes 🍓
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from the copyright controllers of those 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. The exceptions are formatting it for publication as an RFC or translating 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
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 . . . . . . . . . . . . . . . . . . 881. Introduction ✨
The Media Control Channel Framework [RFC6230] gives you a generic way to set up and report on remotely initiated commands 🧚 The Control Framework is the same thing under another name. It borrows a lot of functions from the Session Initiation Protocol (SIP) [RFC3261] for the rendezvous and setup of a reliable channel for control interactions 💅 The Control Framework also brings in the idea of a Control Package. A Control Package is an explicit use of the Control Framework for one particular set of interactions, and this spec defines one for media conference mixers and media connection mixers 🎀
This package is the one that handles the mixer management elements. Those let you create, modify, and delete conference mixers 🦋 It also has elements for joining, modifying, and unjoining media streams between connections and conferences, including mixers between connections. Then there are the responses and notifications that go with all of that. And yes, it has auditing elements too, for checking package capabilities and the mixers the package manages 💜
Fun fact: this package was designed to meet the media-mixing requirements in the Media Server Control Protocol Requirements document [RFC5167]. More specifically, it covers REQ-MCP-22, REQ-MCP-23, REQ-MCP-24, REQ-MCP-25, REQ-MCP-26, and REQ-MCP-27 🌸
It gives you the major conferencing features of SIP media server languages like MSCML [RFC5022] and MSML [RFC5707] 🍓 The key difference is that it delivers all of that through the Media Control Channel Framework 👑
Not covered here: the fancier stuff. That means personalized video mixes for conference participants, support for floor control protocols, and support for video overlays and text insertion 🙈 You can still get there by extending this package, through foreign elements or attributes from another namespace, or by using other Control Packages that build on top of this one.
The functionality here is defined by messages that contain XML [XML] elements and travel over the Media Control Channel Framework 🫶 The XML elements come in two flavours: mixer management elements, and audit elements for checking package capabilities and the mixers the package manages 🔥
Here's how the doc is laid out. Section 3 explains how this Control Package meets the requirements for a Media Control Channel Framework Control Package. Section 4 covers the syntax and semantics of the defined elements, including mixer management (Section 4.2) and audit elements (Section 4.3). Section 5 gives an XML schema for these elements and allows extensibility by letting attributes and elements from other namespaces in. Section 6 has examples of package usage. Section 7 covers the important security considerations for this Control Package. Section 8 covers IANA registration of this Control Package, including its name, XML namespace, and MIME media type 🧚
Part 1 of 18 is done, bestie, more parts are coming 💖✨
2. Conventions and Terminology ✨
okay so first things first, the key words! BCP 14 [RFC2119] is the thing that defines "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 💅 on top of that, BCP 15 spells out requirement levels for compliant implementations 🎀
here are the extra terms we're defining for this doc 🧚
Application Server: A SIP [RFC3261] application server (AS) is a control client that hosts and executes services like 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. main character energy, literally 👑
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 🔥
3. Control Package Definition 🎀
this section is where we fulfill the mandatory requirement for info that MUST be specified when you define 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, and to give 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 they're all contained within a root <mscmixer> element (Section 4.1) ✨
in this package, the MS operates as a Control Server, 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 when it sends event notifications 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. no excuses, bestie 💀
3.3. Common XML Support
the Control Framework requires a Control Package definition to specify whether 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. non-negotiable 💅
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 where the detailed syntax definitions and semantics for the appropriate body types live 📚
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 the 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 points you to the detailed syntax definitions and semantics for the appropriate body types.
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 an <auditresponse> element (Section 4.3.2).
3.6. Audit
the Control Framework encourages Control Packages to specify whether auditing is available, how it's triggered, and what the query/response formats look like 🔎
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 is carried in a REPORT message (or in a 200 response to the CONTROL if the MS 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 that Control Packages provide a range of message flows that show 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. this is serious, so please don't skip it 🙏
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 support attributes and elements from other (foreign) namespaces. if an MS implementation receives a <mscmixer> element containing attributes or elements from another namespace that 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, mainly for diagnostic use 🩺 the implementation can indicate 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 on 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> ✨
okay so <mscmixer> is the big umbrella element that wraps everything in this package 💖 It takes these attributes, on top of the usual XML namespace stuff like xmlns:
version: a string with the mscmixer package version. It's fixed at "1.0" for this version of the package. The attribute is mandatory.desclang: sets the language for the descriptive text in subordinate elements, unless a subordinate element has its owndesclangattribute that overrides it. The descriptive text attributes on subordinate elements are: thereasonattribute 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]). 🌍
<mscmixer> has the following child elements defined, and only one of them can occur 🎀
- Mixer management elements, from 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
- Audit elements, from 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
here's a request to the MS to create a conference mixer 🧚
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference/>
</mscmixer>and here's the MS replying that the conference was created successfully 🥳
<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. They're sorted into requests, responses, and notifications, and the split is honestly so clean 🫶
requests are the messages we send TO the MS asking it to run a specific mixer operation. The request elements are:
<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
responses come back from the MS and describe how the requested operation went 💅 They're wrapped in a <response> element (Section 4.2.3) with a mandatory attribute that gives the status as a numeric code. The response status codes are defined in Section 4.6. The MS MUST respond to a request message with a response message, so no ghosting allowed 🙈
if the MS can't process the request and carry out the mixer operation (fully or partly), the request has failed. In that case 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 in this section, implementations follow Section 4.6 to work out the right status code for the response.
notifications go the other way, from the MS, to give you updates on the status of a mixer operation or subscription 🔔 They're specified in an <event> element (Section 4.2.4).
4.2.1. Conference Elements 👑
4.2.1.1. <createconference>
the <createconference> element gets sent to the MS to request the creation of a new conference (multiparty) mixer 🎉
the <createconference> element takes these attributes:
conferenceid: a string with a unique name for the new conference. If this attribute isn't specified, the MS MUST create a unique name for the conference. The value gets used in later references to the conference (e.g., asconferenceidin a <response>). The attribute is optional. There is no default value.reserved-talkers: the requested number of guaranteed speaker slots to reserve 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: the requested number of guaranteed listener slots to reserve 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 this sequence of child elements 🧁
<codecs>: an element to configure the codecs the conference supports (see Section 4.4). If codecs are specified, they limit the media capability when the MS tries 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.<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 a subscription to conference events (see Section 4.2.1.4.4). The element is optional.
now the error cases, which are kind of the spicy part 🌶️
- if the
conferenceidattribute has a value that an existing conference is already using, the MS reports an error (405), MUST NOT create a new conference, and MUST NOT affect the existing conference. - if the MS can't configure the conference according to the specified
reserved-talkersorreserved-listenersattributes, the MS reports an error (420) and MUST NOT create the conference. - if the MS can't 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 can't 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 can't 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 can't 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) 💌
here's a request to create an audio video conference mixer with specified codecs, a video layout, a video switch, and a subscription 🎬
<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>and here's the response if the conference was created successfully ✨
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" conferenceid="conference1"/>
</mscmixer>and if the MS couldn't create the conference because it doesn't support the H264 codec, the response looks like this 😭
<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> 🎀
okay so <modifyconference> is what the MS gets when someone wants to change a conference that already exists 💅
It has one attribute:
conferenceid: a string with the name of the conference to modify. This one is mandatory, no skipping bestie 🙈
It also needs one or more child elements, in this order:
<codecs>: configures the codecs the conference supports (see Section 4.4). If you set codecs, they limit the media capabilities the MS can use when it tries to join the conference to other entities (see Sections 4.2.2.2 and 4.2.2.3). Existing participants are totally unaffected by policy changes 🫶 This element is optional.<audio-mixing>: configures how the conference audio gets mixed (see Section 4.2.1.4.1). This element is optional.<video-layouts>: configures the video layouts of the conference (see Section 4.2.1.4.2). This element is optional.<video-switch>: configures the video switch policy for the layout of the conference (see Section 4.2.1.4.3). This element is optional.<subscribe>: requests a subscription to conference events (see Section 4.2.1.4.4). This element is optional.
Now the error situations, which are kind of a big deal 😭
- If
conferenceidnames a conference that doesn't exist, the MS reports error (406). - If the MS can't configure the conference using a given
<audio-mixing>element, it reports error (421) and MUST NOT modify the conference in any way 💀 - If the MS can't configure the conference using a given
<video-layouts>element, it reports error (423) and MUST NOT modify the conference in any way 💀 - If the MS can't configure the conference using a given
<video-switch>element, it reports error (424) and MUST NOT modify the conference in any way 💀 - If the MS can't configure the conference using a given
<codecs>element, it reports error (425) and MUST NOT modify the conference.
And once the MS is done processing a <modifyconference> request, it MUST reply with an appropriate <response> element (Section 4.2.3). Non-negotiable ✨
4.2.1.3. <destroyconference> 💜
<destroyconference> is sent to the MS to request that an existing conference be destroyed. Bye bye, conference 👋
It has one attribute:
conferenceid: a string with the name of the conference to destroy. This attribute is mandatory.
It does not take any child elements. Simple.
If conferenceid names a conference that doesn't exist, the MS reports error (406).
Once the MS finishes processing a <destroyconference> request, it MUST reply with an appropriate <response> element (Section 4.2.3).
Here's the tea ☕ If the destroy works (status code 200), then every connection or conference participant gets removed from the conference mixer. An <unjoin-notify> notification event (Section 4.2.4.2) gets sent for each participant, and a <conferenceexit> notification event (Section 4.2.4.3) announces that the conference has exited. If the <response> has any other status code, the conference mixer still exists and the participants are still joined to it 🧚
4.2.1.4. Conference Configuration 🌸
The elements in this section are used to set up and change how conferences are configured.
4.2.1.4.1. <audio-mixing> 🎶
<audio-mixing> defines how the conference audio mix is configured.
It has the following attributes:
type: a string for the audio stream mixing policy. The defined values are "nbest" (the N best, meaning loudest, participant signals get mixed) and "controller" (the contributing participant or participants get picked by the controlling AS through an external floor control protocol). This attribute is optional. The default value is "nbest".n: the number of eligible participants included in the conference audio mix. An eligible participant is someone who contributes audio to the conference, and 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 means that every participant contributing audio to the conference is included in the mix. The default value is 0. This element is optional.
If the type attribute doesn't have the value "nbest", the MS ignores the n attribute 🙃
<audio-mixing> has no child elements.
Here's an example fragment where the audio-mixing policy is "nbest" and 3 participants are included:
<audio-mixing type="nbest" n="3"/>Picture this: the conference has 200 participants, and 30 of them contribute audio. That makes 30 eligible participants for the audio mix. Out of those, the 3 loudest get their audio included in the conference 🔥
4.2.1.4.2. <video-layouts> 🦋
<video-layouts> describes the video presentation layout configuration for participants who provide a video input stream to the conference. It lets you specify multiple video layouts, so the MS automatically switches layouts depending on how many video-enabled participants there are 📺
The <video-layouts> element has no attributes.
It has the following sequence of child elements (one or more):
<video-layout>: an element describing a video layout (Section 4.2.1.4.2.1).
If the MS doesn't support video conferencing at all, or doesn't support multiple video layouts, or doesn't support a specific video layout, the MS reports a 423 error in the response to the request element that contains the <video-layouts> element.
An MS MAY support more than one <video-layout> element, though only one layout can be active at a time. A <video-layout> is active when the number of participants in the conference is equal to or greater than its min-participants attribute value, but less than the min-participants value of any other <video-layout> element. If more than one <video-layout> has the same value for min-participants, the MS reports an error (400). When the active layout has more regions than there are participants in the conference, how the unassigned regions get displayed is implementation-specific 🤷♀️
Assigning participant video streams to regions within the layout follows the video switch policy specified by the <video-switch> element (Section 4.2.1.4.3). 💅
Here's an example fragment describing a single layout:
<video-layouts>
<video-layout><single-view/></video-layout>
</video-layouts>And here's an example fragment describing a sequence of layouts:
<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>So with that sequence: when the conference has one participant providing a video input stream, the single-view format gets used. With two such participants, the dual-view layout kicks in. Three or four participants get the quad-view layout, and five or more get the multiple-3x3 layout. It's giving main character energy 👑
4.2.1.4.2.1. <video-layout> 🎀
okay so the <video-layout> element is literally where the magic happens 🦋 It describes a video layout with one or more regions where the participant video input streams get displayed. main character energy, fr.
It has one attribute, and it's giving optional 💅
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 that specifies the video layout. An MS MAY support the predefined video layouts from the conference information data model for centralized conferencing (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 too. 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 doesn't support the specified video layout configuration, then the MS reports a 423 error (Section 4.6) in the response to the request element that contains the <video-layout> element. 🙈
Each video layout has one or more regions associated with it. 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, so the MS might need to blank out part of each region.
+-----------+-----------+
| | |
| | |
| 1 | 2 |
| | |
| | |
+-----------+-----------+Figure 2: dual-view video layout
<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, so the MS might need to blank out part of each region.
+-----------+
| |
| |
| 1 |
| |
| |
+-----------+
| |
| |
| 2 |
| |
| |
+-----------+Figure 4: dual-view-2x1 video layout
<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
<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
<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
<multiple-5x1/>: layout presenting a 5x1 layout, as shown in Figure 9, where one region occupies 4/9 of the mixed video stream while the others 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> ✨
okay so the <video-switch> element is where the conference sets its policy for how everyone's incoming video streams get placed into regions of the active video layout 🎀 it's basically the bouncer for the screen 💅
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 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.
🚨 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. In other words, the 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:
- 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. - 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.).
- 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). 🫶
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
okay so the <join> operation is what creates a media stream between a connection and a conference, between connections, or between conferences 💖 this part explains the model of conferences and connections, plus what happens when a join request targets something that already has a stream attached 🦋
conferences take multiple inputs and have resources to mix them together ✨ a media server conference is basically a mixer that blends streams. a simple audio mixer just sums its input signals into one common output, but conferences use a fancier move so participants don't hear themselves in the mix 🙈 that algorithm (sometimes called an "n-minus mix") subtracts each participant's own input from the summed inputs, so every contributing participant gets a unique output 💅 each <join> to a conference uses one of the conference's available inputs and/or outputs, up to the max 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 set up by its SIP dialog. the output of a connection can feed several different inputs at once, like a conference mixer AND a recording of that participant's audio 👑
joining two connections that aren't joined to anything else just creates a media stream from the output(s) of one to the matching input(s) of the other 🫶 no mixing needed there. but there are a few common situations where you DO need to combine media from several sources into one input to a connection 😭
first up, a connection might be receiving media from one source (like a conference), and you need to play an announcement to it so both the conference audio and the announcement can be heard by the participant. this is called a "whisper announcement" 🤫 an alternative is letting the announcement preempt the conference media instead.
another one is the call-center coaching vibe 🎧 a supervisor listens to the conversation between an agent and a customer, and gives the agent hints that the customer can't hear.
both of these can be solved by having the controlling AS create one or more conferences for audio mixing, then join and unjoin the media streams as required. a better move (periodt) is having the media server automatically mix media streams that get joined to a common input, whenever only that simple summing of audio signals is needed. that's the case for both use cases above ✨
auto-mixing has several perks. it's conceptually straightforward and simple, and it needs no indirect requests from the controlling AS 💅 that boosts transport efficiency and cuts down on coordination complexity and the latency of the overall operation 🚀. so 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 <createconference> 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 for a connection with a single RTP session per media type 🌈
4.2.2.2. <join>
the <join> element gets 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 they can be bidirectional or unidirectional 🦋 a bidirectional stream is implicitly made 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).
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 specifies a conference identifier and the conference doesn't exist on the MS, the MS reports an error (406). if id1 or id2 specifies a connection identifier and the connection doesn't 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, the default is to join all streams between the entities according to the media configuration of the connection or conference 🍓
you can specify one or more <stream> elements so individual media streams can be controlled independently 🎀 for example, if a connection supports both audio and video, a <stream> element could indicate that only the audio stream is used in receive mode. when there are multiple media streams of the same type for a connection or conference, the configuration MUST be explicitly specified using <stream> elements 💅
you can also use multiple <stream> elements for precise control over the media flow in different directions within the same media stream ✨ one <stream> element can be for the receiving media flow and another for the sending media flow, and each one independently controls things like volume (see the child element of <stream> in Section 4.2.2.5). if there's 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 🫶
if the MS can't execute the join as specified in <stream> because a <stream> element conflicts with (a) another <stream> element, (b) specified connection or conference media capabilities (including supported or available codec information), or (c) a 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), MUST NOT join the entities, and MUST NOT change existing streams of the entities 😭
if the MS can't execute the join as specified in <stream> elements because the MS doesn't support the media stream configuration, the MS reports an error (422), MUST NOT join the entities, and MUST NOT change existing streams of the entities 💀
if the MS can't join an entity to a conference because the conference is full, the MS reports an error (410) 🙃
if the specified entities are already joined, the MS reports an error (408) 🧚
if the MS doesn't support joining two specified connections together, the MS reports an error (426) 🥲
if the MS doesn't support joining two specified conferences together, the MS reports an error (427) 🥲
if the MS can't 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 a <response> element (Section 4.2.3) 💌
here's an example of a request to join two connections together:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="1536067209:913cd14c" id2="1536067209:913cd14c"/>
</mscmixer>and this is the response if the MS doesn't support joining media streams between connections 🫠
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="426" reason="mixing connections not supported"/>
</mscmixer>4.2.2.3. <modifyjoin> ✨
okay bestie, <modifyjoin> is the request you send when you want to tweak streams that are already connected 🎀 between a connection and a conference, between two connections, or between two conferences. it's basically a glow-up for an existing join 💅
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> 🫶 and it MUST configure the streams included within <modifyjoin> to what the child elements say. no vibes-based configuring allowed 💅
if the MS can't modify the join the way the <stream> elements ask, because a <stream> is in conflict with (a) another <stream> element, (b) the 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 it reports an error (407). in that case the MS MUST NOT modify the join between the entities and MUST NOT change existing streams of the entities. 😭
if the MS can't modify the join because it doesn't support the media stream configuration, it reports an error (422). and again, the MS MUST NOT modify the join between the entities and MUST NOT change existing streams of the entities. the vibe stays exactly the same 🧚
if the specified entities aren't already joined, the MS reports an error (409) 💀
if the MS is unable to modify the join between the specified entities for any other reason, it reports an error (411) 🙈
when the MS is finished processing a <modifyjoin> request, it MUST reply with an appropriate <response> element (Section 4.2.3). no ghosting 👑
okay, now the directionality part, which is lowkey the most important bit 🌸. if stream characteristics are controlled independently for each direction, a <modifyjoin> request has to include a child element for each direction, or else you'll accidentally change the original stream directionality. for example, say a <join> sets up 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 this <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 change the sendonly volume, but ALSO make the overall stream directionality change from sendrecv to sendonly, since there's no <stream> element in this <modifyjoin> request for the recvonly direction. oops 😬 (sorry, I'm not yelling, that's just how the spec is written, we're just keeping it accurate 🙈)
to change the sendonly volume and keep the recvonly stream together with its original characteristics (like its volume), you'd do this instead:
<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 how you tell the MS to remove previously established media stream(s) from between a connection and a conference, between two connections, or between two conferences. it's the breakup text, but make it organized 💅
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 it's not present, all currently established streams between "id1" and "id2" get removed 🧹
the MS MUST support <unjoin> for any stream that was established using <join> and that hasn't already been removed by a previous <unjoin> on the same stream. ✨
if the MS can't terminate the join the way the <stream> elements ask, because a <stream> is in conflict with (a) another <stream> element, (b) the 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 it reports an error (407). the MS MUST NOT terminate the join between the entities and MUST NOT change existing streams of the entities. 😭
if the MS can't terminate the join the way the <stream> elements ask, because it doesn't support the media stream configuration, it reports an error (422). the MS MUST NOT terminate the join between the entities and MUST NOT change existing streams of the entities. it's still giving stability 🌈
if the specified entities aren't already joined, the MS reports an error (409) 💀
if the MS can't terminate the join between the specified entities for any other reason, it reports an error (411) 🙈
when the MS has successfully processed a <unjoin> request, it MUST reply with a successful <response> element (Section 4.2.3). 👑
4.2.2.5. <stream> 🍓
okay this one is the star of the whole show ✨. <join>, <modifyjoin>, and <unjoin> all need to identify and manipulate media streams. a media stream is the flow of media between a participant connection and a conference, between two connections, or between two conferences. the <stream> element is a child of <join>, <modifyjoin>, and <unjoin>, and it's used to pick out which stream(s) the request is about and to set how that stream is configured 💖
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.
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 whatever the direction attribute of the parent element says 🎯
if the media attribute doesn't have the value "audio", the MS ignores <volume> and <clamp> elements. 🙅♀️
if the media attribute doesn't have the value "video", the MS ignores a <region> element. 🙅♀️
for example, here's a request to join a connection to a conference in both directions with volume control:
<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>here the audio flowing from the connection (id1) to the conference (id2) gets lowered by 3 dB, and the audio flowing from the conference back to the connection also gets lowered by 3 dB 🎧
in this example the volume is controlled independently for each direction 🌸:
<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>so the audio from the connection (id1) to the conference (id2) gets lowered by 3 dB, but the audio from the conference to the connection gets raised by 3 dB 🔥
4.2.2.5.1. <volume> 🌈
the <volume> element configures the volume of an audio media stream. it can be set to a specific gain amount, set to automatically adjust the gain to a desired target level, or used 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 muted, the MS also automatically changes the state to unmuted when you use an "automatic" or "setgain" volume control 🔊. for example, say an audio stream was muted with <volume controltype="setstate" value="mute"/>. if you then change the gain on that same stream with <volume controltype="setgain" value="+3"/>, the volume goes up AND the stream state flips to unmuted. main character energy, no notes 💅
4.2.2.5.2. <clamp> 🧹
Okay bestie, the <clamp> element is the one that decides whether certain tones get filtered out of a media stream. 💅 It's basically a bouncer for DTMF tones ✨ (DTMF = Dual-Tone Multi-Frequency). It has no child elements, just one attribute, and it's giving very precise energy 🎀
tones: a space-separated list of the tones to remove. This attribute is optional. Its default is"1 2 3 4 5 6 7 8 9 0 * # A B C D", which means all DTMF (Dual-Tone Multi-Frequency) tones get removed. 🫶
4.2.2.5.3. <region> 🌸
So, as we talked about in Section 4.2.1.4.2.1, each <video-layout> is made up of one or more named regions (or areas) where video media can show up 📺 For example, the XCON layout <dual-view> has two regions, named "1" and "2". Iconic layout, no notes 💖
The <region> element is used to explicitly name the area inside a video layout where a video media stream gets displayed. It has no attributes, and its content model is what specifies the name of the region. Simple, clean, slay ✨
4.2.2.5.4. <priority> 👑
The <priority> element explicitly sets the priority of a participant. The MS uses this priority to decide where the media stream is displayed within a video layout (Section 4.2.1.4.3.1). 🦋
It has no attributes, and its content model is a positive integer (see Section 4.7.3). Here's the twist 🙈: the lower the value, the higher the priority. So 1 is the VIP seat. 😭
4.2.3. <response> 💜
Responses to requests get indicated by a <response> element. Main character moment for this one 🌈
The <response> element has the following attributes:
status: a numeric code indicating the response status. Valid values are defined in Section 4.6. This attribute is mandatory. 🔥reason: a string specifying a reason for the response status. This attribute is optional.desclang: specifies the language used in the value of thereasonattribute. A valid value is a language identifier (Section 4.7.7). This attribute is optional. If it's not specified, the value of thedesclangattribute on<mscmixer>(Section 4.1) applies. 🌍conferenceid: a string identifying the conference (see Appendix A.1 of [RFC6230]). This attribute is optional.connectionid: a string identifying the SIP dialog connection (see Appendix A.1 of [RFC6230]). This attribute is optional. 📞
For example, a response when a conference gets created successfully looks like this:
<response code="200"/>And if conference creation fails because the requested conference ID already exists, the response is:
<response code="405" reason="Conference already exists"/>Oop, that's a whole vibe check 💀
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 it 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). Who's been talking, bestie? 👀
It has the following attribute:
conferenceid: a string indicating the name of the conference the event came from. This attribute is mandatory.
It also has the following sequence of child elements (zero or more occurrences):
<active-talker>: an 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 a conference participant in a conference. 💖
It has the following attributes:
connectionid: a string indicating the connectionid of the active talker. This attribute is optional. There is no default value.conferenceid: a string indicating the conferenceid of the active talker. This attribute is optional. There is no default value.
Now listen, this part is so important 🙈 The element does not describe an active talker if both the connectionid and conferenceid attributes are specified, or if neither attribute is specified. Be careful with those two, periodt 💅
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. Bye bye, connection 👋
It 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.
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). This 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). This attribute is optional. There is no default value.desclang: specifies the language used in the value of thereasonattribute. A valid value is a language identifier (Section 4.7.7). This attribute is optional. If it's not specified, the value of thedesclangattribute 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]. This 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]. This 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, either because it got terminated or because an error happened (for example, a hardware error in the conference mixing unit). 😭 This event MUST be sent by the MS whenever a successfully created conference exits. No skipping this one, fr fr 🫶
It has the following attributes:
conferenceid: a 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.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). This 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). This attribute is optional. There is no default value.desclang: specifies the language used in the value of thereasonattribute. A valid value is a language identifier (Section 4.7.7). This attribute is optional. If it's not specified, the value of thedesclangattribute on<mscmixer>(Section 4.1) applies. 🌍
The <conferenceexit> element has no child elements.
When an 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. Fresh start, new conference, who dis 🧚
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 let the MS be audited for package capabilities, as well as for mixers managed by the package. Auditing is seriously important for two use cases, bestie 🎀
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 that info to create request elements using supported capabilities and, when it comes to codecs, to negotiate an appropriate SDP for a user agent's connection. 💅
Second, auditing enables discovery of the existence and status of mixers currently managed by the package on the MS. This could be used when one AS takes over management of mixers if the AS that created the mixers fails or is no longer available (see the security considerations in Section 7). Hand-off energy, lowkey iconic 🫶
4.3.1. <audit> 💅
okay so the <audit> element is how you ask the MS 🧚 for the tea on two things: what it's capable of, and what mixers it's currently managing with this Control Package. "Capabilities" means the supported conference codecs and video layouts. "Mixer information" means the status of the managed mixers plus their codecs. literally a full vibe check 🔍✨
The <audit> element has the following attributes:
capabilities: this decides whether package capabilities get audited. The valid value is a boolean (see Section 4.7.1)."true"means capability info gets reported, and"false"means it doesn't. The attribute is optional, and the default is"true"🎀mixers: same energy, but for mixers currently managed by the package. The valid value is a boolean (see Section 4.7.1)."true"means mixer info gets reported, and"false"means it doesn't. The attribute is optional, and the default is"true"🌸conferenceid: a string identifying one specific conference mixer to audit. If theconferenceidattribute is specified and the conference identifier isn't valid, that's an error (406) 🙈 The attribute is optional and there's no default value.
okay this part is important bestie 👀 ifmixersis"true"AND you've specified aconferenceid, then only the audit info for that one conference mixer gets reported. ifmixersis"false", no mixer audit info comes back at all, even if you included aconferenceid. no exceptions 💀
The <audit> element has no child elements. zero. none. nada 🫶
When the MS gets an <audit> request, it MUST reply with an <auditresponse> element (Section 4.3.2). That response has a mandatory attribute describing the status with a numeric code. Response status codes are defined in Section 4.6. If the request works, the <auditresponse> contains (depending on the attribute values) a <capabilities> element (Section 4.3.2.1) reporting package capabilities, and a <mixers> element (Section 4.3.2.2) reporting managed mixer info. If the MS can't 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 to figure out the right status code for the response 🔥
Here's an example of a request to audit the capabilities and mixers managed by the package:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<audit/>
</mscmixer>In this example, only capabilities are being audited:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<audit mixers="false"/>
</mscmixer>And with this one, only a specific conference mixer gets 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 an <audit> request. it's giving reply energy 💖
The <auditresponse> element has the following attributes:
status: a numeric code indicating the audit response status. The attribute is mandatory. Valid values are defined in Section 4.6.reason: a string giving a reason for the status. The attribute is optional.desclang: specifies the language used in the value of thereasonattribute. The valid value is a language identifier (Section 4.7.7). The attribute is optional. If it isn't specified, the value of thedesclangattribute on<mscmixer>(Section 4.1) applies 🌈
The <auditresponse> element has the following sequence of child elements:
<capabilities>: an element describing the capabilities of the package (see Section 4.3.2.1). The element is optional.<mixers>: an element describing info about managed mixers (see Section 4.3.2.2). The element is optional.
Here's an example of a successful response to an <audit> request for capabilities and mixer info:
<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>4.3.2.1. <capabilities> ✨
The <capabilities> element provides audit info about package capabilities.
The <capabilities> element has no attributes.
The <capabilities> element has the following sequence of child elements:
<codecs>: an element (Section 4.4) describing the codecs available to the package. The element is mandatory.
For example, here's a fragment describing capabilities:
<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 info 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 info for a conference mixer (Section 4.3.2.2.1). The element is optional.<joinaudit>: audit info for a join mixer (Section 4.3.2.2.2). The element is optional.
4.3.2.2.1. <conferenceaudit> 🍓
The <conferenceaudit> element has the following attribute:
conferenceid: a 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>: an element describing the codecs used in the conference. See Section 4.4. The element is optional.<participants>: an element listing the connections or conferences joined to the conference. See Section 4.3.2.2.1.1. The element is optional.<video-layout>: an element describing the active video layout for the conference. See Section 4.2.1.4.2.1. The element is optional.
For example, here's a fragment describing a conference that's been created but has no participants:
<conferenceaudit conferenceid="conference1"/>And here's a fragment for when the same conference has three participants joined to it (two connections and another conference) 👑
<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):
<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, here's a fragment describing an audit of two join mixers, one between connections and the second between conferences:
<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. An AS uses codec definitions to specify the codecs allowed for a conference (for example, when used as a child of <createconference> or <modifyconference)). An MS uses codec definitions to provide audit info about the codecs it supports and the codecs used in specific conferences ✨
The <codecs> element has no attributes.
The <codecs> element has the following sequence of child elements (zero or more occurrences):
<codec>: defines a codec and optionally its policy (Section 4.4.1). The element is optional.
For example, here's a fragment describing two codecs:
<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. It's modeled on the <codec> element in the XCON conference information data model ([RFC6501]) and allows additional information (for example, 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>: an 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>: an 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, here's a fragment with a <codec> element describing the H263 codec:
<codec name="video">
<subtype>H263</subtype>
</codec>And here's a fragment where the <codec> element describes the H264 video codec, with extra info about the profile level and packetization mode 🔥
<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> 💖
Okay so the <params> element is basically a little bag 👜 that holds <param> elements (Section 4.5.1). That's its whole job, and it's a very cute job.
The <params> element has no attributes, but it can hold the following child elements (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, bestie.
The <param> element has the following attributes:
name: a string naming the parameter. This one is mandatory, so no skipping it 🙅♀️type: says how the in-line value of the parameter should be read. A valid value is a MIME media type (see Section 4.7.6). It's optional, and if you leave it out, the default is"text/plain"📝encoding: names a content-transfer-encoding schema that gets applied to the in-line value, on top of whatever MIME media type thetypeattribute says. A valid value is a content-transfer-encoding schema as defined by the"mechanism"token in Section 6.1 of [RFC2045]. This one is optional and has no default value, so it's giving "only if you need it" 🦋
The <param> element content model is the value of the parameter itself. Heads up, though: if the value has XML characters in it (like <), you have to escape it using standard XML conventions. Otherwise the parser is going to get confused, and nobody wants that 😭
4.6. Response Status Codes 🚦
This section covers 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, no exceptions 👑. Any other valid but undefined values are reserved for future use, and new status codes get assigned through the Standards Action process defined in [RFC5226] 🔮
The AS MUST treat any response it doesn't recognize as the same thing as the x00 response code, for all classes. For example, if an AS gets an unrecognized response code of 499, it can safely assume something went wrong with its request, and it should treat that response as if it had received a 400 (Syntax error) response code. Honestly that's such a relief 🥹
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. Fixing a syntax error or switching to a conferenceid the MS actually has would count as modifying it, for example. However, the same request sent to a different MS might work, like if that other MS supports a capability the request needs 🌸
4xx failure responses sort 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) - failure due to the request requiring a capability the MS doesn't support (
420-435)
If more than one code could be reported for the same failure, the MS SHOULD use the most specific error code from the failure class for the error it detected. For example, if the MS detects that the conference identifier in the request is invalid, it uses a 406 status code. But if the MS only detects that an execution error happened, then it uses 419 🧠✨
okay so the status code table is literally the main character of this section 💅✨ every code gets a summary, a description, and a "what do i do now" column, so you always know your next move 🫶
+-------+---------------+----------------------+--------------------+
| 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. |
| | | | |
| 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. | |
| | | | |
| 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. | |
| | | | |
| 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 | |more codes are coming up next, bestie 🦋🌸
4.6. Response Status Codes ✨
| | | MS. | |
+-------+---------------+----------------------+--------------------+Table 1: Status Codes
4.7. Type Definitions 🎀
okay bestie, this section is the vocab list 📖 It defines the types that the attribute definitions lean on, so you always know exactly what a value is allowed to look like 💅
4.7.1. Boolean
so the boolean value space is {true, false, 1, 0}, as defined in Section 3.2.2 of [XMLSchema:Part2] 💖 which means false can be written as "0" or "false", and true can be written as "1" or "true". Both styles are legit, and implementations MUST support both styles of lexical representation 🫶
4.7.2. Non-Negative Integer
the non-negative integer value space is the infinite set {0,1,2,...}, as defined in Section 3.3.20 of [XMLSchema:Part2]. Zero counts, and it just keeps going forever 🌈
4.7.3. Positive Integer
the positive integer value space is the infinite set {1,2,...}, as defined in Section 3.3.25 of [XMLSchema:Part2]. Zero is NOT invited to this one 🙈
4.7.4. String
a string here is whatever sits 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 is a non-negative real number followed by a time unit identifier ⏰ The only two 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
this is a string formatted as an IANA MIME media type [MIME.mediatypes] 📮 The ABNF ([RFC5234]) production for the string looks like this:
media-type = type-name "/" subtype-name *(";" parameter)
parameter = parameter-name "=" valuewhere "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 📜 It 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, and the schema is extensible, so elements allow attributes and child elements from other namespaces 🧚
Elements from outside this package's namespace can occur after elements defined in this package.
The schema is dependent upon the schema (framework.xsd) defined in Appendix A.1 of the Control Framework [RFC6230] 🎀
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-mixer"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:msc-mixer"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
IETF MediaCtrl Mixer 1.0 (20110104)
This is the schema of the Mixer Control Package. It
defines request, response, and notification elements for
mixing.
The schema namespace is urn:ietf:params:xml:ns:msc-mixer
</xsd:documentation>
</xsd:annotation>
<!--
#############################################################
SCHEMA IMPORTS
#############################################################
-->
<xsd:import
namespace="urn:ietf:params:xml:ns:control:framework-attributes"
schemaLocation="framework.xsd">
<xsd:annotation>
<xsd:documentation>
This import brings in the framework attributes for
conferenceid and connectionid.
</xsd:documentation>
</xsd:annotation>
</xsd:import>
<!--
#####################################################
Extensible core type
#####################################################
-->
<xsd:complexType name="Tcore">
<xsd:annotation>
<xsd:documentation>
This type is extended by other (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" />
<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 -->
<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
#####################################################
-->
<xsd:complexType name="joinType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="stream" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other"
processContents="lax" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="id1" type="xsd:string"
use="required" />
<xsd:attribute name="id2" type="xsd:string"
use="required" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="join" type="joinType" />
<xsd:complexType name="modifyjoinType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="stream" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other"
processContents="lax" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="id1" type="xsd:string"
use="required" />
<xsd:attribute name="id2" type="xsd:string"
use="required" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="modifyjoin" type="modifyjoinType" />
<xsd:complexType name="unjoinType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="stream" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other"
processContents="lax" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="id1" type="xsd:string"
use="required" />
<xsd:attribute name="id2" type="xsd:string"
use="required" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="unjoin" type="unjoinType" />
<!--
#####################################################
OTHER TYPES
#####################################################
-->
<xsd:complexType name="eventType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:choice>
<xsd:element ref="active-talkers-notify"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="unjoin-notify"
minOccurs="0" maxOccurs="1" />
<xsd:element ref="conferenceexit"
minOccurs="0" maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="event" type="eventType" />
<xsd:complexType name="activetalkersnotifyType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="active-talker" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="conferenceid" type="xsd:string"
use="required" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-talkers-notify"
type="activetalkersnotifyType" />okay bestie, this chunk is pure XML schema lore 🎀 it defines the active talker, unjoin notify, conference exit, response, subscribe, stream, volume, clamp, audio mixing, video switch, video layouts, audit, and mixers types, so it's giving full conference-control energy ✨
<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" />
<!-- 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"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="subscribe" type="subscribeType" />
<xsd:complexType name="activetalkerssubType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="interval"
type="xsd:nonNegativeInteger" default="3" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="active-talkers-sub"
type="activetalkerssubType" />
<xsd:complexType name="streamType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="volume" minOccurs="0"
maxOccurs="1" />
<xsd:element ref="clamp" minOccurs="0"
maxOccurs="1" />
<xsd:element ref="region" minOccurs="0"
maxOccurs="1" />
<xsd:element ref="priority" minOccurs="0"
maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="media" type="media.datatype"
use="required" />
<xsd:attribute name="label" type="label.datatype" />
<xsd:attribute name="direction"
type="direction.datatype" default="sendrecv" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="stream" type="streamType" />
<xsd:complexType name="volumeType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="controltype"
type="volumecontroltype.datatype" use="required" />
<xsd:attribute name="value" type="xsd:string" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="volume" type="volumeType" />
<xsd:complexType name="clampType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="tones" type="xsd:string"
default="1 2 3 4 5 6 7 8 9 0 * # A B C D"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="clamp" type="clampType" />
<!-- region -->
<xsd:simpleType name="regionType">
<xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType>
<xsd:element name="region" type="regionType" />
<!-- priority -->
<xsd:simpleType name="priorityType">
<xsd:restriction base="xsd:positiveInteger" />
</xsd:simpleType>
<xsd:element name="priority" type="priorityType" />
<xsd:complexType name="audiomixingType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd: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>
<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"
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>
<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>Okay so we're picking up right where the schema left off, so let's keep the vibe going 🎀
<xsd:element name="conferenceaudit" type="conferenceauditType" />
<!-- participants -->
<xsd:complexType name="participantsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="participant" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="participants" type="participantsType" />
<!-- participant -->
<xsd:complexType name="participantType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="id" type="xsd:string"
use="required" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="participant" type="participantType" />
<!-- capabilities -->
<xsd:complexType name="capabilitiesType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="codecs" minOccurs="1"
maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="capabilities" type="capabilitiesType" />
<!-- codecs -->
<xsd:complexType name="codecsType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="codec" minOccurs="0"
maxOccurs="unbounded" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="codecs" type="codecsType" />
<!-- codec -->
<xsd:complexType name="codecType">
<xsd:complexContent>
<xsd:extension base="Tcore">
<xsd:sequence>
<xsd:element ref="subtype" minOccurs="1"
maxOccurs="1" />
<xsd:element ref="params" minOccurs="0"
maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd: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 -->
<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>
<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 🧚
6. Examples ✨
This section is all about examples of the Mixer Control Package, so get ready to see it in action 💅
6.1. AS-MS Framework Interaction Examples
Quick setup check: these examples assume a Control Channel has already been established and synced, as described in the Media Control Channel Framework ([RFC6230]) 🦋
Heads up, the XML messages are wrapped in angled brackets, and the root <mscmixer> plus some other details are left out so things stay readable. The REPORT status is shown in parentheses. Everything else about the protocol is skipped here, just to keep the diagrams from getting messy 🙈
6.1.1. Creating a Conference Mixer and Joining a Participant
This one is the happy path, bestie 🌸 A conference mixer gets created successfully, and then a participant joins.
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 |
| ----------------------------------------> |6.1.2. Receiving Active Talker Notifications
Here the MS is the one doing the talking 🎤 An active talker notification event gets sent by the MS.
Application Server (AS) Media Server (MS)
| |
| (1) CONTROL: <event ...> |
| <--------------------------------------- |
| |
| (4) 200 |
| ----------------------------------------> |
| |6.1.3. Conference Termination
Ending the party 🥺 The MS gets a request to terminate the conference, and that leads to 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
Okay so the mixing package is the star here ✨ These examples show how it can be used to create audio conferences, bridge connections, and video conferences 🎀
Just so you know: the examples don't spell out every single message between the AS and MS, so don't expect a full transcript 💜
6.2.1. Audio Conferencing 🎀
okay so the AS starts by sending 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 gives the conference the id "conf1" and sets it up with 2 reserved talkers, 3 reserved listener slots, an nbest audio-mixing policy, and active talkers notifications every 5 seconds ✨
If the MS can create this conference mixer, it sends back a 200 response 🫶
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200" reason="conference created"
conferenceid="conf1"/>
</mscmixer>Now the AS can join connections to the conference as participants 🦋 A participant who can contribute to the audio mix gets joined like this:
<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 participant 1536067209:913cd14c to conf1 with audio going both ways, 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 can also add listener-only participants by setting the stream direction to receive only 🎧 It's giving "just here for the vibes" energy 💜
<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 participant 9936067209:914cd14c to conf1, 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>Sometimes the AS decides a talker should only listen from now on, so it changes that connection's status like this:
<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>So participant 1536067209:913cd14c can no longer contribute to the audio mix on the conference 🤐 If the MS can carry out this request, it would send a 200 response.
The AS can also decide to remove this participant from the conference entirely:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<unjoin id1="1536067209:913cd14c" id2="conf1"/>
</mscmixer>Again, if the MS can do this, a 200 response would be sent 💖
Finally, the AS ends the conference 🌈
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<destroyconference conferenceid="conf1"/>
</mscmixer>If the MS can destroy 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 every participant still attached when the conference gets 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 when the conference is finally gone, the MS sends a conferenceexit notification event 👑
<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 also be used to join connections to one another 🧚 In a call-center scenario, for example, it can set up and modify connections between a caller, an agent, and a supervisor. so cute, right? 🥹
A caller gets 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 can set up this connection, it would send a 200 response:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200"/>
</mscmixer>Now say the AS wants a supervisor to listen in on the agent and caller conversation and give whispered guidance to the agent 🤫 First, the AS sends 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 that request works, audio output from the caller connection is now sent to both the agent and the supervisor 👀
Second, the AS sends 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 one works too, audio mixing happens on both the agent and supervisor connections. The agent hears the caller and the supervisor, and the supervisor hears the agent and the caller. The caller only hears the agent 💅 If the MS can't join and mix the connections 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 gets the most prominent region in the video layout 📺
The AS sends a request to create an audio-video conference:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference conferenceid="conf2">
<audio-mixing type="nbest"/>
<video-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 setup, the conference uses an nbest audio mixing policy and a <vas/> video-switching policy, so the loudest speaker gets the most prominent region in the layout 👑 Several video layouts are specified, and which one is active depends on how many participants there are 🌈
Let's say 4 participants are already joined to the conference. In that case, the video layout is quad-view (Figure 6) with the most active speaker shown 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 also control which participants show up 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 🔒✨
Okay bestie, this part is SERIOUS, so let's get into it. Since 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 sent 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. Also, implementations MUST address security, confidentiality, and integrity of User Agent sessions with the MS, both for SIP signaling and for the associated RTP media flow. See [RFC6230] for more details 💜.
Adequate transport protection and authentication are critical, especially when the implementation is deployed in open networks. If the implementation doesn't handle these issues correctly, 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, which denies the AS access to package capabilities. 😭 - Resource Exhaustion: An attacker could insert new request messages into the Control Channel (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 creating conference and join mixers is tied to media-mixing resources on the MS, the security policy for this Control Package needs to cover how those mixers are securely managed across more than one Control Channel. A security policy like that is only useful for secure, confidential, and integrity-protected channels. The identity of a Control Channel is determined by its channel identifier, which is the value of the 'cfw-id' attribute in the SDP and the Dialog-ID header in the channel protocol (see [RFC6230]). Channels are the same if they have the same identifier, and different otherwise. 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 that was used to send the request.
- Notifications: The MS MUST only send notification events for conference and join mixers using the same Control Channel that it received the request creating the mixer on.
- Auditing: The MS MUST only provide audit information about conference and join mixers that were created on the same Control Channel that the
<audit>request is sent on. 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 a request on channel 'cfw98969' to audit or destroy that conference, then the MS sends a Control Framework 403 response. 👑
There can be valid reasons why an implementation doesn't reject an audit or mixer manipulation request on a different channel from the one that created the mixer. For example, a system administrator might need a separate channel to audit mixer resources created by system users and to terminate mixers that are using up excessive system resources. Alternatively, a system monitor or resource broker might need a separate channel to audit mixers managed by this package on an MS. However, the full implications need to be understood by the implementation and carefully weighed before accepting these reasons as valid. If the reasons aren't 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 Control Channels using the same channel identifier, one after another. For example, assume a channel is created with the identifier 'cfw1234' and is used to create mixers on the MS. This channel (and its 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 aren't valid for their particular circumstances, the MS uses the appropriate SIP mechanisms to prevent session establishment when the same channel identifier is used to set 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 also 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).
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>
END8.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.
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 Registry9. Contributors 🎀
Asher Shiratzky provided valuable support and contributions to early draft versions of this document.
The authors would like to thank the Mixer design team, consisting of Roni Even, Lorenzo Miniero, Adnan Saleem, Diego Besprosvan, and Mary Barnes, who provided valuable feedback, input, diagrams, and text to this document. 🫶
10. Acknowledgments 🧚
The authors would like to thank Steve Buko and Stephane Bastien for expert reviews of this work.
Shawn Emery carried out a thorough security review. 👑
11. References 📚
11.1. Normative References
okay bestie, these are the receipts the spec leans on hardcore 🧾✨ you need these to fully understand the vibe
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
- [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
- [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
- [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
- [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
- [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
- [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media Control Channel Framework", RFC 6230, May 2011.
- [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012.
- [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008,
http://www.w3.org/TR/2008/REC-xml-20081126. - [XMLSchema:Part2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004.
11.2. Informative References
these ones are extra context, not required reading, but they're so good to know 🦋
- [IANA] IANA, "RTP Payload Types",
http://www.iana.org/assignments/rtp-parameters. - [MIME.mediatypes] IANA, "MIME Media Types",
http://www.iana.org/assignments/media-types. - [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007.
- [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008.
- [RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup Language (MSML)", RFC 5707, February 2010.
Authors' Addresses 💌
- Scott McGlashan, Hewlett-Packard, EMail:
smcg.stds01@mcglashan.org - Tim Melanchuk, Rainwillow, EMail:
timm@rainwillow.com - Chris Boulton, NS-Technologies, EMail:
chris@ns-technologies.com
and that's the whole spec, bestie!! 🌈💖👑 🫶
📦 where this page comes from
- ietf: rfc6505 2012-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms