Chapter 24 - Conferencing in the IMS pptx

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

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

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

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