A Mixer Control Package for the Media Control Channel Framework :: RFC6505
Internet Engineering Task Force (IETF) S. McGlashan
Request for Comments: 6505 Hewlett-Packard
Category: Standards Track T. Melanchuk
ISSN: 2070-1721 Rainwillow
C. Boulton
NS-Technologies
March 2012
A Mixer Control Package for the Media Control Channel Framework
Abstract
This document defines a Media Control Channel Framework Package for
managing mixers for media conferences and connections. The package
defines request elements for managing conference mixers, managing
mixers between conferences and/or connections, as well as associated
responses and notifications. The package also defines elements for
auditing package capabilities and mixers.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6505.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
McGlashan, et al. Standards Track [Page 1]
RFC 6505 Mixer Control Package March 2012
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Control Package Definition . . . . . . . . . . . . . . . . . . 6
3.1. Control Package Name . . . . . . . . . . . . . . . . . . . 6
3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 6
3.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 7
3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 7
3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 7
3.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 8
4.1. . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Mixer Elements . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Conference Elements . . . . . . . . . . . . . . . . . 12
4.2.1.1. . . . . . . . . . . . . . . . . 12
4.2.1.2. . . . . . . . . . . . . . . . . 14
4.2.1.3. . . . . . . . . . . . . . . . 16
4.2.1.4. Conference Configuration . . . . . . . . . . . . . 16
4.2.1.4.1. . . . . . . . . . . . . . . . . 16
4.2.1.4.2. . . . . . . . . . . . . . . . 17
4.2.1.4.2.1. . . . . . . . . . . . . . . 18
4.2.1.4.3. . . . . . . . . . . . . . . . . 24
4.2.1.4.3.1. Priority Assignment . . . . . . . . . . . 26
4.2.1.4.4. . . . . . . . . . . . . . . . . . 27
4.2.1.4.4.1. . . . . . . . . . . . 27
4.2.2. Joining Elements . . . . . . . . . . . . . . . . . . . 28
4.2.2.1. Joining Model . . . . . . . . . . . . . . . . . . 28
4.2.2.2. . . . . . . . . . . . . . . . . . . . . . . 29
4.2.2.3. . . . . . . . . . . . . . . . . . . . 32
4.2.2.4. . . . . . . . . . . . . . . . . . . . . . 34
4.2.2.5. . . . . . . . . . . . . . . . . . . . . . 35
4.2.2.5.1. . . . . . . . . . . . . . . . . . . . 37
4.2.2.5.2. . . . . . . . . . . . . . . . . . . . 38
4.2.2.5.3. . . . . . . . . . . . . . . . . . . . 38
McGlashan, et al. Standards Track [Page 2]
RFC 6505 Mixer Control Package March 2012
4.2.2.5.4. . . . . . . . . . . . . . . . . . . 38
4.2.3. . . . . . . . . . . . . . . . . . . . . . . 38
4.2.4. . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.4.1. . . . . . . . . . . . . . 39
4.2.4.1.1. . . . . . . . . . . . . . . . 40
4.2.4.2. . . . . . . . . . . . . . . . . . 40
4.2.4.3. . . . . . . . . . . . . . . . . . 41
4.3. Audit Elements . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1. . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2. . . . . . . . . . . . . . . . . . . . 44
4.3.2.1. . . . . . . . . . . . . . . . . . . 46
4.3.2.2. . . . . . . . . . . . . . . . . . . . . . 46
4.3.2.2.1. . . . . . . . . . . . . . . 47
4.3.2.2.1.1. . . . . . . . . . . . . . . 47
4.3.2.2.1.1.1. . . . . . . . . . . . . 48
4.3.2.2.2. . . . . . . . . . . . . . . . . . 48
4.4. . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.1. . . . . . . . . . . . . . . . . . . . . . . . 49
4.5. . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5.1. . . . . . . . . . . . . . . . . . . . . . . . 50
4.6. Response Status Codes . . . . . . . . . . . . . . . . . . 51
4.7. Type Definitions . . . . . . . . . . . . . . . . . . . . . 55
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 56
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.1. AS-MS Framework Interaction Examples . . . . . . . . . . . 75
6.1.1. Creating a Conference Mixer and Joining a
Participant . . . . . . . . . . . . . . . . . . . . . 75
6.1.2. Receiving Active Talker Notifications . . . . . . . . 76
6.1.3. Conference Termination . . . . . . . . . . . . . . . . 76
6.2. Mixing Examples . . . . . . . . . . . . . . . . . . . . . 76
6.2.1. Audio Conferencing . . . . . . . . . . . . . . . . . . 77
6.2.2. Bridging Connections . . . . . . . . . . . . . . . . . 79
6.2.3. Video Conferencing . . . . . . . . . . . . . . . . . . 80
7. Security Considerations . . . . . . . . . . . . . . . . . . . 81
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
8.1. Control Package Registration . . . . . . . . . . . . . . . 84
8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 84
8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 85
8.4. MIME Media Type Registration for
'application/msc-mixer+xml' . . . . . . . . . . . . . . . 85
8.5. Mixer Control Package Status Code Registration . . . . . . 86
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 86
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 87
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 87
11.1. Normative References . . . . . . . . . . . . . . . . . . . 87
11.2. Informative References . . . . . . . . . . . . . . . . . . 88
McGlashan, et al. Standards Track [Page 3]
RFC 6505 Mixer Control Package March 2012
1. Introduction
The Media Control Channel Framework [RFC6230] provides a generic
approach for establishment and reporting capabilities of remotely
initiated commands. The Control Framework -- an equivalent term for
the Media Control Channel Framework -- utilizes many functions
provided by the Session Initiation Protocol (SIP) [RFC3261] for the
rendezvous and establishment of a reliable channel for control
interactions. The Control Framework also introduces the concept of a
Control Package. A Control Package is an explicit usage of the
Control Framework for a particular interaction set. This
specification defines a package for media conference mixers and media
connection mixers.
This package defines mixer management elements for creating,
modifying, and deleting conference mixers, elements for joining,
modifying, and unjoining media streams between connections and
conferences (including mixers between connections), as well as
associated responses and notifications. The package also defines
elements for auditing package capabilities and mixers.
This package has been designed to satisfy media-mixing requirements
documented in the Media Server Control Protocol Requirements document
[RFC5167]; more specifically REQ-MCP-22, REQ-MCP-23, REQ-MCP-24,
REQ-MCP-25, REQ-MCP-26, and REQ-MCP-27.
The package provides the major conferencing functionality of SIP
media server languages such as MSCML [RFC5022] and MSML [RFC5707]. A
key differentiator is that this package provides such functionality
using the Media Control Channel Framework.
Out of scope for this mixer package are more advanced functions
including personalized video mixes for conference participants,
support for floor control protocols, as well as support for video
overlays and text insertion. Such functionality can be addressed by
extensions to this package (through addition of foreign elements or
attributes from another namespace) or use of other Control Packages
that could build upon this package.
The functionality of this package is defined by messages, containing
XML [XML] elements and transported using the Media Control Channel
Framework. The XML elements can be divided into two types: mixer
management elements and audit elements (for auditing package
capabilities and mixers managed by the package).
The document is organized as follows. Section 3 describes how this
Control Package fulfills the requirements for a Media Control Channel
Framework Control Package. Section 4 describes the syntax and
McGlashan, et al. Standards Track [Page 4]
RFC 6505 Mixer Control Package March 2012
semantics of defined elements, including mixer management
(Section 4.2) and audit elements (Section 4.3). Section 5 describes
an XML schema for these elements and provides extensibility by
allowing attributes and elements from other namespaces. Section 6
provides examples of package usage. Section 7 describes important
security considerations for use of this Control Package. Section 8
provides information on IANA registration of this Control Package,
including its name, XML namespace, and MIME media type.
2. Conventions and Terminology
In this document, BCP 14 [RFC2119] defines the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In
addition, BCP 15 indicates requirement levels for compliant
implementations.
The following additional terms are defined for use in this document:
Application Server: A SIP [RFC3261] application server (AS) is a
control client that hosts and executes services such as
interactive media and conferencing in an operator's network. An
AS controls the media server (MS), influencing and impacting the
SIP sessions terminating on an MS, which the AS can have
established, for example, using SIP third-party call control.
Media Server: A media server (MS) processes media streams on behalf
of an AS by offering functionality such as interactive media,
conferencing, and transcoding to the end user. Interactive media
functionality is realized by way of dialogs, which are identified
by a URI and initiated by the application server.
MS Conference: An MS Conference provides the media-related mixing
resources and services for conferences. In this document, an MS
Conference is often referred to simply as a conference.
MS Connection: An MS connection represents the termination on a
media server of one or more RTP [RFC3550] sessions that are
associated to a single SIP dialog. A media server receives media
from the output(s) of a connection, and it transmits media on the
input(s) of a connection.
Media Stream: A media stream on a media server represents a media
flow between either a connection and a conference, between two
connections, or between two conferences. Streams can be audio or
video and can be bidirectional or unidirectional.
McGlashan, et al. Standards Track [Page 5]
RFC 6505 Mixer Control Package March 2012
3. Control Package Definition
This section fulfills the mandatory requirement for information that
MUST be specified during the definition of a Control Framework
Package, as detailed in Section 8 of [RFC6230].
3.1. Control Package Name
The Control Framework requires a Control Package definition to
specify and register a unique name. The name and version of this
Control Package is "msc-mixer/1.0" (Media Server Control - Mixer -
version 1.0). Its IANA registration is specified in Section 8.1.
Since this is the initial ("1.0") version of the Control Package,
there are no backwards compatibility issues to address.
3.2. Framework Message Usage
The Control Framework requires a Control Package to explicitly detail
the control messages that can be used as well as provide an
indication of directionality between entities. This will include
which role type is allowed to initiate a request type.
This package specifies CONTROL and response messages in terms of XML
elements defined in Section 4, where the message bodies have the MIME
media type defined in Section 8.4. These elements describe requests,
responses, and notifications, and all are contained within a root
element (Section 4.1).
In this package, the MS operates as a Control Server in receiving
requests from, and sending responses to, the AS (operating as a
Control Client). Mixer management requests and responses are defined
in Section 4.2. Audit requests and responses are defined in
Section 4.3. Mixer management and audit responses are carried in a
framework 200 response or REPORT message bodies. This package's
response codes are defined in Section 4.6.
Note that package responses are different from framework response
codes. Framework error response codes (see Section 7 of [RFC6230])
are used when the request or event notification is invalid, for
example, a request is invalid XML (400) or not understood (500).
The MS also operates as a Control Client in sending event
notification to the AS (Control Server). Event notifications
(Section 4.2.4) are carried in CONTROL message bodies. The AS MUST
respond with a Control Framework 200 response.
McGlashan, et al. Standards Track [Page 6]
RFC 6505 Mixer Control Package March 2012
3.3. Common XML Support
The Control Framework requires a Control Package definition to
specify if the attributes for media dialog or conference references
are required.
This package requires that the XML schema in Appendix A.1 of
[RFC6230] MUST be supported for media dialogs and conferences.
The package uses 'connectionid' and 'conferenceid' attributes for
various element definitions (Section 4). The XML schema (Section 5)
imports the definitions of these attributes from the framework
schema.
3.4. CONTROL Message Body
The Control Framework requires a Control Package to define the
control body that can be contained within a CONTROL command request
and to indicate the location of detailed syntax definitions and
semantics for the appropriate body types.
When operating as a Control Server, the MS receives CONTROL messages
with the MIME media type defined in Section 8.4 and a body containing
a element (Section 4.1) with either a mixer management or
audit request child element.
The following mixer management request elements are carried in
CONTROL message bodies to MS: (Section 4.2.1.1),
(Section 4.2.1.2),
(Section 4.2.1.3), (Section 4.2.2.2),
(Section 4.2.2.3), and (Section 4.2.2.4) elements.
The 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 element (Section 4.1) with a notification child
element (Section 4.2.4).
3.5. REPORT Message Body
The Control Framework requires a Control Package definition to define
the REPORT body that can be contained within a REPORT command
request, or to indicate that no report package body is required.
This section indicates the location of detailed syntax definitions
and semantics for the appropriate body types.
McGlashan, et al. Standards Track [Page 7]
RFC 6505 Mixer Control Package March 2012
When operating as a Control Server, the MS sends REPORT bodies with
the MIME media type defined in Section 8.4 and a element
with a response child element. The response element for mixer
management requests is a element (Section 4.2.3). The
response element for an audit request is a element
(Section 4.3.2).
3.6. Audit
The Control Framework encourages Control Packages to specify whether
auditing is available, how it is triggered, as well as the query/
response formats.
This Control Package supports auditing of package capabilities and
mixers on the MS. An audit request is carried in a CONTROL message
and an audit response in a REPORT message (or a 200 response to the
CONTROL if it can execute the audit in time).
The syntax and semantics of audit request and response elements are
defined in Section 4.3.
3.7. Examples
The Control Framework recommends Control Packages to provide a range
of message flows that represent common flows using the package and
this framework document.
This Control Package provides examples of such message flows in
Section 6.
4. Element Definitions
This section defines the XML elements for this package. The elements
are defined in the XML namespace specified in Section 8.2.
The root element is (Section 4.1). All other XML elements
(requests, responses, and notification elements) are contained within
it. Child elements describe mixer management (Section 4.2) and audit
(Section 4.3) functionality. Response status codes are defined in
Section 4.6 and type definitions in Section 4.7.
Implementation of this Control Package MUST address the security
considerations described in Section 7.
Implementation of this Control Package MUST adhere to the syntax and
semantics of XML elements defined in this section and the schema
(Section 5). The XML schema supports extensibility by allowing
attributes and elements from other namespaces. Implementations MAY
McGlashan, et al. Standards Track [Page 8]
RFC 6505 Mixer Control Package March 2012
support attributes and elements from other (foreign) namespaces. If
an MS implementation receives a element containing
attributes or elements from another namespace, which it does not
support, the MS sends a 428 response (Section 4.6).
Extensible attributes and elements are not described in this section.
In all other cases where there is a difference in constraints between
the XML schema and the textual description of elements in this
section, the textual definition takes priority.
Some elements in this Control Package contain attributes whose value
is descriptive text primarily for diagnostic use. The implementation
can indicated the language used in the descriptive text by means of a
'desclang' attribute [RFC2277]. The 'desclang' attribute can appear
on the root element as well as selected subordinate elements (see
Section 4.1). The 'desclang' attribute value on the root element
applies to all 'desclang' attributes in subordinate elements unless
the subordinate element has an explicit 'desclang' attribute that
overrides it.
Usage examples are provided in Section 6.
4.1.
The element has the following attributes (in addition to
standard XML namespace attributes such as 'xmlns'):
version: a string specifying the mscmixer package version. The
value is fixed as "1.0" for this version of the package. The
attribute is mandatory.
desclang: specifies the language used in descriptive text attributes
of subordinate elements (unless the subordinate element provides a
'desclang' attribute that overrides the value for its descriptive
text attributes). The descriptive text attributes on subordinate
elements include: the 'reason' attribute on
(Section 4.2.3), (Section 4.2.4.2),
(Section 4.2.4.3), and
(Section 4.3.2). A valid value is a language identifier
(Section 4.7.7). The attribute is optional. The default value is
"i-default" (BCP 47 [RFC5646]).
McGlashan, et al. Standards Track [Page 9]
RFC 6505 Mixer Control Package March 2012
The element has the following defined child elements, only
one of which can occur:
1. mixer management elements defined in Section 4.2:
: create and configure a new conference mixer.
See Section 4.2.1.1
: modify the configuration of an existing
conference mixer. See Section 4.2.1.2
: destroy an existing conference mixer. See
Section 4.2.1.3
: create and configure media streams between connections
and/or conferences (for example, add a participant to a
conference). See Section 4.2.2.2
: modify the configuration of joined media streams.
See Section 4.2.2.3
: delete a media stream (for example, remove a
participant from a conference). See Section 4.2.2.4
: response to a mixer request. See Section 4.2.3
: mixer or subscription notification. See Section 4.2.4
2. audit elements defined in Section 4.3:
: audit package capabilities and managed mixers. See
Section 4.3.1
: response to an audit request. See
Section 4.3.2
For example, a request to the MS to create a conference mixer is as
follows:
And a response from the MS that the conference was successfully
created is as follows:
McGlashan, et al. Standards Track [Page 10]
RFC 6505 Mixer Control Package March 2012
4.2. Mixer Elements
This section defines the mixer management XML elements for this
Control Package. These elements are divided into requests,
responses, and notifications.
Request elements are sent to the MS to request a specific mixer
operation to be executed. The following request elements are
defined:
: create and configure a new a conference mixer.
See Section 4.2.1.1
: modify the configuration of an existing
conference mixer. See Section 4.2.1.2
: destroy an existing conference mixer. See
Section 4.2.1.3
: create and configure media streams between connections
and/or conferences (for example, add a participant to a
conference). See Section 4.2.2.2
: modify the configuration of joined media streams. See
Section 4.2.2.3
: delete a media stream (for example, remove a participant
from a conference). See Section 4.2.2.4
Responses from the MS describe the status of the requested operation.
Responses are specified in a element (Section 4.2.3) that
includes a mandatory attribute describing the status in terms of a
numeric code. Response status codes are defined in Section 4.6. The
MS MUST respond to a request message with a response message. If the
MS is not able to process the request and carry out the mixer
operation (in whole or in part), then the request has failed: the MS
MUST ensure that no part of the requested mixer operation is carried
out, and the MS MUST indicate the class of failure using an
appropriate 4xx response code. Unless an error response code is
specified for a class of error within this section, implementations
follow Section 4.6 in determining the appropriate status code for the
response.
McGlashan, et al. Standards Track [Page 11]
RFC 6505 Mixer Control Package March 2012
Notifications are sent from the MS to provide updates on the status
of a mixer operation or subscription. Notifications are specified in
an element (Section 4.2.4).
4.2.1. Conference Elements
4.2.1.1.
The element is sent to the MS to request creation
of a new conference (multiparty) mixer.
The element has the following attributes:
conferenceid: string indicating a unique name for the new
conference. If this attribute is not specified, the MS MUST
create a unique name for the conference. The value is used in
subsequent references to the conference (e.g., as conferenceid in
a ). The attribute is optional. There is no default
value.
reserved-talkers: indicates the requested number of guaranteed
speaker slots to be reserved for the conference. A valid value is
a non-negative integer (see Section 4.7.2). The attribute is
optional. The default value is 0.
reserved-listeners: indicates the requested number of guaranteed
listener slots to be reserved for the conference. A valid value
is a non-negative integer (see Section 4.7.2). The attribute is
optional. The default value is 0.
The element has the following sequence of child
elements:
: an element to configure the codecs supported by the
conference (see Section 4.4). If codecs are specified, then they
impose limitations on media capability when the MS attempts to
join the conference to other entities (see Sections 4.2.2.2 and
4.2.2.3). The element is optional.
: an element to configure the audio mixing
characteristics of a conference (see Section 4.2.1.4.1). The
element is optional.
: an element to configure the video layouts of a
conference (see Section 4.2.1.4.2). The element is optional.
McGlashan, et al. Standards Track [Page 12]
RFC 6505 Mixer Control Package March 2012
: 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.
: an element to request subscription to conference
events. (see Section 4.2.1.4.4). The element is optional.
If the 'conferenceid' attribute specifies a value that is already
used by an existing conference, the MS reports an error (405) and
MUST NOT create a new conference and MUST NOT affect the existing
conference.
If the MS is unable to configure the conference according to
specified 'reserved-talkers' or 'reserved-listeners' attributes, the
MS reports an error (420) and MUST NOT create the conference.
If the MS is unable to configure the conference according to a
specified element, the MS reports an error (421) and
MUST NOT create the conference.
If the MS is unable to configure the conference according to a
specified element, the MS reports an error (423) and
MUST NOT create the conference.
If the MS is unable to configure the conference according to a
specified element, the MS reports an error (424) and
MUST NOT create the conference.
If the MS is unable to configure the conference according to a
specified element, the MS reports an error (425) and MUST
NOT create the conference.
When a MS has finished processing a request, it
MUST reply with an appropriate element (Section 4.2.3).
For example, a request to create an audio video conference mixer with
specified codecs, video layout, video switch, and subscription is as
follows:
McGlashan, et al. Standards Track [Page 13]
RFC 6505 Mixer Control Package March 2012
H264
PCMA
A response from the MS if the conference was successfully created is
as follows:
Alternatively, a response if the MS could not create the conference
due to a lack of support for the H264 codec is as follows:
4.2.1.2.
The element is sent to the MS to request
modification of an existing conference.
The element has the following attribute:
conferenceid: string indicating the name of the conference to
modify. This attribute is mandatory.
McGlashan, et al. Standards Track [Page 14]
RFC 6505 Mixer Control Package March 2012
The element has the following sequence of child
elements (one or more):
: an element to configure the codecs supported by the
conference (see Section 4.4). If codecs are specified, then they
impose limitations in media capability when the MS attempts to
join the conference to other entities (see Sections 4.2.2.2 and
4.2.2.3). Existing conference participants are unaffected by any
policy change. The element is optional.
: an element to configure the audio mixing
characteristics of a conference (see Section 4.2.1.4.1). The
element is optional.
: an element to configure the video layouts of a
conference (see Section 4.2.1.4.2). The element is optional.
: 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.
: an element to request subscription to conference
events. (see Section 4.2.1.4.4). The element is optional.
If the 'conferenceid' attribute specifies the name of a conference
that does not exist, the MS reports an error (406).
If the MS is unable to configure the conference according to a
specified element, the MS reports an error (421) and
MUST NOT modify the conference in any way.
If the MS is unable to configure the conference according to a
specified element, the MS reports an error (423) and
MUST NOT modify the conference in any way.
If the MS is unable to configure the conference according to a
specified element, the MS reports an error (424) and
MUST NOT modify the conference in any way.
If the MS is unable to configure the conference according to a
specified element, the MS reports an error (425) and MUST
NOT modify the conference.
When a MS has finished processing a request, it
MUST reply with an appropriate element (Section 4.2.3).
McGlashan, et al. Standards Track [Page 15]
RFC 6505 Mixer Control Package March 2012
4.2.1.3.
The element is sent to the MS to request
destruction of an existing conference.
The element has the following attribute:
conferenceid: string indicating the name of the conference to
destroy. This attribute is mandatory.
The element does not specify any child elements.
If the 'conferenceid' attribute specifies the name of a conference
that does not exist, the MS reports an error (406).
When a MS has finished processing a request, it
MUST reply with an appropriate element (Section 4.2.3).
Successfully destroying the conference (status code 200) will result
in all connection or conference participants being removed from the
conference mixer, notification events
(Section 4.2.4.2) being sent for each conference participant, and a
notification event (Section 4.2.4.3) indicating that
conference has exited. A with any other status code
indicates that the conference mixer still exists and participants are
still joined to the mixer.
4.2.1.4. Conference Configuration
The elements in this section are used to establish and modify the
configuration of conferences.
4.2.1.4.1.
The element defines the configuration of the
conference audio mix.
The element has the following attributes:
type: is a string indicating the audio stream mixing policy.
Defined values are: "nbest" (where the N best (loudest)
participant signals are mixed) and "controller" (where the
contributing participant(s) is/are selected by the controlling AS
via an external floor control protocol). The attribute is
optional. The default value is "nbest".
McGlashan, et al. Standards Track [Page 16]
RFC 6505 Mixer Control Package March 2012
n: indicates the number of eligible participants included in the
conference audio mix. An eligible participant is a participant
who contributes audio to the conference. Inclusion is based on
having the greatest audio energy. A valid value is a non-negative
integer (see Section 4.7.2). A value of 0 indicates that all
participants contributing audio to the conference are included in
the audio mix. The default value is 0. The element is optional.
If the 'type' attribute does not have the value "nbest", the MS
ignores the 'n' attribute.
The element has no child elements.
For example, a fragment where the audio-mixing policy is set to
"nbest" with 3 participants to be included is as follows:
If the conference had 200 participants of whom 30 contributed audio,
then there would be 30 eligible participants for the audio mix. Of
these, the 3 loudest participants would have their audio included in
the conference.
4.2.1.4.2.
The element describes the video presentation layout
configuration for participants providing a video input stream to the
conference. This element allows multiple video layouts to be
specified so that the MS automatically changes layout depending on
the number of video-enabled participants.
The element has no attributes.
The element has the following sequence of child
elements (one or more):
: element describing a video layout
(Section 4.2.1.4.2.1).
If the MS does not support video conferencing at all, or does not
support multiple video layouts, or does not support a specific video
layout, the MS reports an 423 error in the response to the request
element containing the element.
An MS MAY support more than one element, although only
one layout can be active at a time. A is active if
the number of participants in the conference is equal to or greater
than the value of its 'min-participants' attribute, but less than the
McGlashan, et al. Standards Track [Page 17]
RFC 6505 Mixer Control Package March 2012
value of the 'min-participants' attribute for any other element. An MS reports an error (400) if more than one
has the same value for the 'min-participants'
attribute. When the number of regions within the active layout is
greater than the number of participants in the conference, the
display of unassigned regions is implementation-specific.
The assignment of participant video streams to regions within the
layout is according to the video switch policy specified by the
element (Section 4.2.1.4.3).
For example, a fragment describing a single layout is as follows:
A fragment describing a sequence of layouts is as follows:
When the conference has one participant providing a video input
stream to the conference, then the single-view format is used. When
the conference has two such participants, the dual-view layout is
used. When the conference has three or four participants, the quad-
view layout is used. When the conference has five or more
participants, the multiple-3x3 layout is used.
4.2.1.4.2.1.
The element describes a video layout containing one or
more regions in which participant video input streams are displayed.
The element has the following attribute:
min-participants: the minimum number of conference participants
needed to allow this layout to be active. A valid value is a
positive integer (see Section 4.7.3). The attribute is optional.
The default value is 1.
The element has one child element specifying the video
layout. An MS MAY support the predefined video layouts defined in
the conference information data model for centralized conferencing
McGlashan, et al. Standards Track [Page 18]
RFC 6505 Mixer Control Package March 2012
(XCON) [RFC6501]: , , ,
, , , ,
, and .
The MS MAY support other video layouts. Non-XCON layouts MUST be
specified using an element from a namespace other than the one used
in this specification, for example:
my-single-view
If the MS does not support the specified video layout configuration,
then the MS reports a 423 error (Section 4.6) in the response to the
request element containing the element.
Each video layout has associated with it one or more regions. The
XCON layouts are associated with the following named regions:
: layout with one stream in a single region as shown
in Figure 1.
+-----------+
| |
| |
| 1 |
| |
| |
+-----------+
Figure 1: single-view video layout
: layout presenting two streams side-by-side in two
regions as shown in Figure 2. The MS MUST NOT alter the aspect
ratio of each stream to fit the region, and hence the MS might
need to blank out part of each region.
+-----------+-----------+
| | |
| | |
| 1 | 2 |
| | |
| | |
+-----------+-----------+
Figure 2: dual-view video layout
McGlashan, et al. Standards Track [Page 19]
RFC 6505 Mixer Control Package March 2012
: 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
: layout presenting two streams, one above the
other, in two regions as shown in Figure 4. The MS MUST NOT alter
the aspect ratio of each stream to fit its region, and hence the
MS might need to blank out part of each region.
+-----------+
| |
| |
| 1 |
| |
| |
+-----------+
| |
| |
| 2 |
| |
| |
+-----------+
Figure 4: dual-view-2x1 video layout
McGlashan, et al. Standards Track [Page 20]
RFC 6505 Mixer Control Package March 2012
: 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
: layout presenting four equal-sized regions in a 2x2
layout as shown in Figure 6. Typically, the aspect ratio of the
streams is preserved, so blanking is required.
+-----------+-----------+
| | |
| | |
| 1 | 2 |
| | |
| | |
+-----------+-----------+
| | |
| | |
| 3 | 4 |
| | |
| | |
+-----------+-----------+
Figure 6: quad-view video layout
McGlashan, et al. Standards Track [Page 21]
RFC 6505 Mixer Control Package March 2012
: layout presenting nine equal-sized regions in a 3x3
layout as shown in Figure 7. Typically, the aspect ratio of the
streams is preserved, so blanking is required.
+-----------+-----------+-----------+
| | | |
| | | |
| 1 | 2 | 3 |
| | | |
| | | |
+-----------+-----------+-----------+
| | | |
| | | |
| 4 | 5 | 6 |
| | | |
| | | |
+-----------+-----------+-----------+
| | | |
| | | |
| 7 | 8 | 9 |
| | | |
| | | |
+-----------+-----------+-----------+
Figure 7: multiple-3x3 video layout
McGlashan, et al. Standards Track [Page 22]
RFC 6505 Mixer Control Package March 2012
: layout presenting 16 equal-sized regions in a 4x4
layout as shown in Figure 8. Typically, the aspect ratio of the
streams is preserved, so blanking is required.
+-----------+-----------+-----------+-----------+
| | | | |
| | | | |
| 1 | 2 | 3 | 4 |
| | | | |
| | | | |
+-----------+-----------+-----------+-----------+
| | | | |
| | | | |
| 5 | 6 | 7 | 8 |
| | | | |
| | | | |
+-----------+-----------+-----------+-----------+
| | | | |
| | | | |
| 9 | 10 | 11 | 12 |
| | | | |
| | | | |
+-----------+-----------+-----------+-----------+
| | | | |
| | | | |
| 13 | 14 | 15 | 16 |
| | | | |
| | | | |
+-----------+-----------+-----------+-----------+
Figure 8: multiple-4x4 video layout
McGlashan, et al. Standards Track [Page 23]
RFC 6505 Mixer Control Package March 2012
: layout presents a 5x1 layout as shown in Figure 9
where one region will occupy 4/9 of the mixed video stream, while
the others will each occupy 1/9 of the stream. Typically, the
aspect ratio of the streams is preserved, so blanking is required.
+-----------------------+-----------+
| | |
| | |
| | 2 |
| | |
| | |
| 1 +-----------+
| | |
| | |
| | 3 |
| | |
| | |
+-----------+-----------+-----------+
| | | |
| | | |
| 4 | 5 | 6 |
| | | |
| | | |
+-----------+-----------+-----------+
Figure 9: multiple-5x1 video layout
4.2.1.4.3.
The element describes the configuration of the
conference policy for how participants' input video streams are
assigned to regions within the active video layout.
The element has the following child elements defined
(one child occurrence only) to indicate the video-switching policy of
the conference:
: (Voice-Activated Switching) enables automatic display of the
loudest speaker participant that is contributing both audio and
video to the conference mix. Participants who do not provide an
audio stream are not considered for automatic display. If a
participant provides more than one audio stream, then the policy
for inclusion of such a participant in the VAS is implementation-
specific; an MS could select one stream, sum audio streams, or
ignore the participant for VAS consideration. If there is only
one region in the layout, then the loudest speaker is displayed
there. If more than one region is available, then the loudest
speaker is displayed in the largest region (if any), and then in
McGlashan, et al. Standards Track [Page 24]
RFC 6505 Mixer Control Package March 2012
the first region from the top-left corner of the layout. The MS
assigns the remaining regions based on the priority mechanism
described in Section 4.2.1.4.3.1.
: 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 ,
, and commands with a 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:
The element has the following attributes:
interval: specifies the period between video switches as a number of
seconds. In the case of 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 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
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
, the MS ignores this attribute.
McGlashan, et al. Standards Track [Page 25]
RFC 6505 Mixer Control Package March 2012
If the MS does not support the specified video-switching policy or
other configuration parameters (including separate active speaker
video mixes), then the MS reports a 424 error (Section 4.6) in the
response to the request element containing the
element.
If the MS receives a or request containing a
element (Section 4.2.2.5) that specifies a region and the
conference video-switching policy is set to , then the MS
ignores the region (i.e., conference-switching policy takes
precedence).
If the MS receives a or request containing a
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 video-switching policy
with an interval of 2s
For example, a fragment specifying a video-switching
policy where video switching takes place immediately is as follows:
4.2.1.4.3.1. Priority Assignment
In cases where the video-switching policy does not explicitly
determine the region to which a participant is assigned, the
following priority assignment mechanism applies:
1. Each participant has a (positive integer) priority value: the
lower the value, the higher the priority. The priority value is
determined by the child element (Section 4.2.2.5.4) of
. If not explicitly specified, the default priority
value is 100.
2. The MS uses priority values to assign participants to regions in
the video layout which remain unfilled after application of the
video-switching policy. The MS MUST dedicate larger and/or more
prominent portions of the layout to participants with higher
priority values first (e.g., first, all participants with
priority 1, then those with 2, 3, etc.).
McGlashan, et al. Standards Track [Page 26]
RFC 6505 Mixer Control Package March 2012
3. The policy for displaying participants with the same priority is
implementation-specific.
The MS applies this priority policy each time the video layout is
changed or updated. It is RECOMMENDED that the MS does not move a
participant from one region to another unless required by the video-
switching policy when an active video layout is updated.
This model allows the MS to apply default video layouts after
applying the video-switching policy. For example, region 2 is
statically assigned to Bob, so the priority mechanism only applies to
regions 1, 3, 4, etc.
4.2.1.4.4.
The element is a container for specifying conference
notification events to which a controlling entity subscribes.
Notifications of conference events are delivered using the
element (see Section 4.2.4).
The element has no attributes, but has the following
child element:
: subscription to active talker events
(Section 4.2.1.4.4.1). The element is optional.
The MS MUST support a 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
with a 428 status code (see Section 4.6).
4.2.1.4.4.1.
The 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 element has no child elements.
Active talker notifications are delivered in the element (Section 4.2.4.1).
McGlashan, et al. Standards Track [Page 27]
RFC 6505 Mixer Control Package March 2012
4.2.2. Joining Elements
This section contains definitions of the joining model
(Section 4.2.2.1) as well as the (Section 4.2.2.2),
(Section 4.2.2.3), (Section 4.2.2.4) and
(Section 4.2.2.5) elements.
4.2.2.1. Joining Model
The operation creates a media stream between a connection and
a conference, between connections, or between conferences. This
section describes the model of conferences and connections and
specifies the behavior for join requests to targets that already have
an associated media stream.
Conferences support multiple inputs and have resources to mix them
together. A media server conference in essence is a mixer that
combines media streams. A simple audio mixer simply sums its input
audio signals to create a single common output. Conferences,
however, use a more complex algorithm so that participants do not
hear themselves as part of the mix. That algorithm, sometimes called
an "n-minus mix", subtracts each participants input signal from the
summed input signals, creating a unique output for each contributing
participant. Each operation to a conference uses one of the
conference's available inputs and/or outputs, to the maximum number
of supported participants.
A connection is the termination of one or more RTP sessions on a
media server. It has a single input and output for each media
session established by its SIP dialog. The output of a connection
can feed several different inputs such as both a conference mixer and
a recording of that participant's audio.
Joining two connections that are not joined to anything else simply
creates a media stream from the outputs(s) of one connection to the
corresponding inputs(s) of the other connection. It is not necessary
to combine media from multiple sources in this case. There are,
however, several common scenarios where combining media from several
sources to create a single input to a connection is needed.
In the first case, a connection can be receiving media from one
source (for example, a conference), and it is necessary to play an
announcement to the connection so that both the conference audio and
announcement can be heard by the conference participant. This is
sometimes referred to as a "whisper announcement". An alternative to
a whisper announcement is to have the announcement preempt the
conference media.
McGlashan, et al. Standards Track [Page 28]
RFC 6505 Mixer Control Package March 2012
Another common case is the call-center coaching scenario where a
supervisor can listen to the conversation between an agent and a
customer, and provide hints to the agent that are not heard by the
customer.
Both of these cases can be solved by having the controlling AS create
one or more conferences for audio mixing, and then join and unjoin
the media streams as required. A better solution is to have the
media server automatically mix media streams that are requested to be
joined to a common input when only the simple summing of audio
signals as described above is required. This is the case for both
the use cases presented above.
Automatically mixing streams has several benefits. Conceptually, it
is straightforward and simple, requiring no indirect requests on the
part of the controlling AS. This increases transport efficiency and
reduces the coordination complexity and the latency of the overall
operation. Therefore, it is RECOMMENDED that a media server be able
to automatically mix at least two audio streams where only the simple
summing of signals is required.
When a media server receives a request, it MUST automatically
mix all of the media streams included in the request with any streams
already joined to one of the entities identified in the request, or
it MUST fail the request and MUST NOT join any of the streams (and
MUST NOT change existing streams of the entities). A controlling AS
uses the request for generic conferences where the
complex mixing algorithm is required.
Specifications that extend this package to handle additional media
types such as text MUST define the semantics of the join operation
when multiple streams are requested to be joined to a single input,
such as that for a connection with a single RTP session per media
type.
4.2.2.2.
The element is sent to the MS to request creation of one or
more media streams either between a connection and a conference,
between connections, or between conferences. The two entities to
join are specified by the attributes of .
Streams can be of any media type and can be bidirectional or
unidirectional. A bidirectional stream is implicitly composed of two
unidirectional streams that can be manipulated independently. The
streams to be established are specified by child elements
(see Section 4.2.2.5).
McGlashan, et al. Standards Track [Page 29]
RFC 6505 Mixer Control Package March 2012
The element has the following attributes:
id1: an identifier for either a connection or a conference. The
identifier MUST conform to the syntax defined in Appendix A.1 of
[RFC6230]. The attribute is mandatory.
id2: an identifier for either a connection or a conference. The
identifier MUST conform to the syntax defined in Appendix A.1 of
[RFC6230]. The attribute is mandatory.
Note: Appendix A.1 of [RFC6230] defines the semantics for a
conference identifier but not its syntax. Media server
implementations need to distinguish between conferences and
connections based upon the values of the 'id1' and 'id2' attributes.
If id1 or id2 specify a conference identifier and the conference does
not exist on the MS, the MS reports an error (406). If id1 or id2
specify a connection identifier and the connection does not exist on
the MS, the MS reports an error (412).
The element has the following child element (zero or more):
: 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 elements are specified, then the default is to join
all streams between the entities according to the media configuration
of the connection or conference.
One or more elements can be specified so that individual
media streams can be controlled independently. For example, if a
connection supports both audio and video streams, a element
could be used to indicate that only the audio stream is used in
receive mode. In cases where there are multiple media streams of the
same type for a connection or conference, the configuration MUST be
explicitly specified using elements.
Multiple elements can be specified for precise control over
the media flow in different directions within the same media stream.
One element can be specified for the receiving media flow
and another element for the sending media flow, where each
independently controls features such as volume (see child element of
in Section 4.2.2.5). If there is only one element
for a given media specifying a 'sendonly' or 'recvonly' direction,
then the media flow in the opposite direction is inactive
(established but there's no actual flow of media) unless this leads
to a stream conflict.
McGlashan, et al. Standards Track [Page 30]
RFC 6505 Mixer Control Package March 2012
If the MS is unable to execute the join as specified in
because a element is in conflict with (a) another
element, (b) specified connection or conference media capabilities
(including supported or available codec information), or (c) an
Session Description Protocol (SDP) label value as part of the
connection-id (see Appendix A.1 of [RFC6230]), then the MS reports an
error (407) and MUST NOT join the entities and MUST NOT change
existing streams of the entities.
If the MS is unable to execute the join as specified in
elements because the MS does not support the media stream
configuration, the MS reports an error (422) and MUST NOT join the
entities and MUST NOT change existing streams of the entities.
If the MS is unable to join an entity to a conference because it is
full, then the MS reports an error (410).
If the specified entities are already joined, then the MS reports an
error (408).
If the MS does not support joining two specified connections
together, the MS reports an error (426).
If the MS does not support joining two specified conferences
together, the MS reports an error (427).
If the MS is unable to join the specified entities for any other
reason, the MS reports an error (411).
When the MS has finished processing a request, it MUST reply
with an element (Section 4.2.3).
For example, a request to join two connections together is as
follows:
The response if the MS doesn't support joining media streams between
connections is as follows:
McGlashan, et al. Standards Track [Page 31]
RFC 6505 Mixer Control Package March 2012
4.2.2.3.
The element is sent to the MS to request changes in the
configuration of media stream(s) that were previously established
between a connection and a conference, between two connections, or
between two conferences.
The 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 element has the following child elements (one or
more):
: 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 for any stream that was established
using .
The MS MUST configure the streams that are included within
to that stated by the child elements.
If the MS is unable to modify the join as specified in
elements because a element is in conflict with (a) another
element, (b) specified connection or conference media
capabilities (including supported or available codec information), or
(c) a SDP label value as part of the connection-id (see Appendix A.1
of [RFC6230]), then the MS reports an error (407) and MUST NOT modify
the join between the entities and MUST NOT change existing streams of
the entities.
If the MS is unable to modify the join as specified in
elements because the MS does not support the media stream
configuration, the MS reports an error (422) and MUST NOT modify the
join between the entities and MUST NOT change existing streams of the
entities.
If the specified entities are not already joined, then the MS reports
an error (409).
McGlashan, et al. Standards Track [Page 32]
RFC 6505 Mixer Control Package March 2012
If the MS is unable to modify the join between the specified entities
for any other reason, the MS reports an error (411).
When an MS has finished processing a request, it MUST
reply with an appropriate element (Section 4.2.3).
In cases where stream characteristics are controlled independently
for each direction, then a request needs to specify a
child element for each direction in order to retain the original
stream directionality. For the example, if a request
establishes independent control for each direction of an audio stream
(see Section 4.2.2.5):
then the following request
would cause, in addition to the modification of the sendonly volume,
the overall stream directionality to change from sendrecv to sendonly
since there is no element in this request for
the recvonly direction. The following would change the sendonly
volume and retain the recvonly stream together with its original
characteristics such as volume:
McGlashan, et al. Standards Track [Page 33]
RFC 6505 Mixer Control Package March 2012
4.2.2.4.
The element is sent to the MS to request removal of
previously established media stream(s) from between a connection and
a conference, between two connections, or between two conferences.
The 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 element has the following child element (zero or more
occurrences):
: an element that identifies the media stream(s) to remove
(see Section 4.2.2.5). The element is optional. When not
present, all currently established streams between "id1" and "id2"
are removed.
The MS MUST support for any stream that was established
using and that has not already been removed by a previous
on the same stream.
If the MS is unable to terminate the join as specified in
elements because a element is in conflict with (a) another
element, (b) specified connection or conference media
capabilities, or (c) a SDP label value as part of the connection-id
(see Appendix A.1 of [RFC6230]), then the MS reports an error (407)
and MUST NOT terminate the join between the entities and MUST NOT
change existing streams of the entities.
McGlashan, et al. Standards Track [Page 34]
RFC 6505 Mixer Control Package March 2012
If the MS is unable to terminate the join as specified in
elements because the MS does not support the media stream
configuration, the MS reports an error (422) and MUST NOT terminate
the join between the entities and MUST NOT change existing streams of
the entities.
If the specified entities are not already joined, then the MS reports
an error (409).
If the MS is unable to terminate the join between the specified
entities for any other reason, the MS reports an error (411).
When an MS has successfully processed a request, it MUST
reply with a successful element (Section 4.2.3).
4.2.2.5.
, , and require the identification and
manipulation of media streams. Media streams represent the flow of
media between a participant connection and a conference, between two
connections, or between two conferences. The element is
used (as a child to , , and ) to identify
the media stream(s) for the request and to specify the configuration
of the media stream.
The element has the following attributes:
media: a string indicating the type of media associated with the
stream. A valid value is a MIME type name as defined in Section
4.2 of [RFC4288]. The following values MUST be used for common
types of media: "audio" for audio media, and "video" for video
media. See [IANA] for registered MIME type names. The attribute
is mandatory.
label: a string indicating the SDP label associated with a media
stream [RFC4574]. The attribute is optional.
direction: a string indicating the allowed media flow of the stream
relative to the value of the 'id1' attribute of the parent
element. Defined values are: "sendrecv" (media can be sent and
received), "sendonly" (media can only be sent), "recvonly" (media
can only be received), and "inactive" (stream established but no
media flow). The default value is "sendrecv". The attribute is
optional.
McGlashan, et al. Standards Track [Page 35]
RFC 6505 Mixer Control Package March 2012
The element has the following sequence of child elements:
: an element (Section 4.2.2.5.1) to configure the volume or
gain of the media stream. The element is optional.
: an element (Section 4.2.2.5.2) to configure filtering and
removal of tones from the media stream. The element is optional.
: 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.
: an element (Section 4.2.2.5.4) to configure priority
associated with the stream in the media mix. The element is
optional.
In each child element, the media stream affected is indicated by the
value of the 'direction' attribute of the parent element.
If the 'media' attribute does not have the value of "audio", then the
MS ignores and elements.
If the 'media' attribute does not have the value of "video", then the
MS ignores a element.
For example, a request to join a connection to conference in both
directions with volume control is as follows:
