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]