Chapter 210 Instant Messaging on the Internet pot

Chapter 21

Instant Messaging on the Internet

Instant messaging is one of today’s most popular services. Many youngsters (and not-so￾young people) use the service to keep in touch with their relatives, friends, co-workers, etc.

Millions of instant messages are sent every day. So, it will come as no surprise that such a

popular service is already supported in the IMS.

Instant messaging is the service that allows a user to send some content to another user

in near-real time. Because of the real-time characteristics of instant messages the content is

typically not stored in network nodes, as often happens with other services such as email.

The content in an instant message is typically a text message, but can be an HTML page,

a picture, a file containing a song, a video clip, or any generic file.

The instant messaging service combines perfectly with the presence service, since

presence allows a user to be informed when other users become available (e.g., connect to

the network). Then, users can send instant messages to their friends and start some sort of

messaging conversation.

21.1 The im URI

Like presence, mail, or AAA functions, an instant messaging service can be identified by an

im URI. Like the pres URI the im URI does not define the protocol used to access an instant

message resource. So, whenever SIP is the protocol used to send the instant message it is

recommended to use sip or sips URIs.

The syntax of the im URI is

IM-URI = "im:" [ to ] [ headers ]

to = mailbox

headers = "?" header *( "&" header )

header = hname "=" hvalue

hname = *urlc

hvalue = *urlc

An example of an im URI is

im:[email protected]

ıa- ´ Martı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

454 CHAPTER 21. INSTANT MESSAGING ON THE INTERNET

21.2 Modes of Instant Messages

There are two modes of operation of the instant message service, depending on whether they

are stand-alone instant messages or part of a session of instant messages.

We refer to a pager-mode instant message as one that is sent as a stand-alone message, not

having any relation with previous or future instant messages. This mode of instant messaging

is referred to as “pager mode” because the model resembles the way a two-way pager works.

The model is also similar to the SMS (Short Message Service) in cellular networks.

We refer to a session-based instant message as one that is sent as part of an existing

session, typically established with a SIP INVITE request.

Both models have different requirements and constraints; hence, their implementation is

different. The following sections describe the implementation of both models.

21.3 Pager-mode Instant Messaging

The IETF has created an extension to SIP that allows a SIP UA to send an instant message

to another UA. The extension consists of a new SIP method named MESSAGE. The SIP

MESSAGE method, which is specified in RFC 3428 [115], is able to transport any kind of

payload in the body of the message, formatted with an appropriate MIME type.

Figure 21.1 illustrates the mode of operation. A UAC sends a MESSAGE request (1) to a

proxy. The detailed contents of the request are shown in Figure 21.2. The proxy forwards the

MESSAGE request (2) like any other SIP request, even when the proxy does not support or

understand the SIP MESSAGE method. Eventually, the UAS will receive it and answer with

a 200 (OK) response (3) that is forwarded (4) to the UAC.

UAC

(1) MESSAGE

Proxy UAS

(2) MESSAGE

(3) 200 OK

(4) 200 OK

Figure 21.1: Pager-mode instant message with a MESSAGE request

Like OPTIONS or REGISTER, MESSAGE requests do not create a SIP dialog. They are

stand-alone requests. However, they can be sent as part of an existing dialog (e.g., created by

a SIP INVITE request).

21.3.1 Congestion Control with MESSAGE

One of the problems with SIP derives from the fact that any proxy can change the transport

protocol from TCP to UDP, SCTP, or other transport protocols and vice versa. UDP is

notorious for not offering any congestion control, whereas TCP and SCTP do offer congestion

control. If a UA is sending a large instant message over a transport protocol that does not offer

congestion control, the network proxies can become congested and stop processing other SIP

requests such as INVITE, SUBSCRIBE, etc. Even if a UA sends a large SIP MESSAGE