idnits 2.17.1 draft-boulton-conference-control-package-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1293. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2008) is 5897 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2616' is defined on line 1188, but no explicit reference was found in the text == Unused Reference: 'RFC3262' is defined on line 1197, but no explicit reference was found in the text == Unused Reference: 'RFC3263' is defined on line 1201, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 1205, but no explicit reference was found in the text == Unused Reference: 'RFC3725' is defined on line 1213, but no explicit reference was found in the text == Unused Reference: 'XML' is defined on line 1221, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-mediactrl-sip-control-framework-01 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Boulton 3 Internet-Draft Avaya 4 Intended status: Standards Track T. Melanchuk 5 Expires: August 26, 2008 Rain Willow Communications 6 S. McGlashan 7 Hewlett-Packard 8 A. Shiratzky 9 Radvision 10 February 23, 2008 12 A Conference Control Package for the Media Control Channel Framework 13 draft-boulton-conference-control-package-04 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 26, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document defines a Conference Control Package for the Media 47 Control Channel Framework. This Control Package aims to fulfill 48 Conferencing requirements using the SIP Control Framework. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4. Control Package Definition . . . . . . . . . . . . . . . . . . 7 56 4.1. Control Package Name . . . . . . . . . . . . . . . . . . . 7 57 4.2. Framework Message Usage . . . . . . . . . . . . . . . . . 7 58 4.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 8 59 4.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 8 60 4.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 8 61 5. Element Definitions . . . . . . . . . . . . . . . . . . . . . 9 62 5.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.2. . . . . . . . . . . . . . . . . . . . . 9 64 5.3. . . . . . . . . . . . . . . . . . . . . 12 65 5.4. . . . . . . . . . . . . . . . . . . . 13 66 5.5. . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 5.5.1. Joining Model . . . . . . . . . . . . . . . . . . . . 14 68 5.6. . . . . . . . . . . . . . . . . . . . . . . . 16 69 5.7. . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 5.8. Notifications . . . . . . . . . . . . . . . . . . . . . . 17 71 5.8.1. . . . . . . . . . . . . . . . . . . . . . . . 17 72 5.9. . . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 5.10. . . . . . . . . . . . . . . . . . . . . . . . 18 74 5.11. Conference Configuration . . . . . . . . . . . . . . . . . 19 75 5.11.1. . . . . . . . . . . . . . . . . . . . . 19 76 5.12. Media Streams . . . . . . . . . . . . . . . . . . . . . . 19 77 5.12.1. Configuring Volume . . . . . . . . . . . . . . . . . . 20 78 5.12.2. Configuring Tone Removal . . . . . . . . . . . . . . . 21 79 5.13. Responses . . . . . . . . . . . . . . . . . . . . . . . . 21 80 5.13.1. . . . . . . . . . . . . . . . . . . . . . . 21 81 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 85 9.1. Control Package Registration . . . . . . . . . . . . . . . 31 86 9.2. MIME Registration . . . . . . . . . . . . . . . . . . . . 31 87 9.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 31 88 10. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 32 89 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 91 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 92 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 94 Intellectual Property and Copyright Statements . . . . . . . . . . 37 96 1. Introduction 98 The Media Control Channel Framework 99 [I-D.ietf-mediactrl-sip-control-framework] provides a generic 100 template for establishment and reporting capabilities of remotely 101 initiated commands. The Control Framework also introduces the 102 concept of a Control Package. A Control Package is an explicit usage 103 of the Control Framework for a particular interaction set. This 104 specification defines a package for control of conference instances. 106 2. Conventions and Terminology 108 In this document, BCP 14/RFC 2119 [RFC2119] defines the key words 109 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 110 "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL". In addition, BCP 15 indicates requirement levels for 112 compliant implementations. 114 The following additional terms are defined for use in this document: 116 Application server: A SIP [RFC3261] application server (AS) is a 117 control client that hosts and executes services such as 118 interactive media and conferencing in an operator's network. An 119 AS controls the media server (MS), influencing and impacting the 120 SIP sessions terminating on a media server, which the AS may have 121 established for example using SIP third party call control. 123 Media Server: A media server (MS) processes media streams on behalf 124 of an AS by offering functionality such as interactive media, 125 conferencing, and transcoding to the end user. Interactive media 126 functionality is realized by way of dialogs, which are identified 127 by a URI and initiated by the application server. 129 MS Conference: A MS Conference provides the media related mixing 130 resources and services for conferences. In this document, A MS 131 Conference is often referred to simply as a conference. 133 MS Connection: A Media Server connection represents the termination 134 on a media server of one or more RTP [RFC3550] sessions that are 135 associated to a single SIP dialog. A media server receives media 136 from the output(s) of a connection and it transmits media on the 137 input(s) of a connection. 139 Media Stream: A media stream on a media server represents a media 140 flow between either a connection and a conference, between two 141 connections, or between two conferences. Streams may be audio or 142 video and may be bi-directional or uni-directional. 144 3. Overview 146 The SIP Control Framework [I-D.ietf-mediactrl-sip-control-framework] 147 provides a generic approach for establishment and reporting 148 capabilities of remotely initiated commands. The Framework utilizes 149 many functions provided by the Session Initiation Protocol [RFC3261] 150 (SIP) for the rendezvous and establishment of a reliable channel for 151 control interactions. The Control Framework also introduces the 152 concept of a Control Package. A Control Package is an explicit usage 153 of the Control Framework for a particular interaction set. This 154 specification defines a package for basic conferencing. 156 The scope of the package is control of media server functions for 157 conferencing (e.g. create a conference, add and remove participants 158 from it, etc) as well as responses and notifications related to these 159 functions. Although dialog services such as announcements, 160 recordings, and prompts are generally needed for a complete 161 conference service, those functions are defined in complementary 162 packages. 164 4. Control Package Definition 166 This section fulfils the mandatory requirement for information that 167 MUST be specified during the definition of a Control Framework 168 Package, as detailed in Section 9 of 169 [I-D.ietf-mediactrl-sip-control-framework]. 171 4.1. Control Package Name 173 The Control Framework requires a Control Package definition to 174 specify and register a unique name. The name and version of this 175 Control Package is "msc-conf-audio/1.0" (Media Server Control - 176 Conferencing - Audio - version 1.0). 178 4.2. Framework Message Usage 180 The intent for the Conference Control package is for the creation, 181 manipulation and deletion of conferences as well as joining, 182 manipulation and unjoining of participants to conferences. The 183 Conference Control package is intended for use in an architecture 184 where application logic and media mixing are distributed. For this 185 reason the Control Framework will operate in a manner where CONTROL 186 messages, as defined in the Conference Framework 187 [I-D.ietf-mediactrl-sip-control-framework], MUST only be sent from 188 the network entity providing the application logic. 190 This package defines XML elements in Section 5 and provides an XML 191 Schema in Section 7. 193 The XML elements in this package are split into requests, responses 194 and event notifications. Requests are carried in CONTROL message 195 bodies; and are examples of package 196 requests. See Section 5.1 for a complete enumeration of requests. 197 Responses are carried either in REPORT messages or Control Framework 198 200 response bodies; the element is defined as a package 199 response. Event notifications are also carried in REPORT message 200 bodies; the element is defined for package event 201 notifications. 203 Note that package responses are different from framework response 204 codes. Framework error response codes (see Section 8 of 205 [I-D.ietf-mediactrl-sip-control-framework]) are used when the request 206 or notification is invalid; for example, a request with invalid XML 207 (400), or not understood (500). Package responses are carried in 200 208 response or REPORT message bodies. This package's response codes are 209 defined in Section 5.13.1. 211 The schema uses "connection-id" and "conf-id" attributes which are 212 imported from schema defined in core Control Framework 213 [I-D.ietf-mediactrl-sip-control-framework]. 215 4.3. Common XML Support 217 The Control Framework requires a Control Package definition to 218 specify if the attributes for media dialog or conference references 219 are required. 221 This package requires that the XML Schema in Section 16.1 of 222 [I-D.ietf-mediactrl-sip-control-framework] MUST be supported for 223 media dialogs and conferences. 225 4.4. CONTROL Message Body 227 A valid CONTROL body message MUST conform to the schema defined in 228 Section 7 and described in Section 5. XML messages appearing in 229 CONTROL messages MUST contain , , 230 , , or request 231 elements (Section 5.1). 233 4.5. REPORT Message Body 235 A valid REPORT body MUST conform to the schema defined in Section 7 236 and described in Section 5. XML messages appearing in REPORT 237 messages MUST contain a (Section 5.13), or a 238 (notification) element (Section 5.8). 240 5. Element Definitions 242 This section defines the XML messages for this control package. 244 [Editors Note: since XML Schema may not be able to express all 245 constraints expressed in these definitions, in cases where there is a 246 difference in constraints, the definitions in the section take 247 priority.] 249 5.1. Requests 251 The following request elements are defined: 253 : create and configure a new conference - see 254 Section 5.2 for detail. 256 : modify the configuration of an existing 257 conference - see Section 5.3 for detail. 259 : destroy an existing conference - see 260 Section 5.4 for detail. 262 : create and configure media streams between connections 263 and/or conferences (for example, add a participant to a 264 conference) - see Section 5.5 for detail. 266 : modify the configuration of a joined media stream - 267 see Section 5.6 for detail. 269 : delete a media stream (for example, remove a participant 270 from a conference) - see Section 5.7 for detail. 272 5.2. 274 is used in a request by the AS to create a new 275 conference (multiparty) instance. 277 The element has the following child elements 278 defined: 280 : an element to configure the audio mixing 281 characteristics of a conference (see Section 5.11.1 for more 282 detail). The element is mandatory in a 283 request. 285 : an element to request subscription to conference 286 events. (see Section 5.10 for more detail). The element optional. 288 : element represents the number of guaranteed 289 speaker slots to be reserved for the conference. The element is 290 optional. 292 : element represents the number of guaranteed 293 listener slots to be reserved for the conference. The element is 294 optional. 296 A media server MUST configure the audio mix of a conference as 297 specified by the "" element or it MUST NOT create the 298 conference and MUST report a 405 'Unable to configure audio mix' 299 package level error. A media server must create any subscriptions 300 requested by the ":" element or it MUST NOT create the 301 conference and MUST report a 406 'Unable to create subscription' 302 package level error. A media server MUST establish the reservations 303 requested by any ":" and ":" 304 elements or it MUST NOT create the conference and MUST report a 407 305 'Conference reservation failed' package level error. 307 The element has the following attributes: 309 conf-id: string indicating a unique name for the new conference. If 310 this attribute is not specified, the MS creates a unique name for 311 the conference. The value is used in subsequent references to the 312 conference (e.g. as conf-id in a ). When present in a 313 request the new value of this attribute MUST be 314 unique or else a 403 'Conference already exists' package level 315 error will be reported. The attribute is optional. 317 Conferences SHOULD support subscription to the following events: 319 active-talkers: the list of zero or more speakers that have been 320 active during the previous interval. The input and output 321 parameters for event subscription and notification are given in 322 the following tables. 324 +-----------+-----------+-------------------------+------------+ 325 | Name | Direction | Description | Definition | 326 +-----------+-----------+-------------------------+------------+ 327 | interval | input | minimum interval | Table 2 | 328 | | | | | 329 | speaker | output | an active talker | Table 3 | 330 +-----------+-----------+-------------------------+------------+ 332 Active-Talker Event Parameters 334 +-------------+-----------------------------------------------------+ 335 | Name | Interval | 336 +-------------+-----------------------------------------------------+ 337 | Description | the minimum amount of time (in seconds) that must | 338 | | elapse before further talker-events can be | 339 | | generated | 340 | | | 341 | Direction | input | 342 | | | 343 | Type | A valid TimeDesignation value. | 344 | | | 345 | Optional | No | 346 | | | 347 | Possible | A valid TimeDesignation value. A value is "0" | 348 | Values | suppresses further notifications. | 349 | | | 350 | Default | none | 351 +-------------+-----------------------------------------------------+ 353 Table 2: Interval 355 +-------------+-----------------------------------------------------+ 356 | Name | Speaker | 357 +-------------+-----------------------------------------------------+ 358 | Description | The connection identifier of a speaker that has | 359 | | been active during the preceding interval. | 360 | | | 361 | Direction | output | 362 | | | 363 | Type | a connection identifier: see Section 16.1 of | 364 | | [I-D.ietf-mediactrl-sip-control-framework] | 365 | | | 366 | Optional | No | 367 | | | 368 | Possible | Any connection identifier that is currently a | 369 | Values | member of the conference | 370 | | | 371 | Default | none | 372 +-------------+-----------------------------------------------------+ 374 Table 3: Speaker 376 Subscribing to events is described in Section 5.10 and the 377 notification of events is described in Section 5.8 379 For example, a request to create a conference: 381 382 383 385 When a MS has finished processing a request, it 386 MUST reply with an appropriate element (Section 5.13). 388 5.3. 390 is used by the controlling client to modify 391 properties of an existing conference. 393 The element has the following child elements 394 defined: 396 : an element to configure the conference (see 397 Section 5.11.1 for more detail). The element is optional in a 398 request. 400 : an element to request subscription to conference 401 events. (see Section 5.10 for more detail). The element optional. 403 One or both of the elements and SHOULD be 404 present in a request. 406 A media server MUST configure the audio mix of a conference as 407 specified by any "" element or it MUST NOT modify 408 anything and MUST report a 405 'Unable to configure audio mix' 409 package level error. A media server must create any subscriptions 410 requested by the ":" element or it MUST NOT modify 411 anything and MUST report a 406 'Unable to create subscription' 412 package level error. 414 The element has the following attributes: 416 conf-id: string indicating the name of the conference to modify. 417 The conference MUST be known by the receiving entity or else a 404 418 'Conference does not exist' package level error will be generated. 419 This attribute is mandatory. 421 When a MS has finished processing a request, it 422 MUST reply with an appropriate element (Section 5.13). 424 [Editors Note: TODO - need to cover who to respond if modify is not 425 successful] 427 5.4. 429 is used by the controlling client to destroy an 430 existing conference. 432 The element does not specify any child elements. 434 The element has the following attributes: 436 conf-id: string indicating the name of the conference to destroy. 437 The conference MUST be known by the receiving entity or else a 404 438 'Conference does not exist' package level error will be generated. 439 This attribute is mandatory. 441 When a MS has finished processing a request, it 442 MUST reply with an appropriate element (Section 5.13). 443 Successfully destroying the conference will result in a 200 package 444 level response to the request. Package level error responses do not 445 result in the conference being destroyed. 447 5.5. 449 is used by the controlling AS to create one or more media 450 streams either between a connection and a conference, between 451 connections, or between conferences. Streams may be audio or video 452 and may be bi-directional or uni-directional. A bi-directional 453 stream is implicitly composed of two uni-directional streams that can 454 be manipulated independently. The streams to be established are 455 specified by child elements (see Section 5.12). 457 A MS MUST support ing a participant connection to a conference. 458 It MAY support ing one connection to another connection, or one 459 conference to another conference. 461 Connections are created and destroyed on a media server using the 462 Session Initiation Protocol [RFC3261] (SIP). 464 The element has the following child elements defined: 466 : an element that both identifies the media streams to join 467 and defines the way that they are to be joined (see Section 5.12). 468 The element is optional. If no elements are specified, 469 then the default is the media configuration of the connection or 470 conference. 472 One or more elements may be specified so that individual 473 media streams can be controlled independently; for example, audio 474 only for transmission, but video only for reception. It is an error 475 if a element is in conflict with (a) another 476 element, (b) with dialog, connection or conference media 477 capabilities, or (c) with a SDP label value as part of the 478 connection-id (see Section 16.1 of 479 [I-D.ietf-mediactrl-sip-control-framework]). 481 The two entities to join are specified by the attributes of . 482 The element has the following attributes: 484 id1: an identifier for either a connection or a conference. The 485 identifier MUST conform to the syntax defined in Section 16.1 of 486 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 487 mandatory. 489 id2: an identifier for either a connection or a conference. The 490 identifier MUST conform to the syntax defined in Section 16.1 of 491 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 492 mandatory. 494 Note: Section 16.1 of [I-D.ietf-mediactrl-sip-control-framework] 495 defines the semantics for a conference identifier but not its syntax. 496 Media server implementations need to distinguish between conferences 497 and connections based upon the values of the "id1" and "id2" 498 attributes. 500 When an controlling client has finished processing a request, 501 it MUST reply with an element (Section 5.13). If the 502 participant is already a member of the conference instance, a xxx 503 package level response should be generated. 505 5.5.1. Joining Model 507 The operation creates a media stream between a connection and 508 a conference, between connections, or between conferences. This sub- 509 section describes the model of conferences and connections and 510 specifies the behaviour for join requests to targets that already 511 have an associated media stream. 513 Conferences support multiple inputs and have resources to mix them 514 together. A media server conference in essence is a mixer that 515 combines media streams. A simple audio mix simply sums its input 516 audio signals to create a single common output. Conferences however 517 use a more complex algorithm so that participants do not hear 518 themselves as part of the mix. That algorithm, sometimes called an 519 n-minus mix, subtracts each participants input signal from the summed 520 input signals, creating a unique output for each contributing 521 participant. Each operation to a conference uses one of the 522 conferences available inputs and/or outputs, to the maximum number of 523 supported participants. 525 A connection is the termination of a RTP session(s) on a media 526 server. It has a single input and output for each media session 527 established by its SIP dialog. The output of a connection may feed 528 several different inputs such as both a conference mix and a 529 recording of that participants audio. 531 Joining two connections which are are not joined to anything else 532 simply creates a media stream from the outputs(s) of one connection 533 to the corresponding inputs(s) of the other connection. It is not 534 necessary to combine media from multiple sources in this case. There 535 are however several common scenarios where combining media from 536 several sources to create a single input to a connection is needed. 538 In the first case, a connection may be receiving media from one 539 source, for example a conference, and it is necessary to play an 540 announcement to the connection so that both the conference audio and 541 announcement can be heard by the conference participant. This is 542 sometimes referred to as a whisper announcement. An alternative to a 543 whisper announcement is to have the announcement pre-empt the 544 conference media. 546 Another common case is the call centre coaching scenario where a 547 supervisor can listen to the conversation between an agent and a 548 customer, and provide hints to the agent, which are not heard by the 549 customer. 551 Both of these cases can be solved by having the controlling AS create 552 one or more conferences for audio mixing and to join and unjoin the 553 media streams as required. A better solution is to have the media 554 server automatically mix media streams that are requested to be 555 joined to a common input when only the simple summing of audio 556 signals as described above is required. This is the case for both 557 the use cases presented above. 559 Automatically mixing streams has several benefits. Conceptually, it 560 is straight forward and simple, requiring no indirect requests on the 561 part of the controlling AS. This increases transport efficiency and 562 reduces the coordination complexity and the latency of the overall 563 operation. Therefore, it is RECOMMENDED that a media server be able 564 to automatically mix at least two audio streams where only the simple 565 summing of signals is required. 567 When a media server receives a request, it MUST automatically 568 mix all of the media streams included in the request with any streams 569 already joined to one of the entities identified in the request, or 570 it MUST fail the request and MUST NOT join any of the streams. A 571 controlling AS MUST use the request for generic 572 conferences where the complex mixing algorithm is required. 574 Specifications which extend this package to handle additional media 575 types such as text or video, MUST define the semantics of the join 576 operation when multiple streams are requested to be joined to a 577 single input, such as that for a connection with a single RTP session 578 per media type. 580 5.6. 582 An AS uses to change the configuration of media 583 stream(s) that were previously established between a connection and a 584 conference, between two connections, or between two conferences. 586 The MS MUST support for any stream that was established 587 using . 589 The element has the following child elements defined: 591 : an element that both identifies the media streams to 592 modify and defines the way that each stream should now be 593 configured (see Section 5.12). The element is mandatory. 595 The element has the following attributes: 597 id1: an identifier for either a connection or a conference. The 598 identifier MUST conform to the syntax defined in Section 16.1 of 599 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 600 mandatory. 602 id2: an identifier for either a connection or a conference. The 603 identifier MUST conform to the syntax defined in Section 16.1 of 604 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 605 mandatory. 607 The media server MUST configure the streams that are included within 608 to that stated by the child elements. It MUST NOT 609 change the configuration of any streams not included as child 610 elements. 612 When an MS has finished processing a request, it MUST 613 reply with an appropriate element (Section 5.13). 615 5.7. 617 An AS uses to remove previously established media stream(s) 618 from between a connection and a conference, between two connections, 619 or between two conferences. 621 The MS MUST support for any stream that was established 622 using . 624 The element has the following child elements defined: 626 : an element that identifies the media stream(s) to remove 627 (see Section 5.12). The element is optional. When not present, 628 all streams between "id1" and "id2" are removed. 630 The element has the following attributes: 632 id1: an identifier for either a connection or a conference. The 633 identifier MUST conform to the syntax defined in Section 16.1 of 634 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 635 mandatory. 637 id2: an identifier for either a connection or a conference. The 638 identifier MUST conform to the syntax defined in Section 16.1 of 639 [I-D.ietf-mediactrl-sip-control-framework] The attribute is 640 mandatory. 642 When an MS has successfully received a request, it MUST 643 reply with a successful element (Section 5.13). If the 644 participant is not identified as a member of the conference instance, 645 a xxx package level response should be generated. 647 5.8. Notifications 649 Event notifications are specified in an element. 651 5.8.1. 653 Conference event notifications are either manual or automatic. 655 Manual event notifications are defined when an controlling client 656 subscribes to notifications for conference events using the 657 element of or . For 658 information on the element, see Section 5.10. 660 Automatic event notifications are defined as part of a Control 661 Package. The controlling client SHOULD NOT subscribe to these event 662 notifications. The MS MUST support these event notifications. This 663 package defines one automatic notification event: "conferenceexit" 664 which indicates that a conference has terminated. Note that this 665 notification is not sent if the conference has been destroyed by the 666 AS using a request. 668 The element has the following attributes: 670 name: string indicating the name of conference event. The string is 671 restricted to a sequence of alphanumeric or "." characters. The 672 attribute is mandatory. 674 conferenceid: string identifying the conference. The attribute is 675 mandatory. 677 The element has the following child element: 679 : an XML data structure (see Section 5.9) to pass additional 680 information about the conference event. The element is optional. 682 5.9. 684 The element is a general container for parameterized data. 686 The element has no attributes, but has the following child 687 elements defined: 689 : contains the following attributes: 691 name: a string indicating the name of the parameter. The 692 attribute is mandatory. 694 value: a string indicating the value of the parameter. Multiple 695 values of a parameters can be specified using space separation. 696 The attribute is mandatory. 698 Multiple elements may be specified. 700 5.10. 702 The element is a container for specifying conference 703 notification events to which a controlling entity subscribes. 704 Notifications of conference events are delivered using the 705 element (see Section 5.8.1). 707 The element has no attributes, but has the following 708 child elements defined: 710 : contains the following attributes: 712 name: a string indicating the name of the event to be notified. 713 The attribute is mandatory. 715 The element may have a child element. 717 Multiple elements may be specified. 719 For example, an AS that wants to subscribe to "active-talker" events 720 but does not want to be notified more frequently than every 3 seconds 721 could include the following as a child of either a 722 or element: 724 725 726 727 728 729 730 732 The MS would use the element to send notifications to the AS. 734 5.11. Conference Configuration 736 The elements in this section are used to establish and modify the 737 configuration of conferences. 739 5.11.1. 741 The element defines the configuration of the 742 conference audio mix. It has no child elements and has the following 743 attributes: 745 mix-type: is a string indicating the audio stream mixing policy. 746 Defined values are: "nbest" (where the N best participant signals 747 are mixed) and "controller" (where the contributing participant(s) 748 is/are selected by the controlling AS via an external floor 749 control protocol). The default value is "nbest". The attribute 750 is optional. 752 5.12. Media Streams 754 , and require the identification and 755 manipulations of media streams. Media streams represent the flow of 756 media between a participant connection and a conference, between two 757 connections, or between two conferences. The element is 758 used (as a child to , and element has the following attributes: 764 media: a string indicating the type of media associated with the 765 stream. It is strongly recommended that the following values are 766 used for common types of media: "audio" for audio media, and 767 "video" for video media. The attribute is mandatory. 769 label: a string indicating the SDP label associated with a media 770 stream ([RFC4574]). The attribute is optional. 772 direction: a string indicating the direction of the media flow 773 between a dialog and its end point conference or connection. 774 Defined values are: "sendrecv" (media can be sent and received), 775 "sendonly" (media can only be sent), and "recvonly" (media can 776 only be received). The default value is "sendrecv". The 777 attribute is optional. 779 When the "media" attribute has a value of "audio", the 780 element has the following child elements defined: 782 : an element to configure the volume or gain of the media 783 stream. The element is optional. 785 : an element to configure filtering and removal of tones from 786 a media stream. The element is optional. 788 5.12.1. Configuring Volume 790 The element is used to configure the volume of an audio 791 media stream. It may be set to a specific gain amount, to 792 automatically adjust the gain to a desired target level, or to mute 793 the volume. 795 The element has no child elements but has the following 796 attributes: 798 controltype: a string indicating the type of volume control to use 799 for the stream. Defined values are: "automatic" (the volume will 800 be adjusted automatically to the level specified by the "value" 801 attribute), "setgain" (use the value of the "value" attribute as a 802 specific gain measured in dB to apply), "setstate" (set the state 803 of the stream to "mute" or "unmute" as specified by the value of 804 the "value" attribute). The attribute is optional. 806 value: a string specifying the amount or state for the volume 807 control defined by the value of the "controltype" attribute. 809 5.12.2. Configuring Tone Removal 811 The element is used to configure whether tones should be 812 filtered and removed from a media stream. 814 The element has no child elements but has the following 815 attributes: 817 tones: A list of the tones to remove. 819 5.13. Responses 821 Responses are specified in a element. 823 5.13.1. 825 Reponses to requests are indicated by a element. 827 The element has following attributes: 829 status: numeric code indicating the response status. The attribute 830 is mandatory. 832 reason: string specifying a reason for the response status. The 833 attribute is optional. 835 conf-id: string identifying the conference (see Section 16.1 of 836 [I-D.ietf-mediactrl-sip-control-framework]). The attribute is 837 optional. 839 connection-id: string identifying the SIP dialog connection (see 840 Section 16.1 of [I-D.ietf-mediactrl-sip-control-framework]). The 841 attribute is optional. 843 The following status codes are defined: 845 +-----------+-------------------------------------------------------+ 846 | code | description | 847 +-----------+-------------------------------------------------------+ 848 | 200 | OK | 849 | | | 850 | 401 | Dialog already exists | 851 | | | 852 | 402 | Dialog does not exist | 853 | | | 854 | 403 | Conference already exists | 855 | | | 856 | 404 | Conference does not exist | 857 | | | 858 | 405 | Unable to configure audio mix | 859 | | | 860 | 406 | Unable to create subscription | 861 | | | 862 | 407 | Conference reservation failed | 863 | | | 864 | 420 | Unable to join requested entities | 865 | | | 866 | 421 | Unable to join - conference full | 867 | | | 868 | 422 | Unable to join - mixing connection inputs not | 869 | | supported | 870 | | | 871 | 450 | Unknown or unsupported element | 872 | | | 873 | 451 | Element required | 874 | | | 875 | 452 | Unknown or unsupported attribute | 876 | | | 877 | 453 | Attribute required | 878 +-----------+-------------------------------------------------------+ 880 Table 4: Status codes 882 [Editors Note: more codes probably need to be defined.] 884 For example, a response when a conference was created successfully: 886 887 Success 888 890 The response if conference creation failed due to the requested 891 conference id already existing: 893 894 Conf already exists 895 897 6. Examples 899 [Editors Note: TODO] 901 7. Formal Syntax 903 [Editors Note: XML schema to be updated.] 905 906 913 914 915 916 917 918 919 920 921 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 943 944 945 947 948 950 952 954 955 956 957 959 960 961 963 964 966 967 968 969 971 972 973 975 976 977 978 980 981 982 983 984 985 986 987 989 990 991 992 993 994 995 996 998 1000 1001 1002 1003 1005 1006 1007 1008 1009 1011 1012 1013 1014 1016 1017 1018 1019 1020 1022 1023 1024 1025 1027 1028 1029 1030 1031 1033 1034 1035 1036 1037 1038 1040 1041 1043 1044 1045 1046 1047 1048 1049 1051 1052 1054 1055 1056 1058 1059 1060 1061 1062 1063 1064 1065 1066 1068 1069 1071 1072 1074 1075 1076 1078 1080 1081 1082 1084 1085 1086 1087 1088 1090 1091 1092 1093 1094 1095 1097 1098 1099 1101 1102 1103 1105 1106 1107 1108 1109 1110 1111 1113 1115 Figure 5: Conference Package XML Schema 1117 8. Security Considerations 1119 Security Considerations to be included in later versions of this 1120 document. 1122 9. IANA Considerations 1124 This document registers a new SIP Control Framework Package, a new 1125 MIME type, and a new XML namespace. 1127 9.1. Control Package Registration 1129 Control Package name: msc-conf-audio/1.0 1131 9.2. MIME Registration 1133 TODO: application/msc-conf+xml 1135 9.3. URN Sub-Namespace Registration 1137 TODO: urn:ietf:params:xml:ns:msc-conf 1139 10. Change Summary 1141 The following are the major changes between the -04 of the draft and 1142 the -03 version. 1144 o Updated reference for Media Control Channel Framework 1146 The following are the major changes between the -03 of the draft and 1147 the -02 version. 1149 o None 1151 The following are the major changes between the -02 of the draft and 1152 the -01 version. 1154 o clarified the model for join operations and introduced several new 1155 package error codes 1157 o added definition for MS connection 1159 The following are the major changes between the -01 of the draft and 1160 the -00 version. 1162 o restructured into single request response model for non-trival 1163 operations 1165 o aligned with XML structure of other control framework packages 1167 11. Acknowledgments 1169 The authors would like to thank Ian Evans from Ubiquity Software for 1170 help in the design of concepts contained in this document. Dave 1171 Burke has contributed valuable review comments. 1173 12. References 1175 12.1. Normative References 1177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1178 Requirement Levels", BCP 14, RFC 2119, March 1997. 1180 12.2. Informative References 1182 [I-D.ietf-mediactrl-sip-control-framework] 1183 Boulton, C., Melanchuk, T., and S. McGlashan, "Media 1184 Control Channel Framework", 1185 draft-ietf-mediactrl-sip-control-framework-01 (work in 1186 progress), February 2008. 1188 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1189 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1190 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1192 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1193 A., Peterson, J., Sparks, R., Handley, M., and E. 1194 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1195 June 2002. 1197 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1198 Provisional Responses in Session Initiation Protocol 1199 (SIP)", RFC 3262, June 2002. 1201 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1202 Protocol (SIP): Locating SIP Servers", RFC 3263, 1203 June 2002. 1205 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1206 with Session Description Protocol (SDP)", RFC 3264, 1207 June 2002. 1209 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1210 Jacobson, "RTP: A Transport Protocol for Real-Time 1211 Applications", STD 64, RFC 3550, July 2003. 1213 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1214 Camarillo, "Best Current Practices for Third Party Call 1215 Control (3pcc) in the Session Initiation Protocol (SIP)", 1216 BCP 85, RFC 3725, April 2004. 1218 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1219 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1221 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E., 1222 and F. Yergeau, "Extensible Markup Language (XML) 1.0 1223 (Third Edition)", W3C Recommendation, February 2004. 1225 Authors' Addresses 1227 Chris Boulton 1228 Avaya 1229 Building 3 1230 Wern Fawr Lane 1231 St Mellons 1232 Cardiff, South Wales CF3 5EA 1234 Email: cboulton@avaya.com 1236 Tim Melanchuk 1237 Rain Willow Communications 1239 Email: tim.melanchuk@gmail.com 1241 Scott McGlashan 1242 Hewlett-Packard 1243 Gustav III:s boulevard 36 1244 SE-16985 Stockholm, Sweden 1246 Email: scott.mcglashan@hp.com 1248 Asher Shiratzky 1249 Radvision 1250 24 Raoul Wallenberg st 1251 Tel-Aviv, Israel 1253 Email: ashers@radvision.com 1255 Full Copyright Statement 1257 Copyright (C) The IETF Trust (2008). 1259 This document is subject to the rights, licenses and restrictions 1260 contained in BCP 78, and except as set forth therein, the authors 1261 retain all their rights. 1263 This document and the information contained herein are provided on an 1264 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1265 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1266 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1267 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1268 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1271 Intellectual Property 1273 The IETF takes no position regarding the validity or scope of any 1274 Intellectual Property Rights or other rights that might be claimed to 1275 pertain to the implementation or use of the technology described in 1276 this document or the extent to which any license under such rights 1277 might or might not be available; nor does it represent that it has 1278 made any independent effort to identify any such rights. Information 1279 on the procedures with respect to rights in RFC documents can be 1280 found in BCP 78 and BCP 79. 1282 Copies of IPR disclosures made to the IETF Secretariat and any 1283 assurances of licenses to be made available, or the result of an 1284 attempt made to obtain a general license or permission for the use of 1285 such proprietary rights by implementers or users of this 1286 specification can be obtained from the IETF on-line IPR repository at 1287 http://www.ietf.org/ipr. 1289 The IETF invites any interested party to bring to its attention any 1290 copyrights, patents or patent applications, or other proprietary 1291 rights that may cover technology that may be required to implement 1292 this standard. Please address the information to the IETF at 1293 ietf-ipr@ietf.org. 1295 Acknowledgment 1297 Funding for the RFC Editor function is provided by the IETF 1298 Administrative Support Activity (IASA).