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