XCON Working Group B. Rosen Internet-Draft Marconi Expires: November 22, 2004 A. Johnston MCI May 24, 2004 SIP Conferencing: Sub-conferences and Sidebars draft-rosen-xcon-conf-sidebars-00 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 22, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document discusses the creation, management of operation of sub-conferences in a centralized conferencing architecture, also known as "sidebars". This work uses the SIP Conferencing Framework and builds on the descriptions of sub-conferences in that document. Examples of SIP and XCON protocols are given. Rosen & Johnston Expires November 22, 2004 [Page 1] Internet-Draft SIP Sidebars May 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Sidebars and Dialogs . . . . . . . . . . . . . . . . . . . . . 3 3. Creating Sidebars . . . . . . . . . . . . . . . . . . . . . . 4 4. Adding Participants to a Sidebar . . . . . . . . . . . . . . . 5 5. Terminating a Sidebar . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 7.2 Informative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Rosen & Johnston Expires November 22, 2004 [Page 2] Internet-Draft SIP Sidebars May 2004 1. Introduction This document uses the concepts and definitions from the high level requirements [9] and the SIP conferencing framework [10] documents. While the SIP conferencing framework document describes both SIP and XCON methods for creating and managing a centralized conference, this document will assume a non-SIP method, as sidebars are an advanced conferencing application. Examples of the non-SIP methods include the XCON protocols (used as examples) an IVR, or a web page 2. Sidebars and Dialogs Conference establishment using SIP dialogs is described in the SIP conferencing framework document. The set of XCON protocols to also establish a conference is currently being developed and designed by the XCON working group. Since the details are TBD, this document will refer to the protocol as CPCP (Conference Policy Control Protocol) and omit the details of the messages until they are developed. In SIP sessions, it is not uncommon to have a single dialog with multiple media sessions. The SIP Conferencing Framework assumes this - that a participant uses the Conference URI to establish an INVITE dialog that results in the establishment of one or more media streams. Media streams established using separate dialogs are usually assumed to be unrelated. For example, a pair of SIP/PSTN gateways may have a number of dialogs established between them, and the resulting media streams represent separate calls or sessions. As a result, the simplest sidebar dialog model is to reuse the existing main conference dialog to establish the sidebar. This has the advantage of allowing even the simplest endpoints which are incapable of any local mixing to participate in a conference with sidebars, provided a non-SIP method of controlling the conference is provided. It is also possible for a sidebar to have a separate dialog. However, the motiviation and advantages for this are not obvious. As a result, this document will be restricted to the case of a single dialog and the reuse of that dialog for sidebars. Like a main conference, a sub-conference is identified by a URI. This URI is an alias for the main conference - that is, it must resolve to the same focus as the main conference. If an intended sidebar participant is not a participant in the main conference, the intended participant joins the conference using the sidebar URI using normal SIP means and is added into the sidebar only. If that Rosen & Johnston Expires November 22, 2004 [Page 3] Internet-Draft SIP Sidebars May 2004 participant wishes to become part of the main conference, either a re-INVITE with the main conference URI in the Contact is used, or an INVITE with Replaces from the main conference is issued. Of course, if the participant wishes to maintain separate dialogs, a simple new INVITE would be sent to/from the main conference URI. 3. Creating Sidebars The SIP conferencing architecture supports multiple media types and both centralized and distributed mixing. Sidebars also have this same property. The media type and mixing mode of a sidebar need not be the same as the main conference. In the simplest case, the sidebar has the same media types as the main conference, and is centrally mixed. In this case, the focus changes the mix for the sidebar participants, and no SIP signaling is necessary - the existing main conference mix is replaced with the sidebar mix. On the other hand, if the sidebar has different media types than the main conference, then the focus will need to re-INVITE, adding the new media stream(s). Non-SIP means will be used so that the User Agent renders the new media stream in the proper context to the user. For fully distributed mixing of single dialog sidebars, the focus may need to re-INVITE to add a media stream if the media stream is not already being sent to the participant. The participant will be notified of the desired mix using a non-SIP protocol which will result in the creation of the sidebar. Rosen & Johnston Expires November 22, 2004 [Page 4] Internet-Draft SIP Sidebars May 2004 Alice Focus Bob Carol | | | | |<==================>| | | | |<==================>| | | |<=======================================>| | | | | | Alice creates a sidebar using CPCP. | | | | | | CPCP Create Sidebar F1 | | |------------------->| | | | CPCP Acknowledgement F2 | | |<-------------------| | | | | | | Focus re-INVITEs Alice to create the sidebar | | | | | | INVITE sip:Conf-ID F3 | | |<-------------------| | | | 200 OK F4 | | | |------------------->| | | | ACK F5 | | | |<-------------------| | | | NOTIFY F9 | | | |<-------------------| | | | 200 OK F10 | | | |------------------->| | | Figure 1. Creation of a Sidebar. 4. Adding Participants to a Sidebar Participants can be added to a sidebar in a number of ways. If the intended sidebar participant is already a participant in the main conference and desires a single dialog, then some non-SIP means will be used to add the participant. On the other hand, if the participant is not in the main conference, a SIP means such as a REFER with the Refer-To URI set to the sidebar URI can be used, or a non-SIP means. Either way, a new dialog will be established with the participant and they will join the sidebar. Participants who request multiple dialogs will be INVITEd to the sidebar, perhaps as a result of a REFER. As above, a new dialog will be established with the participant, and they will join the sidebar. Rosen & Johnston Expires November 22, 2004 [Page 5] Internet-Draft SIP Sidebars May 2004 Alice Focus Bob Carol | | | | |<==================>| | | | |<==================>| | | |<=======================================>| | | | | | Alice adds Carol to the sidebar using CPCP | | | | | | CPCP Add participant to sidebar F1 | | |------------------->| | | | CPCP Acknowledgement F2 | | |<-------------------| | | | | | | Focus re-INVITEs Carol to add Carol to the sidebar | | | | | | | INVITE Contact:Conf-ID;isfocus F3 | | |---------------------------------------->| | | 200 OK F4 | | |<----------------------------------------| | | ACK F5 | | |---------------------------------------->| | NOTIFY F6 | | | |<-------------------| | | | 200 OK F7 | | | |------------------->| | | | | NOTIFY F8 | | |---------------------------------------->| | | 200 OK F9 | | |<----------------------------------------| Figure 2. Adding a participant to a sidebar. Alice Focus Bob Devon | | | | |<==================>| | | | |<==================>| | | | | | | Alice adds Devon to the sidebar. | | | | | | CPCP Add participant to sidebar F1 | | |------------------->| | | | CPCP Acknowledgement F2 | | |<-------------------| | | | | | | Alice sends a REFER to Devon to join to the sidebar | Rosen & Johnston Expires November 22, 2004 [Page 6] Internet-Draft SIP Sidebars May 2004 | | | | | REFER Contact:Sidebar-ID;isfocus F3 | |------------------------------------------------------------->| | 202 Accepted F4 | | |<-------------------------------------------------------------| | | NOTIFY F5 | | |<-------------------------------------------------------------| | | 200 OK F6 | | |------------------------------------------------------------->| | | INVITE sip:Sidebar-ID F7 | | |<----------------------------------------| | | 180 Ringing F8 | | |---------------------------------------->| | | 200 OK Contact:Sidebar-ID;isfocus F9 | | |---------------------------------------->| | | ACK F10 | | |<----------------------------------------| | | RTP | | |<=======================================>| | | SUBSCRIBE sip:Sidebar-ID F11 | | |<----------------------------------------| | | 200 OK F12 | | |---------------------------------------->| | | NOTIFY F13 | | |---------------------------------------->| | | 200 OK F14 | | |<----------------------------------------| | NOTIFY F15 | | | |<-------------------| | | | 200 OK F16 | | | |------------------->| | | Figure 3. Adding a participant to a sidebar who is not a member of the Main conference. 5. Terminating a Sidebar Participation in a single dialog sidebar is terminated by non-SIP means. When the last participant leaves it, the sidebar ceases to exist. A multiple dialog sidebar is terminated by a BYE on the dialog for each of the participants. When the last participant leaves it, the sidebar ceases to exist, and the sidebar URI becomes unusable. Note that a single participant sidebar is permissible - another participant may join later. Alice Focus Bob Carol | | | | Rosen & Johnston Expires November 22, 2004 [Page 7] Internet-Draft SIP Sidebars May 2004 |<==================>| | | | |<==================>| | | |<=======================================>| | | | | | Alice and Carol leave the sidebar. | | | | | | | CPCP Leave sidebar F1 | | |<----------------------------------------| | | CPCP Acknowledgement F2 | | |---------------------------------------->| | | INVITE Contact:Conf-ID;isfocus F3 | | |---------------------------------------->| | | 200 OK F4 | | |<----------------------------------------| | | ACK F5 | | |---------------------------------------->| | NOTIFY F6 | | | |<-------------------| | | | 200 OK F7 | | | |------------------->| | | | | NOTIFY F8 | | |---------------------------------------->| | | 200 OK F9 | | |<----------------------------------------| | CPCP Leave sidebar F10 | | |------------------->| | | | CPCP Acknowledegment F11 | | |<-------------------| | | | INVITE sip:Conf-ID F12 | | |<-------------------| | | | 200 OK F13 | | | |------------------->| | | | ACK F14 | | | |<-------------------| | | | NOTIFY F15 | | | |<-------------------| | | | 200 OK F16 | | | |------------------->| | | Figure 4. Terminating a sidebar. 6. Security Considerations This document discusses call control for SIP conferencing. Both call control and conferencing have specific security requirements which will be summarized here. Conferences generally have authorization rules about who may or may not join a conference, what type of media Rosen & Johnston Expires November 22, 2004 [Page 8] Internet-Draft SIP Sidebars May 2004 may or may not be used, etc. This information is used by the Focus to admit or deny participation in a conference. It is recommended that these types of authorization rules be used to provide security for a SIP conference. For this authorization information to be used, the focus needs to be able to authenticate potential participants. Normal SIP mechanisms including Digest authentication and certificates can be used. These conference specific security requirements are discussed further in therequirements and framework documents. For call control security, a user agent must maintain local policy on who is permitted to perform call control operations, initiate REFERs, and replace dialogs. Normal SIP authentication mechanisms are also appropriate here. The specific authentication and authorization schemes are described in the multiparty call control framework document. 7. References 7.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [5] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-03 (work in progress), February 2004. [6] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP) 'Join' Header", draft-ietf-sip-join-03 (work in progress), February 2004. [7] Rosenberg, J., "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", draft-ietf-sip-callee-caps-03 (work in progress), January 2004. [8] Biggs, B., Dean, R. and R. Mahy, "The Session Inititation Rosen & Johnston Expires November 22, 2004 [Page 9] Internet-Draft SIP Sidebars May 2004 Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-05 (work in progress), February 2004. 7.2 Informative References [9] Levin, O. and R. Even, "High Level Requirements for Tightly Coupled SIP Conferencing", draft-ietf-sipping-conferencing-requirements-00 (work in progress), April 2003. [10] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-01 (work in progress), October 2003. [11] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", draft-ietf-sipping-cc-framework-03 (work in progress), October 2003. [12] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001. [13] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. [14] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003. [15] Johnston, A. and R. Sparks, "Session Initiation Protocol Service Examples", draft-ietf-sipping-service-examples-06 (work in progress), February 2004. [16] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-02 (work in progress), February 2004. [17] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP)", draft-ietf-sipping-dialog-package-04 (work in progress), February 2004. Rosen & Johnston Expires November 22, 2004 [Page 10] Internet-Draft SIP Sidebars May 2004 Authors' Addresses Brian Rosen Marconi 1000 FORE Drive Warrendale, PA 15086 EMail: brian.rosen@marconi.com Alan Johnston MCI 100 South 4th Street St. Louis, MO 63102 EMail: alan.johnston@mci.com Rosen & Johnston Expires November 22, 2004 [Page 11] Internet-Draft SIP Sidebars May 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 assignees. 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 Rosen & Johnston Expires November 22, 2004 [Page 12] Internet-Draft SIP Sidebars May 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosen & Johnston Expires November 22, 2004 [Page 13]