idnits 2.17.1 draft-wu-sipping-floor-control-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 38 instances of too long lines in the document, the longest one being 19 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the holders of one or more floors have changed, the conference server SHOULD send a notification to the parties interested in this event. At the same time, the conference server SHOULD send a re-INVITE to the new holders to enable the sending of media. The UA SHOULD not send media until it has received a floorChanged event. The following XML schema fragment defines the floorChanged event. The element 'holding' contains the new holders' information. -- 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 (March 2, 2003) is 7719 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) ** Obsolete normative reference: RFC 3265 (ref. '2') (Obsoleted by RFC 6665) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3388 (ref. '6') (Obsoleted by RFC 5888) ** Obsolete normative reference: RFC 2141 (ref. '7') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 3023 (ref. '10') (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '16') (Obsoleted by RFC 7826) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft Wu/Koskelainen/Schulzrinne 4 Columbia University 5 draft-wu-sipping-floor-control-04.txt 6 March 2, 2003 7 Expires: September 2003 9 Use of Session Initiation Protocol (SIP) and Simple Object Access 10 Protocol (SOAP) for Conference Floor Control 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 To view the list Internet-Draft Shadow Directories, see 31 http://www.ietf.org/shadow.html. 33 Abstract 35 During a conference, floor control coordinates simultaneous access to 36 shared resource in multimedia conferences. Floor control allows 37 applications and users to gain safe and mutually exclusive or non- 38 exclusive access to the shared resources. This document defines an 39 approach of using Session Initiation Protocol (SIP) event 40 notification mechanism and Simple Object Access Protocol (SOAP) to 41 perform floor control. 43 1 Introduction 45 Many existing conference management protocols, such as [11][12] have 46 defined floor control functions. Floor control can be used to avoid 47 or resolve conflicts among simultaneous media inputs. For example, at 48 a given time, the moderator of a floor can ensure that only one 49 person is heard by other participants or one person types into a 50 shared document. 52 The conference models can be centralized or non-centralized [13]. In 53 a centralized model, we assume there is one conference server acting 54 as the root of a conference. The root conference server receives all 55 floor requests and can control the propagation of media in the 56 conference directly or through sending requests to other conference 57 servers in a tree topology. There is no such root conference server 58 in the non-centralized model. The non-centralized model does not 59 work well with the mechanism in this document. In the rest of this 60 document, we simply use conference server referring to the root 61 conference server. 63 The conference server needs to be able to control the shared 64 resources. For example, the mixer in a conference server can 65 selectively choose the media sources for mixing. The moderators and 66 participants of the conference should be able to send the floor 67 control commands to the conference server to change floor status, and 68 the conference server should notify the moderators and participants 69 of changes. 71 A floor control protocol is used to convey the floor control messages 72 among the moderators of the conference, the conference server and the 73 participants of the conference. The floor control protocol does not 74 deal with the conference management such as how to elect the 75 moderator of the conference or how to add users to the conference. 77 We divide the floor control messages into two categories: floor 78 control events and floor control commands. 80 The conference server sends floor control events to moderators or 81 participants to report changes in the resource status. The SIP [1] 82 events architecture [2] is well fitted for conveying floor control 83 events. This document defines a new event package named floor-control 84 for the floor control events. 86 Moderators or participants send floor control commands to the 87 conference server to change the status of resources. Floor control 88 commands are like remote-procedure calls from the moderators or the 89 participants to the conference server. Since one of SOAP's [3] design 90 goals is to encapsulate and exchange RPC calls, instead of creating 91 another RPC protocol, we consider of using SOAP to transmit floor 92 control commands. SOAP messaging most commonly uses HTTP as the 93 transport protocol. However, SIP can also be used to carry the SOAP 94 content [14]. The same mechanism can be used for general conference 95 control [15]. 97 In the centralized conference model, floor claims are ordered in 98 queues at the conference server. Floor moderators can assert priority 99 or reorder the claims in the queues. 101 1.1 Conventions of This Document 103 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 104 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 105 and "OPTIONAL" are to be interpreted as described in RFC 2119 [4]. 107 2 Using SIP and SOAP for Floor Control 109 2.1 SIP Event Notification for Tracking Floor Status 111 A new SIP event package 'floor-control' is introduced for floor 112 status notification. The conference server can indicate that it 113 supports the floor-control event package by including an 'Allow- 114 Events: floor-control' header field. If a user wants to be informed 115 of the floor status, the user's UA MUST send a SUBSCRIBE with the 116 Event header set to 'floor-control' to the conference server. The 117 events in the floor-control package will be described in detail in 118 Section 4. 120 If the user's UA cannot understand the 'floor-control' package, the 121 user may use web based floor control approach. To convey this URL for 122 the web based floor control, the conference server MAY use the 123 'Call-Info' header to bring the URL. And a new value, named 'floor- 124 control', SHOULD be used for the Call-Info header's purpose 125 parameter. 127 2.2 Using SDP to Establish Floor Control Channel 129 We use Session Description Protocol (SDP) [5] to convey the floor 130 control channel information since floor control channels and media 131 channels are closely coupled. Any approach trying to convey floor 132 control channel information must know the detail of the session 133 description. 135 When a user joins a conference, the conference server uses SDP's 'a' 136 line to indicate that the conference is moderated. 138 a=type:moderated 139 The new participants joining the moderated conference SHOULD start 140 media tools as 'mute' so that they do not send media. 142 If only some of the media streams are moderated in a conference, the 143 'a=type:moderated' line MUST NOT be used because this attribute is a 144 session level attribute, it indicates all the media streams in a 145 session are moderated. As introduced later in this section, grouping 146 media channels and a control channel can clearly indicate that the 147 grouped media channels are moderated. For moderated media channels, 148 the new participants SHOULD start the media tools as 'mute' 149 accordingly. 151 As indicated in RFC2327 [5], the 'm' line can specify the conference 152 control tools, the port and protocol used for control. The following 153 is an example: 155 m=control 5060 SIP SOAP 157 However, the 'm' line does not provide the information of HTTP URL or 158 SIP URI. A way of relaying the URI information is to use a session- 159 level 'a=floorcontrol:' attribute. This is similar to how RTSP's 160 'a=control:' attribute [16] works. The following is an example: 162 a=floorcontrol:sip:floorcontrol@foo.example.com 164 Using m=control line cannot associate floor control channel with 165 particular media channels. Thus, it cannot handle the case that a 166 moderator can only control part of the resources, e.g., a moderator 167 can control the cameras but not the microphones. 169 To solve this problem, we can group the control lines with the other 170 media lines as described in the RFC3388 "Grouping of media lines in 171 the Session Description Protocol (SDP) [6]. A new semantics named FL 172 (floor control) is defined for this purpose. An example session 173 description is shown below: 175 v=0 176 o=Foo 289083124 289083124 IN IP4 foo.example.com 177 s=SIP conferencing 178 t=0 0 179 c=IN IP4 224.2.17.12/127 180 a=group:FL 1 2 4 181 m=audio 10000 RTP/AVP 0 182 a=mid:1 183 m=video 20000 RTP/AVP 31 184 a=mid:2 185 m=application 30000 udp wb 186 a=mid:3 187 m=control 5060 SIP SOAP 188 a=floorcontrol:sip:floorcontrol@foo.example.com 189 a=mid:4 191 In this example, the control channel can only control audio and 192 video, but not the whiteboard. The SIP URI for the control channel is 193 sip:floorcontrol@foo.example.com. 195 The control line cannot indicate whether a user is a moderator or 196 not. The conference server will use the floorCreated (Section 4.1) or 197 configChanged (Section 4.3) event notification to indicate that. 199 If a participant dials in the conference, the INVITE message will not 200 contain the m=control line for floor control because the 201 participant's user agent does not know how many floor control 202 channels are needed. The m=control line can only be initiated from 203 the conference server's INVITE message. If a participant's user agent 204 cannot support floor control, in the SIP response, the user agent 205 will set the port as 0 for the m=control line. 207 2.3 Use of SOAP for Floor Control Commands 209 If a user wants to change the floor control status, the user's UA MAY 210 use SOAP to carry the floor control commands. The SOAP message can be 211 carried either in HTTP or SIP. The name and the parameters of the 212 commands will be described in detail in Section 5. 214 Both the moderator and the participants can have control over the 215 conference. However, they have different control command set. The 216 conference server SHOULD have knowledge of the moderated resources 217 (e.g., who can control the resources) and SHOULD be able to convey 218 the knowledge to the users. 220 3 Datatypes in the floor control messages 222 We use an XML-based data format for the floor control messages. A 223 floor control message contains information about floors, resources 224 and floor claims. The namespace URI for elements defined by this 225 specification is a URN [7], using the namespace identifier 'ietf' 226 defined by [8] and extended by [9]. This URN is: 228 urn:ietf:params:xml:ns:floor-control 230 To represent such information, the following sections define several 231 datatypes and provides the XML schema fragment for each datatype. 233 3.1 floorType 234 The floorType is used to define a floor. It contains an optional 235 attribute and several sub-elements. The optional attribute 236 'maxHolders' defines how many users can hold the floor 237 simultanuously. The default value of the 'maxHolders' is 1. The 238 following XML schema fragment defines the floorType. 240 241 242 243 244 245 247 248 249 251 There are three sub-elements in the floorType. The element 252 'resources' has the type 'resourcesType'. It lists the resources the 253 floor controls. If it is not provided, the floor controls all the 254 resources of the conference. The element 'users' has the type 255 'usersType'. It defines who can hold the floor. If it is not 256 provided, every user in the conference can hold the floor. The 257 element 'moderators' has the type 'moderatorsType'. It defines who 258 are the moderators of the floor. If it is not provided in the 259 CreateFloor command, the user who sends the FloorCreate command will 260 serve as the moderator. If the element 'moderators' is not provided 261 in a floor control notification, it means this information is hidden 262 by the conference server. 264 The wildcard xs:any in the floorType is used to provide additional 265 information of the floor, such as floor control policies. 267 3.2 resourcesType 269 The resourcesType groups resources that can be controlled by one 270 floor. It contains a sequence of elements with the type 271 resourceType. The following XML schema fragment defines the 272 resourceType and the resourcesType. 274 275 276 277 278 279 281 282 284 The value of the 'resource' element MUST be one of the mids defined 285 in the SDP of the conference server's message. The SDP's 'a=mid:' 286 attribute provides the value. 288 3.3 usersType 290 The usersType contains a list of users that can claim the floor or 291 the URL of the user list. The following XML schema fragment defines 292 the userType and the usersType. 294 295 296 297 298 299 300 301 302 304 The string value in userType MUST be a valid SIP or SIPS URI. The 305 attribute 'url' of usersType gives the web URL that contains the user 306 list. If it is not provided, there MUST be at least one 'user' 307 element presented. 309 3.4 moderatorsType 311 The moderatorsType contains a floor moderator list. The following 312 XML schema fragment defines the moderatorType and the moderatorsType. 314 315 316 317 318 319 321 322 324 The string value in moderatorType MUST be a valid SIP or SIPS URI. 326 3.5 holdingType 328 The holdingType defines the relationship between the floor holders 329 and the resources. Within the holdingType there are two elements, the 330 resources and the users. The element 'resources' has the type 331 'resourcesType'. If it is not provided, the holding is for all the 332 resources of the conference. The element 'users' has the type 333 'usersType'. If 'users' is not provided, there is no user holding 334 the floor. The holdingType has two attributes, the required 335 attribute timestamp gives the time the users get the access right of 336 the resources and the optional attribute expiration defines when the 337 holding will be expired. If the expiration is not provided, the 338 holding will end until the users release the floor. The following 339 XML schema fragment defines holdingType. 341 342 343 344 345 346 347 348 350 3.6 claimType 352 The claimType contains the information sent by the participants to 353 request a floor. Floor claims are put in a queue at the conference 354 server. Generally, the order of the queue is based on the timestamp 355 of floor claims. 357 The required element 'user' defines who sends the claim. The 358 optional element 'resources' defines what resources the user claims 359 for. If not provided, the user wishes to claim for all the resources. 360 The optional element 'subject' provides the reason for holding the 361 floor. The optional element 'holdingTime' defines how long the user 362 expects to hold the floor. The required attribute 'claimID' MUST be 363 globally unique for the conference, generated by the combination of a 364 random string and the claimer's SIP URI. The claimer can modify an 365 existing claim by sending a new claim with the same claimID as the 366 existing one. When a claim is granted, before the claimer releases 367 the floor, the claim is considered as a granted claim. Granted claims 368 MUST be removed from the claim queue. The conference server MUST keep 369 track of the granted claims. The current floor holder can send a 370 claim with the same claimID as his granted claim to ask for the 371 extension of the holding time. The optional attribute 'timestamp' 372 provides the time that the claim is generated. The optional attribute 373 'expiration' defines when a claim expires. The conference server MUST 374 remove expired floor claims from the floor claim queue. The optional 375 attribute 'priority' defines the priority of the claim. There are 376 four possible priority values, "non-urgent", "normal", "urgent" and 377 "emergency". By default, the priority is "normal". The following XML 378 schema fragment defines the claimType. 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 400 402 3.7 claimsType 404 The claimsType contains a list of claims. The following XML schema 405 fragment defines the claimsType. 407 408 409 410 411 413 3.8 operationType 415 We defined several queue operations such as move up, move down, move 416 to the top and move to the bottom to manipulate the floor claim 417 queue. The 'up', 'down', 'top' and 'bottom' are the operators. The 418 operation MAY have an argument. For 'up' and 'down', the argument 419 means how many steps to move a claim. For 'top', the argument means 420 to what position to move a claim counting down from the top of the 421 queue. For 'bottom', the argument means to what position to move a 422 claim counting up from the bottom of the queue. If the argument is 423 not presented, the operation 'up' will move the claim up one position 424 in the queue; the operation 'down' will move the claim down one 425 position in the queue; the operation 'top' will move a claim at the 426 top of the queue and the operation 'bottom' will move a claim to the 427 bottom of the queue. The following XML schema fragment defines the 428 operatorType and the operationType. 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 446 4 Floor control events 448 Table 1 shows the events for the floor control package. We specify 449 an XML-based data format for the parameters of each event. The MIME 450 type for the format is application/floor-control+xml, consistent with 451 the recommendations provided in RFC 3023 [10]. 453 Event name Description Issuer -> Receiver 454 _____________________________________________________________________ 455 floorCreated A floor has been created for some Server -> User 456 resources and participants. 457 floorRemoved A floor has been removed for some Server -> User 458 resources 459 configChanged Floor configuration changed Server -> User 460 floorChanged Floor changed to different users Server -> User 461 queueChanged Floor claim queue changed Server -> Moderator 463 Table 1: Floor control events 465 In Table 1, the 'Server' refers to 'Conference server' and the 'User' 466 refers to either 'Moderator' or 'Participant'. 468 4.1 floorCreated event 470 When a floor is created for some set of resources, the conference 471 server SHOULD send a notification to the parties interested in this 472 event. 474 The floorCreated event contains the information about what are the 475 resources being controlled and who can access the floor. 477 The XML document for the floorCreated event starts with a 478 'floorCreated' tag. Within the tag are one or more 'floor' elements. 479 The floor element has the type floorType. The following XML schema 480 fragment defines the floorCreated event. 482 483 484 485 486 487 488 490 Figure 1 shows an example of the floorCreated event. 492 493 494 495 mid:1 496 497 498 sip:user_a@foo.example.com 499 sip:user_b@foo.example.com 500 sip:user_c@foo.example.com 501 502 503 sip:user_a@foo.example.com 504 505 506 508 Figure 1: floorCreated event example 510 4.2 floorRemoved event 512 When a floor is removed for some set of resources, the conference 513 server SHOULD send a notification to the parties interested in this 514 event. 516 The XML document for floorRemoved event starts with a 'floorRemoved' 517 tag. Within the tag, there are zero or more 'resources' tag. If the 518 resources tag is not provided, it means the floor for all the 519 resources are removed. The following XML schema fragment defines the 520 floorRemoved event. 522 523 524 525 527 528 529 531 Figure 2 shows an example of the floorRemoved event. 533 534 535 mid:1 536 537 539 Figure 2: floorRemoved event example 541 4.3 configChanged event 543 When the configuration of the floor is changed, the conference server 544 SHOULD send a notification to the parties interested in this event. 545 The event contains the updated floor information. The following XML 546 schema fragment defines the configChanged event. 548 549 550 551 552 553 554 556 Figure 3 shows an example of the configChanged event. 558 4.4 floorChanged event 560 If the holders of one or more floors have changed, the conference 561 server SHOULD send a notification to the parties interested in this 562 event. At the same time, the conference server SHOULD send a re- 563 INVITE to the new holders to enable the sending of media. The UA 564 SHOULD not send media until it has received a floorChanged event. The 565 following XML schema fragment defines the floorChanged event. The 566 element 'holding' contains the new holders' information. 568 569 570 571 573 574 575 576 mid:1 577 578 579 580 sip:user_a@foo.example.com 581 582 583 585 Figure 3: configChanged event example 587 588 589 591 Figure 4 shows an example of the floorChanged event. 593 594 595 596 597 mid:1 598 599 600 sip:user_a@foo.example.com 601 602 603 605 Figure 4: floorChanged event example 607 4.5 queueChanged event 609 The conference server SHOULD send a notification to the parties 610 interested in the queueChanged event when the claim queue changes, 611 e.g., a new claim is added in or an existing claim is removed, 612 The queueChanged event contains the updated claim queue. The required 613 attribute 'timestamp' defines when the event happens. The optional 614 attribute 'url' provides the web URL having the updated claim queue. 615 If the 'url' attribute is not provided, there MUST be one or more 616 claims presented in the queueChanged tag. The following XML schema 617 fragment defines the queueChanged event. 619 620 621 622 624 625 626 627 628 630 Figure 5 shows an example of the queueChanged event. 632 5 Floor control commands 634 Table 2 shows the floor control commands. Floor control commands are 635 encapsulated in SOAP and are sent from the user to the conference 636 server in order to change floor status. 638 In Table 2, the 'Server' refers to 'Conference server' and the 'User' 639 refers to either 'Moderator' or 'Participant'. 641 5.1 CreateFloor command 643 The CreateFloor command creates a floor for some resources and users. 644 Only moderators can execute this command. 646 boolean CreateFloor(floorType floor) 648 The CreateFloor command takes one parameter, floor, to create a new 649 floor for some resources. The parameter 'floor' has the type 650 'floorType'. The response of the method is a boolean value 651 indicating whether the floor is successfully created or not. The 652 following XML schema fragment defines the CreateFloor command and the 653 response of the command. 655 656 657 659 sip:user_a@foo.example.com 660 661 mid:1 662 663 SIP conferencing 664 PT5M 665 666 668 sip:user_b@foo.example.com 669 670 mid:1 671 672 Floor control 673 PT10M 674 675 676 678 Figure 5: queueChanged event example 680 Command name Description Issuer -> Receiver 681 ________________________________________________________________________ 682 CreateFloor Create a floor for some resources Moderator -> Server 683 and participants. 684 RemoveFloor Remove floors for some Moderator -> Server 685 resources. 686 ChangeConfig Change the configuration of a floor Moderator -> Server 687 ClaimFloor Request a floor User -> Server 688 ReleaseFloor Give up a floor User -> Server 689 GrantFloor Grant a floor to some users Moderator -> Server 690 RevokeFloor Force release floors from some users Moderator -> Server 691 RemoveClaims Remove some existing floor claims User -> Server 692 ReorderClaims Reorder some claims in the queue Moderator -> Server 694 Table 2: Floor control commands 695 696 697 698 699 700 701 703 704 705 706 707 709 Figure 6 shows an example of using SOAP to carry the CreateFloor 710 command and the response of the CreateFloor command. 712 5.2 RemoveFloor command 714 The RemoveFloor command deletes floors for several resources. Only 715 moderators can execute this command. 717 boolean RemoveFloor(resourcesType resources) 719 The RemoveFloor command takes one parameter, resources, which has the 720 type resoursesType. The response of the method is a boolean value 721 indicating whether the floor has been successfully removed or not. 722 The following XML schema fragment defines the RemoveFloor command and 723 the response of the command. 725 726 727 728 729 730 731 732 735 736 737 738 739 mid:1 740 mid:2 741 742 743 sip:foo@examples.com 744 745 746 747 748 750 753 754 755 true 756 757 758 760 Figure 6: Use SOAP to encapsulate CreateFloor command 762 763 764 765 766 768 Figure 7 shows an example of using SOAP to carry the RemoveFloor 769 command. 771 5.3 ChangeConfig command 773 The ChangeConfig command changes a floor's configuration. Only 774 777 778 779 780 mid:1 781 mid:2 782 783 784 785 787 Figure 7: Use SOAP to encapsulate RemoveFloor command 789 moderators can execute this command. 791 boolean ChangeConfig(floorType floor) 793 The parameters for the ChangeConfig command is the same as that for 794 the CreateFloor command. The response indicates whether the 795 configuration is successfully changed or not. The following XML 796 schema fragment defines the ChangeConfig command and the response of 797 the command. 799 800 801 802 803 804 805 807 808 809 810 811 812 Figure 8 shows an example of using SOAP to carry the ChangeConfig 813 command. 815 818 819 820 821 822 mid:1 823 mid:2 824 825 826 sip:foo@examples.com 827 828 829 830 831 833 Figure 8: Use SOAP to encapsulate ChangeConfig command 835 5.4 ClaimFloor command 837 When a user wants to request a floor, the user's UA SHOULD send a 838 ClaimFloor command to the conference server. The holder of a floor 839 can also use ClaimFloor command to extend the holding time. To ask 840 for the extension, the new claim MUST have the same claimID as the 841 granted claim which enables the current holding. 843 boolean ClaimFloor(claimsType claims) 845 For new claims, the response of the method is a boolean value 846 indicating whether the claim has been successfully put into the claim 847 queue. For updating an existing claim, the response indicates whether 848 the existing claim get updated successfully. The following XML 849 schema fragment defines the ClaimFloor command and the response of 850 the command. 852 853 854 855 856 857 858 860 861 862 863 864 866 Figure 9 shows an example of using SOAP to carry the ClaimFloor 867 command. 869 5.5 ReleaseFloor event 871 To release a floor, the user's UA can send a ReleaseFloor command to 872 the conference server. The ReleaseFloor command takes one parameter, 873 holding, which has the type holdingType. The sender of the command 874 SHOULD be the same as the sub-element 'user' of the holding 875 parameter. 877 boolean ReleaseFloor (holdingType holding) 879 The following XML schema fragment defines the ReleaseFloor command. 881 882 883 884 885 886 887 889 890 892 895 896 897 898 902 sip:foo@examples.com 903 904 mid:1 905 mid:2 906 907 The auditorium is on fire! 908 P30S 909 910 911 912 913 915 Figure 9: Use SOAP to encapsulate ClaimFloor command 917 918 919 921 Figure 10 shows an example of using SOAP to carry the ReleaseFloor 922 command. 924 5.6 GrantFloor command 926 The GrantFloor command grants floors to one or more users. The 927 parameter 'holding', which has the type 'holdingType', defines the 928 relationship between the floors and the holders. The parameter 929 'claim', which has the type 'claimType', specifies the claim that the 930 floor is granted for. The claim MUST be removed from the queue. If 931 the 'claim' parameter is not provided, the GrantFloor command does 932 not affect the claim queue. Only moderators can execute this command. 934 937 938 939 940 941 mid:1 942 mid:2 943 944 945 sip:foo@examples.com 946 947 948 949 950 952 Figure 10: Use SOAP to encapsulate ReleaseFloor command 954 boolean GrantFloor(holdingType holding, claimType claim) 956 The following XML schema fragment defines the GrantFloor command. 958 959 960 961 962 963 964 965 967 968 969 970 971 972 Figure 11 shows an example of using SOAP to carry the GrantFloor 973 command. 975 978 979 980 981 982 mid:1 983 mid:2 984 985 986 sip:foo@examples.com 987 988 989 990 991 993 Figure 11: Use SOAP to encapsulate GrantFloor command 995 5.7 RevokeFloor command 997 The RevokeFloor command forces the release of a floor from the 998 current holders. 1000 boolean RevokeFloor(holdingType holding) 1002 The parameter holding indicates which floor should be revoked. Only 1003 moderators can execute this command. 1005 The following XML schema fragment defines the RevokeFloor command. 1007 1008 1009 1010 1011 1012 1014 1016 1017 1018 1019 1020 1022 Figure 12 shows an example of using SOAP to carry the RevokeFloor 1023 command. 1025 1028 1029 1030 1031 1032 mid:1 1033 mid:2 1034 1035 1036 sip:foo@examples.com 1037 1038 1039 1040 1041 1043 Figure 12: Use SOAP to encapsulate RevokeFloor command 1045 5.8 RemoveClaims command 1047 The RemoveClaims command removes several claims from the claim queue. 1048 Moderators can remove any claims. Participants can only remove their 1049 own claims. 1051 boolean RemoveClaims(claimsType claims) 1053 RemoveClaims command takes one parameter, claims. The return value 1054 indicates whether the claims have been removed successfully. The 1055 following XML schema fragment defines the RemoveClaims command. 1057 1058 1059 1060 1061 1062 1063 1065 1066 1067 1068 1069 1071 Figure 13 shows an example of using SOAP to carry the RemoveClaims 1072 command. 1074 5.9 ReorderClaims command 1076 The ReorderClaims command changes the order of the claims in the 1077 queue. Only moderators can execute this command. 1079 This command supports some simple operations to change a single 1080 claim's position. It takes three parameters. The parameter 1081 'resources' indicates the claim queue to operate. The parameter 1082 'claim' indicates which claim to move. The parameter 'operation' 1083 defines how to move the claim. 1085 boolean ReorderClaims(resourcesType resources, 1086 claimType claim, 1087 operationType operation) 1089 1092 1093 1094 1095 1096 sip:foo@examples.com 1097 1098 1099 1100 1101 1103 Figure 13: Use SOAP to encapsulate RemoveClaims command 1105 The following XML schema fragment defines the RemoveClaims command. 1107 1108 1109 1110 1111 1112 1113 1114 1115 1117 1118 1119 1120 1121 1123 Figure 14 shows an example of using SOAP to carry the RemoveClaims 1124 command. 1126 1129 1130 1131 1132 sip:foo@examples.com 1133 1134 1135 up 1136 2 1137 1138 1139 1140 1142 Figure 14: Use SOAP to encapsulate ReorderClaims command 1144 6 Floor Control Policies 1146 Each resource SHOULD have its own floor claim queue so that people 1147 interested in one resource will not get notified by the other 1148 resource's claim. However, if multiple resources need to be granted 1149 in atomic mode, e.g., access to all resources is granted or denied as 1150 a group, the conference server MUST use one floor claim queue for all 1151 the resources. The floor claim queue is created when executing the 1152 CreateFloor command. The parameter of the command defines the 1153 resources the floor applys. 1155 When a conference server receives a ClaimFloor command, the 1156 conference server SHOULD append the new claims at the end of the 1157 queue. If the current floor holder releases the floor, the claim at 1158 the front of the queue SHOULD automatically get the floor. The 1159 fulfilled claims MUST be removed from the claim queue. 1161 In one claim request, a user may claim multiple resources in 1162 different floor claim queues. The claim will be appended to all the 1163 applicable queues. To avoid potential deadlock, the claims in 1164 different queues MUST be granted independently. 1166 When a conference server receives a GrantFloor command, the 1167 conference server SHOULD queue the grant until there is an available 1168 floor. Occupied floor can be released by ReleaseFloor and RevokeFloor 1169 commands. 1171 A floor creator can specify some complicated floor control policies, 1172 for example, "senior members get 5 minutes to talk, junior members 2 1173 minutes and visitors 1 minute". There should be a floor control 1174 language to describe the policies and the wildcard 'xs:any' in the 1175 floorType can carry the policies to the conference server. 1177 7 Security consideration 1179 Conference server SHOULD use appropriate authentication to ensure the 1180 commands and events originated from trusted parties. Other SIP 1181 considerations apply [1]. 1183 8 IANA considerations 1185 8.1 New semantics for the "group" SDP Attribute 1187 Name being registered: FL 1189 Long-form name in English: Floor Control 1191 Type of name: Semantics for the "group" SDP Attribute 1193 Purpose: Group medias for floor control 1195 Reference: RFCxxxx (this document) 1197 Contact: Xiaotao Wu 1199 8.2 URN Sub-Namespace Registration 1201 This section registers a new XML namespace, as per the guidelines in 1202 [9] 1204 URI: urn:ietf:params:xml:ns:floor-control 1206 Registrant Contact: Xiaotao Wu 1208 XML: 1210 BEGIN 1211 1212 1214 1215 1216 1218 Conference Floor Control Namespace 1219 1220 1221

Namespace for Conference Floor Control

1222

application/floorcontrol+xml

1223

See RFCXXXX.

1224 1225 1226 END 1228 9 Call flows 1230 9.1 A user joins the conference and gets a floor 1232 Figure 15 shows the call flow when a user joins a moderated 1233 conference, claims for a floor and gets the floor. In the call flow, 1234 initially, the participant first sends an INVITE to the conference 1235 server to join the conference. Since the participant does not know 1236 whether the conference is moderated or not, there is no m=control 1237 line in the initial INVITE. In the 200 response from the conference 1238 server, the conference server uses a=type:moderated line to mute all 1239 the media tools of the participant. The conference server then sends 1240 a re-INVITE with m=control lines to establish floor control channels. 1241 The participants can then send SUBSCRIBE for floor control events and 1242 uses floor control channels for floor control commands. When the 1243 participant gets the floor, the conference server notifies all the 1244 users about the floor change and send a re-INVITE to unmute the media 1245 tools of the participant. 1247 10 Changes from Earlier Version 1249 10.1 Changes from Draft -03 1251 o Add IANA considerations for new semantics for "group" SDP attribute 1252 and URN Sub-Namespace registration 1254 10.2 Changes from Draft -02 1256 o Change the title from "Use of SIP and SOAP for Conference Floor Control" 1257 to "Use of Session Initiation Protocol (SIP) and Simple Object Access 1258 Protocol (SOAP) for Conference Floor Control". 1259 o If only part of the media are moderated, the 'a=type:moderated' line 1260 MUST NOT be used. The grouping of media channels and control channels 1261 can indicate which media are moderated. 1262 o Fix the lost part at the bottom of page 5. 1263 o Add ACK to Figure 15. 1264 o Explicitly describe the floor claim queue model in section 1 and 1265 section 3.6 1266 o Explain the reason to put floor control channel information in SDP. 1267 o Explain how to use Allow-Events header for floor status notification. 1268 o The m=control line can only be initiated from conference server's 1269 INVITE message. 1270 o Add the missing 's' line in the SDP example in Section 2.2. 1271 o Add "a=floorcontrol:" attribute in SDP for control URL information. 1272 o Add re-INVITE to Figure 15. 1273 o Add xs:any wildcard in floorType for additional information of a floor. 1274 o In claimType, the claimID MUST be globally unique. Define the way 1275 of updating an existing claim and extending the current floor holding 1276 time. 1277 o Add priority attribute to claimType. 1278 o Add floor control event examples. 1279 o Separate the references into normative and informative. 1280 o Clarified some wording. 1281 o Fixed some typographical errors. 1283 10.3 Changes from Draft -01 1285 o Reorganize section 2 into three subsections for clearer description of 1286 using SIP and SOAP for floor control 1287 o Provide namespace definitation for the elements defined by this 1288 specification 1289 o If the 'moderators' element is not provided in a floor, in floor control 1290 command, the person creates the floor will serve as the moderator, in 1291 floor control events, it means the information of moderators is hidden 1292 by conference server 1293 o Clarify that the whole string of the value in 'a=mid' line is used as 1294 the value for 'resourceType' 1295 o Clarify that for 'usersType', if the attribute 'url' is not provided, 1296 the list of the users MUST be provided. 1297 o For 'holdingType', if the 'users' element is not provided, it means no 1298 user is holding the floor. Previously, it defined as 'all users holding 1299 the floor'. 1300 o Remove 'maxOccurs=1' in schema fragment because by default, maxOccurs 1301 is 1 1302 o In 'claimType', change the element 'resource' to 'resources', and the 1303 type 'resourceType' to 'resourcesType'. 1305 Conference server participant 1306 | | 1307 | | 1308 +<-------- INVITE --------------+ 1309 | (audio,video,whiteboard) | 1310 | (a=mid:1 a=mid:2 a=mid:3) | 1311 | | 1312 +--------- 200 -------------->+ 1313 | (moderated) | (mute) 1314 | | 1315 |<--------- ACK ----------------| 1316 | | 1317 +------- re-INVITE ------------>+ 1318 | (m=control 5060 SIP SOAP) | 1319 | (a=mid:4) | 1320 | (a=group:FL 1 2 4) | 1321 +<-------- 200 ---------------+ 1322 | | 1323 |---------- ACK --------------->| 1324 | | 1325 +<------- SUBSCRIBE ------------+ 1326 | (Event: floor-control) | 1327 | | 1328 +-------- NOTIFY -------------->+ 1329 | (configChanged) | 1330 | | 1331 +<------- HTTP/SOAP ------------+ 1332 | (ClaimFloor) | 1333 moderator <---- NOTIFY ----+ | 1334 (queueChanged) | | 1335 | | 1336 moderator --- HTTP/SOAP -->+ | 1337 (GrantFloor) | | 1338 +-------- re-INVITE ----------->+ 1339 | (a=sendrecv) | (unmute) 1340 | | 1341 +<-------- 200 ---------------+ 1342 | | 1343 +--------- ACK -------------->+ 1344 | | 1345 +--------- NOTIFY ------------->+ 1346 | (floorChanged) | 1347 other | | 1348 participants <---- NOTIFY ----+ | 1349 (floorChanged) 1351 Figure 15: A user send INVITE to join the conference 1352 o Add an example of the SOAP response of CreateFloor command 1353 o Fix typo 'floor_remove' to 'RemoveFloor' in Figure 7 1355 11 Authors' Addresses 1357 Xiaotao Wu 1358 Dept. of Computer Science 1359 Columbia University 1360 1214 Amsterdam Avenue, MC 0401 1361 New York, NY 10027 1362 USA 1363 electronic mail: xiaotaow@cs.columbia.edu 1365 Petri Koskelainen 1366 Dept. of Computer Science 1367 Columbia University 1368 1214 Amsterdam Avenue, MC 0401 1369 New York, NY 10027 1370 USA 1371 electronic mail: petkos@cs.columbia.edu electronic mail: 1372 petri.koskelainen@nokia.com 1374 Henning Schulzrinne 1375 Dept. of Computer Science 1376 Columbia University 1377 1214 Amsterdam Avenue, MC 0401 1378 New York, NY 10027 1379 USA 1380 electronic mail: schulzrinne@cs.columbia.edu 1382 12 Normative References 1384 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 1385 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 1386 initiation protocol," RFC 3261, Internet Engineering Task Force, June 1387 2002. 1389 [2] A. B. Roach, "Session initiation protocol (sip)-specific event 1390 notification," RFC 3265, Internet Engineering Task Force, June 2002. 1392 [3] W3C, "Simple object access protocol (soap) 1.1." 1394 [4] S. Bradner, "Key words for use in rfcs to indicate requirement 1395 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 1397 [5] M. Handley and V. Jacobson, "SDP: session description protocol," 1398 RFC 2327, Internet Engineering Task Force, Apr. 1998. 1400 [6] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne, 1401 "Grouping of media lines in the session description protocol (SDP)," 1402 RFC 3388, Internet Engineering Task Force, Dec. 2002. 1404 [7] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task 1405 Force, May 1997. 1407 [8] R. Moats, "A URN namespace for IETF documents," RFC 2648, 1408 Internet Engineering Task Force, Aug. 1999. 1410 [9] M. Mealling, "The IETF XML registry," internet draft, Internet 1411 Engineering Task Force, July 2002. Work in progress. 1413 [10] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC 1414 3023, Internet Engineering Task Force, Jan. 2001. 1416 13 Informative References 1418 [11] C. Bormann, D. Kutscher, J. Ott, and D. Trossen, "Simple 1419 conference control protocol service specification," internet draft, 1420 Internet Engineering Task Force, Mar. 2001. Work in progress. 1422 [12] R. Malpani and L. A. Rowe, "Floor control for large-scale mbone 1423 seminars," in 1424 ACM Multimedia, (Seattle, Washington), Nov. 1997. 1426 [13] J. Rosenberg and H. Schulzrinne, "Models for multi party 1427 conferencing in SIP," internet draft, Internet Engineering Task 1428 Force, July 2002. Work in progress. 1430 [14] N. Deason, "SIP for SOAP sessions," internet draft, Internet 1431 Engineering Task Force, Apr. 2002. Work in progress. 1433 [15] H. S. P. Koskelainen and X. Wu, "A sip-based conference control 1434 framework," in NOSSDAV, (Miami, Florida), May 2002. 1436 [16] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming 1437 protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 1438 1998. 1440 Full Copyright Statement 1442 Copyright (c) The Internet Society (2003). All Rights Reserved. 1444 This document and translations of it may be copied and furnished to 1445 others, and derivative works that comment on or otherwise explain it 1446 or assist in its implementation may be prepared, copied, published 1447 and distributed, in whole or in part, without restriction of any 1448 kind, provided that the above copyright notice and this paragraph are 1449 included on all such copies and derivative works. However, this 1450 document itself may not be modified in any way, such as by removing 1451 the copyright notice or references to the Internet Society or other 1452 Internet organizations, except as needed for the purpose of 1453 developing Internet standards in which case the procedures for 1454 copyrights defined in the Internet Standards process must be 1455 followed, or as required to translate it into languages other than 1456 English. 1458 The limited permissions granted above are perpetual and will not be 1459 revoked by the Internet Society or its successors or assigns. 1461 This document and the information contained herein is provided on an 1462 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1463 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1464 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1465 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1466 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1468 Table of Contents 1470 1 Introduction ........................................ 2 1471 1.1 Conventions of This Document ........................ 3 1472 2 Using SIP and SOAP for Floor Control ................ 3 1473 2.1 SIP Event Notification for Tracking Floor Status .... 3 1474 2.2 Using SDP to Establish Floor Control Channel ........ 3 1475 2.3 Use of SOAP for Floor Control Commands .............. 5 1476 3 Datatypes in the floor control messages ............. 5 1477 3.1 floorType ........................................... 5 1478 3.2 resourcesType ....................................... 6 1479 3.3 usersType ........................................... 7 1480 3.4 moderatorsType ...................................... 7 1481 3.5 holdingType ......................................... 8 1482 3.6 claimType ........................................... 8 1483 3.7 claimsType .......................................... 9 1484 3.8 operationType ....................................... 10 1485 4 Floor control events ................................ 10 1486 4.1 floorCreated event .................................. 11 1487 4.2 floorRemoved event .................................. 12 1488 4.3 configChanged event ................................. 13 1489 4.4 floorChanged event .................................. 13 1490 4.5 queueChanged event .................................. 14 1491 5 Floor control commands .............................. 15 1492 5.1 CreateFloor command ................................. 15 1493 5.2 RemoveFloor command ................................. 17 1494 5.3 ChangeConfig command ................................ 18 1495 5.4 ClaimFloor command .................................. 20 1496 5.5 ReleaseFloor event .................................. 21 1497 5.6 GrantFloor command .................................. 22 1498 5.7 RevokeFloor command ................................. 24 1499 5.8 RemoveClaims command ................................ 25 1500 5.9 ReorderClaims command ............................... 26 1501 6 Floor Control Policies .............................. 28 1502 7 Security consideration .............................. 29 1503 8 IANA considerations ................................. 29 1504 8.1 New semantics for the "group" SDP Attribute ......... 29 1505 8.2 URN Sub-Namespace Registration ...................... 29 1506 9 Call flows .......................................... 30 1507 9.1 A user joins the conference and gets a floor ........ 30 1508 10 Changes from Earlier Version ........................ 30 1509 10.1 Changes from Draft -03 .............................. 30 1510 10.2 Changes from Draft -02 .............................. 30 1511 10.3 Changes from Draft -01 .............................. 31 1512 11 Authors' Addresses .................................. 33 1513 12 Normative References ................................ 33 1514 13 Informative References .............................. 34