Chapter 22 - The Instant Messaging Service in the IMS ppt

22.1 Pager-mode Instant Messaging in the IMS The pager-mode instant messaging service was introduced with the first phase of IMS that contained requirements for Application Servers ASes

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

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 implement 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 criteria indicates that the S-CSCF should perform a third-party registration with a particular AS The S-CSCF then sends a 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

Terminal #1

(1) MESSAGE

P-CSCF

(12) 200 OK

P-CSCF

(2) MESSAGE

(11) 200 OK (13) 200 OK

(4) Diameter LIR (5) Diameter LIA

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 protocol specification is described in 3GPP TS 24.247 [45] Session-based instant messaging was not included in Release 5 because at the time 3GPP closed

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 provided 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 consists 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

Terminal #1

(1) INVITE

P-CSCF

(18) 180 Ringing

P-CSCF

(3) INVITE

(17) 180 Ringing (19) 180

Ringing

(7) Diameter LIR (8) Diameter LIA

(15) 180 Ringing

(21) 200 OK (22) 200 OK

(28) ACK

Accept session

(26) 200 OK

(27) ACK

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 new 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

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 users 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

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