An important requirement for commercial conference bridges is the capabil-
ity to convey with confidence the list of all participating users in the confer-
ence to ensure participants the conference is private, with no undesirable
parties listening in. The list of participants is transmitted by the RTP mixer,
using the RTP capability to transmit the name of all registered participants. In
a multicast conference, the CNAME in the Source Description (SDES) is trans-
mitted to inform about participating users. It is the responsibility of the con-
ference bridge to authenticate all participants (the AAA function) and to
communicate the list on a dynamic basis using RTP. In a centralized confer-
ence, the participant list, or roster is communicated to the participants using
the SIP Conferencing Event package [7]. In addition, the RTP mixer includes
information about the current speakers in the Contributing SSRC (see Chapter
5, “Real-Time Internet Multimedia”) or CSRC field. The SIP conference pack-
age provides a way to map a participant’s URI to the SSRC in the RTP packet.
The conference model number 5 in Table 14.1 is for large multicast confer-
ences, where IP multicast is available. Multicast conferences can scale up to
millions of users and do not really require any SIP signaling. Users can join the
multicast conference by addressing their RTP streams to/from the multicast
addresses belonging to the particular conference. SIP may be used to inform
users of the multicast conference address, though any other means to convey
this information (such as Web pages, e-mail, and the SAP) are just as adequate.
Ad Hoc and Scheduled Conferences
Presence and instant messaging can support the setup of spontaneous confer-
ences, in contrast to the more customary scheduled conferences, as used on the
PSTN. It is of interest to note that SIP enables a continuous transition of con-
ferences from ad hoc to scheduled conferences.
Participants in an ad hoc conference could agree, for example, they need
more time and would like to invite other participants, so they set up a sched-
uled conference to discuss a topic in more depth. The list of the ad hoc confer-
ence participants can be included by the application to set up the scheduled
conference. Call flows for ad hoc conferences and call control operations are
described in [5].
Changing the Nature of a Conference
If users in an ad hoc conference with endpoint mixing (row 1 in Table 14.1)
decide to increase the number of participants, they can move the conference to
a central conference server so as to benefit from a dedicated RTP mixer, as
shown in row 4 of Table 14.1. One of the parties must assume the responsibility
SIP Conferencing 249