WDIFF

draft-ietf-sipping-conferencing-framework-02.txt --> draft-ietf-sipping-conferencing-framework-03.txt

SIP
SIPPING J. Rosenberg
Internet-Draft dynamicsoft Cisco Systems
Expires: December 28, 2004 June 29, April 18, 2005 October 18, 2004

A Framework for Conferencing with the Session Initiation Protocol
draft-ietf-sipping-conferencing-framework-02
draft-ietf-sipping-conferencing-framework-03

Status of this Memo

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I 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 December 28, 2004. April 18, 2005.

Abstract

The Session Initiation Protocol (SIP) supports the initiation,
modification, and termination of media sessions between user agents.
These sessions are managed by SIP dialogs, which represent a SIP
relationship between a pair of user agents. Because dialogs are
between pairs of user agents, SIP's usage for two-party
communications (such as a phone call), is obvious. Communications
sessions with multiple participants, generally known as conferencing,
are more complicated. This document defines a framework for how such
conferencing can occur. This framework describes the overall
architecture, terminology, and protocol components needed for

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 1]

Internet-Draft Conferencing Framework June October 2004

multi-party conferencing.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4
3. Overview of Conferencing Architecture . . . . . . . . . . . . 8 7
3.1 Usage of URIs . . . . . . . . . . . . . . . . . . . . . . 11 10
4. Functions of the Elements . . . . . . . . . . . . . . . . . . 13 12
4.1 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12
4.2 Conference Policy Server . . . . . . . . . . . . . . . . . 14 13
4.3 Mixers . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13
4.4 Conference Notification Service . . . . . . . . . . . . . 15 13
4.5 Participants . . . . . . . . . . . . . . . . . . . . . . . 16 14
4.6 Conference Policy . . . . . . . . . . . . . . . . . . . . 16 14
5. Common Operations . . . . . . . . . . . . . . . . . . . . . . 18 15
5.1 Creating Conferences . . . . . . . . . . . . . . . . . . . 18
5.1.1 SIP Mechanisms . . . . . . . . . . . . . . . . . . . . 18
5.1.2 CPCP Mechanisms . . . . . . . . . . . . . . . . . . . 19
5.1.3 Non-Automated Mechanisms . . . . . . . . . . . . . . . 19 15
5.2 Adding Participants . . . . . . . . . . . . . . . . . . . 19
5.2.1 SIP Mechanisms . . . . . 16
5.3 Removing Participants . . . . . . . . . . . . . . . 19
5.2.2 CPCP Mechanisms . . . 16
5.4 Creating Sidebars . . . . . . . . . . . . . . . . 20
5.2.3 Non-Automated Mechanisms . . . . 16
5.5 Destroying Conferences . . . . . . . . . . . 20
5.3 Conditional Joins . . . . . . . 17
5.6 Obtaining Membership Information . . . . . . . . . . . . . 20
5.4 17
5.7 Adding and Removing Participants . . . . Media . . . . . . . . . . . . . . 21
5.4.1 SIP Mechanisms . . 17
5.8 Conference Announcements and Recordings . . . . . . . . . 18
5.9 Floor Control . . . . . . . . . 21
5.4.2 CPCP Mechanisms . . . . . . . . . . . . . 20
6. Physical Realization . . . . . . 21
5.4.3 Non-Automated Mechanisms . . . . . . . . . . . . . . . 21
5.5 Approving Policy Changes . . . .
6.1 Centralized Server . . . . . . . . . . . . . 22
5.6 Creating Sidebars . . . . . . . 21
6.2 Endpoint Server . . . . . . . . . . . . . 24
5.7 Destroying Conferences . . . . . . . . 21
6.3 Media Server Component . . . . . . . . . . 24
5.7.1 SIP Mechanisms . . . . . . . . 23
6.4 Distributed Mixing . . . . . . . . . . . . 25
5.7.2 CPCP Mechanisms . . . . . . . . 24
6.5 Cascaded Mixers . . . . . . . . . . . 25
5.7.3 Non-Automated Mechanisms . . . . . . . . . . 26
7. Security Considerations . . . . . 25
5.8 Obtaining Membership Information . . . . . . . . . . . . . 25
5.8.1 SIP Mechanisms . 28
8. Contributors . . . . . . . . . . . . . . . . . . . 25
5.8.2 CPCP Mechanisms . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . 25
5.8.3 Non-Automated Mechanisms . . . . . . . . . . 30
10. Changes from draft-ietf-sipping-conferencing-framework-02 . 31
11. Changes from draft-ietf-sipping-conferencing-framework-00 . 32
12. Changes since
draft-rosenberg-sipping-conferencing-framework-01 . . . 25
5.9 Adding and Removing Media . . 33
13. Changes since
draft-rosenberg-sipping-conferencing-framework-00 . . . . . 34
14. Informative References . . . . . . . . . 26
5.9.1 SIP Mechanisms . . . . . . . . . . 34
Author's Address . . . . . . . . . . 26
5.9.2 CPCP Mechanisms . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . 26
5.9.3 Non-Automated Mechanisms . . . . . . . . . . . . . . . 26
5.10 Conference Announcements and Recordings . . . . . . . . . 26
5.11 Floor Control . . . . . . . . . . . . . . . . . . . . . . 28
5.12 Camera and Video Controls . . . . . . . . . . . . . . . . 28
6. Physical Realization . . . . . . . . . . . . . . . . . . . . . 29
6.1 Centralized Server . . . . . . . . . . . . . . . . . . . . 29

Rosenberg Expires December 28, 2004 [Page 2]

Internet-Draft Conferencing Framework June 2004

6.2 Endpoint Server . . . . . . . . . . . . . . . . . . . . . 29
6.3 Media Server Component . . . . . . . . . . . . . . . . . . 31
6.4 Distributed Mixing . . . . . . . . . . . . . . . . . . . . 32
6.5 Cascaded Mixers . . . . . . . . . . . . . . . . . . . . . 34
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37
9. Changes from draft-ietf-sipping-conferencing-framework-00 . . 38
10. Changes since
draft-rosenberg-sipping-conferencing-framework-01 . . . . . 39
11. Changes since
draft-rosenberg-sipping-conferencing-framework-00 . . . . . 40
12. Informative References . . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . 43

Rosenberg Expires December 28, 2004 [Page 3]

Internet-Draft Conferencing Framework June 2004

1. Introduction

The Session Initiation Protocol (SIP) [1] supports the initiation,
modification, and termination of media sessions between user agents.
These sessions are managed by SIP dialogs, which represent a SIP
relationship between a pair of user agents. Because dialogs are
between pairs of user agents, SIP's usage for two-party
communications (such as a phone call), is obvious. Communications
sessions with multiple participants, however, are more complicated.
SIP can support many models of multi-party communications. One,
referred to as loosely coupled conferences, makes use of multicast
media groups. In the loosely coupled model, there is no signaling
relationship between participants in the conference. There is no
central point of control or conference server. Participation is
gradually learned through control information that is passed as part
of the conference (using the Real Time Control Protocol (RTCP) [2],
for example). Loosely coupled conferences are easily supported in
SIP by using multicast addresses within its session descriptions.

In another model, referred to as fully distributed multiparty
conferencing, each participant maintains a signaling relationship
with each other participant, using SIP. There is no central point of
control; it is completely distributed amongst the participants. This
model is outside the scope of this document.

In another model, sometimes referred to as the tightly coupled
conference, there is a central point of control. Each participant
connects to this central point. It provides a variety of conference
functions, and may possibly perform media mixing functions as well.
Tightly coupled conferences are not directly addressed by RFC 3261,
although basic participation is possible without any additional
protocol support.

This document is one of a series of specifications that discusses
tightly coupled conferences. Here, we present the overall framework
for tightly coupled conferencing, referred to simply as
"conferencing" from this point forward. This framework presents a
general architectural model for these conferences, presents
terminology used to discuss such conferences, and describes the sets
of protocols involved in a conference. The aim of the framework is
to meet the general requirements for conferencing that are outlined
in [3].

Rosenberg Expires December 28, 2004 [Page 4]

Internet-Draft Conferencing Framework June 2004

2. Terminology
Conference: Conference is an overused term which has different
meanings in different contexts. In SIP, a conference is an
instance of a multi-party conversation. Within the context of
this specification, a conference is always a tightly coupled
conference.
Loosely Coupled Conference: A loosely coupled conference is a
conference without coordinated signaling relationships amongst
participants. Loosely coupled conferences frequently use
multicast for distribution of conference memberships.
Tightly Coupled Conference: A tightly coupled conference is a
conference in which a single user agent, referred to as a focus,
maintains a dialog with each participant. The focus plays the
role of the centralized manager of the conference, and is
addressed by a conference URI.
Focus: The focus is a SIP user agent that is addressed by a
conference URI and identifies a conference (recall that a
conference is a unique instance of a multi-party conversation).
The focus maintains a SIP signaling relationship with each
participant in the conference. The focus is responsible for
ensuring, in some way, that each participant receives the media
that make up the conference. The focus also implements conference
policies. The focus is a logical role.
Conference URI: A URI, usually a SIP URI, which identifies the focus
of a conference.
Participant: The software element that connects a user or automata to
a conference. It implements, at a minimum, a SIP user agent, but
may also include a conference policy control protocol client, for
example.
Conference Notification Service: A conference notification service is
a logical function provided by the focus. The focus can act as a
notifier [4], accepting subscriptions to the conference state, and
notifying subscribers about changes to that state. The state
includes the state maintained by the focus itself, the conference
policy, and the media policy.
Conference Policy Server: A conference policy server is a logical
function which can store and manipulate the conference policy.
The conference policy is the overall set of rules governing
operation of the conference. It is broken into membership policy
and media policy. Unlike the focus, there is not an instance of
the conference policy server for each conference. Rather, there
is an instance of the membership and media policies for each
conference.
Conference Policy: The complete set of rules for a particular
conference manipulated by the conference policy server. It
includes the membership policy and the media policy. There is an
instance of conference policy for each conference.

Rosenberg Expires December 28, 2004 [Page 5]

Internet-Draft Conferencing Framework June 2004

Membership Policy: A set of rules manipulated by the conference
policy server regarding participation in a specific conference.
These rules include directives on the lifespan of the conference,
who can and cannot join the conference, definitions of roles
available in the conference and the responsibilities associated
with those roles, and policies on who is allowed to request which
roles.
Media Policy: A set of rules manipulated by the conference policy
server regarding the media composition of the conference. The
media policy is used by the focus to determine the mixing
characteristics for the conference. The media policy includes
rules about which participants receive media from which other
participants, and the ways in which that media is combined for
each participant. In the case of audio, these rules can include
the relative volumes at which each participant is mixed. In the
case of video, these rules can indicate whether the video is
tiled, whether the video indicates the loudest speaker, and so on.
Conference Policy Control Protocol (CPCP): The protocol used by
clients to manipulate the conference policy.
Mixer: A mixer receives a set of media streams of the same type, and
combines their media in a type-specific manner, redistributing the
result to each participant. This includes media transported using
RTP \cite{rfc1889}. As a result, the term defined here is a
superset of the mixer concept defined in RFC 1889, since it allows
for non-RTP-based media such as instant messaging sessions [5].
Conference-Unaware Participant: A conference-unaware participant is a
participant in a conference that is not aware that it is actually
in a conference. As far as the UA is concerned, it is a
point-to-point call.
Cascaded Conferencing: A mechanism for group communications in which
a set of conferences are linked by having their focuses interact
in some fashion.
Simplex Cascaded Conferences: a group of conferences which are linked
such that the user agent which represents the focus of one
conference is a conference-unaware participant in another
conference.
Conference-Aware Participant: A conference-aware participant is a
participant in a conference that has learned, through automated
means, that it is in a conference, and that can use a conference
policy control protocol, media policy control protocol, or
conference subscription, to implement advanced functionality.
Conference Server: A conference server is a physical server which
contains, at a minimum, the focus. It may also include a
conference policy server and mixers.
Mass Invitation: A conference policy control protocol request to
invite a large number of users into the conference.

Rosenberg Expires December 28, 2004 [Page 6]

Internet-Draft Conferencing Framework June 2004

Mass Ejection: A conference policy control protocol request to remove
a large number of users from the conference.
Sidebar: A sidebar appears to the users within the sidebar as a
"conference within the conference". It is a conversation amongst
a subset of the participants to which the remaining participants
are not privy.
Anonymous Participant: An anonymous participant is one that is known
to other participants through the conference notification service,
but whose identity is being withheld.
Hidden Participant: A hidden participant is one that is not known to
other participants in the conference. They may be known to the
moderator, depending on conference policy.

Rosenberg Expires December 28, 2004 [Page 7]

Internet-Draft Conferencing Framework June 2004

3. Overview of Conferencing Architecture

+-----------+
| |
| |
|Participant|
| 4 |
| |
+-----------+
|
|SIP
|Dialog
|4
|
+-----------+ +-----------+ +-----------+
| | | | | |
| | | | | |
|Participant|-----------| Focus |------------|Participant|
| 1 | SIP | | SIP | 3 |
| | Dialog | | Dialog | |
+-----------+ 1 +-----------+ 3 +-----------+
|
|
|SIP
|Dialog
|2
|
+-----------+
| |
| |
|Participant|
| 2 |
| |
+-----------+

Figure 1

The central component (literally) in a SIP conference is the focus.
The focus maintains a SIP signaling relationship with each
participant in the conference. The result is a star topology, shown
in Figure Figure 1.

The focus is responsible for making sure that the media streams which
constitute the conference are available to the participants in the
conference. It does that through the use of one or more mixers, each
of which combines a number of input media streams to produce one or

Rosenberg Expires December 28, 2004 [Page 8]

Internet-Draft Conferencing Framework June 2004

more output media streams. The focus uses the media policy to
determine the proper configuration of the mixers.

The focus has access to the conference policy (composed of the
membership and media policies), an instance of which exist for each
conference. Effectively, the conference policy can be thought of as
a database which describes the way that the conference should
operate. It is the responsibility of the focus to enforce those
policies. Not only does the focus need read access to the database,
but it needs to know when it has changed. Such changes might result
in SIP signaling (for example, the ejection of a user from the
conference using BYE), and most changes will require a notification
to be sent to subscribers using the conference notification service.

The conference is represented by a URI, which identifies the focus.
Each conference has a unique focus and a unique URI identifying that
focus. Requests to the conference URI are routed to the focus for
that specific conference.

Users usually join the conference by sending an INVITE to the
conference URI. As long as the conference policy allows, the INVITE
is accepted by 36

Rosenberg Expires April 18, 2005 [Page 2]

Internet-Draft Conferencing Framework October 2004

1. Introduction

The Session Initiation Protocol (SIP) [1] supports the focus initiation,
modification, and the termination of media sessions between user is brought into the conference.
Users can leave the conference agents.
These sessions are managed by sending a BYE, as they would in a
normal call.

Similarly, the focus can terminate a dialog with SIP dialogs, which represent a participant,
should the conference policy change to indicate that the participant
is no longer allowed in the conference. A focus can also initiate an
INVITE, should the conference policy indicate that the focus needs to
bring SIP
relationship between a participant into the conference.

The notion pair of a conference-unaware participant is important in this
framework. A conference-unaware participant does not even know that
the UA it is communicating with happens to be a focus. As far as
it's concerned, its a UA just like any other. The focus, user agents. Because dialogs are
between pairs of course,
knows that its a focus, and it performs the tasks needed user agents, SIP's usage for the
conference to operate.

Conference-unaware participants have access to two-party
communications (such as a good deal of
functionality. They can join and leave conferences using SIP, and
obtain more advanced features through stimulus signaling, phone call), is obvious. Communications
sessions with multiple participants, however, are more complicated.
SIP can support many models of multi-party communications. One,
referred to as
discussed loosely coupled conferences, makes use of multicast
media groups. In the loosely coupled model, there is no signaling
relationship between participants in [6]. However, if the participant wishes to explicitly conference. There is no
central point of control aspects or conference server. Participation is
gradually learned through control information that is passed as part
of the conference using functional signaling
protocols, (using the participant must be conference-aware.

Rosenberg Expires December 28, 2004 [Page 9]

Internet-Draft Conferencing Framework June 2004

.....................................
. .
. .
. .
. .
. Conference .
. Policy .
Conference . .
Policy . +-----------+ //-----\\ . Real Time Control . | | || || . Protocol . | Conference| \\-----// .
+---------------->| Policy | | | .
| . | Server |----> |Membership .
| . | | | | .
| . +-----------+ | & | .
| . | | .
| . | Media | .
+-----------+ . +-----------+ | Policy| .
| | . | | \ // .
| | . | | \-----/ .
|Participant|<--------->| Focus | | .
| | (RTCP) [2],
for example). Loosely coupled conferences are easily supported in
SIP . | | | .
| | Dialog . | |<-----------+ .
+-----------+ . |...........| .
^ . | Conference| .
| . |Notification .
+------------>| Service | .
Subscription. +-----------+ .
. .
. .
. .
. .
.....................................

Conference
Functions

Figure 2

A conference-aware by using multicast addresses within its session descriptions.

In another model, referred to as fully distributed multiparty
conferencing, each participant maintains a signaling relationship
with each other participant, using SIP. There is one that has access to advanced
functionality through additional protocol interfaces. The client
uses these protocols no central point of
control; it is completely distributed amongst the participants. This
model is outside the scope of this document.

In another model, sometimes referred to interact with as the tightly coupled
conference, there is a central point of control. Each participant
connects to this central point. It provides a variety of conference policy server
functions, and may possibly perform media mixing functions as well.
Tightly coupled conferences are not directly addressed by RFC 3261,
although basic participation is possible without any additional
protocol support.

This document is one of a series of specifications that discusses
tightly coupled conferences. Here, we present the focus. A model overall framework
for tightly coupled conferencing, referred to simply as
"conferencing" from this interaction is shown point forward. This framework presents a
general architectural model for these conferences, presents
terminology used to discuss such conferences, and describes the sets
of protocols involved in Figure
Figure 2. The participant can interact with a conference. It also discusses the focus using
extensions, such as REFER, ways in order to access enhanced call control
functions [7].
which SIP itself is involved in conferencing. The participant can SUBSCRIBE to aim of the conference URI,
and be connected
framework is to meet the conference notification service provided by general requirements for conferencing that
are outlined in [3]. An additional document, the focus. Through this mechanism, it can learn about changes Centralized
Conferencing (XCON) framework [16], discusses the non-SIP signaling
aspects of conferencing in more detail, as well as providing
additional functionality and details necessary for a generic protocol
agnostic conferencing architecture.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 10] 3]

Internet-Draft Conferencing Framework June October 2004

participants (effectively, the state

The participant can communicate with the context of
this specification, a conference policy server
using is always a tightly coupled
conference.
Loosely Coupled Conference: A loosely coupled conference policy control protocol. Through this protocol,
it can affect the is a
conference policy. The without coordinated signaling relationships amongst
participants. Loosely coupled conferences frequently use
multicast for distribution of conference memberships.
Tightly Coupled Conference: A tightly coupled conference policy server
need not be available in any particular conference, although there is
always a
conference policy. in which a single user agent, referred to as a focus,
maintains a dialog with each participant. The interfaces between the focus and the conference policy, and the
conference policy server and plays the conference policy, are not subject
to standardization at
role of the time centralized manager of this writing. They are intended
primarily to show the logical roles involved in a conference, as
opposed to suggesting and is
addressed by a physical decomposition. conference URI.
Focus: The separation of
these functions focus is documented here to encourage clarity in the
requirements and to allow individual implementations the flexibility
to compose a conferencing system in SIP user agent that is addressed by a scalable
conference URI and robust manner.

3.1 Usage of URIs

It is fundamental to this framework identifies a conference (recall that a
conference is uniquely
identified by a URI, and that this URI identifies unique instance of a multi-party conversation).
The focus maintains a SIP signaling relationship with each
participant in the conference. The focus which is responsible for
ensuring, in some way, that each participant receives the media
that make up the conference. The focus also implements conference URI
policies. The focus is unique, such
that no two conferences have the same conference URI. a logical role.
Conference URI: A conference
URI is always URI, usually a SIP or SIPS URI.

The conference URI is opaque to any participants which might use it.
There is no way to look at the URI, and know for certain whether it which identifies the focus
of a focus, as opposed to conference.
Participant: The software element that connects a user or an interface on automata to
a PSTN
gateway. This is in line with conference. It implements, at a minimum, a SIP user agent, but
may also include a conference policy control protocol client, for
example.
Conference State: The state of the general philosophy conference includes the state of URI usage
[8]. However, contextual information surrounding
the URI (for
example, SIP header parameters) may indicate that focus and the URI represents
a conference.

When a SIP request is sent conference policy. Focus state includes the set
of participants connected to the focus and the state of their
respective dialogs.
Conference Notification Service: A conference URI, that request notification service is
routed
a logical function provided by the focus. The focus can act as a
notifier [4], accepting subscriptions to the focus, conference state, and only
notifying subscribers about changes to the focus. The element or system that creates state. The state
includes the state maintained by the focus itself, the conference
policy, and the media policy.
Conference Policy Server: A conference URI policy server is responsible for guaranteeing this
property.

The conference URI can represent a long-lived logical
function which can store and manipulate the conference or interest
group, such as "sip:discussion-on-dogs@example.com". policy.
The focus
identified by this URI would always exist, conference policy is the overall set of rules governing
operation of the conference, and always be managing include membership policy and
media policy. Unlike the focus, there is not an instance of the
conference policy server for whatever participants are currently joined. Other
conference URIs can represent short-lived conferences, such as an
ad-hoc each conference.

Ideally, a conference URI is never constructed or guessed by a user. Rather, there is an
instance of the conference URIs are learned through many mechanisms. A policy for each conference instance.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 11] 4]

Internet-Draft Conferencing Framework June October 2004

conference URI can be emailed or sent in an instant message. A
conference URI can be linked on

Conference Policy: The complete set of rules for a web page. A particular
conference URI can be
obtained from a manipulated by the conference policy control protocol, which can be server. The
policy includes membership and media policies. The conference
policy is used to create conferences specify and control the policies associated with them.

To determine that a SIP URI does represent operation of a focus, standard
techniques for URI capability discovery can be used. Specifically,
the callee capabilities specification [9] provides the "isfocus"
feature tag to indicate that
conference instance.
Membership Policy: A set of rules manipulated by the URI is a focus. Caller preferences
parameters are also used to indicate that conference
policy server regarding participation in a focus supports specific conference.
These rules include directives on the
conference notification service. This is done by declaring support
for lifespan of the SUBSCRIBE method conference,
who can and cannot join the relevant package(s) conference, definitions of roles
available in the caller
preferences feature parameters conference and the responsibilities associated
with the conference URI.

The other functions in a conference are also represented those roles, and policies on who is allowed to request which
roles.
Media Policy: A set of rules manipulated by URIs. If the conference policy
server regarding the media composition of the conference. The
media policy is implemented through web pages, this
server is identified used by HTTP URIs. If it is accessed using an
explicit protocol, it is a URI defined for that protocol.

Starting with the conference URI, focus to determine the URIs mixing
characteristics for the conference. The media policy includes
rules about which participants receive media from which other logical
entities
participants, and the ways in which that media is combined for
each participant. In the conference case of audio, these rules can be learned using include
the conference
notification service.

Rosenberg Expires December 28, 2004 [Page 12]

Internet-Draft Conferencing Framework June 2004

4. Functions relative volumes at which each participant is mixed. In the
case of video, these rules can indicate whether the Elements

This section gives video is
tiled, whether the video indicates the loudest speaker, and so on.
Mixer: A mixer receives a more detailed description set of media streams of the functions
typically implemented same type, and
combines their media in each of a type-specific manner, redistributing the elements.

4.1 Focus
result to each participant. This includes media transported using
RTP [2]. As its name implies, a result, the focus term defined here is the center a superset of the conference. All
participants
mixer concept defined in the conference are connected to RFC 3550, since it by allows for
non-RTP-based media such as instant messaging sessions [5].
Conference-Unaware Participant: A conference-unaware participant is a SIP dialog.
The focus
participant in a conference that is responsible for maintaining the dialogs connected to it.
It ensures not aware that it is actually
in a conference. As far as the dialogs are connected to UA is concerned, it is a
point-to-point call.
Cascaded Conferencing: A mechanism for group communications in which
a set of participants
who conferences are allowed to participate in the conference, as defined linked by the
membership policy. The focus also uses SIP to manipulate the media
sessions, having their focuses interact
in order to make sure each participant obtains all the
media for some fashion.
Simplex Cascaded Conferences: a group of conferences which are linked
such that the conference. To do that, user agent which represents the focus makes use of mixers.

When one
conference is a focus receives an INVITE, it checks the membership policy.
The membership policy might indicate that this conference-unaware participant in another
conference.
Conference-Aware Participant: A conference-aware participant is not
allowed to join, a
participant in which case the call can be rejected. It might
indicate a conference that another participant, acting as has learned, through automated
means, that it is in a moderator, needs to
approve this new participant. In conference, and that case, the INVITE might be
parked on can use a conference
policy control protocol, media policy control protocol, or
conference subscription, to implement advanced functionality.
Conference Server: A conference server is a physical server which
contains, at a music-on-hold server, or minimum, the focus. It may also include a 183 response might be sent to
indicate progress.
conference policy server and mixers.

Rosenberg Expires April 18, 2005 [Page 5]

Internet-Draft Conferencing Framework October 2004

Mass Invitation: A notification, using the conference notification
service, would be sent to the moderator. The moderator then has the
ability policy control protocol request to manipulate the policies using
invite a large number of users into the conference.
Mass Ejection: A conference policy control protocol. If protocol request to remove
a large number of users from the policies are changed conference.
Sidebar: A sidebar appears to allow this new
participant, the focus can accept users within the INVITE (or unpark it from sidebar as a
"conference within the
music-on-hold server). The interpretation conference". It is a conversation amongst
a subset of the membership policy
by participants to which the focus is, itself, a matter of local policy, and remaining participants
are not subject to
standardization.

If a privy.
Anonymous Participant: An anonymous participant manipulated the membership policy to indicate is one that a
certain is known
to other participant was no longer allowed participants through the conference notification service,
but whose identity is being withheld.

Rosenberg Expires April 18, 2005 [Page 6]

Internet-Draft Conferencing Framework October 2004

3. Overview of Conferencing Architecture

Figure 1

The central component (literally) in a SIP conference is the conference,
the focus.
The focus would send maintains a BYE to that other SIP signaling relationship with each
participant to remove them.
This is often referred to as "ejecting" a user from in the conference. The process of ejecting fundamentally constitutes these two steps -
the establishment of the policy through the conference policy
protocol, and the implementation of that policy (using a BYE) by the
focus.

Similarly, if result is a user manipulated the membership policy to indicate star topology, shown
in Figure Figure 1.

The focus is responsible for making sure that a number of users need to be added to the conference, media streams which
constitute the focus
would send an INVITE to those participants. This is often referred conference are available to as the "mass invitation" function. As with ejection, it is
fundamentally composed of participants in the policy functions
conference. It does that specify the
participants which should be present, and through the implementation use of those
functions. A policy request to add one or more mixers, each
of which combines a set number of users might not require
an INVITE input media streams to execute it; those users might already be participants in produce one or

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 13] 7]

Internet-Draft Conferencing Framework June October 2004

more output media streams. The focus uses the conference.

A similar model media policy to
determine the proper configuration of the mixers.

The focus has access to the conference and media policies, for which
an instance of each exists for media policy. If each conference. Effectively, the media
conference policy
indicates that can be thought of as a participant database which describes the
way that the conference should not receive any video, operate. It is the responsibility of
the focus
might implement that policy by sending a re-INVITE, removing to enforce those policies. Not only does the
media stream focus need
read access to that participant. Alternatively, if the video is
being centrally mixed, database, but it could inform the mixer needs to send know when it has
changed. Such changes might result in SIP signaling (for example,
the ejection of a black
screen to that participant. The means by which user from the policy is
implemented are not subject to specification.

4.2 Conference Policy Server

The conference policy server allows clients to manipulate using BYE), and
interact with most
changes will require a notification to be sent to subscribers using
the conference policy. The notification service. Further details on conference
and media policy is used
by provided in the focus to make authorization decisions and guide its overall
behavior. Logically speaking, there is a one-to-one mapping between
a conference policy and a focus. XCON framework document [16].

The conference policy is represented by a URI. There is a unique
conference policy for each conference. The conference policy URI
points to a conference policy server which can manipulate that
conference policy. A conference policy server also has a "top level"
URI URI, which can be used to access functions that are independent of any
conference. Perhaps the most important of these functions is identifies the
creation of a new conference. Creation of a new focus.
Each conference will
result in the construction of has a new unique focus and a corresponding
conference URI, which can then be used unique URI identifying that
focus. Requests to the conference URI are routed to the focus for
that specific conference.

Users usually join the conference itself,
along with a media policy and by sending an INVITE to the
conference policy.

The URI. As long as the conference policy server allows, the INVITE
is accessed using a client-server
transactional protocol. The client accepted by the focus and the user is brought into the conference.
Users can be leave the conference by sending a participant BYE, as they would in a
normal call.

Similarly, the
conference, or it focus can be terminate a third party. Access control lists for who
can modify dialog with a conference policy are themselves part of participant,
should the conference
policy.

The conference policy server is responsible for reconciliation of
potentially conflicting requests regarding change to indicate that the policy for participant
is no longer allowed in the conference.

The client of A focus can also initiate an
INVITE, should the conference policy control protocol can be any
entity interested in manipulating indicate that the conference policy. Clearly,
participants might be interested focus needs to
bring a participant into the conference.

The notion of a conference-unaware participant is important in manipulating them. this
framework. A conference-unaware participant
might want does not even know that
the UA it is communicating with happens to raise or lower be a focus. As far as
it's concerned, its a UA just like any other. The focus, of course,
knows that its a focus, and it performs the volume tasks needed for one of the other
conference to operate.

Conference-unaware participants it is hearing. Or, a participant might want have access to add a
user to good deal of
functionality. They can join and leave conferences using SIP, and
obtain more advanced features through stimulus signaling, as
discussed in [6]. However, if the conference.

A client participant wishes to explicitly
control aspects of the conference policy protocol could also be another
server whose job is to determine using functional signaling
protocols, the conference policy. As an participant must be conference-aware.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 14] 8]

Internet-Draft Conferencing Framework June October 2004

example, a floor control server is responsible for determining which
participant(s) in a conference are allowed to speak at any given
time, based on

.....................................
. .
. .
. .
. .
. Conference .
. Policy .
Conference . .
Policy . +-----------+ //-----\\ .
Control . | | || || .
Protocol . | Conference| \\-----// .
+---------------->| Policy | | | .
| . | Server |----> |Membership .
| . | | | | .
| . +-----------+ | & | .
| . | | .
| . | Media | .
+-----------+ . +-----------+ | Policy| .
| | . | | \ // .
| | . | | \-----/ .
|Participant|<--------->| Focus | | .
| | SIP . | | | .
| | Dialog . | |<-----------+ .
+-----------+ . |...........| .
^ . | Conference| .
| . |Notification .
+------------>| Service | .
Subscription. +-----------+ .
. .
. .
. .
. .
.....................................

Conference
Functions

Figure 2

A conference-aware participant requests and access rules. The floor
control server would act as a client of the conference policy server,
and change the media policy based on who is allowed one that has access to speak. advanced
functionality through additional protocol interfaces. The client of
uses these protocols to interact with the conference policy control protocol could also be
another conference policy server.

4.3 Mixers server
and the focus. A mixer is responsible model for combining the media streams that make up this interaction is shown in Figure
Figure 2. The participant can interact with the conference, and generating one or more output streams that are
distributed focus using
extensions, such as REFER, in order to recipients (which could be participants or other
mixers). access enhanced call control
functions [7]. The process of combining media is specific participant can SUBSCRIBE to the media
type, conference URI,
and is directed be connected to the conference notification service provided by
the focus, under focus. Through this mechanism, it can learn about changes in

Rosenberg Expires April 18, 2005 [Page 9]

Internet-Draft Conferencing Framework October 2004

participants (effectively, the guidance state of the rules
described in dialogs), the media policy.

A mixer is not aware of a "conference" as an entity, per se. A mixer
receives media streams as inputs,
policy, and based on directions provided by the focus, generates media streams as outputs. There is no grouping
of media streams beyond membership policy.

The participant can communicate with the policies that describe conference policy server
using a conference policy control protocol. Through this protocol,
it can affect the ways conference policy. The conference policy server
need not be available in which
the streams are mixed.

A mixer any particular conference, although there is
always under the control of a focus. conference policy.

The interfaces between the focus is
responsible for interpreting and the media conference policy, and then installing
the appropriate rules in the mixer. If the focus is directly
controlling a mixer,
conference policy server and the mixer can either be co-resident with conference policy are detailed in
the
focus, or can be controlled through some kind XCON framework document [16]. For the purposes of protocol.

However, a focus need not directly control SIP-based
conferencing, they serve as logical roles involved in a mixer. Rather, conference,
as opposed to representing a focus
can delegate physical decomposition. The separation
of these functions is documented here to encourage clarity in the mixing
requirements and to ensure compatibility between SIP based
conferencing and the extensions to the participants, each of which has their
own mixer. This is framework described in Section Section 6.4.

4.4 Conference Notification Service

The focus can provide a conference notification service. In [16].
More importantly, this
role, it acts as approach provides individual SIP
implementations the flexibility to compose a notifier, as defined conferencing system in RFC 3265 [4]. It accepts
subscriptions from clients for the conference URI, a
scalable and generates
notifications to them as robust manner without requiring the state complete development
of the conference changes.

This state is composed these interfaces.

3.1 Usage of two separate pieces. The first URIs

It is the
state of fundamental to this framework that a conference is uniquely
identified by a URI, and that this URI identifies the focus and which is
responsible for the second conference. The conference URI is unique, such
that no two conferences have the same conference policy. URI. A
subscriber to the conference notification service can use
capabilities defined in the
URI is always a SIP events framework [4] to request that
it receive focus state changes only, conference policy changes only, or both.

Rosenberg Expires December 28, 2004 [Page 15]

Internet-Draft Conferencing Framework June 2004 SIPS URI.

The state of the focus includes the conference URI is opaque to any participants connected which might use it.
There is no way to look at the URI, and know for certain whether it
identifies a focus, as opposed to a user or an interface on a PSTN
gateway. This is in line with the
focus, and general philosophy of URI usage
[8]. However, contextual information about surrounding the dialogs associated with them. As
new participants join, this state changes, and is reported through URI (for
example, SIP header parameters) may indicate that the notification service. Similarly, when someone leaves, this state
also changes, allowing subscribers URI represents
a conference.

When a SIP request is sent to learn about this fact.

As described previously, the conference policy includes URI, that request is
routed to the
membership policy focus, and the media policy. As those policies change,
due only to usage of the CPCP, direct change by the focus, focus. The element or through an
application, system
that creates the conference notification service informs subscribers
of these changes.

4.5 Participants

A participant in a conference URI is any SIP user agent that has responsible for guaranteeing this
property.

The conference URI can represent a dialog
with long-lived conference or interest
group, such as "sip:discussion-on-dogs@example.com". The focus
identified by this URI would always exist, and always be managing the focus. This SIP user agent
conference for whatever participants are currently joined. Other
conference URIs can be a PC application, represent short-lived conferences, such as an

Rosenberg Expires April 18, 2005 [Page 10]

Internet-Draft Conferencing Framework October 2004

ad-hoc conference.

Ideally, a SIP
hardphone, conference URI is never constructed or guessed by a PSTN gateway. It user.
Rather, conference URIs are learned through many mechanisms. A
conference URI can also be another focus. emailed or sent in an instant message. A
conference which has URI can be linked on a participant that is the focus of another web page. A conference is called URI can be
obtained from a simplex cascaded conference. They conference policy control protocol, which can also be used
to provide scalable create conferences where there are regional
sub-conferences, each of which is connected to the main conference.

4.6 Conference Policy

The conference policy contains the rules that guide the operation of and the focus. The rules can be simple, such as an access list policies associated with them.

To determine that
defines the set of allowed participants in a conference. The rules SIP URI does represent a focus, standard
techniques for URI capability discovery can also be incredibly complex, specifying time-of-day based rules on
participation conditional on used. Specifically,
the presence of other participants. It
is important callee capabilities specification [9] provides the "isfocus"
feature tag to understand indicate that there is no restriction on the type
of rules that can be encapsulated in URI is a conference policy.

The conference policy can be manipulated using web applications or
voice applications. It can focus. Caller preferences
parameters are also be manipulated with proprietary
protocols. However, the conference policy control protocol can be used as to indicate that a standardized means of manipulating focus supports the
conference policy.
By notification service. This is done by declaring support
for the nature of conference policies, not all aspects of SUBSCRIBE method and the policy
can be manipulated relevant package(s) in the caller
preferences feature parameters associated with the conference policy control protocol. URI.

The other functions in a conference policy includes the membership policy and are also represented by URIs. If
the media
policy. The membership conference policy includes per-participant policies that
specify how the focus server is implemented through web pages, this
server is identified by HTTP URIs. If it is to handle a particular participant. These
include whether or not the participant accessed using an
explicit protocol, it is anonymous, a URI defined for example.

The media policy describes that protocol.

Starting with the way in which conference URI, the set of inputs to a
mixer are combined to generate URIs for the set of outputs. Media policies
can span media types. In other words, logical
entities in the policy on how one media
stream is mixed conference can be based on characteristics of other media learned using the conference
notification service.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 16] 11]

Internet-Draft Conferencing Framework June October 2004

streams. Media policies can be based on any quantifiable
characteristic

4. Functions of the media stream (its source, volume, codecs,
speaking/silence, etc.), and they can be based on internal or
external variables accessible by Elements

This section gives a more detailed description of the media policy.

Some examples functions
typically implemented in each of media policies include:
o The video output the elements.

4.1 Focus

As its name implies, the focus is the picture center of the loudest speaker (video
follows audio).
o The audio from each participant will be mixed with equal weight,
and distributed conference. All
participants in the conference are connected to all other participants.
o it by a SIP dialog.
The audio and video that is distributed focus is responsible for maintaining the one selected by dialogs connected to it.
It ensures that the
floor control server.

Rosenberg Expires December 28, 2004 [Page 17]

Internet-Draft Conferencing Framework June 2004

5. Common Operations

There dialogs are connected to a large number of ways in which users can interact with a
conference. They can join, leave, set policies, approve members, and
so on. This section is meant as an overview of the major
conferencing operations, summarizing how they operate. More detailed
examples of the SIP mechanisms can be found in [7].

5.1 Creating Conferences

There participants
who are many ways allowed to participate in which a conference can be created. the conference, as defined by the
membership policy. The
creation of a conference actually constructs several elements all at focus also uses SIP to manipulate the same time. It results media
sessions, in order to make sure each participant obtains all the creation
media for the conference. To do that, the focus makes use of mixers.

When a focus and a
conference receives an INVITE, it checks the membership policy. It also results
The membership policy might indicate that this participant is not
allowed to join, in the construction of a
conference URI, which uniquely identifies the focus. Since case the
conference URI call can be rejected. It might
indicate that another participant, acting as a moderator, needs to be unique, the element which creates
conferences is responsible for guaranteeing
approve this new participant. In that uniqueness. This
can case, the INVITE might be accomplished deterministically, by keeping records of
conference URIs, or by generating URIs algorithmically,
parked on a music-on-hold server, or
probabilistically, by creating random URI with sufficiently low
probabilities of collision.

When a media and 183 response might be sent to
indicate progress. A notification, using the conference policy are created, they are established
with default rules that are implementation dependent. If notification
service, would be sent to the creator
of moderator. The moderator then has the conference wishes
ability to change those rules, they would do so manipulate the policies using the conference policy control protocol (CPCP), for example.

Of course, using conference policy
control protocol. If the policies are changed to allow this new
participant, the focus can accept the INVITE (or unpark it from the CPCP requires that an element know
music-on-hold server). The interpretation of the URI for
manipulating membership policy
by the policy. That requires focus is, itself, a means matter of local policy, and not subject to learn
standardization.

If a participant manipulated the
conference membership policy URI from to indicate that a
certain other participant was no longer allowed in the conference URI, since conference,
the conference
URI focus would send a BYE to that other participant to remove them.
This is frequently the sole result returned often referred to the client as "ejecting" a result user from the conference.
The process of conference creation. Any other URIs associated with ejecting fundamentally constitutes these two steps -
the
conference are learned establishment of the policy through the conference notification service.
They are carried as elements in policy
protocol, and the notifications.

5.1.1 SIP Mechanisms

SIP can be used to create conferences hosted in implementation of that policy (using a central server BYE) by
sending an INVITE to the
focus.

Similarly, if a conferencing application user manipulated the membership policy to indicate
that would
automatically create a new conference and then place a user into it.

Creation number of conferences where users need to be added to the conference, the focus resides in
would send an endpoint
operates differently. There, the endpoint itself creates the
conference URI, and hands it out to other endpoints which are INVITE to be
the those participants. What differs from case This is often referred
to case as the "mass invitation" function. As with ejection, it is how
fundamentally composed of the endpoint
decides policy functions that specify the
participants which should be present, and the implementation of those
functions. A policy request to create add a conference.

One important case is the ad-hoc conference described set of users might not require
an INVITE to execute it; those users might already be participants in Section 6.2.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 18] 12]

Internet-Draft Conferencing Framework June October 2004

There, an endpoint unilaterally decides to create

the conference
based on local conference.

A similar model exists for media policy. The dialogs that were connected to If the UA are
migrated to media policy
indicates that a participant should not receive any video, the endpoint-hosted focus, using focus
might implement that policy by sending a re-INVITE to pass re-INVITE, removing the
conference URI
media stream to the newly joined participants. that participant. Alternatively, one UA can ask another UA to create an endpoint-hosted
conference. This is accomplished with the SIP Join header [10]. The
UA which receives the Join header in an invitation may need to create
a new conference URI (a new one is not needed if the dialog that video is
being joined is already part of a conference). The conference URI is
then handed to centrally mixed, it could inform the recently joined participants through a re-INVITE.

5.1.2 CPCP Mechanisms

Another way mixer to create a conference is through interaction with the
conference policy server. Using the conference policy control
protocol, send a client can instruct the conference policy server black
screen to
create a new conference and return that participant. The means by which the conference URI and conference policy URI.

5.1.3 Non-Automated Mechanisms

One way to create a conference is through interaction with an IVR
application.
implemented are not subject to specification.

4.2 Conference Policy Server

The user would send a SIP INVITE conference policy server allows clients to the conferencing
application. This application would manipulate and
interact with the user, collect
information about conference policy. The conference policy is used
by the desired conference, focus to make authorization decisions and create it. The user
can then be placed into their newly created conference.

Of course, guide its overall
behavior. Logically speaking, there is a user can also create conferences by interacting with one-to-one mapping between
a
web server. The web conference policy and a focus.

Further detail on the functionality and access to the policy server would prompt
are provided in the user XCON framework document [16].

4.3 Mixers

A mixer is responsible for combining the neccessary
information (start and stop times of media streams that make up
the conference, participants,
etc.) and return the conference URI generating one or more output streams that are
distributed to the user. recipients (which could be participants or other
mixers). The user would copy
this URI into their SIP phone, process of combining media is specific to the media
type, and send it an INVITE is directed by the focus, under the guidance of the rules
described in order to join the newly-created conference.

5.2 Adding Participants

There are many mechanisms for adding participants to media policy.

A mixer is not aware of a conference.
These include SIP, the conference policy control protocol, "conference" as an entity, per se. A mixer
receives media streams as inputs, and
non-automated means. In all cases, participant additions can be
first party (a user adds themself) or third party (a user adds
another user).

5.2.1 SIP Mechanisms

First person additions using SIP based on directions provided by
the focus, generates media streams as outputs. There is no grouping
of media streams beyond the policies that describe the ways in which
the streams are trivially accomplished with a
standard INVITE. mixed.

A participant can send an INVITE request to mixer is always under the
conference URI, control of a focus, either directly or
indirectly The focus is responsible for interpreting the media
policy, and if then installing the conference policy allows them to join,

Rosenberg Expires December 28, 2004 [Page 19]

Internet-Draft Conferencing Framework June 2004

they are added to appropriate rules in the conference. mixer. If a UA does not know
the conference URI, but has learned about a
dialog which focus is connected to directly controlling a conference (by using mixer, the dialog event
package, for example [11]), mixer can either be
co-resident with the UA focus, or can join be controlled through some kind of
protocol. If the conference by using focus is indirectly controlling a mixer, it
delegates the Join header mixing to join the dialog.

Third party additions with SIP are done using REFER [12]. participants, each of which has their own
mixer. This is described in Section 6.4.

4.4 Conference Notification Service

The client focus can send provide a REFER request to the participant, asking them to send an
INVITE request to the conference URI. Additionally, the client can
send a REFER request to the focus, asking notification service. In this

Rosenberg Expires April 18, 2005 [Page 13]

Internet-Draft Conferencing Framework October 2004

role, it to send an INVITE to the
participant. The latter technique has the benefit of allowing a
client to add acts as a conference-unaware participant that does not support notifier, as defined in RFC 3265 [4]. It accepts
subscriptions from clients for the REFER method.

5.2.2 CPCP Mechanisms

A basic function conference URI, and generates
notifications to them as the state of the conference policy control protocol changes.

This state is to add
participants. A client composed of the protocol can specify any SIP URI
(which may identify themself) that is to be added. If the URI does
not identify a user that two separate pieces. The first is already a participant in the conference,
state of the focus will send an INVITE to that URI in order to add them in.

5.2.3 Non-Automated Mechanisms

There are countless non-automated means for asking a participant to
join and the conference. Generally, they involve conveying second is the conference URI policy. A
subscriber to the desired participant, so that they can send an
INVITE to it. These mechanisms all require some kind of human
interaction.

As an example, a user conference notification service can send an instant message [13] to the third
party, containing an HTML document which requests use
capabilities defined in the user SIP events framework [4] to click
on request that
it receive focus state changes only, conference policy changes only,
or both.

The state of the hyperlink to join focus includes the conference:

<html>
Hey, would you like participants connected to <a href="sip:9sf88fk-99sd@conferences.example.com">join
</a> the conference now?
</html>

5.3 Conditional Joins

In many cases, a new participant will not wish to join
focus, and information about the conference
unless they can join dialogs associated with a particular set of policies. them. As an
example, a participant may want to join anonymously, so that other
new participants know that someone has joined, but not who. To

Rosenberg Expires December 28, 2004 [Page 20]

Internet-Draft Conferencing Framework June 2004

accomplish this, the conference policy control protocol join, this state changes, and is used to
establish these policies prior to reported through
the generation or acceptance of an
invitation notification service. Similarly, when someone leaves, this state
also changes, allowing subscribers to learn about this fact.

Conference notification associated with changes to the conference. For example, if conference
policies is discussed in [16].

4.5 Participants

A participant in a conference is any SIP user wishes to join agent that has a conference dialog
with a known conference URI, the focus. This SIP user would obtain the
URI for the conference policy, manipulate the policy to set themself
as an anonymous participant, and then actually join the agent can be a PC application, a SIP
hardphone, or a PSTN gateway. It can also be another focus. A
conference by
sending an INVITE request to which has a participant that is the focus of another
conference URI.

5.4 Removing Participants

As with additions, there are several mechanisms for departures.
These include SIP mechanisms and CPCP mechanisms. Removals is called a simplex cascaded conference. They can also be first person or third person.

5.4.1 SIP Mechanisms

First person departures
used to provide scalable conferences where there are trivially accomplished by sending a BYE
request regional
sub-conferences, each of which is connected to the focus. This terminates the dialog with main conference.

4.6 Conference Policy

The conference policy contains the focus and
removes rules that guide the participant from operation of
the conference.

Third person departures focus. The rules can also be done using SIP, through simple, such as an access list that
defines the REFER
method.

5.4.2 CPCP Mechanisms set of allowed participants in a conference. The CPCP rules
can also be used by a client to remove any participant (including
themself). When CPCP is used for this purpose, the focus will send a
BYE request to incredibly complex, specifying time-of-day based rules on
participation conditional on the participant that is being removed. The focus will
execute any presence of other signaling that participants. It
is needed to remove them (for
example, manipulate other dialogs in order important to manage understand that there is no restriction on the change type
of rules that can be encapsulated in
media streams). a conference policy.

The conference policy control protocol can be manipulated using web applications or
voice applications. It can also be used to remove a
large number of users. This manipulated with proprietary
protocols. The conference policy control protocol is generally referred to proposed as mass
ejection.

5.4.3 Non-Automated Mechanisms

As with the other common conferencing functions, there are many
non-automated ways to remove a participant. The identity
standardized means of the
participant can be entered into a web form. When the user clicks
submit, the focus sends a BYE to that participant, removing them from
the conference. Alternatively, manipulating the conference can expose an IM
interface, where the user can send an IM to policy. Further
detail on the conference saying
"remove Bob", causing the policy and conference server to remove Bob. policy control
protocol are provided in [16].

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 21] 14]

Internet-Draft Conferencing Framework June October 2004

5.5 Approving Policy Changes
OPEN ISSUE: The basic mechanism described here depends on the
actual protocols used for conference and media policy
manipulation. If the protocol itself provides change
notifications, sip-events may not be needed for that purpose.
Thus, this description here is tentative.

A conference policy for

5. Common Operations

There are a particular conference may designate one or
more large number of ways in which users as moderators for some can interact with a
conference. They can join, leave, set of media policy or conference
policy change requests. This means that those moderators need to
approve the specific policy change. Typically, moderators are used
to policies, approve member additions members, and removals. However,
so on. This section is meant as an overview of the major
conferencing operations, summarizing how they operate. More detailed
examples of the framework
allows for moderators to be associated with any policy change that SIP mechanisms can be made.

Moderating a policy request is done using a combination found in [7].

As well as providing an overview of the
conference notification service and common conferencing
operations, each of the CPCP protocol.

First, subsections in this section of the document
provides a client makes description of the SIP mechanism for supporting the
operation. Non-SIP mechansims are discussed in the XCON framework
document [16].

5.1 Creating Conferences

There are many ways in which a policy change. This conference can be directly, using
the CPCP, or indirectly. An indirect policy change request is any
non-CPCP action that requires approval. created. The simplest example is an
INVITE to the focus from a new participant. That represents
creation of a
request to change conference actually constructs several elements all at
the membership of same time. It results in the conference. From creation of a
moderation perspective, it is handled identically to focus and a
conference policy. It also results in the case where construction of a
client used
conference URI, which uniquely identifies the CPCP to request that focus. Since the same user
conference URI needs to be added to the
conference.

Part of unique, the conference policy itself may designate any policy change
as moderated. This means element which creates
conferences is responsible for guaranteeing that they change cannot uniqueness. This
can be performed accomplished deterministically, by the
client directly. As a result, the CPCP request will be answered keeping records of
conference URIs, or by generating URIs algorithmically, or
probabilistically, by creating random URI with sufficiently low
probabilities of collision.

When a response saying media and conference policy are created, they are established
with default rules that are implementation dependent. If the action will be done pending authorization.
That completes the CPCP transaction. In the case creator
of the conference wishes to change those rules, they would do so
using a policy change
requested indirectly through some other means, the behavior depends
on the non-SIP mechanism. For example, if a user sends a

SIP INVITE request can be used to the conference create conferences hosted in order a central server by
sending an INVITE to join, and a conferencing application that join request is
moderated, the focus would normally accept it and play music-on-hold
until the request is approved.

Even though the CPCP transaction failed, it does result in a change
in internal state. Specifically, the requested change shows up as
automatically create a
"pending" state within the media and new conference policies. This means
that the change has been requested, but has not taken effect. It is
almost and then place a form user into it.

Creation of change request history. However, because it is a
state change, it is something that can result in notifications
through conferences where the conference notification service.

Therefore, focus resides in order to moderate requests, an endpoint
operates differently. There, the moderator subscribes to endpoint itself creates the
conference policy notification service. Normally, the

Rosenberg Expires December 28, 2004 [Page 22]

Internet-Draft Conferencing Framework June 2004

notifications from the focus do not reflect pending state changes.
That is, the service will not normally send a notification informing
a subscriber that a policy change request was made URI, and failed due hands it out to
lack of authorization. However, notifications other endpoints which are to be
the moderator do
reflect these changes. That participants. What differs from case to case is because the policy of how the focus is endpoint
decides to
inform moderators, and only moderators, of these changes. Indeed,
different users can be moderators for different parts of the
conference and media policies. For example, one user can be a
moderator for membership changes, and another, create a moderator for
whether users can be anonymously joined or not.

There are two ways that conference.

One important case is the focus knows whether a subscriber ad-hoc conference described in Section 6.2.
There, an endpoint unilaterally decides to create the conference notification service is a moderator.
based on local policy. The first is
configured policy (once again through CPCP). That policy can specify dialogs that a particular user is were connected to the moderator for UA are
migrated to the endpoint-hosted focus, using a particular piece of
policy. Therefore, if that user subscribes re-INVITE to pass the
conference
notification service, any notification sent URI to that user will include
pending changes the newly joined participants.

Rosenberg Expires April 18, 2005 [Page 15]

Internet-Draft Conferencing Framework October 2004

Alternatively, one UA can ask another UA to that piece of policy. As create an alternative, a
SUBSCRIBE request from a user can include a filter [14] that requests
receipt of these pending state changes. If the conference policy
allows, that request endpoint-hosted
conference. This is honored, and the subscriber will receive
notifications about pending state changes.

Once accomplished with the moderator SIP Join header [10]. The
UA which receives a notification about the pending state
change, they use the CPCP to implement their decision. If the
moderator decides Join header in an invitation may need to approve the change, they use create
a new conference URI (a new one is not needed if the CPCP or MPCP dialog that is
being joined is already part of a conference). The conference URI is
then handed to
actually perform the change themselves. Since the moderator recently joined participants through a re-INVITE.

5.2 Adding Participants

There are many mechanisms for adding participants to a
piece of policy is allowed conference.
In all cases, participant additions can be first party (a user adds
themself) or third party (a user adds another user).

First person additions using SIP are trivially accomplished with a
standard INVITE. A participant can send an INVITE request to change that piece of policy, by
definition, their change is accepted the
conference URI, and performed. If if the moderator
decides conference policy allows them to reject the change, join,
they use the CPCP are added to remove the pending
state from the database.

The pending state persists in conference.

If a UA does not know the database for conference URI, but has learned about a period of time
dialog which
is, itself, part of the is connected to a conference policy. If (by using the moderator does not
either approve or reject dialog event
package, for example [11]), the change, UA can join the pending state eventually
disappears, as if conference by using
the change was explicitly rejected.

If Join header to join the pending state is approved, dialog.

Third party additions with SIP are done using REFER [12]. The client
can send a real change REFER request to the conference or
media policy takes place, and this change will be reflected in participant, asking them to send an
INVITE request to the conference notification service. In this way, if a URI. Additionally, the client makes can
send a
policy change, and their REFER request is rejected because they are not
authorized, to the client can subscribe focus, asking it to send an INVITE to the conference notification
service
participant. The latter technique has the benefit of allowing a
client to learn if their change is eventually approved add a conference-unaware participant that does not support
the REFER method.

5.3 Removing Participants

As with additions, there are several mechanisms for departures.
Removals can also be first person or rejected. third person.

First person departures are trivially accomplished by sending a BYE
request to the focus. This general mechanism for moderating policy requests is consistent terminates the dialog with the moderation of presence subscriptions [15][16].

Rosenberg Expires December 28, 2004 [Page 23]

Internet-Draft Conferencing Framework June 2004

5.6 focus and
removes the participant from the conference.

Third person departures can also be done using SIP, through the REFER
method.

5.4 Creating Sidebars

A sidebar is a "conference within a conference", allowing a subset of
the participants to converse amongst themselves. Frequently,
participants in a sidebar will still receive media from the main

Rosenberg Expires April 18, 2005 [Page 16]

Internet-Draft Conferencing Framework October 2004

conference, but "in the background". For audio, this may mean that
the volume of the media is reduced, for example.

A sidebar is represented by a separate conference URI. This URI is a
type of "alias" for the main conference URI. Both route to the same
focus. Like any other conference, the sidebar conference URI has a
conference policy and a media policy associated with it. Like any
other conference, one can join it by sending an INVITE to this URI,
or ask others to join by referring them to it. However, it differs
from a normal conference URI in several ways. First, users in the
main conference do not need to establish a separate dialog to the
sidebar conference. The focus recognizes the sidebar as a special
URI, and knows to use the existing dialog to the main conference as a
"virtual" connection to the sidebar URI.

The second difference is the way in which conference and media
policies are implemented. If the conference policy control protocol
is used to add a user to a normal conference, the focus will
typically send an INVITE to the participant to ask them to join. For
a sidebar conference, it is done differently. If the conference
policy control protocol is used to add a user to it, and that user is
already part of the main conference, the focus will use the
conference notification service to alert the existing participant
that they have been asked to join the sidebar. The invited user can
then make use of the CPCP to formally add themselves to a
type of "alias" for the sidebar.

5.7 main conference URI.

5.5 Destroying Conferences

Conferences can be destroyed in several ways. Generally, whether
those means are applicable for any particular conference is a
component of the conference policy.

When a conference is destroyed, the conference and media policies
associated with it are destroyed. Any attempts to read or write
those policies results in a protocol error. Furthermore, the
conference URI becomes invalid. Any attempts to send an INVITE to
it, or SUBSCRIBE to it, would result in a SIP error response.

Typically, if a conference is destroyed while there are still
participants, the focus would send a BYE to those participants before
actually destroying the conference. Similarly, if there were any
users subscribed to the conference notification service, those
subscriptions would be terminated by the server before the actual

Rosenberg Expires December 28, 2004 [Page 24]

Internet-Draft Conferencing Framework June 2004
destruction.

5.7.1 SIP Mechanisms

There is no explicit means in SIP to destroy a conference. However,
a conference may be destroyed as a by-product of a user leaving the
conference, which can be done with BYE. In particular, if the
conference policy states that the conference is destroyed once the
last user leaves, when that user does leave (using a SIP BYE
request), the conference is destroyed.

5.7.2 CPCP Mechanisms

The CPCP contains mechanisms for explicitly destroying a conference.

5.7.3 Non-Automated Mechanisms

As with conference creation, a conference can be destroyed by
interacting with a web application or voice application that prompts
the user for the conference to be destroyed.

5.8

5.6 Obtaining Membership Information

A participant in a conference will frequently wish to know the set of
other users in the conference. This information can be obtained many
ways.

5.8.1 SIP Mechanisms

The conference notification service allows a conference aware
participant to subscribe to it, and receive notifications that
contain the list of participants. When a new participant joins or
leaves, subscribers are notified. The conference notification
service also allows a user to do a "fetch" [4] to obtain the current
listing.

5.8.2 CPCP Mechanisms

The CPCP contains mechanisms for querying for the current set of
conference participants.

5.8.3 Non-Automated Mechanisms

Users can also interact with applications to obtain conference
membership. There may be a conference web page associated with the
conference, which has a link that will fetch the current list of
participants and display them in the browser. Similarly, an
interactive voice response application connected to the focus can be

Rosenberg Expires December 28, 2004 [Page 25]

Internet-Draft Conferencing Framework June 2004

used to obtain the current membership. A user in the conference
could press the pound key on their phone, and hear a listing of the
current participants.

5.9

5.7 Adding and Removing Media

Each conference is composed of a particular set of media that the

Rosenberg Expires April 18, 2005 [Page 17]

Internet-Draft Conferencing Framework October 2004

focus is managing. For example, a conference might contain a video
stream and an audio stream. The set of media streams that constitute
the conference can be changed by participants. When the set of media
in the conference change, the focus will need to generate a re-INVITE
to each participant in order to add or remove the media stream to
each participant. When a media stream is being added, a participant
can reject the offered media stream, in which case it will not
receive or contribute to that stream. Rejection of a stream by a
participant does not imply that that the stream is no longer part of
the conference - just that the participant is not involved in it.

There are several ways in which a media stream can be added or
removed from a conference.

5.9.1 SIP Mechanisms

A SIP re-INVITE can be used by a participant to add or remove a media
stream. This is accomplished using the standard offer/answer
techniques for adding media streams to a session [17]. This will
trigger the focus to generate its own re-INVITEs.

5.9.2 CPCP Mechanisms

The CPCP can be used to add or remove a media stream. This too will
trigger the focus to generate a re-INVITE to each participant in
order to affect the change.

5.9.3 Non-Automated Mechanisms

As with most of the other common functions, addition and removal of
media streams can be accomplished with a web application or
interactive voice application.

5.10 media streams to a session [14]. This will
trigger the focus to generate its own re-INVITEs.

5.8 Conference Announcements and Recordings

Conference announcements and recordings play a key role in many real
conferencing systems. Examples of such features include:
o Asking a user to state their name before joining the conference,
in order to support a roll call
o Allowing a user to request a roll call, so they can hear who else
is in the conference

Rosenberg Expires December 28, 2004 [Page 26]

Internet-Draft Conferencing Framework June 2004
o Allowing a user to press some keys on their keypad in order to
record the conference
o Allowing a user to press some keys on their keypad in order to be
connected with a human operator
o Allowing a user to press some keys on their keypad to mute or
unmute their line

Rosenberg Expires April 18, 2005 [Page 18]

Internet-Draft Conferencing Framework October 2004

User 1
+-----------+
| |
| |
|Participant|
| 1 |
| |
+-----------+
|SIP
|Dialog
Conference |1
Policy +---|--------+
User 2 Server | | | Application
+-----------+ +-----------+ | CPCP non-SIP *************
| | | | |-------- * *
| | | | | * *
|Participant|-----------| Focus |------------*Participant*
| 2 | SIP | | | SIP * 4 *
| | Dialog | |--+ Dialog * *
+-----------+ 2 +-----------+ 4 *************
|
|
|SIP
|Dialog
|3
|
+-----------+
| |
| |
|Participant|
| 3 |
| |
+-----------+
User 3

Figure 4 3

In this framework, these capabilities are modeled as an application
which acts as a participant in the conference. This is shown

Rosenberg Expires December 28, 2004 [Page 27]

Internet-Draft Conferencing Framework June 2004
pictorially in Figure 4. 3. The conference has four participants.
Three of these participants are end users, and the fourth is the
announcement application.

If the announcement application wishes to play an announcement to all
the conference members (for example, to announce a join), it merely
sends media to the mixer as would any other participant. The
announcement is mixed in with the conversation and played to the
participants.

Rosenberg Expires April 18, 2005 [Page 19]

Internet-Draft Conferencing Framework October 2004

Similarly, the announcement application can play an announcement to a
specific user by using the CPCP to configure configuring its media policy so that the media it
generates is only heard by the target user. The application then
generates the desired announcement, and it will be heard only by the
selected recipient.

The announcement application can also receive input from a specific
user through the conference. The announcement application would use
the CPCP to cause in-band DTMF to be dropped from the mix, and sent
only to itself. When a user wishes to invoke an operation, such as
to obtain a roll call, the user would press the appropriate key
sequence. That sequence would be heard only by the announcement
application. Once the application determines that the user wishes to
hear a roll call, To do this, it can use the CPCP to set the media policy so that
media from that user is delivered only to the announcement
application. This "disconnects" the user from the rest of the
conference so they can interact with the application. Once the
interaction is done, and announcement application uses the CPCP
interaction framework [6]. This allows it to
"reconnect" the collect user to the conference.

5.11 input,
possibly through keypad stimulus, and take actions.

5.9 Floor Control

Floor control is similar to a conference announcement application.
Within the context of this framework, floor control is would be managed
by an application
(possibly application, possibly one that is not a participant) participant, that uses the CPCP would
use a non-SIP protocol to enforce the resulting floor control
decisions.

[[Need more work here]]

5.12 Camera and Video Controls
OPEN ISSUE: Originally, I was just going to say that this is
outside the scope of conferencing. But, it does impact
conferencing. Effectively, camera control is treated like a media
stream. The mixer would combine the various requests across
participants and direct them to the appropriate device. How does
that work though? In a video conference with 4 participants, the
camera Further detail on floor control needs to identify the specific user whose camera is
to be controlled. That is something unique to conferencing. provided in the XCON
framework document [16].

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 28] 20]

Internet-Draft Conferencing Framework June October 2004

6. Physical Realization

In this section, we present several physical instantiations of these
components, to show how these basic functions can be combined to
solve a variety of problems.

6.1 Centralized Server

In the most simplistic realization of this framework, there is a
single physical server in the network which implements the focus, the
conference policy server, and the mixers. This is the classic "one
box" solution, shown in Figure 5. 4.

Figure 5 4

6.2 Endpoint Server

Another important model is that of a locally-mixed ad-hoc conference.
In this scenario, two users (A and B) are in a regular point-to-point
call. One of the participants (A) decides to conference in a third
participant, C. To do this, A begins acting as a focus. Its

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 29] 21]

Internet-Draft Conferencing Framework June October 2004

existing dialog with B becomes the first dialog attached to the
focus. A would re-INVITE B on that dialog, changing its Contact URI
to a new value which identifies the focus. In essence, A "mutates"
from a single-user UA to a focus plus a single user UA, and in the
process of such a mutation, its URI changes. Then, the focus makes
an outbound INVITE to C. When C accepts, it mixes the media from B
and C together, redistributing the results. The mixed media is also
played locally. Figure 6 5 shows a diagram of this transition.

B B
+------+ +------+
| | | |
| UA | | UA |
| | | |
+------+ +------+
| . | .
| . | .
| . | .
| . Transition | .
| . ------------> | .
SIP| .RTP SIP| .RTP
| . | .
| . | .
| . | .
| . | .
| . +----------+
+------+ | +------+ | SIP +------+
| | | |Focus | |----------| |
| UA | | |C.Pol.| | | UA |
| | | |Mixers| |..........| |
+------+ | | | | RTP +------+
| +------+ |
A | + | C
| + <..|.......
| + | .
| +------+ | .
| |Parti-| | .
| |cipant| | .
| | | | .
| +------+ | .
+----------+ .
A .
.

Internal
Interface

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 30] 22]

Internet-Draft Conferencing Framework June October 2004

Figure 6 5

It is important to note that the external interfaces in this model,
between A and B, and between B and C, are exactly the same to those
that would be used in a centralized server model. B could also
include a conference policy server and conference notification
service, allowing the participants to have access to them if they so
desired. Just because the focus is co-resident with a participant
does not mean any aspect of the behaviors and external interfaces
will change.

6.3 Media Server Component

+------------+ +------------+
| App Server| SIP |Conf. Cmpnt.|
| |-------------| |
| Focus | Conf. Proto | Focus |
| C.Pol |-------------| C.Pol |
| | Media Proto | Mixers |
|Notification|-------------| |
| | | |
+------------+ +------------+
| \ .. .
| \\ RTP... .
| \\ .. .
| SIP \\ ... .
SIP | \\ ... .RTP
| ..\ .
| ... \\ .
| ... \\ .
| .. \\ .
| ... \\ .
| .. \ .
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+

Figure 7 6

In this model, shown in Figure 7, 6, each conference involves two
centralized servers. One of these servers, referred to as the
"application server" owns and manages the membership and media
policies, and maintains a dialog with each participant. As a result,
it represents the focus seen by all participants in a conference.
However, this server doesn't provide any media support. To perform
the actual media mixing function, it makes use of a second server,
called the "mixing server". This server includes a focus, and a

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 31] 23]

Internet-Draft Conferencing Framework June October 2004

conference policy server, but has no conference notification service.
It has a default membership policy, which accepts all invitations
from the top-level focus. Its conference policy server accepts any
controls made by the application server. The focus in the
application server uses third party call control to connect the media
streams of each user to the mixing server, as needed. If the focus
in the application server receives a conference policy control
command from a client, it delegates that to the media server by
making the same media policy control command to it.

This model allows for the mixing server to be used as a resource for
a variety of different conferencing applications. This is because it
is unaware of any conference or media policies; it is merely a
"slave" to the top-level server, doing whatever it asks.

6.4 Distributed Mixing

In a distributed mixed conference, there is still a centralized
server which implements the focus, conference policy server, and
media policy server. However, there are no centralized mixers.
Rather, there are mixers in each endpoint, along with a conference
policy server. The focus distributes the media by using third party
call control [18] [15] to move a media stream between each participant and
each other participant. As a result, if there are N participants in
the conference, there will be a single dialog between each
participant and the focus, but the session description associated
with that dialog will be constructed to allow media to be distributed
amongst the participants. This is shown in Figure 8. 7.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 32] 24]

Internet-Draft Conferencing Framework June October 2004

+---------+
|Partcpnt |
media | | media
...............| |..................
. | Mixers | .
. |C.Pol.Srv| .
. +---------+ .
. | .
. | .
. | .
. dialog | .
. | .
. | .
. | .
. +---------+ .
. |Cnf.Srvr.| .
. | | .
. | Focus | .
. |C.Pol.Srv| .
. / | | \ .
. / +---------+ \ .
. / \ .
. / \ .
. / dialog \ .
. / \ .
. /dialog \ .
. / \ .
. / \ .
. / \ .
. .
+---------+ +---------+
|Partcpnt | |Partcpnt |
| | | |
| | ......................... | |
| Mixers | | Mixers |
|C.Pol.Srv| media |C.Pol.Srv|
+---------+ +---------+

Figure 8 7

There are several ways in which the media can be distributed to each
participant for mixing. In a multi-unicast model, each participant
sends a copy of its media to each other participant. In this case,
the session description manages N-1 media streams. In a multicast
model, each participant joins a common multicast group, and each
participant sends a single copy of its media stream to that group.
The underlying multicast infrastructure then distributes the media,
so that each participant gets a copy. In a single-source multicast

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 33] 25]

Internet-Draft Conferencing Framework June October 2004

model (SSM), each participant sends its media stream to a central
point, using unicast. The central point then redistributes the media
to all participants using multicast. The focus is responsible for
selecting the modality of media distribution, and for handling any
hybrids that would be necessitated from clients with mixed
capabilities.

When a new participant joins or is added, the focus will perform the
necessary third party call control to distribute the media from the
new participant to all the other participants, and vice-a-versa.

The central conference server also includes a conference policy
server. Of course, the central conference server cannot implement
any of the media policies directly. Rather, it would delegate the
implementation to the conference policy servers co-resident with a
participant. As an example, if a participant decides to switch the
overall conference mode from "voice activated" to "continuous
presence", they would communicate with the central conference policy
server. The conference policy server, in turn, would communicate
with the conference policy servers co-resident with each participant,
using the same conference policy control protocol, and instruct them
to use "continuous presence".

This model requires additional functionality in user agents, which
may or may not be present. The participants, therefore, must be able
to advertise this capability to the focus.

6.5 Cascaded Mixers

In very large conferences, it may not be possible to have a single
mixer that can handle all of the media. A solution to this is to use
cascaded mixers. In this architecture, there is a centralized focus,
but the mixing function is implemented by a multiplicity of mixers,
scattered throughout the network. Each participant is connected to
one, and only one of the mixers. The focus uses some kind of control
protocol to connect the mixers together, so that all of the
participants can hear each other.

+---------+
+-----------------------| |------------------------+
| ++++++++++++++++++++| |++++++++++++++++++ |
| + +------| Focus |---------+ + |
| + | | | | + |
| + | +-| |--+ | + |
| + | | +---------+ | | + |
| + | | + | | + |

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 34] 26]

Internet-Draft Conferencing Framework June October 2004

| + | | + | | + |
| + | | + | | + |
| + | | +---------+ | | + |
| + | | | | | | + |
| + | | | Mixer 2 | | | + |
| + | | | | | | + |
| + | | +---------+ | | + |
| + | |... . .... | | + |
| + .|....| . .|.... | + |
| + ...... | | . | ..|... + |
| + ... | | . | | ....+ |
| +---------+ | | +---------+ | | +---------+ |
| | | | | | | | | | | |
| | Mixer 2 | | | | Mixer 3 | | | | Mixer 4 | |
| | | | | | | | | | | |
| +---------+ | | +---------+ | | +---------+ |
| . . | | . . | | . . |
| . . | | .. . | | .. . |
| . . | | . . | | . . |
+---------+ . | +---------+ . | +---------+ . |
| Prtcpnt | . | | Prtcpnt | . | | Prtcpnt | . |
| 1 | . | | 1 | . | | 1 | . |
+---------+ . | +---------+ . | +---------+ . |
. | . | . |
+---------+ +---------+ +---------+
| Prtcpnt | | Prtcpnt | | Prtcpnt |
| 1 | | 1 | | 1 |
+---------+ +---------+ +---------+

------- SIP Dialog
....... Media Flow
+++++++ Control Protocol

Figure 9 8

This architecture is shown in Figure 9. 8.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 35] 27]

Internet-Draft Conferencing Framework June October 2004

7. Security Considerations

Conferences frequently require security features in order to properly
operate. The conference policy may dictate that only certain
participants can join, or that certain participants can create new
policies. Generally speaking, conference applications are very
concerned about authorization decisions. Mechanisms for establishing
and enforcing such authorization rules is a central concept
throughout this document.

Of course, authorization rules require authentication. Normal SIP
authentication mechanisms should suffice for the conference
authorization mechanisms described here.

Privacy is an important aspect of conferencing. Users may wish to
join a conference without anyone knowing that they have joined, in
order to silently listen in. In other applications, a participant
may wish just to hide their identity from other participants, but
otherwise let them know of their presence. These functions need to
be provided by the conferencing system.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 36] 28]

Internet-Draft Conferencing Framework June October 2004

8. Contributors

This document is the result of discussions amongst the conferencing
design team. The members of this team include:

Alan Johnston
Brian Rosen
Rohan Mahy
Henning Schulzrinne
Orit Levin
Roni Even
Tom Taylor
Petri Koskelainen
Nermeen Ismail
Andy Zmolek
Joerg Ott
Dan Petrie

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 37] 29]

Internet-Draft Conferencing Framework June October 2004

9. Acknowledgements

The authors would like to thank Mary Barnes and Chris Boulton for
their comments. Thanks to Allison Mankin for her comments and
support of this work.

Rosenberg Expires April 18, 2005 [Page 30]

Internet-Draft Conferencing Framework October 2004

10. Changes from draft-ietf-sipping-conferencing-framework-02

Removed detailed discussions on policy servers, CPCP operations,
sidebars, and approval of policy changes. These now reside in the
XCON framework draft, which is referenced from here now.

Rosenberg Expires April 18, 2005 [Page 31]

Internet-Draft Conferencing Framework October 2004

11. Changes from draft-ietf-sipping-conferencing-framework-00

Updated references and formatting cleanup.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 38] 32]

Internet-Draft Conferencing Framework June October 2004

10.

12. Changes since draft-rosenberg-sipping-conferencing-framework-01
o Clarified that the conference notification service uses a single
package with some kind of filtering to select whether you get the
focus or policy state.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 39] 33]

Internet-Draft Conferencing Framework June October 2004

11.

13. Changes since draft-rosenberg-sipping-conferencing-framework-00
o Rework of terminology.
o More details on moderating policy changes.
o Rework of the overview, and in particular, a shift of focus from
basic/complex conferences (a term which has been removed) to
conference aware/unaware participants.
o Removal of explicit reference to megaco for controlling a mixer.
o Discussion of a lot more conferencing operations.
o New sidebar mechanism.

14 Informative References

[1] 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.

[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.

[3] Levin, O., "Requirements O. and R. Even, "High Level Requirements for Tightly
Coupled SIP Conferencing",
draft-levin-sipping-conferencing-requirements-01
draft-ietf-sipping-conferencing-requirements-01 (work in
progress), July 2002. October 2004.

[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.

[5] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-06
draft-ietf-simple-message-sessions-08 (work in progress), May
August 2004.

[6] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)",
draft-ietf-sipping-app-interaction-framework-01
draft-ietf-sipping-app-interaction-framework-02 (work in
progress), February July 2004.

[7] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-03
draft-ietf-sipping-cc-conferencing-04 (work in progress),
February July
2004.

[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.

[9] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-03 (work in progress), January 2004.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 40] 34]

Internet-Draft Conferencing Framework June October 2004

RFC 3840, August 2004.

[10] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP)
'Join' Header", draft-ietf-sip-join-03 (work in progress),
February 2004.

[11] 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.

[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.

[13] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.

[14] Khartabil, H., Leppanen, E. and T. Moran, "Requirements for
Presence Specific Event Notification Filtering",
draft-ietf-simple-pres-filter-reqs-03 (work in progress),
January 2004.

[15] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.

[16] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)",
draft-ietf-simple-winfo-package-05 (work in progress), January
2003.

[17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.

[18]

[15] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol", draft-ietf-sipping-3pcc-06 Protocol (SIP)", BCP 85, RFC 3725, April
2004.

[16] Barnes, M. and C. Boulton, "A Framework for Centralized
Conferencing", draft-barnes-xcon-framework-00.txt (work in
progress), January September 2004.

Rosenberg Expires December 28, 2004 [Page 41]

Internet-Draft Conferencing Framework June 2004

Author's Address

Jonathan Rosenberg
dynamicsoft
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US

Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 42] 35]

Internet-Draft Conferencing Framework June October 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 (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.

Rosenberg Expires December 28, 2004 April 18, 2005 [Page 43] 36]

----