idnits 2.17.1 draft-miniero-bfcp-control-package-01.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 985. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 996. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1009. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (July 8, 2008) is 5769 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: 'RFC2234' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'RFC3550' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'RFC4574' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mediactrl-ivr-control-package' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'I-D.boulton-ivr-vxml-control-package' is defined on line 932, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (Obsoleted by RFC 8856) == Outdated reference: A later version (-12) exists of draft-ietf-mediactrl-sip-control-framework-02 == Outdated reference: A later version (-11) exists of draft-ietf-mediactrl-ivr-control-package-00 == Outdated reference: A later version (-14) exists of draft-ietf-mediactrl-mixer-control-package-00 Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Miniero 3 Internet-Draft S P. Romano 4 Expires: January 9, 2009 University of Napoli 5 R. Even 6 Polycom 7 S. McGlashan 8 Hewlett-Packard 9 July 8, 2008 11 A Binary Floor Control Protocol (BFCP) Control Package for the Media 12 Control Channel Framework 13 draft-miniero-bfcp-control-package-01 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 January 9, 2009. 40 Abstract 42 This document defines a Media Control Channel Framework Package for 43 BFCP-based conference moderation. The control of Media Servers and 44 their related resources in decomposed network architectures plays an 45 important role in various Next Generation Networks. This Control 46 Package aims at adding BFCP functionality to conferences using the 47 Media Control Channel Framework. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Control Package Definition . . . . . . . . . . . . . . . . . . 4 56 5.1. Control Package Name . . . . . . . . . . . . . . . . . . . 5 57 5.2. Framework Message Usage . . . . . . . . . . . . . . . . . 5 58 5.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 6 59 5.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 6 60 5.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 6 61 5.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Floors Manipulation . . . . . . . . . . . . . . . . . . . . . 7 63 7. Element Definitions . . . . . . . . . . . . . . . . . . . . . 8 64 7.1. . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7.1.1. Shared elements . . . . . . . . . . . . . . . . . . . 10 66 7.1.2. Requests . . . . . . . . . . . . . . . . . . . . . . . 11 67 7.1.3. Responses . . . . . . . . . . . . . . . . . . . . . . 17 68 7.1.4. Notifications . . . . . . . . . . . . . . . . . . . . 18 69 7.2. Audit Elements . . . . . . . . . . . . . . . . . . . . . . 19 70 7.2.1. . . . . . . . . . . . . . . . . . . . . . . . 19 71 7.2.2. . . . . . . . . . . . . . . . . . . . 19 72 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 73 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 76 12. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 19 77 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 80 Intellectual Property and Copyright Statements . . . . . . . . . . 23 82 1. Introduction 84 The Media Control Channel Framework 85 [I-D.ietf-mediactrl-sip-control-framework] provides a generic 86 approach for establishment and reporting capabilities of remotely 87 initiated commands. The Framework utilizes many functions provided 88 by the Session Initiation Protocol (SIP) [RFC3261] for the rendezvous 89 and establishment of a reliable channel for control interactions. 90 The Control Framework also introduces the concept of a Control 91 Package. A Control Package is an explicit usage of the Control 92 Framework for a particular interaction set. This specification 93 defines a package for floor control in conferences based on the use 94 of the Binary Floor Control Protocol (BFCP) [RFC4582]. 96 2. Conventions 98 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 99 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 100 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 101 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 102 levels for compliant implementations. 104 3. Terminology 106 TBD. Inherited from other documents, including 107 [I-D.ietf-mediactrl-sip-control-framework] and 108 [I-D.ietf-mediactrl-mixer-control-package]. 110 Application Server: TBD. 112 Media Server: TBD. 114 Control Package: TBD. 116 4. Overview 118 The Media Control Channel Framework 119 [I-D.ietf-mediactrl-sip-control-framework] provides a generic 120 approach for establishment and reporting capabilities of remotely 121 initiated commands. The Framework utilizes many functions provided 122 by the Session Initiation Protocol (SIP) [RFC3261] for the rendezvous 123 and establishment of a reliable channel for control interactions. 124 The Control Framework also introduces the concept of a Control 125 Package. A Control Package is an explicit usage of the Control 126 Framework for a particular interaction set. This specification 127 defines a package for floor control in conferences based on the use 128 of the Binary Floor Control Protocol (BFCP) [RFC4582]. 130 Floor control is needed whenever access to a resource, or set of 131 resources, needs to be moderated. A typical example is the right to 132 talk in a conference. In such a scenario, a participant willing to 133 talk would first have to place a request concerning the floor 134 associated with such audio resource. The participant would then be 135 added to the conference mix only when his request has been granted, 136 by the server itself or by a designated chair. RFC4582 [RFC4582] 137 defines a Binary Floor Control Protocol (BFCP) to specifically deal 138 with such a need. It defines all the relevant entities (floors, 139 queues, requests) and related actors (floor control servers, 140 participants and chairs). So, the scope of this package is adding 141 BFCP-based floor control functionality to complementary packages that 142 might need it, as the Mixer Control Package 143 [I-D.ietf-mediactrl-mixer-control-package]. In particular, this 144 package aims at dealing with the case where the Floor Control Server 145 (FCS), as defined in [RFC4582], is co-located with the Media Server 146 (MS). In fact, if the FCS were co-located with the Application 147 Server (AS), floor control would be part of the AS application logic, 148 and thus out of scope for the MS. A typical example of how this 149 could be accomplished is the 'controller' mechanism as specified in 150 [I-D.ietf-mediactrl-mixer-control-package], where mixing in the MS 151 and its contributors are actively setup by the AS, according to any 152 policy the AS might be enforcing, including floor control. 154 Considering users are added by the AS to the MS by means of a 3PCC 155 [RFC3725] mechanism, a way to include BFCP negotiation is needed. In 156 fact, users willing to act as floor participants will need to be made 157 aware of all the relevant identifiers (i.e. the transport address of 158 the floor control server, the BFCP conference ID associated with the 159 mix, the BFCP user ID the user has been assigned, all the floor 160 identifiers and their mapping with existing resources, and so on) to 161 properly interact with a floor control server. To achieve this, 162 RFC4583 [RFC4583] provides with a way to negotiate BFCP connections 163 within the context of a SDP offer/answer [RFC3264]. 165 5. Control Package Definition 167 This section fulfills the mandatory requirement for information that 168 MUST be specified during the definition of a Control Framework 169 Package, as detailed in Section 9 of 170 [I-D.ietf-mediactrl-sip-control-framework]. 172 5.1. Control Package Name 174 The Control Framework requires a Control Package definition to 175 specify and register a unique name and version. 177 The name and version of this Control Package is "msc-bfcp/1.0" (Media 178 Server Control - Binary Floor Control - version 1.0). 180 5.2. Framework Message Usage 182 BFCP functionality includes several different capabilities. There 183 must be means to appropriately create, modify and destroy each of the 184 available resources. This includes means to create a BFCP conference 185 with specified settings, adding and removing floors to the 186 conference, setting or unsetting designated chairs for such floors 187 and so on. Proper subscription and notification mechanisms must also 188 be made available, in order to make the AS aware of all the relevant 189 events it might be interested to. 191 This package defines XML elements in Section 7 and provides an XML 192 Schema in Section 9. Additionally, some examples are provided in 193 Section 8. 195 The XML elements in this package are split into requests, responses 196 and event notifications, all of which are contained within a root 197 element. Requests are carried in CONTROL message bodies; 198 and elements are examples of package 199 requests. Responses are carried either in REPORT message or Control 200 Framework 200 response bodies; the element is defined as a 201 package response. Event notifications are instead carried in CONTROL 202 message bodies; the element is defined for package event 203 notifications. Event subscription is accomplished by means of the 204 element. 206 Note that package responses are different from framework response 207 codes. Framework error response codes (see Section 8 of 208 [I-D.ietf-mediactrl-sip-control-framework]) are used when the request 209 or event notification is invalid; for example, a request is invalid 210 XML (400), or not understood (500). Package responses are carried in 211 200 response or REPORT message bodies. This package's response codes 212 are defined in Section 7.1.3.1. 214 The schema uses the "connection-id" and "conf-id" attributes which 215 are imported from the schema defined in the core Control Framework 216 [I-D.ietf-mediactrl-sip-control-framework]. 218 5.3. Common XML Support 220 The Control Framework requires a Control Package definition to 221 specify if the attributes for media dialog or conference references 222 are required. 224 This package requires that the XML Schema in Section 17.1 of 225 [I-D.ietf-mediactrl-sip-control-framework] MUST be supported for 226 media dialogs and conferences. 228 5.4. CONTROL Message Body 230 The Control Framework requires a Control Package to define the 231 control body that can be contained within a CONTROL command request 232 and to indicate the location of detailed syntax definitions and 233 semantics for the appropriate body types. 235 When operating as Control Framework Server, the MS receives CONTROL 236 messages with a body containing an element with either a 237 floor control management or audit request child element. 239 The following mixer management request elements are carried in 240 CONTROL message bodies to MS: (Section 7.1.2.1), 241 (Section 7.1.2.2), 242 (Section 7.1.2.3), (Section 7.1.2.4), 243 (Section 7.1.2.5), (Section 7.1.2.6), 244 (Section 7.1.2.7) and 245 (Section 7.1.2.8) elements. 247 The request element (Section 7.2.1) is also carried in 248 CONTROL message bodies. 250 When operating as Control Framework Client, the MS sends CONTROL 251 messages with a body containing a notification (Section 7.1.3.1), or a 259 (notification) element (Section 7.1.4.2). 261 5.6. Audit 263 The Control Framework encourages Control Packages to specify whether 264 auditing is available, how it is triggered as well as the query/ 265 response formats. 267 This Control Packages supports auditing of package capabilities and 268 dialogs on the MS. An audit request is carried in a CONTROL messages 269 and an audit response in a REPORT message (or a 200 reponse to the 270 CONTROL if it can execute the audit in time). 272 The syntax and semantics of audit request and response elements is 273 defined in Section 4.4. 275 6. Floors Manipulation 277 Before delving into the details of the package elements, a few words 278 are worth being spent with respect to how floors are assumed to be 279 manipulated in this package. 281 Floors are defined as tokens associated with a resource, or set of 282 resources, in order to moderate the access to their functionality by 283 users. This introduces the need for a mechanism in the package to 284 properly take care of this kind of association, especially when 285 dealing about resources directly manipulated by the Media Server 286 (e.g. andio and video). 288 Let's consider the following figure, which presents the view of an 289 audio conference with three participants, and the related media 290 labels associated with each participant's media stream: 292 MS 293 +---------------+ 294 UAC A | | UAC B 295 o-----------+--x x--+-----------o 296 a1b2c3 | | d4e5f6 297 | | 298 | x | 299 | | | 300 +-------+-------+ 301 | 302 | g7h8i9 303 | 304 o 305 UAC C 307 Figure 1: Audio Conference with labels 309 Even if each participant sees a different label for the stream it has 310 with the mixer, the floor associated with the only available resource 311 in the conference (audio) is the same. This means that the package 312 needs to have a way to address each resource in the conference 313 according to how it is defined in 314 [I-D.ietf-mediactrl-mixer-control-package], e.g. "associate media 315 'audio' with floor 11" or any other more complex assignment involving 316 labels and the like. Once a participant's media stream is attached 317 to the resource, the related label is consequently associated with 318 the floor as specified in [RFC4583]. Figure 2 depicts such the case 319 where all the participants have been attached to the mix. 321 MS 322 +---------------+ 323 UAC A | | UAC B 324 o-----------+--+~~>[ ]<~~+--+-----------o 325 a1b2c3 | ^ | d4e5f6 326 (floor 11) | | | (floor 11) 327 | + | 328 | | | 329 +-------+-------+ 330 | 331 | g7h8i9 332 | (floor 11) 333 o 334 UAC C 336 Figure 2: Audio Conference with labels and floors 338 The same approach can be considered when dealing with different 339 floors associated with one or more different resources, e.g. 340 conferences with an audio and a video stream, conferences with two 341 different audio streams, and so on. Each floor needs to be 342 unambiguously associated with a subset of the available resources 343 (e.g. floor 11 is audio1 and floor 22 is video, or floor 11 is audio1 344 while floor 22 is audio2, or floor 11 is audio1 AND audio2 AND 345 video2, and so on). 347 To achieve this, each floor, together with its configuration, is 348 defined in the package by the element, as described in 349 Section 7.1.1.1. 351 7. Element Definitions 353 This section defines the XML messages for this control package. 355 [Editors Note: since XML Schema may not be able to express all 356 constraints expressed in these definitions, in cases where there is a 357 difference in constraints, the definitions in the section take 358 priority.] 360 7.1. 362 The element has the following attributes (in addition to 363 standard XML namspace attributes such as xmlns): 365 version: a string specifying the mscbfcp package version. The value 366 is fixed as '1.0' for this version of the package. The attribute is 367 mandatory. 369 The element has the following defined child elements, only 370 one of which can occur: 372 : create and configure a new BFCP conference, 373 associated with an existing framework conference instance to 374 moderate - see Section 7.1.2.1 for details; 376 : destroy a BFCP conference, thus stopping the 377 moderation of the associated framework conference instance - see 378 Section 7.1.2.2 for details; 380 : add and configure a new floor to an existing BFCP 381 conference - see Section 7.1.2.3 for details; 383 : modify the configuration of a currently handled floor 384 in an existing BFCP conference - see Section 7.1.2.4 for details; 386 : remove a currently handled floor from an existing 387 BFCP conference - see Section 7.1.2.5 for details; 389 : add a floor participant to a BFCP conference - see 390 Section 7.1.2.6 for details; 392 : modify an existing floor participant in a BFCP 393 conference - see Section 7.1.2.7 for details; 395 : remove a floor participant from a BFCP 396 conference - see Section 7.1.2.8 for details. 398 : response to a floor control request - see Section 7.1.3 399 for details. 401 : bfcp or subscription notification - see Section 7.1.4 for 402 details. 404 7.1.1. Shared elements 406 All the previously introduced requests make use of the same element 407 specification to describe the desired operation. Specifically, 408 , and make use of the 409 element (Section 7.1.1.1), while , 410 and make use of the 411 element (Section 7.1.1.2). 413 7.1.1.1. 415 The element is used in the package to configure a floor in a 416 BFCP conference. It addresses all the relevant settings for a floor, 417 including the resource (or, again, set of resources) it must be 418 associated with, the maximum number of users that can be granted the 419 floor at the same time, the maximum number of requests the same 420 participant can place for this floor at the same time, and the 421 default policy the FCS considers for incoming requests about the 422 floor. 424 The element has the following attributes: 426 bfcp-floor-id: string indicating the name of the BFCP floor. This 427 attribute is optional. 429 : an element indicating the type of media associated with the 430 floor, i.e. the resource associated with the floor, as defined in 431 [I-D.ietf-mediactrl-mixer-control-package]. The string might be a 432 comma-separated list in case the floor is associated with more 433 than one resource (e.g. media="audio,video"). This element is 434 mandatory. 436 : an element indicating the maximum number of users that 437 can be granted this floor at the same time: this basically sets 438 the size of the granted floor queue. In case all the queue slots 439 have already been granted, subsequent requests are put on hold. 440 This element is optional: if missing, the default value (max- 441 users="1") is used. 443 : an element indicating the maximum number of requests 444 each user can place for the floor before being granted it. This 445 element is optional: if missing, the default value (max- 446 requests"="1) is used. 448 : an element indicating the default policy the FCS must take 449 whenever receiving requests for this floor and the chair is 450 missing. In fact, in case a chair is involved, the request is 451 forwarded to him, which then takes a decision about it. The 452 policy can be an 'autodeny' (deny all the requests for this 453 floor), 'autoaccept' (accept all the requests for this floor) or 454 'ignore' (ignore all the requests for this floor and put them on 455 ice, waiting for a chair to appear) policy. This element is 456 optional: if missing, the default value (policy="autoaccept") is 457 used. 459 The "bfcp-floor-id" attribute has different roles according to the 460 request the element is part of. The behaviour of the package 461 changes accordingly. Specifically: 463 : if the attribute is not specified, 464 the MS creates a unique name for the BFCP floor. The value is 465 used in subsequent references to the conference (e.g. as bfcp- 466 floor-id in a ). The new value of this attribute 467 MUST be unique or else a 403 'Floor already exists' package level 468 error will be reported. 470 : if the attribute is not specified, the value of the 471 attribute in the father element is used. If it is specified, 472 instead, it must not conflict with the value of the attribute in 473 the father element, otherwise it is an error. 475 TBD. Elaborate the floor mechanism. 477 [Note: the first problem that comes to mind is the actual association 478 between a floor and a resource in the MS. Specifically, enforcing 479 the decisions might be an issue, since there's no way this package 480 and msc-mixer can talk with each other...] 482 7.1.1.2. 484 TBD. Elaborate the participant mechanism. 486 [Note: this element will include the same mechanism used in other 487 packages to address a connection, in order to associate a BFCP user 488 identifier to it. Besides, it will include means to specify whether 489 or not a participant is chair of any of the available floors.] 491 7.1.2. Requests 492 7.1.2.1. 494 is used in a request by the AS to moderate an 495 existing conference instance, by associating to it a new, properly 496 configured, BFCP conference. 498 The element has the following attributes: 500 conf-id: string indicating the name of the conference to moderate. 501 The conference MUST be known by the receiving entity or else a 404 502 'Conference does not exist' package level error will be generated. 503 This attribute is mandatory. 505 bfcp-conf-id: string (an unsigned integer) indicating a unique name 506 for the BFCP conference. If this attribute is not specified, the 507 MS creates a unique name for the BFCP conference. The value is 508 used in subsequent references to the conference (e.g. as bfcp- 509 conf-id in a ), and in actual BFCP protocol contents as 510 well, and as such MUST adhere to the syntax defined in [RFC4582]. 511 When present in a request, the new value of 512 this attribute MUST be unique or else a 403 'Conference already 513 exists' package level error will be reported. The attribute is 514 optional. 516 Additionally, to configure the new BFCP conference, the 517 element has the following child elements 518 defined: 520 : an element (Section 7.1.1.1) to configure a floor in the 521 new BFCP conference (see Section 7.1.1.1 for more details). This 522 element only refers to floors already available at creation time. 523 New floors can still be added subsequently by means of an 524 request (see Section 7.1.2.3). This element is 525 optional. 527 : an element to request subscription to conference 528 events. (see Section 7.1.4.1 for more details). This element is 529 optional. 531 Multiple elements may be defined, in case several floors are 532 needed. 534 When a MS has finished processing a request, it 535 MUST reply with an appropriate element (Section 7.1.3). 537 7.1.2.2. 539 is used in a request by the AS to destroy a 540 BFCP conference, thus stopping the moderatation of the associated 541 existing framework conference instance. A successful processing of 542 this request does NOT result in a destruction of the associated media 543 conference: it only results in the media conference not being 544 moderated by means of BFCP anymore. The actual destruction of the 545 media conference itself is accomplished through the means provided in 546 [I-D.ietf-mediactrl-mixer-control-package]. 548 The element has the following attributes: 550 bfcp-conf-id: string indicating the name of the BFCP conference to 551 destroy. The conference MUST be known by the receiving entity or 552 else a 404 'Conference does not exist' package level error will be 553 generated. This attribute is mandatory. 555 The element does not specify any child 556 elements. 558 When a MS has finished processing an request, 559 it MUST reply with an appropriate element 560 (Section 7.1.3.1). 562 7.1.2.3. 564 is used in a request by the AS to add one or more floors 565 to an existing BFCP conference instance. 567 The element has the following attributes: 569 bfcp-conf-id: string indicating the name of the BFCP conference to 570 add the floor(s) to. The conference MUST be known by the 571 receiving entity or else a 404 'Conference does not exist' package 572 level error will be generated. This attribute is mandatory. 574 Additionally, to configure the new floor(s), the element 575 has the following child elements defined: 577 : an element to configure a new floor in the specified BFCP 578 conference (see Section 7.1.1.1 for more details). This element 579 is mandatory. 581 Multiple elements may be defined, in case several floors are 582 to be added at the same time. 584 When a MS has finished processing an request, it MUST 585 reply with an appropriate element (Section 7.1.3.1). 587 7.1.2.4. 589 is used in a request by the AS to modify the 590 configuration of a floor in an existing BFCP conference instance. 592 The element has the following attributes: 594 bfcp-conf-id: string indicating the name of the BFCP conference to 595 modify the floor's in. The conference MUST be known by the 596 receiving entity or else a 404 'Conference does not exist' package 597 level error will be generated. This attribute is mandatory. 599 bfcp-floor-id: string indicating the name of the BFCP floor to 600 modify the floor. The floor MUST be known by the receiving entity 601 or else a 404 'Floor does not exist' package level error will be 602 generated. This attribute is mandatory. 604 Additionally, to modify the configuration of the floor, the 605 element has the following child elements defined: 607 : an element to configure the specified floor in the 608 specified BFCP conference (see Section 7.1.1.1 for more details). 609 This element is mandatory. 611 It is an error if the provided element conflicts with the 612 BFCP floor identifier attribute. 614 When a MS has finished processing a request, it MUST 615 reply with an appropriate element (Section 7.1.3.1). 617 7.1.2.5. 619 is used in a request by the AS to remove an existing 620 floor from the BFCP conference instance it is in. A successful 621 processing of this request does NOT result in a destruction of the 622 associated resource (or set of resources): it only results in the 623 associated resource not being moderated by means of BFCP anymore. 624 The actual destruction of the resource (in case it is directly 625 handled and manipulated by the MS itself) is accomplished through the 626 means provided in [I-D.ietf-mediactrl-mixer-control-package]. 628 The element has the following attributes: 630 bfcp-conf-id: string indicating the name of the BFCP conference to 631 remove the floor from. The conference MUST be known by the 632 receiving entity or else a 404 'Conference does not exist' package 633 level error will be generated. This attribute is mandatory. 635 bfcp-floor-id: string indicating the name of the BFCP floor to 636 remove. The floor MUST be known by the receiving entity or else a 637 404 'Floor does not exist' package level error will be generated. 638 This attribute is mandatory. 640 The element does not specify any child elements. 642 When a MS has finished processing a request, it MUST 643 reply with an appropriate element (Section 7.1.3.1). 645 7.1.2.6. 647 is used in a request by the AS to add a new BFCP 648 participant instance to an existing BFCP conference. Some additional 649 details can also be provided about the new participant, if it will be 650 the chair of one of the floors for example. 652 The element has the following attributes: 654 bfcp-conf-id: string indicating the name of the BFCP conference to 655 add the participant to. The conference MUST be known by the 656 receiving entity or else a 404 'Conference does not exist' package 657 level error will be generated. This attribute is mandatory. 659 bfcp-user-id: string (an unsigned integer) indicating a unique name 660 for the new BFCP participant. If this attribute is not specified, 661 the MS creates a unique name for the BFCP participant. The value 662 is used in subsequent references to the conference (e.g. as bfcp- 663 conf-id in a ), and in actual BFCP protocol contents as 664 well, and as such MUST adhere to the syntax defined in [RFC4582]. 665 When present in an request, the new value of this 666 attribute MUST be unique or else a 405 'User already exists' 667 package level error will be reported. The attribute is optional. 669 Additionally, to configure the new participant, the 670 element has the following child elements defined: 672 : an element to configure a new floor in the specified 673 BFCP conference (see Section 7.1.1.2 for more details). This 674 element is mandatory. 676 Only one element can be present, which means only one 677 BFCP participant instance can be added at the same time. 679 When a MS has finished processing an request, it 680 MUST reply with an appropriate element (Section 7.1.3.1). 682 [Note: is this really needed? there may be RFC4583 for that...] 684 7.1.2.7. 686 is used in a request by the AS to modify the 687 configuration of a participant in an existing BFCP conference 688 instance. A typical use case for this request is to set or unset a 689 participant as chair of a floor in a conference. 691 The element has the following attributes: 693 bfcp-conf-id: string indicating the name of the BFCP conference to 694 modify the floor's in. The conference MUST be known by the 695 receiving entity or else a 404 'Conference does not exist' package 696 level error will be generated. This attribute is mandatory. 698 bfcp-user-id: string indicating the name of the BFCP participant 699 whose settings must be modified. The participant MUST be known by 700 the receiving entity or else a 406 'User does not exist' package 701 level error will be generated. This attribute is mandatory. 703 Additionally, to modify the configuration of the participant, the 704 element has the following child elements defined: 706 : an element to configure the specified participant in 707 the specified BFCP conference (see Section 7.1.1.2 for more 708 details). This element is mandatory. 710 It is an error if the provided element conflicts with 711 the BFCP participant identifier attribute. 713 When a MS has finished processing a request, it 714 MUST reply with an appropriate element (Section 7.1.3.1). 716 7.1.2.8. 718 is used in a request by the AS to remove an 719 existing participant from the BFCP conference instance it is in. A 720 successful processing of this request does NOT result in a 721 termination of the participant's media session: it only results in 722 the associated media streams not being moderated by means of BFCP 723 anymore.. 725 The element has the following attributes: 727 bfcp-conf-id: string indicating the name of the BFCP conference to 728 remove the floor from. The conference MUST be known by the 729 receiving entity or else a 404 'Conference does not exist' package 730 level error will be generated. This attribute is mandatory. 732 bfcp-user-id: string indicating the name of the BFCP participant to 733 remove. The participant MUST be known by the receiving entity or 734 else a 406 'User does not exist' package level error will be 735 generated. This attribute is mandatory. 737 The element does not specify any child elements. 739 When a MS has finished processing a request, it 740 MUST reply with an appropriate element (Section 7.1.3.1). 742 [Note: is this really needed? there may be RFC4583 for that...] 744 7.1.3. Responses 746 All responses to the previously described requests are specified in a 747 element. This element may be contained in the body either 748 of a REPORT framework message or in a 200 framework message. 750 7.1.3.1. 752 Reponses to requests are indicated by a element. 754 The element has the following attributes: 756 status: numeric code indicating the response status. This attribute 757 is mandatory. 759 reason: string specifying a human readable description of the reason 760 for the response status. This attribute is optional. 762 bfcp-conf-id: string identifying the BFCP conference the request 763 referred to. This attribute is optional. 765 bfcp-floor-id: string identifying the BFCP floor the request 766 referred to. This attribute is optional. 768 The following status codes are defined: 770 +------+-------------+ 771 | code | description | 772 +------+-------------+ 773 | 200 | OK | 774 | 4xx | whatever | 775 +------+-------------+ 777 Table 1: Status codes 779 TBD. Add all error codes and their meanings 781 7.1.4. Notifications 783 In case the AS is interested in receiving events regarding a BFCP 784 conference, a notification mechanism is provided in the package. The 785 AS requests subscription to such events by adding a child 786 element to the request, whereas the MS triggers 787 the related events in subsequent REPORT messages. Event 788 notifications are then delivered using the element. 790 7.1.4.1. 792 BFCP event notifications are defined when an AS subscribes to 793 notifications for BFCP-related events using the element 794 in a request. 796 The element has no attributes, but has the following 797 child elements defined: 799 : contains the following attributes: 800 name: a string indicating the name of the event to be notified. 801 This attribute is mandatory. 803 Multiple elements may be specified. 805 The MS would then use the element to send notifications to 806 the AS. 808 7.1.4.2. 810 Delivery of events the AS subscribed for is accomplished by means of 811 an element. 813 The element has the following attributes: 815 name: string indicating the name of the BFCP event. This attribute 816 is mandatory. 818 bfcp-conf-id: string identifying the BFCP conference the event 819 happened in. This attribute is mandatory. 821 Additionally, to provide the AS with details upon the event, the 822 element has the following child elements defined: 824 TBD. Elaborate the notification mechanism. 826 7.2. Audit Elements 828 7.2.1. 830 TBD. 832 7.2.2. 834 TBD. 836 8. Examples 838 TBD. 840 9. Formal Syntax 842 TBD. 844 10. Security Considerations 846 TBD. 848 11. IANA Considerations 850 TBD. 852 12. Change Summary 854 The following are the major changes between the -00 and the -01 855 versions of the draft: 857 o updated references (mixer draft); 859 o updated authors; 861 o aligned syntax to the one used in msc-ivr and msc-mixer 862 (); 864 o added placeholders for event notifications and auditing; 866 o added participant related methods, and moved floor related 867 discussions; 869 13. Acknowledgements 871 TBD. 873 14. References 875 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 876 Specifications: ABNF", RFC 2234, November 1997. 878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", BCP 14, RFC 2119, March 1997. 881 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 882 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 883 October 1998. 885 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 886 A., Peterson, J., Sparks, R., Handley, M., and E. 887 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 888 June 2002. 890 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 891 with Session Description Protocol (SDP)", RFC 3264, 892 June 2002. 894 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 895 Camarillo, "Best Current Practices for Third Party Call 896 Control (3pcc) in the Session Initiation Protocol (SIP)", 897 BCP 85, RFC 3725, April 2004. 899 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 900 Jacobson, "RTP: A Transport Protocol for Real-Time 901 Applications", STD 64, RFC 3550, July 2003. 903 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 904 Control Protocol (BFCP)", RFC 4582, November 2006. 906 [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format 907 for Binary Floor Control Protocol (BFCP) Streams", 908 RFC 4583, November 2006. 910 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 911 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 913 [I-D.ietf-mediactrl-sip-control-framework] 914 Boulton, C., Melanchuk, T., and S. McGlashan, "Media 915 Control Channel Framework", 916 draft-ietf-mediactrl-sip-control-framework-02 (work in 917 progress), April 2008. 919 [I-D.ietf-mediactrl-ivr-control-package] 920 McGlashan, S., Melanchuk, T., and C. Boulton, "An 921 Interactive Voice Response (IVR) Control Package for the 922 Media Control Channel Framework", 923 draft-ietf-mediactrl-ivr-control-package-00 (work in 924 progress), June 2008. 926 [I-D.ietf-mediactrl-mixer-control-package] 927 Melanchuk, T., McGlashan, S., and C. Boulton, "A Mixer 928 Control Package for the Media Control Channel Framework", 929 draft-ietf-mediactrl-mixer-control-package-00 (work in 930 progress), July 2008. 932 [I-D.boulton-ivr-vxml-control-package] 933 Boulton, C., Melanchuk, T., and S. McGlashan, "A VoiceXML 934 Control Package for the Media Control Channel Framework", 935 draft-boulton-ivr-vxml-control-package-04 (work in 936 progress), February 2008. 938 Authors' Addresses 940 Lorenzo Miniero 941 University of Napoli 942 Via Claudio 21 943 Napoli 80125 944 Italy 946 Email: lorenzo.miniero@unina.it 947 Simon Pietro Romano 948 University of Napoli 949 Via Claudio 21 950 Napoli 80125 951 Italy 953 Email: spromano@unina.it 955 Roni Even 956 Polycom 957 94 Derech Em Hamoshavot 958 Petach Tikva 49130 959 Israel 961 Email: roni.even@polycom.co.il 963 Scott McGlashan 964 Hewlett-Packard 965 Gustav III:s boulevard 36 966 Stockholm SE-16985 967 Sweden 969 Email: scott.mcglashan@hp.com 971 Full Copyright Statement 973 Copyright (C) The IETF Trust (2008). 975 This document is subject to the rights, licenses and restrictions 976 contained in BCP 78, and except as set forth therein, the authors 977 retain all their rights. 979 This document and the information contained herein are provided on an 980 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 981 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 982 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 983 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 984 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 985 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 987 Intellectual Property 989 The IETF takes no position regarding the validity or scope of any 990 Intellectual Property Rights or other rights that might be claimed to 991 pertain to the implementation or use of the technology described in 992 this document or the extent to which any license under such rights 993 might or might not be available; nor does it represent that it has 994 made any independent effort to identify any such rights. Information 995 on the procedures with respect to rights in RFC documents can be 996 found in BCP 78 and BCP 79. 998 Copies of IPR disclosures made to the IETF Secretariat and any 999 assurances of licenses to be made available, or the result of an 1000 attempt made to obtain a general license or permission for the use of 1001 such proprietary rights by implementers or users of this 1002 specification can be obtained from the IETF on-line IPR repository at 1003 http://www.ietf.org/ipr. 1005 The IETF invites any interested party to bring to its attention any 1006 copyrights, patents or patent applications, or other proprietary 1007 rights that may cover technology that may be required to implement 1008 this standard. Please address the information to the IETF at 1009 ietf-ipr@ietf.org.