idnits 2.17.1 draft-ietf-mediactrl-mixer-control-package-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 19 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 839 has weird spacing: '...le-view layou...' == Line 852 has weird spacing: '...al-view layou...' == Line 867 has weird spacing: '...ew-crop layou...' == Line 902 has weird spacing: '...x1-crop layou...' == Line 923 has weird spacing: '...ad-view layou...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2010) is 5171 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-9' is mentioned on line 3299, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-mediactrl-sip-control-framework-11 == Outdated reference: A later version (-32) exists of draft-ietf-xcon-common-data-model-18 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. McGlashan 3 Internet-Draft Hewlett-Packard 4 Intended status: Standards Track T. Melanchuk 5 Expires: August 29, 2010 Rain Willow Communications 6 C. Boulton 7 NS-Technologies 8 February 25, 2010 10 A Mixer Control Package for the Media Control Channel Framework 11 draft-ietf-mediactrl-mixer-control-package-11 13 Abstract 15 This document defines a Media Control Channel Framework Package for 16 managing mixers for media conferences and connections. The package 17 defines request elements for managing conference mixers, managing 18 mixers between conferences and/or connections, as well as associated 19 responses and notifications. The package also defines elements for 20 auditing package capabilities and mixers. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on August 29, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 76 3. Control Package Definition . . . . . . . . . . . . . . . . . 7 77 3.1. Control Package Name . . . . . . . . . . . . . . . . . . 7 78 3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 7 79 3.3. Common XML Support . . . . . . . . . . . . . . . . . . . 8 80 3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . 8 81 3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 8 82 3.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 10 85 4.1. . . . . . . . . . . . . . . . . . . . . . . . 10 86 4.2. Mixer Elements . . . . . . . . . . . . . . . . . . . . . 11 87 4.2.1. Conference Elements . . . . . . . . . . . . . . . . . 12 88 4.2.1.1. . . . . . . . . . . . . . . . 12 89 4.2.1.2. . . . . . . . . . . . . . . . 15 90 4.2.1.3. . . . . . . . . . . . . . . . 16 91 4.2.1.4. Conference Configuration . . . . . . . . . . . . 17 92 4.2.1.4.1. . . . . . . . . . . . . . . . 17 93 4.2.1.4.2. . . . . . . . . . . . . . . . 17 94 4.2.1.4.2.1. . . . . . . . . . . . . . 19 95 4.2.1.4.3. . . . . . . . . . . . . . . . 24 96 4.2.1.4.3.1. Priority assignment . . . . . . . . . . . 26 97 4.2.1.4.4. . . . . . . . . . . . . . . . . . 27 98 4.2.1.4.4.1. . . . . . . . . . . 27 99 4.2.2. Joining Elements . . . . . . . . . . . . . . . . . . 27 100 4.2.2.1. Joining Model . . . . . . . . . . . . . . . . . . 27 101 4.2.2.2. . . . . . . . . . . . . . . . . . . . . . 29 102 4.2.2.3. . . . . . . . . . . . . . . . . . . 31 103 4.2.2.4. . . . . . . . . . . . . . . . . . . . . 33 104 4.2.2.5. . . . . . . . . . . . . . . . . . . . . 35 105 4.2.2.5.1. . . . . . . . . . . . . . . . . . . 36 106 4.2.2.5.2. . . . . . . . . . . . . . . . . . . . 37 107 4.2.2.5.3. . . . . . . . . . . . . . . . . . . 37 108 4.2.2.5.4. . . . . . . . . . . . . . . . . . 37 109 4.2.3. . . . . . . . . . . . . . . . . . . . . . 38 110 4.2.4. . . . . . . . . . . . . . . . . . . . . . . . 38 111 4.2.4.1. . . . . . . . . . . . . . 39 112 4.2.4.1.1. . . . . . . . . . . . . . . . 39 113 4.2.4.2. . . . . . . . . . . . . . . . . . 40 114 4.2.4.3. . . . . . . . . . . . . . . . . 40 115 4.3. Audit Elements . . . . . . . . . . . . . . . . . . . . . 42 116 4.3.1. . . . . . . . . . . . . . . . . . . . . . . . 42 117 4.3.2. . . . . . . . . . . . . . . . . . . . 43 118 4.3.2.1. . . . . . . . . . . . . . . . . . 45 119 4.3.2.2. . . . . . . . . . . . . . . . . . . . . 46 120 4.3.2.2.1. . . . . . . . . . . . . . . 46 121 4.3.2.2.1.1. . . . . . . . . . . . . . 47 122 4.3.2.2.1.1.1. . . . . . . . . . . . . 47 123 4.3.2.2.2. . . . . . . . . . . . . . . . . . 48 124 4.4. . . . . . . . . . . . . . . . . . . . . . . . . 48 125 4.4.1. . . . . . . . . . . . . . . . . . . . . . . . 49 126 4.4.1.1. . . . . . . . . . . . . . . . . . . . . 50 127 4.4.1.2. . . . . . . . . . . . . . . . . . . . . 50 128 4.4.1.2.1. . . . . . . . . . . . . . . . . . . . 50 129 4.5. Response Status Codes . . . . . . . . . . . . . . . . . . 51 130 4.6. Type Definitions . . . . . . . . . . . . . . . . . . . . 55 131 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 57 132 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 76 133 6.1. AS-MS Framework Interaction Examples . . . . . . . . . . 76 134 6.1.1. Creating a conference mixer and joining a 135 participant . . . . . . . . . . . . . . . . . . . . . 76 136 6.1.2. Receiving active talker notifications . . . . . . . . 77 137 6.1.3. Conference termination . . . . . . . . . . . . . . . 77 138 6.2. Mixing Examples . . . . . . . . . . . . . . . . . . . . . 77 139 6.2.1. Audio conferencing . . . . . . . . . . . . . . . . . 78 140 6.2.2. Bridging connections . . . . . . . . . . . . . . . . 80 141 6.2.3. Video conferencing . . . . . . . . . . . . . . . . . 81 142 7. Security Considerations . . . . . . . . . . . . . . . . . . . 83 143 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 144 8.1. Control Package Registration . . . . . . . . . . . . . . 86 145 8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 86 146 8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 87 147 8.4. MIME Media Type Registration for 148 'application/msc-mixer+xml' . . . . . . . . . . . . . . . 87 149 9. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 89 150 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 97 151 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 98 152 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 99 153 12.1. Normative References . . . . . . . . . . . . . . . . . . 99 154 12.2. Informative References . . . . . . . . . . . . . . . . . 99 155 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101 157 1. Introduction 159 The Media Control Channel Framework 160 [I-D.ietf-mediactrl-sip-control-framework] provides a generic 161 approach for establishment and reporting capabilities of remotely 162 initiated commands. The Framework utilizes many functions provided 163 by the Session Initiation Protocol [RFC3261] (SIP) for the rendezvous 164 and establishment of a reliable channel for control interactions. 165 The Control Framework also introduces the concept of a Control 166 Package. A Control Package is an explicit usage of the Control 167 Framework for a particular interaction set. This specification 168 defines a package for media conference mixers and media connection 169 mixers. 171 This package defines mixer management elements for creating, 172 modifying and deleting conference mixers, elements for joining, 173 modifying and unjoining media streams between connections and 174 conferences (including mixers between connections), as well as 175 associated responses and notifications. The package also defines 176 elements for auditing package capabilities and mixers. 178 This package has been designed to satisfy media mixing requirements 179 documented in the Media Server Control Protocol Requirements document 180 ([RFC5167]); more specifically REQ-MCP-22, REQ-MCP-23, REQ-MCP-24, 181 REQ-MCP-25, REQ-MCP-26 and REQ-MCP-27. 183 The package provides the major conferencing functionality of SIP 184 Media Server languages such as MSCML ([RFC5022]) and MSML 185 ([RFC5707]). A key differentiator is that this package provides such 186 functionality using the Media Control Channel Framework. 188 Out of scope for this mixer package are more advanced functions 189 including personalized video mixes for conference participants, 190 support for floor control protocols, as well as support for video 191 overlays and text insertion. Such functionality can be addressed by 192 extensions to this package (through addition of foreign elements or 193 attributes from another namespace) or use of other control packages 194 which could build upon this package. 196 The functionality of this package is defined by messages, containing 197 XML [XML] elements, transported using the Media Control Channel 198 Framework. The XML elements can be divided into two types: mixer 199 management elements; and elements for auditing package capabilities 200 as well as mixers managed by the package. 202 The document is organized as follows. Section 3 describes how this 203 control package fulfills the requirements for a Media Control Channel 204 Framework control package. Section 4 describes the syntax and 205 semantics of defined elements, including mixer management 206 (Section 4.2) and audit elements (Section 4.3). Section 5 describes 207 an XML schema for these elements and provides extensibility by 208 allowing attributes and elements from other namespaces. Section 6 209 provides examples of package usage. Section 7 describes important 210 security considerations for use of this control package. Section 8 211 provides information on IANA registration of this control package, 212 including its name, XML namespace and MIME media type. 214 2. Conventions and Terminology 216 In this document, BCP 14/RFC 2119 [RFC2119] defines the key words 217 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 218 "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 219 "OPTIONAL". In addition, BCP 15 indicates requirement levels for 220 compliant implementations. 222 The following additional terms are defined for use in this document: 224 Application server: A SIP [RFC3261] application server (AS) is a 225 control client that hosts and executes services such as 226 interactive media and conferencing in an operator's network. An 227 AS controls the media server (MS), influencing and impacting the 228 SIP sessions terminating on a media server, which the AS can have 229 established for example using SIP third party call control. 231 Media Server: A media server (MS) processes media streams on behalf 232 of an AS by offering functionality such as interactive media, 233 conferencing, and transcoding to the end user. Interactive media 234 functionality is realized by way of dialogs, which are identified 235 by a URI and initiated by the application server. 237 MS Conference: A MS Conference provides the media related mixing 238 resources and services for conferences. In this document, A MS 239 Conference is often referred to simply as a conference. 241 MS Connection: A Media Server connection represents the termination 242 on a media server of one or more RTP [RFC3550] sessions that are 243 associated to a single SIP dialog. A media server receives media 244 from the output(s) of a connection and it transmits media on the 245 input(s) of a connection. 247 Media Stream: A media stream on a media server represents a media 248 flow between either a connection and a conference, between two 249 connections, or between two conferences. Streams can be audio or 250 video and can be bi-directional or uni-directional. 252 3. Control Package Definition 254 This section fulfills the mandatory requirement for information that 255 MUST be specified during the definition of a Control Framework 256 Package, as detailed in Section 8 of 257 [I-D.ietf-mediactrl-sip-control-framework]. 259 3.1. Control Package Name 261 The Control Framework requires a Control Package definition to 262 specify and register a unique name. The name and version of this 263 Control Package is "msc-mixer/1.0" (Media Server Control - Mixer - 264 version 1.0). Its IANA registration is specified in Section 8.1. 266 Since this is the initial ("1.0") version of the control package, 267 there are no backwards compatibility issues to address. 269 3.2. Framework Message Usage 271 The Control Framework requires a Control Package to explicitly detail 272 the control messages that can be used as well as provide an 273 indication of directionality between entities. This will include 274 which role type is allowed to initiate a request type. 276 This package specifies CONTROL and response messages in terms of XML 277 elements defined in Section 4, where the message bodies have the MIME 278 media type defined in Section 8.4. These elements describe requests, 279 response and notifications and all are contained within a root 280 element (Section 4.1). 282 In this package, the MS operates as a Control Server in receiving 283 requests from, and sending responses to, the AS (operating as Control 284 Client). Mixer management requests and responses are defined in 285 Section 4.2. Audit requests and responses are defined in 286 Section 4.3. Mixer management and audit responses are carried in a 287 framework 200 response or REPORT message bodies. This package's 288 response codes are defined in Section 4.5. 290 Note that package responses are different from framework response 291 codes. Framework error response codes (see Section 8 of 292 [I-D.ietf-mediactrl-sip-control-framework]) are used when the request 293 or event notification is invalid; for example, a request is invalid 294 XML (400), or not understood (500). 296 The MS also operates as a Control Client in sending event 297 notification to the AS (Control Server). Event notifications 298 (Section 4.2.4) are carried in CONTROL message bodies. The AS MUST 299 respond with a Control Framework 200 response. 301 3.3. Common XML Support 303 The Control Framework requires a Control Package definition to 304 specify if the attributes for media dialog or conference references 305 are required. 307 This package requires that the XML Schema in Section 16.1 of 308 [I-D.ietf-mediactrl-sip-control-framework] MUST be supported for 309 media dialogs and conferences. 311 The package uses "connectionid" and "conferenceid" attributes for 312 various element definitions (Section 4). The XML schema (Section 5) 313 imports the definitions of these attributes from the framework 314 schema. 316 3.4. CONTROL Message Body 318 The Control Framework requires a Control Package to define the 319 control body that can be contained within a CONTROL command request 320 and to indicate the location of detailed syntax definitions and 321 semantics for the appropriate body types. 323 When operating as Control Server, the MS receives CONTROL messages 324 with the MIME media type defined in Section 8.4 and a body containing 325 a element (Section 4.1) with either a mixer management or 326 audit request child element. 328 The following mixer management request elements are carried in 329 CONTROL message bodies to MS: (Section 4.2.1.1), 330 (Section 4.2.1.2), 331 (Section 4.2.1.3), (Section 4.2.2.2), 332 (Section 4.2.2.3) and (Section 4.2.2.4) elements. 334 The request element (Section 4.3.1) is also carried in 335 CONTROL message bodies. 337 When operating as Control Client, the MS sends CONTROL messages with 338 the MIME media type defined in Section 8.4 and a body containing a 339 element (Section 4.1) with a notification child 340 element (Section 4.2.4). 342 3.5. REPORT Message Body 344 The Control Framework requires a control package definition to define 345 the REPORT body that can be contained within a REPORT command 346 request, or that no report package body is required. This section 347 indicates the location of detailed syntax definitions and semantics 348 for the appropriate body types. 350 When operating as Control Server, the MS sends REPORT bodies with the 351 MIME media type defined in Section 8.4 and a element with 352 a response child element. The response element for mixer management 353 requests is a element (Section 4.2.3). The response 354 element for an audit request is a element 355 (Section 4.3.2). 357 3.6. Audit 359 The Control Framework encourages Control Packages to specify whether 360 auditing is available, how it is triggered as well as the query/ 361 response formats. 363 This Control Packages supports auditing of package capabilities and 364 mixers on the MS. An audit request is carried in a CONTROL message 365 and an audit response in a REPORT message (or a 200 response to the 366 CONTROL if it can execute the audit in time). 368 The syntax and semantics of audit request and response elements is 369 defined in Section 4.3. 371 3.7. Examples 373 The Control Framework recommends Control Packages to provide a range 374 of message flows that represent common flows using the package and 375 this framework document. 377 This Control Package provides examples of such message flows in 378 Section 6. 380 4. Element Definitions 382 This section defines the XML elements for this package. The elements 383 are defined in the XML namespace specified in Section 8.2. 385 The root element is (Section 4.1). All other XML elements 386 (requests, responses and notification elements) are contained within 387 it. Child elements describe mixer management (Section 4.2) and audit 388 (Section 4.3) functionality. Response status codes are defined in 389 Section 4.5 and type definitions in Section 4.6. 391 Implementation of this control package MUST address the Security 392 Considerations described in Section 7. 394 Implementation of this control package MUST adhere to the syntax and 395 semantics of XML elements defined in this section and the schema 396 (Section 5). The XML schema supports extensibility by allowing 397 attributes and elements from other namespaces. Implementations MAY 398 support attributes and elements from other (foreign) namespaces. If 399 an MS implementation receives a element containing 400 attributes or elements from another namespace which it does not 401 support, the MS sends a 428 response (Section 4.5). 403 Extensible attributes and elements are not described in this section. 404 In all other cases where there is a difference in constraints between 405 the XML schema and the textual description of elements in this 406 section, the textual definition takes priority. 408 Usage examples are provided in Section 6. 410 4.1. 412 The element has the following attributes (in addition to 413 standard XML namespace attributes such as xmlns): 415 version: a string specifying the mscmixer package version. The 416 value is fixed as '1.0' for this version of the package. The 417 attribute is mandatory. 419 The element has the following defined child elements, only 420 one of which can occur: 422 1. mixer management elements defined in Section 4.2: 424 create and configure a new conference mixer. 425 See Section 4.2.1.1 427 modify the configuration of an existing 428 conference mixer. See Section 4.2.1.2 430 destroy an existing conference mixer. See 431 Section 4.2.1.3 433 create and configure media streams between connections 434 and/or conferences (for example, add a participant to a 435 conference). See Section 4.2.2.2 437 modify the configuration of joined media streams. 438 See Section 4.2.2.3 440 delete a media stream (for example, remove a 441 participant from a conference). See Section 4.2.2.4 443 response to a mixer request. See Section 4.2.3 445 mixer or subscription notification. See Section 4.2.4 447 2. audit elements defined in Section 4.3: 449 audit package capabilities and managed mixers. See 450 Section 4.3.1 452 response to an audit request. See Section 4.3.2 454 For example, a request to the MS to create a conference mixer: 456 457 458 460 and a response from the MS that the conference was successfully 461 created: 463 464 465 467 4.2. Mixer Elements 469 This section defines the mixer management XML elements for this 470 control package. These elements are divided into requests, responses 471 and notifications. 473 Request elements are sent to the MS to request a specific mixer 474 operation to be executed. The following request elements are 475 defined: 477 create and configure a new a conference mixer. 478 See Section 4.2.1.1 480 modify the configuration of an existing 481 conference mixer. See Section 4.2.1.2 483 destroy an existing conference mixer. See 484 Section 4.2.1.3 486 create and configure media streams between connections and/or 487 conferences (for example, add a participant to a conference). See 488 Section 4.2.2.2 490 modify the configuration of joined media streams. See 491 Section 4.2.2.3 493 delete a media stream (for example, remove a participant 494 from a conference). See Section 4.2.2.4 496 Responses from the MS describe the status of the requested operation. 497 Responses are specified in a element (Section 4.2.3) which 498 includes a mandatory attribute describing the status in terms of a 499 numeric code. Response status codes are defined in Section 4.5. The 500 MS MUST respond to a request message with a response message. If the 501 MS is not able to process the request and carry out the mixer 502 operation (in whole or in part), then the request has failed: the MS 503 MUST ensure that no part of the requested mixer operation is carried 504 out, and the MS MUST indicate the class of failure using an 505 appropriate 4xx response code. Unless an error response code is 506 specified for a class of error within this section, implementations 507 follow Section 4.5 in determining the appropriate status code for the 508 response. 510 Notifications are sent from the MS to provide updates on the status 511 of a mixer operation or subscription. Notifications are specified in 512 an element (Section 4.2.4). 514 4.2.1. Conference Elements 516 4.2.1.1. 518 The element is sent to the MS to request creation 519 of a new conference (multiparty) mixer. 521 The element has the following attributes: 523 conferenceid: string indicating a unique name for the new 524 conference. If this attribute is not specified, the MS MUST 525 create a unique name for the conference. The value is used in 526 subsequent references to the conference (e.g. as conferenceid in a 527 ). The attribute is optional. There is no default 528 value. 530 reserved-talkers: indicates the requested number of guaranteed 531 speaker slots to be reserved for the conference. A valid value is 532 a non-negative integer (see Section 4.6.2). The attribute is 533 optional. The default value is 0. 535 reserved-listeners: indicates the requested number of guaranteed 536 listener slots to be reserved for the conference. A valid value 537 is a non-negative integer (see Section 4.6.2). The attribute is 538 optional. The default value is 0. 540 The element has the following sequence of child 541 elements: 543 : an element to configure the codecs supported by the 544 conference (see Section 4.4). If codecs are specified, then they 545 impose limitations in media capability when the MS attempts to 546 join the conference to other entities (see Section 4.2.2.2 and 547 Section 4.2.2.3). The element is optional. 549 : an element to configure the audio mixing 550 characteristics of a conference (see Section 4.2.1.4.1). The 551 element is optional. 553 : an element to configure the video layouts of a 554 conference (see Section 4.2.1.4.2). The element is optional. 556 : an element to configure the video switch policy for 557 the layout of a conference (see Section 4.2.1.4.3). The element 558 is optional. 560 : an element to request subscription to conference 561 events. (see Section 4.2.1.4.4). The element is optional. 563 If the conferenceid attribute specifies a value which is already used 564 by an existing conference, the MS reports an error (405) and MUST NOT 565 create a new conference and MUST NOT affect the existing conference. 567 If the MS is unable to configure the conference according to 568 specified reserved-talkers or reserved-listeners attributes, the MS 569 reports an error (420) and MUST NOT create the conference. 571 If the MS is unable to configure the conference according to a 572 specified element, the MS reports an error (421) and 573 MUST NOT create the conference. 575 If the MS is unable to configure the conference according to a 576 specified element, the MS reports an error (423) and 577 MUST NOT create the conference. 579 If the MS is unable to configure the conference according to a 580 specified element, the MS reports an error (424) and 581 MUST NOT create the conference. 583 If the MS is unable to configure the conference according to a 584 specified element, the MS reports an error (425) and MUST 585 NOT create the conference. 587 When a MS has finished processing a request, it 588 MUST reply with an appropriate element (Section 4.2.3). 590 For example, a request to create an audio video conference mixer with 591 specified codecs, video layout, video switch and subscription: 593 594 596 597 598 H264 599 600 601 PCMA 602 603 604 605 606 single-view 607 dual-view 608 quad-view 609 610 611 612 613 614 615 617 and a response from the MS if the conference was successfully 618 created: 620 621 622 624 alternatively, a response if MS could not create the conference due 625 to a lack of support for the H264 codec: 627 628 630 632 4.2.1.2. 634 The element is sent to the MS to request 635 modification of an existing conference. 637 The element has the following attributes: 639 conferenceid: string indicating the name of the conference to 640 modify. This attribute is mandatory. 642 The element has the following sequence of child 643 elements (1 or more): 645 : an element to configure the codecs supported by the 646 conference (see Section 4.4). If codecs are specified, then they 647 impose limitations in media capability when the MS attempts to 648 join the conference to other entities (see Section 4.2.2.2 and 649 Section 4.2.2.3). Existing conference participants are unaffected 650 by any policy change. The element is optional. 652 : an element to configure the audio mixing 653 characteristics of a conference (see Section 4.2.1.4.1). The 654 element is optional. 656 : an element to configure the video layouts of a 657 conference (see Section 4.2.1.4.2). The element is optional. 659 : an element to configure the video switch policy for 660 the layout of a conference (see Section 4.2.1.4.3). The element 661 is optional. 663 : an element to request subscription to conference 664 events. (see Section 4.2.1.4.4). The element is optional. 666 If the conferenceid attribute specifies the name of a conference 667 which does not exist, the MS reports an error (406). 669 If the MS is unable to configure the conference according to a 670 specified element, the MS reports an error (421) and 671 MUST NOT modify the conference in any way. 673 If the MS is unable to configure the conference according to a 674 specified element, the MS reports an error (423) and 675 MUST NOT modify the conference in any way. 677 If the MS is unable to configure the conference according to a 678 specified element, the MS reports an error (424) and 679 MUST NOT modify the conference in any way. 681 If the MS is unable to configure the conference according to a 682 specified element, the MS reports an error (425) and MUST 683 NOT modify the conference. 685 When a MS has finished processing a request, it 686 MUST reply with an appropriate element (Section 4.2.3). 688 4.2.1.3. 690 The element is sent to the MS to request 691 destruction of an existing conference. 693 The element has the following attributes: 695 conferenceid: string indicating the name of the conference to 696 destroy. This attribute is mandatory. 698 The element does not specify any child elements. 700 If the conferenceid attribute specifies the name of a conference 701 which does not exist, the MS reports an error (406). 703 When a MS has finished processing a request, it 704 MUST reply with an appropriate element (Section 4.2.3). 706 Successfully destroying the conference (status code 200) will result 707 in all connection or conference participants being removed from the 708 conference mixer, notification events 709 (Section 4.2.4.2) being sent for each conference participant and a 710 notification event (Section 4.2.4.3) indicating that 711 conference has exited. A with any other status code 712 indicates that the conference mixer still exists and participants are 713 still joined to the mixer. 715 4.2.1.4. Conference Configuration 717 The elements in this section are used to establish and modify the 718 configuration of conferences. 720 4.2.1.4.1. 722 The element defines the configuration of the 723 conference audio mix. 725 The element has the following attributes: 727 type: is a string indicating the audio stream mixing policy. 728 Defined values are: "nbest" (where the N best (loudest) 729 participant signals are mixed) and "controller" (where the 730 contributing participant(s) is/are selected by the controlling AS 731 via an external floor control protocol). The attribute is 732 optional. The default value is "nbest". 734 n: indicates the number of eligible participants included in the 735 conference audio mix. An eligible participant is a participant 736 who contributes audio to the conference. Inclusion is based on 737 having the greatest audio energy. A valid value is a non-negative 738 integer (see Section 4.6.2). A value of 0 indicates that all 739 participants contributing audio to the conference are included in 740 the audio mix. The default value is 0. The element is optional. 742 If the type attribute does not have the value "nbest", the MS ignores 743 the "n" attribute. 745 The element has no child elements. 747 For example, a fragment where the audio mixing policy is set to 748 "nbest" with 3 participants to be included: 750 752 If the conference had 200 participants of whom 30 contributed audio, 753 then there would be 30 eligible participants for the audio mix. Of 754 these, the 3 loudest participants would have their audio included in 755 the conference. 757 4.2.1.4.2. 759 The element describe the video presentation layout 760 configuration for participants providing a video input stream to the 761 conference. This element allows multiple video layouts to be 762 specified so that the MS automatically changes layout depending on 763 the number of video-enabled participants. 765 The element has no attributes. 767 The element has the following sequence of child 768 elements (1 or more): 770 : element describing a video layout 771 (Section 4.2.1.4.2.1). 773 If the MS does not support video conferencing at all, or does not 774 support multiple video layouts, or does not support a specific video 775 layout, the MS reports an 423 error in the response to the request 776 element containing the element. 778 An MS MAY support more than one element, although only 779 one layout can be active at a time. A is active if 780 the number of participants in the conference is equal to or greater 781 than the value of its "min-participants" attribute, but less than the 782 value of the "min-participants" attribute for any other element. An MS reports an error (400) if more than one 784 has the same value for the "min-participants" 785 attribute. When the number of regions within the active layout is 786 greater than the number of participants in the conference, the 787 display of unassigned regions is implementation-specific. 789 The assignment of participant video streams to regions within the 790 layout is according to the video switch policy specified by the 791 element (Section 4.2.1.4.3). 793 For example, a fragment describing a single layout: 795 796 single-view 797 799 And a fragment describing a sequence of layouts: 801 802 single-view 803 dual-view 804 quad-view 805 multiple-3x3 806 808 When the conference has one participant providing a video input 809 stream to the conference, then the single-view format is used. When 810 the conference has two such participants, the dual-view layout is 811 used. When the conference has three or four participants, the quad- 812 view layout is used. When the conference has five or more 813 participants, the multiple-3x3 layout is used. 815 4.2.1.4.2.1. 817 The element describes a video layout containing one or 818 more regions in which participant video input streams are displayed. 820 The element has the following attributes: 822 min-participants: the minimum number of conference participants 823 needed to allow this layout to be active. A valid value is a 824 positive integer (see Section 4.6.3). The attribute is optional. 825 The default value is 1. 827 The element has a content model specifying the name of 828 the video layout. 830 An MS MAY support the predefined video layouts defined in the XCON 831 conference information data model 832 ([I-D.ietf-xcon-common-data-model]). The MS MAY support other video 833 layouts. Non-XCON layouts MUST be prefixed with a label; for 834 example, mylayout:single-view. 836 Each video layout has associated with it one or more regions. The 837 XCON layouts are associated with the following named regions: 839 single-view layout with one stream in a single region as shown in 840 Figure 1. 842 +-----------+ 843 | | 844 | | 845 | 1 | 846 | | 847 | | 848 +-----------+ 850 Figure 1: single-view video layout 852 dual-view layout presenting two streams side-by-side in two regions 853 as shown in Figure 2. The MS MUST NOT alter the aspect ratio of 854 each stream to fit the region and hence the MS might need to blank 855 out part of each region. 857 +-----------+-----------+ 858 | | | 859 | | | 860 | 1 | 2 | 861 | | | 862 | | | 863 +-----------+-----------+ 865 Figure 2: dual-view video layout 867 dual-view-crop layout presenting two streams side-by-side in two 868 regions as shown in Figure 3. The MS MUST alter the aspect ratio 869 of each stream to fit its region so that no blanking is required. 871 +-----------+-----------+ 872 | | | 873 | | | 874 | 1 | 2 | 875 | | | 876 | | | 877 +-----------+-----------+ 879 Figure 3: dual-view-crop video layout 881 dual-view-2x1 layout presenting two streams one above the other in 882 two regions as shown in Figure 4. The MS MUST NOT alter the 883 aspect ratio of each stream to fit its region and hence the MS 884 might need to blank out part of each region. 886 +-----------+ 887 | | 888 | | 889 | 1 | 890 | | 891 | | 892 +-----------+ 893 | | 894 | | 895 | 2 | 896 | | 897 | | 898 +-----------+ 900 Figure 4: dual-view-2x1 video layout 902 dual-view-2x1-crop layout presenting two streams one above the other 903 in two regions as shown in Figure 5. The MS MUST alter the aspect 904 ratio of each stream to fit its region so that no blanking is 905 required. 907 +-----------+ 908 | | 909 | | 910 | 1 | 911 | | 912 | | 913 +-----------+ 914 | | 915 | | 916 | 2 | 917 | | 918 | | 919 +-----------+ 921 Figure 5: dual-view-2x1-crop video layout 923 quad-view layout presenting four equal-sized regions in a 2x2 layout 924 as shown in Figure 6. Typically the aspect ratio of the streams 925 is preserved, so blanking is required. 927 +-----------+-----------+ 928 | | | 929 | | | 930 | 1 | 2 | 931 | | | 932 | | | 933 +-----------+-----------+ 934 | | | 935 | | | 936 | 3 | 4 | 937 | | | 938 | | | 939 +-----------+-----------+ 941 Figure 6: quad-view video layout 943 multiple-3x3 layout presenting nine equal-sized regions in a 3x3 944 layout as shown in Figure 7. Typically the aspect ratio of the 945 streams is preserved, so blanking is required. 947 +-----------+-----------+-----------+ 948 | | | | 949 | | | | 950 | 1 | 2 | 3 | 951 | | | | 952 | | | | 953 +-----------+-----------+-----------+ 954 | | | | 955 | | | | 956 | 4 | 5 | 6 | 957 | | | | 958 | | | | 959 +-----------+-----------+-----------+ 960 | | | | 961 | | | | 962 | 7 | 8 | 9 | 963 | | | | 964 | | | | 965 +-----------+-----------+-----------+ 967 Figure 7: multiple-3x3 video layout 969 multiple-4x4 layout presenting sixteen equal-sized regions in a 4x4 970 layout as shown in Figure 8. Typically the aspect ratio of the 971 streams is preserved, so blanking is required. 973 +-----------+-----------+-----------+-----------+ 974 | | | | | 975 | | | | | 976 | 1 | 2 | 3 | 4 | 977 | | | | | 978 | | | | | 979 +-----------+-----------+-----------+-----------+ 980 | | | | | 981 | | | | | 982 | 5 | 6 | 7 | 8 | 983 | | | | | 984 | | | | | 985 +-----------+-----------+-----------+-----------+ 986 | | | | | 987 | | | | | 988 | 9 | 10 | 11 | 12 | 989 | | | | | 990 | | | | | 991 +-----------+-----------+-----------+-----------+ 992 | | | | | 993 | | | | | 994 | 13 | 14 | 15 | 16 | 995 | | | | | 996 | | | | | 997 +-----------+-----------+-----------+-----------+ 999 Figure 8: multiple-4x4 video layout 1001 multiple-5x1 layout presents a 5x1 layout as shown in Figure 9 where 1002 one region will occupy 4/9 of the mixed video stream while the 1003 others will each occupy 1/9 of the stream. Typically the aspect 1004 ratio of the streams is preserved, so blanking is required. 1006 +-----------------------+-----------+ 1007 | | | 1008 | | | 1009 | | 2 | 1010 | | | 1011 | | | 1012 | 1 +-----------+ 1013 | | | 1014 | | | 1015 | | 3 | 1016 | | | 1017 | | | 1018 +-----------+-----------+-----------+ 1019 | | | | 1020 | | | | 1021 | 4 | 5 | 6 | 1022 | | | | 1023 | | | | 1024 +-----------+-----------+-----------+ 1026 Figure 9: multiple-5x1 video layout 1028 4.2.1.4.3. 1030 The element describe the configuration of the 1031 conference policy for how participant's input video streams are 1032 assigned to regions within the active video layout. 1034 The element has the following attributes: 1036 type: a string indicating the video switching policy of the 1037 conference. Defined values are: 1039 vas (Voice Activated Switching) enables automatic display of the 1040 loudest speaker participant also providing a video input stream 1041 to the conference. Participants who do not provide an audio 1042 stream are not considered for automatic display. If a 1043 participant provides more than one audio stream, then the 1044 policy for inclusion of such a participant in the VAS is 1045 implementation-specific; an MS could select one stream, sum 1046 audio streams or ignore the participant for VAS consideration. 1047 If there is only one region in the layout, then the loudest 1048 speaker is displayed there. If more than one region is 1049 available, then the loudest speaker is displayed in the largest 1050 region, if any, and then in the first region from the top-left 1051 corner of the layout. The MS assigns the remaining regions 1052 based on the priority mechanism described in 1053 Section 4.2.1.4.3.1. 1055 controller enables manual control over video switching. The 1056 controller AS determines how the regions are assigned based on 1057 an external floor control policy. The MS receives , 1058 and commands with a element 1059 (Section 4.2.2.5) indicating the region where the stream is 1060 displayed. If no explicit region is specified, the MS assigns 1061 the region based on the priority mechanism described in 1062 Section 4.2.1.4.3.1. 1064 An MS MAY support other video switching policies. Other policy 1065 names MUST be prefixed with a label; e.g. "mypolicies:policy1". 1066 The attribute is optional. The default value is 'vas'. 1068 interval: specifies the period between video switches as a number of 1069 seconds. In the case of 'vas' policy, a speaker needs to be the 1070 loudest speaker for the interval before the switch takes place. A 1071 valid value is a non-negative integer (see Section 4.6.2). A 1072 value of 0 indicates that switching is applied immediately. The 1073 attribute is optional. The default value is 3 (seconds). 1075 activespeakermix: indicates whether or not the active (loudest) 1076 speaker participant receives a video stream without themselves 1077 displayed in the case of the 'vas' switching policy. If enabled, 1078 the MS needs to generate two video streams for each conference 1079 mix: one for the active speaker participant without themselves 1080 displayed - details of this video layout are implementation- 1081 specific; and one for other participants as described in the 'vas' 1082 switch policy above. A valid value is a boolean (see 1083 Section 4.6.1). A value of true indicates that a separate video 1084 mix is generated for the active speaker without themselves being 1085 displayed. A value of false indicates that all participants 1086 receive the same video mix. The attribute is optional. The 1087 default value is false. If the type attribute is not set to 1088 'vas', the MS ignores this attribute. 1090 If the MS does not support the specified video switching policy or 1091 other configuration parameters (including separate active speaker 1092 video mixes), then MS reports a 424 error (Section 4.5) in the 1093 response to the request element containing the 1094 element. 1096 If the MS receives a or request containing a 1097 element (Section 4.2.2.5) specifying a region and the 1098 conference video switching policy is set to 'vas', then the MS 1099 ignores the region (i.e. conference switching policy takes 1100 precedence). 1102 If the MS receives a or request containing a 1103 element (Section 4.2.2.5) specifying a region which is not 1104 defined for the currently active video layout, the MS MUST NOT report 1105 an error. Even though the participant is not currently visible, the 1106 MS displays the participant if the layout changes to one which 1107 defines the specified region. 1109 The element has no child elements. 1111 For example, a fragment specifying a 'vas' video switching policy 1112 with an interval of 2s 1114 1116 For example, a fragment specifying a 'controller' video switching 1117 policy where video switching takes place immediately: 1119 1121 4.2.1.4.3.1. Priority assignment 1123 In cases where the video switching policy does not explicitly 1124 determine the region to which a participant is assigned, the 1125 following priority assignment mechanism applies: 1127 1. Each participant has an (positive integer) priority value: the 1128 lower the value, the higher the priority. The priority value is 1129 determined by the child element (Section 4.2.2.5.4) of 1130 . If not explicitly specified, the default priority 1131 value is 100. 1133 2. The MS uses priority values to assign participants to regions in 1134 the video layout which remain unfilled after application of the 1135 video switching policy. The MS MUST dedicate larger and/or more 1136 prominent portions of the layout to participants with higher 1137 priority values first (e.g. first, all participants with priority 1138 1, then those with 2, 3, etc). 1140 3. The policy for displaying participants with the same priority is 1141 implementation-specific. 1143 The MS applies this priority policy each time the video layout is 1144 changed or updated. It is RECOMMENDED that the MS does not move a 1145 participant from one region to another unless required by the video 1146 switching policy when an active video layout is updated. 1148 This model allows the MS to apply default video layouts after 1149 applying the video switch policy. For example, region 2 is 1150 statically assigned to Bob, so the priority mechanism only applies to 1151 regions 1, 3, 4, etc. 1153 4.2.1.4.4. 1155 The element is a container for specifying conference 1156 notification events to which a controlling entity subscribes. 1157 Notifications of conference events are delivered using the 1158 element (see Section 4.2.4). 1160 The element has no attributes, but has the following 1161 child element: 1163 : subscription to active talker events 1164 (Section 4.2.1.4.4.1). The element is optional. 1166 The MS MUST support a subscription. It MAY 1167 support other event subscriptions (specified using attributes and 1168 child elements from a foreign namespace). If the MS does not support 1169 a subscription specified in a foreign namespace, it sends a 1170 with a 428 status code (see Section 4.5). 1172 4.2.1.4.4.1. 1174 The element has the following attributes: 1176 interval: the minimum amount of time (in seconds) that elapses 1177 before further active talker events can be generated. A valid 1178 value is a non-negative integer (see Section 4.6.2). A value of 0 1179 suppresses further notifications. The attribute is optional. The 1180 default value is 3 (seconds). 1182 The element has no child elements. 1184 Active talker notifications are delivered in the element (Section 4.2.4.1). 1187 4.2.2. Joining Elements 1189 In this section, the joining model is defined (Section 4.2.2.1) as 1190 well as definitions of the (Section 4.2.2.2), 1191 (Section 4.2.2.3), (Section 4.2.2.4) and 1192 (Section 4.2.2.5) elements. 1194 4.2.2.1. Joining Model 1196 The operation creates a media stream between a connection and 1197 a conference, between connections, or between conferences. This 1198 section describes the model of conferences and connections and 1199 specifies the behavior for join requests to targets that already have 1200 an associated media stream. 1202 Conferences support multiple inputs and have resources to mix them 1203 together. A media server conference in essence is a mixer that 1204 combines media streams. A simple audio mixer simply sums its input 1205 audio signals to create a single common output. Conferences however 1206 use a more complex algorithm so that participants do not hear 1207 themselves as part of the mix. That algorithm, sometimes called an 1208 n-minus mix, subtracts each participants input signal from the summed 1209 input signals, creating a unique output for each contributing 1210 participant. Each operation to a conference uses one of the 1211 conference's available inputs and/or outputs, to the maximum number 1212 of supported participants. 1214 A connection is the termination of a RTP session(s) on a media 1215 server. It has a single input and output for each media session 1216 established by its SIP dialog. The output of a connection can feed 1217 several different inputs such as both a conference mixer and a 1218 recording of that participant's audio. 1220 Joining two connections which are are not joined to anything else 1221 simply creates a media stream from the outputs(s) of one connection 1222 to the corresponding inputs(s) of the other connection. It is not 1223 necessary to combine media from multiple sources in this case. There 1224 are however several common scenarios where combining media from 1225 several sources to create a single input to a connection is needed. 1227 In the first case, a connection can be receiving media from one 1228 source, for example a conference, and it is necessary to play an 1229 announcement to the connection so that both the conference audio and 1230 announcement can be heard by the conference participant. This is 1231 sometimes referred to as a whisper announcement. An alternative to a 1232 whisper announcement is to have the announcement pre-empt the 1233 conference media. 1235 Another common case is the call center coaching scenario where a 1236 supervisor can listen to the conversation between an agent and a 1237 customer, and provide hints to the agent, which are not heard by the 1238 customer. 1240 Both of these cases can be solved by having the controlling AS create 1241 one or more conferences for audio mixing, and then join and unjoin 1242 the media streams as required. A better solution is to have the 1243 media server automatically mix media streams that are requested to be 1244 joined to a common input when only the simple summing of audio 1245 signals as described above is required. This is the case for both 1246 the use cases presented above. 1248 Automatically mixing streams has several benefits. Conceptually, it 1249 is straight forward and simple, requiring no indirect requests on the 1250 part of the controlling AS. This increases transport efficiency and 1251 reduces the coordination complexity and the latency of the overall 1252 operation. Therefore, it is RECOMMENDED that a media server be able 1253 to automatically mix at least two audio streams where only the simple 1254 summing of signals is required. 1256 When a media server receives a request, it MUST automatically 1257 mix all of the media streams included in the request with any streams 1258 already joined to one of the entities identified in the request, or 1259 it MUST fail the request and MUST NOT join any of the streams (and 1260 MUST NOT change existing streams of the entities). A controlling AS 1261 uses the request for generic conferences where the 1262 complex mixing algorithm is required. 1264 Specifications which extend this package to handle additional media 1265 types such as text, MUST define the semantics of the join operation 1266 when multiple streams are requested to be joined to a single input, 1267 such as that for a connection with a single RTP session per media 1268 type. 1270 4.2.2.2. 1272 The element is sent to the MS to request creation of one or 1273 more media streams either between a connection and a conference, 1274 between connections, or between conferences. The two entities to 1275 join are specified by the attributes of . 1277 Streams can be of any media type, and can be bi-directional or uni- 1278 directional. A bi-directional stream is implicitly composed of two 1279 uni-directional streams that can be manipulated independently. The 1280 streams to be established are specified by child elements 1281 (see Section 4.2.2.5). 1283 The element has the following attributes: 1285 id1: an identifier for either a connection or a conference. The 1286 identifier MUST conform to the syntax defined in Section 16.1 of 1287 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 1288 mandatory. 1290 id2: an identifier for either a connection or a conference. The 1291 identifier MUST conform to the syntax defined in Section 16.1 of 1292 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 1293 mandatory. 1295 Note: Section 16.1 of [I-D.ietf-mediactrl-sip-control-framework] 1296 defines the semantics for a conference identifier but not its syntax. 1297 Media server implementations need to distinguish between conferences 1298 and connections based upon the values of the "id1" and "id2" 1299 attributes. 1301 If id1 or id2 specify a conference identifier and the conference does 1302 not exist on the MS, the MS reports an error (406). If id1 or id2 1303 specify a connection identifier and the connection does not exist on 1304 the MS, the MS reports an error (412). 1306 The element has the following child element (0 or more): 1308 : an element that both identifies the media streams to join 1309 and defines the way that they are to be joined (see 1310 Section 4.2.2.5). The element is optional. 1312 If no elements are specified, then the default is to join 1313 all streams between the entities according to the media configuration 1314 of the connection or conference. 1316 One or more elements can be specified so that individual 1317 media streams can be controlled independently. For example, if a 1318 connection supports both audio and video streams, a element 1319 could be used to indicate that only the audio stream is used in 1320 receive mode. In cases where there are multiple media streams of the 1321 same type for a connection or conference, the configuration MUST be 1322 explicitly specified using elements. 1324 Multiple elements can be specified for precise control over 1325 the media flow in different directions within the same media stream. 1326 One element can be specified for the receiving media flow 1327 and another element for the sending media flow, where each 1328 independently controls features such as volume (see child element of 1329 in Section 4.2.2.5). If there is only one element 1330 for a given media specifying a 'sendonly' or 'recvonly' direction, 1331 then the media flow in the opposite direction is inactive 1332 (established but no actual flow of media) unless this leads to a 1333 stream conflict. 1335 If the MS is unable to execute the join as specified in 1336 because a element is in conflict with (a) another 1337 element, (b) with specified connection or conference media 1338 capabilities (including supported or available codec information), or 1339 (c) with a SDP label value as part of the connection-id (see Section 1340 16.1 of [I-D.ietf-mediactrl-sip-control-framework]), then the MS 1341 reports an error (407) and MUST NOT join the entities and MUST NOT 1342 change existing streams of the entities. 1344 If the MS is unable to execute the join as specified in 1345 elements because the MS does not support the media stream 1346 configuration, the MS reports an error (422) and MUST NOT join the 1347 entities and MUST NOT change existing streams of the entities. 1349 If the MS is unable to join an entity to a conference because it is 1350 full, then the MS reports an error (410). 1352 If the specified entities are already joined, then the MS reports an 1353 error (408). 1355 If the MS does not support joining two specified connections 1356 together, the MS reports an error (426). 1358 If the MS does not support joining two specified conferences 1359 together, the MS reports an error (427). 1361 If the MS is unable to join the specified entities for any other 1362 reason, the MS reports an error (411). 1364 When the MS has finished processing a request, it MUST reply 1365 with an element (Section 4.2.3). 1367 For example, a request to join two connection together: 1369 1370 1371 1373 and the response if the MS doesn't support joining media streams 1374 between connections: 1376 1377 1378 1380 4.2.2.3. 1382 The element is sent to the MS to request changes in the 1383 configuration of media stream(s) that were previously established 1384 between a connection and a conference, between two connections, or 1385 between two conferences. 1387 The element has the following attributes: 1389 id1: an identifier for either a connection or a conference. The 1390 identifier MUST conform to the syntax defined in Section 16.1 of 1391 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 1392 mandatory. 1394 id2: an identifier for either a connection or a conference. The 1395 identifier MUST conform to the syntax defined in Section 16.1 of 1396 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 1397 mandatory. 1399 The element has the following child elements (1 or 1400 more): 1402 : an element that both identifies the media streams to 1403 modify and defines the way that each stream is now to be 1404 configured (see Section 4.2.2.5). 1406 The MS MUST support for any stream that was established 1407 using . 1409 The MS MUST configure the streams that are included within 1410 to that stated by the child elements. 1412 If the MS is unable to modify the join as specified in 1413 elements because a element is in conflict with (a) another 1414 element, (b) with specified connection or conference media 1415 capabilities (including supported or available codec information), or 1416 (c) with a SDP label value as part of the connection-id (see Section 1417 16.1 of [I-D.ietf-mediactrl-sip-control-framework]), then the MS 1418 reports an error (407) and MUST NOT modify the join between the 1419 entities and MUST NOT change existing streams of the entities. 1421 If the MS is unable to modify the join as specified in 1422 elements because the MS does not support the media stream 1423 configuration, the MS reports an error (422) and MUST NOT modify the 1424 join between the entities and MUST NOT change existing streams of the 1425 entities. 1427 If the specified entities are not already joined, then the MS reports 1428 an error (409). 1430 If the MS is unable to modify the join between the specified entities 1431 for any other reason, the MS reports an error (411). 1433 When an MS has finished processing a request, it MUST 1434 reply with an appropriate element (Section 4.2.3). 1436 In cases where stream characteristics are controlled independently 1437 for each direction, then a request needs to specify a 1438 child element for each direction in order to retain the original 1439 stream directionality. For the example, if a request 1440 establishes independent control for each direction of an audio stream 1441 (see Section 4.2.2.5): 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1454 then the following request 1456 1457 1458 1459 1460 1461 1462 1464 would cause, in addition to the sendonly volume being modified, that 1465 the overall stream directionality changes from sendrecv to sendonly 1466 since there is no element in this request for 1467 the recvonly direction. The following would change the sendonly 1468 volume and retain the recvonly stream together with its original 1469 characteristics such as volume: 1471 1472 1473 1474 1475 1476 1477 1478 1480 4.2.2.4. 1482 The element is sent to the MS to request removal of 1483 previously established media stream(s) from between a connection and 1484 a conference, between two connections, or between two conferences. 1486 The element has the following attributes: 1488 id1: an identifier for either a connection or a conference. The 1489 identifier MUST conform to the syntax defined in Section 16.1 of 1490 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 1491 mandatory. 1493 id2: an identifier for either a connection or a conference. The 1494 identifier MUST conform to the syntax defined in Section 15.1 of 1495 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 1496 mandatory. 1498 The element has the following child element (0 or more 1499 occurrences): 1501 : an element that identifies the media stream(s) to remove 1502 (see Section 4.2.2.5). The element is optional. When not 1503 present, all currently established streams between "id1" and "id2" 1504 are removed. 1506 The MS MUST support for any stream that was established 1507 using and has not already been removed by a previous 1508 on the same stream. 1510 If the MS is unable to terminate the join as specified in 1511 elements because a element is in conflict with (a) another 1512 element, (b) with specified connection or conference media 1513 capabilities or (c) with a SDP label value as part of the 1514 connection-id (see Section 16.1 of 1515 [I-D.ietf-mediactrl-sip-control-framework]), then the MS reports an 1516 error (407) and MUST NOT terminate the join between the entities and 1517 MUST NOT change existing streams of the entities. 1519 If the MS is unable to terminate the join as specified in 1520 elements because the MS does not support the media stream 1521 configuration, the MS reports an error (422) and MUST NOT terminate 1522 the join between the entities and MUST NOT change existing streams of 1523 the entities. 1525 If the specified entities are not already joined, then the MS reports 1526 an error (409). 1528 If the MS is unable to terminate the join between the specified 1529 entities for any other reason, the MS reports an error (411). 1531 When an MS has successfully processed a request, it MUST 1532 reply with a successful element (Section 4.2.3). 1534 4.2.2.5. 1536 , and require the identification and 1537 manipulations of media streams. Media streams represent the flow of 1538 media between a participant connection and a conference, between two 1539 connections, or between two conferences. The element is 1540 used (as a child to , and element has the following attributes: 1546 media: a string indicating the type of media associated with the 1547 stream. The following values MUST be used for common types of 1548 media: "audio" for audio media, and "video" for video media. The 1549 attribute is mandatory. 1551 label: a string indicating the SDP label associated with a media 1552 stream ([RFC4574]). The attribute is optional. 1554 direction: a string indicating the allowed media flow of the stream 1555 relative to the value of the "id1" attribute of the parent 1556 element. Defined values are: "sendrecv" (media can be sent and 1557 received), "sendonly" (media can only be sent), "recvonly" (media 1558 can only be received) and "inactive" (stream established but no 1559 media flow). The default value is "sendrecv". The attribute is 1560 optional. 1562 The element has the following sequence of child elements: 1564 : an element (Section 4.2.2.5.1) to configure the volume or 1565 gain of the media stream. The element is optional. 1567 : an element (Section 4.2.2.5.2) to configure filtering and 1568 removal of tones from the media stream. The element is optional. 1570 : an element (Section 4.2.2.5.3) to configure a region 1571 within a video layout where the media stream is displayed. The 1572 element is optional. 1574 : an element (Section 4.2.2.5.4) to configure priority 1575 associated with the stream in the media mix. The element is 1576 optional. 1578 In each child element, the media stream affected is indicated by the 1579 value of the direction attribute of the parent element. 1581 If the media attribute does not have the value of "audio", then the 1582 MS ignores and elements. 1584 If the media attribute does not have the value of "video", then the 1585 MS ignores a element. 1587 For example, a request to join a connection to conference in both 1588 directions with volume control: 1590 1591 1592 1593 1594 1595 1596 1598 where audio flow from the connection (id1) to the conference (id2) 1599 has the volume lowered by 3dB, and likewise the volume of the audio 1600 flow from the conference to the connection is lowered by 3 dB. 1602 In this example, the volume is independently controlled for each 1603 direction. 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1616 where audio flow from the connection (id1) to the conference (id2) 1617 has the volume lowered by 3dB, but the volume of the audio flow from 1618 the conference to the connection is raised by 3 dB. 1620 4.2.2.5.1. 1622 The element is used to configure the volume of an audio 1623 media stream. It can be set to a specific gain amount, to 1624 automatically adjust the gain to a desired target level, or to mute 1625 the volume. 1627 The element has no child elements but has the following 1628 attributes: 1630 controltype: a string indicating the type of volume control to use 1631 for the stream. Defined values are: "automatic" (the volume will 1632 be adjusted automatically to the level specified by the "value" 1633 attribute), "setgain" (use the value of the "value" attribute as a 1634 specific gain measured in dB to apply), "setstate" (set the state 1635 of the stream to "mute" or "unmute" as specified by the value of 1636 the "value" attribute). The attribute is mandatory. 1638 value: a string specifying the amount or state for the volume 1639 control defined by the value of the "controltype" attribute. The 1640 attribute is optional. There is no default value. 1642 If the audio media stream is in a muted state, then the MS also 1643 changes automatically the state to unmuted with an "automatic" or 1644 "setgain" volume control. For the example, assume an audio stream 1645 has been muted with . 1646 If the gain on the same stream is changed with , then the volume is increased and 1648 stream state is also changed to unmuted. 1650 4.2.2.5.2. 1652 The element is used to configure whether tones are filtered 1653 and removed from a media stream. 1655 The element has no child elements but has the following 1656 attributes: 1658 tones: A space-separated list of the tones to remove. The attribute 1659 is optional. The default value is "1 2 3 4 5 6 7 8 9 0 * # A B C 1660 D" (i.e. all DTMF tones removed). 1662 4.2.2.5.3. 1664 The element is used to explicitly specify the region within 1665 a video layout where the media stream is displayed. 1667 The element has no attributes and its content model 1668 specifies the name of the region layout. 1670 4.2.2.5.4. 1672 The element is used to explicitly specify the priority of 1673 a participant. The MS uses this priority to determine where the 1674 media stream is displayed within a video layout 1675 (Section 4.2.1.4.3.1). 1677 The element has no attributes and its content model 1678 specifies a positive integer (see Section 4.6.3). The lower the 1679 value, the higher the priority. 1681 4.2.3. 1683 Responses to requests are indicated by a element. 1685 The element has following attributes: 1687 status: numeric code indicating the response status. Valid values 1688 are defined in Section 4.5. The attribute is mandatory. 1690 reason: string specifying a reason for the response status. The 1691 attribute is optional. 1693 conferenceid: string identifying the conference (see Section 16.1 of 1694 [I-D.ietf-mediactrl-sip-control-framework]). The attribute is 1695 optional. 1697 connectionid: string identifying the SIP dialog connection (see 1698 Section 16.1 of [I-D.ietf-mediactrl-sip-control-framework]). The 1699 attribute is optional. 1701 For example, a response when a conference was created successfully: 1703 1704 Success 1705 1707 The response if conference creation failed due to the requested 1708 conference id already existing: 1710 1711 Conf already exists 1712 1714 4.2.4. 1716 When a mixer generates a notification event, the MS sends the event 1717 using an element. 1719 The element has no attributes, but has the following sequence 1720 of child elements (0 or more instances of each child): 1722 specifies an active talkers notification 1723 (Section 4.2.4.1). 1725 notifies that a connection or conference has been 1726 completely unjoined (Section 4.2.4.2). 1728 notifies that a conference has exited 1729 (Section 4.2.4.3). 1731 4.2.4.1. 1733 The element describes zero or more speakers 1734 that have been active in a conference during the specified interval 1735 (see Section 4.2.1.4.4.1). 1737 The element has the following attributes: 1739 conferenceid: string indicating the name of the conference from 1740 which the event originated. This attribute is mandatory. 1742 The element has the following sequence of 1743 child elements (0 or more occurrences): 1745 element describing an active talker 1746 (Section 4.2.4.1.1). 1748 4.2.4.1.1. 1750 The element describes an active talker, associated 1751 with either a connection or conference participant in a conference. 1753 The element has the following attributes: 1755 connectionid: string indicating the connectionid of the active 1756 talker. This attribute is optional. There is no default value. 1758 conferenceid: string indicating the conferenceid of the active 1759 talker. This attribute is optional. There is no default value. 1761 Note that the element does not describe an active talker if both the 1762 connectionid and conferenceid attributes are specified, or if neither 1763 attribute is specified. 1765 The element has no child elements. 1767 4.2.4.2. 1769 The element describes a notification event where a 1770 connection and/or conference have been completely unjoined. 1772 The element has the following attributes: 1774 status: a status code indicating why the unjoin occurred. A valid 1775 value is a non-negative integer (see Section 4.6.2). The MS MUST 1776 support the following values: 1778 0 indicates the join has been terminated by a request. 1780 1 indicates the join terminated due to an execution error. 1782 2 indicates that the join terminated because a connection or 1783 conference has terminated. 1785 All other valid but undefined values are reserved for future use, 1786 where a standards-track RFC is required to define new status 1787 codes. The AS MUST treat any status code it does not recognize as 1788 being equivalent to 1 (join execution error). The attribute is 1789 mandatory. 1791 reason: a textual description providing a reason for the status 1792 code; e.g. details about an error. A valid value is a string (see 1793 Section 4.6.4). The attribute is optional. There is no default 1794 value. 1796 id1: an identifier for either a connection or a conference. The 1797 identifier MUST conform to the syntax defined in Section 16.1 of 1798 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 1799 mandatory. 1801 id2: an identifier for either a connection or a conference. The 1802 identifier MUST conform to the syntax defined in Section 16.1 of 1803 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 1804 mandatory. 1806 The element has no child elements. 1808 4.2.4.3. 1810 The element indicates that a conference has exited 1811 because it has been terminated or because a error occurred (for 1812 example, a hardware error in the conference mixing unit). This event 1813 MUST be sent by the MS whenever a successfully created conference 1814 exits. 1816 The element has the following attributes: 1818 conferenceid: string indicating the name of the conference. This 1819 attribute is mandatory. 1821 status: a status code indicating why the conference exited. A valid 1822 value is a non-negative integer (see Section 4.6.2). The MS MUST 1823 support the following values: 1825 0 indicates the conference has been terminated by a 1826 request. 1828 1 indicates the conference terminated due to an execution error. 1830 2 indicates the conference terminated due to exceeding the 1831 maximum duration for a conference. 1833 All other valid but undefined values are reserved for future use, 1834 where a standards-track RFC is required to define new status 1835 codes. The AS MUST treat any status code it does not recognize as 1836 being equivalent to 1 (conference execution error). The attribute 1837 is mandatory. 1839 reason: a textual description providing a reason for the status 1840 code; e.g. details about an error. A valid value is a string (see 1841 Section 4.6.4). The attribute is optional. There is no default 1842 value. 1844 The element has no child elements. 1846 When a MS sends a event, the identifier for the 1847 conference (conferenceid attribute) is no longer valid on the MS and 1848 can be reused for another conference. 1850 For example, the following notification event would be sent from the 1851 MS when the conference with identifier "conference99" exits due to a 1852 successful : 1854 1855 1856 1858 1859 1861 4.3. Audit Elements 1863 The audit elements defined in this section allow the MS to be audited 1864 for package capabilities as well as mixers managed by the package. 1865 Auditing is particularly important for two use cases. First, it 1866 enables discovery of package capabilities supported on an MS before 1867 an AS creates a conference mixer or joins connections and 1868 conferences. The AS can then use this information to create request 1869 elements using supported capabilities and, in the case of codecs, to 1870 negotiate an appropriate SDP for a user agent's connection. Second, 1871 auditing enables discovery of the existence and status of mixers 1872 currently managed by the package on the MS. This could be used when 1873 one AS takes over management of mixers if the AS which created the 1874 mixers fails or is no longer available (see Security Considerations 1875 described in Section 7). 1877 4.3.1. 1879 The request element is sent to the MS to request information 1880 about the capabilities of, and mixers currently managed with, this 1881 control package. Capabilities include supported conference codecs 1882 and video layouts. Mixer information includes the status of managed 1883 mixers as well as codecs. 1885 The element has the following attributes: 1887 capabilities: indicates whether package capabilities are to be 1888 audited. A valid value is a boolean (see Section 4.6.1). A value 1889 of true indicates that capability information is to be reported. 1890 A value of false indicates that capability information is not to 1891 be reported. The attribute is optional. The default value is 1892 true. 1894 mixers: indicates whether mixers currently managed by the package 1895 are to be audited. A valid value is a boolean (see 1896 Section 4.6.1). A value of true indicates that mixer information 1897 is to be reported. A value of false indicates that mixer 1898 information is not to be reported. The attribute is optional. 1899 The default value is true. 1901 conferenceid: string identifying a specific conference mixer to 1902 audit. It is an error (406) if the conferenceid attribute is 1903 specified and the conference identifier is not valid. The 1904 attribute is optional. There is no default value. 1906 If the mixers attribute has the value true and conferenceid attribute 1907 is specified, then only audit information about the specified 1908 conference mixer is reported. If the mixers attribute has the value 1909 false, then no mixer audit information is reported even if a 1910 conferenceid attribute is specified. 1912 The element has no child elements. 1914 When the MS receives an request, it MUST reply with a 1915 element (Section 4.3.2) which includes a mandatory 1916 attribute describing the status in terms of a numeric code. Response 1917 status codes are defined in Section 4.5. If the request is 1918 successful, the contains (depending on attribute 1919 values) a element (Section 4.3.2.1) reporting package 1920 capabilities and a element (Section 4.3.2.2) reporting 1921 managed mixer information. If the MS is not able to process the 1922 request and carry out the audit operation, the audit request has 1923 failed and the MS MUST indicate the class of failure using an 1924 appropriate 4xx response code. Unless an error response code is 1925 specified for a class of error within this section, implementations 1926 follow Section 4.5 in determining the appropriate status code for the 1927 response. 1929 For example, a request to audit capabilities and mixers managed by 1930 the package: 1932 1933 1934 1936 In this example, only capabilities are to be audited: 1938 1939 1940 1942 With this example, only a specific conference mixer is to be audited: 1944 1945 1946 1948 4.3.2. 1950 The element describes a response to a 1951 request. 1953 The element has the following attributes: 1955 status: numeric code indicating the audit response status. The 1956 attribute is mandatory. Valid values are defined in Section 4.5. 1958 reason: string specifying a reason for the status. The attribute is 1959 optional. 1961 The element has the following sequence of child 1962 elements: 1964 element (Section 4.3.2.1) describing capabilities of 1965 the package. The element is optional. 1967 element (Section 4.3.2.2) describing information about 1968 managed mixers. The element is optional. 1970 For example, a successful response to a request requesting 1971 capabilities and mixer information: 1973 1974 1975 1976 1977 1978 H263 1979 1980 1981 H264 1982 1983 1984 PCMU 1985 1986 1987 PCMA 1988 1989 1990 1991 1992 1993 1994 1995 PCMA 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2009 4.3.2.1. 2011 The element provides audit information about package 2012 capabilities. 2014 The element has no attributes. 2016 The element has the following sequence of child 2017 elements: 2019 : element (Section 4.4) describing codecs available to the 2020 package. The element is mandatory. 2022 For example, a fragment describing capabilities: 2024 2025 2026 2027 H263 2028 2029 2030 H264 2031 2032 2033 PCMU 2034 2035 2036 PCMA 2037 2038 2039 2041 4.3.2.2. 2043 The element provides audit information about mixers. 2045 The element has no attributes. 2047 The element has the following sequence of child elements (0 2048 or more occurrences, any order): 2050 : audit information for a conference mixer 2051 (Section 4.3.2.2.1). The element is optional. 2053 : audit information for a join mixer (Section 4.3.2.2.2). 2054 The element is optional. 2056 4.3.2.2.1. 2058 The element has the following attributes: 2060 conferenceid: string identifying the conference (see Section 16.1 of 2061 [I-D.ietf-mediactrl-sip-control-framework]). The attribute is 2062 mandatory. 2064 The element has the following sequence of child 2065 elements: 2067 element describing codecs used in the conference. See 2068 Section 4.4. The element is optional. 2070 element listing connections or conferences joined to 2071 the conference. See Section 4.3.2.2.1.1. The element is 2072 optional. 2074 element describing the active video layout for the 2075 conference. See Section 4.2.1.4.2.1. The element is optional. 2077 For example, a fragment describing a conference which has been 2078 created but has no participants: 2080 2082 And a fragment when the same conference has three participants (two 2083 connections and another conference) joined to it: 2085 2086 2087 2088 PCMU 2089 2090 2091 2092 2093 2094 2095 2096 2098 4.3.2.2.1.1. 2100 The element is a container for elements 2101 (Section 4.3.2.2.1.1.1). 2103 The element has no attributes, but the following child 2104 elements are defined (0 or more): 2106 : specifies a participant (Section 4.3.2.2.1.1.1). 2108 4.3.2.2.1.1.1. 2110 The element describes a participant. 2112 The element has the following attributes: 2114 id: an identifier for either a connection or a conference. The 2115 identifier MUST conform to the syntax defined in Section 16.1 of 2116 [I-D.ietf-mediactrl-sip-control-framework]. The attribute is 2117 mandatory. 2119 The element has no children. 2121 4.3.2.2.2. 2123 The element has the following attributes: 2125 id1: an identifier for either a connection or a conference. The 2126 identifier MUST conform to the syntax defined in Section 16.1 of 2127 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 2128 mandatory. 2130 id2: an identifier for either a connection or a conference. The 2131 identifier MUST conform to the syntax defined in Section 16.1 of 2132 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 2133 mandatory. 2135 The element has no children. 2137 For example, a fragment describing an audit of two join mixers, one 2138 between connections and the second between conferences: 2140 2141 2142 2143 2145 4.4. 2147 The element is a container for one or more codec 2148 definitions. Codec definitions are used by an AS to specify the 2149 codecs allowed for a conference (e.g. when used as a child of 2150 or element has no attributes. 2156 The element has the following sequence of child elements (0 2157 or more occurrences): 2159 : defines a codec and optionally its policy (Section 4.4.1). 2160 The element is optional. 2162 For example, a fragment describing two codecs: 2164 2165 2166 PCMA 2167 2168 2169 H263 2170 2171 2173 4.4.1. 2175 The element describes a codec. The element is modeled on the 2176 element in the XCON conference information data model 2177 ([I-D.ietf-xcon-common-data-model]) and allows addition information 2178 (e.g. rate, speed, etc) to be specified. 2180 The element has no attributes. 2182 The element has the following sequence of child elements: 2184 : element (Section 4.4.1.1) describing the codec's name. 2185 The element is mandatory. 2187 : element (Section 4.4.1.2) describing additional 2188 information about the codec. This package is agnostic to the 2189 names and values of the codec parameters supported by an 2190 implementation. The element is optional. 2192 For example, a fragment with a element describing the H263 2193 codec: 2195 2196 H263 2197 2199 And a fragment where the element describes the H264 codec 2200 with additional information about the profile level and packetization 2201 mode: 2203 2204 H264 2205 2206 42A01E 2207 0 2208 2209 2211 4.4.1.1. 2213 The element specifies the name of a codec. The possible 2214 names are the values of the 'subtype' column of the RTP Payload 2215 Format media types per [RFC4855] defined in IANA ([IANA]). 2217 The element has no attributes and its content model is the 2218 codec name. 2220 4.4.1.2. 2222 The element is a container for elements 2223 (Section 4.4.1.2.1). 2225 The element has no attributes, but the following child 2226 elements are defined (0 or more): 2228 : specifies a parameter name and value (Section 4.4.1.2.1). 2230 4.4.1.2.1. 2232 The element describes a parameter name and value. 2234 The element has the following attributes: 2236 name: a string indicating the name of the parameter. The attribute 2237 is mandatory. 2239 type: specifies a type indicating how the inline value of the 2240 parameter is to be interpreted. A valid value is a MIME media 2241 type (see Section 4.6.6). The attribute is optional. The default 2242 value is "text/plain". 2244 The element content model (text and/or XML) is the value of 2245 the parameter. Values in XML format MUST use a namespace other than 2246 the one used in this specification. Note that a text value which 2247 contains XML characters (e.g. "<") needs to be escaped following 2248 standard XML conventions. 2250 4.5. Response Status Codes 2252 This section describes the response codes in Table 1 for the status 2253 attribute of mixer management (Section 4.2.3) and audit 2254 (Section 4.3.2) responses. The MS MUST support the 2255 status response codes defined here. All other valid but undefined 2256 values are reserved for future use, where a standards-track RFC is 2257 required to define new status codes. The AS MUST treat any responses 2258 it does not recognize as being equivalent to the x00 response code 2259 for all classes. For example, if an AS receives an unrecognized 2260 response code of 499, it can safely assume that there was something 2261 wrong with its request and treat the response as if it had received a 2262 400 (Syntax error) response code. 2264 4xx responses are definite failure responses from a particular MS. 2265 The reason attribute in the response SHOULD identify the failure in 2266 more detail, for example, "Mandatory attribute missing: id2 join 2267 element" for a 400 (Syntax error) response code. 2269 The AS SHOULD NOT retry the same request without modification (for 2270 example, correcting a syntax error or changing the conferenceid to 2271 use one available on the MS). However, the same request to a 2272 different MS might be successful; for example, if another MS supports 2273 a capability required in the request. 2275 4xx failure responses can be grouped into three classes: failure due 2276 to a syntax error in the request (400); failure due to an error 2277 executing the request on the MS (405-419); and failure due to the 2278 request requiring a capability not supported by the MS (420-435). 2280 In cases where more than one request code could be reported for a 2281 failure, the MS SHOULD use the most specific error code of the 2282 failure class for the detected error. For example, if the MS detects 2283 that the conference identifier in the request is invalid, then it 2284 uses a 406 status code. However, if the MS merely detects that an 2285 execution error occurred, then 419 is used. 2287 +-------+---------------+----------------------+--------------------+ 2288 | Code | Summary | Description | Informational: AS | 2289 | | | | Possible Recovery | 2290 | | | | Action | 2291 +-------+---------------+----------------------+--------------------+ 2292 | 200 | OK | request has | | 2293 | | | succeeded | | 2294 | | | | | 2295 | 400 | Syntax error | request is | Change the request | 2296 | | | syntactically | so that it is | 2297 | | | invalid: it is not | syntactically | 2298 | | | valid with respect | valid. | 2299 | | | to the XML schema | | 2300 | | | specified in | | 2301 | | | Section 5 or it | | 2302 | | | violates a | | 2303 | | | co-occurrence | | 2304 | | | constraint for a | | 2305 | | | request element | | 2306 | | | defined in | | 2307 | | | Section 4. | | 2308 | | | | | 2309 | 405 | Conference | request uses an | Send an | 2310 | | already | identifier to create | request | 2311 | | exists | a new conference | (Section 4.3.1) | 2312 | | | (Section 4.2.1.1) | requesting the | 2313 | | | which is already | list of conference | 2314 | | | used by another | mixer identifiers | 2315 | | | conference on the | already used by | 2316 | | | MS. | the MS and then | 2317 | | | | use a conference | 2318 | | | | identifier which | 2319 | | | | is not listed. | 2320 | | | | | 2321 | 406 | Conference | request uses an | Send an | 2322 | | does not | identifier for a | request | 2323 | | exist | conference which | (Section 4.3.1) | 2324 | | | does not exist on | requesting the | 2325 | | | the MS. | list of conference | 2326 | | | | mixer identifiers | 2327 | | | | used by the MS and | 2328 | | | | then use a | 2329 | | | | conference | 2330 | | | | identifier which | 2331 | | | | is listed. | 2332 | | | | | 2333 | 407 | Incompatible | request specifies a | Change the media | 2334 | | stream | media stream | stream | 2335 | | configuration | configuration which | configuration to | 2336 | | | is in conflict with | match the | 2337 | | | itself, or the | capabilities of | 2338 | | | connection or | the connection or | 2339 | | | conference | conference | 2340 | | | capabilities (see | | 2341 | | | Section 4.2.2.2) | | 2342 | | | | | 2343 | 408 | joining | request attempts to | Send an | 2344 | | entities | create a join mixer | request | 2345 | | already | (Section 4.2.2.2) | (Section 4.3.1) | 2346 | | joined | where the entities | requesting the | 2347 | | | are already joined | list of join | 2348 | | | | mixers on the MS | 2349 | | | | and then use | 2350 | | | | entities which are | 2351 | | | | not listed. | 2352 | | | | | 2353 | 409 | joining | request attempts to | Send an | 2354 | | entities not | manipulate a join | request | 2355 | | joined | mixer where entities | (Section 4.3.1) | 2356 | | | which are not joined | requesting the | 2357 | | | | list of join | 2358 | | | | mixers on the MS | 2359 | | | | and then use | 2360 | | | | entities which are | 2361 | | | | listed. | 2362 | | | | | 2363 | 410 | Unable to | request attempts to | | 2364 | | join - | join a participant | | 2365 | | conference | to a conference | | 2366 | | full | (Section 4.2.2.2) | | 2367 | | | but the conference | | 2368 | | | is already full | | 2369 | | | | | 2370 | 411 | Unable to | request attempts to | | 2371 | | perform join | create, modify or | | 2372 | | mixer | delete a join | | 2373 | | operation | between entities but | | 2374 | | | fails | | 2375 | | | | | 2376 | 412 | Connection | request uses an | | 2377 | | does not | identifier for a | | 2378 | | exist | connection which | | 2379 | | | does not exist on | | 2380 | | | the MS. | | 2381 | 419 | Other | requested operation | | 2382 | | execution | cannot be executed | | 2383 | | error | by the MS. | | 2384 | | | | | 2385 | 420 | Conference | request to create a | | 2386 | | reservation | new conference | | 2387 | | failed | (Section 4.2.1.1) | | 2388 | | | failed due to | | 2389 | | | unsupported | | 2390 | | | reservation of | | 2391 | | | talkers or | | 2392 | | | listeners. | | 2393 | | | | | 2394 | 421 | Unable to | request to create or | | 2395 | | configure | modify a conference | | 2396 | | audio mix | failed due to | | 2397 | | | unsupported audio | | 2398 | | | mix. | | 2399 | | | | | 2400 | 422 | Unsupported | request contains one | | 2401 | | media stream | or more | | 2402 | | configuration | elements | | 2403 | | | (Section 4.2.2.5) | | 2404 | | | whose configuration | | 2405 | | | is not supported by | | 2406 | | | the MS. | | 2407 | | | | | 2408 | 423 | Unable to | request to create or | | 2409 | | configure | modify a conference | | 2410 | | video layouts | failed due to | | 2411 | | | unsupported video | | 2412 | | | layout | | 2413 | | | configuration. | | 2414 | | | | | 2415 | 424 | Unable to | request to create or | | 2416 | | configure | modify a conference | | 2417 | | video switch | failed due to | | 2418 | | | unsupported video | | 2419 | | | switch | | 2420 | | | configuration. | | 2421 | | | | | 2422 | 425 | Unable to | request to create or | | 2423 | | configure | modify a conference | | 2424 | | codecs | failed due to | | 2425 | | | unsupported codec. | | 2426 | | | | | 2427 | 426 | Unable to | request to join | | 2428 | | join - mixing | connection entities | | 2429 | | connections | (Section 4.2.2.2) | | 2430 | | not supported | failed due lack of | | 2431 | | | support for mixing | | 2432 | | | connections. | | 2433 | | | | | 2434 | 427 | Unable to | request to join | | 2435 | | join - mixing | conference entities | | 2436 | | conferences | (Section 4.2.2.2) | | 2437 | | not supported | failed due lack of | | 2438 | | | support for mixing | | 2439 | | | conferences. | | 2440 | | | | | 2441 | 428 | Unsupported | the request contains | | 2442 | | foreign | attributes or | | 2443 | | namespace | elements from | | 2444 | | attribute or | another namespace | | 2445 | | element | which the MS does | | 2446 | | | not support | | 2447 | | | | | 2448 | 435 | Other | request requires | | 2449 | | unsupported | another capability | | 2450 | | capability | not supported by the | | 2451 | | | MS | | 2452 +-------+---------------+----------------------+--------------------+ 2454 Table 1: status codes 2456 4.6. Type Definitions 2458 This section defines types referenced in attribute definitions. 2460 4.6.1. Boolean 2462 The value space of boolean is the set {true, false}. 2464 4.6.2. Non-Negative Integer 2466 The value space of non-negative integer is the infinite set 2467 {0,1,2,...}. 2469 4.6.3. Positive Integer 2471 The value space of positive integer is the infinite set {1,2,...}. 2473 4.6.4. String 2475 A string in the character encoding associated with the XML element. 2477 4.6.5. Time Designation 2479 A time designation consists of a non-negative real number followed by 2480 a time unit identifier. 2482 The time unit identifiers are: "ms" (milliseconds) and "s" (seconds). 2484 Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s". 2486 4.6.6. MIME Media Type 2488 A string formatted as a IANA MIME media type ([MIME.mediatypes]). 2490 5. Formal Syntax 2492 This section defines the XML schema for the Mixer Control Package. 2494 The schema defines datatypes, attributes, and mixer elements in the 2495 urn:ietf:params:xml:ns:msc-mixer namespace. In most elements the 2496 order of child elements is significant. The schema is extensible: 2497 elements allow attributes and child elements from other namespaces. 2498 Elements from outside this package's namespace can occur after 2499 elements defined in this package. 2501 The schema is dependent upon the schema (framework.xsd) defined in 2502 Section 16.1 of the Control Framework 2503 [I-D.ietf-mediactrl-sip-control-framework]. 2505 2506 2513 2514 2515 IETF MediaCtrl Mixer 1.0 (20100225) 2517 This is the schema of the Mixer control package. It 2518 defines request, response and notification elements for 2519 mixing. 2521 The schema namespace is urn:ietf:params:xml:ns:msc-mixer 2523 2524 2526 2534 2537 2538 2539 This import brings in the framework attributes for 2540 conferenceid and connectionid. 2541 2542 2543 2545 2553 2554 2555 2556 This type is extended by other (non-mixed) component types to 2557 allow attributes from other namespaces. 2558 2559 2560 2561 2562 2564 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2589 2590 2591 2593 2594 2595 2597 2599 2607 2609 2610 2611 2612 2613 2615 2617 2619 2621 2623 2625 2626 2627 2629 2631 2632 2633 2635 2637 2639 2640 2641 2642 2643 2645 2647 2649 2651 2652 2654 2655 2657 2658 2659 2661 2663 2665 2666 2667 2668 2669 2671 2672 2674 2675 2676 2678 2681 2689 2690 2691 2692 2693 2695 2697 2698 2700 2702 2703 2704 2706 2708 2709 2710 2711 2712 2714 2716 2717 2719 2721 2722 2723 2725 2727 2728 2729 2730 2731 2733 2735 2736 2738 2740 2741 2742 2744 2746 2754 2755 2756 2757 2758 2759 2761 2763 2765 2768 2769 2770 2771 2772 2774 2776 2777 2778 2779 2780 2782 2784 2785 2787 2788 2789 2791 2794 2795 2796 2797 2798 2800 2801 2802 2803 2804 2806 2808 2809 2810 2811 2812 2815 2816 2818 2819 2821 2823 2824 2825 2827 2829 2831 2832 2833 2834 2835 2837 2838 2840 2842 2843 2844 2845 2847 2849 2850 2851 2852 2853 2855 2856 2858 2859 2860 2861 2862 2864 2866 2867 2868 2869 2870 2872 2874 2875 2876 2877 2879 2881 2882 2883 2884 2885 2887 2888 2890 2891 2892 2894 2897 2898 2899 2900 2901 2903 2905 2907 2909 2911 2912 2914 2915 2917 2918 2919 2921 2923 2924 2925 2926 2927 2929 2930 2932 2933 2934 2935 2937 2939 2940 2941 2942 2943 2945 2946 2948 2949 2951 2953 2955 2956 2957 2958 2960 2962 2963 2964 2965 2967 2969 2970 2971 2972 2973 2975 2976 2978 2980 2981 2982 2984 2986 2988 2989 2990 2991 2992 2994 2995 2998 3000 3002 3003 3004 3006 3008 3010 3011 3012 3013 3014 3016 3018 3019 3020 3021 3023 3025 3026 3028 3029 3030 3032 3033 3035 3036 3038 3040 3041 3042 3043 3044 3046 3047 3049 3051 3052 3053 3054 3056 3058 3059 3060 3061 3062 3064 3066 3068 3069 3071 3072 3073 3074 3076 3078 3080 3081 3082 3083 3084 3086 3088 3090 3091 3093 3094 3096 3098 3100 3101 3102 3103 3104 3106 3107 3109 3111 3112 3113 3115 3117 3119 3120 3121 3122 3123 3125 3127 3129 3131 3132 3134 3135 3136 3138 3139 3141 3142 3143 3144 3145 3147 3149 3150 3151 3152 3154 3156 3158 3159 3160 3161 3162 3164 3165 3167 3168 3169 3171 3173 3175 3176 3177 3178 3179 3181 3183 3184 3185 3186 3187 3189 3191 3192 3193 3194 3195 3197 3199 3200 3201 3202 3204 3206 3208 3209 3210 3211 3212 3214 3216 3218 3219 3220 3221 3223 3225 3227 3228 3229 3231 3232 3233 3234 3235 3236 3237 3239 3241 3242 3243 3244 3246 3248 3249 3250 3251 3252 3254 3255 3256 3258 3259 3261 3263 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3282 3283 3284 3285 3286 3287 3289 3290 3291 3293 3294 3295 3297 3298 3299 3300 3301 3303 3304 3305 3306 3307 3308 3309 3310 3312 3313 3314 3315 3316 3317 3319 3320 3321 3322 3323 3324 3325 3326 3327 3329 3330 3331 3332 3333 3334 3335 3337 3339 Figure 10: Mixer Package XML Schema 3341 6. Examples 3343 This section provides examples of the Mixer Control package. 3345 6.1. AS-MS Framework Interaction Examples 3347 The following example assume a control channel has been established 3348 and synced as described in the Media Control Channel Framework 3349 ([I-D.ietf-mediactrl-sip-control-framework]). 3351 The XML messages are in angled brackets (with the root and 3352 other details omitted for clarity); the REPORT status is in round 3353 brackets. Other aspects of the protocol are omitted for readability. 3355 6.1.1. Creating a conference mixer and joining a participant 3357 A conference mixer is created successfully and a participant is 3358 joined. 3360 Application Server (AS) Media Server (MS) 3361 | | 3362 | (1) CONTROL: | 3363 | ----------------------------------------> | 3364 | | 3365 | (2) 202 | 3366 | <--------------------------------------- | 3367 | | 3368 | | 3369 | (3) REPORT: | 3370 | (terminate) | 3371 | <---------------------------------------- | 3372 | | 3373 | (4) 200 | 3374 | ----------------------------------------> | 3375 | | 3376 | (5) CONTROL: | 3377 | ----------------------------------------> | 3378 | | 3379 | (6) 202 | 3380 | <--------------------------------------- | 3381 | | 3382 | (7) REPORT: | 3383 | (terminate) | 3384 | <---------------------------------------- | 3385 | | 3386 | (8) 200 | 3387 | ----------------------------------------> | 3389 6.1.2. Receiving active talker notifications 3391 An active talker notification event is sent by the MS. 3393 Application Server (AS) Media Server (MS) 3394 | | 3395 | (1) CONTROL: | 3396 | <--------------------------------------- | 3397 | | 3398 | (4) 200 | 3399 | ----------------------------------------> | 3400 | | 3402 6.1.3. Conference termination 3404 The MS receives a request to terminate the conference, resulting in 3405 conferenceexit and participant unjoined notifications. 3407 Application Server (AS) Media Server (MS) 3408 | | 3409 | (1) CONTROL: | 3410 | ----------------------------------------> | 3411 | | 3412 | (2) 200: | 3413 | <--------------------------------------- | 3414 | | 3415 | (3) CONTROL: | 3416 | (unjoin-notify) | 3417 | <---------------------------------------- | 3418 | | 3419 | (4) 200 | 3420 | ----------------------------------------> | 3421 | | 3422 | (5) CONTROL: | 3423 | (conferenceexit) | 3424 | <---------------------------------------- | 3425 | | 3426 | (6) 200 | 3427 | ----------------------------------------> | 3429 6.2. Mixing Examples 3431 The following examples show how the mixing package can be used to 3432 create audio conferences, bridge connections and video conferences. 3434 The examples do not specify all messages between the AS and MS. 3436 6.2.1. Audio conferencing 3438 The AS sends a request to create a conference mixer: 3440 3441 3443 3444 3445 3446 3447 3448 3450 The request specifies that the conference is assigned the conference 3451 id "conf1" and is configured with 2 reserved talkers, 3 reserved 3452 listener slots, audio mixing policy set to nbest and with active 3453 talkers notifications set to 5 seconds. 3455 If the MS is able to create this conference mixer, it sends 200 3456 response: 3458 3459 3461 3463 The AS is now able to join connections to the conference as 3464 participants. A participant able to contribute to the audio mix 3465 would be joined as follows: 3467 3468 3469 3470 3471 3473 If the MS can join the participant 1536067209:913cd14c to the 3474 conference conf1 with audio in both directions, then it sends a 3475 successful response: 3477 3478 3479 3481 The AS could also join listener-only participants to the conference 3482 by setting the stream direction to receive only: 3484 3485 3486 3487 3488 3490 If the MS can join the participant 9936067209:914cd14c to the 3491 conference conf1 then it would send a successful response (not 3492 shown). 3494 As the active talker changes, the MS sends an active talker 3495 notification to the AS: 3497 3498 3499 3500 3501 3502 3503 3505 The AS could decide to change the status of a talker connection so 3506 that they can only listen: 3508 3509 3510 3511 3512 3514 Where the participant 1536067209:913cd14c is no longer able to 3515 contribute to the audio mix on the conference. If the MS is able to 3516 execute this request, it would send a 200 response. 3518 The AS could decide to remove this participant from the conference: 3520 3521 3522 3524 Again, if the MS can execute this request, a 200 response would be 3525 sent. 3527 Finally, the AS terminates the conference: 3529 3530 3531 3532 If the MS is able to destroy the conference conf1, it sends a 200 3533 response: 3535 3536 3537 3539 For each participant attached to the conference when it is destroyed, 3540 the MS sends an unjoin notification event: 3542 3543 3544 3546 3547 3549 And the MS sends a conferenceexit notification event when the 3550 conference finally exits: 3552 3553 3554 3555 3556 3558 6.2.2. Bridging connections 3560 The mixer package can be used to join connections to one another. In 3561 a call center scenario, for example, this package can be used to set 3562 up and modify connections between a caller, agent and supervisor. 3564 A caller is joined to an agent with bi-directional audio: 3566 3567 3568 3569 3570 3572 If the MS is able to establish this connection, then it would send a 3573 200 response: 3575 3576 3577 3579 Now assume that the AS wants a supervisor to listen into the agent 3580 conversation with the caller and provide whispered guidance to the 3581 agent. First the AS would send a request to join the supervisor and 3582 the caller connections: 3584 3585 3586 3587 3588 3590 If this request was successful, audio output from the caller 3591 connection would now be sent to both the agent and the supervisor. 3593 Second, the AS would send a request to join the supervisor and the 3594 agent connections: 3596 3597 3598 3599 3600 3602 If this request was successful, the audio mixing would occur on both 3603 the agent and supervisor connections: the agent would hear the caller 3604 and supervisor, and the supervisor would hear the agent and caller. 3605 The caller would only hear the agent. If the MS is unable to join 3606 and mix connections in this way, it would send a 426 response. 3608 6.2.3. Video conferencing 3610 In this example, an audio video-conference is created with the 3611 loudest participant has the most prominent region in the video 3612 layout. 3614 The AS sends a request to create an audio-video conference: 3616 3617 3618 3619 3620 3621 single-view 3622 dual-view 3623 quad-view 3624 multiple-5x1 3625 3626 3627 3628 In this configuration, the conference uses a nbest audio mixing 3629 policy and a vas video switch policy, so that the loudest speaker 3630 receives the most prominent region in the layout. Multiple video 3631 layouts are specified and active one depends on the number of 3632 participants. 3634 Assume that 4 participants are already joined to the conference. In 3635 that case, the video layout will be quad-view (Figure 6) with the 3636 most active speaker displayed in region 1. When a fifth participant 3637 joins, the video layout automatically switches to a multiple-5x1 3638 layout (Figure 9), again with the most active speaker in region 1. 3640 The AS can manipulate which participants are displayed in the 3641 remaining regions. For example, it could force an existing 3642 conference participant to be displayed in region 2: 3644 3645 3646 3647 2 3648 3649 3650 3652 7. Security Considerations 3654 As this control package processes XML markup, implementations MUST 3655 address the security considerations of [RFC3023]. 3657 As a Control Package of the Media Control Channel Framework, 3658 security, confidentiality and integrity of messages transported over 3659 the control channel MUST be addressed as described in Section 12 of 3660 the Media Control channel Framework 3661 ([I-D.ietf-mediactrl-sip-control-framework]), including Transport 3662 Level Protection, Control Channel Policy Management and Session 3663 Establishment. In addition, implementations MUST address security, 3664 confidentiality and integrity of User Agent sessions with the MS, 3665 both in terms of SIP signaling and associated RTP media flow; see 3666 [I-D.ietf-mediactrl-sip-control-framework] for further details on 3667 this topic. 3669 Adequate transport protection and authentication are critical, 3670 especially when the implementation is deployed in open networks. If 3671 the implementation fails to correctly address these issues, it risks 3672 exposure to malicious attacks, including (but not limited to): 3674 Denial of Service: An attacker could insert a request message into 3675 the transport stream causing specific conferences or join mixers 3676 on the MS to be destroyed. For example, , where the value of "XXXX" could be guessed 3678 or discovered by auditing active mixers on the MS using an 3679 request. Likewise, an attacker could impersonate the MS and 3680 insert error responses into the transport stream so denying the AS 3681 access to package capabilities. 3683 Resource Exhaustion: An attacker could insert into the control 3684 channel new request messages (or modify existing ones) with, for 3685 instance, elements causing large numbers of 3686 conference mixer resources to be allocated. At some point this 3687 will exhaust the number of conference mixers that the MS is able 3688 to allocate. 3690 The Media Control Channel Framework permits additional policy 3691 management, including resource access and control channel usage, to 3692 be specified at the control package level beyond that specified for 3693 the Media Control Channel Framework (see Section 12.3 of 3694 [I-D.ietf-mediactrl-sip-control-framework]). 3696 Since creation of conference and join mixers is associated with media 3697 mixing resources on the MS, the security policy for this control 3698 package needs to address how such mixers are securely managed across 3699 more than one control channel. Such a security policy is only useful 3700 for secure, confidential and integrity protected channels. The 3701 identity of control channels is determined by the channel identifier: 3702 i.e. the value of the cfw-id attribute in the SDP and Dialog-ID 3703 header in the channel protocol (see 3704 [I-D.ietf-mediactrl-sip-control-framework]). Channels are the same 3705 if they have the same identifier; otherwise, they are different. 3706 This control package imposes the following additional security 3707 policies: 3709 Responses: The MS MUST only send a response to a mixer management or 3710 audit request using the same control channel as the one used to 3711 send the request. 3713 Notifications: The MS MUST only send notification events for 3714 conference and join mixers using the same control channel as it 3715 received the request creating the mixer. 3717 Auditing: The MS MUST only provide audit information about 3718 conference and join mixers which have been created on the same 3719 control channel as the one upon the request is sent. For 3720 example, if a join between two connections has been created on one 3721 channel, then a request on another channel to audit all mixers - 3722 - would not report on this join mixer. 3724 Rejection: The MS SHOULD reject requests to audit or manipulate an 3725 existing conference or join mixer on the MS if the channel is not 3726 the same as the one used when the mixer was created. The MS 3727 rejects a request by sending a Control Framework 403 response (see 3728 Section 7.4 and Section 12.3 of 3729 [I-D.ietf-mediactrl-sip-control-framework]). For example, if a 3730 channel with identifier 'cfw1234' has been used to send a request 3731 to create a particular conference and the MS receives on channel 3732 'cfw98969' a request to audit or destroy this particular 3733 conference, then the MS sends a 403 framework response. 3735 There can be valid reasons why an implementation does not reject an 3736 audit or mixer manipulation request on a different channel from the 3737 one which created the mixer. For example, a system administrator 3738 might require a separate channel to audit mixer resources created by 3739 system users and to terminate mixers consuming excessive system 3740 resources. Alternatively, a system monitor or resource broker might 3741 require a separate channel to audit mixers managed by this package on 3742 a MS. However, the full implications need to be understood by the 3743 implementation and carefully weighted before accepting these reasons 3744 as valid. If the reasons are not valid in their particular 3745 circumstances, the MS rejects such requests. 3747 There can also be valid reasons for 'channel handover' including high 3748 availability support or where one AS needs to take over management of 3749 mixers after the AS which created them has failed. This could be 3750 achieved by the control channels using the same channel identifier, 3751 one after another. For example, assume a channel is created with the 3752 identifier 'cfw1234' and the channel is used to create mixers on the 3753 MS. This channel (and associated SIP dialog) then terminates due to 3754 a failure on the AS. As permitted by the Control Framework, the 3755 channel identifier 'cfw1234' could then be reused so that another 3756 channel is created with the same identifier 'cfw1234', allowing it to 3757 'take over' management of the mixers on the MS. Again, the 3758 implementation needs to understand the full implications and 3759 carefully weight them before accepting these reasons as valid. If 3760 the reasons are not valid for their particular circumstances, the MS 3761 uses the appropriate SIP mechanisms to prevent session establishment 3762 when the same channel identifier is used in setting up another 3763 control channel (see Section 4 of 3764 [I-D.ietf-mediactrl-sip-control-framework]). 3766 8. IANA Considerations 3768 This specification instructs IANA to register a new Media Control 3769 Channel Framework Package, a new XML namespace, a new XML schema and 3770 a new MIME type. 3772 8.1. Control Package Registration 3774 This section registers a new Media Control Channel Framework package, 3775 per the instructions in Section 12.1 of 3776 [I-D.ietf-mediactrl-sip-control-framework]. 3778 To: ietf-sip-control@iana.org 3779 Subject: Registration of new Channel Framework package 3780 Package Name: msc-mixer/1.0 3781 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 3782 with the RFC number for this specification.] 3783 Published Specification(s): RFCXXXX 3784 Person & email address to contact for further information: 3785 IETF, MEDIACTRL working group, (mediactrl@ietf.org), 3786 Scott McGlashan (smcg.stds01@mcglashan.org). 3788 8.2. URN Sub-Namespace Registration 3790 This section registers a new XML namespace, 3791 "urn:ietf:params:xml:ns:msc-mixer", per the guidelines in RFC 3688 3792 [RFC3688]. 3794 URI: urn:ietf:params:xml:ns:msc-mixer 3795 Registrant Contact: IETF, MEDIACTRL working group, 3796 (mediactrl@ietf.org), Scott McGlashan 3797 (smcg.stds01@mcglashan.org). 3798 XML: 3799 BEGIN 3800 3801 3803 3804 3805 Media Control Channel Framework Mixer 3806 Package attributes 3807 3808 3809

Namespace for Media Control Channel 3810 Framework Mixer Package attributes

3811

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

3812 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 3813 with the RFC number for this specification.] 3814

See RFCXXXX

3815 3816 3817 END 3819 8.3. XML Schema Registration 3821 This section registers an XML schema as per the guidelines in RFC 3822 3688 [RFC3688]. 3824 URI: urn:ietf:params:xml:ns:msc-mixer 3825 Registrant Contact: IETF, MEDIACTRL working group, 3826 (mediactrl@ietf.org), Scott McGlashan 3827 (smcg.stds01@mcglashan.org). 3828 Schema: The XML for this schema can be found in 3829 Section 5 of this document. 3831 8.4. MIME Media Type Registration for 'application/msc-mixer+xml' 3833 This section registers the "application/msc-mixer+xml" MIME type. 3835 To: ietf-types@iana.org 3836 Subject: Registration of MIME media type 3837 application/msc-mixer+xml 3838 MIME media type name: application 3839 MIME subtype name: msc-mixer+xml 3840 Required parameters: (none) 3841 Optional parameters: charset 3842 Indicates the character encoding of enclosed XML. Default is 3843 UTF-8. 3844 Encoding considerations: Uses XML, which can employ 8-bit 3845 characters, depending on the character encoding used. See RFC 3846 3023 [RFC3023], section 3.2. 3847 Security considerations: No known security considerations outside 3848 of those provided by the Media Control Channel Framework Mixer 3849 Package. 3850 Interoperability considerations: This content type provides 3851 constructs for the Media Control Channel Framework Mixer package. 3852 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please 3853 replace XXXX with the RFC number for this specification.] 3854 Applications which use this media type: Implementations of 3855 the Media Control Channel Framework Mixer package. 3856 Additional Information: Magic Number(s): (none) 3857 File extension(s): (none) 3858 Macintosh File Type Code(s): (none) 3859 Person & email address to contact for further information: Scott 3860 McGlashan 3861 Intended usage: LIMITED USE 3862 Author/Change controller: The IETF 3863 Other information: None. 3865 9. Change Summary 3867 Note to RFC Editor: Please remove this whole section. 3869 The following are the changes between the -11 and -10 versions 3870 (addressing IETF Last Call comments): 3872 o 4.2.2.3: For , removed the statement "It MUST NOT 3873 change the configuration of any streams not included as child 3874 elements." since modifications in stream directionality can affect 3875 other streams of the same type. 3877 o 4.2.2.5.2: Changed definition of tones attribute of 3878 element so that if the element is specified, then all DTMF tones 3879 are clamped by default. Updated XML schema. 3881 o 7: Corrected references from Section 11 to Section 12 in Control 3882 Framework. 3884 o Fixed various typos. 3886 The following are the changes between the -10 and -09 versions: 3888 o References: Moved the XCON reference to the Normative References 3889 section. 3891 o 4.2: Mixer Elements: clarified that when a requested mixer 3892 operation (partially) fails, the MS carries out no part of the 3893 operation and sends an error response. 3895 The following are the changes between the -09 and -08 versions 3896 following shepherd writeup: 3898 o 4.2.4.1.1: : Removed the statement that it is an 3899 error if an element has both connectionid and 3900 conferenceid attributes specified because the AS always sends a 3901 framework 200 in response to notification events, including active 3902 talker events. Instead, clarified that no active talker is 3903 described if both attributes are specified or if neither attribute 3904 is specified. 3906 o Various spelling and grammatical errors fixed. 3908 The following are the changes between the -08 and -07 versions. 3910 o 8.4: Changed file extension from '.xml' to (none) 3911 o Changed "~" to a ":" for connectionid 3913 o 4.2.6.1: Clarified that can contain an XML value. 3915 o 4.2.4.2: Changed status codes so that only 0-2 3916 defined and all others are reserved for future use requiring a 3917 standard-track RFC. 3919 o 4.2.4.3: Changed status codes so that only 0-2 3920 defined and all others are reserved for future use requiring a 3921 standard-track RFC. 3923 o 4.5: Changed status code for and so 3924 that certain codes are defined and all others are reserved for 3925 future use requiring a standard-track RFC. 3927 The following are the changes between the -07 and -06 versions. 3929 o Generally corrected references from Section 17.1 to Section 16.1 3930 of Control Channel Framework. 3932 o 4.2.2.2: removed "is" in "unless this is leads to a stream 3933 conflict" 3935 o 4.2.2.3: corrected error code from 408 to 409 for "If the 3936 specified entities are not already joined, then the MS reports an 3937 error (408)." 3939 o 4.2.1.4.3: corrected error code from 409 to 424 for "If the MS 3940 does not support the specified video switching policy or ..., then 3941 MS reports a 409 error". 3943 o 4.2.1.4.2: corrected error code from 408 to 423 for "If the MS 3944 does not support video conferencing at all, or ...., the MS 3945 reports an 408 error ..." 3947 o 4.2.1.1, 4.2.1.2, 4.2.2.2, 4.2.2.3: Clarified that 3948 specified in or impose a 3949 limitation in the media capability of a conference and this 3950 limitation affects whether the conference can be or 3951 ed to another entity. 3953 The following are the changes between the -06 and -05 versions. 3955 o 4.4.1: : corrected typos, added an example of 3956 usage, added a section and moved the section 3957 inside this section. 3959 o 8: IANA Considerations: Updated IANA registration information and 3960 added registration for the XML Schema 3962 The following are the changes between the -05 and -04 versions. 3964 o Schema: Fixed problem with non-deterministic content models. 3966 o 7. Security Considerations: Added requirement that 3967 implementations need to secure SIP and RTP sessions with User 3968 Agents. 3970 The following are the changes between the -04 and -03 versions. 3972 o 4.2.1.4.3: corrected typo 3974 o 4.2.2.3: Clarified the behavior of for cases where 3975 each direction of a stream is independently controlled. 3977 o 4.2.2.5: Corrected syntax error in examples. 3979 o 4.2.2.5.1: Clarified that when an audio stream is in the muted 3980 state, then a automatic or setgain control causes the 3981 state to change automatically to unmuted. 3983 o 7 Security: Clarified that both conference and join mixers are 3984 covered by the package security policies. 3986 o 7 Security: Added a denial of service example where the attacker 3987 impersonates the MS. 3989 o 7 Security: Clarified that the package security policy for 3990 multiple channels is only useful if the channels themselves are 3991 secured. 3993 o Updated acknowledgements. 3995 The following are the major changes between the -03 and -02 versions. 3997 o Corrected various typos and nits. 3999 o Conformance language: Removed unnecessary MUSTs, especially for 4000 error codes. Changed most RECOMMENDEDs to MUST or MAY. Removed 4001 lowercase 'should', 'must' and 'may'. 4003 o Tidied up Abstract 4005 o Removed old Introduction section (it just duplicated the 4006 abstract). Replaced it with the old Overview Section. Section 4007 numbering changed! 4009 o Introduction: Clarified which MediaCtrl Requirements are satisfied 4010 by this package. 4012 o 4.2.1.1: : Clarified that an attempt to create a 4013 conference with an identifier already used by an existing 4014 conference does not affect the existing conference (405 error 4015 response). 4017 o 4.2.1.4.1: : Added a 'n' attribute for the number of 4018 participants to be included in nbest audio mixing. 4020 o 4.2.1.4.3: : Clarified that the active speaker in 4021 video switching is the loudest speaker. 4023 o 4.2.1.4.4: : Clarified that if a subscription specified 4024 in a foreign namespace element or attribute is not supported by 4025 the MS, then the MS generates a 428 error response. Changed 4026 conformance support for from SHOULD to MUST. 4027 Removed 422 error response. 4029 o 4.2.2: Joining Elements: Added text to the empty section. 4031 o 4.2.2.2, 4.2.2.3, 4.2.2.4: , and : 4032 Clarified that join operation failures do not affect existing 4033 stream properties of the entities (407 and new 422 error 4034 response). Clarified stream failure errors in and 4035 . 4037 o 4.2.2.2: . Clarified that elements can be used to 4038 independently control properties of the media flow in different 4039 directions. Added a response code (422) for when the MS does not 4040 support a media stream configuation. 4042 o 4.2.2.2: . Clarified that error responses are generated if 4043 id1 or id2 reference a conference or connection which does not 4044 exist. Added an error status code (412) for non-existant 4045 connections. 4047 o 4.2.2.5: : Changed the definition so that in each child 4048 element, the media stream affected is indicated by the value of 4049 the direction attribute of the parent element. Added examples of 4050 controlling the media flow properties. 4052 o 4.2.4.2: . Added reserved range of status codes. 4053 Changed code from 1 to 0 for the unjoin case. Changed code from 3 4054 to 1 for execution error. 4056 o 4.2.4.3: . Added reserved range of status codes. 4057 Changed code from 1 to 0 for the destroyconference case (align 4058 with IVR). Added a code for conference exiting due to exceeding 4059 its maximum duration. 4061 o Schema: Adding missing version attribute on . 4063 o Security Considerations: Major update. Added examples showing 4064 malicious attacks when channel security is not correctly 4065 addressed. Added more details on multiple channel cases including 4066 administrator and monitor channels as well as channel handover. 4068 o Removed affliations in Contributors section. 4070 The following are the major changes between the -02 and -01 versions. 4072 o Section 4: Aligned Control Package definitions with requirements 4073 in Section 8 of the Control Framework. 4075 o Following October Interim meeting discussion on response codes, 4076 generally clarified usage of error status codes, modified some 4077 codes and re-organized the response codes section (Section 4.5) 4078 with more guidance and details. 4080 o MIXER-006. No action required following October 2008 interim 4081 discussion. 4083 o MIXER-008. No action required following October 2008 interim 4084 discussion. 4086 o MIXER-009. No action required for control package - addressed in 4087 -05 framework draft following interim October 2008 discussion. 4089 o MIXER-010/5.2.2.5: Clarified that in the element, an 4090 "inactive" direction value indicates the stream is established but 4091 there is no media flow. Such a stream can be manipulated by 4092 and . 4094 o 5.2.2.5: : Clarified that the media stream specified in 4095 child elements , , and is the 4096 stream originating from the entity identified as id1. 4098 o 5.2.1.4.3: : Clarified that it is not an error if a 4099 specifies a region which is not defined for the currently 4100 active video layout. 4102 o 5.2.1.4.2.1: : Added descriptions and ASCII art for 4103 layout and regions of XCON video layouts. 4105 o Added examples of audio conferencing, connection bridging and 4106 video conferencing. 4108 The following are the major changes between the -01 and -00 versions. 4110 o [MIXER-001]/5.2.4.3: Added notification event. 4112 o [MIXER-003]/5.2.1.4.2.1: Added ASCII diagrams for video layouts. 4114 o [MIXER-004]/5.3.2.2.1: Added active information to 4115 . 4117 o [MIXER-007]/5.4.1: Added inside so additional 4118 codec information can be specified. 4120 o 5.2.1.1: Fixed example with missing min- 4121 participants attributes. 4123 o 5: Changed handling of unsupported foreign namespace elements and 4124 attributes. The MS send a 427 error response if it encounters 4125 foreign elements and attributes it does not support. 4127 o 5.2.1.4.3: . Clarified that the VAS policy is 4128 implementation-specific if a participant provides more than one 4129 audio stream. 4131 o 5.2.2.2/5.2.2.3/5.2.2.4: Clarified that joining behavior so that 4132 streams which have previously been ed or ed 4133 are not affected by a general . 4135 o 5.2.1.4.3: : Added support for whether active 4136 speaker is displayed on their video layout ('activespeakermix' 4137 attribute) and clarified that personal video mixes are out of 4138 scope for this package. 4140 o 5.2.1.4.3/5.2.2.5.4: : Added support for a priority 4141 mechanism in video switching policy and a . 4144 o 8:Updated security section 4146 o 13:Updated references 4148 o 5.2.1.4.4.1: Added default of 3 seconds for 4149 interval. 4151 o 5.2.2.5.1: controltype attribute set to mandatory. 4153 o Updated schema 4155 The following are the major changes between the -00 of this work 4156 group item draft and the individual submission -04 version. 4158 o Control package name is now 'msc-mixer/1.0'. Namespace is now 4159 'urn:ietf:params:xml:ns:msc-mixer'. Mime type is now 4160 'application/msc-mixer+xml'. 4162 o Added XML root element . 4164 o Editorial tidy up of sections. 4166 o Added audit request/response elements. 4168 o Added video layout and switching conference configuration. 4170 o : changed 'mix-type' attribute to 'type' 4171 (consistency with video-switch) 4173 o Added "inactive" as value of 's direction attribute. 4175 o Added child to element. 4177 o : element is no longer mandatory; 4178 added and child elements. reserved- 4179 talkers and reserved-listeners as attributes. 4181 o replaced conf-id attribute with conferenceid attribute. 4183 o Removed element. Active talkers subscription and 4184 notifications used dedicated elements now. 4186 o Added notification event to indicate when 4187 (un)expected joins occur. Use case: connection or conference 4188 joined to a conference and conference exits (either by request or 4189 runtime error. 4191 The following are the major changes between the -04 of the draft and 4192 the -03 version. 4194 o Updated reference for Media Control Channel Framework 4196 The following are the major changes between the -03 of the draft and 4197 the -02 version. 4199 o None 4200 The following are the major changes between the -02 of the draft and 4201 the -01 version. 4203 o clarified the model for join operations and introduced several new 4204 package error codes 4206 o added definition for MS connection 4208 The following are the major changes between the -01 of the draft and 4209 the -00 version. 4211 o restructured into single request response model for non-trivial 4212 operations 4214 o aligned with XML structure of other control framework packages 4216 10. Contributors 4218 Asher Shiratzky provided valuable support and contributions to early 4219 versions of this document. 4221 The authors would like to thank the Mixer design team consisting of 4222 Roni Even, Lorenzo Miniero, Adnan Saleem, Diego Besprosvan and Mary 4223 Barnes who provided valuable feedback, input, diagrams and text to 4224 this document. 4226 11. Acknowledgments 4228 The authors would like to thank Roni Even, Lorenzo Miniero, Steve 4229 Buko and Stephane Bastien for expert reviews of this work. 4231 Shawn Emery carried out a thorough security review. 4233 12. References 4235 12.1. Normative References 4237 [I-D.ietf-mediactrl-sip-control-framework] 4238 Boulton, C., Melanchuk, T., and S. McGlashan, "Media 4239 Control Channel Framework", 4240 draft-ietf-mediactrl-sip-control-framework-11 (work in 4241 progress), October 2009. 4243 [I-D.ietf-xcon-common-data-model] 4244 Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 4245 "Conference Information Data Model for Centralized 4246 Conferencing (XCON)", draft-ietf-xcon-common-data-model-18 4247 (work in progress), February 2010. 4249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4250 Requirement Levels", BCP 14, RFC 2119, March 1997. 4252 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 4253 Types", RFC 3023, January 2001. 4255 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4256 January 2004. 4258 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 4259 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 4261 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E., 4262 and F. Yergeau, "Extensible Markup Language (XML) 1.0 4263 (Third Edition)", W3C Recommendation, February 2004. 4265 12.2. Informative References 4267 [IANA] "IANA registry for RTP Payload Types", 4268 . 4270 [MIME.mediatypes] 4271 "IANA registry for MIME Media Types", 4272 . 4274 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4275 A., Peterson, J., Sparks, R., Handley, M., and E. 4276 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4277 June 2002. 4279 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 4280 Jacobson, "RTP: A Transport Protocol for Real-Time 4281 Applications", STD 64, RFC 3550, July 2003. 4283 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 4284 Formats", RFC 4855, February 2007. 4286 [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 4287 Control Markup Language (MSCML) and Protocol", RFC 5022, 4288 September 2007. 4290 [RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol 4291 Requirements", RFC 5167, March 2008. 4293 [RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup 4294 Language (MSML)", RFC 5707, February 2010. 4296 Authors' Addresses 4298 Scott McGlashan 4299 Hewlett-Packard 4301 Email: smcg.stds01@mcglashan.org 4303 Tim Melanchuk 4304 Rain Willow Communications 4306 Email: tim.melanchuk@gmail.com 4308 Chris Boulton 4309 NS-Technologies 4311 Email: chris@ns-technologies.com