It is fundamental to this framework that a conference is uniquely
identified by a URI, and that this URI identifies the focus that is
responsible for the conference. The conference URI is unique, such
that no two conferences have the same conference URI. A conference
URI is always a SIP or SIPS URI.
The conference URI is opaque to any participants that 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 general philosophy of URI usage
[8]. However, contextual information surrounding the URI (for
example, SIP header parameters) may indicate that the URI represents
a conference.
When a SIP request is sent to the conference URI, that request is
routed to the focus, and only to the focus. The element or system
that creates the conference URI is responsible for guaranteeing this
property.
The conference URI can represent a 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
conference for whatever participants are currently joined. Other
conference URIs can represent short-lived conferences, such as an
ad-hoc conference.
Ideally, a conference URI is never constructed or guessed by a user.
Rather, conference URIs are learned through many mechanisms. A
conference URI can be emailed or sent in an instant message. A
conference URI can be linked on a web page. A conference URI can
also be obtained from some non-SIP mechanism.
To determine that a SIP URI does represent 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 the UA is acting as focus in this
dialog. Callee capability parameters are also used to indicate that
a focus supports the conference notification service. This is done
by declaring support for the SUBSCRIBE method and the relevant
package(s) in the caller preferences feature parameters associated
with the conference URI.
Other functions in a conference may be represented by URIs. If the
conference policy is exposed through a web application, it is
identified by an HTTP URI. If it is accessed using an explicit
protocol, it is a URI defined for that protocol.
Starting with the conference URI, the URIs for the other logical
entities in the conference can be learned using the conference
notification service.
4. Functions of the Elements
This section gives a more detailed description of the functions
typically implemented in each of the elements.
4.1. Focus
As its name implies, the focus is the center of the conference. All
participants in the conference are connected to it by a SIP dialog.
The focus is responsible for maintaining the dialogs connected to it.
It ensures that the dialogs are connected to a set of participants
who are allowed to participate in the conference, as defined by the
membership policy. The focus also uses SIP to manipulate the media
sessions, in order to make sure each participant obtains all the
media for the conference. To do that, the focus makes use of mixers.
When a focus receives an INVITE, it checks the conference policy.
The policy might indicate that this participant is not allowed to
join, in which case the call can be rejected. It might indicate that
another participant, acting as a moderator, needs to approve this new
participant. In that case, the INVITE might be parked on a music-
on-hold server, or a 183 response might be sent to indicate progress.
A notification, using the conference notification service, would be
sent to the moderator. The moderator could then allow this new
participant to join, and the focus could then accept the INVITE (or
unpark it from the music-on-hold server). The interpretation of
policy by the focus is, itself, a matter of local policy, and not
subject to standardization.
When it is necessary to remove a SIP participant (with a confirmed
dialog) from a conference, the focus would send a BYE to that
participant to remove the participant. This is often referred to as
"ejecting" a user from the conference, and is called "mass ejection"
when done for many users. Similarly, if it is necessary to add a new
SIP participant to a conference, the focus would send an INVITE
request to that participant. When done for a large number of users,
this is called mass invitation. Finally, if it is necessary to
change the properties of the media of a session (for example to
remove video) for a SIP participant, the focus can update the session
description for that participant by sending a re-INVITE or UPDATE
[15] request with a new offer to that participant.
In many cases, the signaling actions performed by the focus, such as
ejection or addition of a participant, will change the media
composition of the conference. To affect these changes, the focus
interacts with the mixer. Through that interaction, it makes sure
that all valid participants received a copy of the media streams, and
that each participant sends media to an IP address and port on the
mixer that cause it to be appropriately mixed with the other media in
the conference. The means by which the focus interacts with the
mixer are outside the scope of this specification.
4.2. Conference Policy Server
The conference policy server is a logical component of the system.
It represents the interface between clients and the conference policy
that governs the operation of the conference. Clients communicate
with the conference policy server using a non-SIP-specific mechanism.
4.3. Mixers
A mixer is responsible for combining the media streams that make up
the conference, and generating one or more output streams that are
distributed to recipients (which could be participants or other
mixers). The process of combining media is specific to the media
type, and is directed by the focus, under the guidance of the rules
described in the media policy.
A mixer is not aware of a "conference" as an entity, per se. A mixer
receives media streams as inputs, and 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 mixed.
A mixer is always under the control of a focus, either directly or
indirectly. The focus is responsible for interpreting the media
policy, and then installing the appropriate rules in the mixer. If
the focus is directly controlling a mixer, the mixer can either be
co-resident with the focus, or can be controlled through some kind of
protocol. If the focus is indirectly controlling a mixer, it
delegates the mixing to the participants, each of which has its own
mixer. This is described in Section 6.4.
4.4. Conference Notification Service
The focus can provide a conference notification service. In this
role, it acts as a notifier, as defined in RFC 3265 [4]. It accepts
subscriptions from clients for the conference URI, and generates
notifications to them as the state of the conference changes.
The state of the conference includes the participants connected to
the focus, and also information about the dialogs associated with
them. As new participants join, this state changes, and is reported
through the notification service. Similarly, when someone leaves,
this state also changes, allowing subscribers to learn about this
fact.
If a participant is anonymous, the conference notification service
will either withhold the identity of a new participant from other
conference participants, or will neglect to inform other conference
participants about the presence of the anonymous participant. The
choice of approach depends on the level of anonymity provided to the
anonymous participant.
4.5. Participants
A participant in a conference is any SIP user agent that has a dialog
with the focus. This SIP user agent can be a PC application, a SIP
hardphone, or a PSTN gateway. It can also be another focus. A
conference that has a participant that is the focus of another
conference is called a simplex cascaded conference. They can also be
used to provide scalable 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
the focus. The rules can be simple, such as an access list that
defines the set of allowed participants in a conference. The rules
can also be incredibly complex, specifying time-of-day-based rules on
participation, conditional on the presence of other participants. It
is important to understand that there is no restriction on the type
of rules that can be encapsulated in a conference policy.
The conference policy can be manipulated using web applications or
voice applications. It can also be manipulated with non-SIP-specific
standard or proprietary protocols.
5. Common Operations
There are 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].
As well as providing an overview of the common conferencing
operations, each of the subsections in this section of the document
provides a description of the SIP mechanism for supporting the
operation. Non-SIP mechanisms are also possible, but not discussed
here.
5.1. Creating Conferences
There are many ways in which a conference can be created. The
creation of a conference actually constructs several elements all at
the same time. It results in the creation of a focus and a
conference policy. It also results in the construction of a
conference URI, which uniquely identifies the focus. Since the
conference URI needs to be unique, the element that creates
conferences is responsible for guaranteeing that uniqueness. This
can be accomplished deterministically (by keeping records of
conference URIs, or by generating URIs algorithmically), or
probabilistically, (by creating a random URI with sufficiently low
probabilities of collision).
When conference policy is created, it is established with default
rules that are implementation-dependent. If the creator of the
conference wishes to change those rules, they would do so using a
non-SIP mechanism.
SIP can be used to create conferences hosted in a central server by
sending an INVITE to a conferencing application that would
automatically create a new conference and then place a user into it.
Creation of conferences where the focus resides in an endpoint
operates differently. There, the endpoint itself creates the
conference URI, and hands it out to other endpoints that will be the
participants. What differs from case to case is how the endpoint
decides to create a conference.
One important case is the ad-hoc conference described in Section 6.2.
There, an endpoint unilaterally decides to create the conference
based on local policy. The dialogs that were connected to the UA are
migrated to the endpoint-hosted focus, using a re-INVITE or UPDATE to
pass the conference URI to the newly joined participants.
Alternatively, one UA can ask another UA to create an endpoint-hosted
conference. This is accomplished with the SIP Join header [10]. The
UA that 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 is
being joined is already part of a conference). The conference URI is
then handed to the recently joined participants through a re-INVITE
or UPDATE.
5.2. Adding Participants
There are many mechanisms for adding participants to a 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 the
conference URI, and if the conference policy allows them to join,
they are added to the conference.
If a UA does not know the conference URI, but has learned about a
dialog which is connected to a conference (by using the dialog event
package, for example [11]), the UA can join the conference by using
the Join header to join the dialog.
Third party additions with SIP are done using REFER [12]. The client
can send 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 it to send an INVITE to the
participant. The latter technique has the benefit of allowing a
client to 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 third person.
First person departures are trivially accomplished by sending a BYE
request to the focus. This terminates the dialog with the focus and
removes the participant from the conference. The focus can also
remove a participant from the conference by sending it a BYE. In
either case, the focus interacts with the mixer to make sure that the
departed participant ceases receiving conference media, and that
media from that participant are no longer mixed into the conference.
Third person departures can also be done using SIP, through the REFER
method.
5.4. 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 policy associated with
it is destroyed. Any attempts to read or write the policy 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
destruction.
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 or a specific user leaves, when that user does leave (using
a SIP BYE request), the conference is destroyed.
5.5. 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 in
many ways.
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.6. Adding and Removing Media
Each conference is composed of a particular set of media that the
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 the stream is no longer part of the
conference, only that the participant is not involved in it.
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 [13]. This will
trigger the focus to generate its own re-INVITEs.
5.7. 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
o Allowing a user to press some keys on their keypad to record the
conference
o Allowing a user to press some keys on their keypad to be connected
with a human operator
o Allowing a user to press some keys on their keypad to mute or
unmute their line
User 1
+-----------+
| |
| |
|Participant|
| 1 |
| |
+-----------+
|SIP
|Dialog
Conference |1
Policy +---|--------+
User 2 Server | | | Application
+-----------+ +-----------+ | non-SIP *************
| | | | |-------- * *
| | | | | * *
|Participant|-----------| Focus |------------*Participant*
| 2 | SIP | | | SIP * 4 *
| | Dialog | |--+ Dialog * *
+-----------+ 2 +-----------+ 4 *************
|
|
|SIP
|Dialog
|3
|
+-----------+
| |
| |
|Participant|
| 3 |
| |
+-----------+
User 3
Figure 3
In this framework, these capabilities are modeled as an application
that acts as a participant in the conference. This is shown
pictorially in Figure 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.
Similarly, the announcement application can play an announcement to a
specific user by configuring the conference 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. To do this, it can use the application
interaction framework [6]. This allows it to collect user input,
possibly through keypad stimulus, and to take actions.
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 4.
Conference Server
...................................
. .
. +------------+ .
. | Conference | .
. |Notification| .
. | Server | .
. +------------+ .
. +----------+ .
. |Conference| +-----+ .
. | Policy | +-------+ +-----+| .
. | Server | | Focus | |Mixer|+ .
. +----------+ +-------+ +-----+ .