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