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. | 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. The IMS Conferencing Service The IMS conferencing service specified in 3GPP TS 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 . In the IMS the conference server is distributed into two logical entities one handling signaling and the other handling media as shown in Figure . 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. 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 . 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 .
