XCON Working Group B. Rosen Internet-Draft Marconi Expires: January 14, 2005 A. Johnston MCI July 16, 2004 SIP Conferencing: Sub-conferences and Sidebars draft-rosen-xcon-conf-sidebars-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 January 14, 2005. 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 January 14, 2005 [Page 1] Internet-Draft SIP Sidebars July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Sidebars and Dialogs . . . . . . . . . . . . . . . . . . . . . 3 3. Sidebar mechanism requirements . . . . . . . . . . . . . . . . 4 4. Creating Sidebars . . . . . . . . . . . . . . . . . . . . . . 5 5. Adding Participants to a Sidebar . . . . . . . . . . . . . . . 7 6. Terminating a Sidebar . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 9.2 Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 15 Rosen & Johnston Expires January 14, 2005 [Page 2] Internet-Draft SIP Sidebars July 2004 1. Introduction This document uses the concepts and definitions from the SIP high level conferencing requirements and the SIP conferencing framework [9] 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) [8] 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 motivation 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. As discussed in the framework, 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 Rosen & Johnston Expires January 14, 2005 [Page 3] Internet-Draft SIP Sidebars July 2004 normal SIP means and is added into the sidebar only. If that 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. Sidebar mechanism requirements A properly authorized participant in a conference which allows sidebars must be able to: REQ-1 Create a sidebar conference. REQ-2 Invite participants to join the sidebar, both members of the main conference and outside the conference. REQ-3 Discover the status of the invited participants. REQ-4 Remove participants from a sidebar. REQ-5 Delete the sidebar. In addition, any participant or potential participant in a sidebar must be able to: REQ-6 Discover they have been invited to a sidebar. REQ-7 Accept or deny an invitation to a sidebar. REQ-8 Discover who else is a participant in the sidebar. REQ-9 Switch back and forth between the sidebar and the main conference. REQ-10 Add/delete media streams in the sidebar. REQ-11 Leave the sidebar. CPCP [8] can meet requirements REQ-1, REQ-2, REQ-5, REQ-6, and REQ-10. As the conference package [5] contains sidebar rosters, notifications from the focus can meet requirements REQ-3 and REQ-8. In addition, if a "pending" user status is added to the conference package (or the existing "on-hold" status reused), it can meet requirement REQ-6. The remaining requirements need to be met using controls provided by Rosen & Johnston Expires January 14, 2005 [Page 4] Internet-Draft SIP Sidebars July 2004 the template, as discussed in the media policy document. Specifically, REQ-9 is needed if the nature of the media type limits the user to participation in only one stream at a time. For example, a user can effectively only listen to a single audio stream at a time, so they can only participate in either the main audio conference or in an audio sidebar but not both at the same time. On the other hand, a user can easily participate in multiple text sidebars while still participating actively in the main conference. Thus, the need for this requirement is media specific. In the main conference, the equivalent requirements to requirements REQ-7, REQ-9 and REQ-11 are met using the signaling protocol, i.e. an INVITE is accepted or rejected to join the main conference, a re-INVITE places media streams on and off hold, and a BYE is sent to leave the main conference. Since a sidebar shares the main conference dialog, clearly these signaling methods are not applicable, except for a participant who is only in the sidebar and not a participant in the main conference. However, the signaling could still be used as the channel to convey this information. For example, a re-INVITE could be initiated by the participant to accept the sidebar invitation if an SDP attribute were defined to convey this information. A re-INVITE could also be used to switch between participation in the main conference and the sidebar, and to leave the sidebar. Alternatively, a CPCP command could be used meet REQ-7, REQ-9 and REQ-11. Until one approach or the other is chosen for this, the call flows will show CPCP/re-INVITE as the mechanism for accepting or denying a sidebar invitation. switching between participation in the main conference and the sidebar, and leaving a sidebar. 4. 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 Rosen & Johnston Expires January 14, 2005 [Page 5] Internet-Draft SIP Sidebars July 2004 new media stream(s). Conference package notifications and SDP information will be used by the User Agent to render the new media stream in the proper context as a sidebar. 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. Figure 1 shows a call flow for the creation of a sidebar conference. In this flow and those that follow, Alice, Bob, and Carol are participants in the main conference while Devon is not. Rosen & Johnston Expires January 14, 2005 [Page 6] Internet-Draft SIP Sidebars July 2004 Alice Focus Carol Bob | | | | |<==================>| | | | |<==================>| | | |<=======================================>| | | | | | Alice creates a sidebar using CPCP. | | | | | | CPCP Create Sidebar F1 | | |------------------->| | | | CPCP Acknowledgement F2 | | |<-------------------| | | | | | | | Alice adds herself into the sidebar using CPCP. | | | | | | CPCP Add Alice to sidebar F3 | | |------------------->| | | | CPCP Acknowledgement F4 | | |<-------------------| | | | | | | | Alice is notified that she is invited to the sidebar | | | | | | NOTIFY F5 | | | |<-------------------| | | | 200 OK F6 | | | |------------------->| | | | | | | | Alice joins the sidebar | | | | | | | CPCP/re-INVITE F7 | | | |<------------------>| | | | | | | | Alice is notified that she is a participant in the sidebar | | | | | | NOTIFY F8 | | | |<-------------------| | | | 200 OK F9 | | | |------------------->| | | Figure 1. Creation of a Sidebar. 5. 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. Rosen & Johnston Expires January 14, 2005 [Page 7] Internet-Draft SIP Sidebars July 2004 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 using some non-SIP means. Alice Focus Carol Bob | | | | |<==================>| | | | |<==================>| | | |<=======================================>| | | | | | Alice adds Carol to the sidebar using CPCP | | | | | | CPCP Add Carol to sidebar F1 | | |------------------->| | | | CPCP Acknowledgement F2 | | |<-------------------| | | | | | | | Carol is notified that she has been invited to the sidebar with Alice | | | | | | NOTIFY F3 | | | |------------------->| | | | 200 OK F4 | | | |<-------------------| | | | | | | Carol joins the sidebar | | | | | | | | CPCP/re-INVITE F5 | | | |<------------------>| | | | | | | Alice is notified that Carol has joined the sidebar | | | | | | NOTIFY F6 | | | |<-------------------| | | | 200 OK F7 | | | |------------------->| | | | | | | | Carol is notified that she is now in the sidebar | | | | | | | NOTIFY F8 | | | |------------------->| | | | 200 OK F9 | | | |<-------------------| | Figure 2. Adding a participant to a sidebar. Rosen & Johnston Expires January 14, 2005 [Page 8] Internet-Draft SIP Sidebars July 2004 Alice Focus Carol Devon | | | | |<==================>| | | | |<==================>| | | | | | Alice adds Devon who is not in the conference to the sidebar.| | | | | CPCP Add Devon to sidebar F1 | |------------------->| | | CPCP Acknowledgement F2 | |<-------------------| | | | | | Alice sends a REFER to Devon to join to the sidebar | | | | | REFER Refer-To:sip:Sidebar-ID F3 | |------------------------------------------------------------->| | 202 Accepted F4 | |<-------------------------------------------------------------| | | NOTIFY F5 | |<-------------------------------------------------------------| | | 200 OK F6 | |------------------------------------------------------------->| | | INVITE sip:Sidebar-ID F7 | | |<----------------------------------------| | | 180 Ringing F8 | | |---------------------------------------->| | | 200 OK Contact:sip:Sidebar-ID;isfocus F9| | |---------------------------------------->| | | ACK F10 | | |<----------------------------------------| | | RTP | | |<=======================================>| | | SUBSCRIBE sip:Sidebar-ID F11 | | |<----------------------------------------| | | 200 OK F12 | | |---------------------------------------->| | | | | Devon is notified that she has been invited to a sidebar with Alice | | | | | NOTIFY F13 | | |---------------------------------------->| | | 200 OK F14 | | |<----------------------------------------| | | | | | Devon joins the sidebar | | | | | | CPCP/re-INVITE F15 | | |<--------------------------------------->| Rosen & Johnston Expires January 14, 2005 [Page 9] Internet-Draft SIP Sidebars July 2004 | | | | Devon is notified that Alice is in the sidebar with her | | | | | | NOTIFY F16 | | |---------------------------------------->| | | 200 OK F17 | | |<----------------------------------------| | | | | Alice is notified that Devon has joined the sidebar | | | | | NOTIFY F18 | | |<-------------------| | | 200 OK F19 | | |------------------->| | | | | | | Carol is notified that Devon has joined the sidebar | | | | | | | NOTIFY F20 | | | |------------------->| | | | 200 OK F21 | | | |<-------------------| | Figure 3. Adding a participant to a sidebar who is not a member of the main conference. 6. 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 Carol Devon | | | | |<==================>| | | | |<==================>| | | |<=======================================>| | | | | | Carol leaves the sidebar. | | | | | | | CPCP/re-INVITE F1 | | | |<------------------>| | | | | | | Carol is notified that she has left the sidebar | Rosen & Johnston Expires January 14, 2005 [Page 10] Internet-Draft SIP Sidebars July 2004 | | | | | | NOTIFY F2 | | | |------------------->| | | | 200 OK F3 | | | |<-------------------| | | | | | Devon is notified that Carol has left the sidebar | | | | | | NOTIFY F4 | | |---------------------------------------->| | | 200 OK F5 | | |<----------------------------------------| | | | | Alice is notified that Carol has left the sidebar | | | | | NOTIFY F6 | | |<-------------------| | | 200 OK F7 | | |------------------->| | | | Devon leaves the sidebar. | | | | | | BYE F8 | | |<----------------------------------------| | | 200 OK F9 | | |---------------------------------------->| | | | | Devon is notified that she has left the sidebar. | | | | | | NOTIFY F10 | | |---------------------------------------->| | | 200 OK F11 | | |<----------------------------------------| | | | Alice is notified that Devon has left the sidebar. | | | NOTIFY F12 | |<-------------------| | 200 OK F13 | |------------------->| | | | Alice leaves the sidebar. | | | CPCP/re-INVITE F14 | |<------------------>| | | | Alice is notified that she has left the sidebar. | | | NOTIFY F15 | Rosen & Johnston Expires January 14, 2005 [Page 11] Internet-Draft SIP Sidebars July 2004 |<-------------------| | 200 OK F16 | |------------------->| Figure 4. Terminating a sidebar. 7. 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 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 identity mechanisms including Digest challenge, certificates, and identity header fields can be used. These conference specific security requirements are discussed further in the requirements 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. 8. IANA Considerations None. 9. References 9.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. Rosen & Johnston Expires January 14, 2005 [Page 12] Internet-Draft SIP Sidebars July 2004 [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-04 (work in progress), May 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] Khartabil, H. and P. Koskelainen, "The Conference Policy Control Protocol (CPCP)", draft-ietf-xcon-cpcp-xcap-00 (work in progress), May 2004. 9.2 Informative References [9] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-02 (work in progress), June 2004. [10] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001. [11] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. [12] 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. Authors' Addresses Brian Rosen Marconi 1000 FORE Drive Warrendale, PA 15086 EMail: brian.rosen@marconi.com Rosen & Johnston Expires January 14, 2005 [Page 13] Internet-Draft SIP Sidebars July 2004 Alan Johnston MCI 100 South 4th Street St. Louis, MO 63102 EMail: alan.johnston@mci.com Rosen & Johnston Expires January 14, 2005 [Page 14] Internet-Draft SIP Sidebars July 2004 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 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosen & Johnston Expires January 14, 2005 [Page 15]