Chapter 24
Conferencing in the IMS
In Chapter 23, we introduced the basic technologies and architectures developed by the IETF
in the conferencing area. In this chapter, we discuss how those technologies are used in
the IMS to provide a conferencing service. This chapter is fairly brief because applying the
technologies described in Chapter 23 to the IMS architecture is relatively straight-forward.
24.1 The IMS Conferencing Service
The IMS conferencing service (specified in 3GPP TS 24.147 [32]) is based on the SIPPING
conferencing framework (specified in RFC 4353 [272]). Of the specifications produced
within the XCON working group, the IMS conferencing service only uses BFCP (specified
in RFC 4582 [106]). In the future, as the work in the XCON working group progresses, the
IMS conferencing service may use the XCON framework and the conference control protocol
developed by the XCON working group. However, at present, they are not yet used in the
context of this IMS service.
The IMS conferencing services is based on the tightly-coupled conference model
described in Figure 23.3. In the IMS, the conference server is distributed into two logical
entities: one handling signaling and the other handling media, as shown in Figure 24.1. The
former corresponds to a combination of an AS and an MRFC; the latter corresponds to an
MRFP.
PSTN interworking is also part of the IMS conferencing service. Users on the PSTN can
participate in IMS conferences through an MGCF, which acts as a conference participant and
talks SIP to the AS/MRFC part of the conference server.
24.1.1 Creating and Joining a Conference
A client creates a conference at a server by sending an INVITE request (1) to the server’s
conference factory URI (defined in RFC 4579 [195]), as shown in Figure 24.2. The server
responds with a 200 (OK) response (2) that carries the new conference URI in its Contact
header field. Users joining the conference send INVITE requests (4) to this conference URI.
Therefore, the conference factory URI is only used at conference creation in order to obtain
a conference URI, which is allocated by the conference server. Once a conference is created,
it is identified by its conference URI.
´ıa- M ar t´ın
The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition
Gonzalo Camarillo and Miguel A. Garc
© 2008 John Wiley & Sons, Ltd. ISBN: 978- 0- 470- 51662- 1
500
CHAPTER 24. CONFERENCING IN THE IMS
Figure 24.1: The IMS conference service architecture
Figure 24.2: Conference creation using a conference factory URI
24.1. THE IMS CONFERENCING SERVICE
501
Figure 24.3: Joining a conference identified by a PSI
In Figure 24.2, Bob joins the conference by sending an INVITE request (4) to the
conference URI. Bob can obtain such a URI in several ways. For example, Alice can send it
to him in an email or tell him on the phone. Alternatively, Alice can send a REFER request
to Bob so that Bob sends an INVITE to the conference URI. Alice can also send a REFER
request to the conference server so that it sends an INVITE to Bob.
Clients can also request the creation of a conference with a particular conference URI.
To do this, a client sends its initial INVITE request to the conference URI it wants to be
allocated for the conference (the host part of the URI needs to route to the conference server).
On receiving such an INVITE request, the conference server checks if its policy allows it to
allocate such a conference URI (e.g., the URI may not be available because it is in use by
another conference) and, if it does, the conference server returns the same conference URI in
the contact header field of a 200 (OK) response.
Conference URIs are PSIs (see Section 3.5.4) and are routed as such. Figure 24.3 shows
an IMS terminal sending and INVITE request to a conference URI that is hosted at a different
502
CHAPTER 24. CONFERENCING IN THE IMS
domain. The I-CSCF of the terminating domain consults the HSS (7) in order to resolve
the PSI (i.e., the conference URI). The HSS provides the I-CSCF (8) with the address of
the AS/MRFC corresponding to the PSI and the I-CSCF relays the INVITE request to that
AS/MRFC (9). Before returning a 183 (Session Progress) response (11), the AS/MRFC
allocates resources at an MRFP.
24.1.2 Other Actions
Conference participants can use the SIP conference event package (specified in RFC
4575 [289]) to obtain information about the conference, as described in Section 23.2.1.
Conferences implementing floor control use BFCP (specified in RFC 4582 [106]).
24.2 Relation with the Work in TISPAN and OMA
The IMS conference service described in this chapter has been specified by 3GPP. In addition,
there is also work by both TISPAN and the OMA in this area.
As will be discussed in Chapter 26, TISPAN has specified the TISPAN simulation
services, which later contributed to 3GPP under the name of Multimedia Telephony Services.
These services are telephony services similar to the PSTN/ISDN supplementary services
but implemented using the IMS infrastructure and its protocols (e.g., SIP). One of these
simulation services is the CONF service, which is discussed in Section 26.4. The CONF
service is specified in ETSI TS 183 005 [135] and 3GPP TS 24.605 [66], which are largely
based on the IMS service described in this chapter (which is mainly based on 3GPP TS
24.147 [32]).
The OMA has also specified services in the conferencing area. The OMA PoC (Push-
to-talk over Cellular) service, which we discuss in Chapter 25, is a conferencing service that
uses a particular floor control policy. OMA SIMPLE IM [242] and CPM (Converged IP
Messaging) [240] mostly focus on messaging-based services.
