Request for Comments: 4353 Cisco Systems
Category: Informational February 2006
A Framework for Conferencing with the
Session Initiation Protocol (SIP)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 multi-
party conferencing.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview of Conferencing Architecture ...........................6
3.1. Usage of URIs ..............................................9
4. Functions of the Elements ......................................10
4.1. Focus .....................................................10
4.2. Conference Policy Server ..................................11
4.3. Mixers ....................................................11
4.4. Conference Notification Service ...........................12
4.5. Participants ..............................................13
4.6. Conference Policy .........................................13
5. Common Operations ..............................................13
5.1. Creating Conferences ......................................13
5.2. Adding Participants .......................................14
5.3. Removing Participants .....................................15
5.4. Destroying Conferences ....................................15
5.5. Obtaining Membership Information ..........................16
5.6. Adding and Removing Media .................................16
5.7. Conference Announcements and Recordings ...................16
6. Physical Realization ...........................................18
6.1. Centralized Server ........................................18
6.2. Endpoint Server ...........................................19
6.3. Media Server Component ....................................21
6.4. Distributed Mixing ........................................22
6.5. Cascaded Mixers ...........................................24
7. Security Considerations ........................................26
8. Contributors ...................................................26
9. Acknowledgements ...............................................26
10. Informative References ........................................27
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 the other participants, 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 presents the overall framework for tightly coupled SIP
conferencing, referred to simply as "conferencing" from this point
forward. This framework presents a general architectural model for
these conferences and presents terminology used to discuss such
conferences. It also discusses the ways in which SIP itself is
involved in conferencing. The aim of the framework is to meet the
general requirements for conferencing that are outlined in [3]. This
specification alludes to non-SIP-specific mechanisms for achieving
several conferencing functions. Those mechanisms are outside the
scope of this specification.
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, that 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 implement non-SIP-specific mechanisms for additional
functionality.
Conference State: The state of the conference includes the state of
the focus, the set of participants connected to the conference,
and the state of their respective dialogs.
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.
Conference Policy Server: A conference policy server is a logical
function that can store and manipulate the conference policy.
This logical function is not specific to SIP, and may not
physically exist. It refers to the component that interfaces a
protocol to the conference policy.
Conference Policy: The complete set of rules governing a particular
conference.
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 [2]. As a result, the term defined here is a superset of the
mixer concept defined in RFC 3550, 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 that are linked
such that the user agent that 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. A conference-aware participant
can use the conference notification service or additional non-
SIP-specific mechanisms for additional functionality.
Conference Server: A conference server is a physical server that
contains, at a minimum, the focus. It may also include a
conference policy server and mixers.
Mass Invitation: An attempt to add a large number of users into a
conference.
Mass Ejection: An attempt to remove a large number of users from a
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.
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, as
shown in Figure 1.
The focus is responsible for making sure that the media streams that
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
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, an instance of which
exists for each conference. Effectively, the conference policy can
be thought of as a database that 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 those changes that affect the
conference state will require a notification to be sent to
subscribers using the conference notification service.
The conference is represented by a URI that 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 the focus and the user is brought into the conference.
Users can leave the conference by sending a BYE, as they would in a
normal call.
Similarly, the focus can terminate a dialog with 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 to bring a participant into the conference.
The notion 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, the UA appears like any other UA. The focus, of
course, knows that it’s a focus, and it performs the tasks needed for
the conference to operate.
Conference-unaware participants have access to a 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 participant wishes to explicitly
control aspects of the conference using functional signaling
protocols, the participant must be conference-aware.
.....................................
. .
. .
. .
. .
. .
. .
. .
. +-----------+ //-----\\ .
. | | || || .
non-SIP . | Conference| \\-----// .
+---------------->| Policy | | | .
| . | Server |----> | | .
| . | | |Conference| .
| . +-----------+ | Policy | .
| . | | .
| . | | .
+-----------+ . +-----------+ | | .
| | . | | \ // .
| | . | | \-----/ .
|Participant|<--------->| Focus | | .
| | SIP . | | | .
| | Dialog . | |<-----------+ .
+-----------+ . |...........| .
^ . | Conference| .
| . |Notification .
+------------>| Service | .
Subscription. +-----------+ .
. .
. .
. .
. .
.....................................
Conference
Functions
Figure 2
A conference-aware participant is one that has access to advanced
functionality through additional protocol interfaces, which may
include access to the conference policy through non-SIP-specific
mechanisms. A model for this interaction is shown in Figure 2. The
participant can interact with the focus using extensions, such as
REFER, in order to access enhanced call control functions [7]. The
participant can SUBSCRIBE to the conference URI, and be connected to
the conference notification service provided by the focus. Through
this mechanism, it can learn about changes in participants -
effectively, the state of the dialogs and the media.
The participant can communicate with the conference policy server
using some kind of non-SIP-specific mechanism by which it can affect
the conference policy. The conference policy server need not be
available in any particular conference, although there is always a
conference policy.
The interfaces between the focus and the conference policy, and
between the conference policy server and the conference policy are
non-SIP-specific. For the purposes of SIP-based conferencing, they
serve as logical roles involved in a conference, as opposed to
representing a physical decomposition. The separation of these
functions is documented here to encourage clarity in the
requirements. This approach provides individual SIP implementations
the flexibility to compose a conferencing system in a scalable and
robust manner without requiring the complete development of these
interfaces.
3.1. Usage of URIs