Internet Draft E. Kim Internet Engineering Task Force NIST/ETRI draft-ekim-sipping-conf-floor-package-01.txt S.Kang February 2005 ETRI Expires August 2005 G. Camarillo Ericsson A Session Initiation Protocol (SIP) Event Package for Conference Floor State draft-ekim-sipping-conf-floor-package-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six Months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 20, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. E.Kim Expires - August 2005 [Page 1] Floor State Event Package February 2005 Abstract This document defines a conference floor event package for Session Initiation Protocol (SIP) conferences that require floor control. The conference floor event package allows users to subscribe to a conference floor server URIs. Notifications are sent about changes in the floor state of the conference and optionally about changes in the state of additional floor components of the conference. Subscriptions and notifications of conference floor are supported by an event package within the general SIP event notification framework. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. Terminology....................................................3 4. Background and Requirements....................................4 5. Conference Floor Event Package.................................5 5.1 Event Package Name.........................................5 5.2 Subscriber Generating a SUBSCRIBE Request..................5 5.3 Duration of the subscription...............................7 5.4 Notifier Generation of NOTIFY Requests.....................8 5.5 Subscriber Processing of NOTIFY Requests...................9 5.6 Handling of Forked Requests................................9 5.7 Rate of Notification.......................................9 6. Data format of the Floor state information.....................9 6.1 Floor Information.........................................10 6.2 Schema....................................................11 7. Examples......................................................13 8. Security Considerations.......................................15 9. References....................................................15 Acknowledgments..................................................16 Author's Addresses...............................................17 Intellectual Property Statement..................................18 E.Kim Expires - August 2005 [Page 2] Floor State Event Package February 2005 1. Introduction The Session Initiation Protocol (SIP) [1] conference package [3] defines an event package for SIP conferences providing the conference notification service as outlined in the SIP conferencing framework [4]. Here, we define conference floor event package for SIP conferences, which support conference floor event followed the rule defined in RFC3265, the general event notification framework of SIP [2]. This document aims at providing state information of floor control of a conference to its participants, no matter which participant supports specific floor control protocol or not. As long as a participant supports SIP conference floor event, even though it does not include a specific floor control protocol such as BFCP [5], it can get the changes of floor state of the conference it joins by subscribing the event. The conference floor server URI acts as the notifier, and provides clients with updates on conference floor state. Another possible scenario to get floor event information is that conference participants subscribe to the conference server, called focus [4], and the conference server requests the floor information to the floor control server and acts as the notifier. Focus and floor control server are logical entities, and communication between the focus and floor control server is out of the scope of the document. This document is intended to continue a discussion to explore standard operations for conference floor event package. Please send comments to the mailing list or 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant implementations. 3. Terminology Floor A permission to temporarily access or manipulate a specific shared resource or set of resources. E.Kim Expires - August 2005 [Page 3] Floor State Event Package February 2005 Floor control A mechanism that enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource. Floor control server A logical entity that maintains the state of the floor(s) including which floors exists, who the floor chairs are, who holds a floor, etc. Requests to manipulate a floor are directed at the floor control server. 4. Background and Requirements Floor control is one of the needed functionalities for multi-party conferences in which more than one speaker are participated. XCON WG is working on providing floor control functions for centralized conference, and builds a specific protocol named BFCP [5] and defines essential operations for floor control, so that a UA are able to request, be granted, release, and be withdrawn a floor by the protocol. It is also possible a participant in the conference who uses a BFCP get the information of the floor state by the protocol. There are, however, not every UA may have the specific floor control protocol, and sometimes it is okay to join the conference without the floor control protocol when it only want to be an audience which does not need to request floors in the conference. Especially, when one joins to a conference with a mobile wireless device which has lack of resources and bandwidth, it might not have enough resources to equip all the needed protocol. However, the audiences may still want to have the knowledge of the floors to understand what is going on in the conference such as who is talking now. In other hand, some participants want to get more specified floor state information than what the floor control protocol provides, although it uses the floor control protocol for obtaining and releasing the floors. Currently, all the changes about a requested floor are provided by request-answer mode in the BFCP. However, someone may want to get only 'granted' floor information rather than to get all the changes of the floor state, someone may want to only 5 recent issued floor information, or someone may want to get only audio floors information. Otherwise, someone may want to manipulate the time period when it receives the requesting floor information. To meet these requirements, this draft defines a floor state event package for SIP based conference aware UAs [4]. This event package can be used for such participants. Those who do not have the specific floor control protocol can get the floor state information by subscribing the floor state event. The floor state event package E.Kim Expires - August 2005 [Page 4] Floor State Event Package February 2005 includes event throttling and event filtering, so that it also satisfies those who want to richer information of the floors of the conference. 5. Conference Floor Event Package RFC3265 defining the general event notification framework of SIP [2] provides an extension to SIP [1] for events. This document is for specifying conference floor event. The general information required for SIP event package is following RFC3265. Conference aware SIP clients subscribe to the floor control server represented by URIs. The floor control server has all state information for floors in the conference [5], and it notifies the floor state to the subscribed participants. NOTE: Another possible scenario to get floor event information is that conference participants subscribe to the conference server, called focus [4], and the conference server requests the floor information to the floor control server and acts as the notifier. In this case, the floor event information can be merged into the conference event package. We need to discuss more if it is needed to be merged into the conference event package. 5.1 Event Package Name The name of the conference floor control event package is "floor". This value appears in the Event and Allow-Events header, as described in RFC3265. Example of usage: Event: floor 5.2 Subscriber Generating a SUBSCRIBE Request 5.2.1 SUBSCRIBE Bodies A SUBSCRIBE for a conference floor package MAY contain a body. The body can contain specific type of floor. In addition, the body can specify the rules for event throttling or/and event filtering, such as when a notification should be sent to, or what types of information should be contain in the notification. E.Kim Expires - August 2005 [Page 5] Floor State Event Package February 2005 The specified rule can be changed during a dialog by re-issuing a new SUBSCRIBE message. If a SUBSCRIBE within a dialog does not contain a filtering rule, it implies to apply the existing filtering rule. To support event filtering, all subscribers and notifiers SHOULD support the "application/floor-filter+xml" data format. The subscribe request MUST contain an Accept header field, if the body includes the filter, and the value MUST be "application/floor- filter+xml", and MAY include any other types capable of representing dialog state. A SUBSCRIBE for a conference floor package MAY be sent without a body. This implies the default subscription filtering policy. By the default policy, notifications are generated whenever if there is any change in the state of the floors in the conference. Notifications normally contain partial state that has changed. The exception is a NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the full state of the information requested by the subscriber. 5.2.2 Event Filtering The floor state changes MAY occur quite often when multiple speakers try to get the floor in a very aggressive conversation. The audience MAY not want to get all the changes of the event, and only want to get essential changes among them such as floor "granted", or only want to get the most recent 5 changes. Sometimes, subscribers MAY want to get only "audio" floor information, ignoring video or whiteboard floor event changes which are simply recognizable via application. Multiple filters MAY be included in one SUBSCRIBE message, as required. To filter floor event information, the body has the root element of "floor-filters". The element is consisted of one or more "filter" elements, which describes specific rules for notification. The "filter" has a mandatory attribute "id", and includes an optional "floor-info" sub-element and an optional "floor-number" sub-element. The "floor-info" sub-element is used for applying the filter by specific floor state information. The sub-element has an optional "floor-id" sub-element and an optional "resource" sub-element and an optional "state" sub-element. The "resource" sub-element indicates audio, video, whiteboard, or other resources. The "state" sub-element has the value of "requested", "granted", "accepted", "released", and "withdrawn". E.Kim Expires - August 2005 [Page 6] Floor State Event Package February 2005 The "floor-number" sub-element is used for specifying the specific number of floor events. Each filter is defined by "include" or "exclude". 5.2.3 Filtering examples If a subscriber want to get a recent 5 event changes via the responding notification, the SUBSCRIBE body contains the following information. If a subscriber want to get only "granted" "audio" information, but want to exclude a specific floor-id, the SUBSCRIBE body contains the following information. 5.3 Duration of the subscription The duration of this subscription is following the rule of the conference event package [3]. E.Kim Expires - August 2005 [Page 7] Floor State Event Package February 2005 5.4 Notifier Generation of NOTIFY Requests 5.4.1 Notifier Processing of SUBSCRIBE Requests The conference floors information contains sensitive information as the conference information [4]. When a conference URI acts as a notifier, it treats the floors information as the same policy with the conference information. When a floor control server acts as a notifter of this event, the authorization policy should be made. In a basic recommendation policy, all subscriptions SHOULD be authenticated and then authorized before approval. If the SUBSCRIBE message includes filter with the data format of "application/floor-filter+xml", and if the notifier is able to interpret the filter, it MUST generate the notifications by the request. If it cannot support the filter, it MUST send an error message. 5.4.2 Notify bodies As described in RFC 3265 [2], the NOTIFY message will contain bodies that describe the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE, or a package-specific default if the Accept header field was omitted from the SUBSCRIBE. In this event package, the body of the notification contains floors document. This document describes the state of floors of a conference. All subscribers and notifiers MUST support the "application/floor-info+xml" data format described in Section 4. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/floor-info+xml". If the header field is present, it MUST include "application/floor-info+xml", and MAY include any other types capable of representing dialog state. 5.4.3 Generation rule of NOTIFY Requests Notifications SHOULD be generated for the conference every time when a change is made in the state in any of the information delivered to the subscriber. The changes generally occur when a floor is requested, accepted, granted, released, or withdrawn to a participant, and when a floor holder is changed. When the notifier receives a SUBSCRIBE with filtering or event throttling rule, notification SHOULD be generated for the conference E.Kim Expires - August 2005 [Page 8] Floor State Event Package February 2005 every time when the specified rule requested by the subscriber is satisfied. The notifier incorporate, re-apply, or remove when it receives new SUBSCRIBE message with new rule to be added, modified, or removed from the existing rule. 5.5 Subscriber Processing of NOTIFY Requests The NOTIFY for the conference floor event package will only contain information about those floors of which state has changed. To construct a coherent view of the total state of all floors, a subscriber to the event package will need to combine NOTIFYs received over time. If the NOTIFY indicates that a subscription has been terminated, the subscription is assumed to be terminated. The basic rule for events handling is applied as the RFC3265 [2] states. 5.6 Handling of Forked Requests The conference floors are handled in centralized way. Thus, SUBSCRIBE requests for this event should normally not be forked. 5.7 Rate of Notification RFC 3265 [2] requires each package to specify the maximum rate at which notifications can be sent. With consideration of the congestion control, it is RECOMMENDED that the server not generate notifications for a single subscriber at a rate faster than once every 5 seconds, applying the same rule with the conference event package [4]. If the SUBSCRIBE contain any specified rule for the duration, it follows the rule. 6. Data format of the Floor state information XML document is used for the conference floor information. It MUST be well-formed and SHOULD be valid. The document SHOULD be based on XML 1.0 and MUST be encoded using UTF-8. The namespace URI for elements defined by this specification is a URN [6], using the namespace identifier 'ietf' defined by [7] and extended by [8]. This URN is: E.Kim Expires - August 2005 [Page 9] Floor State Event Package February 2005 urn:ietf:params:xml:ns:floor-info A conference floor information document begins with the root element tag "floor-info". 6.1 Floor Information Floor information has the root element "floors-info". This element has an attribute, "conf-uri". The attribute is the identifier of the conference in which the floors are exchanged. The root element also has zero or more "floor-info" sub-element. The "floor-info" has one mandatory attribute, "floor-id". It is the identifier of a floor. If SDP or BFCP assigns a floor-id for a resource, this value is matched with the value. The "floor-info" has one "resource" sub-element, which identifies the type (audio, video) or codec of the floor resource. It has zero or more "chairs" sub-element that gives the information of chairs who take charge of the floor. It has "state" sub-element that explains current status of the floor, such as the floor is granted, released, etc. 6.1.1 Resource element The resource element specifies the resource name matched with the floor. Generally it will be the same with the media name appeared in the m lines of SDP. 6.1.2 Chairs element The chairs element has zero or more chair element which is describing the URIs of the chair. More than one chair can take charge of a floor. If this element is used, it SHOULD show the all members of the chair for the floor. 6.1.3 State element The state element shows the current state of the floor, and the time information about the floor. It has a "floorstate" element,which has a mendatory "transaction" attribute identifying the floor request. The "floorstate" element also has one or more "users" sub-element, one or more "floor-action" sub-element, zero or more "action-time" sub-element and "expiration" sub-element. The "users" element has one or more user element which is identified by URIs. The user element is used for reporting the participants who currently make an action about the floor. E.Kim Expires - August 2005 [Page 10] Floor State Event Package February 2005 The "floor-action" element is for the state of the floor related any action taken for the floor. It has the value of "requested," "accepted," "granted," "released," or "withdrawn". The following explains the usage of the values. requested: The floor is requested. accepted: The requested floor is accepted by floor server. granted: The requested floor is granted by floor server. In an internal operation, floor server sends the request to the floor chair(s), and the request is admitted by the floor chair(s). The specific functional behavior is out of the scope of this document and it will be performed by a floor control protocol. released: The floor holder releases the floor. withdrawn: The floor which has been holding by someone is enforced to be taken back by some reason. The reason will be dependant on the policy of a floor control protocol. The "action-time" element notifies the time when the floor operation is made. The "expiration" is for the time information for the floor, especially notifies the expiration time. 6.2 Schema E.Kim Expires - August 2005 [Page 11] Floor State Event Package February 2005 E.Kim Expires - August 2005 [Page 12] Floor State Event Package February 2005 7. Examples The following is an example document of floor information in a conference. audio granted 2005-02-17T09:30:47 2005-02-17T09:45:47 requsted 2005-02-17T09:32:00 whiteboard E.Kim Expires - August 2005 [Page 13] Floor State Event Package February 2005 granted 2005-02-17T09:30:47 2005-02-17T09:35:47 requsted 2005-02-17T09:32:00 If the subscriber designates a filter indicating that only "granted" event changes should be included for the floor event, the notification MUST be generated as the following: audio granted 2005-02-17T09:30:47 2005-02-17T09:45:47 whiteboard granted E.Kim Expires - August 2005 [Page 14] Floor State Event Package February 2005 2005-02-17T09:30:47 2005-02-17T09:35:47 If the subscriber designates a filter indicating that only "granted" "audio" event changes should be included for the floor event, the notification MUST be generated as the following: audio granted 2005-02-17T09:30:47 2005-02-17T09:45:47 8. Security Considerations Conference floor information is very sensitive information, so that the server MUST use appropriate authentication to ensure the commands to manipulate or interact the data originated from trusted parties. Other SIP considerations apply. The further concerned security issues will be identified as the further works go on. 9. References [1] J. Rosenberg, H. Schulzrinne, et al, "SIP: Session Initiation Protocol, " RFC3261, Internet Engineering Task Force, Jun. 2002. E.Kim Expires - August 2005 [Page 15] Floor State Event Package February 2005 [2] A. Roach, "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [2] J. Rosenberg, "A framework for conferencing with the session initiation protocol, " Internet Draft, Internet Engineering Task Force, Feb. 2003. Work in progress. [3] J. Rosenberg, H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Conference State, " Internet Draft, Internet Engineering Task Force, Jul. 2004. Work in progress. [4] P. Koskelainen, "Requirements for conference policy data, " Internet Draft, Internet Engineering Task Force, Feb. 2003. Work in progress. [4] W3C, "Simple Object Access Protocol (SOAP) 1.1. " [5] G. Camarillo, J. Ott, K. Drage, "The Binary Floor Control Protocol (BFCP), " Internet Draft, Internet Engineering Task Force, April. 2004. Work in progress. [6] R. Moats, "URN syntax, " RFC2141, Internet Engineering Task Force, May 1997. [7] R. Moats, "A URN namespace for IETF documents, " RFC2648, Internet Engineering Task Force, Aug. 1999. [8] M. Mealling, "The IETF XML registry, " Internet Draft, Internet Engineering Task Force, Jul. 2002. Work in progress. Acknowledgments E.Kim Expires - August 2005 [Page 16] Floor State Event Package February 2005 Author's Addresses Eunsook Kim 100 Bureau Drive Gaithersburg MD 20899 USA E-mail: eunah@nist.gov / eunah@etri.re.kr Shin-Gak Kang 361 Gajeong-Dong Yuseong-Gu Deajon 305-350 Korea E-mail: sgkang@etri.re.kr Gonzalo Camarillo Hirsalantie 11 Jorvas 02420 Finland E-mail: Gonzalo.Camarillo@ericsson.com E.Kim Expires - August 2005 [Page 17] Floor State Event Package February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement E.Kim Expires - August 2005 [Page 18] Floor State Event Package February 2005 Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. E.Kim Expires - August 2005 [Page 19]