draft-ietf-mediactrl-mixer-control-package-11.txt   draft-ietf-mediactrl-mixer-control-package-12.txt 
Network Working Group S. McGlashan Network Working Group S. McGlashan
Internet-Draft Hewlett-Packard Internet-Draft Hewlett-Packard
Intended status: Standards Track T. Melanchuk Intended status: Standards Track T. Melanchuk
Expires: August 29, 2010 Rain Willow Communications Expires: May 15, 2011 Rain Willow Communications
C. Boulton C. Boulton
NS-Technologies NS-Technologies
February 25, 2010 November 11, 2010
A Mixer Control Package for the Media Control Channel Framework A Mixer Control Package for the Media Control Channel Framework
draft-ietf-mediactrl-mixer-control-package-11 draft-ietf-mediactrl-mixer-control-package-12
Abstract Abstract
This document defines a Media Control Channel Framework Package for This document defines a Media Control Channel Framework Package for
managing mixers for media conferences and connections. The package managing mixers for media conferences and connections. The package
defines request elements for managing conference mixers, managing defines request elements for managing conference mixers, managing
mixers between conferences and/or connections, as well as associated mixers between conferences and/or connections, as well as associated
responses and notifications. The package also defines elements for responses and notifications. The package also defines elements for
auditing package capabilities and mixers. auditing package capabilities and mixers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on May 15, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
3. Control Package Definition . . . . . . . . . . . . . . . . . 7 3. Control Package Definition . . . . . . . . . . . . . . . . . 8
3.1. Control Package Name . . . . . . . . . . . . . . . . . . 7 3.1. Control Package Name . . . . . . . . . . . . . . . . . . 8
3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 7 3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 8
3.3. Common XML Support . . . . . . . . . . . . . . . . . . . 8 3.3. Common XML Support . . . . . . . . . . . . . . . . . . . 9
3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . 8 3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . 9
3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 8 3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 9
3.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 10 4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 11
4.1. <mscmixer> . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. <mscmixer> . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Mixer Elements . . . . . . . . . . . . . . . . . . . . . 11 4.2. Mixer Elements . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Conference Elements . . . . . . . . . . . . . . . . . 12 4.2.1. Conference Elements . . . . . . . . . . . . . . . . . 14
4.2.1.1. <createconference> . . . . . . . . . . . . . . . 12 4.2.1.1. <createconference> . . . . . . . . . . . . . . . 14
4.2.1.2. <modifyconference> . . . . . . . . . . . . . . . 15 4.2.1.2. <modifyconference> . . . . . . . . . . . . . . . 16
4.2.1.3. <destroyconference> . . . . . . . . . . . . . . . 16 4.2.1.3. <destroyconference> . . . . . . . . . . . . . . . 18
4.2.1.4. Conference Configuration . . . . . . . . . . . . 17 4.2.1.4. Conference Configuration . . . . . . . . . . . . 18
4.2.1.4.1. <audio-mixing> . . . . . . . . . . . . . . . 17 4.2.1.4.1. <audio-mixing> . . . . . . . . . . . . . . . 18
4.2.1.4.2. <video-layouts> . . . . . . . . . . . . . . . 17 4.2.1.4.2. <video-layouts> . . . . . . . . . . . . . . . 19
4.2.1.4.2.1. <video-layout> . . . . . . . . . . . . . 19 4.2.1.4.2.1. <video-layout> . . . . . . . . . . . . . 20
4.2.1.4.3. <video-switch> . . . . . . . . . . . . . . . 24 4.2.1.4.3. <video-switch> . . . . . . . . . . . . . . . 26
4.2.1.4.3.1. Priority assignment . . . . . . . . . . . 26 4.2.1.4.3.1. Priority assignment . . . . . . . . . . . 28
4.2.1.4.4. <subscribe> . . . . . . . . . . . . . . . . . 27 4.2.1.4.4. <subscribe> . . . . . . . . . . . . . . . . . 29
4.2.1.4.4.1. <active-talkers-sub> . . . . . . . . . . 27 4.2.1.4.4.1. <active-talkers-sub> . . . . . . . . . . 29
4.2.2. Joining Elements . . . . . . . . . . . . . . . . . . 27 4.2.2. Joining Elements . . . . . . . . . . . . . . . . . . 29
4.2.2.1. Joining Model . . . . . . . . . . . . . . . . . . 27 4.2.2.1. Joining Model . . . . . . . . . . . . . . . . . . 30
4.2.2.2. <join> . . . . . . . . . . . . . . . . . . . . . 29 4.2.2.2. <join> . . . . . . . . . . . . . . . . . . . . . 31
4.2.2.3. <modifyjoin> . . . . . . . . . . . . . . . . . . 31 4.2.2.3. <modifyjoin> . . . . . . . . . . . . . . . . . . 33
4.2.2.4. <unjoin> . . . . . . . . . . . . . . . . . . . . 33 4.2.2.4. <unjoin> . . . . . . . . . . . . . . . . . . . . 36
4.2.2.5. <stream> . . . . . . . . . . . . . . . . . . . . 35 4.2.2.5. <stream> . . . . . . . . . . . . . . . . . . . . 37
4.2.2.5.1. <volume> . . . . . . . . . . . . . . . . . . 36 4.2.2.5.1. <volume> . . . . . . . . . . . . . . . . . . 39
4.2.2.5.2. <clamp> . . . . . . . . . . . . . . . . . . . 37 4.2.2.5.2. <clamp> . . . . . . . . . . . . . . . . . . . 39
4.2.2.5.3. <region> . . . . . . . . . . . . . . . . . . 37 4.2.2.5.3. <region> . . . . . . . . . . . . . . . . . . 39
4.2.2.5.4. <priority> . . . . . . . . . . . . . . . . . 37 4.2.2.5.4. <priority> . . . . . . . . . . . . . . . . . 40
4.2.3. <response> . . . . . . . . . . . . . . . . . . . . . 38 4.2.3. <response> . . . . . . . . . . . . . . . . . . . . . 40
4.2.4. <event> . . . . . . . . . . . . . . . . . . . . . . . 38 4.2.4. <event> . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.4.1. <active-talkers-notify> . . . . . . . . . . . . . 39 4.2.4.1. <active-talkers-notify> . . . . . . . . . . . . . 41
4.2.4.1.1. <active-talker> . . . . . . . . . . . . . . . 39 4.2.4.1.1. <active-talker> . . . . . . . . . . . . . . . 41
4.2.4.2. <unjoin-notify> . . . . . . . . . . . . . . . . . 40 4.2.4.2. <unjoin-notify> . . . . . . . . . . . . . . . . . 42
4.2.4.3. <conferenceexit> . . . . . . . . . . . . . . . . 40 4.2.4.3. <conferenceexit> . . . . . . . . . . . . . . . . 43
4.3. Audit Elements . . . . . . . . . . . . . . . . . . . . . 42 4.3. Audit Elements . . . . . . . . . . . . . . . . . . . . . 44
4.3.1. <audit> . . . . . . . . . . . . . . . . . . . . . . . 42 4.3.1. <audit> . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.2. <auditresponse> . . . . . . . . . . . . . . . . . . . 43 4.3.2. <auditresponse> . . . . . . . . . . . . . . . . . . . 46
4.3.2.1. <capabilities> . . . . . . . . . . . . . . . . . 45 4.3.2.1. <capabilities> . . . . . . . . . . . . . . . . . 47
4.3.2.2. <mixers> . . . . . . . . . . . . . . . . . . . . 46 4.3.2.2. <mixers> . . . . . . . . . . . . . . . . . . . . 48
4.3.2.2.1. <conferenceaudit> . . . . . . . . . . . . . . 46 4.3.2.2.1. <conferenceaudit> . . . . . . . . . . . . . . 48
4.3.2.2.1.1. <participants> . . . . . . . . . . . . . 47 4.3.2.2.1.1. <participants> . . . . . . . . . . . . . 49
4.3.2.2.1.1.1. <participant> . . . . . . . . . . . . 47 4.3.2.2.1.1.1. <participant> . . . . . . . . . . . . 49
4.3.2.2.2. <joinaudit> . . . . . . . . . . . . . . . . . 48 4.3.2.2.2. <joinaudit> . . . . . . . . . . . . . . . . . 50
4.4. <codecs> . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4. <codecs> . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.1. <codec> . . . . . . . . . . . . . . . . . . . . . . . 49 4.4.1. <codec> . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.1.1. <subtype> . . . . . . . . . . . . . . . . . . . . 50 4.5. <params> . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.1.2. <params> . . . . . . . . . . . . . . . . . . . . 50 4.5.1. <param> . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.1.2.1. <param> . . . . . . . . . . . . . . . . . . . 50 4.6. Response Status Codes . . . . . . . . . . . . . . . . . . 53
4.5. Response Status Codes . . . . . . . . . . . . . . . . . . 51 4.7. Type Definitions . . . . . . . . . . . . . . . . . . . . 57
4.6. Type Definitions . . . . . . . . . . . . . . . . . . . . 55 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 59
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 57 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.1. AS-MS Framework Interaction Examples . . . . . . . . . . 78
6.1. AS-MS Framework Interaction Examples . . . . . . . . . . 76
6.1.1. Creating a conference mixer and joining a 6.1.1. Creating a conference mixer and joining a
participant . . . . . . . . . . . . . . . . . . . . . 76 participant . . . . . . . . . . . . . . . . . . . . . 78
6.1.2. Receiving active talker notifications . . . . . . . . 77 6.1.2. Receiving active talker notifications . . . . . . . . 79
6.1.3. Conference termination . . . . . . . . . . . . . . . 77 6.1.3. Conference termination . . . . . . . . . . . . . . . 79
6.2. Mixing Examples . . . . . . . . . . . . . . . . . . . . . 77 6.2. Mixing Examples . . . . . . . . . . . . . . . . . . . . . 79
6.2.1. Audio conferencing . . . . . . . . . . . . . . . . . 78 6.2.1. Audio conferencing . . . . . . . . . . . . . . . . . 80
6.2.2. Bridging connections . . . . . . . . . . . . . . . . 80 6.2.2. Bridging connections . . . . . . . . . . . . . . . . 82
6.2.3. Video conferencing . . . . . . . . . . . . . . . . . 81 6.2.3. Video conferencing . . . . . . . . . . . . . . . . . 83
7. Security Considerations . . . . . . . . . . . . . . . . . . . 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 85
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88
8.1. Control Package Registration . . . . . . . . . . . . . . 86 8.1. Control Package Registration . . . . . . . . . . . . . . 88
8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 86 8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 88
8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 87 8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 89
8.4. MIME Media Type Registration for 8.4. MIME Media Type Registration for
'application/msc-mixer+xml' . . . . . . . . . . . . . . . 87 'application/msc-mixer+xml' . . . . . . . . . . . . . . . 89
9. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 89 9. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 91
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 97 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 100
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 98 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 101
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 102
12.1. Normative References . . . . . . . . . . . . . . . . . . 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 102
12.2. Informative References . . . . . . . . . . . . . . . . . 99 12.2. Informative References . . . . . . . . . . . . . . . . . 103
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 104
1. Introduction 1. Introduction
The Media Control Channel Framework The Media Control Channel Framework
[I-D.ietf-mediactrl-sip-control-framework] provides a generic [I-D.ietf-mediactrl-sip-control-framework] provides a generic
approach for establishment and reporting capabilities of remotely approach for establishment and reporting capabilities of remotely
initiated commands. The Framework utilizes many functions provided initiated commands. The Control Framework - an equivalent term for
by the Session Initiation Protocol [RFC3261] (SIP) for the rendezvous the Media Control Channel Framework - utilizes many functions
and establishment of a reliable channel for control interactions. provided by the Session Initiation Protocol [RFC3261] (SIP) for the
The Control Framework also introduces the concept of a Control rendezvous and establishment of a reliable channel for control
Package. A Control Package is an explicit usage of the Control interactions. The Control Framework also introduces the concept of a
Framework for a particular interaction set. This specification Control Package. A Control Package is an explicit usage of the
defines a package for media conference mixers and media connection Control Framework for a particular interaction set. This
mixers. specification defines a package for media conference mixers and media
connection mixers.
This package defines mixer management elements for creating, This package defines mixer management elements for creating,
modifying and deleting conference mixers, elements for joining, modifying and deleting conference mixers, elements for joining,
modifying and unjoining media streams between connections and modifying and unjoining media streams between connections and
conferences (including mixers between connections), as well as conferences (including mixers between connections), as well as
associated responses and notifications. The package also defines associated responses and notifications. The package also defines
elements for auditing package capabilities and mixers. elements for auditing package capabilities and mixers.
This package has been designed to satisfy media mixing requirements This package has been designed to satisfy media mixing requirements
documented in the Media Server Control Protocol Requirements document documented in the Media Server Control Protocol Requirements document
skipping to change at page 8, line 41 skipping to change at page 8, line 41
media type defined in Section 8.4. These elements describe requests, media type defined in Section 8.4. These elements describe requests,
response and notifications and all are contained within a root response and notifications and all are contained within a root
<mscmixer> element (Section 4.1). <mscmixer> element (Section 4.1).
In this package, the MS operates as a Control Server in receiving In this package, the MS operates as a Control Server in receiving
requests from, and sending responses to, the AS (operating as Control requests from, and sending responses to, the AS (operating as Control
Client). Mixer management requests and responses are defined in Client). Mixer management requests and responses are defined in
Section 4.2. Audit 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 Section 4.3. Mixer management and audit responses are carried in a
framework 200 response or REPORT message bodies. This package's framework 200 response or REPORT message bodies. This package's
response codes are defined in Section 4.5. response codes are defined in Section 4.6.
Note that package responses are different from framework response Note that package responses are different from framework response
codes. Framework error response codes (see Section 8 of codes. Framework error response codes (see Section 8 of
[I-D.ietf-mediactrl-sip-control-framework]) are used when the request [I-D.ietf-mediactrl-sip-control-framework]) are used when the request
or event notification is invalid; for example, a request is invalid or event notification is invalid; for example, a request is invalid
XML (400), or not understood (500). XML (400), or not understood (500).
The MS also operates as a Control Client in sending event The MS also operates as a Control Client in sending event
notification to the AS (Control Server). Event notifications notification to the AS (Control Server). Event notifications
(Section 4.2.4) are carried in CONTROL message bodies. The AS MUST (Section 4.2.4) are carried in CONTROL message bodies. The AS MUST
skipping to change at page 11, line 14 skipping to change at page 11, line 14
4. Element Definitions 4. Element Definitions
This section defines the XML elements for this package. The elements This section defines the XML elements for this package. The elements
are defined in the XML namespace specified in Section 8.2. are defined in the XML namespace specified in Section 8.2.
The root element is <mscmixer> (Section 4.1). All other XML elements The root element is <mscmixer> (Section 4.1). All other XML elements
(requests, responses and notification elements) are contained within (requests, responses and notification elements) are contained within
it. Child elements describe mixer management (Section 4.2) and audit it. Child elements describe mixer management (Section 4.2) and audit
(Section 4.3) functionality. Response status codes are defined in (Section 4.3) functionality. Response status codes are defined in
Section 4.5 and type definitions in Section 4.6. Section 4.6 and type definitions in Section 4.7.
Implementation of this control package MUST address the Security Implementation of this control package MUST address the Security
Considerations described in Section 7. Considerations described in Section 7.
Implementation of this control package MUST adhere to the syntax and Implementation of this control package MUST adhere to the syntax and
semantics of XML elements defined in this section and the schema semantics of XML elements defined in this section and the schema
(Section 5). The XML schema supports extensibility by allowing (Section 5). The XML schema supports extensibility by allowing
attributes and elements from other namespaces. Implementations MAY attributes and elements from other namespaces. Implementations MAY
support attributes and elements from other (foreign) namespaces. If support attributes and elements from other (foreign) namespaces. If
an MS implementation receives a <mscmixer> element containing an MS implementation receives a <mscmixer> element containing
attributes or elements from another namespace which it does not attributes or elements from another namespace which it does not
support, the MS sends a 428 response (Section 4.5). support, the MS sends a 428 response (Section 4.6).
Extensible attributes and elements are not described in this section. Extensible attributes and elements are not described in this section.
In all other cases where there is a difference in constraints between In all other cases where there is a difference in constraints between
the XML schema and the textual description of elements in this the XML schema and the textual description of elements in this
section, the textual definition takes priority. section, the textual definition takes priority.
Some elements in this control package contain attributes whose value
is descriptive text. Since the descriptive text is for diagnostic
use only, and is neither a protocol element nor intended for user
display, the descriptive text does not require a language indicator
such as a language tag ([RFC2277]) and thus does not carry one.
These comprise: the reason attribute on <response> (Section 4.2.3),
<unjoin-notify> (Section 4.2.4.2), <conferenceexit> (Section 4.2.4.3)
and <auditresponse> (Section 4.3.2).
Usage examples are provided in Section 6. Usage examples are provided in Section 6.
4.1. <mscmixer> 4.1. <mscmixer>
The <mscmixer> element has the following attributes (in addition to The <mscmixer> element has the following attributes (in addition to
standard XML namespace attributes such as xmlns): standard XML namespace attributes such as xmlns):
version: a string specifying the mscmixer package version. The version: a string specifying the mscmixer package version. The
value is fixed as '1.0' for this version of the package. The value is fixed as '1.0' for this version of the package. The
attribute is mandatory. attribute is mandatory.
skipping to change at page 13, line 28 skipping to change at page 13, line 37
<modifyjoin> modify the configuration of joined media streams. See <modifyjoin> modify the configuration of joined media streams. See
Section 4.2.2.3 Section 4.2.2.3
<unjoin> delete a media stream (for example, remove a participant <unjoin> delete a media stream (for example, remove a participant
from a conference). See Section 4.2.2.4 from a conference). See Section 4.2.2.4
Responses from the MS describe the status of the requested operation. Responses from the MS describe the status of the requested operation.
Responses are specified in a <response> element (Section 4.2.3) which Responses are specified in a <response> element (Section 4.2.3) which
includes a mandatory attribute describing the status in terms of a includes a mandatory attribute describing the status in terms of a
numeric code. Response status codes are defined in Section 4.5. The 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 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 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 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 MUST ensure that no part of the requested mixer operation is carried
out, and the MS MUST indicate the class of failure using an out, and the MS MUST indicate the class of failure using an
appropriate 4xx response code. Unless an error response code is appropriate 4xx response code. Unless an error response code is
specified for a class of error within this section, implementations specified for a class of error within this section, implementations
follow Section 4.5 in determining the appropriate status code for the follow Section 4.6 in determining the appropriate status code for the
response. response.
Notifications are sent from the MS to provide updates on the status Notifications are sent from the MS to provide updates on the status
of a mixer operation or subscription. Notifications are specified in of a mixer operation or subscription. Notifications are specified in
an <event> element (Section 4.2.4). an <event> element (Section 4.2.4).
4.2.1. Conference Elements 4.2.1. Conference Elements
4.2.1.1. <createconference> 4.2.1.1. <createconference>
skipping to change at page 14, line 14 skipping to change at page 14, line 23
conferenceid: string indicating a unique name for the new conferenceid: string indicating a unique name for the new
conference. If this attribute is not specified, the MS MUST conference. If this attribute is not specified, the MS MUST
create a unique name for the conference. The value is used in create a unique name for the conference. The value is used in
subsequent references to the conference (e.g. as conferenceid in a subsequent references to the conference (e.g. as conferenceid in a
<response>). The attribute is optional. There is no default <response>). The attribute is optional. There is no default
value. value.
reserved-talkers: indicates the requested number of guaranteed reserved-talkers: indicates the requested number of guaranteed
speaker slots to be reserved for the conference. A valid value is speaker slots to be reserved for the conference. A valid value is
a non-negative integer (see Section 4.6.2). The attribute is a non-negative integer (see Section 4.7.2). The attribute is
optional. The default value is 0. optional. The default value is 0.
reserved-listeners: indicates the requested number of guaranteed reserved-listeners: indicates the requested number of guaranteed
listener slots to be reserved for the conference. A valid value listener slots to be reserved for the conference. A valid value
is a non-negative integer (see Section 4.6.2). The attribute is is a non-negative integer (see Section 4.7.2). The attribute is
optional. The default value is 0. optional. The default value is 0.
The <createconference> element has the following sequence of child The <createconference> element has the following sequence of child
elements: elements:
<codecs>: an element to configure the codecs supported by the <codecs>: an element to configure the codecs supported by the
conference (see Section 4.4). If codecs are specified, then they conference (see Section 4.4). If codecs are specified, then they
impose limitations in media capability when the MS attempts to impose limitations in media capability when the MS attempts to
join the conference to other entities (see Section 4.2.2.2 and join the conference to other entities (see Section 4.2.2.2 and
Section 4.2.2.3). The element is optional. Section 4.2.2.3). The element is optional.
skipping to change at page 15, line 31 skipping to change at page 16, line 9
When a MS has finished processing a <createconference> request, it When a MS has finished processing a <createconference> request, it
MUST reply with an appropriate <response> element (Section 4.2.3). MUST reply with an appropriate <response> element (Section 4.2.3).
For example, a request to create an audio video conference mixer with For example, a request to create an audio video conference mixer with
specified codecs, video layout, video switch and subscription: specified codecs, video layout, video switch and subscription:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference conferenceid="conference1" <createconference conferenceid="conference1"
reserved-talkers="1" reserved-listeners="10"> reserved-talkers="1" reserved-listeners="10">
<codecs> <codecs>
<codec> <codec name="video">
<subtype>H264</subtype> <subtype>H264</subtype>
</codec> </codec>
<codec> <codec name="audio">
<subtype>PCMA</subtype> <subtype>PCMA</subtype>
</codec> </codec>
</codecs> </codecs>
<audio-mixing type="nbest"/> <audio-mixing type="nbest"/>
<video-layouts> <video-layouts>
<video-layout min-participants="1">single-view</video-layout> <video-layout min-participants="1"><single-view/></video-layout>
<video-layout min-participants="2">dual-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="3"><quad-view/></video-layout>
</video-layouts> </video-layouts>
<video-switch type="vas" interval="5"/> <video-switch interval="5"><vas/></video-switch>
<subscribe> <subscribe>
<active-talkers-sub interval="4"/> <active-talkers-sub interval="4"/>
</subscribe> </subscribe>
</createconference> </createconference>
</mscmixer> </mscmixer>
and a response from the MS if the conference was successfully and a response from the MS if the conference was successfully
created: created:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
skipping to change at page 18, line 28 skipping to change at page 19, line 9
Defined values are: "nbest" (where the N best (loudest) Defined values are: "nbest" (where the N best (loudest)
participant signals are mixed) and "controller" (where the participant signals are mixed) and "controller" (where the
contributing participant(s) is/are selected by the controlling AS contributing participant(s) is/are selected by the controlling AS
via an external floor control protocol). The attribute is via an external floor control protocol). The attribute is
optional. The default value is "nbest". optional. The default value is "nbest".
n: indicates the number of eligible participants included in the n: indicates the number of eligible participants included in the
conference audio mix. An eligible participant is a participant conference audio mix. An eligible participant is a participant
who contributes audio to the conference. Inclusion is based on who contributes audio to the conference. Inclusion is based on
having the greatest audio energy. A valid value is a non-negative having the greatest audio energy. A valid value is a non-negative
integer (see Section 4.6.2). A value of 0 indicates that all integer (see Section 4.7.2). A value of 0 indicates that all
participants contributing audio to the conference are included in participants contributing audio to the conference are included in
the audio mix. The default value is 0. The element is optional. 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 If the type attribute does not have the value "nbest", the MS ignores
the "n" attribute. the "n" attribute.
The <audio-mixing> element has no child elements. The <audio-mixing> element has no child elements.
For example, a fragment where the audio mixing policy is set to For example, a fragment where the audio mixing policy is set to
"nbest" with 3 participants to be included: "nbest" with 3 participants to be included:
skipping to change at page 19, line 37 skipping to change at page 20, line 18
greater than the number of participants in the conference, the greater than the number of participants in the conference, the
display of unassigned regions is implementation-specific. display of unassigned regions is implementation-specific.
The assignment of participant video streams to regions within the The assignment of participant video streams to regions within the
layout is according to the video switch policy specified by the layout is according to the video switch policy specified by the
<video-switch> element (Section 4.2.1.4.3). <video-switch> element (Section 4.2.1.4.3).
For example, a fragment describing a single layout: For example, a fragment describing a single layout:
<video-layouts> <video-layouts>
<video-layout>single-view</video-layout> <video-layout><single-view/></video-layout>
</video-layouts> </video-layouts>
And a fragment describing a sequence of layouts: And a fragment describing a sequence of layouts:
<video-layouts> <video-layouts>
<video-layout min-participants="1">single-view</video-layout> <video-layout min-participants="1"><single-view/></video-layout>
<video-layout min-participants="2">dual-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="3"><quad-view/></video-layout>
<video-layout min-participants="5">multiple-3x3</video-layout> <video-layout min-participants="5"><multiple-3x3/></video-layout>
</video-layouts> </video-layouts>
When the conference has one participant providing a video input When the conference has one participant providing a video input
stream to the conference, then the single-view format is used. When stream to the conference, then the single-view format is used. When
the conference has two such participants, the dual-view layout is the conference has two such participants, the dual-view layout is
used. When the conference has three or four participants, the quad- used. When the conference has three or four participants, the quad-
view layout is used. When the conference has five or more view layout is used. When the conference has five or more
participants, the multiple-3x3 layout is used. participants, the multiple-3x3 layout is used.
4.2.1.4.2.1. <video-layout> 4.2.1.4.2.1. <video-layout>
The <video-layout> element describes a video layout containing one or The <video-layout> element describes a video layout containing one or
more regions in which participant video input streams are displayed. more regions in which participant video input streams are displayed.
The <video-layout> element has the following attributes: The <video-layout> element has the following attributes:
min-participants: the minimum number of conference participants min-participants: the minimum number of conference participants
needed to allow this layout to be active. A valid value is a needed to allow this layout to be active. A valid value is a
positive integer (see Section 4.6.3). The attribute is optional. positive integer (see Section 4.7.3). The attribute is optional.
The default value is 1. The default value is 1.
The <video-layout> element has a content model specifying the name of The <video-layout> element has one child element specifying the video
the video layout. layout. An MS MAY support the predefined video layouts defined in
the XCON conference information data model
([I-D.ietf-xcon-common-data-model]): <single-view>, <dual-view>,
<dual-view-crop>, <dual-view-2x1>, <dual-view-2x1-crop>, <quad-view>,
<multiple-3x3>, <multiple-4x4> and <multiple-5x1>.
An MS MAY support the predefined video layouts defined in the XCON The MS MAY support other video layouts. Non-XCON layouts MUST be
conference information data model specified using an element from a namespace other than the one used
([I-D.ietf-xcon-common-data-model]). The MS MAY support other video in this specification. For example,
layouts. Non-XCON layouts MUST be prefixed with a label; for
example, <video-layout>mylayout:single-view<video-layout>. <video-layout>
<mylayout xmlns='http://example.com/foo'>my-single-view</mylayout>
</video-layout>
If the MS does not support the specified video layout configuration,
then the MS reports a 423 error (Section 4.6) in the response to the
request element containing the <video-layout> element.
Each video layout has associated with it one or more regions. The Each video layout has associated with it one or more regions. The
XCON layouts are associated with the following named regions: XCON layouts are associated with the following named regions:
single-view layout with one stream in a single region as shown in <single-view/> layout with one stream in a single region as shown in
Figure 1. Figure 1.
+-----------+ +-----------+
| | | |
| | | |
| 1 | | 1 |
| | | |
| | | |
+-----------+ +-----------+
Figure 1: single-view video layout Figure 1: single-view video layout
dual-view layout presenting two streams side-by-side in two regions <dual-view/> layout presenting two streams side-by-side in two
as shown in Figure 2. The MS MUST NOT alter the aspect ratio of regions as shown in Figure 2. The MS MUST NOT alter the aspect
each stream to fit the region and hence the MS might need to blank ratio of each stream to fit the region and hence the MS might need
out part of each region. to blank out part of each region.
+-----------+-----------+ +-----------+-----------+
| | | | | |
| | | | | |
| 1 | 2 | | 1 | 2 |
| | | | | |
| | | | | |
+-----------+-----------+ +-----------+-----------+
Figure 2: dual-view video layout Figure 2: dual-view video layout
dual-view-crop layout presenting two streams side-by-side in two <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 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. of each stream to fit its region so that no blanking is required.
+-----------+-----------+ +-----------+-----------+
| | | | | |
| | | | | |
| 1 | 2 | | 1 | 2 |
| | | | | |
| | | | | |
+-----------+-----------+ +-----------+-----------+
Figure 3: dual-view-crop video layout Figure 3: dual-view-crop video layout
dual-view-2x1 layout presenting two streams one above the other in <dual-view-2x1/> layout presenting two streams one above the other
two regions as shown in Figure 4. The MS MUST NOT alter the 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 aspect ratio of each stream to fit its region and hence the MS
might need to blank out part of each region. might need to blank out part of each region.
+-----------+ +-----------+
| | | |
| | | |
| 1 | | 1 |
| | | |
| | | |
+-----------+ +-----------+
| | | |
| | | |
| 2 | | 2 |
| | | |
| | | |
+-----------+ +-----------+
Figure 4: dual-view-2x1 video layout Figure 4: dual-view-2x1 video layout
dual-view-2x1-crop layout presenting two streams one above the other <dual-view-2x1-crop/> layout presenting two streams one above the
in two regions as shown in Figure 5. The MS MUST alter the aspect other in two regions as shown in Figure 5. The MS MUST alter the
ratio of each stream to fit its region so that no blanking is aspect ratio of each stream to fit its region so that no blanking
required. is required.
+-----------+ +-----------+
| | | |
| | | |
| 1 | | 1 |
| | | |
| | | |
+-----------+ +-----------+
| | | |
| | | |
| 2 | | 2 |
| | | |
| | | |
+-----------+ +-----------+
Figure 5: dual-view-2x1-crop video layout Figure 5: dual-view-2x1-crop video layout
quad-view layout presenting four equal-sized regions in a 2x2 layout <quad-view/> layout presenting four equal-sized regions in a 2x2
as shown in Figure 6. Typically the aspect ratio of the streams layout as shown in Figure 6. Typically the aspect ratio of the
is preserved, so blanking is required. streams is preserved, so blanking is required.
+-----------+-----------+ +-----------+-----------+
| | | | | |
| | | | | |
| 1 | 2 | | 1 | 2 |
| | | | | |
| | | | | |
+-----------+-----------+ +-----------+-----------+
| | | | | |
| | | | | |
| 3 | 4 | | 3 | 4 |
| | | | | |
| | | | | |
+-----------+-----------+ +-----------+-----------+
Figure 6: quad-view video layout Figure 6: quad-view video layout
multiple-3x3 layout presenting nine equal-sized regions in a 3x3 <multiple-3x3/> layout presenting nine equal-sized regions in a 3x3
layout as shown in Figure 7. Typically the aspect ratio of the layout as shown in Figure 7. Typically the aspect ratio of the
streams is preserved, so blanking is required. streams is preserved, so blanking is required.
+-----------+-----------+-----------+ +-----------+-----------+-----------+
| | | | | | | |
| | | | | | | |
| 1 | 2 | 3 | | 1 | 2 | 3 |
| | | | | | | |
| | | | | | | |
+-----------+-----------+-----------+ +-----------+-----------+-----------+
skipping to change at page 23, line 31 skipping to change at page 24, line 27
+-----------+-----------+-----------+ +-----------+-----------+-----------+
| | | | | | | |
| | | | | | | |
| 7 | 8 | 9 | | 7 | 8 | 9 |
| | | | | | | |
| | | | | | | |
+-----------+-----------+-----------+ +-----------+-----------+-----------+
Figure 7: multiple-3x3 video layout Figure 7: multiple-3x3 video layout
multiple-4x4 layout presenting sixteen equal-sized regions in a 4x4 <multiple-4x4/> layout presenting sixteen equal-sized regions in a
layout as shown in Figure 8. Typically the aspect ratio of the 4x4 layout as shown in Figure 8. Typically the aspect ratio of
streams is preserved, so blanking is required. the streams is preserved, so blanking is required.
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| | | | | | | | | |
| | | | | | | | | |
| 1 | 2 | 3 | 4 | | 1 | 2 | 3 | 4 |
| | | | | | | | | |
| | | | | | | | | |
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| | | | | | | | | |
| | | | | | | | | |
skipping to change at page 24, line 33 skipping to change at page 25, line 33
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
| | | | | | | | | |
| | | | | | | | | |
| 13 | 14 | 15 | 16 | | 13 | 14 | 15 | 16 |
| | | | | | | | | |
| | | | | | | | | |
+-----------+-----------+-----------+-----------+ +-----------+-----------+-----------+-----------+
Figure 8: multiple-4x4 video layout Figure 8: multiple-4x4 video layout
multiple-5x1 layout presents a 5x1 layout as shown in Figure 9 where <multiple-5x1/> layout presents a 5x1 layout as shown in Figure 9
one region will occupy 4/9 of the mixed video stream while the where one region will occupy 4/9 of the mixed video stream while
others will each occupy 1/9 of the stream. Typically the aspect the others will each occupy 1/9 of the stream. Typically the
ratio of the streams is preserved, so blanking is required. aspect ratio of the streams is preserved, so blanking is required.
+-----------------------+-----------+ +-----------------------+-----------+
| | | | | |
| | | | | |
| | 2 | | | 2 |
| | | | | |
| | | | | |
| 1 +-----------+ | 1 +-----------+
| | | | | |
| | | | | |
skipping to change at page 25, line 33 skipping to change at page 26, line 33
+-----------+-----------+-----------+ +-----------+-----------+-----------+
Figure 9: multiple-5x1 video layout Figure 9: multiple-5x1 video layout
4.2.1.4.3. <video-switch> 4.2.1.4.3. <video-switch>
The <video-switch> element describe the configuration of the The <video-switch> element describe the configuration of the
conference policy for how participant's input video streams are conference policy for how participant's input video streams are
assigned to regions within the active video layout. assigned to regions within the active video layout.
The <video-switch> element has the following attributes: The <video-switch> element has the following child elements defined
(one child occurrence only) indicating the video switching policy of
the conference:
type: a string indicating the video switching policy of the <vas/> (Voice Activated Switching) enables automatic display of the
conference. Defined values are: loudest speaker participant also providing a video input stream to
the conference. Participants who do not provide an audio stream
are not considered for automatic display. If a participant
provides more than one audio stream, then the policy for inclusion
of such a participant in the VAS is implementation-specific; an MS
could select one stream, sum audio streams or ignore the
participant for VAS consideration. If there is only one 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.
vas (Voice Activated Switching) enables automatic display of the <controller/> enables manual control over video switching. The
loudest speaker participant also providing a video input stream controller AS determines how the regions are assigned based on an
to the conference. Participants who do not provide an audio external floor control policy. The MS receives <join>,
stream are not considered for automatic display. If a <modifyjoin> and <unjoin> commands with a <stream> element
participant provides more than one audio stream, then the (Section 4.2.2.5) indicating the region where the stream is
policy for inclusion of such a participant in the VAS is displayed. If no explicit region is specified, the MS assigns the
implementation-specific; an MS could select one stream, sum region based on the priority mechanism described in
audio streams or ignore the participant for VAS consideration. Section 4.2.1.4.3.1.
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 An MS MAY support other video switching policies. Other policies
controller AS determines how the regions are assigned based on MUST be specified using an element from a namespace other than the
an external floor control policy. The MS receives <join>, one used in this specification. For example,
<modifyjoin> and <join> 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 policy <video-switch>
names MUST be prefixed with a label; e.g. "mypolicies:policy1". <mypolicy xmlns='http://example.com/foo'/>
The attribute is optional. The default value is 'vas'. </video-switch>
The <video-switch> element has the following attributes:
interval: specifies the period between video switches as a number of interval: specifies the period between video switches as a number of
seconds. In the case of 'vas' policy, a speaker needs to be the seconds. In the case of <vas/> policy, a speaker needs to be the
loudest speaker for the interval before the switch takes place. A loudest speaker for the interval before the switch takes place. A
valid value is a non-negative integer (see Section 4.6.2). A valid value is a non-negative integer (see Section 4.7.2). A
value of 0 indicates that switching is applied immediately. The value of 0 indicates that switching is applied immediately. The
attribute is optional. The default value is 3 (seconds). attribute is optional. The default value is 3 (seconds).
activespeakermix: indicates whether or not the active (loudest) activespeakermix: indicates whether or not the active (loudest)
speaker participant receives a video stream without themselves speaker participant receives a video stream without themselves
displayed in the case of the 'vas' switching policy. If enabled, displayed in the case of the <vas/> switching policy. If enabled,
the MS needs to generate two video streams for each conference the MS needs to generate two video streams for each conference
mix: one for the active speaker participant without themselves mix: one for the active speaker participant without themselves
displayed - details of this video layout are implementation- displayed - details of this video layout are implementation-
specific; and one for other participants as described in the 'vas' specific; and one for other participants as described in the
switch policy above. A valid value is a boolean (see <vas/> switch policy above. A valid value is a boolean (see
Section 4.6.1). A value of true indicates that a separate video Section 4.7.1). A value of true indicates that a separate video
mix is generated for the active speaker without themselves being mix is generated for the active speaker without themselves being
displayed. A value of false indicates that all participants displayed. A value of false indicates that all participants
receive the same video mix. The attribute is optional. The receive the same video mix. The attribute is optional. The
default value is false. If the type attribute is not set to default value is false. If the type attribute is not set to
'vas', the MS ignores this attribute. <vas/>, the MS ignores this attribute.
If the MS does not support the specified video switching policy or If the MS does not support the specified video switching policy or
other configuration parameters (including separate active speaker other configuration parameters (including separate active speaker
video mixes), then MS reports a 424 error (Section 4.5) in the video mixes), then MS reports a 424 error (Section 4.6) in the
response to the request element containing the <video-switch> response to the request element containing the <video-switch>
element. element.
If the MS receives a <join> or <modifyjoin> request containing a If the MS receives a <join> or <modifyjoin> request containing a
<stream> element (Section 4.2.2.5) specifying a region and the <stream> element (Section 4.2.2.5) specifying a region and the
conference video switching policy is set to 'vas', then the MS conference video switching policy is set to <vas/>, then the MS
ignores the region (i.e. conference switching policy takes ignores the region (i.e. conference switching policy takes
precedence). precedence).
If the MS receives a <join> or <modifyjoin> request containing a If the MS receives a <join> or <modifyjoin> request containing a
<stream> element (Section 4.2.2.5) specifying a region which is not <stream> element (Section 4.2.2.5) specifying a region which is not
defined for the currently active video layout, the MS MUST NOT report defined for the currently active video layout, the MS MUST NOT report
an error. Even though the participant is not currently visible, the an error. Even though the participant is not currently visible, the
MS displays the participant if the layout changes to one which MS displays the participant if the layout changes to one which
defines the specified region. defines the specified region.
The <video-switch> element has no child elements. For example, a fragment specifying a <vas/> video switching policy
For example, a fragment specifying a 'vas' video switching policy
with an interval of 2s with an interval of 2s
<video-switch type="vas" interval="2"/> <video-switch interval="2"><vas/></video-switch>
For example, a fragment specifying a 'controller' video switching For example, a fragment specifying a <controller/> video switching
policy where video switching takes place immediately: policy where video switching takes place immediately:
<video-switch type="controller" interval="0"/> <video-switch interval="0"><controller/></video-switch>
4.2.1.4.3.1. Priority assignment 4.2.1.4.3.1. Priority assignment
In cases where the video switching policy does not explicitly In cases where the video switching policy does not explicitly
determine the region to which a participant is assigned, the determine the region to which a participant is assigned, the
following priority assignment mechanism applies: following priority assignment mechanism applies:
1. Each participant has an (positive integer) priority value: the 1. Each participant has an (positive integer) priority value: the
lower the value, the higher the priority. The priority value is lower the value, the higher the priority. The priority value is
determined by the <priority> child element (Section 4.2.2.5.4) of determined by the <priority> child element (Section 4.2.2.5.4) of
skipping to change at page 28, line 24 skipping to change at page 29, line 27
The <subscribe> element has no attributes, but has the following The <subscribe> element has no attributes, but has the following
child element: child element:
<active-talkers-sub>: subscription to active talker events <active-talkers-sub>: subscription to active talker events
(Section 4.2.1.4.4.1). The element is optional. (Section 4.2.1.4.4.1). The element is optional.
The MS MUST support a <active-talkers-sub> subscription. It MAY The MS MUST support a <active-talkers-sub> subscription. It MAY
support other event subscriptions (specified using attributes and support other event subscriptions (specified using attributes and
child elements from a foreign namespace). If the MS does not support child elements from a foreign namespace). If the MS does not support
a subscription specified in a foreign namespace, it sends a a subscription specified in a foreign namespace, it sends a
<response> with a 428 status code (see Section 4.5). <response> with a 428 status code (see Section 4.6).
4.2.1.4.4.1. <active-talkers-sub> 4.2.1.4.4.1. <active-talkers-sub>
The <active-talkers-sub> element has the following attributes: The <active-talkers-sub> element has the following attributes:
interval: the minimum amount of time (in seconds) that elapses interval: the minimum amount of time (in seconds) that elapses
before further active talker events can be generated. A valid before further active talker events can be generated. A valid
value is a non-negative integer (see Section 4.6.2). A value of 0 value is a non-negative integer (see Section 4.7.2). A value of 0
suppresses further notifications. The attribute is optional. The suppresses further notifications. The attribute is optional. The
default value is 3 (seconds). default value is 3 (seconds).
The <active-talker-sub> element has no child elements. The <active-talkers-sub> element has no child elements.
Active talker notifications are delivered in the <active-talker- Active talker notifications are delivered in the <active-talkers-
notify> element (Section 4.2.4.1). notify> element (Section 4.2.4.1).
4.2.2. Joining Elements 4.2.2. Joining Elements
In this section, the joining model is defined (Section 4.2.2.1) as In this section, the joining model is defined (Section 4.2.2.1) as
well as definitions of the <join> (Section 4.2.2.2), <modifyjoin> well as definitions of 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.3), <unjoin> (Section 4.2.2.4) and <stream>
(Section 4.2.2.5) elements. (Section 4.2.2.5) elements.
4.2.2.1. Joining Model 4.2.2.1. Joining Model
skipping to change at page 36, line 18 skipping to change at page 37, line 24
manipulations of media streams. Media streams represent the flow of manipulations of media streams. Media streams represent the flow of
media between a participant connection and a conference, between two media between a participant connection and a conference, between two
connections, or between two conferences. The <stream> element is connections, or between two conferences. The <stream> element is
used (as a child to <join>, <modifyjoin> and <unjoin) to identify the used (as a child to <join>, <modifyjoin> and <unjoin) to identify the
media stream(s) for the request and to specify the configuration of media stream(s) for the request and to specify the configuration of
the media stream. the media stream.
The <stream> element has the following attributes: The <stream> element has the following attributes:
media: a string indicating the type of media associated with the media: a string indicating the type of media associated with the
stream. The following values MUST be used for common types of stream. A valid value is a MIME type-name as defined in Section
media: "audio" for audio media, and "video" for video media. The 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 ([IANA]) for registered MIME type names. The
attribute is mandatory. attribute is mandatory.
label: a string indicating the SDP label associated with a media label: a string indicating the SDP label associated with a media
stream ([RFC4574]). The attribute is optional. stream ([RFC4574]). The attribute is optional.
direction: a string indicating the allowed media flow of the stream direction: a string indicating the allowed media flow of the stream
relative to the value of the "id1" attribute of the parent relative to the value of the "id1" attribute of the parent
element. Defined values are: "sendrecv" (media can be sent and element. Defined values are: "sendrecv" (media can be sent and
received), "sendonly" (media can only be sent), "recvonly" (media received), "sendonly" (media can only be sent), "recvonly" (media
can only be received) and "inactive" (stream established but no can only be received) and "inactive" (stream established but no
skipping to change at page 38, line 35 skipping to change at page 39, line 45
4.2.2.5.2. <clamp> 4.2.2.5.2. <clamp>
The <clamp> element is used to configure whether tones are filtered The <clamp> element is used to configure whether tones are filtered
and removed from a media stream. and removed from a media stream.
The <clamp> element has no child elements but has the following The <clamp> element has no child elements but has the following
attributes: attributes:
tones: A space-separated list of the tones to remove. The attribute tones: A space-separated list of the tones to remove. The attribute
is optional. The default value is "1 2 3 4 5 6 7 8 9 0 * # A B C is optional. The default value is "1 2 3 4 5 6 7 8 9 0 * # A B C
D" (i.e. all DTMF tones removed). D" (i.e. all DTMF (Dual-Tone Multi-Frequency) tones removed).
4.2.2.5.3. <region> 4.2.2.5.3. <region>
The <region> element is used to explicitly specify the region within As described in Section 4.2.1.4.2.1, each <video-layout> is composed
a video layout where the media stream is displayed. of one or more named regions (or areas) in which video media can be
presented. For example, the XCON layout <dual-view> has two regions
named "1" and "2" respectively.
The <region> element is used to explicitly specify the name of the
area within a video layout where a video media stream is displayed.
The <region> element has no attributes and its content model The <region> element has no attributes and its content model
specifies the name of the region layout. specifies the name of the region.
4.2.2.5.4. <priority> 4.2.2.5.4. <priority>
The <priority> element is used to explicitly specify the priority of The <priority> element is used to explicitly specify the priority of
a participant. The MS uses this priority to determine where the a participant. The MS uses this priority to determine where the
media stream is displayed within a video layout media stream is displayed within a video layout
(Section 4.2.1.4.3.1). (Section 4.2.1.4.3.1).
The <priority> element has no attributes and its content model The <priority> element has no attributes and its content model
specifies a positive integer (see Section 4.6.3). The lower the specifies a positive integer (see Section 4.7.3). The lower the
value, the higher the priority. value, the higher the priority.
4.2.3. <response> 4.2.3. <response>
Responses to requests are indicated by a <response> element. Responses to requests are indicated by a <response> element.
The <response> element has following attributes: The <response> element has following attributes:
status: numeric code indicating the response status. Valid values status: numeric code indicating the response status. Valid values
are defined in Section 4.5. The attribute is mandatory. are defined in Section 4.6. The attribute is mandatory.
reason: string specifying a reason for the response status. The reason: string specifying a reason for the response status. The
attribute is optional. attribute is optional.
conferenceid: string identifying the conference (see Section 16.1 of conferenceid: string identifying the conference (see Section 16.1 of
[I-D.ietf-mediactrl-sip-control-framework]). The attribute is [I-D.ietf-mediactrl-sip-control-framework]). The attribute is
optional. optional.
connectionid: string identifying the SIP dialog connection (see connectionid: string identifying the SIP dialog connection (see
Section 16.1 of [I-D.ietf-mediactrl-sip-control-framework]). The Section 16.1 of [I-D.ietf-mediactrl-sip-control-framework]). The
attribute is optional. attribute is optional.
For example, a response when a conference was created successfully: For example, a response when a conference was created successfully:
<response code="200"> <response code="200"/>
<reason>Success</reason>
</response>
The response if conference creation failed due to the requested The response if conference creation failed due to the requested
conference id already existing: conference id already existing:
<response code="403"> <response code="405" reason="Conference already exists"/>
<reason>Conf already exists</reason>
</response>
4.2.4. <event> 4.2.4. <event>
When a mixer generates a notification event, the MS sends the event When a mixer generates a notification event, the MS sends the event
using an <event> element. using an <event> element.
The <event> element has no attributes, but has the following sequence The <event> element has no attributes, but has the following sequence
of child elements (0 or more instances of each child): of child elements (0 or more instances of each child):
<active-talkers-notify> specifies an active talkers notification <active-talkers-notify> specifies an active talkers notification
skipping to change at page 41, line 13 skipping to change at page 42, line 17
The <active-talker> element has no child elements. The <active-talker> element has no child elements.
4.2.4.2. <unjoin-notify> 4.2.4.2. <unjoin-notify>
The <unjoin-notify> element describes a notification event where a The <unjoin-notify> element describes a notification event where a
connection and/or conference have been completely unjoined. connection and/or conference have been completely unjoined.
The <unjoin-notify> element has the following attributes: The <unjoin-notify> element has the following attributes:
status: a status code indicating why the unjoin occurred. A valid status: a status code indicating why the unjoin occurred. A valid
value is a non-negative integer (see Section 4.6.2). The MS MUST value is a non-negative integer (see Section 4.7.2). The MS MUST
support the following values: support the following values:
0 indicates the join has been terminated by a <unjoin> request. 0 indicates the join has been terminated by a <unjoin> request.
1 indicates the join terminated due to an execution error. 1 indicates the join terminated due to an execution error.
2 indicates that the join terminated because a connection or 2 indicates that the join terminated because a connection or
conference has terminated. conference has terminated.
All other valid but undefined values are reserved for future use, All other valid but undefined values are reserved for future use,
where a standards-track RFC is required to define new status where new status codes are assigned using the Standards Action
codes. The AS MUST treat any status code it does not recognize as process defined in [RFC5226]. The AS MUST treat any status code
being equivalent to 1 (join execution error). The attribute is it does not recognize as being equivalent to 1 (join execution
mandatory. error). The attribute is mandatory.
reason: a textual description providing a reason for the status reason: a textual description providing a reason for the status
code; e.g. details about an error. A valid value is a string (see code; e.g. details about an error. A valid value is a string (see
Section 4.6.4). The attribute is optional. There is no default Section 4.7.4). The attribute is optional. There is no default
value. value.
id1: an identifier for either a connection or a conference. The id1: an identifier for either a connection or a conference. The
identifier MUST conform to the syntax defined in Section 16.1 of identifier MUST conform to the syntax defined in Section 16.1 of
[I-D.ietf-mediactrl-sip-control-framework] The attribute is [I-D.ietf-mediactrl-sip-control-framework] The attribute is
mandatory. mandatory.
id2: an identifier for either a connection or a conference. The id2: an identifier for either a connection or a conference. The
identifier MUST conform to the syntax defined in Section 16.1 of identifier MUST conform to the syntax defined in Section 16.1 of
[I-D.ietf-mediactrl-sip-control-framework] The attribute is [I-D.ietf-mediactrl-sip-control-framework] The attribute is
skipping to change at page 42, line 11 skipping to change at page 43, line 19
example, a hardware error in the conference mixing unit). This event example, a hardware error in the conference mixing unit). This event
MUST be sent by the MS whenever a successfully created conference MUST be sent by the MS whenever a successfully created conference
exits. exits.
The <conferenceexit> element has the following attributes: The <conferenceexit> element has the following attributes:
conferenceid: string indicating the name of the conference. This conferenceid: string indicating the name of the conference. This
attribute is mandatory. attribute is mandatory.
status: a status code indicating why the conference exited. A valid status: a status code indicating why the conference exited. A valid
value is a non-negative integer (see Section 4.6.2). The MS MUST value is a non-negative integer (see Section 4.7.2). The MS MUST
support the following values: support the following values:
0 indicates the conference has been terminated by a 0 indicates the conference has been terminated by a
<destroyconference> request. <destroyconference> request.
1 indicates the conference terminated due to an execution error. 1 indicates the conference terminated due to an execution error.
2 indicates the conference terminated due to exceeding the 2 indicates the conference terminated due to exceeding the
maximum duration for a conference. maximum duration for a conference.
All other valid but undefined values are reserved for future use, All other valid but undefined values are reserved for future use,
where a standards-track RFC is required to define new status where new status codes are assigned using the Standards Action
codes. The AS MUST treat any status code it does not recognize as process defined in [RFC5226]. The AS MUST treat any status code
being equivalent to 1 (conference execution error). The attribute it does not recognize as being equivalent to 1 (conference
is mandatory. execution error). The attribute is mandatory.
reason: a textual description providing a reason for the status reason: a textual description providing a reason for the status
code; e.g. details about an error. A valid value is a string (see code; e.g. details about an error. A valid value is a string (see
Section 4.6.4). The attribute is optional. There is no default Section 4.7.4). The attribute is optional. There is no default
value. value.
The <conferenceexit> element has no child elements. The <conferenceexit> element has no child elements.
When a MS sends a <conferenceexit> event, the identifier for the When a MS sends a <conferenceexit> event, the identifier for the
conference (conferenceid attribute) is no longer valid on the MS and conference (conferenceid attribute) is no longer valid on the MS and
can be reused for another conference. can be reused for another conference.
For example, the following notification event would be sent from the For example, the following notification event would be sent from the
MS when the conference with identifier "conference99" exits due to a MS when the conference with identifier "conference99" exits due to a
skipping to change at page 43, line 32 skipping to change at page 44, line 39
The <audit> request element is sent to the MS to request information The <audit> request element is sent to the MS to request information
about the capabilities of, and mixers currently managed with, this about the capabilities of, and mixers currently managed with, this
control package. Capabilities include supported conference codecs control package. Capabilities include supported conference codecs
and video layouts. Mixer information includes the status of managed and video layouts. Mixer information includes the status of managed
mixers as well as codecs. mixers as well as codecs.
The <audit> element has the following attributes: The <audit> element has the following attributes:
capabilities: indicates whether package capabilities are to be capabilities: indicates whether package capabilities are to be
audited. A valid value is a boolean (see Section 4.6.1). A value audited. A valid value is a boolean (see Section 4.7.1). A value
of true indicates that capability information is to be reported. of true indicates that capability information is to be reported.
A value of false indicates that capability information is not to A value of false indicates that capability information is not to
be reported. The attribute is optional. The default value is be reported. The attribute is optional. The default value is
true. true.
mixers: indicates whether mixers currently managed by the package mixers: indicates whether mixers currently managed by the package
are to be audited. A valid value is a boolean (see are to be audited. A valid value is a boolean (see
Section 4.6.1). A value of true indicates that mixer information Section 4.7.1). A value of true indicates that mixer information
is to be reported. A value of false indicates that mixer is to be reported. A value of false indicates that mixer
information is not to be reported. The attribute is optional. information is not to be reported. The attribute is optional.
The default value is true. The default value is true.
conferenceid: string identifying a specific conference mixer to conferenceid: string identifying a specific conference mixer to
audit. It is an error (406) if the conferenceid attribute is audit. It is an error (406) if the conferenceid attribute is
specified and the conference identifier is not valid. The specified and the conference identifier is not valid. The
attribute is optional. There is no default value. attribute is optional. There is no default value.
If the mixers attribute has the value true and conferenceid attribute If the mixers attribute has the value true and conferenceid attribute
is specified, then only audit information about the specified is specified, then only audit information about the specified
conference mixer is reported. If the mixers attribute has the value conference mixer is reported. If the mixers attribute has the value
false, then no mixer audit information is reported even if a false, then no mixer audit information is reported even if a
conferenceid attribute is specified. conferenceid attribute is specified.
The <audit> element has no child elements. The <audit> element has no child elements.
When the MS receives an <audit> request, it MUST reply with a When the MS receives an <audit> request, it MUST reply with a
<auditresponse> element (Section 4.3.2) which includes a mandatory <auditresponse> element (Section 4.3.2) which includes a mandatory
attribute describing the status in terms of a numeric code. Response attribute describing the status in terms of a numeric code. Response
status codes are defined in Section 4.5. If the request is status codes are defined in Section 4.6. If the request is
successful, the <auditresponse> contains (depending on attribute successful, the <auditresponse> contains (depending on attribute
values) a <capabilities> element (Section 4.3.2.1) reporting package values) a <capabilities> element (Section 4.3.2.1) reporting package
capabilities and a <mixers> element (Section 4.3.2.2) reporting capabilities and a <mixers> element (Section 4.3.2.2) reporting
managed mixer information. If the MS is not able to process the managed mixer information. If the MS is not able to process the
request and carry out the audit operation, the audit request has request and carry out the audit operation, the audit request has
failed and the MS MUST indicate the class of failure using an failed and the MS MUST indicate the class of failure using an
appropriate 4xx response code. Unless an error response code is appropriate 4xx response code. Unless an error response code is
specified for a class of error within this section, implementations specified for a class of error within this section, implementations
follow Section 4.5 in determining the appropriate status code for the follow Section 4.6 in determining the appropriate status code for the
response. response.
For example, a request to audit capabilities and mixers managed by For example, a request to audit capabilities and mixers managed by
the package: the package:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<audit/> <audit/>
</mscmixer> </mscmixer>
In this example, only capabilities are to be audited: In this example, only capabilities are to be audited:
skipping to change at page 45, line 6 skipping to change at page 46, line 13
</mscmixer> </mscmixer>
4.3.2. <auditresponse> 4.3.2. <auditresponse>
The <auditresponse> element describes a response to a <audit> The <auditresponse> element describes a response to a <audit>
request. request.
The <auditresponse> element has the following attributes: The <auditresponse> element has the following attributes:
status: numeric code indicating the audit response status. The status: numeric code indicating the audit response status. The
attribute is mandatory. Valid values are defined in Section 4.5. attribute is mandatory. Valid values are defined in Section 4.6.
reason: string specifying a reason for the status. The attribute is reason: string specifying a reason for the status. The attribute is
optional. optional.
The <auditresponse> element has the following sequence of child The <auditresponse> element has the following sequence of child
elements: elements:
<capabilities> element (Section 4.3.2.1) describing capabilities of <capabilities> element (Section 4.3.2.1) describing capabilities of
the package. The element is optional. the package. The element is optional.
<mixers> element (Section 4.3.2.2) describing information about <mixers> element (Section 4.3.2.2) describing information about
managed mixers. The element is optional. managed mixers. The element is optional.
For example, a successful response to a <audit> request requesting For example, a successful response to a <audit> request requesting
capabilities and mixer information: capabilities and mixer information:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<auditresponse status="200"> <auditresponse status="200">
<capabilities> <capabilities>
<codecs> <codecs>
<codec> <codec name="video">
<subtype>H263</subtype> <subtype>H263</subtype>
</codec> </codec>
<codec> <codec name="video">
<subtype>H264</subtype> <subtype>H264</subtype>
</codec> </codec>
<codec> <codec name="audio">
<subtype>PCMU</subtype> <subtype>PCMU</subtype>
</codec> </codec>
<codec> <codec name="audio">
<subtype>PCMA</subtype> <subtype>PCMA</subtype>
</codec> </codec>
</codecs> </codecs>
</capabilities> </capabilities>
<mixers> <mixers>
<conferenceaudit conferenceid="conf1"> <conferenceaudit conferenceid="conf1">
<codecs> <codecs>
<codec> <codec name="audio">
<subtype>PCMA</subtype> <subtype>PCMA</subtype>
</codec> </codec>
</codecs> </codecs>
<participants> <participants>
<participant id="1536067209:913cd14c"/> <participant id="1536067209:913cd14c"/>
</participants> </participants>
</conferenceaudit> </conferenceaudit>
<joinaudit id1="1536067209:913cd14c" id2="conf1"/> <joinaudit id1="1536067209:913cd14c" id2="conf1"/>
<joinaudit id1="1636067209:113cd14c" id2="1836067209:313cd14c"/> <joinaudit id1="1636067209:113cd14c" id2="1836067209:313cd14c"/>
<joinaudit id1="1736067209:213cd14c" id2="1936067209:413cd14c"/> <joinaudit id1="1736067209:213cd14c" id2="1936067209:413cd14c"/>
skipping to change at page 47, line 12 skipping to change at page 48, line 12
The <capabilities> element has the following sequence of child The <capabilities> element has the following sequence of child
elements: elements:
<codecs>: element (Section 4.4) describing codecs available to the <codecs>: element (Section 4.4) describing codecs available to the
package. The element is mandatory. package. The element is mandatory.
For example, a fragment describing capabilities: For example, a fragment describing capabilities:
<capabilities> <capabilities>
<codecs> <codecs>
<codec> <codec name="video">
<subtype>H263</subtype> <subtype>H263</subtype>
</codec> </codec>
<codec> <codec name="video">
<subtype>H264</subtype> <subtype>H264</subtype>
</codec> </codec>
<codec> <codec name="audio">
<subtype>PCMU</subtype> <subtype>PCMU</subtype>
</codec> </codec>
<codec> <codec name="audio">
<subtype>PCMA</subtype> <subtype>PCMA</subtype>
</codec> </codec>
</codecs> </codecs>
</capabilities> </capabilities>
4.3.2.2. <mixers> 4.3.2.2. <mixers>
The <mixers> element provides audit information about mixers. The <mixers> element provides audit information about mixers.
The <mixers> element has no attributes. The <mixers> element has no attributes.
skipping to change at page 48, line 25 skipping to change at page 49, line 25
For example, a fragment describing a conference which has been For example, a fragment describing a conference which has been
created but has no participants: created but has no participants:
<conferenceaudit conferenceid="conference1"/> <conferenceaudit conferenceid="conference1"/>
And a fragment when the same conference has three participants (two And a fragment when the same conference has three participants (two
connections and another conference) joined to it: connections and another conference) joined to it:
<conferenceaudit conferenceid="conference1"> <conferenceaudit conferenceid="conference1">
<codecs> <codecs>
<codec> <codec name="audio">
<subtype>PCMU</subtype> <subtype>PCMU</subtype>
</codec> </codec>
</codecs> </codecs>
<participants> <participants>
<participant id="connection1"/> <participant id="connection1"/>
<participant id="connection2"/> <participant id="connection2"/>
<participant id="conference2"/> <participant id="conference2"/>
</participants> </participants>
</conferenceaudit> </conferenceaudit>
skipping to change at page 50, line 11 skipping to change at page 51, line 11
The <codecs> element has the following sequence of child elements (0 The <codecs> element has the following sequence of child elements (0
or more occurrences): or more occurrences):
<codec>: defines a codec and optionally its policy (Section 4.4.1). <codec>: defines a codec and optionally its policy (Section 4.4.1).
The element is optional. The element is optional.
For example, a fragment describing two codecs: For example, a fragment describing two codecs:
<codecs> <codecs>
<codec> <codec name="audio">
<subtype>PCMA</subtype> <subtype>PCMA</subtype>
</codec> </codec>
<codec> <codec name="video">
<subtype>H263</subtype> <subtype>H263</subtype>
</codec> </codec>
</codecs> </codecs>
4.4.1. <codec> 4.4.1. <codec>
The <codec> element describes a codec. The element is modeled on the The <codec> element describes a codec. The element is modeled on the
<codec> element in the XCON conference information data model <codec> element in the XCON conference information data model
([I-D.ietf-xcon-common-data-model]) and allows addition information ([I-D.ietf-xcon-common-data-model]) and allows addition information
(e.g. rate, speed, etc) to be specified. (e.g. rate, speed, etc) to be specified.
The <codec> element has no attributes. The <codec> element has the following attributes:
name: indicates the type name of the codec's media format as defined
in IANA ([IANA]). A valid value is a "type-name" as defined in
Section 4.2 of [RFC4288]. The attribute is manadatory.
The <codec> element has the following sequence of child elements: The <codec> element has the following sequence of child elements:
<subtype>: element (Section 4.4.1.1) describing the codec's name. <subtype>: element whose content model describes the subtype of the
The element is mandatory. codec's media format as defined in IANA ([IANA]). A valid value
is a "subtype-name" as defined in Section 4.2 of [RFC4288]. The
element is mandatory.
<params>: element (Section 4.4.1.2) describing additional <params>: element (Section 4.5) describing additional information
information about the codec. This package is agnostic to the about the codec. This package is agnostic to the names and values
names and values of the codec parameters supported by an of the codec parameters supported by an implementation. The
implementation. The element is optional. element is optional.
For example, a fragment with a <codec> element describing the H263 For example, a fragment with a <codec> element describing the H263
codec: codec:
<codec> <codec name=video">
<subtype>H263</subtype> <subtype>H263</subtype>
</codec> </codec>
And a fragment where the <codec> element describes the H264 codec And a fragment where the <codec> element describes the H264 video
with additional information about the profile level and packetization codec with additional information about the profile level and
mode: packetization mode:
<codec> <codec name="video">
<subtype>H264</subtype> <subtype>H264</subtype>
<params> <params>
<param name="profile-level-id">42A01E</param> <param name="profile-level-id">42A01E</param>
<param name="packetization-mode">0</param> <param name="packetization-mode">0</param>
</params> </params>
</codec> </codec>
4.4.1.1. <subtype> 4.5. <params>
The <subtype> element specifies the name of a codec. The possible
names are the values of the 'subtype' column of the RTP Payload
Format media types per [RFC4855] defined in IANA ([IANA]).
The <subtype> element has no attributes and its content model is the
codec name.
4.4.1.2. <params>
The <params> element is a container for <param> elements The <params> element is a container for <param> elements
(Section 4.4.1.2.1). (Section 4.5.1).
The <params> element has no attributes, but the following child The <params> element has no attributes, but the following child
elements are defined (0 or more): elements are defined (0 or more):
<param>: specifies a parameter name and value (Section 4.4.1.2.1). <param>: specifies a parameter name and value (Section 4.5.1).
4.4.1.2.1. <param> 4.5.1. <param>
The <param> element describes a parameter name and value. The <param> element describes a parameter name and value.
The <param> element has the following attributes: The <param> element has the following attributes:
name: a string indicating the name of the parameter. The attribute name: a string indicating the name of the parameter. The attribute
is mandatory. is mandatory.
type: specifies a type indicating how the inline value of the type: specifies a type indicating how the inline value of the
parameter is to be interpreted. A valid value is a MIME media parameter is to be interpreted. A valid value is a MIME media
type (see Section 4.6.6). The attribute is optional. The default type (see Section 4.7.6). The attribute is optional. The default
value is "text/plain". value is "text/plain".
The <param> element content model (text and/or XML) is the value of encoding: specifies a content-transfer-encoding schema applied to
the parameter. Values in XML format MUST use a namespace other than the inline value of the parameter on top of the MIME media type
the one used in this specification. Note that a text value which specified with the type attribute. A valid value is a content-
contains XML characters (e.g. "<") needs to be escaped following transfer-encoding schema as defined by the "mechanism" token in
standard XML conventions. Section 6.1 of [RFC2045]. The attribute is optional. There is no
default value.
4.5. Response Status Codes The <param> element content model is the value of the parameter.
Note that a value which contains XML characters (e.g. "<") needs to
be escaped following standard XML conventions.
4.6. Response Status Codes
This section describes the response codes in Table 1 for the status This section describes the response codes in Table 1 for the status
attribute of mixer management <response> (Section 4.2.3) and audit attribute of mixer management <response> (Section 4.2.3) and audit
<auditresponse> (Section 4.3.2) responses. The MS MUST support the <auditresponse> (Section 4.3.2) responses. The MS MUST support the
status response codes defined here. All other valid but undefined status response codes defined here. All other valid but undefined
values are reserved for future use, where a standards-track RFC is values are reserved for future use, where new status codes are
required to define new status codes. The AS MUST treat any responses assigned using the Standards Action process defined in [RFC5226].
it does not recognize as being equivalent to the x00 response code The AS MUST treat any responses it does not recognize as being
for all classes. For example, if an AS receives an unrecognized equivalent to the x00 response code for all classes. For example, if
response code of 499, it can safely assume that there was something an AS receives an unrecognized response code of 499, it can safely
wrong with its request and treat the response as if it had received a assume that there was something wrong with its request and treat the
400 (Syntax error) response code. response as if it had received a 400 (Syntax error) response code.
4xx responses are definite failure responses from a particular MS. 4xx responses are definite failure responses from a particular MS.
The reason attribute in the response SHOULD identify the failure in The reason attribute in the response SHOULD identify the failure in
more detail, for example, "Mandatory attribute missing: id2 join more detail, for example, "Mandatory attribute missing: id2 join
element" for a 400 (Syntax error) response code. element" for a 400 (Syntax error) response code.
The AS SHOULD NOT retry the same request without modification (for The AS SHOULD NOT retry the same request without modification (for
example, correcting a syntax error or changing the conferenceid to example, correcting a syntax error or changing the conferenceid to
use one available on the MS). However, the same request to a use one available on the MS). However, the same request to a
different MS might be successful; for example, if another MS supports different MS might be successful; for example, if another MS supports
skipping to change at page 56, line 33 skipping to change at page 57, line 33
| | | not support | | | | | not support | |
| | | | | | | | | |
| 435 | Other | request requires | | | 435 | Other | request requires | |
| | unsupported | another capability | | | | unsupported | another capability | |
| | capability | not supported by the | | | | capability | not supported by the | |
| | | MS | | | | | MS | |
+-------+---------------+----------------------+--------------------+ +-------+---------------+----------------------+--------------------+
Table 1: status codes Table 1: status codes
4.6. Type Definitions 4.7. Type Definitions
This section defines types referenced in attribute definitions. This section defines types referenced in attribute definitions.
4.6.1. Boolean 4.7.1. Boolean
The value space of boolean is the set {true, false}. The value space of boolean is the set {true, false, 1, 0} as defined
in Section 3.2.2 of [XMLSchema:Part2]. In accordance with this
definition, the concept of false can be lexically represented by the
strings "0" and "false" and the concept of true by the strings "1"
and "true"; implementations MUST support both styles of lexical
representation.
4.6.2. Non-Negative Integer 4.7.2. Non-Negative Integer
The value space of non-negative integer is the infinite set The value space of non-negative integer is the infinite set
{0,1,2,...}. {0,1,2,...} as defined in Section 3.3.20 of [XMLSchema:Part2].
4.6.3. Positive Integer 4.7.3. Positive Integer
The value space of positive integer is the infinite set {1,2,...}. The value space of positive integer is the infinite set {1,2,...} as
defined in Section 3.3.25 of [XMLSchema:Part2].
4.6.4. String 4.7.4. String
A string in the character encoding associated with the XML element. A string in the character encoding associated with the XML element as
defined in Section 3.2.1 of [XMLSchema:Part2].
4.6.5. Time Designation 4.7.5. Time Designation
A time designation consists of a non-negative real number followed by A time designation consists of a non-negative real number followed by
a time unit identifier. a time unit identifier.
The time unit identifiers are: "ms" (milliseconds) and "s" (seconds). The time unit identifiers are: "ms" (milliseconds) and "s" (seconds).
Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s". Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s".
4.6.6. MIME Media Type 4.7.6. MIME Media Type
A string formatted as a IANA MIME media type ([MIME.mediatypes]). A string formated as an IANA MIME media type ([MIME.mediatypes]).
The ABNF ([RFC5234]) production for the string is:
type-name "/" subtype-name *(";" parameter-name)
where "type-name" and "subtype-name" are defined in Section 4.2, and
"parameter-name" in Section 4.3, of [RFC4288].
5. Formal Syntax 5. Formal Syntax
This section defines the XML schema for the Mixer Control Package. This section defines the XML schema for the Mixer Control Package.
The schema is normative.
The schema defines datatypes, attributes, and mixer elements in the The schema defines datatypes, attributes, and mixer elements in the
urn:ietf:params:xml:ns:msc-mixer namespace. In most elements the urn:ietf:params:xml:ns:msc-mixer namespace. In most elements the
order of child elements is significant. The schema is extensible: order of child elements is significant. The schema is extensible:
elements allow attributes and child elements from other namespaces. elements allow attributes and child elements from other namespaces.
Elements from outside this package's namespace can occur after Elements from outside this package's namespace can occur after
elements defined in this package. elements defined in this package.
The schema is dependent upon the schema (framework.xsd) defined in The schema is dependent upon the schema (framework.xsd) defined in
Section 16.1 of the Control Framework Section 16.1 of the Control Framework
skipping to change at page 58, line 30 skipping to change at page 59, line 31
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-mixer" <xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-mixer"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes" xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
elementFormDefault="qualified" elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:msc-mixer" xmlns="urn:ietf:params:xml:ns:msc-mixer"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
IETF MediaCtrl Mixer 1.0 (20100225) IETF MediaCtrl Mixer 1.0 (20101020)
This is the schema of the Mixer control package. It This is the schema of the Mixer control package. It
defines request, response and notification elements for defines request, response and notification elements for
mixing. mixing.
The schema namespace is urn:ietf:params:xml:ns:msc-mixer The schema namespace is urn:ietf:params:xml:ns:msc-mixer
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
skipping to change at page 67, line 47 skipping to change at page 68, line 49
<xsd:element name="volume" type="volumeType" /> <xsd:element name="volume" type="volumeType" />
<xsd:complexType name="clampType"> <xsd:complexType name="clampType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="tones" type="xsd:string" <xsd:attribute name="tones" type="xsd:string"
default="1 2 3 4 5 6 7 8 9 0 A B C D"/> default="1 2 3 4 5 6 7 8 9 0 * # A B C D"/>
</xsd:extension> </xsd:extension>
</xsd:complexContent>
</xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="clamp" type="clampType" /> <xsd:element name="clamp" type="clampType" />
<!-- region --> <!-- region -->
<xsd:simpleType name="regionType"> <xsd:simpleType name="regionType">
<xsd:restriction base="xsd:NMTOKEN" /> <xsd:restriction base="xsd:NMTOKEN" />
</xsd:simpleType> </xsd:simpleType>
<xsd:element name="region" type="regionType" /> <xsd:element name="region" type="regionType" />
skipping to change at page 68, line 46 skipping to change at page 69, line 47
</xsd:complexType> </xsd:complexType>
<xsd:element name="audio-mixing" type="audiomixingType" /> <xsd:element name="audio-mixing" type="audiomixingType" />
<!-- video-switch --> <!-- video-switch -->
<xsd:complexType name="videoswitchType"> <xsd:complexType name="videoswitchType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:any namespace="##other" minOccurs="0" <xsd:choice>
maxOccurs="unbounded" processContents="lax" /> <xsd:element name="vas" type="Tcore"/>
</xsd:sequence> <xsd:element name="controller" type="Tcore"/>
<xsd:attribute name="type" <xsd:any namespace="##other" processContents="lax" />
type="videoswitchtype.datatype" default="vas" />
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="interval" <xsd:attribute name="interval"
type="xsd:nonNegativeInteger" default="3" /> type="xsd:nonNegativeInteger" default="3" />
<xsd:attribute name="activespeakermix" <xsd:attribute name="activespeakermix"
type="boolean.datatype" default="false" /> type="xsd:boolean" default="false" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="video-switch" type="videoswitchType" /> <xsd:element name="video-switch" type="videoswitchType" />
<!-- video-layouts --> <!-- video-layouts -->
<xsd:complexType name="videolayoutsType"> <xsd:complexType name="videolayoutsType">
<xsd:complexContent> <xsd:complexContent>
skipping to change at page 69, line 33 skipping to change at page 70, line 35
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="video-layouts" type="videolayoutsType" /> <xsd:element name="video-layouts" type="videolayoutsType" />
<!-- video-layout --> <!-- video-layout -->
<!-- doesn't extend tCore since its content model is mixed --> <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:complexType name="videolayoutType" mixed="true"> <xsd:attribute name="min-participants"
<xsd:sequence> type="xsd:positiveInteger" default="1" />
<xsd:any namespace="##other" minOccurs="0" </xsd:extension>
maxOccurs="unbounded" processContents="lax" /> </xsd:complexContent>
</xsd:sequence>
<xsd:attribute name="min-participants"
type="xsd:positiveInteger" default="1" />
<xsd:anyAttribute namespace="##other" processContents="lax" />
</xsd:complexType> </xsd:complexType>
<xsd:element name="video-layout" type="videolayoutType" /> <xsd:element name="video-layout" type="videolayoutType" />
<xsd:complexType name="auditType"> <xsd:complexType name="auditType">
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="capabilities" <xsd:attribute name="capabilities"
type="boolean.datatype" default="true" /> type="xsd:boolean" default="true" />
<xsd:attribute name="mixers" type="boolean.datatype" <xsd:attribute name="mixers" type="xsd:boolean"
default="true" /> default="true" />
<xsd:attribute name="conferenceid" type="xsd:string" /> <xsd:attribute name="conferenceid" type="xsd:string" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="audit" type="auditType" /> <xsd:element name="audit" type="auditType" />
<xsd:complexType name="auditresponseType"> <xsd:complexType name="auditresponseType">
<xsd:complexContent> <xsd:complexContent>
skipping to change at page 73, line 36 skipping to change at page 74, line 49
<xsd:complexContent> <xsd:complexContent>
<xsd:extension base="Tcore"> <xsd:extension base="Tcore">
<xsd:sequence> <xsd:sequence>
<xsd:element ref="subtype" minOccurs="1" <xsd:element ref="subtype" minOccurs="1"
maxOccurs="1" /> maxOccurs="1" />
<xsd:element ref="params" minOccurs="0" <xsd:element ref="params" minOccurs="0"
maxOccurs="1" /> maxOccurs="1" />
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="name" type="xsd:string"
use="required" />
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="codec" type="codecType" /> <xsd:element name="codec" type="codecType" />
<!-- subtype --> <!-- subtype -->
<xsd:simpleType name="subtypeType"> <xsd:simpleType name="subtypeType">
<xsd:restriction base="xsd:string" /> <xsd:restriction base="xsd:string" />
skipping to change at page 74, line 21 skipping to change at page 75, line 36
<xsd:any namespace="##other" minOccurs="0" <xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" /> maxOccurs="unbounded" processContents="lax" />
</xsd:sequence> </xsd:sequence>
</xsd:extension> </xsd:extension>
</xsd:complexContent> </xsd:complexContent>
</xsd:complexType> </xsd:complexType>
<xsd:element name="params" type="paramsType" /> <xsd:element name="params" type="paramsType" />
<!-- param --> <!-- param -->
<!-- doesn't extend tCore since its content model is mixed --> <!-- doesn't extend tCore since its content model is mixed -->
<xsd:complexType name="paramType" mixed="true"> <xsd:complexType name="paramType" mixed="true">
<xsd:sequence> <xsd:sequence/>
<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" /> <xsd:attribute name="name" type="xsd:string" use="required" />
<xsd:attribute name="type" type="mime.datatype" <xsd:attribute name="type" type="mime.datatype"
default="text/plain" /> default="text/plain" />
<xsd:anyAttribute namespace="##other" processContents="lax" /> <xsd:attribute name="encoding" type="xsd:string"/>
</xsd:complexType> </xsd:complexType>
<xsd:element name="param" type="paramType" /> <xsd:element name="param" type="paramType" />
<!-- <!--
#################################################### ####################################################
DATATYPES DATATYPES
#################################################### ####################################################
--> -->
<xsd:simpleType name="version.datatype"> <xsd:simpleType name="version.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="1.0" /> <xsd:enumeration value="1.0" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
skipping to change at page 75, line 39 skipping to change at page 77, line 4
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="direction.datatype"> <xsd:simpleType name="direction.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="sendonly" /> <xsd:enumeration value="sendonly" />
<xsd:enumeration value="recvonly" /> <xsd:enumeration value="recvonly" />
<xsd:enumeration value="sendrecv" /> <xsd:enumeration value="sendrecv" />
<xsd:enumeration value="inactive" /> <xsd:enumeration value="inactive" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true" />
<xsd:enumeration value="false" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="mime.datatype"> <xsd:simpleType name="mime.datatype">
<xsd:restriction base="xsd:string" /> <xsd:restriction base="xsd:string" />
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="videoswitchtype.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="vas" />
<xsd:enumeration value="controller" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="volumecontroltype.datatype"> <xsd:simpleType name="volumecontroltype.datatype">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="automatic" /> <xsd:enumeration value="automatic" />
<xsd:enumeration value="setgain" /> <xsd:enumeration value="setgain" />
<xsd:enumeration value="setstate" /> <xsd:enumeration value="setstate" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
</xsd:schema> </xsd:schema>
skipping to change at page 80, line 20 skipping to change at page 81, line 20
If the MS can join the participant 9936067209:914cd14c to the If the MS can join the participant 9936067209:914cd14c to the
conference conf1 then it would send a successful response (not conference conf1 then it would send a successful response (not
shown). shown).
As the active talker changes, the MS sends an active talker As the active talker changes, the MS sends an active talker
notification to the AS: notification to the AS:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<event> <event>
<active-talker-notify conferenceid="conf1"> <active-talkers-notify conferenceid="conf1">
<active-talker connectionid="1536067209:913cd14c"/> <active-talker connectionid="1536067209:913cd14c"/>
</active-talker-notify> </active-talkers-notify>
</event> </event>
</mscmixer> </mscmixer>
The AS could decide to change the status of a talker connection so The AS could decide to change the status of a talker connection so
that they can only listen: that they can only listen:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="1536067209:913cd14c" id2="conf1"> <modifyjoin id1="1536067209:913cd14c" id2="conf1">
<stream media="audio" direction="recvonly"/> <stream media="audio" direction="recvonly"/>
</modifyjoin> </modifyjoin>
skipping to change at page 82, line 43 skipping to change at page 83, line 43
In this example, an audio video-conference is created with the In this example, an audio video-conference is created with the
loudest participant has the most prominent region in the video loudest participant has the most prominent region in the video
layout. layout.
The AS sends a request to create an audio-video conference: The AS sends a request to create an audio-video conference:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer"> <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference conferenceid="conf2"> <createconference conferenceid="conf2">
<audio-mixing type="nbest"/> <audio-mixing type="nbest"/>
<video-switch type="vas"/>
<video-layouts> <video-layouts>
<video-layout min-participants="1">single-view</video-layout> <video-layout min-participants="1"><single-view/></video-layout>
<video-layout min-participants="2">dual-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="3"><quad-view/></video-layout>
<video-layout min-participants="5">multiple-5x1</video-layout> <video-layout min-participants="5"><multiple-5x1/></video-layout>
</video-layouts> </video-layouts>
<video-switch><vas/></video-switch>
</createconference> </createconference>
</mscmixer> </mscmixer>
In this configuration, the conference uses a nbest audio mixing In this configuration, the conference uses a nbest audio mixing
policy and a vas video switch policy, so that the loudest speaker policy and a <vas/> video switch policy, so that the loudest speaker
receives the most prominent region in the layout. Multiple video receives the most prominent region in the layout. Multiple video
layouts are specified and active one depends on the number of layouts are specified and active one depends on the number of
participants. participants.
Assume that 4 participants are already joined to the conference. In Assume that 4 participants are already joined to the conference. In
that case, the video layout will be quad-view (Figure 6) with the that case, the video layout will be quad-view (Figure 6) with the
most active speaker displayed in region 1. When a fifth participant most active speaker displayed in region 1. When a fifth participant
joins, the video layout automatically switches to a multiple-5x1 joins, the video layout automatically switches to a multiple-5x1
layout (Figure 9), again with the most active speaker in region 1. layout (Figure 9), again with the most active speaker in region 1.
skipping to change at page 90, line 9 skipping to change at page 91, line 9
Person & email address to contact for further information: Scott Person & email address to contact for further information: Scott
McGlashan <smcg.stds01@mcglashan.org> McGlashan <smcg.stds01@mcglashan.org>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: None. Other information: None.
9. Change Summary 9. Change Summary
Note to RFC Editor: Please remove this whole section. Note to RFC Editor: Please remove this whole section.
The following are the changes between the -12 and -11 versions
(primarily addressing IESG DISCUSS, comments and nits):
o Introduction: Clarified that Control Framework is an equivalent
term for the Media Control Channel Framework.
o 4.2.4.2, 4.2.4.3, 4.5: Replaced reference to standards-tracks RFC
for assignment of new values, with reference to using Standards
Action process defined in RFC 5226.
o 4.0: Clarified that while some elements contain attributes whose
value is descriptive text, this descriptive text is for diagnostic
use only and does not require a language indicator such as a
language tag.
o 4.2.2.5.2: expanded DTMF acronym.
o 4.2.1.4.2.1: Changed <video-layout> so that the layout is a child
element rather than content value. Changed examples to match.
Updated XML schema.
o 4.2.1.4.3: Changed <video-switch> so that the policy is a child
element rather than content value. Changed examples to match.
Updated XML schema.
o 4.4.1: changed <codec> to include name attribute; aligned
definition with RFC4288; updated XML schema.
o 4.2.2.5: Clarified that the media attribute of <stream> is a MIME
type-name with reference to RFC 4288.
o 4.5.1: Added encoding attribute to <param> to allow for
specification of content-transfer-encoding schema. Updated XML
schema.
o 4.5.1: Simplified content model of <param> to be text only.
Updated XML schema.
o 4.6.6: Clarified MIME media type format with ABNF production
referencing RFC 4288.
o 4.2.2.5.3: clarified the definition of <region> as an area in a
video layout
o 5: Stated that the schema is normative.
o 5: Corrected default value of tones attribute in schema to match
definition in 4.2.2.5.2.
o 4.6: Type definitions; added references to XML Schema datatypes
where appropriate; changed definition of boolean to match W3C
definition and updated boolean type in schema.
o Typos: in 4.2.1.4.2.1, added '/' to <video-layout>; in 4.2.1.4.3
<video-switch>, replaced second <join> with <unjoin>; in 4.2.3,
corrected code and status in <response> examples;
o Validated all examples against XML schema and corrected where
necessary.
The following are the changes between the -11 and -10 versions The following are the changes between the -11 and -10 versions
(addressing IETF Last Call comments): (addressing IETF Last Call comments):
o 4.2.2.3: For <modifyjoin>, removed the statement "It MUST NOT o 4.2.2.3: For <modifyjoin>, removed the statement "It MUST NOT
change the configuration of any streams not included as child change the configuration of any streams not included as child
elements." since modifications in stream directionality can affect elements." since modifications in stream directionality can affect
other streams of the same type. other streams of the same type.
o 4.2.2.5.2: Changed definition of tones attribute of <clamp> o 4.2.2.5.2: Changed definition of tones attribute of <clamp>
element so that if the element is specified, then all DTMF tones element so that if the element is specified, then all DTMF tones
skipping to change at page 94, line 26 skipping to change at page 96, line 40
o Removed affliations in Contributors section. o Removed affliations in Contributors section.
The following are the major changes between the -02 and -01 versions. The following are the major changes between the -02 and -01 versions.
o Section 4: Aligned Control Package definitions with requirements o Section 4: Aligned Control Package definitions with requirements
in Section 8 of the Control Framework. in Section 8 of the Control Framework.
o Following October Interim meeting discussion on response codes, o Following October Interim meeting discussion on response codes,
generally clarified usage of error status codes, modified some generally clarified usage of error status codes, modified some
codes and re-organized the response codes section (Section 4.5) codes and re-organized the response codes section (Section 4.6)
with more guidance and details. with more guidance and details.
o MIXER-006. No action required following October 2008 interim o MIXER-006. No action required following October 2008 interim
discussion. discussion.
o MIXER-008. No action required following October 2008 interim o MIXER-008. No action required following October 2008 interim
discussion. discussion.
o MIXER-009. No action required for control package - addressed in o MIXER-009. No action required for control package - addressed in
-05 framework draft following interim October 2008 discussion. -05 framework draft following interim October 2008 discussion.
skipping to change at page 100, line 12 skipping to change at page 102, line 12
Shawn Emery carried out a thorough security review. Shawn Emery carried out a thorough security review.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-mediactrl-sip-control-framework] [I-D.ietf-mediactrl-sip-control-framework]
Boulton, C., Melanchuk, T., and S. McGlashan, "Media Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework", Control Channel Framework",
draft-ietf-mediactrl-sip-control-framework-11 (work in draft-ietf-mediactrl-sip-control-framework-12 (work in
progress), October 2009. progress), September 2010.
[I-D.ietf-xcon-common-data-model] [I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized "Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-18 Conferencing (XCON)", draft-ietf-xcon-common-data-model-20
(work in progress), February 2010. (work in progress), October 2010.
[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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. 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 [RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006. Protocol (SDP) Label Attribute", RFC 4574, August 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.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E., [XML] Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E.,
and F. Yergeau, "Extensible Markup Language (XML) 1.0 and F. Yergeau, "Extensible Markup Language (XML) 1.0
(Third Edition)", W3C Recommendation, February 2004. (Third Edition)", W3C Recommendation, February 2004.
[XMLSchema:Part2]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C Recommendation, October 2004.
12.2. Informative References 12.2. Informative References
[IANA] "IANA registry for RTP Payload Types", [IANA] "IANA registry for RTP Payload Types",
<http://www.iana.org/assignments/rtp-parameters>. <http://www.iana.org/assignments/rtp-parameters>.
[MIME.mediatypes] [MIME.mediatypes]
"IANA registry for MIME Media Types", "IANA registry for MIME Media Types",
<http://www.iana.org/assignments/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, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 5022, Control Markup Language (MSCML) and Protocol", RFC 5022,
September 2007. September 2007.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008. Requirements", RFC 5167, March 2008.
[RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup [RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup
Language (MSML)", RFC 5707, February 2010. Language (MSML)", RFC 5707, February 2010.
 End of changes. 148 change blocks. 
353 lines changed or deleted 463 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/