Internet Engineering Task Force SIPPING WG Internet Draft J. Rosenberg dynamicsoft H. Schulzrinne Columbia U. draft-rosenberg-sip-call-package-01.txt March 1, 2002 Expires: September 2002 SIP Event Packages for Call Leg and Conference State STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document defines two new event packages for the SIP Events architecture, along with two new data formats used in notifications for those packages. The first is a call-leg package, and the second is a conference package. The call-leg package allows users to subscribe to another user, an receive notifications about the changes in state of call legs that the user is involved in. The conference package allows users to subscribe to a URL that is associated with a conference. Notifications are sent about changes in the membership of this conference, changes in active speaker, and media mixing information. These general purpose packages can enable many new SIP services, including single line extension, automatic callback, unattended consultation-hold transfer, call park and pickup, and IM- J. Rosenberg et. al. [Page 1] Internet Draft call-pkg March 1, 2002 a-call. J. Rosenberg et. al. [Page 2] Internet Draft call-pkg March 1, 2002 Table of Contents 1 Introduction ........................................ 5 2 Dialog Event Package ................................ 6 2.1 Event Package Name .................................. 6 2.2 Event Package Parameters ............................ 6 2.3 SUBSCRIBE Bodies .................................... 6 2.4 Subscription Duration ............................... 6 2.5 NOTIFY Bodies ....................................... 7 2.6 Notifier Processing of SUBSCRIBE Requests ........... 7 2.7 Notifier Generation of NOTIFY Requests .............. 8 2.8 Subscriber Processing of NOTIFY Requests ............ 9 2.9 Handling of Forked Requests ......................... 9 2.10 Rate of Notifications ............................... 9 2.11 State Agents ........................................ 9 3 Dialog Data Format .................................. 9 3.1 Structure of Dialog Information ..................... 10 3.2 Dialog Sub-Elements ................................. 11 3.2.1 Status .............................................. 12 3.2.2 Local SDP ........................................... 12 3.2.3 Remote SDP .......................................... 12 3.2.4 Route Set ........................................... 13 3.2.5 Remote Target ....................................... 13 3.2.6 Local CSeq .......................................... 13 3.2.7 Remote CSeq ......................................... 14 4 Conference Event Package ............................ 14 4.1 Event Package Name .................................. 15 4.2 Event Package Parameters ............................ 15 4.3 SUBSCRIBE Bodies .................................... 15 4.4 Subscription Duration ............................... 15 4.5 NOTIFY Bodies ....................................... 15 4.6 Notifier Processing of SUBSCRIBE Requests ........... 16 4.7 Notifier Generation of NOTIFY Requests .............. 16 4.8 Subscriber Processing of NOTIFY Requests ............ 16 4.9 Handling of Forked Requests ......................... 17 4.10 Rate of Notifications ............................... 17 4.11 State Agents ........................................ 17 5 Conference Data Format .............................. 17 5.1 Structute of the Format ............................. 17 5.2 User Sub-Elements ................................... 18 5.3 Example ............................................. 19 6 Relationship to User Presence ....................... 20 7 Open Issues and To-Dos .............................. 20 J. Rosenberg et. al. [Page 3] Internet Draft call-pkg March 1, 2002 8 Security Considerations ............................. 20 9 IANA Considerations ................................. 20 10 Acknowledgements .................................... 21 11 Changes since -00 ................................... 21 12 Authors Addresses ................................... 21 13 Normative References ................................ 21 14 Informative References .............................. 22 J. Rosenberg et. al. [Page 4] Internet Draft call-pkg March 1, 2002 1 Introduction The SIP Events framework [1] defines general mechanisms for subscription to, and notification of, events within SIP networks. It introduces the notion of a package, which is a specific "instantiation" of the events mechanism for a well-defined set of events. Packages have been defined for user presence [3], watcher information [4], and message waiting indicators [5], amongst others. Here, we define two new packages - one for dialogs, and the other for conferences. The need for these packages is driven based on the fact that many applications are driven off of knowledge about the progress of dialogs and conferences. In the case of dialogs, we see many potential applications that require knowledge of dialog state: Automatic Callback: In this basic PSTN application, user A calls user B. User B is busy. User A would like to get a callback when user B hangs up. When B hangs up, user A's phone rings. When A picks it up, they here ringing, and are being connected to B. In VoIP, this requires A to receive a notification when the dialogs at A are complete. Presence-Enabled Conferencing: In this application, a user A wishes to set up a conference call with users B and C. Rather than scheduling it, it is to be created automatically when A, B and C are all available. To do this, the server providing the application would like to know whether A, B and C are "online", not idle, and not in a phone call. Determining whether or not A, B and C are in calls can be done in two ways. In the first, the server acts as a call stateful proxy for users A, B and C, and therefore knows their call state. This won't always be possible, however, and it introduces scalability, reliability, and operational complexities. Rather, the server would subscriber to the dialog state of those users, and receive notifications as it changes. This enables the application to be provided in a distributed way; the server need not reside in the same domain as the users. IM Conference Alerts: In this application, a user can get an IM sent to their phone whenever someone joins a conference that the phone is involved in. The IM alerts are generated by an application separate from the conference server. In general, defining dialog and conference state packages allows for construction of distributed applications, where the application requires information on dialog and conference state, but is not co- J. Rosenberg et. al. [Page 5] Internet Draft call-pkg March 1, 2002 resident with the end user or conference server. We think this is a very important piece of the SIP services model. 2 Dialog Event Package This section provides the details for defining a SIP Events package, as specified by [1]. 2.1 Event Package Name The name of this event package is "dialog". This package name is carried in the Event and Allow-Events header, as defined in [1]. 2.2 Event Package Parameters This package does not define any event package parameters. 2.3 SUBSCRIBE Bodies A SUBSCRIBE for a dialog package MAY contain a body. This body defines a filter to apply to the subscription. A SUBSCRIBE for a dialog package MAY be sent without a body. This implies the default subscription filtering policy. The default policy is: o Notifications are generated every time there is any change in the state of any dialogs for the user identified in the request URI of the SUBSCRIBE. o Notifications do not normally contain full state; rather, they only indicate the state of the dialog whose state has changed. The exception is a NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the complete view of dialog state. o The notifications contain the identities of the participants in the dialog, and the dialog identifiers. Additional information, such as the route set, remote target URI, CSeq numbers, SDP information, and so on, are not included normally unless explicitly requested and/or explicitly authorized. 2.4 Subscription Duration Dialog state changes fairly quickly; once established, a typical phone call lasts a few minutes (this is different for other session types, of course). However, the interval between new calls is typically infrequent. J. Rosenberg et. al. [Page 6] Internet Draft call-pkg March 1, 2002 We do note that there are two distinct use cases for dialog state. The first is when a subscriber is interested in the state of a specific dialog (and they are authorized to find out about just the state of that dialog). In that case, when the dialog terminates, so too does the subscription. In these cases, the refresh interval can be very long, since there exists an easy alternative way to destroy subscription state. As a result, the default duration of these subscriptions is one day. The subscriber MAY request other durations. In another case, a subscriber is interested in the state of all call legs for a specific user. In these cases, a shorter interval makes more sense. The default is one hour for these subscriptions. OPEN ISSUE: We should probably have a single default subscription duration. 2.5 NOTIFY Bodies The body of the notification contains a dialog information document. The format of this document is described in Section 3. Its MIME type is "application/dialog-info+xml". All subscribers MUST support this format, and MUST list its type in any Accept header in the SUBSCRIBE. When no Accept header is present in the SUBSCRIBE, its default value is "application/dialog-info+xml". Other dialog information formats might be defined in the future. In that case, the subscriptions MAY indicate support for other formats. However, they MUST always support and list "application/dialog- info+xml" as an allowed format. Of course, the notifications generated by the server MUST be in one of the formats specified in the Accept header in the SUBSCRIBE request. 2.6 Notifier Processing of SUBSCRIBE Requests The dialog information for a user contains very sensitive information. Therefore, all subscriptions SHOULD be authenticated and then authorized before approval. Authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made. It is RECOMMENDED that if the policy of a user is that A is allowed to call them, dialog subscriptions from user A be allowed. However, the information provided in the notifications does not contain any dialog identification information; merely an indication of whether the user in in one or more calls, or not. Specifically, they should J. Rosenberg et. al. [Page 7] Internet Draft call-pkg March 1, 2002 not be able to find out any more information than if they sent an INVITE. It is RECOMMENDED that if a user agent registers with the address- of-record X, that this user agent authorize subscriptions that come from any entity that can authenticate itself as X. Complete information on the dialog state SHOULD be sent in this case. This authorization behavior allows a group of devices representing a single user to all become aware of each other's state. This is useful for applications such as single-line-extension. 2.7 Notifier Generation of NOTIFY Requests Notifications are generated for the dialog package when a new dialog comes into existence at a UA, or when the state of an existing dialog changes. For the purposes of this package, we define the states of a dialog through numeric codes. These codes are equivalent to the most recent SIP status codes sent in response to the INVITE which created the call leg. The status code "0" is reserved for the case where no response has yet been received or sent. When a UAC initially creates an INVITE to establish a call, this causes a change to state "0". When it receives the first non-100 provisional response, the state changes to the value of that status code. Any further provisional responses cause the UA to change state to the value of that status code. When a final response is received, the state changes to the value of that response. If the response was a non-200, the dialog is considered terminated, and no further state changes are possible. Multiple 2xx responses received create additional dialogs, each with the state of that specific 2xx. When a UAS initially receives an INVITE to establish a call, this causes a change to the state of the provisional response which was sent. Any subequent provisional responses cause a change in state to the value of that response. A final response causes a transition in state to that response code. There is no change in state when the ACK arrives. However, if no ACK is received, and the UAS destroys the call, the state changes to a value of -1. When the call is terminated as a result of a BYE, the state changes to -1. OPEN ISSUE: This is kind of ugly. We could alternately define a more formal state machine. J. Rosenberg et. al. [Page 8] Internet Draft call-pkg March 1, 2002 2.8 Subscriber Processing of NOTIFY Requests The SIP Events framework expects packages to specify how a subscriber processes NOTIFY requests in any package specific ways, and in particular, how it uses the NOTIFY requests to contruct a coherent view of the state of the subscribed resource. Typically, the NOTIFY for the dialog package will only contain information about those dialogs whose state has changed. To construct a coherent view of the total state of all dialogs, a subscriber to the dialog package will need to combine NOTIFYs received over time. The subscriber maintains is complete dialog list in a table, indexed by the id. This ID is different from the formal dialog ID as defined in [2], which is the concatenation of the local tag, remote tag, and Call-Id. This ID is conveyed in the id attribute of the dialog element of the "application/dialog-info+xml" type. If the dialog information in a NOTIFY has a dialog listed with an ID not in the table, an entry is added to that table. The version number from the dialog element is also extracted, and placed in the table. If the dialog information in a NOTIFY has a dialog listed with an ID in the table, and the version in the NOTIFY is greater than the version stored in the table, the dialog information in the table for that dialog is updated, including the version number. If a dialog is updated such that its status is now "-1", that entry MAY be removed from the table at any time. 2.9 Handling of Forked Requests A forked SUBSCRIBE request for dialog state can install multiple subscriptions. Subscribers to this package MUST be prepared to install subscription state for each NOTIFY generated as a result of a single SUBSCRIBE. 2.10 Rate of Notifications For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server not generate notifications for a single subscriber at a rate faster than once every 5 seconds. 2.11 State Agents Dialog state is ideally maintained in the user agents in which the dialog resides. Therefore, the elements that maintain the dialog are the ones best suited to handle subscriptions to it. Therefore, the usage of state agents is NOT RECOMMENDED for this package. 3 Dialog Data Format J. Rosenberg et. al. [Page 9] Internet Draft call-pkg March 1, 2002 We specify an XML-based data format to describe the state of a dialog. The MIME type for this format is "application/dialog- info+xml", consistent with the recommendations provided in RFC 3023 [6]. 3.1 Structure of Dialog Information A dialog-info document starts with a user tag that identitifies the user. Within that tag are a series of dialog tags. Each of those use attributes to identify the dialog and provide its version number. There are also attributes to provide the formal dialog identifier, using the local and remote tags, and the Call-ID. Additional attributes are present to specify the local and remote URIs. There is also an attribute that indicates whether the user initiated this dialog or not. Within the dialog tags are a single mandatory tag which contains the status, followed by a series of optional tags that contain additional information about the dialog. The top level tag is user: The mandatory uri attribute is the identifier of the user whose dialog state is being reported. What follows is a series of dialog tags: The local-uri, local-tag, remote-uri, remote-tag and call-id attributes convey their corresponding components of the dialog state as defined in [2]. The direction attribute is "initiator" if the user J. Rosenberg et. al. [Page 10] Internet Draft call-pkg March 1, 2002 initiated this dialog, and "recipient" if it did not. The remote tag attribute won't be present if there is only a "half-dialog", resulting from generation of a request that can create a dialog. For example, if a UAC sends an INVITE that looks like, in part: INVITE sip:callee@foo.com SIP/2.0 From: sip:caller@bar.com;tag=123 To: sip:callee@foo.com Call-ID: 987@1.2.3.4 the dialog tag sent out in a notification might looks like: If a 200 OK is received, which looks like, in part: SIP/2.0 200 OK From: sip:caller@bar.com;tag=123 To: sip:callee@foo.com;tag=abc Call-ID: 987@1.2.3.4 The dialog is now confirmed, and the notification sent out will have a dialog tag which looks like: 3.2 Dialog Sub-Elements There are many sub-elements defined for the dialog element. J. Rosenberg et. al. [Page 11] Internet Draft call-pkg March 1, 2002 3.2.1 Status The only mandatory sub-element of dialog is status. The mandatory code attribute contains the status code. This is the SIP response code last sent or received for this leg in the initial INVITE that established the leg. If no response has been sent or received, the value of zero is used. If the call ends, a value of -1 is used. The value within the status tag is a textual phrase that can be rendered to described call status. The reason phrase from the response is RECOMMENDED. Example: Ringing 3.2.2 Local SDP The local SDP tag contains the SDP used by the notifier for its end of the dialog. This tag should generally NOT be included in the notifications, unless explicitly requested by the subscriber. The SDP is included, verbatim, between the tags. 3.2.3 Remote SDP The remote SDP tag contains the SDP used by the notifier for the other end of the dialog. This tag should generally NOT be included in the notifications, unless explicitly requested by the subscriber. J. Rosenberg et. al. [Page 12] Internet Draft call-pkg March 1, 2002 The SDP is included, verbatim, between the tags. 3.2.4 Route Set The route-set tag contains the route set as constructed by the user agent for this dialog, as defined in RFC BBBB [2]. It is constructed from the Record-Route header field used for this dialog. This tag should generally NOT be included in the notifications, unless explicitly requested by the subscriber. The route set is included verbatim. It is structured as a comma separated list of URLs. Example: sip:proxy2.example.com;lr 3.2.5 Remote Target The remote-target contains the remote-target URI as constructed by the user agent for this dialog, as defined in RFC BBBB [2]. It is constructed from the Contact header of the INVITE. This tag should generally not be included in notifications, unless explicitly requested by the subscriber. The remote target URI is included verbatim between the tags. Example: sip:user@pc33.example.com 3.2.6 Local CSeq J. Rosenberg et. al. [Page 13] Internet Draft call-pkg March 1, 2002 The local-cseq tag contains the most recent value of the CSeq header used by the UA in an outgoing request on the dialog. This tag should generally NOT be included in the notifications, unless explicitly requested by the subscriber. The numeric value of the CSeq is included as the CDATA. 3.2.7 Remote CSeq The remote-cseq tag contains the most recent value of the CSeq header seen by the UA in an incoming request on the dialog. This tag should generally NOT be included in the notifications, unless explicitly requested by the subscriber. The numeric value of the CSeq is included as the CDATA. 4 Conference Event Package The conference event package allows a user to subscribe to a conference. A conference is a collection of users that are all able to communicate with each other. Generally, when multicast is not used, a conference is associated by a set of dialogs that have their media mixed together. This is true for all of the non-multicast models in [7]. However, some of the models use topologies where there is no root to which all dialogs are connected. These topologies do not work well with the mechanism here. This package allows a user to subscribe to a conference, identified by a SIP URI. Ideally, this SIP URI routes the SUBSCRIBE to the entity acting as the root of the topology (which is why it doesn't work well for the non-centralized topologies). The notifications contain information on the participants in the conference. The specific information conveyed is: o The SIP URI identifying the user. o The dialog state associated with that users attachment to the conference. J. Rosenberg et. al. [Page 14] Internet Draft call-pkg March 1, 2002 o Their status in the conference (active, declined, departed). o Their status in terms of receiving media in the conference. This section provides the details for defining a SIP Events package, as specified by [1]. 4.1 Event Package Name The name of this event package is "conference". This package name is carried in the Event and Allow-Events header, as defined in [1]. 4.2 Event Package Parameters This event package does not define any event package parameters. 4.3 SUBSCRIBE Bodies A SUBSCRIBE for a dialog package MAY contain a body. This body defines a filter to apply to the subscription. A SUBSCRIBE for a conference package MAY be sent without a body. This implies the default subscription filtering policy. The default policy is: o Notifications are generated every time there is any change in the set of users participating in the conference, or a change their state (dialog state, media mixing state, etc.) o Notifications do not normally contain full state; rather, they only indicate the state of the participant whose state has changed. The exception is a NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the complete view of conference state. o For a given user, the notifications contain the identity information and status. 4.4 Subscription Duration The default expiration time for a subscription to a conference is one hour. Of course, once the conference ends, all subscriptions to that particular conference are terminated, with a reason of "noresource" [1]. 4.5 NOTIFY Bodies The body of the notification contains a conference information J. Rosenberg et. al. [Page 15] Internet Draft call-pkg March 1, 2002 document. The format of this document is described in Section 5. Its MIME type is "application/conference-info+xml". All subscibers MUST support this format, and MUST list its type in an Accept header in the SUBSCRIBE. The default value for the Accept header when it is not present in a request is "application/conference-info+xml". Other conference information formats might be defined in the future. In that case, the subscriptions MAY indicate support for other formats. However, they MUST always support and list "application/conference-info+xml" as an allowed format. Of course, the notifications generated by the server MUST be in one of the formats specified in the Accept header in the SUBSCRIBE request. 4.6 Notifier Processing of SUBSCRIBE Requests The conference information contains very sensitive information. Therefore, all subscriptions SHOULD be authenticated and then authorized before approval. Authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made. It is RECOMMENDED that all users in the conference be allowed to subscribe to the conference. 4.7 Notifier Generation of NOTIFY Requests Notifications SHOULD be generated for the conference whenever a new participant joins, a participant leaves, and a dial-out attempt succeeds or fails. Notifications MAY be generated for the conference whenever the media mixing status of a user changes. 4.8 Subscriber Processing of NOTIFY Requests The SIP Events framework expects packages to specify how a subscriber processes NOTIFY requests in any package specific ways, and in particular, how it uses the NOTIFY requests to contruct a coherent view of the state of the subscribed resource. Typically, the NOTIFY for the conference package will only contain information about those users whose state has changed. To construct a coherent view of the total state of the entire conference, a subscriber to the conference package will need to combine NOTIFYs received over time. The subscriber maintains is complete user list in a table, indexed by the id in the dialog element. If the dialog information in a NOTIFY has a dialog listed with an ID not in the table, an entry is added to that table. The version number from the J. Rosenberg et. al. [Page 16] Internet Draft call-pkg March 1, 2002 dialog element is also extracted, and placed in the table. If the dialog information in a NOTIFY has a dialog listed with an ID in the table, and the version in the NOTIFY is greater than the version stored in the table, the dialog information in the table for that dialog is updated, including the version number. If a dialog is updated such that its status is now "-1", that entry MAY be removed from the table at any time. 4.9 Handling of Forked Requests By their nature, the conferences supported by this package are centralized. Therefore, SUBSCRIBE requests for a conference should not generally fork. Users of this package MUST NOT install more than a single subscription as a result of a single SUBSCRIBE request. 4.10 Rate of Notifications For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server not generate notifications for a single subscriber at a rate faster than once every 5 seconds. 4.11 State Agents Conference state is ideally maintained in the element in which the conference resides. Therefore, the elements that maintain the conference are the ones best suited to handle subscriptions to it. Therefore, the usage of state agents is NOT RECOMMENDED for this package. 5 Conference Data Format The conference data format is an XML document of MIME type "application/conference-info+xml", consistent with the recommendations provided in RFC 3023 [6]. 5.1 Structute of the Format The conference data format has the top level tag of conference. It consists of a set of sub-tags of type user, which contain information on the users in the conference. Each user tag contains the identity of the user, their dialog information, their status in the conference, and their media reception information. The top level tag is conference: J. Rosenberg et. al. [Page 17] Internet Draft call-pkg March 1, 2002 The mandatory uri attribute contains the URI used to join the conference call (and to subscribe to its state). What follows are a series of user tags: The uri attribute contains the URI for the user. This is a logical identifier, not a machine specific one (i.e., its taken from the To/From, not the Contact). The name is a textual name for rendering to a human. It is ususally taken from the display name. 5.2 User Sub-Elements The sub-elements of the user tag are status, dialog aned media- status. Status contains the status of the user in the conference. The statuses have the following meaning: active: The user is in an active dialog with the conference host. departed: The user sent a BYE, thus leaving the conference. booted: The user was sent a BYE by the conference host, booting them out of the conference. failed: The conference host is a dialout conference server, and its attempt to contact the specific user resulted in a non-200 class final response. J. Rosenberg et. al. [Page 18] Internet Draft call-pkg March 1, 2002 The dialog element is the same one from the dialog package above. The media-status attribute is a series of media streams. Each media stream is associated with a media type, a sending status, and a receiving status. If the send-status is "received-by-all", it means that the media for that stream that is being generated by the user is being mixed by the server and sent to all recipients. "muted" means that no one is receiving their media. If the receive-status is "receiving-all" it means that the user is hearing all other participants. If it is "anchor-only", the user is hearing media from just a single participant. 5.3 Example The following is an example conference information document: J. Rosenberg et. al. [Page 19] Internet Draft call-pkg March 1, 2002 This document describes a conference with two users, both of which are active. 6 Relationship to User Presence The SIP events package for user presence [3] has a close relationship with these two event packages. It is fundamental to the presence model that the information used to obtain user presence is constructed from any number of different input sources. Examples of such sources include SIP REGISTER requests and uploads of presence documents. These two packages can be considered another mechanism that allows a presence agent to determine the presence state of the user. Specifically, a user presence server can act as a subscriber for the dialog and conference packages to obtain additional information that can be used to construct a presence document. 7 Open Issues and To-Dos o There is a strong relationship between the dialog event package, and the notifications used by the REFER specification [8]. Should these be unified, so that a REFER basically implies a subscription to the dialog state created by that REFER?. o Reuse of dialogs for conference and dialog subscriptions needs to be discussed. It has an implication for the dialog state package. Now, the session may be terminated, but the dialog remains. o Need to add IANA considerations o Should we split this into two documents, or even four? Probably two. 8 Security Considerations Subscriptions to dialog state and conference state can reveal very sensitive information. For this reason, the document recommends authentication and authorization, and provides guidelines on sensible authorization policies. Since the data in notifications is sensitive as well, end-to-end SIP encryption mechanisms using S/MIME SHOULD be used to protect it. 9 IANA Considerations TODO. J. Rosenberg et. al. [Page 20] Internet Draft call-pkg March 1, 2002 10 Acknowledgements The authors would like to thank Dan Petrie for his comments. 11 Changes since -00 o Alignment with bis and sip-events o Added direction attribute to dialog format o Removed To-Join and To-Replace header, along with joining and replacing URIs from the various formats. o Conference data format reuses dialog formats o Added media mixing information to conference format o Removal of example services (will go into service examples specification) o Removal of floor control from conference package; rather, place it into a separate event package, as was done in 12 Authors Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu 13 Normative References [1] A. Roach et al. , "SIP-specific event notification," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation J. Rosenberg et. al. [Page 21] Internet Draft call-pkg March 1, 2002 protocol," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. 14 Informative References [3] J. Rosenberg, "SIP extensions for presence," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. [4] J. Rosenberg, "A SIP event sub-package for watcher information," Internet Draft, Internet Engineering Task Force, July 2001. Work in progress. [5] R. Mahy and I. Slain, "SIP event package for message waiting indication," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. [6] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," Request for Comments 3023, Internet Engineering Task Force, Jan. 2001. [7] J. Rosenberg and H. Schulzrinne, "Models for multi party conferencing in SIP," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. [8] R. Sparks, "The refer method," Internet Draft, Internet Engineering Task Force, Oct. 2001. Work in progress. Full Copyright Statement Copyright (c) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. J. Rosenberg et. al. [Page 22] Internet Draft call-pkg March 1, 2002 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. J. Rosenberg et. al. [Page 23]