Mobile Instant Messaging Systems - A Comparative Study

Transcription

HELSINKI UNIVERSITY OF TECHNOLOGY
Department of Computer Science and Engineering
Telecommunications Software and Multimedia Laboratory
Peter Salin
Mobile Instant Messaging Systems A Comparative Study and Implementation
Master’s Thesis submitted in partial fulfillment of the requirements for the degree of
Master of Science in Technology.
Espoo, September 21, 2004
Supervisor:
Professor Antti Ylä-Jääski
Instructor:
Juhani Malka, M.Sc.
HELSINKI UNIVERSITY
OF TECHNOLOGY
ABSTRACT OF THE
MASTER’S THESIS
Author:
Peter Salin
Name of the thesis: Mobile Instant Messaging Systems A Comparative Study and Implementation
Date:
September 21, 2004
Number of pages: 75 + 5
Department:
Department of Computer
Professorship: T-110
Science and Engineering
Supervisor:
Prof. Antti Ylä-Jääski
Instructor:
Juhani Malka, M.Sc.
Ever since their introduction less than a decade ago, modern instant messaging systems
have experienced a massive growth in users. Meanwhile, text messaging has revolutionized the use of the mobile phone, bringing mobile messaging forward as a new
source of revenue for service providers. Now service providers look to enrich mobile
messaging by bringing the combination of presence awareness and real-time messaging,
that is instant messaging, to the mobile environment. However, several restrictions are
inflicted on mobile services due to the differences of mobile and wireline environments.
The instant messaging standards destined for mobile networks must be able to adapt
to these restrictions.
IMPS (Instant Messaging and Presence Service) is an instant messaging system designed especially for mobile environments. Another instant messaging system, the SIP
(Session Initiation Protocol) based SIMPLE (SIP for Instant Messaging and Presence
Leveraging Extensions) service, will be introduced in forthcoming third generation (3G)
networks as part of the 3G multimedia services.
This thesis evaluates the applicability of IMPS and SIMPLE in mobile networks and
presents the strengths and weaknesses of the standards in comparison to each other.
The architecture of IMPS was found to be quite simple while SIMPLE is based on a
more complex structure utilizing several different protocols and data formats. Despite
their differences, both architectures are very scalable. The comparison also found the
security services of SIMPLE to be better than those of IMPS. However, SIMPLE has
problems with proxy traversal while IMPS is able to traverse proxies without problems.
The performance of SIMPLE was considered slightly better than IMPS’s when it comes
to bandwidth usage and delays, although the performance of IMPS is more than adequate for mobile environments as well. The level of extensibility and interoperability
is equally high for both IMPS and SIMPLE.
In conclusion, IMPS is easy to deploy due to its simple architecture, while considerable
effort and resources are required to deploy the more complex SIMPLE service. On the
other hand, SIMPLE enables a range of other multimedia services to be launched based
on the same framework. As SIMPLE offers stronger security services, it is a better
alternative for transporting business-critical information. In contrast, IMPS enables
the creation of a global instant messaging service spanning both mobile networks and
the wireline Internet, while SIMPLE is unable to accomplish the same due to proxy
traversal problems. All in all, both services conform well to the requirements of mobile
networks.
Keywords: mobile instant messaging, instant messaging, presence awareness, IMPS,
SIMPLE
ii
TEKNISKA HÖGSKOLAN
Författare:
Titel:
Datum:
Avdelning:
Övervakare:
Handledare:
SAMMANDRAG AV DIPLOMARBETE
Peter Salin
System för mobila direktmeddelanden En jämförande studie och implementation
21.09.2004
Antal sidor: 75 + 5
Avdelningen för datateknik
Professur:
T-110
Prof. Antti Ylä-Jääski
DI Juhani Malka
Moderna system för direktmeddelande har ända sedan introduktionen för mindre än
tio år sedan erfarit en massiv ökning i antalet användare. Under tiden har textmeddelanden (SMS) revolutionerat sättet på vilket mobiltelefoner används, vilket har fört
fram mobila meddelanden som en ny inkomstkälla för tjänstleverantörer. Nu strävar
leverantörer av mobila tjänster till att berika utbudet av tjänster genom att lansera
direktmeddelande i en mobil omgivning. Mobila och stationära omgivningar skiljer sig
emellertid avsevärt ifrån varandra. Detta medför en hel del begränsningar, till vilka en
standard för mobila direktmeddelanden måste klara av att anpassa sig.
IMPS (Instant Messaging and Presence System) är ett system för direktmeddelande
konstruerat speciellt för att användas i en mobil omgivning. Ett annat system för
direktmeddelande, det SIP (Session Initiation Protocol) baserade SIMPLE (SIP for
Instant Messaging and Presence Leveraging Extensions), kommer att lanseras som en
multimediatjänst i kommande tredje generationens (3G) nätverk.
Detta arbete undersöker hur väl IMPS och SIMPLE tillämpar sig för användning i
mobila nätverk samt beskriver standardernas styrkor och svagheter i jämförelse med
varandra.
Arkitekturen hos IMPS visade sig vara relativt simpel, medan SIMPLE har en mera
komplex struktur och använder sig flera olika protokoll och data format. Trots skillnaderna, är skalbarheten hos båda arkitekturerna utmärkt. Jämförelsen visade också
att SIMPLE erbjuder bättre säkerhetstjänster än IMPS. Däremot har SIMPLE problem med proxyservrar medan IMPS-trafik kan genomkorsa proxyservrar utan problem.
Prestationsförmågan hos SIMPLE betraktades vara något bättre än IMPS’ när det
gäller förbrukning av bandbredd och fördröjningar, även om prestationen hos IMPS
också visade sig vara mer än tillräcklig för mobila omgivningar. När det gäller flexibilitet och interoperabilitet ligger bägge standarder på lika hög nivå.
Som slutsats: IMPS är enklare att ta i bruk tack vare dess simplare arkitektur medan en
lansering av SIMPLE kräver större ansträngingar och resurser. Å andra sidan möjliggör
ramverket på vilket SIMPLE är baserat lanseringen av en lång rad andra multimediatjänster. Eftersom SIMPLE erbjuder starkare säkerhetstjänster, är den bättre lämpad
för transportering av business-kritisk information. I motsats möjliggör IMPS skapandet
av en global tjänst för direktmeddelande innehållande både mobila nätverk och Internet, medan SIMPLE inte förmår detsamma p.g.a. problem med proxyservrar. Allt som
allt anpassar sig bägge tjänster väl till mobila omgivningar.
Nyckelord: mobilt direktmeddelande, direktmeddelande, närvaro, IMPS, SIMPLE
iii
Acknowledgements
This Master’s thesis has been done for Celtius Ltd.
I want to thank the management of Celtius Ltd. for giving me the opportunity to write
this thesis for their company.
I wish to thank my instructor Juhani Malka for his valuable input and guidance during
the entire work process.
I would also like to thank my supervisor, Professor Antti Ylä-Jääski, for his helpful comments and advice regarding the thesis.
My gratitude also goes to all those who read and commented the final draft version of this
thesis.
Finally, I would like to thank my family for their support throughout my entire studies.
Espoo, September 21, 2004
Peter Salin
iv
Contents
Abbreviations
viii
1 Introduction
1
1.1
Objectives and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Internet Instant Messaging
3
2.1
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.1
Concepts and Model . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.2
Differences from Other Communication Systems . . . . . . . . . . .
8
2.4
2.5
2.6
Proprietary Instant Messaging Systems . . . . . . . . . . . . . . . . . . . . . 10
2.4.1
ICQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2
AOL Instant Messenger . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.3
Yahoo Messenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.4
MSN Messenger/Windows Messenger . . . . . . . . . . . . . . . . . 11
Standards and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.1
IMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.2
SIMPLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.3
XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6.1
Server Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6.2
Message Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7
Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8.1
Types of Security Threats . . . . . . . . . . . . . . . . . . . . . . . . 17
v
3 Mobile Instant Messaging
20
3.1
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2
History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3
Differences in Comparison to Instant Messaging in Fixed Networks . . . . . 22
3.4
3.3.1
Device Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.2
Network Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.3
Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4
Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Standards and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.1
xMS (SMS, EMS, MMS)
. . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.2
IMPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Comparison of IMPS and SIMPLE
32
4.1
Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2
Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3
4.4
4.2.1
Architecture
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.2
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.3
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1
Bandwidth Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2
Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.3
Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.4
Coverage Loss
4.3.5
Proxy Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.6
Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.7
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.1
Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.2
Attack Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.3
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5
Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6
Extensibility
4.7
Current Status and Future Trends . . . . . . . . . . . . . . . . . . . . . . . 52
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.7.1
Industry Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7.2
Service Maturity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7.3
Future Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
vi
5 Implementation of IMPS CSP Protocol
5.1
5.2
5.3
55
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.1
Overall Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.2
CSP Protocol Requirements . . . . . . . . . . . . . . . . . . . . . . . 57
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.1
Tools
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.2
CSP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.3
CSP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.1
Programming Language . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3.2
Tools
5.3.3
Software Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3.4
Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3.5
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6 Discussion and Conclusions
65
6.1
Comparison of IMPS and SIMPLE . . . . . . . . . . . . . . . . . . . . . . . 65
6.2
Implementation of IMPS CSP protocol . . . . . . . . . . . . . . . . . . . . . 66
6.3
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.4
Significance of the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.5
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Bibliography
70
A Message Flow Examples
76
vii
Abbreviations
3GPP
Third Generation Partnership Project
APEX
Application Exchange
CIR
Connection Initiation Request
CLP
Command Line Protocol
CPIM
Common Profile for Instant Messaging
CPP
Common Profile for Presence
CSP
Client-Server Protocol
DOM
Document Object Model
DTD
Document Type Definition
EMS
Enhanced Messaging Service
GIF
Graphics Interchange Format
GLMS
Group and List Management Server
GPRS
General Packet Radio Service
GSM
Global System for Mobile communications
HTTP
Hypertext Transfer Protocol
HTTPS
Hypertext Transfer Protocol (Secure)
IEC
International Engineering Consortium
IETF
Internet Engineering Task Force
IM
Instant Messaging
IMAP
Internet Message Access Protocol
IMPP
Instant Messaging and Presence Protocol
viii
IMPS
Instant Messaging and Presence Service
IMS
IP Multimedia Subsystem
IP
Internet Protocol
IRC
Internet Relay Chat
JPEG
Joint Photographic Experts Group
MD5
Message Digest Algorithm #5
MIDI
Musical Instrument Digital Interface
MIME
Multipurpose Internet Mail Extensions
MMS
Multimedia Messaging Service
MPEG
Moving Pictures Experts Group
MSRP
Message Session Relay Protocol
OMA
Open Mobile Alliance
PIDF
Presence Information Data Format
POP
Post Office Protocol
PRIM
Presence and Instant Messaging Protocol
RFC
Request For Comments
RTT
Round-Trip Time
SAP
Service Access Point
SAX
Simple API for XML
SHA
Secure Hash Algorithm
SIMPLE
SIP for Instant Messaging and Presence Leveraging Extensions
SIP
Session Initiation Protocol
SIPPING
Session Initiation Protocol Project Investigation
SMCNP
Server Mobile Core Network Protocol
SMIL
Synchronized Multimedia Integration Language
S/MIME
Secure MIME
SMS
Short Message Service
ix
SSP
Server-Server Protocol
TCP
Transmission Control Protocol
TLS
Transport Layer Security
UDP
User Datagram Protocol
UML
Unified Modeling Language
UMTS
Universal Mobile Telecommunications System
URI
Uniform Resource Identifier
VoIP
Voice over IP
WAP
Wireless Application Protocol
WBXML
Wireless Binary XML
WLAN
Wireless Local Area Network
WSP
Wireless Session Protocol
XCAP
XML Configuration Access Protocol
XML
Extensible Markup Language
XMPP
Extensible Messaging and Presence Protocol
x
Chapter 1
Introduction
Picture yourself in a situation where you realize that you have an hour of free time to
spend. You decide to gather a group of friends to meet for a cup of coffee. Using your
mobile phone you are able to see which of your friends currently are available and possibly
even where they are located and what mood they are in. Quickly you have gathered a
list of people, potentially willing to keep you company. Next you send an instant message
to the whole group, inviting them to join you. As all responses are sent to the group,
negotiating the time and place to meet is efficient and easy. Before you know it, you are
all at the cafeteria having your cup of coffee.
The above example illustrates one application of mobile instant messaging. As neither
presence information nor group instant messaging are available in current mobile networks,
the above situation would require numerous phone calls or text messages, consuming most
of the time available.
The combination of presence awareness and real-time messaging offered by instant messaging systems has proved to be the source of a killer application in the Internet, gathering
hundreds of millions of users. Although originally considered a teenager toy, the benefits
of instant messaging have been realized by both academic and corporate organizations in
the last few years.
Concurrently with the instant messaging revolution of the Internet, the introduction of
text messaging has launched a similar phenomenon in mobile networks. Over time, mobile
messaging has proved one of the most important sources of revenue for providers of mobile
services and new messaging services, such as multimedia messaging and mobile email, have
been introduced in recent years.
Now, instant messaging is about to make the transition from the wireline Internet to mobile
networks. This thesis studies the requirements placed upon instant messaging systems by
mobile environments and evaluates the applicability of two instant messaging systems set
for introduction in mobile networks in the future.
1
CHAPTER 1. INTRODUCTION
1.1
2
Objectives and Scope
The objectives of this thesis are:
To identify requirements and limitations related to mobile instant messaging
To compare IMPS and SIMPLE emphasizing the requirements of mobility
To design and implement the client and the server end of the IMPS CSP protocol
In order to be able to evaluate the applicability of instant messaging systems to mobile
environments, the restrictions of mobile networks that affect such a system must be identified. Earlier work in this area has been performed by Parvianen et al. [48], Vogiazou
[68] and Leggio et al. [37].
IMPS (Instant Messaging and Presence Service) and SIMPLE (SIP for Instant Messaging
and Presence Leveraging Extensions) are two instant messaging systems, both more than
likely to be deployed in mobile networks in forthcoming years. The main objective of this
thesis is to uncover the strengths and weaknesses of these services and to evaluate how
well they conform to the requirements of mobile environments. This kind of study has not
been performed earlier, but Leggio et al. [37] have evaluated the performance of XMPP
(Extensible Messaging and Presence Protocol) in mobile networks while Greene et al. [27],
Mituoka et al. [40] and Parvianen et al. [48] have proposed their own instant messaging
solutions for mobile environments.
Finally, the design and implementation of the Client-Server Protocol (CSP) of IMPS is
one goal of this thesis. The CSP protocol provides clients of the IMPS instant messaging
service with access to the IMPS server and the functionality provided by the IMPS service.
In essence, CSP enables a user to interact with all other users connected to the same IMPS
service.
The scope of this thesis is limited to exploring instant messaging standards in general;
evaluating single products or implementations of the standards is not inside the scope of
the thesis.
1.2
Structure
Chapter 2 introduces the concept of instant messaging and presents the solutions currently
used in Internet instant messaging. Chapter 3 describes the services used to enable mobile
messaging and studies the restrictions that mobile environments inflict on mobile instant
messaging services. Two mobile instant messaging candidates, IMPS and SIMPLE, are
compared in Chapter 4. Chapter 5 presents the design and implementation of the CSP
protocol of IMPS. Finally, Chapter 6 discusses the findings of the thesis and presents the
conclusions that can be drawn from them.
Chapter 2
Internet Instant Messaging
Instant messaging services have enjoyed a constant growth ever since their introduction.
Real-time messages and presence information are the pieces of technology that makes
instant messaging different from previous communication services. However, the success
of instant messaging is not based on technical differences only; also the methods and
concepts used in instant messaging clients, such as popup windows and buddy lists, have
contributed to the birth of a completely new type of communication. Although first
considered a toy for teenagers, the value of instant messaging to enterprises, e.g. in form
of cost savings and increase in efficiency, has been recognized in recent years.
This chapter introduces the concept of instant messaging as well as the solutions available
for enabling Internet instant messaging. Section 2.1 defines the term ’instant messaging’.
Section 2.2 presents the history of instant messaging in the Internet. In Section 2.3, an
overview of the concepts and model of instant messaging is given. Section 2.4 describes
the proprietary solutions for instant messaging while Section 2.5 presents standardized
solutions. The architectural choices used in instant messaging systems are explained in
Section 2.6. Section 2.7 describes the interoperability problem of Internet instant messaging. Finally, in Section 2.8 the security features of Internet instant messaging systems are
discussed.
2.1
Definition
Several different interpretations of the term ’instant messaging’ exist. This section clarifies
the meaning of the term within this thesis.
IEC (International Engineering Consortium) provides the following definition: ”Instant
messaging (IM) is an Internet protocol (IP)–based application that provides convenient
communication between people using a variety of different device types” [18].
Campbell et al. [14] defines instant messaging as ”the exchange of content between a set
3
CHAPTER 2. INTERNET INSTANT MESSAGING
4
of participants in near real time”.
Webopedia.com [69] states that instant messaging is ”a type of communications service
that enables you to create a kind of private chat room with another individual in order
to communicate in real time over the Internet, analogous to a telephone conversation
but using text-based, not voice-based, communication. Typically, the instant messaging
system alerts you whenever somebody on your private list is online”.
According to another online IT-specific encyclopedia, Whatis.com [70], instant messaging
is ”the ability to easily see whether a chosen friend or co-worker is connected to the Internet
and, if they are, to exchange messages with them”.
Finally, Kohda et al. [35] refers to instant messaging as ”buddy list applications, which
consist of two orthogonal services, presence and short messaging”.
The IEC definition is rather vague and applies to almost all types of messaging. Campbell
et al. recognizes the fact that instant messages are delivered to the recipient in real time.
The remaining definitions all include presence as a part of instant messaging, thus exposing
the dual nature of the term. Instant messaging is often perceived as a service consisting
of both presence and sending of instant messages. However, the term instant messaging is
frequently used also when referring to the sending of instant messages. In this thesis the
former definition will mainly be used. If the term ”instant messaging” is referring to the
sending of instant messages it will be made clear by context.
Definition 1 Instant messaging is a type of communication service providing users with
two elements; presence information and real-time messaging.
As it is an essential part of instant messaging it is necessary to provide a definition for
presence as well.
Webopedia.com [69] defines presence as ”the ability to detect whether other users are
online and whether they are available”.
Day et al. [19] provides the following definition: ”Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. ”online” or ”offline”) of
other users”.
For the purposes of this thesis, the latter definition is suitable. It should be stressed that
presence information is not restricted to online status only, other attributes such as mood,
location and language might just as well be included. Also note that instant messaging is
merely one application of presence; other technologies, e.g. VoIP (Voice over IP), provide
presence services as well.
Definition 2 Presence is a means for finding, retrieving, and subscribing to changes in
the presence information of other users.
2.2
5
History
The Unix ’talk’ tool, released in the mid 1980’s, was one of the first applications to provide
real-time messaging. ’Talk’ did not provide presence information, but combined with e.g.
the Unix ’finger’ command, the elements of instant messaging were in place. ’Zephyr’, a
notification service released for Unix in 1987, combined real-time messaging and online
status information, but it was originally intended for sending short notifications to users
and not for session-like communication.
In 1988, Internet Relay Chat (IRC) was introduced. IRC provides both real-time messaging and online status information; therefore it can be classified as instant messaging.
Private messaging between two users is the most frequently used type of communication
for instant messaging applications. IRC differs from this as it is designed and mainly used
for group chat, i.e. users join together at a channel (or chat room) where the ongoing
discussion is seen by all joined users.
Instant messaging as we know it today was born in 1996, when Mirabilis, a small Israeli
start-up company, launched ICQ (I Seek You). ICQ included features such as buddy lists,
presence subscriptions/notifications and, of course, sending of instant messages. Whereas
all the previously mentioned solutions were text-based, the ICQ client came with graphical
user interface making it very easy to use. The freely distributed ICQ rapidly gained
popularity, reaching 850 000 registered users in within six months of its release. As the
amount of users connected to the Internet kept soaring, so did the popularity of ICQ.
Although ICQ was free, the major players in the Internet business recognized the value of
such a vast user base. In May 1997 AOL (America Online) released their instant messaging
software, the AOL Instant Messenger. One year later, in June 1998, AOL acquired the
majority of instant messaging users when it bought Mirabilis and ICQ. Microsoft and
Yahoo were not going to let AOL go unchallenged as they released their own solutions,
MSN Messenger and Yahoo Messenger.
All of these new applications became very popular, having a considerable amount of registered users. Unfortunately there was a slight problem; all solutions were based on proprietary protocols, meaning that a user of one IM system could not exchange messages with
a user of another IM system. The problem was addressed by the Internet Engineering
Task Force (IETF), which in 1999 formed the Instant Messaging and Presence Protocol
(IMPP) working group. The group was to specify requirements and framework for instant
messaging, and eventually produce a standard instant messaging protocol.
The IMPP working group had severe difficulties in deciding on an instant messaging
protocol. Therefore it was decided to let the market decide and three new work groups
were formed, each creating their own protocol: Application Exchange (APEX, formerly
IMXP), Presence and Instant Messaging Protocol (PRIM) and SIP for Instant Messaging
and Presence Leveraging Extensions (SIMPLE). The IMPP working group would define a
6
model and common formats for instant messaging, thus ensuring interoperability between
the protocols.
SIMPLE proved to be the strongest of the three candidates; PRIM was discontinued
quite early and APEX, although a finalized standard, has generated only limited interest.
In 2002, a new challenger joined the race as IETF approved a working group for the
Extensible Messaging and Presence Protocol (XMPP). Since then SIMPLE and XMPP
have been battling it out, along with IMPS (Instant Messaging and Presence Services),
a solution mainly targeted at mobile environments but perfectly applicable elsewhere as
well (see Section 3.4.2).
Figure 2.1 displays the growth of users of instant messaging along with the timeline of
instant messaging.
Figure 2.1: The history and user growth of instant messaging. Source: IDC
2.3
2.3.1
Overview
Concepts and Model
RFC (Request For Comment) 2778 [20], produced by the IETF IMPP working group,
defines a common vocabulary and presents an abstract model for instant messaging. This
model is used as such by all current solutions, both proprietary and open standards.
7
Presence Service
Figure 2.2 displays an overview of a presence service. A presence service has two distinct
types of clients: ’presentities’ and ’watchers’. Presentities provide presence information to
the presence service, while watchers request presence information about presentities from
the presence service. Naturally, the same application can act both as a presentity and as
a watcher.
Figure 2.2: Overview of a presence service
The watchers are classified as well; there are ’subscribers’, ’fetchers’ and ’pollers’ (see
Figure 2.3). A subscriber is a watcher that has subscribed to the presence information of
a presentity. The presence service keeps track of the subscriptions and sends a notification
to the subscriber whenever the presence information of the subscribed presentity changes.
A fetcher requests the presence service for presence information about a presentity. The
presence service does not send notifications to fetchers, presence information is only sent
upon the request of the fetcher. A poller is a special kind of a fetcher that polls the
presence service for presence information about a presentity on a regular basis.
Figure 2.3: Different kinds of watchers
Instant Message Service
Equally to the presence service, the instant message service also has two kinds of clients:
’senders’ and ’instant inboxes’ (see Figure 2.4). Senders are the source of instant messages
8
to be delivered by the instant message service. An instant inbox is a container for instant
messages that are to be read by the owner of the inbox. The instant message service
accepts instant messages from senders and attempts to deliver them to the instant inboxes,
to which they are addressed. Typically, the instant inbox resides in the client application,
although it is not required by the IMPP definition.
Figure 2.4: Overview of an instant message service
2.3.2
Differences from Other Communication Systems
Model
Presence, as such, is clearly not part of any major established communication systems of
today, but also the method for delivering messages differs considerably from the methods
currently used.
Most of the currently used messaging systems are based on a paradigm called ’store-andforward’. When sending a message over a network using this paradigm, each message
transfer agent stores and forwards the message to the next agent. In case the next agent
cannot be reached, delivery can be reattempted later on. The store of the message transfer
agent closest to the user agent of the recipient usually serves as an inbox to the user agent.
The user agent fetches the messages from the inbox when it is online. Even though it is
possible for messages to arrive real-time, ’store-and-forward’ is viewed as non-real-time
delivery system since all delivered messages do not arrive in real-time. Examples of messaging systems using ’store-and-forward’ include traditional email, SMS (Short Message
Service) and MMS (Multimedia Messaging Service).
For instant messaging systems, intermediate elements along the path from the sender to
the recipient merely relay the instant message to the next element without storing it. If
the recipient cannot be reached, e.g. when the user is not online, then the instant message
is normally discarded. Some instant messaging systems provide storage for messages sent
to offline users, but this is a distinct service and not part of instant messaging as such.
Sending instant messages from peer to peer is also possible using a few instant messaging
9
systems (e.g. ICQ and SIMPLE). These systems provide the sender with the address of the
recipient, using which the instant messages can be sent directly to the recipient without
any server intervention.
Usage
Voice calls and email are by far the two most popular communication systems of today [8].
Table 2.1 shows some usage related properties of instant messaging compared with the corresponding properties of voice calls and email. Instant messaging can be seen as some kind
of combination of features from voice calls and email. Like voice calls instant messaging
provides real-time communication but at a price comparable to email. Of course, instant
messaging is not free; deploying an instant messaging solution in an enterprise requires noticeable investments. However, after deployment the cost of usage is significantly lower for
instant messaging than for voice calls, especially for international communication. When
it comes to archiving, email systems provide the most sophisticated solutions. Presence
information is one of the greatest benefits for users of instant messaging. Surveys show
that 40-60% of business related phone calls fail due to the callee being busy or absent
[67]. Presence information practically eliminates this phenomena for instant messaging,
assuming that users keep their presence information up-to-date.
Table 2.1: Comparison of popular messaging systems
Messaging
System
Real-time
Cost
Presence
Archiving
Voice call
Yes
High
Partly, the call is either
established or not
No
Email
No
Low
No, the sender does not
know whether the recipient is available or not.
Yes
Instant
Messaging
Yes
Low
Yes, the status of the recipient is known by the
system at all times.
Depends on the IM client.
Must often be done explicitly by the user.
Table 2.2 shows how initiating a business related line of communication using different
messaging systems affects the productivity of parties involved. Voice calls often interrupt
the work of the callee, and on the contrary, emailing is more prone to suspend caller’s
work for a while. Instant messaging is more like voice calls in this aspect, but presence
information provides a means to prevent unnecessary interruptions. Instant messaging can
also reduce productivity if not deployed carefully within an organization. Gossiping and
constant interruptions are some aspects that can decrease productivity. The productivity
aspect of instant messaging is discussed in more detail in [44] and [64].
The comparisons of Tables 2.1 and 2.2 reveal that instant messaging have both strong
and weak points in comparison with current communication systems. There clearly exists
10
Table 2.2: The influence of messaging systems on productivity
Messaging
System
Caller
Callee
Voice call
Generally no decrease in productivity. If
the callee is reached, a direct answer can
be received.
Often decreases productivity as the interrupted callee must drop its current work in
order to answer the call.
Email
Decrease in productivity while waiting for
a reply.
Affects productivity only slightly since the
callee can choose when to answer the
email.
Instant
Messaging
Typically no productivity reduction. The
presence service allows the caller to select
currently available callee.
Reduces productivity upon message reception, but the callee can use the presence
service to control the arrival of messages.
a niche for instant messaging as it is more suitable for particular tasks than the current
systems. However, instant messaging will not eliminate any of the current systems. Users
will choose which system to use based on the type of communication. Instant messaging is suitable for quick real-time conversations, email is convenient for errands that do
not require an immediate response and voice calls are often preferred for e.g. business
negotiations as the risk of misunderstandings is reduced.
2.4
Proprietary Instant Messaging Systems
The instant messaging market is currently dominated by three big companies, AOL, Yahoo
and Microsoft. These companies all offer their own proprietary solutions based on private
protocols that are not interoperable. From the viewpoint of instant messaging, there are
no fundamental differences between the solutions. Instead, the solutions try to attract
users by incorporating non-instant messaging features such as weather reports or online
games. The rest of this section describes these instant messaging systems in brief.
2.4.1
ICQ
ICQ (short for I Seek You), created in 1996 by a small Israeli start-up company called
Mirabilis, is considered the ancestor of instant messaging systems. ICQ introduced concepts like buddy lists, presence subscriptions and block lists, which form the basis for every
instant messaging system of today. Internet growth was exponential at the time and ICQ
quickly gathered a large user base. When Mirabilis was bought for $287 by AOL in 1998,
ICQ had already gathered 12 million users. Currently ICQ has 180 million registered
users, of which approximately 68 millions are active users. The majority of the user base
is located in Asia and Europe, while the amount of users in the U.S. is relatively small.
Table 2.3 presents the amount of active users per instant messaging system. The numbers
are based on a research performed by the Radicati Group in October 2003.
11
Table 2.3: Active users per proprietary instant messaging system
2.4.2
Messaging System
Active Users
AIM
100 million
ICQ
68 million
MSN
66 million
Yahoo
36 million
AOL Instant Messenger
In the early 1990’s America Online (AOL) had a significant amount of users subscribing
to their online services, which included communication through electronic bulletin boards.
In May 1997 AOL released the AOL Instant Messenger (AIM) to provide these users with
the means to communicate with the outside world and vice versa. AIM quickly gained
popularity especially in the U.S., home of AOL, and was starting to catch up with ICQ.
The competition between ICQ and AIM came to an end in 1998, when AOL bought the
company behind ICQ, cornering about 90% of the market. The amount of users has not
decreased since then, but the introduction of several competing systems has reduced the
market share. Presently, AIM is used by roughly 100 million people.
2.4.3
Yahoo Messenger
Yahoo joined the instant messaging race in June 1999 with the release of the Yahoo
Messenger. Starting with no user base, but with a brand well-known to many users of the
Internet, Yahoo currently has a user base of around 36 million for their instant messaging
services.
2.4.4
MSN Messenger/Windows Messenger
Microsoft published their instant messaging solution, the MSN Messenger, in July 1999.
Similarly to Yahoo, Microsoft started out with a non-existent user base but coupling the
Messenger with e.g. Hotmail and Windows has enabled Microsoft to build a large user
base rapidly.
As of now Microsoft has two different instant messaging clients. In addition to the previously mentioned MSN Messenger, the Windows Messenger was released for Windows XP
in 2001. In comparison to the MSN Messenger, the Windows Messenger is more business
focused and includes support for e.g. SIMPLE and the Exchange IM Server. The two
clients are interoperable as both use the same instant messaging network.
All in all, Microsoft’s instant messaging system currently serves about 66 million users.
2.5
12
Standards and Protocols
Ever since it became evident that users of the proprietary solutions would not be able to
communicate with each other, IETF has been striving to produce a standardized solution
for instant messaging. This section presents the results of the standardization efforts.
2.5.1
IMPP
IETF originally chartered IMPP (Instant Messaging and Presence Protocol) in order to
define protocols and data formats necessary to build an internet-scaled instant messaging
system. The working group managed to produce a model for presence and instant messaging in RFC 2778 [20] and requirements for an instant messaging protocol in RFC 2779
[19]. However, as stated in Section 2.2, the working group failed to achieve a common
consensus for an instant messaging protocol. This resulted in the launch of several new
working groups specifying protocols based on IMPP.
It was decided that although the IMPP working group was not to specify any instant
messaging protocol, it would carry on with its work. It would focus on producing standards
for enabling interoperability between instant messaging systems. The working group has
since created RFCs containing:
a common extensible instant message format (message/cpim)
a common extensible presence information format (application/pidf+xml)
a common profile for instant messaging (CPIM)
a common profile for presence (CPP)
CPIM [50] and CPP [51] specify semantics and data formats for common instant messaging
and presence services. The goal of the profiles is to facilitate the creation of gateways
between instant messaging systems for interoperability. CPIM uses the message/cpim
MIME (Multipurpose Internet Mail Extension) type [7] as data format for instant messages
while PIDF (Presence Information Data Format) [65] is used for formatting presence
information in CPP.
In order for an instant messaging system to be IMPP compliant, it must conform to the
CPIM and CPP profiles and their data formats as well as meet the requirements of RFC
2778 and RFC 2779.
2.5.2
SIMPLE
The IETF SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions)
working group was one of the three working groups formed in 2000 when the IMPP
13
working group failed to agree on a common protocol for instant messaging. Of the three,
the SIMPLE solution is the only one still going strong; the other two have more or less
failed.
As the name indicates, SIMPLE is based on SIP (Session Initiation Protocol) [60]. The
primary work of the SIMPLE working group is to generate an IMPP-compliant proposed
standard SIP extension for instant messaging. SIMPLE defines the presence protocol as
an instantiation of the general event notification framework for SIP [56]. For sending
instant messaging SIMPLE provides two modes: a pager mode [14] and a session mode
[13]. When using the pager mode instant messages are sent as SIP messages. In session
mode SIP is used to initiate a session, in which the instant messages then are sent. Detailed
information concerning the technical details of the SIMPLE specifications can be found in
Chapter 4.
The progress of the SIMPLE working group has been quite slow, mostly due to the complexity of the SIP protocol. Overall, the SIMPLE specifications currently consist of close to
20 Internet Drafts. Only a few Requests for Comments has been produced so far, including
pager mode messaging specified in RFC 3428. Despite the slow-moving standardization
process, the SIMPLE standard has gained support from several major companies including
Microsoft, IBM and Yahoo.
2.5.3
XMPP
The Extensible Messaging and Presence Protocol (XMPP) is beyond doubt the strongest
challenger to the SIMPLE standard in the Internet. Like SIMPLE, XMPP is also administered by an IETF working group, i.e. the XMPP working group. XMPP has been formed
from the basis of the Jabber protocol.
The Jabber protocol is the result of a project started by Jeremie Miller in 1998 [16]. The
goal of the project was to produce an interoperable and open instant messaging protocol,
an alternative to the proprietary solutions. The first public release of the protocol took
place in May 2000. In June 2000 project members sent an Internet Draft of the Jabber
protocol to the IMPP working group (see Section 2.5.1) as an instant messaging protocol
proposal. However, the organization of the Jabber project was not mature enough at the
time and the Internet Draft was left to expire. In 2001 the Jabber Software Foundation was
formed to organize the projects and commercial bodies involved in the Jabber community.
Following the reorganization, a new Internet Draft was submitted to the IETF in February
2002, eventually leading to the birth of the XMPP working group in October 2002.
XMPP is in essence the core of the XML (Extensible Markup Language) based Jabber
protocol. XMPP has been made IMPP compliant by the working group. The Jabber
Software Foundation will continue to work on the parts of the Jabber protocol that are
not part of XMPP or IMPP, exploring features such as: multi-user chat, calendaring and
14
whiteboarding.
Compared to SIMPLE, the XMPP solution is more mature. Recently, three of four Internet
Drafts have been approved as Proposed Standards and the protocol has already been
widely deployed with tens of thousands of active servers and millions of users. Although
it has not acquired the support of as many major companies as SIMPLE, XMPP is also
embraced by big enterprises, including Hewlett-Packard and Intel. An in-depth comparison
of SIMPLE and XMPP from the viewpoint of XMPP can be found in [17].
2.6
Architecture
Although virtually all currently available instant messaging systems are based on different protocols, architecturally the solutions are quite similar. Nevertheless, two greater
architectural aspects can be distinguished, namely the distribution of servers and the
mechanism for message exchange.
2.6.1
Server Distribution
Essentially two models can be found for how servers are organized in current instant
messaging systems: the centralized model and the distributed model.
In the centralized model, all information is gathered at one place handled by either one
server or a cluster of servers. All traffic resulting from registration and lookup tasks,
such as logging in, subscribing to presence, fetching presence and receiving notifications,
is routed through the centralized server.
In the distributed model the information is stored by a network of servers, all managing
the information related to their own domain. When users request their home server for
information available in other domains, the server forwards the request to the server of
that domain.
Table 2.4: Advantages and disadvantages of the server distribution models
Characteristic
Centralized model
Distributed model
Administration/Maintenance
Easy
Moderate
Scalability
Limited
Good
Attack vulnerability
High
Moderate
Performance
Limited
Good
Table 2.4 provides a light comparison of the two models. For a single authority, the
centralized model is easier to administer and maintain than the distributed model. Hence,
all the proprietary instant messaging systems are based on the centralized model (see
Table 2.5).
15
On the other hand, the centralized model has several obvious disadvantages. When the
group of users accessing the system expands, more and more traffic is directed at the
server (or cluster of servers) causing severe congestion. All proprietary IM systems have
quite recently experienced outages relating to this as the amount of users logging on has
been soaring. The single point of access is also a security issue as it makes the system
vulnerable to denial-of-service attacks.
The distributed model is more scalable with less traffic directed at a single server. In
addition, an attack on a server does not usually affect the whole system, but as Lundgren
et al. points out in [39], many of the current distributed systems can suffer from single
points of failure if not built carefully. Also, since most communication takes place between
users in the same region, a home server in a distributed system is able to deliver information
faster than a centralized server.
2.6.2
Message Exchange
When it comes to exchanging messages between counterparts, the instant messaging systems can be divided into two camps. One sends all messages, including instant messages,
via a dedicated server to the recipient, while the other transmits instant messages peerto-peer. For peer-to-peer messaging, only instant messages are sent from peer to peer, all
login and presence information must still be sent to the server (see Figure 2.5).
Figure 2.5: Peer-to-peer instant messaging
Again, both mechanisms come with both gains and losses. Sending instant messages via
a server places an extra burden on the server, adding further delay to the delivery under
congestion. On the other hand, sending messages via a server protects the identity of the
users, as the IP (Internet Protocol) address of a user is not disclosed to other users. Group
chat is also easier to implement when messages pass through a server.
With peer-to-peer messaging the IP addresses of the involved parties are disclosed, but a
more efficient data transfer is achieved. Some instant messaging systems send text based
instant messages via a server, but sends content requiring more bandwidth (e.g. video and
16
files) peer-to-peer in order to reduce server load.
Table 2.5 lists the server distribution model and message exchange mechanism for the
existing instant messaging systems. A more detailed evaluation of peer-to-peer networking
and server distribution has been performed by Quintana et al. in [55]
Table 2.5: Architectural differences between instant messaging systems
2.7
Messaging System
Registration/Lookup
Message exchange
AIM
Centralized
Via server
ICQ
Centralized
Peer to peer
IRC
Distributed
Via server/Peer to peer
IMPS
Distributed
Via server
MSN
Centralized
Via server
SIMPLE
Distributed
Peer to peer
XMPP
Distributed
Via server
Yahoo
Centralized
Via server
Interoperability
Interoperability is a serious problem in today’s world of instant messaging. As mentioned
in earlier chapters, the proprietary solutions are not able to cooperate, creating ’islands’
of users unable to communicate with each other. The problem can be seen by comparing
Table 2.3 on page 11 with Figure 2.1 on page 6; the sum of users of four different instant
messaging systems is already greater than the sum of all users. This is, of course, due to
users being forced to run several different clients concurrently in order to reach all their
contacts.
The fear of losing their large user bases makes the companies behind the proprietary
solutions reluctant to open up their systems. The interoperability problem has initiated
attempts to create clients able to communicate with all major proprietary protocols. As
the proprietary protocols are not publicly documented, these solutions are purely based
on reverse-engineering. The messengers from Trillian and Odigo are probably the most
advanced in this area. The multi-network clients do only hide the interoperability problem
they do not solve it, e.g. users are still required to have accounts in all IM systems
they want to access. In addition, the corporations owning the proprietary solutions keep
changing their protocols in order to cut off multi-network clients.
Most of the up-and-coming open standard instant messaging protocols are IMPP compliant. This makes it relatively straight-forward to create gateways enabling users of one
instant messaging system to interact directly with users of another system.
2.8
17
Security
The competition for users caused the companies behind the proprietary instant messaging
solutions to give security a low priority, putting most emphasis on the feature richness for
their products. Because of this, notable security flaws can still be found in all proprietary
solutions.
The forthcoming standardized solutions have incorporated stronger security mechanism
into their design. This makes the standardized instant messaging systems strong contenders in the enterprise instant messaging market.
2.8.1
Types of Security Threats
Several types of security threats for instant messaging can be identified. The main threats
are briefly discussed below, more comprehensive studies of instant messaging security
threats can be found in [29], [38], [42] and [64].
Worms
A worm is a program that tries to propagate itself across a network, using the resources
available on one machine to attack others. Furthermore, a worm might try to cause
damage on the attacked machine before propagation. Most worms are programs spread
through email. The content of the email tries trick users into running the worm, in which
case the worm searches the contacts of the user and forwards itself to these.
Anti-virus products monitoring email traffic are quite effective against worms and can
reduce the rate of propagation considerably. Although, worms can propagate just as well
through instant messages than through email, support for monitoring instant messaging
has not been available until just recently.
Trojan Horses
A Trojan horse is a program masquerading as a benign application, tricking the user into
executing it. Upon execution the Trojan horse usually opens a backdoor, through which
an attacker can access the system. The Trojan horse might also collect user information,
such as logins and passwords, and send them over the Internet to the attacker.
Traditionally, firewalls provide protection against Trojan horses, since the firewall can
be configured to block all traffic but traffic from well-known services. When it comes to
instant messaging the Trojan horses can operate via the instant messaging client, making it
hard to detect using traditional firewalls. Most Trojan horses exploiting instant messaging
utilize the file sharing capabilities in order to infiltrate the system.
18
Buffer Overflow Attacks
Buffer overflow attacks exploit design flaws that allow an attacker to send overly long input
streams to an application, causing the application to overflow its memory and execute code
provided by the attacker instead.
Buffer overflow vulnerabilities have been found in all four of the major proprietary instant
messaging solutions. Nguyen provides a list of attacks exploiting known buffer overflow
vulnerabilities of the instant messaging systems in [42].
Man-in-the-Middle Attacks
A man-in-the-middle attack, allows an adversary to listen to and insert messages into
an ongoing session, impersonating one of the users. Alternatively, the adversary can
attempt to hijack the connection, disconnecting one of the parties and continuing the
session impersonating the disconnected user. The intention of a man-in-the-middle attack
is usually to obtain user passwords and other secret information, either by eavesdropping
the connections or by asking the user directly, disguised as a trusted friend.
A man-in-the-middle attack against a proprietary instant messaging system is fairly easy
to carry out as most systems offer virtually no protection against it. Data is usually sent
both unencrypted and unauthenticated, making reading and producing messages easy for
an adversary. The standard solutions provide better protection against man-in-the-middle
attacks.
Replay Attacks
A replay attack is an attack in which the adversary records a session between two parties
and later replays the recorded data impersonating one party of the earlier communication.
Systems with a weak login mechanism are vulnerable to this attack since the adversary
can login as another user merely by replaying a previously recorded session.
Denial-of-Service Attacks
A denial-of-service (DoS) attack aims to overload the system or service which it is directed
at, effectively making it impossible to use the service. Flooding the target with messages
is the most usual type of denial-of-service attack, but known vulnerabilities of the target
system that allow the adversary to cause the system to consume a large amount of CPU
or to halt the system can also be used in a DoS attack. For attacking large systems, a
distributed DoS attack involving numerous computers is often used.
Especially instant messaging systems based on architectures with centralized servers (see
Section 2.6.1) are vulnerable to this kind of attack. Although the usual reason for a DoS
19
attack is to cause annoyance, it can also be used for example when hijacking a session in
order to block one party of the session.
Chapter 3
Mobile Instant Messaging
Similar to instant messaging in the Internet, mobile messaging also took off in the last
decade of the 20th century. Mobile services might seem no different from Internet services
from a user’s point of view, but the mobile environment imposes several requirements that
a mobile service must fulfill before it can be successfully launched. This chapter presents
the concept of mobile messaging and identifies the restrictions of mobile environments that
a mobile instant messaging service must be able to handle.
The chapter consists of the following parts: Section 3.1 defines the term ’mobile instant
messaging’. Section 3.2 briefly presents the history of mobile messaging. The differences
between mobile and fixed environments from a mobile instant messaging point of view are
described in Section 3.3. Finally, Section 3.4 describes the standards related to mobile
instant messaging.
3.1
Definition
As the word ’mobile’ has several distinct interpretations depending on the context, attempting to provide an unambiguous definition of ’mobile instant messaging’ is in place.
MobileIN.com [41] provides a proper definition stating that ”Mobile Instant Messaging
(MIM) is the ability to engage in IM from a mobile handset via various bearer technologies,
which may include SMS, WAP or GPRS”.
Although implied by the examples of bearers in the previous definition, it should be
stressed that only devices connected through wireless bearers can participate in mobile
instant messaging. In the scope of this thesis, a device must be able to be both mobile and
connected to a network simultaneously in order to engage in mobile instant messaging. A
device connected to a wireline network that first is disconnected, then moved and finally
reconnected does not fit this requirement.
Furthermore, a handset is required to participate in mobile instant messaging. Therefore,
20
CHAPTER 3. MOBILE INSTANT MESSAGING
21
using instant messaging from a laptop connected through a wireless connection is not
considered mobile instant messaging in the scope of this thesis, as the laptop does not
have the limitations of a typical handset.
Definition 3 Mobile instant messaging is the ability to engage in instant messaging from
a mobile handset via various wireless bearer technologies.
Finally, it should be noted that it is possible for an instant messaging system providing
mobile instant messaging to users with mobile handsets to provide instant messaging to
users with fixed connections as well. In fact, this is usually the preferred behavior.
3.2
History
As wireless networks only have existed for a few decades, the history of mobile messaging
is short and the history of mobile instant messaging even shorter.
Mobile messaging took off in the late 1990’s when SMS messaging was made available
to GSM (Global System for Mobile communications) subscribers. In the following years,
SMS usage kept rising rapidly as can be seen from Figure 3.1.
Figure 3.1: Worldwide monthly SMS traffic. Source: EMC Research
The success of SMS got the operators of mobile networks to realize the value of mobile
messaging; considerable revenues can be gained using only a fraction of the available
bandwidth. Therefore, new messaging services similar to SMS but with richer features,
such as EMS (Enhanced Messaging Service) and MMS, have been designed and deployed
lately.
The most successful messaging system of the Internet, email, has also been brought to
mobile clients in a number of different ways. In the beginning, email in mobile clients was
22
handled through SMS messages. Later, mobile email was made available through WAP
(Wireless Application Protocol) and recently mobile devices with email clients managing
email using well-known mail protocols such as IMAP (Internet Message Access Protocol)
or POP (Post Office Protocol) on top of GPRS (General Packet Radio Service) have been
made available.
Instant messaging solutions for mobile devices have been available since 2002, when AOL
and Yahoo started providing access to their instant messaging network using an SMS interface. However, these services are not available worldwide, only users of wireless carriers
that have made an agreement with AOL or Yahoo can use them. The SMS-based instant
messaging services are not very convenient to use as they require the user to remember
several commands and phone numbers. The recent introduction of mobile devices that allow both installation of third party software and packet switched data transfer has enabled
companies to develop their own mobile client software for their proprietary protocols. For
example, AOL has released an instant messaging client for mobile devices running the
Symbian operating system.
Work for a non-proprietary mobile instant messaging solution commenced in 2001 when
Ericsson, Nokia and Motorola teamed up to form the Wireless Village initiative (now
known as IMPS), a joint project established to create universal specifications for mobile
instant messaging. The first release of the specifications was made available in 2002 but
it was not until in the fourth quarter of 2003 that the first mobile device with support for
the technology was published.
The IP Multimedia Subsystem (IMS) defined for enabling multimedia communication
services for 3G networks uses SIP for establishing multimedia sessions. The upcoming
3GPP (Third Generation Partnership Project) Release 6 specifications include instant
messaging using SIMPLE, bringing SIMPLE forth as a contender to IMPS in the mobile
instant messaging world as soon as IMS is widely deployed.
3.3
Differences in Comparison to Instant Messaging in Fixed
Networks
Transitioning from developing Internet services targeted at fixed networks to developing
mobile services is not a trivial task. The mobile environment introduces several constraints
on a mobile service that do not exist in traditional, fixed environments. Not only does the
technology used for establishing wireless networks place limitations on a mobile service,
but also mobile terminals and the behavior of users differ significantly between fixed and
mobile environments. This section presents the characteristics of mobile environments that
deviate from the corresponding ones of wireline environments. Even though only aspects
affecting mobile instant messaging services are considered here, most of them apply to
mobile services in general.
3.3.1
23
Device Limitations
Due to the requirement of portability, mobile devices have several differences in comparison
to stationary computers, which should be considered when designing a mobile service.
These differences are presented briefly below; in-depth studies are available in [15], [23]
and [52].
Display Size
As mobile devices are pocket-sized for portability, it follows that displays must be relatively
small to fit the devices. Due to the small display size, special emphasis must be put on
user interface design for mobile applications. In addition, there are no standard display
resolutions for mobile devices. There exist high-level languages allowing the target device
to render the user interface using its native style, thus trading look-and-feel design for
portability. However, in practice distinct versions of the user interface must often be
created for different display types.
Input Device
Size constraints of portable devices make many traditional input devices such as keyboards
and mice impossible to use with mobile devices. Instead, mobile devices come equipped
with limited keyboards, navigator buttons, touch screens or pointing devices.
When it comes to instant messaging, the greatest problem arising from these alternative
input devices is the difficulty of typing. Typing using any of the aforementioned methods
is notably slower than typing using a regular keyboard. In recent years some progress has
been made in this area; for example the T9 text input system has been introduced.
Memory
Memory is another aspect differing in size from wireline environments to mobile environments. Both physical memory and permanent storage memory are limited on mobile
devices.
These memory limitations cannot be ignored when designing a mobile service. Due to
memory constraints some handsets might e.g. be unable to receive large bulks of data,
forcing designers to utilize alternative methods such as sending data in smaller chunks.
Luckily, rapid progress has been made in this area. In the last few years the magnitude of
memory sizes has shifted from KB to MB. Several solutions for storing data permanently
fitting into a very small space, such as CompactFlash, MultiMediaCard, Secure Digital
Card and SmartMedia Card, have been put into market and are used in numerous new
mobile devices.
24
Processing Power
In addition to memory limitations, mobile devices are limited also when it comes to processing power. When designing a mobile instant messaging service the restrictions of
mobile device processors need to be considered especially when deciding what data formats to use. Data formats are of importance because of the processing power that is
required to en/decode them for network transmission. Codecs for some formats are very
efficient while others require heavy computing. In addition, some formats require more
processing power to encode than to decode and vice versa. In general, codecs demanding
more processing power often result in a better data compression rate and since data size
is another important aspect of mobile computing, this trade-off between processing power
and data size must also be taken into account when choosing data formats.
Battery
Practically all mobile devices are powered by batteries. As most batteries are rechargeable,
saving batteries is often quite nonessential. Furthermore, software engineers implementing
a mobile service have more influence on battery usage than the designers of the service.
A designer of a mobile service can slightly affect the usage of power by optimizing the
use of the processor and data communications. Data communication hardware consumes
power especially when sending or receiving data, optimizing the amount of sent data can
help reducing power consumption. For techniques reducing the need for processing power,
see the previous subsection.
Media Formats
The operating systems of mobile handsets come equipped with a limited range of natively
supported media formats. When specifying a mobile service, support for a particular media
type cannot be assumed. Preferably a mobile instant messaging service should provide
the means for parties of a communication to find out the mutually supported formats or
at least notify the sender of a message when the recipient does not support a particular
media format.
3.3.2
Network Limitations
The characteristics of wireless network links differ considerably from those of links in
conventional wireline networks. These differences affect the behavior of network data
traffic in various ways that need to be considered when designing a mobile service. As the
transport protocols currently in use were originally designed for wireline networks some of
them do not adapt well to wireless environments. The aspects most relevant to protocol
performance are presented below. When deciding which transport protocols to use for a
25
mobile service, each protocol needs to be evaluated against these characteristics in order
to find the most suitable for the particular case.
Bandwidth
Although new generation wireless networks will provide users with bandwidth that is closer
to the one provided to subscribers of fixed networks, bandwidth is still a factor that cannot
be ignored when planning mobile services. E.g. the data rate of 2.5G systems, which is
presently the most widespread wireless technology, is 10-20 kbps uplink and 10-40 kbps
downlink while the corresponding rates of the up-and-coming 3G systems are 64 kbps resp.
384 kbps [30]. In addition to the reduced bandwidth, bandwidth variations are also more
frequent in wireless networks. Handovers and the fact that voice usually has precedence
over data in wireless networks are two causes for bandwidth fluctuation.
Even though most instant messages contain only text and are small in size, bandwidth
limitations cannot be completely neglected as many instant message services allow any
kind of content to be sent. Another reason for optimizing the bandwidth usage is operator
charging schemes (see Section 3.3.4).
Delay
The delays in wireless networks can be several magnitudes greater than in conventional
wireline ones; delays exceeding one second are not unusual in wireless environments,
whereas delays in fixed networks often are measured in milliseconds. Most of the latency in wireless networks is caused by transmission delays in the radio access network
and by the extensive processing done at the physical layer [30].
Another characteristic of wireless networks is high delay jitter, i.e. variations to the round
trip time. Typical causes for increased delay jitter are [28]:
Temporal loss of coverage, e.g. in tunnels or elevators
Handovers
Blocking by higher-priority traffic such as voice calls
Delays and delay jitter especially affect the performance of protocols providing reliable
delivery, such as TCP (Transmission Control Protocol). Several mechanisms for improving
TCP performance in wireless environments have been developed. The Timestamps Option
[33] aims to make TCP adapt better to delays and delay jitter.
As instant messaging is a real-time service, minimizing the time it takes for a message the
reach the recipient is essential. For example, initiating a connection with a connectionoriented protocol is very time-consuming when long delays are experienced. Therefore,
keeping the connection active between messages improves performance considerably.
26
Packet Losses
Another characteristic specific to wireless networks is a high packet loss rate. As opposed
to the wireline networks where packet losses usually are caused by congestion, packet
losses in wireless networks are mainly caused by bit errors, i.e. packets are corrupted
while traversing the network. Common reasons for these bit errors are [49]:
Weak signal power
Co-channel interference (several sources with equal signal power)
External noise sources between transmitter and receiver
Due to the high probability of packet corruption, many wireless technologies apply linklayer error correction techniques in order to reduce end-to-end packet losses.
In particular the TCP protocol, which is built around the assumption that packet losses
are caused by congestion, suffers a decrease in performance in wireless environments. A
number of papers studying and proposing improvements to TCP, including [21], [30], [33]
and [36], are available. Unreliable transport protocols, such as UDP (User Datagram
Protocol), obviously suffer from more packets being lost but deliver packets without a
decrease in performance. Designers of mobile services must consider this trade-off between
performance and reliability.
Proxies
NAT (Network Address Translation) gateways and firewalls are common in fixed networks,
but in wireless networks the majority of the clients are connected to the Internet through a
proxy. Especially peer-to-peer applications like instant messaging do not interact well with
NAT gateways [47]. Problems arising from the use of NAT gateways in mobile networks
include:
Incoming connections to clients are not possible, the client must initiate the connec-
tion
The IP address to which the recipient should reply changes when packets traverse the
gateway, therefore applications that store addresses in the data portion of messages
are unlikely to work with proxies
Applications cannot send reply data to dedicated ports, the ports dynamically allo-
cated by the proxy must be used
Proxies might drop idle connections that are still active in order to free up resources
In order to be usable in mobile networks an instant messaging service must provide mechanisms for allowing messaging through various types of proxies.
3.3.3
27
Mobility
The fact that users can be on the move while using a mobile service also introduces a few
aspects different from fixed environments. These differences are presented below.
Roaming
Roaming is the ability to move freely while maintaining an active connection to a wireless
network. There are two types of roaming: contractual roaming and handover roaming.
Contractual roaming is the ability to use services outside of the network of the home
service provider and still only pay the home service provider. When it comes to designing
mobile services contractual roaming is not a factor.
Handover roaming is a factor that mobile services should consider. Handover roaming itself
comes in two flavors, horizontal handovers and vertical handovers. Horizontal handovers
are the ability to move from one access point to another within the same technology.
As stated in Section 3.3.2 horizontal handovers have an impact for instance on network
delay and on delay jitter. Vertical roaming enables moving between to different types of
technologies, e.g. from UMTS (Universal Mobile Telecommunications Network) to GPRS
or from UMTS to WLAN (Wireless Local Area Network). Vertical roaming might alter
the behavior of a network connection completely as the characteristics of the underlying
technology are changed.
Coverage
Another aspect of wireless networks that is not available in wireline networks is network
coverage. Naturally, coverage is lost when the mobile device is moved outside of the area
covered by the network, but temporary coverage loss is also possible when moving in the
network. Temporal coverage loss usually occurs in closed locations like e.g. tunnels or
elevators. In addition to decreases in performance discussed in Section 3.3.2 coverage loss
often cause disconnections.
A mobile service should be able to cope with users being disconnected unexpectedly,
minimizing the damage inflicted by sudden disconnections. Services preserving user state
and letting users continue a previous session upon login is one example of reducing the
impact of unexpected disconnections.
3.3.4
28
Other
Switching Equipment
Due to the quite extensive range of limitations of mobile devices and mobile networks listed
in the previous sections, users will prefer to use conventional devices and fixed networks
whenever possible. Most users will most likely use a service from their mobile device while
on the move, but then switch to the computer when at home or in the office.
A mobile instant messaging service should be able to manage the frequently changing
device capabilities of users constantly changing equipment and perhaps even support simultaneous sessions from a single user with multiple devices.
Charging
Finally, the success of a mobile service often depends on its cost; if the service is too
expensive it will not be able to compete against other similar services, e.g. mobile instant
messaging cannot compete against short messaging services if it costs much more even
though it comes with more advanced features.
As many operators are likely to charge by the amount of data transferred, optimizing the
amount of data sent by the service not only increases the performance of the service, but
also makes it cheaper to use.
3.4
Standards and Protocols
This section provides an overview of the standards related to mobile instant messaging.
Although the xMS services cannot be classified as instant messaging, their usage is very
similar to instant messaging as described in Section 3.4.1. Section 3.4.2 introduces IMPS,
currently the only instant messaging system designed specifically for mobile environments.
3.4.1
xMS (SMS, EMS, MMS)
Technically none of the xMS messaging services can be seen as instant messaging due to
the lack of presence information. Nevertheless, the usage of these services resembles the
use of instant messaging services very much. Since users carry their mobile devices with
them, their presence rate is much higher than at a fixed computer. As the probability for
receiving a quick reply to a message is considerably higher, the content of xMS messages is
often similar to the content in instant messages, i.e. xMS is often used for short questions
to which an immediate answer is expected. The following subsections give a brief overview
of the xMS messaging services.
29
Short Message Service (SMS)
SMS (Short Message Service) was originally designed and used for service messages, making it possible for operators to send service notifications to subscribers. This explains the
low capacity (140 data octets) and limited functionality (text only) of SMS. The first SMS
message was sent already in 1992, but it took until the end of the 1990’s until the mass
use of the SMS service begun.
At first all messages were mobile terminated, operators using SMS messages to notify
users of waiting voicemail. The launch of support for mobile originated SMS messages,
allowed end users to take an active role and send SMS messages to each other. This
new functionality allowed the creation of interactive services using the SMS technology.
Subscribers adopted this new form of mobile interaction quickly and as shown in Figure
3.1, the popularity of the SMS service has been growing swiftly ever since.
Locationwise SMS is far more popular in Europe and Asia than in North America, where
competing transmission technologies [43] and the Receiving Party Pays (RPP) system [66],
[71] have been slowing down the rollout of SMS.
Enhanced Messaging Service (EMS)
EMS (Enhanced Messaging Service) was the first standardized messaging solution to offer
richer messaging content than SMS. The EMS standard was born in the beginning of year
2000 when 3GPP, the same standardization body that defined SMS, started working on
it. Of the terminal manufacturers, Alcatel, Ericsson, Siemens and Motorola have been
fostering the standard and included EMS support in their terminals. The first EMS
compliant mobile devices became available to customers in mid 2001.
EMS is completely based on SMS technology allowing up to 255 SMS messages to be
chained together as one EMS message increasing the amount of data that can be transported in one message from 140 bytes to about 38KB. EMS supports various contents
including formatted text, animation, polyphonic sounds and color pictures. EMS also
allows combinations of different media types in one message as long as the maximum
message size is not exceeded.
A major advantage of EMS being based on existing SMS technology is that operators do
not need to invest in new infrastructure in order to offer EMS messaging. EMS messaging
is completely transparent to SMS service centers. Practically the only requirement for
EMS messaging is that both the sender and the recipient of an EMS message carry mobile
devices that are EMS compliant.
EMS is often seen as an intermediary step between SMS and MMS. For example, Baskerville
predicts a market share of only 3% for EMS in 2006 while MMS is projected a share of
over 30 %. The supporting forces behind EMS recognize the fact the MMS is a more ideal
30
messaging service for 3G networks than EMS, however they see EMS as a cost-effective
technology that eases the transition to MMS.
Figure 3.2: Global message revenue market share projection for 2006. Source: Baskerville
Multimedia Messaging Service (MMS)
Following EMS, MMS (Multimedia Messaging Service) is the next evolutionary step of
mobile messaging. MMS supports messages with theoretically unlimited size and a by far
richer range of multimedia content than EMS. MMS supports many standard multimedia
formats like JPEG, GIF, MPEG and MIDI, which can be combined in one message using
a presentation language (e.g. SMIL).
The MMS specifications are defined by both 3GPP and OMA (Open Mobile Alliance) in an
effort to achieve worldwide interoperability. As opposed to EMS, which is based on SMS
technology, MMS is a completely new technology. MMS makes use of existing protocols
(e.g. WAP, SMTP, HTTP (Hypertext Transfer Protocol)) and message formats (SMIL,
MIME) as far as possible, but requires operators to invest in new network elements. Table
3.1 summarizes the main differences between SMS, EMS and MMS.
Although many network operators already offer MMS services to subscribers and most
new mobile devices contain support for MMS, the volume of sent messages has so far been
relatively small. Subscribers are still reluctant to use the service as they cannot be sure
that the counterpart has an MMS compliant handset. Assuming the cost of sending MMS
messages is kept reasonable, it is probable that MMS will acquire a significant amount of
the messaging market (see Figure 3.2) as soon as the penetration level of MMS compliant
handsets is high enough for mass use.
31
Table 3.1: Comparison of mobile messaging services [11]
Feature
SMS
EMS
MMS
Media supported
Text only
Formatted text, simple
media formats, e.g.
pictures, animations,
sounds
Multiple rich media formats, e.g. video, audio,
text
Delivery mechanism
Signaling channel
Signaling channel
Data channel
Store-and-Forward
Yes
Yes
Yes
Confirmation of message delivery
Yes
Yes
Yes
Protocols
SMS
specific,
SMPP
SMS specific
WAP and general Internet e.g.
MIME,
HTTP, SMTP
Platform
SMS Center
SMS Center
MMS Server, MMS
Relay, MMS Message
Store,
MMS
User
Agent,
MMS User
Databases
3.4.2
e.g.
IMPS
IMPS (Instant Messaging and Presence Service) is a set of specifications striving to ensure
interoperability in mobile instant messaging. The initiative was started in 2001 by three
leading telecommunication companies, namely Ericsson, Motorola and Nokia. The initiative was originally known as the Wireless Village but has since then been consolidated
into the Open Mobile Alliance (OMA), which is an industry forum for developing market
driven, interoperable mobile service enablers.
In order to minimize interoperability issues, the initiative is open to participation from
industry supporters interested in providing input regarding ongoing specification work.
The aim of IMPS is not only to provide exchange of messages and presence information in
mobile networks, but also to facilitate the creation of gateways to other instant messaging
services. For a detailed evaluation of IMPS as a whole compared to SIMPLE, see Chapter
4.
The first approved version of the IMPS specification was released in February 2002 and
it was followed up by version 1.1 in November 2002. Version 1.2 has been available as a
candidate enabler since February 2003 and will be approved by the end of 2004. Currently
the initiative is working on version 1.3 and a candidate enabler is planned towards the end
of 2004. Although the specification work has been quite rapid, IMPS has been quite slow
to market. It was not until the final quarter of 2003 that the first IMPS compliant mobile
devices were released and only a few operators are currently offering instant messaging
based on IMPS to subscribers. Like MMS, the IMPS service is expected to take off as
soon as the penetration of IMPS capable handsets is high enough.
Chapter 4
Comparison of IMPS and SIMPLE
This chapter contains a comparison of two open instant messaging standards applicable in
mobile environments, namely IMPS and SIMPLE. IMPS is specifically defined for use in
mobile environments and SIMPLE will soon be incorporated into 3G networks as part of
the SIP-based IMS (IP Multimedia Subsystem). Therefore, these two services are without
doubt the top contenders in the mobile instant messaging race.
As IMPS services have not yet been deployed by operators and IMS is not yet available in
commercial wireless networks, measuring the performance of the services using tests was
not possible. Hence, the comparison between the two services had to be performed on
a theoretical basis. Specifications, articles and technical reports related to the area were
utilized. In addition, test results from sub-areas, e.g. studies evaluating the performance
of transport protocols in wireless networks, were considered in the comparison.
The aim of the comparison was to investigate which of the two standards suits the demands
of mobile instant messaging the best. Therefore, the features differing between mobile and
fixed environments listed in Section 3.3 were emphasized in the comparison. However,
some features crucial to both environments, such as security, were also studied.
The comparison was performed between version 1.2 of IMPS and the current (August
2004) specifications of SIMPLE. IMPS version 1.2 is currently a stable candidate enabler
to which no further changes are expected. The final release is planned towards the end
of 2004. Most SIMPLE specifications are still ongoing work available as Internet Drafts.
Nevertheless, the specifications containing the main functionality are in a stable state.
Thus, although neither service is complete it is possible to carry out a fairly thorough
comparison between them.
This chapter is organized as follows: Section 4.1 compares the functionality provided by
the services. Section 4.2 presents and evaluates the architectures and protocols of the
services. The performance and security is investigated in Sections 4.3 and 4.4. The next
two sections, Section 4.5 and Section 4.6, study the interoperability and extensibility of
the services. Finally, Section 4.7 presents the current status and anticipates the future
32
CHAPTER 4. COMPARISON OF IMPS AND SIMPLE
33
trends of the two services.
4.1
Functionality
This section provides an overview of IMPS and SIMPLE functionality. The functionality
is considered from the user’s point of view. Succeeding sections study the technology
behind the functionality in detail.
Table 4.1 displays the support for main instant messaging functionality in IMPS and
SIMPLE. As can be seen there are few differences between the two services. All major
features are available in both services.
Table 4.1: IMPS and SIMPLE functionality
Function
IMPS
SIMPLE
Login and logout
Yes
Yes
Service and capability
negotiation
Yes
No, services and capabilities are not negotiated with a
server. It is up to client to reject unsupported requests
and content types.
User search
Yes
No
Invitations
Yes
Yes
Contact lists
Yes
Yes
Presence subscriptions
Yes
Yes
Presence notifications
Yes
Yes
Update presence
Yes
Yes
Presence authorization
Yes
Yes
Watcher list
Yes
Yes
Watcher notifications
No
Yes
Sending and receiving
instant messages
Yes
Yes
Delivery reports
Yes
Yes
Message blocking
Yes
No, must be implemented in the client
Message composition
indication
No
Yes
Group Messaging
Yes
Yes, but specified by the SIPPING WG
General functions
Presence
Instant Messaging
In IMPS all traffic is directed via an IMPS server before reaching its destination (see
Section 2.6.2). The IMPS service enables clients to inform the IMPS server about supported services, client capabilities etc. This makes it possible for IMPS servers to reject
traffic not supported by the client. Since SIMPLE sends instant messages peer-to-peer,
34
a similar mechanism cannot be implemented. This explains the differences in service negotiation, capability negotiation and message blocking functionality of the two services.
SIMPLE provides the means for clients to reject single messages but mechanisms for deciding which messages to reject, are not part of the specifications. SIMPLE clients can
however implement e.g. message blocking in non-standard ways.
IMPS offers functionality for finding out the IMPS address of a user through a search.
For example, if the real name of the user is known, the IMPS address can be discovered
using the search functionality. SIMPLE does not provide this kind of functionality; the
address of the user must be resolved using other means before a line of communication
can be initiated.
The presence service features provided by the services are similar, except for the lack of
watcher notifications in IMPS. Using watcher notifications a user can find out whenever
another user subscribes to or unsubscribe from the presence information of the user. IMPS
offers the functionality for retrieving a list of current watchers, but real-time notifications
about changes made to the list are only sent in SIMPLE.
Message compositions indications can be used to notify a user as soon as the other party
starts composing a reply to a message. This feature is available in several proprietary
instant messaging systems. SIMPLE offers support for message composition indications,
while IMPS does not.
Group messaging is a feature analogous to chatting, allowing users to join groups and
participate in discussions within the group. IMPS includes support for group messaging.
The SIMPLE working group does not directly offer group messaging. Instead, the SIPPING (Session Initiation Protocol Project Investigation) working group defines a more
general service called conferencing, providing group functionality for any type of media
session. Therefore group messaging can be accomplished by combining conferencing with
SIMPLE messaging sessions. As conferencing is included in the IMS, group messaging will
be available in networks supporting the IMS architecture.
4.2
Technology
This section describes and compares the architectures and protocols utilized by the two
compared services, IMPS and SIMPLE.
4.2.1
Architecture
IMPS
The architecture of the IMPS service is depicted in Figure 4.1. IMPS is based on a clientserver architecture, all traffic sent from a client passes through the server (see Section
35
2.6.2); peer-to-peer messaging is not supported.
Figure 4.1: IMPS architecture [6]
IMPS Server
The IMPS server holds five important elements; the Service Access Point (SAP) and four
service elements. The SAP serves as the interface through which the outside environment
can communicate with the IMPS server. The interface provides IMPS clients, the mobile
core network, proprietary gateways and other IMPS servers with access to the functionality
of the SAP and the service elements. The functionality of the SAP includes:
Authentication and authorization
Service discovery and service agreement
User profile management
Service relay
The functionality specific to instant messaging can be divided into four logical groups.
Each service element comprises the functionality of one such group. Table 4.2 lists the
service elements and their main functionality.
All IMPS servers are required to provide SAP functionality but service elements can be
scattered among several servers; a server is not required to implement all of them. This
36
Table 4.2: IMPS service elements
Service element
Main functionality
Presence
Presence management
Presence subscriptions
Presence authorization
Contact list management
Instant Messaging
Instant message delivery
Access control
Group
Group usage
Group management
Group access control
Content
Content sharing
facilitates the creation of distributed IMPS services, where servers relay requests to the
server containing a particular service element using the Server-Server Protocol (SSP).
IMPS Clients
The IMPS system defines two types of clients, Embedded Clients and CLI (Command
Line Interface) Clients. The Embedded Client can be embedded into several different
environments, e.g. mobile terminals, fixed PC-clients and automated applications. The
Client-Server Protocol (CSP) allows these clients to be fully interoperable despite their
differences. CLI Clients use the text message based Command Line Protocol (CLP) to
communicate with IMPS servers. CLP consists of commands typed by the user and sent
as SMS messages to the IMPS server, which sends an SMS message in reply for the user
to read and interpret. Consequently, CLI Clients need no software except for the ability
to send and receive SMS messages. CLI Clients provide only a subset of the functionality
provided by Embedded Clients.
SIMPLE
Figure 4.2 shows the architecture of SIMPLE. As mentioned previously,
the
SIMPLE specifications are not yet finalized and therefore changes to the architecture,
such as addition or removal of reference points, are possible.
The reference points and their associated communication protocols are summarized in
Table 4.3 and further elaborated on in the following subsections. As can be seen from
the table, protocols providing direct interaction between the server elements are still to
be defined. Some of these undefined reference points are not necessarily needed as server
elements can communicate with each other utilizing reference points used by clients. In
this case a server element acts as a client in order to use the services provided by another
server. For example, a GLMS (Group and List Management Server) can subscribe to
presence information provided by a presence server. Furthermore, several server elements
can be co-located into one physical element, in which case an element has direct access to
37
Figure 4.2: SIMPLE architecture
the information of the other co-located elements.
Table 4.3: SIMPLE reference points
Reference Point
Functions
Protocol
IM-1, IM-2, IM-3
Session signaling between IM elements using the SIP/IP Core
SIP
IM-4
Peer-to-peer messaging
MSRP
IM-5, IM-6
Messaging through IM Servers
MSRP
IM-7
Communication between a Presence Server and an IM Server
Undefined
PRS-1, PRS-2
Communication between a Presence Client and a Presence Server
SIP
PRS-3
Presence information and authorization management
XCAP
GM-1, GM-2
Communication between a Group Management Client and GLMS
SIP
GM-3
Management of groups and lists at the GLMS
XCAP
GM-4
Communication between a GLMS and a Presence Server
Undefined
GM-5
Communication between a GLMS and an IM Server
Undefined
It should be noted that Figure 4.2 is somewhat simplified as the server elements themselves
can consist of several smaller elements that are not required to exist at the same location
either (for an example, see Figure 4.3). However no means for communication between
the sub-elements of the server elements have been defined. In practice, it follows that the
sub-elements usually will be co-located in the same physical entity, similar to the servers
of Figure 4.2.
IM Server
SIMPLE provides two modes for sending instant messages: pager mode and session mode.
38
In pager mode instant messages are sent over SIP using the MESSAGE method extension
[14]. When using session mode messaging, a session is established using SIP, after which
the Message Session Relay Protocol (MSRP) [13] is used for exchanging instant messages
within the session.
Both modes are able to function without any actual server functionality. In this case the
IM Server element of Figure 4.2 simply consists of a regular SIP proxy. When using pager
mode, IM Server elements only route the message to the recipient over IM-1, IM-2 and
IM-3. For session mode messaging, the session is initiated using IM-1, IM-2 and IM-3,
while the actual message session is established over IM-4 using MSRP.
MSRP sessions can also be directed through MSRP relay elements [34] using reference
points IM-5 and IM-6. Currently this is the only case where the IM Server could include extra functionality. For example, a store-and-forward mechanism enabling offline
messaging could be implemented.
Presence Server
By definition a SIMPLE presence server is a physical entity either acting as a presence
agent or forwarding incoming subscriptions to entities that may act as presence agents
[58]. A presence agent is a SIP user agent which manages presence subscriptions and sends
notifications to watchers whenever the presence information of the subscribed presentity is
updated. In order to manage presence subscriptions and notifications the presence agent
needs access to both presence information and presence authorization rules, both defined
as separate entities. As the methods to be used for communicating between these entities
are undefined, most implementations will co-locate all in one physical element, generally
called the Presence Server, as shown in Figure 4.3.
Figure 4.3: SIMPLE Presence Server
Figure 4.3 also illustrates another aspect typical to SIMPLE; on several occasions multiple
39
methods for performing the same function exist. For example, presence information can
be updated either using the SIP PUBLISH method over PRS-1 and PRS-2 or using the
XML Configuration Access Protocol (XCAP) [59] over PRS-3.
GLMS
The Group and List Management Server (GLMS) is responsible for the management of
contact lists, group lists and group access lists. The GLMS allows users to create groups
and to define the users which are allowed access to the created groups. The XCAP protocol
(over GM-3) is generally used to manage the content on the GLMS.
The GLMS might act as a server for ongoing group messaging sessions as well, but group
messaging sessions can also be hosted by other entities, such as dedicated application
servers or the hosts that created the groups.
4.2.2
Protocols
This section presents protocols specific to the IMPS and SIMPLE services. Well-known
protocols such as TCP, UDP or HTTP are not presented although used by the services.
Only protocols enabling the actual functionality of the services are presented.
IMPS
The IMPS architecture and the protocols used for transporting data between the elements
of the architecture are presented in Figure 4.2. This section presents CSP and SSP,
the protocols most essential to the IMPS service. Of the other protocols, CLP is quite
inconvenient to operate and contains only a subset of the functionality of CSP. The Server
Mobile Core Network Protocol (SMCNP) for enabling features such as charging has not
been defined by OMA at all.
Client-Server Protocol (CSP)
The Client-Server Protocol (CSP) provides IMPS clients with access to the IMPS server
and its functionality. The functions provided by the server are used through CSP transactions. A CSP transaction consists of the messages needed to carry out a function,
ordinarily one request and its response. Most CSP transactions are only available within
a CSP session. A CSP session is established when the user logs in to the system and
terminated upon user logout or if the server decides to disconnect the user. CSP sessions
are transport independent, i.e. they remain valid even when the transport connection is
broken, a phenomenon typical to mobile networks as described in Section 3.3.3.
In order to achieve the flexibility needed for CSP to be used in clients varying from
mobile terminals to fixed PC-clients, several different transport bindings have been defined.
Logically a CSP transport binding is divided into two channels: a mandatory data channel
in which all CSP messages are exchanged and a conditional CIR (Connection Initiation
40
Request) channel used to activate the data channel whenever it is not active (Figure 4.4).
This communication model enables a server to communicate with clients behind proxies,
which is a usual situation in mobile networks (see Section 3.3.2)
Figure 4.4: IMPS communication model
The protocol bindings defined for the data channel are WSP (Wireless Session Protocol),
HTTP, HTTPS and SMS, while the bindings for the CIR channel are WAP push over
SMS, WAP push over UDP, SMS, UDP, TCP and HTTP.
CSP data is carried over the network using the XML message format according to the
DTDs (Document Type Definition) specified in [2] and [4]. See Appendix A for examples
of CSP messages. In order to optimize messages for size, CSP also supports the WBXML
(Wireless Binary XML) format [1].
Server-Server Protocol (SSP)
The Server-Server Protocol (SSP) [3] connects IMPS servers with each other. SSP enables
IMPS clients to use IMPS functionality distributed across the network, possibly provided
by different service providers. In addition, SSP enables other instant messaging networks
to communicate with the IMPS network through proprietary gateways.
SSP is transferred using either HTTP or HTTPS over the TCP transport protocol. As
HTTP is an asymmetrical protocol two physical TCP connections are required in order
to provide two-way communication. SSP uses persistent TCP connections for improved
performance.
Equally to the CSP protocol, SSP is also conveyed between network elements in the XML
format. WBXML is not supported by SSP since servers ordinarily communicate with each
other via wireline connections with high bandwidth.
SIMPLE
Session Initiation Protocol (SIP)
The Session Initiating Protocol (SIP) is a signaling protocol used for creating, modifying
and terminating sessions with one or more participants [60]. SIP allows for any kind of
session to be initiated, including IP telephony calls, multimedia conferences and instant
messaging sessions. Sessions created using SIP are peer-to-peer, i.e. the SIP framework
is only used for managing sessions, not for session traffic. This typically results in a SIP
trapezoid shown in Figure 4.5.
User agents are SIP entities able send SIP requests acting as clients (UAC) and respond
41
Figure 4.5: The SIP trapezoid
to incoming requests as servers (UAS). All servers and clients of the SIMPLE architecture
(Figure 4.2) act as user agents.
SIP proxies accept SIP requests from user agents or other SIP proxies and route them
closer to the recipient.
In addition to proxies and user agents, registrars are also important elements in SIP
networks. Registrars accept registrations of address information from other SIP entities.
The registrars store the information in location services which are then used by SIP
proxies when routing messages.
Finally, redirect servers can be utilized to redirect incoming requests to other destinations, e.g. a user could set the SIP phone at work to redirect all calls to the SIP phone at
home.
SIP is very similar to the HTTP protocol [22], utilizing the same request/response transaction model where each transaction consists of a request invoking a particular method
and the responses to the request. The majority of the message and header field syntax is
also derived directly from HTTP.
SIP allows extensions to the protocol to be made in the form of new methods and header
fields. Three extensions of the SIP protocol have a central role in SIMPLE, namely the
event notification extension [56], the pager mode instant messaging extension [14] and the
UPDATE method extension [57]. The event notification extension enables SIP nodes to
be notified when a particular event occurs. The instant messaging extension adds support
for sending instant messages in SIP messages without creating a session. Finally, the
UPDATE method extension provides the means for updating presence information. In
addition, group messaging software may use the REFER method extension [62].
Table 4.4 lists the main SIP methods and their use in SIMPLE.
Message Session Relay Protocol (MSRP)
The Message Session Relay Protocol (MSRP) [13] is an instant message transport protocol defined by the SIMPLE working group. As opposed to pager mode instant message exchange which uses the SIP MESSAGE method, MSRP is a session-based protocol.
MSRP sessions can be setup using any signaling protocol capable of initiating sessions. In
SIMPLE the SIP protocol is naturally used.
42
Table 4.4: SIMPLE usage of SIP methods
SIP method
SIMPLE function
REGISTER
Login/logout, enables the user to be reached by other users
INVITE
Initiating instant messaging and group messaging sessions
REFER
Alternative method for inviting users into ongoing group messaging sessions
BYE
Terminating sessions
SUBSCRIBE
Subscribing to the presence information of other users, watcher information, group
change information etc.
NOTIFY
Notifies subscribers of particular events, e.g. changes to presence information
UPDATE
Updating presence information
MESSAGE
Sending of pager mode instant messages
Like SIP, MSRP is also a text based protocol similar to the HTTP protocol. MSRP is a
fairly simple protocol, only two request methods are needed: the SEND method and the
REPORT method. The SEND method is obviously used for sending instant messages.
MSRP does not limit instant messages to contain only text; any content type can be used.
The REPORT method can be used for receiving delivery reports for sent instant messages.
As MSRP is based on HTTP, it allows for extending the protocol by adding new methods
and header fields. The ’Relay Extensions for MSRP’ specification [34] does exactly that,
adding support for using relay intermediaries to MSRP, which originally is a peer-to-peer
protocol.
XML Configuration Access Protocol (XCAP)
The XML Configuration Access Protocol (XCAP) [59] allows clients to retrieve, modify
and delete XML data stored on a server. Although defined by the SIMPLE working group,
XCAP is a general-purpose protocol which area of usage is not restricted to SIMPLE.
However, XCAP is particularly suitable for the needs of SIMPLE as all data permanently
stored in SIMPLE server elements, such as presence information, watcher information and
presence authority rules, is defined in the XML format.
XCAP provides the means for mapping XML documents and document elements directly
to HTTP URIs (Uniform Resource Identifier). This enables XCAP to manipulate XML
documents stored on a server using normal HTTP primitives. The HTTP GET method is
used for retrieving XML documents or parts of them, the PUT method is used for creating
or modifying documents and the DELETE method can be utilized for deletion of XML
documents.
The XCAP specification in [59] defines a framework for manipulation of XML data. In
addition, each application storing data on XCAP servers comes with application-specific
conventions, e.g. XML schemas and bootstrap URIs, which need to be defined. Therefore
each application using XCAP is required to specify application-specific requirements in an
43
’XCAP Application Usage’ document. For example, an application usage for manipulating
presence information using XCAP is defined in [32].
4.2.3
Summary
As a whole, the architecture of IMPS is more mature than the SIMPLE architecture.
The IMPS architecture is relatively simple; complete instant messaging functionality can
be delivered using only two protocols, CSP and SSP, defining the client-client and the
server-server interfaces clearly and unambiguously.
The SIMPLE architecture is without doubt more complex; numerous reference points are
defined for accessing the service. The functionality has been divided into several small
elements of which each has been defined independently from the others in order to provide
a flexible system. However, although the client-server interfaces of the elements are quite
clearly defined, communication between server elements is mostly undefined. Also, on
several occasions the SIMPLE service provides several alternatives for performing the
same function. While this on one hand improves flexibility, it might on the other hand
increase complexity as server solutions are forced to provide all alternatives in order to
be functional against all kinds of clients. Again, it should be stressed that the SIMPLE
specifications are ongoing work; changes to the current solution are possible.
The protocols on which the network communication of IMPS and SIMPLE relies are very
similar; both services rely on HTTP-like protocols based on the request/response model.
In addition, all data except for the content of instant messages is transferred in the XML
format for both IMPS and SIMPLE. The characteristics of the protocol and data formats
when it comes to performance, security etc. are evaluated in subsequent sections.
4.3
Performance
This section evaluates the performance of IMPS and SIMPLE compared to each other.
Several aspects such as bandwidth usage, delays, processing, coverage loss, proxy traversal
and scalability were studied. As mentioned earlier, the performance comparison is based
purely on theoretical facts, no real tests could be performed due to the lack of deployed
implementations of the services.
4.3.1
Bandwidth Usage
As instant messages usually only contain short strings of text, it might seem unimportant
to optimize them for size. However, in addition to the actual data, instant messages
carry addressing information, session identifiers etc. increasing the size of the message
substantially. Moreover, although 3G networks offer a broad bandwidth, only a fraction
44
of it will be allocated for SIP signaling. Also, it will take long until complete 3G coverage
is reached and until then low-bandwidth technology, such as GPRS, will be widely used.
Message Size
Protocol messages consist of two parts: protocol data and payload data. In order to
optimize the total size of a message, both parts need to be optimized. IMPS messages
have a relatively small protocol part; most information is generally carried as payload
data. SIMPLE messages carry more information in the protocol part of the message and
only the actual instant message or presence information is carried in the payload part.
For optimizing the size of the protocol part IMPS includes a WSP (Wireless Session
Protocol) transport binding. In essence, WSP is a tokenized version of HTTP resulting
in smaller sized messages. For compressing the payload data, IMPS provides support for
the WBXML format. WBXML tokenizes the XML elements of the CSP protocol. As the
XML elements of the CSP protocol have lengthy names, the WBXML format reduces the
size of the payload data significantly. On average the size of a compressed CSP message
is about 25% of the uncompressed message.
SIMPLE SIP messages can be compressed using the SigComp solution [54] as described
in [12]. SigComp compresses both the protocol and the payload part of SIP messages. A
performance evaluation performed by Nordberg et al. in [46] indicates that the message
size can be reduced to approximately 25-50% of the uncompressed size for SIP messages
sent in 3G networks.
By comparing the message sizes of instant messages for both services (see Appendix A
for message examples) it can be noted that sending uncompressed IMPS instant messages
consumes over three times more data than pager mode SIP instant messages. Setting up a
SIMPLE session mode and sending one message requires a little more data than one IMPS
message. Nevertheless, after session mode has been set up, all subsequent SIMPLE instant
messages are over five times smaller than corresponding IMPS messages. Conclusively,
despite IMPS providing a somewhat higher compression rate, SIMPLE messages are still
considerably smaller than IMPS messages.
Finally, the message size can also be affected by reducing the size of presence notifications
received from the presence server. The size of notifications can be decreased using partial
notifications, i.e. the server sends only the changed part of the presence information in
the notification. Both IMPS and SIMPLE includes support partial notifications.
Filtering Rules
The bandwidth usage can also be limited using filtering rules. Clients can use filtering rules
to narrow the amount of events resulting in notifications. Filtering rules can also be used to
45
block instant messages from certain users, thus limiting the amount of data received. IMPS
supports filtering rules for both presence information and instant messaging. SIMPLE only
supports filtering rules for presence information; instant messages cannot be blocked before
arriving at the client due to the peer-to-peer property of SIMPLE.
Signaling
IMPS needs no signaling in order to send an instant message to another user. SIMPLE
needs to setup a session using SIP when using session mode instant messaging, thus introducing data overhead in comparison to IMPS.
Furthermore, SIMPLE presence subscriptions are not permanent, clients must refresh
subscriptions periodically. The length of the period depends on the policy of the presence
server. In comparison, IMPS presence subscriptions are guaranteed to last for the length
of an IMPS session. However, IMPS clients might need to renew subscriptions whenever
they login to the system, creating overhead comparable to SIMPLE presence refreshments.
4.3.2
Delays
Delays and delay jitter are not as important factors in instant messaging as in other realtime services. E.g. when sending voice or video, keeping delays and delay jitter to a
minimum is critical to the quality of the communication. Nevertheless, instant messaging
is a real-time service and if delays grow too high, the user experience deteriorates. Delay
jitter is not a factor in instant messaging since messages are not sent in an uninterrupted
stream.
There are two types of delays affecting user experience: the session setup delay and the
message exchange delay. These are studied in more detail below.
Session Setup
The session setup delay is the amount of time needed for initiating the sending of an
instant message. The delay caused from establishing a data channel to the radio access
network can be neglected here as both services perform the same procedure.
In IMPS, clients create a session with the IMPS server upon logging in to the system, but
sessions are not initiated with recipients of instant messages. Hence there is no session
setup delay associated with the IMPS service.
SIMPLE pager mode messaging generates no session setup delay either. SIMPLE session
mode messaging requires a session to be set up using SIP before the first instant message
can be sent. A minimum of three SIP messages or 2 round-trip times (RTTs) are needed
to complete the setup of a SIMPLE instant messaging session.
46
Message Exchange
The message exchange delay is simply the amount of time elapsed between sending an
instant message and its arrival at the recipient. The following aspects of the services
affect the message exchange delay:
System architecture
Transport protocol
Persistent connections
Message size
In IMPS all data communication with the IMPS server is client-initiated, i.e. the server
can only send data to the client in a reply to a request initiated by a client. The IMPS
server utilizes the CIR channel (Figure 4.4) to trigger requests from clients when needed.
This inflicts an additional RTT to occur between the receiver and the IMPS server for
each message. This is illustrated in Figure 4.6.
Figure 4.6: IMPS message exchange
IMPS recommends but does not require persistent connections to be used between clients
and servers. Since IMPS is based on HTTP, using persistent connections offer significant
performance gains due to the reduced number of connection initiations.
SIMPLE message exchange using session mode is efficient since messages are sent peer-topeer. The protocol for session mode messaging, MSRP, uses the TCP protocol for transport and recommends reusing open connections, thus improving performance in wireless
environments. The efficiency of pager mode messaging also depends on the use of persistent connections; if connections between SIMPLE clients and SIP proxies can be reused,
then messages can be delivered efficiently. In addition to TCP, SIP also supports using
UDP for transportation in which case the bit error rate of the network dictates the performance of pager mode messaging. However, since pager mode messages are sent in the
low-bandwidth signaling channel, session mode messages will usually have a lower message
exchange delay.
4.3.3
Processing
As described in Section 3.3.1, the processing and memory constraints of mobile devices
should be taken into account by mobile services. Both IMPS and SIMPLE offer basic
47
functionality for restricting the size of a single message in order to prevent clients from
running out of memory.
IMPS clients can specify the maximum message size it is able to process in one chunk
during the login procedure. In SIMPLE the MSRP protocol allows sending large messages
in smaller chunks when using session based messaging. For pager mode, instant messages
are restricted to 1300 bytes by the specification.
4.3.4
Coverage Loss
Both the IMPS and the SIMPLE service are able to cope with sudden disconnections
caused by the loss of radio network coverage. Clients of neither service need to re-login
to the system upon a disconnection, only the transport layer connections need to be
reestablished. For session based messaging, SIMPLE clients need to store some information
in order to be able to re-initiate the transport connection upon sudden disconnections,
otherwise a new session must be negotiated.
4.3.5
Proxy Traversal
Mobile networks are usually connected to the Internet via NAT proxies. Therefore, the
ability to communicate through proxies is an important feature of mobile instant messaging
services as it enables a global service, available from both mobile and wireline clients.
IMPS makes use of the CIR channel presented in 4.2.2 in order to traverse proxies. As
all client-server communication is client-initiated and the server can trigger client requests
using the CIR channel, IMPS clients can use the IMPS service through proxies without
problems. The cost of this arrangement is some additional delay to message exchange as
described in Section 4.3.2.
Implementations of SIP as specified in [60] have severe problems with NAT traversal.
The problem stems from SIP proxies sending replies to ports defined in the SIP requests.
RFC 3581 [61] defines a header extension to the SIP protocol solving the problem for
TCP. However, the problem persists for UDP connections and all server-initiated requests.
Several solutions to the problem have been proposed, including [9] and [63], but it will take
long until a standard solution is available in every SIP proxy. SIMPLE services function
perfectly inside mobile networks, e.g. using IMS in 3G networks, but due to the NAT
problems it is currently not possible to create fully functional SIMPLE services spanning
both mobile and wireline networks.
4.3.6
Scalability
By scalability, the system performance when used by a substantial amount of simultaneous
users is meant. Scalability is important as these services are expected to acquire millions
48
of users over time. The architectures of the two compared services provide excellent
scalability. Neither service requires any centralized network elements, enabling data to
be distributed among several servers. By building a network of distributed servers, both
services can serve a vast amount of simultaneous clients.
4.3.7
Summary
Generally, SIMPLE performs better than IMPS when it comes to optimizing bandwidth
usage and delays. IMPS causes no session setup delays, but session mode messaging
enables shorter message exchange delays and smaller messages for SIMPLE.
On the other hand, the mechanisms causing delays in message exchange for IMPS also
enable IMPS messages to traverse NAT proxies without problems. In contrast to IMPS,
SIMPLE currently has severe problems with NAT traversal.
The architectures of both services enable good scalability supporting customer bases of
large scale. The ability to recover from disconnections due to coverage loss is also good
for both IMPS and SIMPLE.
4.4
Security
This section describes the security services provided by the compared instant messaging
systems and evaluates how well the systems are protected against the security threats
listed in Section 2.8.
4.4.1
Security Services
Authentication
IMPS requires user authentication before access to server functionality can be provided.
For user authentication, either a two-way or a four-way access control mechanism can
be used. Using the two-way mechanism, the user sends both the user identifier and the
password in plain text to the server, which either grants or denies access. The four-way
mechanism is a digest authentication based on a challenge sent by the server. The four-way
mechanism supports the following digest schemes: SHA (Secure Hash Algorithm), MD4
(Message Digest Algorithm #4), MD5 and MD6. Server authentication is provided only
when the HTTPS transport binding is used. No mechanisms have been defined explicitly
for end-to-end authentication of instant messages. However, as any MIME type is allowed
for content of instant messages, end-to-end authentication can be accomplished using e.g.
S/MIME (Secure MIME) signatures.
SIMPLE does not enforce clients or servers to be authenticated. However, SIP proxies are
49
required to support authentication mechanisms and to use them whenever requested. SIP
proxies can authenticate clients using a scheme based on the HTTP authentication scheme
[26] while clients can utilize TLS (Transport Layer Security) for server authentication. For
end-to-end authentication, e.g. in session mode messaging, S/MIME signatures can be
applied.
Authorization
Both IMPS and SIMPLE allow clients to specify authorization rules for their own presence
information. In addition, IMPS lets clients specify access rules for instant messages as well,
enabling the server to block messages from unauthorized users.
In IMPS the services to be used are negotiated during the login procedure. Although the
main purpose of the service negotiation is to ensure that clients do not request services
not supported by the server, it can also be utilized to implement service authorization. In
SIMPLE services are not negotiated, therefore service authorization can only be provided
using proprietary solutions.
Accountability
Neither IMPS nor SIMPLE require service elements to create audit trails or logs of transactions. Nevertheless, although not enforced by specifications, most server implementations
traditionally come equipped with some level of accountability features.
Confidentiality
For protecting the confidentiality of protocol messages IMPS clients can utilize the HTTPS
transport binding, assuring that message content is only interpretable by the local IMPS
server. Strangely, IMPS does not enforce end-to-end confidentiality, i.e. even though a
client sends a message over HTTPS to the server, secure delivery from the server onwards
is not guaranteed.
In SIMPLE, TLS can be used to ensure that only trusted elements can read messages.
Using the SIPS addressing scheme described in [60], a SIMPLE client can demand secure
connections to be used along the whole path between the client and the recipient of a
message. For providing end-to-end confidentiality for messaging sessions, encryption using
S/MIME can be utilized if supported by both parties.
Integrity
Message integrity can be ensured in IMPS only when using the HTTPS transport binding and even then the integrity is only guaranteed between the client and the server. In
50
SIMPLE the SIPS addressing scheme can be used to cause TLS to be used between intermediaries, thus providing message integrity. SIMPLE also supports the use of S/MIME
signatures for end-to-end integrity.
4.4.2
Attack Vulnerability
This subsection evaluates how well IMPS and SIMPLE are able to withstand some of the
security threats listed in Section 2.8.
Man-in-the-Middle Attacks
When using two-way authentication in IMPS, an adversary listening to network traffic
can easily learn the password of the user as it is sent in plain text. When using fourway authentication passwords are harder to grab, but as the session identifier assigned
to the created session is sent in plain text in each message, hijacking an ongoing session
is simple. In essence, the HTTPS transport binding is the only mechanism providing
adequate protection against man-in-the-middle attacks. Even when HTTPS is used it
only guarantees secure delivery up to the server, an adversary can snatch and modify
instant messages between the server and the final recipient instead.
SIMPLE specifications do not force server elements to perform authentication of incoming
traffic. Since neglecting authentication allows an adversary to impersonate any other
user, providing authentication is in practice mandatory for SIMPLE systems. In order to
prevent adversaries to read message content, the SIPS addressing format should be used.
For end-to-end security the messages can be both encrypted and signed using S/MIME.
When all these techniques are in use, SIMPLE provides relatively strong protection against
man-in-the-middle attacks.
Replay Attacks
As TSL includes mechanisms for preventing replay attacks, IMPS users are decently protected against replay attacks while using the HTTPS transport. For other transports,
messages can be replayed as long as the session from which the original message was
captured is still active. Also, two-way authentication can be successfully replayed while
four-way authentication cannot.
Like IMPS messages, SIMPLE messages are sufficiently protected against replay attacks
when transported over TSL connections. In order to prevent replay attacks SIMPLE
requires all signed presence notifications to contain timestamps. Similarly, pager mode
instant messaging obligates the usage of the SIP Date-header to defend against replay
attacks.
51
Denial-of-Service Attacks
Instant messaging systems are especially vulnerable to denial-of-service attacks due to the
amplification properties of the presence service; an update of presence information can
result in numerous notifications being sent out.
Although it is never possible to mitigate denial-of-service attacks completely, authenticating incoming requests is one of the most effective means for reducing the probability of
such an attack. As mentioned earlier, IMPS requires user authentication and SIMPLE
provides mechanisms for authenticating both client and server requests.
4.4.3
Summary
When using only the minimum required security services, the level of protection provided
by both IMPS and SIMPLE is too weak to be used in business-oriented environments or
public networks. Fortunately, both services include support for stronger security mechanisms as well.
Overall, SIMPLE comes equipped with stronger security mechanisms than IMPS but the
complexity of the SIMPLE architecture can make it difficult to apply strong security
throughout the whole network. However, the IMS specifications define a security model to
be deployed throughout 3G networks assuring strong security for SIMPLE within mobile
networks. From the SIMPLE point of view, IMS security services are a combination of
SIMPLE security and 3GPP security. For further information about the IMS security
model and 3GPP security, see [53] and [45].
IMPS provides only two security mechanisms, authentication and the HTTPS transport
binding. A server provider can provide a secure service within a closed network by enforcing the use of both these mechanisms. However, users of the service have no means
to request end-to-end security for messages. Consequently, the service is vulnerable to
security breaches in networks without common security policies, such as a global IMPS
service in the Internet.
4.5
Interoperability
The IETF IMPP working group produces standards aiming to provide interoperability
between instant messaging systems. IMPP and the requirements it places on instant
messaging systems for interoperability were described in Section 2.5.1.
SIMPLE does conform to the IMPP specifications in full, facilitating the creation of interoperability gateways between SIMPLE and other IMPP compliant instant messaging
systems.
IMPS conforms to all other IMPP requirements except for the PIDF presence format [65].
52
The lack of PIDF support does not prevent gateways from being created, but the gateways
needs to translate the IMPS presence format to the PIDF format and vice versa. This
means that presence information cannot be preserved end-to-end, which has implications
especially on security since signed or encrypted presence information cannot pass through
gateways.
The OMA Presence & Availability Working Group is currently working on adding PIDF
support to the presence architecture meaning that IMPS is likely to be fully IMPPcompliant in the future. Furthermore, the OMA Messaging Working Group is in the
process of defining gateway functionality for connecting IMPS and SIMPLE networks
together.
4.6
Extensibility
As instant messaging is still a young service, it is subject to changes as instant messaging
matures over the years. Consequently, extensibility is an important characteristic in the
comparison of IMPS and SIMPLE.
IMPS protocols are largely based on the XML format. New transactions and extensions to
existing transactions can easily be added to the protocols using XML Namespaces [10]. In
addition, all IMPS protocols are version-numbered; a new protocol version can be released
when major changes to existing functionality are needed. In IMPS, protocol versions are
usually not backwards compatible, but XML extensions are.
SIMPLE also utilizes the XML format, enabling existing data formats to be extended
easily. For example, SIMPLE defines several extensions to the XML based PIDF presence
format. However, in contrast to IMPS which protocols are completely defined in XML,
much of the SIMPLE functionality is provided by HTTP-like protocols such as SIP and
MSRP. Both SIP and MSRP can be extended with new methods and header fields. In fact,
as described in Section 4.2.2 SIMPLE is based upon SIP extensions. SIMPLE protocols,
such as MSRP and XCAP, are not versioned which places limits on the amount of changes
that can be made to the protocols.
Finally, when it comes to layer independency IMPS does not depend on underlying protocols, making it possible to change the transport binding without affecting IMPS functionality. SIMPLE on the other hand is tightly coupled with SIP, meaning that all changes to
the SIP protocol might have an impact on SIMPLE as well.
4.7
Current Status and Future Trends
This section presents the current status and future trends of the compared services.
4.7.1
53
Industry Support
The main founders of IMPS (known as Wireless Village at the time), Ericsson, Motorola
and Nokia are the main forces behind the service. Each of these companies has mobile
terminals with IMPS support on the market today. In addition, around 20 companies are
currently offering IMPS client and server software. No free IMPS solutions have emerged
up to date.
As mentioned in Section 2.5.2, SIP and SIMPLE are supported by several major information technology players, such as Microsoft, IBM and Yahoo. There are numerous commercial and free SIP implementations available, a quite comprehensive list can be found
in [31]. Of all SIP implementations around 15 include SIMPLE functionality as well.
However, since the SIMPLE specifications are ongoing work, only a few implementations
include newer features such as session mode messaging and XCAP.
4.7.2
Service Maturity
Of the two compared services, IMPS is without doubt the more mature. IMPS is ready
to be taken into use immediately; several terminals already include IMPS client software
and IMPS server software is available on the market as well. However, there is a notable
shortage of deployed IMPS services. Few network operators provide IMPS services and
although mobile IMPS clients are able to function with public IMPS servers as well,
currently only one public server, Yamigo [72], is known.
As mentioned earlier, parts of the SIMPLE specifications are still ongoing work, e.g. major
changes were made to the MSRP protocol enabling session mode instant messaging as late
as July 2004. The current deadline for the SIMPLE working group is set at September
2004, but work is expected to continue during 2005 as well.
4.7.3
Future Trends
Although IMPS is ready for deployment, network operators have initially been slow to
introduce mobile instant messaging, evidently in the fear of losing SMS revenues. However,
due to the superior functionality provided by mobile instant messaging, a few operators
deploying instant messaging services will probably force the rest to follow in order to retain
their customer bases.
As more mobile handsets featuring support for IMPS becomes available, the IMPS service
will start gaining momentum. Since the deployment of IMS, which enables SIMPLE to
be used in mobile networks, is still a few years away IMPS is expected to attain an early
lead in the mobile instant messaging race.
The introduction of IMS into mobile networks makes SIP and consequently SIMPLE hot
topics in the wireless world. As instant messaging based on SIMPLE is part of IMS,
54
deploying IMS automatically makes the SIMPLE service available to mobile users.
As both standards are interoperable and OMA currently is defining a gateway for connecting IMPS and SIMPLE together, it is probable that both services will co-exist in the
future as opposed to one of the services fading away completely.
Chapter 5
Implementation of IMPS CSP
Protocol
As part of this thesis, one protocol of the IMPS service, namely the CSP protocol (Client
Server Protocol) was implemented. The CSP protocol enables communication between an
IMPS client and an IMPS server (see Figure 4.1 in Section 4.2). For an overview of the
CSP protocol, see Section 4.2.2. Both the client and the server part of the protocol were
implemented. For the client, the implementation consists of an application programming
interface (API) on which e.g. a client equipped with a user interface can be built. The
server is a fully functional implementation.
The reason for choosing to implement the CSP protocol of the IMPS service is quite
obvious. A CSP compatible IMPS server can provide a fully functional IMPS service to
all CSP compatible clients subscribed to that particular server. Of course, the SSP (Server
Server Protocol) is needed to allow communication between users of separate servers, but
a functional service cannot be based on SSP only. The CLP (Command Line Protocol)
protocol is based on text messages and supports only a subset of the features supported by
CSP. CLP will primarily be used in mobile devices not supporting packet-switched data
transfer; the majority of new mobile devices supporting IMPS will base their clients on
the CSP protocol.
In the time frame of this thesis only one protocol could be implemented and as the CSP
protocol forms the basis of the IMPS service it was chosen. The next logical step after producing a fully functional CSP implementation would be to implement the SSP protocol,
which not only provides inter-domain communication but also enables distributing services across multiple servers and connecting other instant messaging networks with IMPS
through gateways.
This section is organized as follows: Section 5.1 presents the requirements of the software.
The design of the software is depicted in Section 5.2. The solutions used in the implementation and the problems arising during the implementation phase are described in Section
55
CHAPTER 5. IMPLEMENTATION OF IMPS CSP PROTOCOL
56
5.3.
5.1
Requirements
Version 1.2 of the CSP protocol was chosen for the implementation. Although not yet
finalized, no further changes are expected to version 1.2 before its final release before
the end of 2004. This section presents the requirements set upon the implementation in
general, as well as the requirements imposed by the protocol specifications.
5.1.1
Overall Requirements
To ensure that the implementation would be both easy to use for end-users and simple
to maintain and expand for software developers, a list of high-level requirements was
produced:
Extensibility
– Easy addition of unimplemented CSP functionality
– Easy addition of additional transport bindings
– Easy addition of new protocol versions
Clear, maintainable structure
Multi-platform support (Windows, Linux, Solaris, ...)
High performance
As not all features of the CSP protocol were to be implemented (see Section 5.1.2), the
ability to add missing features to the solution later on was considered important. Since new
protocol versions are under constant development, the solution should also be extensible
enough to allow integration of these into the software.
The structure of the software should not only provide extensibility, a clear structure easy
to comprehend for developers new to the solution was also required.
Another requirement was not to restrict the solution to any particular environment, but
rather to make sure that the solution is applicable in a broad range of different environments with no or only minor changes.
Finally, as the client library was to perform well in environments with limited resources
and a scalable server solution was desired as well, the performance aspect of the system
could not be overlooked. However, the clarity of the design was given a higher priority,
thus no performance optimizations decreasing the comprehensiveness of the system were
to be made.
5.1.2
57
CSP Protocol Requirements
The CSP Static Conformance Requirement document [5] lists the features of the CSP
protocol version 1.2, specifying which features are mandatory to implement and which
are optional. As described in Section 4.2.1, the functionality of the CSP protocol can be
divided into five larger groups (see Table 5.1). Of these groups only the SAP is mandatory to implement. However, creating a service consisting of only the SAP functionality
would not be meaningful since this merely provides users with the ability to login and
logout of the service. Therefore more functionality was needed in order to build a usable
system. However, the time frame of the project also placed constraints on the amount of
functionality that could be included.
Table 5.1: Implemented CSP requirements
Functionality
Requirement
Implemented
Implemented
sub-elements
Service Access Point
Mandatory
Yes
Mandatory
Instant Messaging Service Element
Optional
Yes
Mandatory
Presence Service Element
Optional
Yes
Mandatory + contact list management and updating presence
information
Group Service Element
Optional
No
Content Service Element
Optional
Yes
Mandatory
As the two primary elements of instant messaging are presence information and message
exchange, both the instant messaging service element and the presence service element
were to be implemented. The shared content service does not require much effort to
implement; therefore it was chosen for implementation as well. As required, all mandatory
elements of the selected service elements were to be implemented. In addition, contact list
management and the ability to update presence information, which are optional features of
the presence service element were also chosen for implementation as these were considered
to be essential parts of a presence service.
5.2
Design
The CSP protocol was described in Section 4.2.2. This section presents the design of the
CSP protocol implementation. The tools utilized in the design are described in Section
5.2.1. Sections 5.2.2 and 5.2.3 describe the design of the IMPS client and the IMPS server,
respectively.
5.2.1
58
Tools
Unified Modeling Language (UML)
The Unified Modeling Language (UML) is a notational language for specifying, visualizing
and documenting models of software. UML is especially suitable for designing objectoriented software. UML was utilized extensively during the design, the entire design of
the system being documented using UML. Several of the standard diagram types specified
within UML were used, in particular use-case diagrams, package diagrams, class diagrams
and sequence diagrams [24].
Microsoft Visio
Microsoft Visio is a tool for creating business and technical diagrams. The tool includes
support for a wide variety of different diagram types, e.g. organizational charts, flow
charts, database models and software program planning. For software program planning
Visio supports several UML diagram types, which made it a suitable tool for creating the
design diagrams of the CSP implementation.
5.2.2
CSP Client
The design of the CSP client library is clarified by the UML class diagram of Figure 5.1.
Figure 5.1: Architecture of the CSP client library
59
The ImpsClient and CspReceiver classes form the application programming interface
(API) that is visible to the end-user of the library. The ImpsClient class provides methods
for configuring and initializing the client. Client-initiated messages are also sent using the
ImpsClient class. The CspReceiver class contains callback methods that are invoked when
the client receives server-initiated CSP messages. CspReceiver contains stubs for the callback methods; for non-default behavior these methods shall be overridden by applications
using the library. The subsections below provide more detailed descriptions of how CSP
messages are sent and received using the CSP client library.
When it comes to the internals of the library, the TransportHandler class is the main controller, directing messages to their correct destination class. By having classes implement
the CIRTransport or the Transport interface, support for additional transport bindings for
CIR and data channels can easily be added to the client, thus fulfilling the requirement
listed in Section 5.1.1.
Sending CSP Requests
Messages are sent using the sendMessage method of ImpsClient:
CspMessage *sendMessage(const CspMessage &request)
The method takes the CSP request to be sent as an input parameter and returns the
resulting CSP response message as a return value. The CspMessage class is the base class
for CSP messages, containing features shared by all CSP messages. All CSP messages are
subclasses of CspMessage as shown in Figure 5.2.
Figure 5.2: CSP message tree
60
Receiving CSP Requests
The library invokes the callback methods of CspReceiver upon reception of messages initiated by the IMPS server. These callback methods will be handed the incoming message
as the first parameter, while the second parameter contains a response message to be filled
by the method.
void handleMessageNotification (const MessageNotification &req, StatusMessage &res)
For example, the implementation of the handleMessageNotification -method above would
examine the received message notification and produce a status message to be sent back
to the IMPS server.
5.2.3
CSP Server
The architecture of the server is depicted in Figure 5.3, the UML packages representing
the logical components of the system.
Figure 5.3: Server architecture
Table 5.2 below describes the primary tasks of each logical component in brief.
61
Table 5.2: System component tasks
Component
Function
Transport
Handles all data sent or received via the network interface over the supported
transport bindings.
XML Parser
Parses raw XML data filling the data into abstract data types derived from
the CSPMessage class (see Figure 5.2).
CSP Server Controller
Links the different components of the system together. Also performs regular
tasks, such as cleaning up expired sessions etc.
Validator
Validates aspects that are common to all messages, e.g. verifies that the
session identifier of the message is valid.
Transaction Handler
Creates and executes Transaction objects performing the actions needed to
fulfill each CSP request.
APIs
Provides access to the data of the server. For example, all presence subscriptions of a particular user can be fetched using the Presence API.
Data Storage
Contains the mechanisms needed for storing the permanent data of the system.
Transactions
All logic for fulfilling CSP requests is contained in Transaction objects. Transaction
objects are instances of classes implementing the Transaction interface shown in Figure
5.4. The Transaction interface enables the Transaction Handler to create and execute
a certain CSP transaction based on the type of CSP request. A Transaction object
examines the received CSP request, carries out the procedures needed to fulfill the request
and creates a CSP response message to be sent back in reply.
Figure 5.4: The Transaction interface
Some CSP transactions endure for several message exchanges between the client and the
server. In this case Transaction objects are stored on the server while waiting for further
messages from the client. Then the Transaction Handler retrieves and resumes execution
of the previously created Transaction object.
In order to clarify the operation of the server, the UML sequence diagram in Figure 5.5
shows the flow of control during its primary task, responding to incoming requests.
62
Figure 5.5: Flow of control for incoming messages
Adding New Functionality
According to the requirements of Section 5.1.1, addition of new transactions to the server
was made as simple as possible. The process is described below:
1. Creation of abstract data types (CSPMessage) for the messages of the new transaction
2. Addition of support for the new messages to the XML parser
3. Creation of a Transaction class for performing the logic related to the transaction
4. Registering the new Transaction with the Transaction Handler
In essence, creating a few classes derived from existing base classes and registering these
with the server is all that is needed; no changes to the main flow of the server are needed
at all.
Similarly, many aspects are hidden behind common interfaces allowing for easy addition
and changing of system parts. For example, new transport bindings can be added and the
data storage component can be changed without affecting the rest of the system at all.
5.3
Implementation
This section describes the solutions used and the problems encountered during the implementation of the CSP protocol. First, the tools and libraries utilized in the implementation
are presented. Then problems arising in during the implementation phase are discussed.
Finally, improvements that could be done in the future are identified.
5.3.1
63
Programming Language
Both the server and the client library were written in the C++ programming language. An
alternative object-oriented language would have been the Java programming language. As
C++ code generally is more efficient and takes less space than Java code, it was considered
more suitable than Java especially for mobile devices, which are one possible environment
of the CSP client. Furthermore, since there would be quite an amount of shared code
between the client library and the server it was sensible to implement both using the same
programming language.
5.3.2
Tools
Microsoft Visual Studio 6.0
The program code and binaries of the CSP protocol implementations were produced using
the Microsoft Visual Studio 6.0 application development suite. However, no Windowsspecific features were utilized in order to make the code compilable for as many platforms
as possible according to the requirements of Section 5.1.1.
5.3.3
Software Libraries
Xerces XML Parser
Version 2.5.0 of the Xerces C++ XML parser was used the produce the XML parsing
module of the system. The Xerces library provides for both parsing and validation of XML
structures. As Document Type Definitions (DTD) for the CSP protocol were provided in
the specifications ([2], [4]), Xerces was able to validate incoming XML messages based on
the DTDs, thus reducing the amount of code needed to be written.
The Xerces API provides access to XML data using both SAX (Simple API for XML)
and DOM (Document Object Model). Since SAX surpasses DOM when it comes to speed
and memory consumption [25], it was seen as the best choice considering that the client
library might be executed in environments with limited resources.
Celtius HTTP API
Celtius HTTP API for C++ is a powerful HTTP library for use in both client and server
applications. As the library conforms to Wireless Profiled HTTP specifications it is perfectly applicable in both wireless and wireline environments.
In order to implement the HTTP transport binding of the CSP protocol, the CSP client
library utilizes the HTTP client that is part of the Celtius HTTP API while the CSP
server relies on the HTTP server support included in the same library.
5.3.4
64
Problems
During the creation process of the CSP protocol no severe problems that would have
suspended the flow of work were encountered. As version 1.2 is the third release of the
CSP protocol, most principal elements have been thoroughly reviewed and the protocol is
rather stable as a whole.
Still, there are some ambiguities in the specifications especially when handling special
cases. For example, management of presence subscriptions in cases where users subscribe
or unsubscribe to contact lists is not clearly described in the specifications. Also, reconnecting to a previous session is not defined in an unambiguous fashion. The implementation resolves these uncertainties by applying the solution that appears most reasonable.
This does however not guarantee complete interoperability.
Another minor problem was the lack of other implementations against which the implementation could have been tested. IMPS clients are currently available in a few mobile
devices, but these clients are still based on previous versions of the CSP protocol. Furthermore, network operators are still to deploy IMPS services and Internet IMPS servers
supporting version 1.2 of the CSP protocol are not available either. The main advantage
of testing the software against other implementations of the same protocol would have
been the ability to resolve the kind of ambiguities mentioned in the previous paragraph.
5.3.5
Future Work
Although the created CSP implementation fulfills most of the mandatory protocol requirements, much of the optional functionality, such as access control, invitations and user
search, is not available. Also, the group messaging service element was not implemented
due to the limited time frame of the project. In order to create a richer implementation,
these features could be added in the future.
Other possible improvements for the future include the addition of support for new transport bindings as well as incorporating support for other versions of the CSP protocol into
the implementation.
Finally, an implementation of the IMPS Server-Server Protocol (SSP) would combined
with the CSP implementation provide a complete IMPS service.
Chapter 6
Discussion and Conclusions
Section 3.3 presented a number of characteristics of mobile environments that deviate
from the corresponding characteristics of wireline environments. Two instant messaging
systems, IMPS and SIMPLE, were compared in Chapter 4, the comparison emphasizing
the characteristics of mobile environments. Furthermore, the design and implementation
of the IMPS CSP protocol was introduced in Chapter 5. Thus, all the objectives listed in
Section 1.1 were fulfilled.
The remainder of this chapter summarizes the results of the comparison and the implementation work in Sections 6.1 and 6.2. Conclusions from the results are drawn in Section
6.3. Finally, the significance of the results and future work to be done are considered in
Sections 6.4 and 6.5.
6.1
Comparison of IMPS and SIMPLE
As IMPS is specifically defined for usage in mobile environments and the IP Multimedia
Subsystem (IMS) brings SIMPLE to forthcoming 3G networks, these two services are the
top alternatives for mobile instant messaging.
IMPS is a more mature service than SIMPLE. IMPS version 1.2 is nearly finalized and
version 1.3 is already being defined. SIMPLE has not yet reached standard status and
parts of the service are still ongoing work. However, the main elements of SIMPLE are
ready and the service should be adopted as an IETF standard in 2005.
The functionality of both services is very similar from a user’s point of view, but the techniques used to provide the functionality differ considerably between the services. IMPS
is based on a rather simple architecture where all client communication passes through
servers. SIMPLE on the other hand is a fairly complex solution which relies on SIP for
much of its functionality but other protocols such as XCAP and MSRP are also utilized.
The fact that SIMPLE provides two completely different messaging modes, pager mode
65
CHAPTER 6. DISCUSSION AND CONCLUSIONS
66
and session mode, only adds to the complexity. Despite their differences, both architectures allow for excellent scalability as functionality and users can be distributed among a
multitude of servers.
Both services utilize techniques for optimizing the performance in mobile environments.
Overall, SIMPLE is slightly more efficient than IMPS when it comes to bandwidth usage
and delays. Performance-wise, the most notable flaw in SIMPLE is the inability to traverse
proxies. This affects the applicability of the service since a global service cannot be created.
IMPS is able to handle proxy traversal without problems.
SIMPLE includes mechanisms for providing the service with relatively strong security.
Due to the complexity of the SIMPLE architecture, applying an even level of security
throughout a network requires a great deal of cooperation between network administrators.
IMPS provides sufficient security only between the client and its local server, end-to-end
security can not be requested by clients and is therefore not guaranteed in all networks.
Since the IMPS protocols are completely based on XML and function on top of several different transport bindings, IMPS qualifies as an extensible and flexible solution. SIMPLE
also utilizes the XML format, but the tight coupling with the SIP protocol reduces flexibility to an extent.
Finally, both services are built based on the requirements formulated by the IMPP working
group, thus enabling good interoperability with other instant messaging systems. However,
IMPS does not support the PIDF presence format, whereas SIMPLE is fully compliant
with IMPP.
6.2
Implementation of IMPS CSP protocol
The implementation of the CSP protocol of the IMPS service was successfully completed
according to the plan and the requirements set upon the implementation were fulfilled.
Minor problems were caused by ambiguities in the specifications. In addition, the lack of
other similar implementations complicated interoperability testing slightly.
6.3
Conclusions
Tables 6.1 and 6.2 list the main advantages and disadvantages of the compared services.
The rest of this section presents the conclusions drawn from the results of the comparison.
67
Table 6.1: Advantages and disadvantages of IMPS
Advantages
Disadvantages
Simple architecture
Security
Scalability
Lack of charging protocol
Extensibility
Proxy traversal
Table 6.2: Advantages and disadvantages of SIMPLE
Advantages
Disadvantages
Scalability
Complex architecture
Interoperability
Tightly coupled with SIP
Security
Proxy traversal
Efficiency
IMPS is a simple solution that is easy to deploy
The simple architecture of IMPS makes it possible for service providers to take the service into use without great efforts. In the simplest case, the service provider only needs to
deploy one IMPS server. By updating the server with addresses of other servers, communication between users of different service providers or distributed services can be enabled.
As a range of different bearers can be used to access the IMPS service, most service
providers already have the infrastructure needed to deploy the service. IMPS lacks charging functionality; if service providers intend to charge per sent message, then a proprietary
solution must be utilized.
SIMPLE is a complex solution that requires effort to deploy
As opposed to IMPS, the architecture of SIMPLE consists of several distinct elements
communicating using numerous different protocols and data formats. This alone makes
deploying SIMPLE far from effortless. In addition, a functioning SIP network is needed
as a prerequisite for building a SIMPLE service. The SIP-based IMS standard brings
multimedia services, including SIMPLE, to 3G networks. IMS also includes charging
functionality which enables service providers to choose from different charging schemes for
instant messaging. Although deploying IMS and SIMPLE requires resources from service
providers, the amount of new services enabled by IMS should pay back the effort over
time.
68
SIMPLE provides the performance and security needed for business-oriented
services
The combination of SIP and peer-to-peer messaging provides SIMPLE with good performance considering the demands related to mobile instant messaging services. Both
bandwidth usage and messaging delay can be optimized for usage in mobile environments.
Additionally, security issues have not been neglected in the design of SIMPLE. All protocols used in SIMPLE come equipped with security mechanisms strong enough to eliminate
most security threats. All in all, the level of performance and security is high enough for
using SIMPLE for business-oriented services.
IMPS lacks in security
Although the performance of IMPS in mobile environments is up to par with the requirements for mobile environments, IMPS fails to meet some expectations when it comes to
security. A service provider can create a secure service in a closed network by having
all servers accept only secure connections. However, in larger networks with no common
security policy, end-to-end security cannot be guaranteed. In such networks, a mechanism
allowing clients to request that a message should be rejected in case it cannot be delivered
securely would be needed. Unfortunately, IMPS lacks this kind of mechanism.
IMPS can be used to implement a global service spanning both wireline and
wireless networks
IMPS includes mechanisms allowing servers to communicate with clients even if the two are
separated by a proxy. Although the solution for proxy traversal adds some extra delay to
server initiated messages, the advantage of the solution easily outweighs the disadvantages.
While most mobile clients and many fixed PC clients are connected to the Internet through
proxies, the proxy traversal ability of IMPS makes communication between them possible.
This enables creating a global service on the Internet, to which users can connect using
both mobile and fixed clients.
SIMPLE has problems traversing proxies
SIMPLE has severe problems traversing proxies. The difficulties are caused both by the
SIP protocol and by peer-to-peer sessions. Several independent solutions to the problem
have been proposed, all adding to the complexity of the service. So far no solutions for
solving the problem completely and efficiently have been standardized. SIMPLE functions
well inside mobile networks or intranets, but connecting mobile network users with Internet
users is currently not possible.
69
Both IMPS and SIMPLE are applicable in mobile environments
All in all, the comparison confirmed that IMPS and SIMPLE conform to the requirements
set forth by mobile environments. Both IMPS and SIMPLE feature numerous optimizations for improving the suitability of the services in mobile environments. Of course, both
services have their strengths and weaknesses, against which own requirements should be
compared before selecting a mobile instant messaging solution.
6.4
Significance of the Results
This thesis strives to bring new information to the domain of mobile services by studying
the limitations placed on mobile services and by evaluating the applicability of two mobile
instant messaging services with these limitations in mind. Although one service could not
be declared superior to the other, this thesis provides an overview of the advantages and
disadvantages of both services and an assessment of the applicability of the services in
mobile networks.
6.5
Future Work
As the functionality of the next version of IMPS is already being defined and many parts
of the SIMPLE specifications are not finalized, updates and improvements will be made
to both the compared services in the future. These changes can affect the validity of the
results of the comparison. Therefore, the comparison should be kept up to date as the
services evolve.
As the comparison was carried out on a theoretical basis, performing tests in real mobile
networks would also be of interest in the future.
Furthermore, the implementation of the IMPS CSP protocol could be broadened to include
more functionality, such as access control and group messaging.
Bibliography
[1] Open Mobile Alliance.
Client-Server Protocol Binary Definition and Example,
Version 1.2, February 2003. Available at: http://member.openmobilealliance.
org/ftp/public documents/MWG/IM/Permanent documents/OMA-IMPS-WV-CSP
WBXML-V1 2-20030221-C.zip [referred to 30.8.2004].
February 2003.
Presence Attribute DTD and Examples, Version 1.2,
Available at:
http://member.openmobilealliance.org/ftp/
public documents/mwg/IM/Permanent documents/OMA-IMPS-WV-CSP PA DTD-V1
2-20030221-C.zip [referred to 30.8.2004].
[3] Open Mobile Alliance. Server-Server Protocol Semantics Document, Candidate Version 1.2, February 2003. Available at: http://member.openmobilealliance.org/
ftp/public documents/MWG/IM/Permanent documents/OMA-IMPS-WV-SSP-V1
2-20030221-C.zip [referred to 30.8.2004].
Client-Server Protocol DTD and Examples, Candidate
Version 1.2, March 2004. Available at: http://member.openmobilealliance.org/
ftp/public documents/mwg/IM/Permanent documents/OMA-IMPS-WV-CSP DTD-V1
2-20040317-C.zip [referred to 30.8.2004].
[5] Open
Mobile
quirement,
Alliance.
Client-Server
Candidate Version 1.2,
Protocol
March 2004.
Static
Conformance
Available at:
Re-
http:
//member.openmobilealliance.org/ftp/public documents/mwg/IM/
Permanent documents/OMA-IMPS-WV-SSP SCR-V1 2-20040427-C.zip
[referred
to 30.8.2004].
[6] Open Mobile Alliance. System Architecture Model, Candidate Version 1.2, May 2004.
[7] D. Atkins and G. Klyne. Common Presence and Instant Messaging (CPIM): Message
Format (RFC 3862). The Internet Society, August 2004.
[8] AT&T. Getting The Most From Your Favourite Gizmo ... The Telephone, May 2004.
Available at: http://www.att.com/news/item/0,1847,13059,00.html [referred to
30.8.2004].
70
BIBLIOGRAPHY
71
[9] G. Bajko, B. Bertenyi, and K. Kiss. Multimedia Sessions Between 3G Wireless and
Internet Users. In IEEE International Conference on Communications, 2001, pages
435–439, June 2001.
[10] T. Bray, D. Hollander, A. Layman, and R. Tobin. Namespaces in XML 1.1. World
Wide Web Consortium, February 2004.
Available at: http://www.w3.org/TR/
xml-names11/.
[11] S. Buckingham. Data on MMS. Mobile Lifestreams, November 2001.
[12] G. Camarillo. Compressing the Session Initiation Protocol (SIP) (RFC 3486). The
Internet Society, February 2003.
[13] B. Campbell,
Protocol.
R. Mahy,
and C. Jennings.
The Message Session Relay
Internet draft, Internet Engineering Task Force, August 2004.
Work in progress,
Available at:
http://www.ietf.org/internet-drafts/
draft-ietf-simple-message-sessions-08.txt [referred to 30.8.2004].
[14] B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, and D. Gurle. Session
Initiation Protocol (SIP) Extension for Instant Messaging (RFC 3428). The Internet
Society, December 2002.
[15] I. Chlamtac and J. Redi.
Mobile Computing: Challenges and Potential.
In
Encyclopedia of Computer Science, 4th Edition. International Thomson Publishing, 1998. Available at: http://www.jasonredi.com/papers/mobile computing
summary distrib.pdf [referred to 30.8.2004].
[16] The Jabber Community. Brief chronology of activity related to Jabber and XMPP in
the IETF standards process. Available at: http://www.jabber.org/ietf/history.
php [referred to 30.8.2004].
[17] The Jabber Community.
The Instant Messaging Standards Race: Comparing
XMPP/Jabber and SIP/SIMPLE, May 2003.
[18] International Engineering Consortium. Instant Messaging. Available at: http://
www.iec.org/online/tutorials/instant msg/ [referred to 30.8.2004].
[19] M. Day, S. Aggarwal, G. Mohr, and J. Vincent. Instant Messaging / Presence Protocol
Requirements (RFC 2779). The Internet Society, February 2000.
[20] M. Day, J. Rosenberg, and H. Sugano. A Model for Presence and Instant Messaging
(RFC 2778). The Internet Society, February 2000.
[21] H. Elaarag. Improving TCP Performance over Mobile Networks. ACM Computing
Surveys, 34(3):357–374, September 2002. ACM Press.
BIBLIOGRAPHY
72
[22] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, Masinter L., P. Leach, and T. BernersLee. Hypertext Transfer Protocol – HTTP/1.1 (RFC 2616). The Internet Society,
June 1999.
[23] G.H. Forman and J. Zahorjan. The Challenges of Mobile Computing. Computer,
27(4):38–47, 1994.
[24] M. Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language.
Addison-Wesley Longman Publishing Co., Inc., 2003.
[25] S. Franklin. XML Parsers: DOM and SAX Put to the Test, February 2001. Available
at: http://www.devx.com/xml/Article/16922/0/page/1 [referred to 30.8.2004].
[26] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and
L. Stewart. HTTP Authentication: Basic and Digest Access Authentication (RFC
2617). The Internet Society, June 1999.
[27] D. Greene and D. O’Mahony. Instant Messaging & Presence Management in Mobile
Ad-Hoc Networks. In Second IEEE Annual Conference on Pervasive Computing and
Communications Workshops, pages 55–59, March 2004.
[28] A. Gurtov. Making TCP Robust Against Delay Spikes. Technical Report Series
of Publications C, No C-2001-53, University of Helsinki, Department of Computer
Science, November 2001.
[29] N. Hindocha. Threats to Instant Messaging. Technical report, Symantec Security Response, October 2002. Available at: http://www.symantec.com/avcenter/
reference/threats.to.instant.messaging.pdf [referred to 30.8.2004].
[30] H. Inamura (Editor), G. Montenegro (Editor), R. Ludwig, A. Gurtov, and S. Khafizov.
TCP Over Second (2.5G) and Third (3G) Generation Wireless networks (RFC 3481).
The Internet Society, February 2003.
[31] iptel.org. SIP Products. Available at: http://www.iptel.org/info/products/
[referred to 30.8.2004].
[32] M. Isomäki and E. Leppänen.
An Extensible Markup Language (XML) Con-
figuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents.
Internet draft, Internet Engineering Task Force, June 2004.
Work in progress,
Available at:
http://www.ietf.org/internet-drafts/
draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt
[referred
to
30.8.2004].
[33] V. Jacobson, R. Braden, and D. Borman. TCP Extension for High Performance
(RFC 1323). The Internet Society, May 1992.
BIBLIOGRAPHY
73
[34] C. Jennings and R. Mahy.
lay Protocol (MSRP).
Relay Extensions for Message Sessions Re-
Internet draft, Internet Engineering Task Force, July
2004. Work in progress, Available at: http://www.ietf.org/internet-drafts/
draft-ietf-simple-msrp-relays-01.txt [referred to 30.8.2004].
[35] Y. Kohda, H. Sugano, and S. Okuyama. IMPP: A New Instant Messaging Standard
and Its Impact on Internet Business. Fujitsu Scientific & Technical Journal: Information Technologies in the Internet Era, 36(2):147–153, December 2000. Available at:
http://magazine.fujitsu.com/us/vol36-2/paper06.pdf [referred to 30.8.2004].
[36] T.V. Lakshman and U. Madhow. The Performance of TCP/IP for Networks with
High Bandwidth-Delay Products and Random Loss. IEEE/ACM Transactions on
Networking, 5(3):336–350, June 1997. ACM Press.
[37] S. Leggio, T. Kulve, O. Riva, and M. Kojo. An Analysis of Instant Messaging and
E-mail Access Protocol Behaviour in Wireless Environments. Technical report, University of Helsinki, Department of Computer Science, March 2004.
[38] T. Louis. AIM Still Not Secure. Planet IT, February 2001. Available at: http:
//www.tnl.net/who/bibliography/aimsecurity/ [referred to 30.8.2004].
[39] H. Lundgren, R. Gold, E. Nordström, and M. Wiggberg. A Distributed Instant Messaging Architecture based on the Pastry Peer-To-Peer Routing Substrate. Technical
report, Uppsala University of Sweden, 2003. Available at: http://winternet.sics.
se/workshops/sncnw2003/proceedings/18T-sncnw.pdf [referred to 30.8.2004].
[40] M. Mitsuoka, S. Watanabe, J. Kakuta, and S. Okuyama. Instant Messaging with Mobile Phones to Support Awareness. In Symposium on Applications and the Internet,
pages 223–230, January 2001.
[41] MobileIN.com. Mobile Instant Messaging. Available at: http://www.mobilein.com/
MIM.htm [referred to 30.8.2004].
[42] P. Nguyen. Instant Messaging technology for the business market: Do the advantages
outweigh the risks?
Technical report, SANS Institute, November 2003. Available
at: http://www.giac.org/practical/GSEC/Phuong Nguyen GSEC.pdf [referred to
30.8.2004].
[43] P. Nicholls. Short Message Service Long on Possibilities. Available at: http://www.
klixxx.com/archive/smssolution.shtml [referred to 30.8.2004].
[44] J. Nielsen. IM, Not IP (Information Pollution). ACM Queue, 1(8):75–76, November
2003.
[45] V. Niemi and K. Nyberg. UMTS Security. John Wiley & Sons, December 2003.
BIBLIOGRAPHY
74
[46] M. Nordberg, H. Hannu, J. Christoffersson, and L. Zaccomer. Improving SigComp
performance through Extended Operations. In Vehicular Technology Conference,
2003, pages 3425–3428, October 2003.
[47] V. Pai and P. Rana. A Transparent Framework for Enabling Incoming TCP Connections to Host Behind a NAT Gateway. In Computer Communications and Networks,
2003, pages 572–575, October 2003.
[48] R. Parvianen and P. Parnes. Mobile Instant Messaging. In 10th International Conference on Telecommunications, pages 425–430, 2003.
[49] C.E. Perkins. Mobile networking in the Internet. Mobile Networks and Applications,
3(4):319–334, 1999. ACM Press.
[50] J. Peterson. Common Profile for Instant Messaging (CPIM) (RFC 3860). The Internet Society, August 2004.
[51] J. Peterson. Common Profile for Presence (CPP) (RFC 3859). The Internet Society,
August 2004.
[52] E. Pitoura and B. Bhargava. Dealing With Mobility: Issues and Research Challenges.
Technical report, Department of Computer Science, Purdue University, US, November
1993.
[53] M. Poikselkä, G. Mayer, H. Kharatabil, and A. Niemi. The IMS: IP Multimedia
Concepts and Services in the Mobile Domain. John Wiley & Sons, June 2004.
[54] R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, and J. Rosenberg. Signaling Compression (SigComp) (RFC 3320). The Internet Society, January 2003.
[55] A. Quintana, J. Ramsinghani, and T. Walls. Peer-to-Peer Computing: The Search
for Viable Business Models. Technical report, Kellogg Tech Ventures, 2001. Available at: http://www.ranjaygulati.com/new/research/PEER-TO.pdf [referred to
30.8.2004].
[56] A. B. Roach. Session Initiation Protocol (SIP) - Specific Event Notification (RFC
3265). The Internet Society, June 2002.
[57] J. Rosenberg. The Session Initiation Protocol (SIP) UPDATE Method (RFC 3311).
The Internet Society, September 2002.
[58] J. Rosenberg. A Presence Event Package for the Session Initiation Protocol (SIP)
(RFC 3856). The Internet Society, August 2004.
[59] J. Rosenberg.
The Extensible Markup Language (XML) Configuration Ac-
cess Protocol (XCAP).
Internet draft, Internet Engineering Task Force, July
2004. Work in progress, Available at: http://www.ietf.org/internet-drafts/
draft-ietf-simple-xcap-03.txt [referred to 30.8.2004].
BIBLIOGRAPHY
75
[60] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks,
M. Handley, and E. Schooler. SIP: Session Initiation Protocol (RFC 3261). The
Internet Society, June 2002.
[61] J. Rosenberg and M. Schulzrinne. An Extension to the Session Initiation Protocol
(SIP) for Symmetric Response Routing (RFC 3581. The Internet Society, August
2003.
[62] R. Sparks. The Session Initiation Protocol (SIP) Refer Method (RFC 3515). The
Internet Society, April 2003.
[63] B. Sterman and D. Schwartz.
NAT Traversal in SIP, 2001.
Available at:
http://corp.deltathree.com/technology/nattraversalinsip.pdf [referred to
30.8.2004].
[64] J. Stone and S. Merrion. Instant Messaging or Instant Headache?
ACM Queue,
2(2):72–80, April 2004.
[65] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, and J. Peterson. Presence
Information Data Format (PIDF) (RFC 3863). The Internet Society, August 2004.
[66] E. Sutherland. Wireless telecommunications: value and mobility. Technical report,
Indian Institute of Technology, 2002.
[67] techiwarehouse.com.
Instant
Messaging.
Available
at:
http://www.
techiwarehouse.com/Articles/2003-05-12.html [referred to 30.8.2004], May
2003.
[68] Y. Vogiazou. Wireless Presence and Instant Messaging. Technical report, Knowledge
Media Institute, November 2002.
[69] Webopedia.com. Online Encyclopedia dedicated to computer technology. Available
at: http://www.webopedia.com.
[70] Whatis.com. Available at: http://www.whatis.com.
[71] R.L. Wickham (Editor-in Chief). SMS: Europe’s Smash Hit. Wireless Review, Available at: http://wirelessreview.com/ar/wireless sms europes smash/ [referred
to 30.8.2004], March 2001.
[72] Yamigo.com. It’s a Wireless Village. Available at: http://www.yamigo.com/.
Appendix A
Message Flow Examples
SIMPLE
Session Mode Messaging
Alice → atlanta.com proxy
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 179
v=0
o=alice 2890844557 2890844559 IN IP4 pc33.example.com
s=
c=IN IP4 pc33.atlanta.com
76
APPENDIX A. MESSAGE FLOW EXAMPLES
t=0 0
m=message 9 msrp *
a=accept-types:text/plain
a=path:msrp://pc33.atlanta.com:7777/iau39;tcp
atlanta.com proxy → Alice
SIP/2.0 100 Trying
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1
To: Bob <sip:[email protected]>
CSeq: 314159 INVITE
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1
To: Bob <sip:[email protected]>;tag=a6c85cf
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 182
v=0
o=bob 2890844612 2890844616 IN IP4 bobpc.biloxi.com
s=
c=IN IP4 bobpc.biloxi.com
t=0 0
m=message 9 msrp *
a=accept-types:text/plain
a=path:msrp://bobpc.biloxi.com:8888/9di4ea;tcp
Alice → Bob
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: Bob <sip:[email protected]>;tag=a6c85cf
CSeq: 314159 ACK
Content-Length: 0
Alice → Bob
MSRP d93kswow SEND
To-Path:msrp://bobpc.biloxi.com:8888/9di4ea;tcp
From-Path:msrp://pc33.atlanta.com:7777/iau39;tcp
Message-ID: 12339sdqwer
Content-Type:text/plain
Hi, I’m Alice!
-------d93kswow$
77
Bob → Alice
MSRP d93kswow 200 OK
To-Path:msrp://bobpc.biloxi.com:8888/9di4ea;tcp
From-Path:msrp://pc33.atalanta.com:7777/iau39;tcp
-------d93kswow$
Bob → Alice
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:[email protected]>;tag=a6c85cf
To: Alice <sip:[email protected]>;tag=1928301774
CSeq: 231 BYE
Content-Length: 0
Alice → Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
From: Bob <sip:[email protected]>;tag=a6c85cf
To: Alice <sip:[email protected]>;tag=1928301774
CSeq: 231 BYE
Content-Length: 0
Pager Mode Messaging
Alice → atlanta.com proxy
MESSAGE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:[email protected];tag=49583
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 14
Hi, I’m Alice!
78
SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776sgdkse; received=1.2.3.4
From: sip:[email protected];;tag=49394
To: sip:[email protected];tag=ab8asdasd9
Call-ID: [email protected]
CSeq: 1 MESSAGE
Content-Length: 0
IMPS
Messaging
Alice → IMPS server
POST /wv/ HTTP/1.1
Host: imps.atlanta.com
Content-Length: 949
Content-Type: application/vnd.wv.csp.xml
<WV-CSP-Message xmlns="http://www.openmobilealliance.org/DTD/WV-CSP1.2">
<Session>
<SessionDescriptor>
<SessionType>Inband</SessionType>
<SessionID>pc33.atlanta.com#48815atlanta.com</SessionID>
</SessionDescriptor>
<Transaction>
<TransactionDescriptor>
<TransactionMode>Request</TransactionMode>
<TransactionID>IMApp01#12345@NOK5110</TransactionID>
</TransactionDescriptor>
<TransactionContent xmlns="http://www.openmobilealliance.org/DTD/WV-TRC1.2">
<SendMessage-Request>
<DeliveryReport>F</DeliveryReport>
<MessageInfo>
<ContentType>text/plain</ContentType>
<ContentEncoding>None</ContentEncoding>
<ContentSize>58</ContentSize>
<Recipient>
<User>
<UserID>wv:[email protected]</UserID>
</User>
</Recipient>
<Sender>
79
<User>
<UserID>wv:[email protected]</UserID>
</User>
</Sender>
<Validity>600</Validity>
</MessageInfo>
<ContentData>Hi, I’m Alice!</ContentData>
</SendMessage-Request>
</TransactionContent>
</Transaction>
</Session>
</WV-CSP-Message>
IMPS server → Alice
HTTP/1.1 200 OK
Date: Sat, 21 Aug 2004 07:40:27 GMT
Content-Length: 702
Content-Type: application/vnd.wv.csp.xml
<WV-CSP-Message xmlns="http://www.openmobilealliance.org/DTD/WV-CSP1.2">
<Session>
<SessionDescriptor>
<SessionType>Inband</SessionType>
<SessionID>pc33.atlanta.com#[email protected]</SessionID>
</SessionDescriptor>
<Transaction>
<TransactionDescriptor>
<TransactionMode>Response</TransactionMode>
<TransactionID>IMApp01#12345@NOK5110</TransactionID>
</TransactionDescriptor>
<TransactionContent xmlns="http://www.openmobilealliance.org/DTD/WV-TRC1.2">
<SendMessage-Response>
<Result>
<Code>200</Code>
<Description>Successfully completed.</Description>
</Result>
<MessageID>0x0000f132</MessageID>
</SendMessage-Response>
</TransactionContent>
</Transaction>
<Poll>F</Poll>
</Session>
</WV-CSP-Message>
80

Mobile Instant Messaging Systems - A Comparative Study

Transcription

Similar documents

Enterprise Messaging Solution

LaundryAlert System

UltraNEXUS-HD Blade

Val Babajov - Invest Bulgaria Agency

The Next Necessity™ - InSinkErator Image Server

The Next Necessity™ - InSinkErator Image Server

Instant Marinater

Comverse-OMA Messaging Workshop

www.trail-appliances.com