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 3 GPP 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 conferen ce 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 a llows 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. . 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. 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. 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