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.
Nội dung trích xuất từ tài liệu:
Chapter 24 - Conferencing in the IMS Chapter 24Conferencing in the IMSIn Chapter 23, we introduced the basic technologies and architectures developed by the IETFin the conferencing area. In this chapter, we discuss how those technologies are used inthe IMS to provide a conferencing service. This chapter is fairly brief because applying thetechnologies described in Chapter 23 to the IMS architecture is relatively straight-forward.24.1 The IMS Conferencing ServiceThe IMS conferencing service (specified in 3GPP TS 24.147 [32]) is based on the SIPPINGconferencing framework (specified in RFC 4353 [272]). Of the specifications producedwithin the XCON working group, the IMS conferencing service only uses BFCP (specifiedin RFC 4582 [106]). In the future, as the work in the XCON working group progresses, theIMS conferencing service may use the XCON framework and the conference control protocoldeveloped by the XCON working group. However, at present, they are not yet used in thecontext of this IMS service. The IMS conferencing services is based on the tightly-coupled conference modeldescribed in Figure 23.3. In the IMS, the conference server is distributed into two logicalentities: one handling signaling and the other handling media, as shown in Figure 24.1. Theformer corresponds to a combination of an AS and an MRFC; the latter corresponds to anMRFP. PSTN interworking is also part of the IMS conferencing service. Users on the PSTN canparticipate in IMS conferences through an MGCF, which acts as a conference participant andtalks SIP to the AS/MRFC part of the conference server.24.1.1 Creating and Joining a ConferenceA client creates a conference at a server by sending an INVITE request (1) to the server’sconference factory URI (defined in RFC 4579 [195]), as shown in Figure 24.2. The serverresponds with a 200 (OK) response (2) that carries the new conference URI in its Contactheader 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 obtaina conference URI, which is allocated by the conference server. Once a conference is created,it is identified by its conference URI.The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third EditionGonzalo Camarillo and Miguel A . Garc ıa-Mart´n ´ ı© 2008 John Wiley & Sons, Ltd. ISBN: 978-0-470-51662-1 CHAPTER 24. CONFERENCING IN THE IMS500 Figure 24.1: The IMS conference service architecture Figure 24.2: Conference creation using a conference factory URI24.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 theconference URI. Bob can obtain such a URI in several ways. For example, Alice can send itto him in an email or tell him on the phone. Alternatively, Alice can send a REFER requestto Bob so that Bob sends an INVITE to the conference URI. Alice can also send a REFERrequest 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 beallocated 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 toallocate such a conference URI (e.g., the URI may not be available because it is in use byanother conference) and, if it does, the conference server returns the same conference URI inthe 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 showsan IMS terminal sending and INVITE request to a conference URI that is hosted at a different CHAPTER 24. CONFERENCING IN THE IMS502domain. The I-CSCF of the terminating domain consults the HSS (7) in order to resolvethe PSI (i.e., the conference URI). The HSS provides the I-CSCF (8) with the address ofthe AS/MRFC corresponding to the PSI and the I-CSCF relays the INVITE request to thatAS/MRFC (9). Before returning a 183 (Session Progress) response (11), the AS/MRFCallocates resources at an MRFP.24.1.2 Other ActionsConference participants can use the SIP conference event package (specified in RFC4575 [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 OMAThe IMS conference service described in this chapter has been specified by 3GPP. In additi ...