................//.\.....***.......
// \ *** *
// *** * RTP
SIP // *** \ *
// *** \SIP *
// *** RTP \ *
/ ** \ *
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
Figure 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
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 that 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 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
Figure 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. User A could also
implement a conference policy and a 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 | non-SIP | Focus |
| C.Pol |-------------| C.Pol |
| | | Mixers |
|Notification| | |
| | | |
+------------+ +------------+
| \ .. .
| \\ RTP... .
| \\ .. .
| SIP \\ ... .
SIP | \\ ... .RTP
| ..\ .
| ... \\ .
| ... \\ .
| .. \\ .
| ... \\ .
| .. \ .
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
Figure 6
In this model, shown in Figure 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
implements a conference policy, but has no conference notification
service. Its conference policy tells it to accept all invitations
from the top-level focus. 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 conference policy; 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 that 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 [14] 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 7.
+---------+
|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 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
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 versa.
The central conference server also exposes an interface to the
conference policy. Of course, the central conference server cannot
implement any of the media operations or policies directly. Rather,
it would delegate the implementation to each 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 that are co-resident with each participant,
using some non-SIP-specific mechanism, 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.
This architecture is shown in Figure 8.
+---------+
+-----------------------| |------------------------+
| ++++++++++++++++++++| |++++++++++++++++++ |
| + +------| Focus |---------+ + |
| + | | | | + |
| + | +-| |--+ | + |
| + | | +---------+ | | + |
| + | | + | | + |
| + | | + | | + |
| + | | + | | + |
| + | | +---------+ | | + |
| + | | | | | | + |
| + | | | Mixer 2 | | | + |
| + | | | | | | + |
| + | | +---------+ | | + |
| + | |... . .... | | + |
| + .|....| . .|.... | + |
| + ...... | | . | ..|... + |
| + ... | | . | | ....+ |