One document matched: draft-rosen-xcon-conf-sidebars-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-21 00:30:39 |