Chapter 22 The Instant Messaging Service in the IMS Chapter 21 described the basic components of the instant messaging service. We learnt that there are two modes of operation: pager mode and session-based mode. In this chapter we analyze how these two modes are applied to the IMS. We explore the basic call flows and present examples of services that can be enriched with instant message capabilities. 22.1 Pager-mode Instant Messaging in the IMS The pager-mode instant messaging service was introduced with the first phase of IMS that came as part of Release 5 of the 3GPP specifications. 3GPP TS 23.228 [43] already contained requirements for Application Servers (ASes) and S-CSCFs to be able to send textual information to an IMS terminal. 3GPP TS 24.229 [37] introduces support for the MESSAGE method extension. The specification mandates IMS terminals to implem e nt the MESSAGE method (specified in RFC 3428 [115]) and to allow implementation to be an optional feature in S-CSCFs and ASes (e.g., if required by the service). Obviously, pager-mode instant messages are subject to the constraints (e.g., message size, etc.) that we described in Section 21.3. The main purpose of a pager-mode instant message is to allow the S-CSCF or ASes to send short instant messages to the IMS terminal. Since the MESSAGE method is already implemented in IMS terminals, users are able to send pager-mode instant messages to other IMS users. The flow is simple, as depicted in Figure 22.1. An example of a service provided with the SIP MESSAGE method is shown in Figure 22.2. An AS is the controller of a voicemail system. The AS is interested to know when the user successfully logs on to the IMS, so that the AS can inform the user that there are pending voicemails to be retrieved. The service is implemented as follows: the user registers with the IMS as usual, (1)–(20) in Figure 22.2. When the registration is complete the S-CSCF evaluates the initial filter criteria. One of the initial filter criter ia indicates that the S-CSCF should perform a third-party registration with a particular AS. The S-CSCF then sends a third-party REGISTER request (21) to the indicated AS. The purpose of the third- party REGISTER request is not to register the user with the AS, but instead to indicate to the AS that the user has just registered with the S-CSCF. Upon receipt of the REGISTER ´ı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 478 CHAPTER 22. THE INSTANT MESSAGING SERVICE IN THE IMS IMS Terminal #1 (1) MESSAGE P-CSCF (12) 200 OK P-CSCF (2) MESSAGE (11) 200 OK (13) 200 OK S-CSCF S-CSCF (4) Diameter LIR (5) Diameter LIA I-CSCF HSS IMS Terminal #2 (3) MESSAGE (6) MESSAGE (7) MESSAGE (8) MESSAGE (9) 200 OK Originating Visited Network Originating Home Network Terminating Home Network Terminating Visited Network (10) 200 OK (14) 200 OK Alert user Evaluation of initial filter criteria Evaluation of initial filter criteria Figure 22.1: Pager-mode instant messaging in the IMS request (21) the AS generates a MESSAGE request (23) that contains some informative text, maybe a link to a website that holds the transcription of the pending messages to retrieve or any other information that the service designer considers appropriate. The MESSAGE request is forwarded via the S-CSCF and P-CSCF as any other SIP message. 22.2 Pager-mode Instant Messaging to Multiple Recipients IMS also allows IMS terminals to send MESSAGE request to multiple recipients. This is done in cooperation with the help of a List Server, which takes the role of a URI-list server. In fact, the technology is a straight-forward application of MESSAGE URI-list services that we described in Section 21.6.1. The UE is able to send the list of recipients attached to the MESSAGE request, as a resource list, along with the instant message. The MESSAGE request is addressed to the Public Service Identity of the list AS that executes the multiple messaging service. IMS terminals can also indicate when the user is composing a message, by making use of the isComposing feature for instant message. We described the isComposing feature in Section 21.5. 22.3 Session-based Instant Messaging in the IMS The session-based instant messaging service was introduced in Release 6 of the 3GPP speci- fications. The detailed p rotocol specification is d escribed in 3GPP TS 24.247 [45]. Session- based instant messaging was not included in Release 5 because at the time 3GPP closed 22.3. SESSION-BASED INSTANT MESSAGING IN THE IMS 479 IMS Terminal (1) REGISTER P-CSCF (10) 401 Unauthorized S-CSCF (2) REGISTER (9) 401 Unauthorized (11) REGISTER (20) 200 OK (12) REGISTER (19) 200 OK I-CSCF HSS (3) Diameter UAR (4) Diameter UAA (5) REGISTER (8) 401 Unauthorized (6) Diameter MAR (7) Diameter MAA (13) Diameter UAR (14) Diameter UAA (15) REGISTER (18) 200 OK (16) Diameter SAR (17) Diameter SAA AS Evaluation of initial filter criteria (21) REGISTER (22) 200 OK (23) MESSAGE (24) MESSAGE (25) MESSAGE (26) 200 OK (27) 200 OK (28) 200 OK Figure 22.2: Example of a service p rovided with pager-mode instant messages Release 5 the IETF had just started work on session-based instant messaging. Therefore, the functionality of session-based instant messaging was postponed until Release 6. We described in Section 21.4 how to establish a session of instant messages with an INVITE request that contains provisions in SDP for the instant message media. The Message Session Relay Protocol (MSRP) is the actual protocol used to transport the messages. In the IMS, MSRP is implemented in the IMS terminals. In addition, the MRFP may also implement MSRP. The reason behind this is that there are two different scenarios for establishing a session of instant messages. In the first scenario, which we show in Figure 22.3, an IMS terminal establishes a session toward another endpoint. SIP messages traverse regular IMS nodes (P-CSCFs, S-CSCFs, perhaps ASes, etc.). MSRP is then sent end-to-end. The only difference from a basic session setup c onsists of the absence of the precondition extension requirement in the INVITE request, if session-based messaging is the only media stream declared in SDP. This is the reason for not having 183 (Session Progress) responses, PRACK, or UPDATE requests in the flow. In the second scenario the MRFC and MRFP are intermediaries in the network. This might be a result of operator constraints, such as the ability to generate charging events 480 CHAPTER 22. THE INSTANT MESSAGING SERVICE IN THE IMS IMS Terminal #1 (1) INVITE P-CSCF (18) 180 Ringing P-CSCF (3) INVITE (17) 180 Ringing (19) 180 Ringing S-CSCF S-CSCF (7) Diameter LIR (8) Diameter LIA (15) 180 Ringing (21) 200 OK (22) 200 OK (28) ACK Accept session (26) 200 OK (27) ACK I-CSCF HSS IMS Terminal #2 (5) INVITE (2) 100 Trying (4) 100 Trying (6) 100 Trying (9) INVITE (10) 100 Trying (11) INVITE (12) 100 Trying (13) INVITE (14) 100 Trying Originating Visited Network Originating Home Network Terminating Home Network Terminating Visited Network (16) 180 Ringing (20) 180 Ringing (24) 200 OK (30) ACK Alert user (29) ACK (23) 200 OK Evaluation of initial filter criteria Evaluation of initial filter criteria (25) 200 OK (32) MSRP: SEND (31) ACK (33) MSRP: 200 OK (34) MSRP: SEND (35) MSRP: 200 OK Figure 22.3: Session-based instant messages: end-to-end MSRP session depending on the size of the message or on any additional contents in MSRP SEND messages. Another reason might be that the MRF is acting as a multiparty conference unit for instant messages (also known as chat rooms). Figure 22.4 shows the flow for a multiparty conference. For the sake of simplicity we assume that both users who join the conference belong to the same network operator, although they may have allocated different S-CSCFs and P-CSCFs. In the figure a first user sends an INVITE request (1) that traverses their allocated P-CSCF and S-CSCF. Their S-CSCF forwards the INVITE request (5) to the MRFC. The MRFC, which controls the MRFP by means of the H.248 protocol (7), creates a n ew termination for the user. Then the user sends an empty MSRP SEND request (14), i.e., where there is no body. This allows the MRFP to bind the TCP connection to the MSRP session. 22.3. SESSION-BASED INSTANT MESSAGING IN THE IMS 481 Figure 22.4: A multi-party session-based conference (chat server) Later, a second user joins the conference and establishes another session with the MRFC. Once the SIP session is established, the user also sends an empty MSRP SEND request (29) that allows the MRFP to bind the TCP connection to the MSRP session. At any time any of the u sers can send an instant message that is transported over an MSRP SEND request: for instance, when the second user sends an MSRP SEND request (31) the MRFP sends a copy of it (33) to the remaining participants of the conference. 482 CHAPTER 22. THE INSTANT MESSAGING SERVICE IN THE IMS 22.4 File Transfer IMS also supports the transfer of files with SIP and MSRP. We have already described this technology in Section 21.7: this service is a straight-forward application of the file transfer mechanism that we described earlier. . constraints, such as the ability to generate charging events 480 CHAPTER 22. THE INSTANT MESSAGING SERVICE IN THE IMS IMS Terminal #1 (1) INVITE P-CSCF (18) 180 Ringing P-CSCF (3) INVITE (17) 180 Ringing (19). Session-based Instant Messaging in the IMS The session-based instant messaging service was introduced in Release 6 of the 3GPP speci- fications. The detailed p rotocol specification is d escribed in. Chapter 22 The Instant Messaging Service in the IMS Chapter 21 described the basic components of the instant messaging service. We learnt that there are two modes of operation: