draft-ietf-sipping-conferencing-requirements-00.txt   draft-ietf-sipping-conferencing-requirements-01.txt 
SIPPING Working Group O. Levin SIPPING Working Group O. Levin
Internet-Draft RADVISION Internet-Draft Microsoft Corporation
Expires: October 22, 2003 R. Even Expires: March 2, 2005 R. Even
Polycom Polycom
April 23, 2003 September 2004
High Level Requirements for Tightly Coupled SIP Conferencing High Level Requirements for Tightly Coupled SIP Conferencing
draft-ietf-sipping-conferencing-requirements-00 draft-ietf-sipping-conferencing-requirements-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 22, 2003. This Internet-Draft will expire on March 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document examines a wide range of conferencing requirements for This document examines a wide range of conferencing requirements for
tightly coupled SIP conferences. Separate documents will map the tightly coupled SIP conferences. Separate documents will map the
requirements to existing protocol primitives, define new protocol requirements to existing protocol primitives, define new protocol
extensions, and introduce new protocols as needed. Together, these extensions, and introduce new protocols as needed. Together, these
documents will provide a guide for building interoperable SIP documents will provide a guide for building interoperable SIP
conferencing applications. conferencing applications.
Table of Contents Table of Contents
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. An Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 2. An Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. High Level Requirements . . . . . . . . . . . . . . . . . . 4 3. High Level Requirements . . . . . . . . . . . . . . . . . . . 4
3.1 Discovery Phase . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Discovery Phase . . . . . . . . . . . . . . . . . . . . . 4
3.2 Conference Creation . . . . . . . . . . . . . . . . . . . . 5 3.2 Conference Creation . . . . . . . . . . . . . . . . . . . 5
3.3 Conference Termination . . . . . . . . . . . . . . . . . . . 5 3.3 Conference Termination . . . . . . . . . . . . . . . . . . 5
3.4 ParticipantsĘ Manipulations . . . . . . . . . . . . . . . . 5 3.4 Participants' Manipulations . . . . . . . . . . . . . . . 5
3.4.1 Participation of a Conference-unaware User Agent . . . . . . 5 3.4.1 Participation of a Conference-unaware User Agent . . . 5
3.4.2 Dial-Out Scenarios . . . . . . . . . . . . . . . . . . . . . 6 3.4.2 Dial-Out Scenarios . . . . . . . . . . . . . . . . . . 5
3.4.3 Dial-In Scenarios . . . . . . . . . . . . . . . . . . . . . 6 3.4.3 Dial-In Scenarios . . . . . . . . . . . . . . . . . . 6
3.4.4 Third Party Invitation to a Conference . . . . . . . . . . . 6 3.4.4 Third Party Invitation to a Conference . . . . . . . . 6
3.4.5 ParticipantsĘ Removal . . . . . . . . . . . . . . . . . . . 6 3.4.5 Participants' Removal . . . . . . . . . . . . . . . . 6
3.4.6 ParticipantsĘ Privacy . . . . . . . . . . . . . . . . . . . 7 3.4.6 Participants' Privacy . . . . . . . . . . . . . . . . 7
3.5 Conference State Information . . . . . . . . . . . . . . . . 7 3.5 Conference State Information . . . . . . . . . . . . . . . 7
3.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5.1 Description . . . . . . . . . . . . . . . . . . . . . 7
3.5.2 Dissemination of Changes . . . . . . . . . . . . . . . . . . 8 3.5.2 Dissemination of Changes . . . . . . . . . . . . . . . 8
3.5.3 On-demand Information Dissemination . . . . . . . . . . . . 8 3.5.3 On-demand Information Dissemination . . . . . . . . . 8
3.6 Focus Role Migration . . . . . . . . . . . . . . . . . . . . 9 3.6 Focus Role Migration . . . . . . . . . . . . . . . . . . . 9
3.7 Side-bar Conferences . . . . . . . . . . . . . . . . . . . . 9 3.7 Side-bar Conferences . . . . . . . . . . . . . . . . . . . 9
3.8 Cascading of Conferences . . . . . . . . . . . . . . . . . . 10 3.8 Cascading of Conferences . . . . . . . . . . . . . . . . . 10
3.9 SIMPLE and SIP Conferencing Coordination . . . . . . . . . . 10 3.9 SIMPLE and SIP Conferencing Coordination . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
Normative References . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Informative References . . . . . . . . . . . . . . . . . . . 11 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 6.2 Informative References . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
1. Scope 1. Scope
This document examines a wide range of conferencing requirements for This document examines a wide range of conferencing requirements for
tightly coupled SIP (RFC 3261 [2]) conferencing. tightly coupled SIP (RFC 3261 [2]) conferencing.
The requirements are grouped by subjects in various areas allowing The requirements are grouped by subjects in various areas allowing
solutions to progress in parallel. solutions to progress in parallel.
Separate documents will map the requirements to existing protocol Separate documents will map the requirements to existing protocol
skipping to change at page 3, line 51 skipping to change at page 3, line 51
A dedicated conference server, in addition to the basic features, A dedicated conference server, in addition to the basic features,
offers richer functionality including simultaneous conferences, large offers richer functionality including simultaneous conferences, large
scalable conferences, reserved conferences, and managed conferences. scalable conferences, reserved conferences, and managed conferences.
A conferencing server can support any subset of the advanced A conferencing server can support any subset of the advanced
conferencing functions presented in this document. conferencing functions presented in this document.
The media graph of a SIP conference can be centralized, The media graph of a SIP conference can be centralized,
de-centralized, or any combination of both and potentially differ per de-centralized, or any combination of both and potentially differ per
media type. In centralized case, the media sessions are established media type. In centralized case, the media sessions are established
between the focus and each one of the participants. In de-centralized between the focus and each one of the participants. In
(i.e. distributed) case, the media graph is a (multicast or de-centralized (i.e. distributed) case, the media graph is a
multi-unicast) mesh among the participants. Consequently, the media (multicast or multi-unicast) mesh among the participants.
processing (e.g. mixing) can be performed either by the focus alone Consequently, the media processing (e.g. mixing) can be performed
or by the participants. either by the focus alone or by the participants.
Conference participants and third parties can have different roles Conference participants and third parties can have different roles
and privileges in a certain conference. For example, conferencing and privileges in a certain conference. For example, conferencing
policy can state that the rights to disconnect from and to invite to policy can state that the rights to disconnect from and to invite to
a conference are limited to the conference chair only. a conference are limited to the conference chair only.
Throughout the document, by conference policies we mean a set of Throughout the document, by conference policies we mean a set of
parameters and rules (e.g. maximum number of participants, needs parameters and rules (e.g. maximum number of participants, needs
chair-person supervision or not, password protected or not, duration, chair-person supervision or not, password protected or not, duration,
a way of media mixing, etc.) that are defined at the onset of a a way of media mixing, etc.) that are defined at the onset of a
conference. Typically, conference policies would be specified by a conference. Typically, conference policies would be specified by a
conference creator and need special privileges to be manipulated. conference creator and need special privileges to be manipulated.
Throughout the document, by a conference state we mean a set of Throughout the document, by a conference state we mean a set of
information describing the conference in progress. This includes information describing the conference in progress. This includes
participantsĘ information (such as dialog identifiers), media participants' information (such as dialog identifiers), media
sessions in progress, the current loudest speaker, the current chair, sessions in progress, the current loudest speaker, the current chair,
etc. etc.
3. High Level Requirements 3. High Level Requirements
In addition to the requirements presented in this document, In addition to the requirements presented in this document,
supplementary requirements for conferencing policy, media mixing and supplementary requirements for conferencing policy, media mixing and
other manipulations, floor control, privileges control, etc. will be other manipulations, floor control, privileges control, etc. will be
discussed in separate documents. discussed in separate documents.
3.1 Discovery Phase 3.1 Discovery Phase
Some of the requirements presented in this section can be met either Some of the requirements presented in this section can be met either
by configuration means or by using proprietary conventions. by configuration means or by using proprietary conventions.
Nevertheless, we feel that standard means for implementing these Nevertheless, we feel that standard means for implementing these
functions by automata MUST be defined. functions by automata MUST be defined.
REQ -1: Discovery of a location of an arbitrary SIP conferencing REQ -1: Discovery of a location of an arbitrary SIP conferencing
server(s). server(s).
EditorĘs Note: No solution currently exists.
REQ -2: Given a SIP AOR of a certain entity, resolution whether the REQ -2: Given a SIP AOR of a certain entity, resolution whether the
SIP entity has focus capabilities. SIP entity has focus capabilities.
EditorĘs Note: No solution currently exists. REQ-3: Given a global identifier of a particular conference, locating
the conference focus.
REQ -3: Given a global identifier of a particular conference,
locating the conference focus.
REQ -4: Given a global identifier of a particular conference, REQ -4: Given a global identifier of a particular conference,
obtaining the conference properties. obtaining the conference properties.
REQ -5: Given a global identifier of a particular conference, REQ -5: Given a global identifier of a particular conference,
obtaining the conference state information. obtaining the conference state information.
3.2 Conference Creation 3.2 Conference Creation
Given a focus location, a means MUST be defined for an interested Given a focus location, a means MUST be defined for an interested
entity (including a user agent) to implement the procedures below: entity (including a user agent) to implement the procedures below:
REQ -1: Creation of an ad-hoc conference identifier and the REQ-1: Creation of an ad-hoc conference identifier and the conference
conference with specified properties. with specified properties.
REQ -2: Creation of a reserved conference identifier for a conference REQ -2: Creation of a reserved conference identifier for a conference
with specified properties. with specified properties.
REQ -3: Specifying properties upon conference creation in any of the REQ -3: Specifying properties upon conference creation in any of the
following ways: default, profiles and explicitly. following ways: default, profiles and explicitly.
3.3 Conference Termination 3.3 Conference Termination
REQ -1: Given a conference identifier, a means MUST be defined for a REQ -1: Given a conference identifier, a means MUST be defined for a
user agent to disconnect all participants from the conference and user agent to disconnect all participants from the conference and
terminate the conference including the release of the associated terminate the conference including the release of the associated
resources. resources.
REQ -2: A means MAY be defined for requesting a focus to revert a REQ -2: A means MAY be defined for requesting a focus to revert a
two-party conference to a basic SIP point-to-point session including two-party conference to a basic SIP point-to-point session including
the release of the associated conferencing resources. the release of the associated conferencing resources.
3.4 ParticipantsĘ Manipulations 3.4 Participants' Manipulations
Some of the requirements presented in this section can be met by Some of the requirements presented in this section can be met by
human intervention, configuration means, or by using proprietary human intervention, configuration means, or by using proprietary
conventions. Nevertheless, we feel that standard means for conventions. Nevertheless, we feel that standard means for
implementing these functions by automata MUST be defined. implementing these functions by automata MUST be defined.
3.4.1 Participation of a Conference-unaware User Agent 3.4.1 Participation of a Conference-unaware User Agent
REQ -1: Focus MUST be able to invite and disconnect an RFC 3261 REQ -1: Focus MUST be able to invite and disconnect an RFC 3261
compliant only SIP user agent to and from a SIP conference. compliant only SIP user agent to and from a SIP conference.
REQ -2: RFC 3261 compliant only SIP user agent MUST be able to REQ-2: An RFC 3261 compliant only SIP user agent MUST be able to
dial-in a particular SIP conference. In this case, only the human dial-in to a particular SIP conference. In this case, only the human
knows that he/she is connected to the conference. knows that he/she is connected to the conference.
3.4.2 Dial-Out Scenarios 3.4.2 Dial-Out Scenarios
REQ -1: A means MUST be defined for a focus to invite another user REQ -1: A means MUST be defined for a focus to invite another user
agent to one of the focusĘ conferences. This procedure MUST result in agent to one of the focus' conferences. This procedure MUST result
establishing of a single SIP dialog between the two. in the establishment of a single SIP dialog between the two.
REQ -2: Given an existent SIP dialog between two user agents, where REQ-2: Given an existing SIP dialog between two user agents, if at
at least one with focus capabilities, a means MUST be defined for the least one User agent has focus capabilities, a means MUST be defined
conference focus to invite the other user agent to one of the focusĘ for the conference focus to invite the other user agent to one of the
conferences without additional SIP dialog establishment. focus' conferences without additional SIP dialog establishment.
REQ -3: An invitation to a user agent to join a conference MUST REQ -3: An invitation to a user agent to join a conference MUST
include a standard indication that it is "a conference" and the include a standard indication that it is a conference and the
conference identifier. conference identifier.
3.4.3 Dial-In Scenarios 3.4.3 Dial-In Scenarios
REQ -1: A means MUST be defined for a user agent to create an ad-hoc REQ -1: A means MUST be defined for a user agent to create an ad-hoc
conference with default properties (as per "Conference Creation" REQ conference with default properties (as per "Conference Creation"
-1 above) and to become its participant using a single SIP dialog. REQ-1 above) and to become a participant using a single SIP dialog.
REQ -2: Given a reserved conference identifier, a means MUST be REQ -2: Given a reserved conference identifier, a means MUST be
defined for a user agent to activate the conference and to become its defined for a user agent to activate the conference and to become a
participant using a single SIP dialog. participant using a single SIP dialog.
REQ -3: Given a conference identifier of an active conference, a REQ-3: Given a conference identifier of an active conference, a means
means MUST be defined for a user agent to dial-in the conference and MUST be defined for a user agent to dial-in the conference and to
to become its participant using a single SIP dialog between the two. become a participant using a single SIP dialog between the two.
REQ -4: Given an identifier of one of the dialogs of a particular REQ -4: Given an identifier of one of the dialogs of a particular
active conference, a means MUST be defined for a user agent to active conference, a means MUST be defined for a user agent to
dial-in the conference and to become its participant. dial-in the conference and to become a participant.
3.4.4 Third Party Invitation to a Conference 3.4.4 Third Party Invitation to a Conference
REQ -1: Given a conference identifier, a means MUST be defined for a REQ -1: Given a conference identifier, a means MUST be defined for a
user agent to invite another user agent to this conference. user agent to invite another user agent to this conference.
REQ -2: Given an identifier of one of the dialogs of a particular REQ -2: Given an identifier of one of the dialogs of a particular
active conference, a means MUST be defined for a user agent to invite active conference, a means MUST be defined for a user agent to invite
another user agent to this conference. another user agent to this conference.
REQ -3: Given a conference identifier, a means SHOULD be defined for REQ-3: Given a conference identifier, a means SHOULD be defined for a
a user agent to invite a list of user agents to this conference (a user agent to invite a list of user agents to this conference (a
so-called "mass invitation"). so-called "mass invitation").
3.4.5 ParticipantsĘ Removal 3.4.5 Participants' Removal
REQ -1: A means MUST be defined for a conference focus to remove a REQ -1: A means MUST be defined for a conference focus to remove a
conference participant from the conference. conference participant from the conference.
REQ -2: Given a conference identifier, a means MUST be defined for a REQ -2: Given a conference identifier, a means MUST be defined for a
user agent to remove a participant from the conference. user agent to remove a participant from the conference.
REQ -3: Given an identifier of one of the dialogs of a particular REQ -3: Given an identifier of one of the dialogs of a particular
active conference, a means MUST be defined for a user agent to remove active conference, a means MUST be defined for a user agent to remove
a participant from the conference. a participant from the conference.
REQ -4: Given a conference identifier, a means MUST be defined for a REQ -4: Given a conference identifier, a means MUST be defined for a
user agent to remove all the participants from the conference. user agent to remove all the participants from the conference.
REQ -5: Given a conference identifier and a sub-list of participants, REQ -5: Given a conference identifier and a sub-list of participants,
a means MAY be defined for a user agent to remove the specified a means MAY be defined for a user agent to remove the specified
participants from the conference (a so-called "mass ejection"). participants from the conference (a so-called "mass ejection").
3.4.6 ParticipantsĘ Privacy 3.4.6 Participants' Privacy
A conference focus SHOULD support the procedures described in this A conference focus SHOULD support the procedures described in this
section. A conference participant MAY support the procedures section. A conference participant MAY support the procedures
described in this section. The requirements imply that "anonymizing" described in this section. The requirements imply that "anonymizing"
operations MUST be performed on all: the call control, the media operations MUST be performed on all: the call control, the media
control and the media content when appropriate. control and the media content when appropriate.
REQ -1: A conference participant joins the conference "anonymously", REQ -1: A conference participant joins the conference "anonymously",
i.e. his/her presence can be announced but without disclosing his/her i.e. his/her presence can be announced but without disclosing
identity. his/her identity.
REQ -2: A conference participant requests a focus for anonymous REQ -2: A conference participant requests a focus for anonymous
participation in the conference. participation in the conference.
REQ -3: A conference participant joins a conference in a "hidden REQ -3: A conference participant joins a conference in a "hidden
mode", i.e. his/her both presence and identity are not to be mode", i.e. his/her both presence and identity are not to be
disclosed to other participants. disclosed to other participants.
REQ -4: A conference participant requests a focus for participation REQ-4: A conference participant requests a focus for participation in
in the conference in a hidden mode. the conference in a hidden mode.
3.5 Conference State Information 3.5 Conference State Information
3.5.1 Description 3.5.1 Description
By a conference state we mean a virtual database describing the By a conference state we mean a virtual database describing the
conference in progress. This includes different conference aspects - conference in progress. This includes different conference aspects -
participantsĘ information (such as dialog identifiers and state), participants' information (such as dialog identifiers and state),
media sessions in progress (such as current stream contributing media sessions in progress (such as current stream contributing
sources and encoding schemes), the current loudest speaker, the sources and encoding schemes), the current loudest speaker, the
current chair, etc. Conference state is the latest conference current chair, etc. Conference state is the latest conference
snapshot triggered by changes in participantsĘ state, conference snapshot triggered by changes in participants' state, conference
policy changes, etc. policy changes, etc.
REQ -1: Conference state virtual database MUST have a modular REQ-1: A conference state virtual database MUST have a modular
definition, i.e. it MUST be possible to access different conference definition, i.e. it MUST be possible to access different conference
aspects independently. aspects independently.
REQ -2: It MUST be possible to aggregate information relating to REQ -2: It MUST be possible to aggregate information relating to
different conference aspects in a single report. different conference aspects in a single report.
REQ -3: A mechanism for extensible definition and registration of REQ -3: A mechanism for extensible definition and registration of
conference state evolving aspects MUST be present. conference state evolving aspects MUST be present.
REQ -4: A default conference state report MUST be defined. It SHOULD REQ -4: A default conference state report MUST be defined. It SHOULD
contain minimal useful to participants information (e.g. a list of contain A minimal useful set of information (e.g. a list of current
current conference participants). conference participants).
3.5.2 Dissemination of Changes 3.5.2 Dissemination of Changes
REQ -1: A means MUST be defined for reporting the conference state REQ -1: A means MUST be defined for reporting the conference state
changes to interested parties (including non-conference participants) changes to interested parties (including non-conference participants)
in a timely manner. in a timely manner.
REQ -2: A means MUST be defined for a SIP user agent to express its REQ -2: A means MUST be defined for a SIP user agent to express its
interest in selected state changes only. interest in selected state changes only.
REQ -3: A means MUST be defined for a SIP user agent to express the REQ -3: A means MUST be defined for a SIP user agent to express the
minimum interval between receiving state change reports. minimum interval between receiving state change reports.
REQ -4: It MUST be possible to aggregate recent changes in a single REQ -4: It MUST be possible to aggregate recent changes in a single
reporting event. reporting event.
REQ -5: Default conference state change reports MUST be defined. They REQ -5: Default conference state change reports MUST be defined. They
SHOULD contain minimal useful to the participants information (e.g. SHOULD contain minimal useful to the participants information (e.g.
participantsĘ joining and leaving the conference). participants' joining and leaving the conference).
3.5.3 On-demand Information Dissemination 3.5.3 On-demand Information Dissemination
REQ -1: A means MUST be defined to disseminate any conference state REQ -1: A means MUST be defined to disseminate any conference state
information to interested parties (including SIP user agents) information to interested parties (including SIP user agents)
on-demand. on-demand.
REQ -2: A means MUST be defined for an interested party (including REQ-2: A means MUST be defined for an interested party (including a
SIP user agents) to request conference state information of a SIP user agent) to request conference state information of a
particular conference defined by the conference identifier. particular conference defined by the conference identifier.
REQ -3: A means MUST be defined for an interested party (including REQ-3: A means MUST be defined for an interested party (including a
SIP user agents) to specify the subset of the conference state SIP user agent) to specify the subset of the conference state
information it wants and capable to receive. information it wants and capable to receive.
3.6 Focus Role Migration 3.6 Focus Role Migration
EditorĘs Note: We should decide whether the requirements below can be
met by using SIP or non-SIP means.
REQ -1: A procedure for delegating a focus role by the current focus REQ -1: A procedure for delegating a focus role by the current focus
to another participant MUST be defined. to another participant MUST be defined.
REQ -2: A procedure for requesting a conference focus to transfer its REQ -2: A procedure for requesting a conference focus to transfer its
role to another participant MUST be defined. role to another participant MUST be defined.
REQ -3: A procedure for on-demand unconditional transfer of the focus REQ -3: A procedure for on-demand unconditional transfer of the focus
role to a different participant MUST be defined. role to a different participant MUST be defined.
REQ -4: A detection procedure for a focus failure condition MUST be REQ -4: A detection procedure for a focus failure condition MUST be
skipping to change at page 9, line 44 skipping to change at page 9, line 39
REQ -3: A conference participant creates a side-bar conference with REQ -3: A conference participant creates a side-bar conference with
one or more participants in a conference by SIP means. one or more participants in a conference by SIP means.
REQ -4: A conference participant joins a side-bar within the REQ -4: A conference participant joins a side-bar within the
conference by SIP means. conference by SIP means.
REQ -5: A conference participant is invited to a side-bar within the REQ -5: A conference participant is invited to a side-bar within the
conference by SIP means. conference by SIP means.
REQ -6: A conference-unaware user agent (a participant or not) REQ-6: A conference-unaware user agent (a participant or not) creates
creates and participates in side-bar conferences. It MAY be achieved and participates in side-bar conferences. It MAY be achieved by
by non-SIP means. non-SIP means.
REQ -7: A conference participant creates side-bar conferences within REQ -7: A conference participant creates side-bar conferences within
the conference without establishing any additional SIP dialogs with the conference without establishing any additional SIP dialogs with
the focus. It MAY be achieved by non-SIP means. the focus. It MAY be achieved by non-SIP means.
REQ -8: A conference participant joins any number of side-bars within REQ -8: A conference participant joins any number of side-bars within
the conference without establishing any additional SIP dialogs with the conference without establishing any additional SIP dialogs with
the focus. It MAY be achieved by non-SIP means. the focus. It MAY be achieved by non-SIP means.
REQ -9: A conference participant is invited to any number of REQ-9: A conference participant is invited to any number of side-bars
side-bars within the conference without establishing any additional within the conference without establishing any additional SIP dialogs
SIP dialogs with the focus. It MAY be achieved by non-SIP means. with the focus. It MAY be achieved by non-SIP means.
3.8 Cascading of Conferences 3.8 Cascading of Conferences
"Cascading of Conferences" is a term that has different meanings in "Cascading of Conferences" is a term that has different meanings in
different contexts. Some examples are listed below: different contexts. Some examples are listed below:
- Peer-to-peer chaining of signaling. (Many ways exist to build the media - Peer-to-peer chaining of signaling. (Many ways exist to
graph in this case.)
- Conferences have hierarchal signaling relations. (Many ways exists to
build the media graph in this case.) build the media graph in this case.)
- "Cascading" is used to distribute the media "mixing" only. The
distribution of signaling is not required. - Conferences have hierarchal signaling relations. (Many
ways exists to build the media graph in this case.)
- "Cascading" is used to distribute the media "mixing"
only. The distribution of signaling is not required.
As it can be seen from the examples, each will define a different set As it can be seen from the examples, each will define a different set
of requirements. of requirements.
EditorĘs Note: We need to discuss which of the architectures require
our attention as a part of the SIP conferencing force.
3.9 SIMPLE and SIP Conferencing Coordination 3.9 SIMPLE and SIP Conferencing Coordination
REQ -1: SIMPLE-based Presence and Instant Messaging architecture REQ -1: SIMPLE-based Presence and Instant Messaging architecture
SHOULD fit into the general SIP Conferencing architecture. SHOULD fit into the general SIP Conferencing architecture.
REQ -2: A scenario where a multimedia SIP conference and a multiparty REQ -2: A scenario where a multimedia SIP conference and a multiparty
IM conversation take place among the same group of participants MUST IM conversation take place among the same group of participants MUST
be addressed. be addressed.
REQ -3: A scenario where a side-bar or/and a sub-IM-conference is REQ -3: A scenario where a side-bar or/and a sub-IM-conference is
being held as a part of SIP conference MUST be addressed. being held as a part of SIP conference MUST be addressed.
4. Security Considerations 4. Security Considerations
EditorĘs Note: Will be provided in the next version of the document. This document discusses high level requirements for SIP conferencing.
Conferencing has some specific security requirements which will be
summarized here at a very high level.
All of the operations and functions described in this document need
to be authorized by a focus or a participant. It is expected that
conferences will be governed by a set of authorization rules defined
as a part of the conference policy. In order for the conference
policy to be implemented, 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 will be discussed in detail in the
protocol documents.
Conferencing also has privacy implications. Some of these are
discussed in this document. Standard SIP mechanisms for a user agent
to request privacy should be utilized by a focus and will be detailed
in the protocol documents.
5. Contributors 5. Contributors
This work is based on the discussions among the members of the SIP This work is based on the discussions among the members of the SIP
Conferencing design team. Conferencing design team.
Normative References 6. References
6.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
Informative References 6.2 Informative References
Authors' Addresses Authors' Addresses
Orit Levin Orit Levin
RADVISION Microsoft Corporation
266 Harristown Road One Microsoft Way
Glen Rock, NJ 75024 Redmond, WA 98052
EMail: orit@radvision.com EMail: oritl@microsoft.com
Roni Even Roni Even
Polycom Polycom
94 Derech Em Hamoshavot 94 Derech Em Hamoshavot
Petach Tikva, Israel Petach Tikva, Israel
EMail: roni.even@polycom.co.il EMail: roni.even@polycom.co.il
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/