Project Report onPresence and Mobile Instant Messaging

Prepared in fulfillment of the courseDistributed Systems

BySandeep Paul Katumalla

Ajith Kannath

AtUniversity of California, Irvine

Department of Information and Computer Sciences

Winter, 2011

Acknowledgments

We wish to express our sincere gratitude to Prof. Nalini Venkatasubramanian, University of California, Irvine, for giving us the opportunity and motivation to work on this project.Her clear and precise explanations of the various concepts and technologies, along with an exhaustive list of project options provided have been invaluable resources to this endeavor.

Table of Contents

1. Introduction and Motivation 4

2. Existing protocols on Instant Messaging 5

3. Implementation of Presence and Instant Messaging using SIP protocol 6 3.1 Approach Followed 6 3.2 Session Initiation Protocol 7 3.3 Timing Diagram 8 3.4 State Diagram 9

4. Conclusion and Future Work 10

5. Screenshots of the Application 11

6. References 13

7. Appendix 14

1 Introduction and Motivation

The rapid development of many modern communication technologies have given users many more options for communicating in their workplace and personal life. Of these new communication technologies, instant messaging is one of the most proliferating communication technologies adopted. The rise in popularity of instant messaging in recent years have led to its acceptance as a valuable method of communication in academic and professional sectors. Instant messaging protocols have enabled users to interact in a faster way as compared to protocols like e-mail while avoiding any potential costs as opposed to voice telephony. Instant messaging is looked upon as the major killing application in the field of IP-telephony.

In telecommunication networks, presence information is defined as a status indicator showing the willingness and ability of a potential communicator to communicate. The client application on the user's side contacts a presence service and provides presence state via network. At the server end it is stored in his personal availability record and is distributed to other users to convey his availability for communication. Modern instant messaging clients use various user availability states such as "free for chat", "busy", "away", "do not disturb" etc. to portray the users current mood, location or free text status. Presence shows the availability state of a user (and maybe much more information about his current state, location etc) and any other user can make use of this data to decide whether to initiate a conversation with that user.

Instant messaging (IM) is a form of real-time text based communication between two or more people with personal computers or any other devices using shared clients. Instant messaging goes hand-in-hand with presence in the sense, a user needs to know the presence information of another to initiate a messaging session with him. IM is considered as one among the various 'online chat' protocols and the specific thing about IM is that it facilitates connection between a specified list of known users called 'buddy list', 'friend list' or 'contact list'. It differs from e-mails in the sense that IM is real-time communication. It allows the user, advantages of both email systems, where communication is free and telephonic systems where communication is real-time.

Modern companies try to combine different solutions with instant messaging and produce combined and highly potential applications. We will be discussing many of the current instant messaging architectures in the next section. It is also possible to save instant messages for a later reference and many current instant messaging/chat systems support this feature. Each modern IM generally provide its own client which can be a separately installed software or a browser based client. Also, lately there are many third-party client software applications that will connect with most of major IM services. Modern systems hardly distinguish between IM and MIM (Mobile Instant Messaging) so we will be using both terms interchangeably with the same meaning implied. Also MIM is now available in the form of many applications in many embedded operating systems as Windows Mobile, Blackberry OS, Symbian OS, Android OS etc. Many modern IM systems even allow to incorporate microblogging functionalities within them enabling the users in the 'friends list' to comment on the status message of a particular user. A recent example for such an application is 'Google BUZZ' .

We have designed and developed a SIP (Session initiation protocol) based presence and instant messaging protocol. So as a first step we have done a wide survey of all the existing distributed or centralized protocols which deal with presence and messaging. We have analyzed many IM systems which are currently in market, and the protocols which they follow. We have also extended the norm of standard instant messaging to one of “remote invocation of applications” in android device where any device can remotely invoke any application in his friend's device provided the friend has authorized him to do so. We are also planning to extend our application to involve multi-lingual voice chat wherein the user can chat in English and the message will get automatically converted to

any of the four languages – German, Chinese, French and Italian. The multi-lingual voice chat support will completely remove the language barriers which people have currently. For instance, a British national can chat transparently with a French national, without ever knowing that both of them have no language in common.

2 Existing protocols on Instant Messaging

XMPP : Extensible Messaging and Presence Protocol(XMPP) is an open standard communications protocol for message oriented middleware based on XML.The XMPP network which is a free and open source software uses a client–server architecture that is decentralized and hence there is no central authoritative server.It was originally developed for near real time extensible instant messaging , presence information and contacts maintenance.Owing to its extensibility, it led to its widespread use in VoIP(Voice over Internet Protocol) and file transfer signaling. The unique feature of XMPP is that it uses an open systems approach of development and application, which allows anyone to implement an XMPP service that can interoperate with other organizations' implementations.

RTP/RTCP : Another important protocol that is relevant is RTP or Real-time Transport Protocol(RTP), which standardizes video and audio packets for delivery over IP networks. It is mainly used in conjunction with RTCP or Real-time control protocol, which monitors transmission statistics and QoS, along with the synchronization of multiple streams.Designed for end to end real time transfer of stream data, it also provides for jitter compensation and detection of out of sequence packets.It is widely considered to be the primary standard for multimedia transmission over IP networks.The Transmission Control Protocol (TCP) is not normally used in RTP application because TCP favors reliability over real time transfer. As a consequence of this , a majority of the RTP implementations are built on the User Datagram Protocol (UDP).

MSNP : The Microsoft Notification Protocol(MSNP) was developed by Microsoft , which was primarily designed for the .NET messenger service and clients attached to it was also made flexible enough to be adopted by third party clients such as Pidgin and Trillian. MSNP consists of a series of commands sent between the client and the server which establish a connection on reqeust from a user and passes the data between two endpoints in a conversation. Subsequent versions of MSNP have incorporated features such as VoIP (Voice over Internet Protocol) and video streaming. The MSNP has a breakingpoint version of the protocol that supports high performance simulations allowing a 10GB blade to generate over 2.4 million concurrent TCP flows or in other words, about 5 million people to communicate through the messenger server at any given time.

MSN Messenger : One of the first instant messaging and presence systems was the .NET Messenger Service or the MSN Messenger Service developed by Microsoft, which used the Microsoft Notification Protocol.Also called the Windows Live Messenger, it is currently designed to work with the latest versions of Windows,Blackberry OS, iOS, Java ME,S60 and the Zune HD. It offered many first time features such as the Album viewer, selective offline status, integration with social networks as well as off line messaging. The lastest version is Windows Live Messenger 2009.It was proposed to have features related to multi-person audio/video chat, and they are also attempting to create interoperability with AIM/XMPP/ICQ.

Google Wave Federation Protocol : Perhaps the latest in instant messaging protocols is the Google Wave Federation Protocol is an extension of XMPP that is used in Google Wave.It is designed for near real-time communication between the computer supported cooperative work wave servers. It has incorporated some inherited features of Extensible Messaging and Presence Protocol (XMPP)such as the discovery of IP addresses and port numbers, using Domain Name System

(DNS) SRV records, and TLS authentication and encryption of connections. The XMPP transport encrypts operations at a transport level and hence only provides cryptographic security between servers connected directly to each other.

Skype : One of the most recent names to emerge in the domain of instant messaging and VoIP is Skype.Skype uses a proprietary Internet telephony (VoIP) network based on peer-to-peer architecture. The protocol has not been made publicly available by Skype and official applications using the protocol are closed-source. The Skype network's unique feature is that it is not interoperable with most other VoIP networks without the required licensing from Skype. Skype was the first peer-to-peer VoIP network ,which meant that it requires minimal centralized infrastructure. Its user directory is decentralized and distributed among the clients, or nodes, in the network.

Yahoo Messenger Protocol : Another popular instant messaging protocol is the Yahoo messenger protocol. Like most other cutting edge instant messaging technologies , this protocol too supports many features beyond just messaging , such as off-line messaging, file transfer, chat, conferencing, voice chat, webcams and avatars. The purpose of the YMSG protocol is to provide a language and series of conventions for software communicating with Yahoo!'s Instant Messaging service. In essence YMSG performs the same role for IM as HTTP does for the World Wide Web. Unlike HTTP, however, YMSG is a proprietary standard, aligned only with a single messaging service provider.

Jingle : Another peer to peer session control protocol is Jingle which is again an extension of XMPP. Here, for the first time multimedia streams are delivered using the Real-time Transport Protocol(RTP), for services such as VoIP and video conferencing.

Zephyr : The Zephyr protocol is another Unix based application suite which is a conglomeration of multiple seperate programs working together towards a common cause.Along with the IRC, Zephyr was the first widely used IP based instant messaging system. Today, Zephyr is rarely used , and the few places it is still used is in university environments , but has largely been replaced by the latest applications such as XMPP.

TOC : Lastly, we discuss the TOC or Talk to OSCAR protocol which was used mainly by third party AOL instant messenger clients. TOC works as a wrapper for the OSCAR protocol.From a high level view, the TOC server was similar to an OSCAR client listening to a socket and translating messsages between two dissimilar protocols.

3 Implementation of Presence and Instant Messaging using SIP protocol

3.1 Session Initiation Protocol

Session initiation protocol (SIP) is an IETF initiated protocol, widely used for multimedia communication sessions such as voice and video calls over the internet. The protocol is widely used for creating, modifying and terminating two-party or multi-party sessions consisting of more than one media stream. Modifications involve changing addresses of ports, inviting more participants, adding or deleting more media streams and the like. The protocol defines a distributed environment which involves a dedicated SIP server and a number of clients. The SIP server is assumed to be up and running all the time. The clients, when they boot-up, register with the SIP server and the SIP server maintains a list of all the clients that are currently registered with it.The SIP server maintains this data as a table which includes the clients' names and their corresponding IPs. The SIP server's

IP is assumed to be known by all the clients. Whenever a client wants to communicate with another client, it conatcts the server with the remote client name. The SIP server will in-turn send an INVITE message to the remote client and waits for the reply. Once the remote client replies with a 200 OK message, the server establishes and maintains a session involving both the clients. Once the session is established, direct communication can take place between the clients without dependency on the server. The clients should update the server about any change in its basic informations as the IP, port numbers in which they communicate and the like.

3.2 Approach Followed

Both the client and server side of the presence and messaging application is implemented in custom means. The server is assumed to reside on a system which has a static IP. All the clients provided an interface in which they can choose the SIP server to which they want to communicate with, and set the SIP server's IP within their configuration settings. The SIP server has an online database of all the clients currently registered to the server. Initially this database will be null. The server also maintains the login credentials of all the clients (i.e, the username and password). When a client tries to authenticate itself by registering to the server, the server matches the credetial information provided with its database. If the client is a valid client with proper, verified credentials, the server replies the client with a list of its online friends. If the authorization has failed, the server replies with a null list, thus notifying client that its authorization credentials (either username or password) are wrong. On the client side, once it sends its authorization details to the server and gets a list of the available friends, it presents the user, with a list of his friends showing whoever is online or not. This gives the user, the basic presence information of his friends.

In some networks, the client's IP may not be static ; it keeps changing in a while. Also, in a distributed system, the client can go offline, or even crash or fail without any prior indication. This situation is taken care of, by a notification mechanism. The client keeps notifying the server, of its current IP, every five seconds (this time is configurable). There is a dedicated client thread which does this, and these messages are also considered as "am alive" messages by the server. The server has a dedicated thread which monitors inputs from the client and updates the presence information database. The database is a form of a table which contains fields for the client's name, its IP and a boolean indicating its presence information. Given below is a sample table maintained by the server.

Username IP PresenceCauvan 192.168.1.32 FALSEMark 192.168.1.102 TRUERony 192.168.1.45 TRUE

Sophie 192.168.1.65 FALSE

Figure 1 : Presence database maintained by server

If the server does not receive an "am alive" message from a client within ten seconds, the client is considered to be offline and the table is updated accordingly. The server sends this table to all the present clients, once in every five seconds so that the clients get the updated presence information of their friends. Once the clients have this presence information with them, they display it to the user and the user can select any other present user for online chat. If user1 wants to chat with user2, he selects the user2 from his buddy-list and can directly starts chatting with him. Since this chat application is meant for a mobile platform, only one chat session is supported per user. Given below is a timing diagrams of all the operations that happens between two clients and the server.

3.3 Timing Diagram

Client 1 Server Client 2

Log in Request

Confirm authenticationand send current online list

Periodically send "alive" message

Respond with the current online list after each message Log in Request

Update Confirm authenticationList and send current online listView

Update List View

Periodically send "alive" message

Respond with the current online list after each message

Initiate 2 way end to end chat session

Client 1 Logs out

Server sends updates friends listand IPs

Update List View

The client1 first logs in with his credentials. The server authenticates him and sends an online list of friends for that client. The client start sending periodic "am alive" messages and the server responds with current online list of friends. The client, upon receiving that list from the server, updates his list view. The second client also boots up and follows the same procedure. Subsequently, both the clients know about the existence of other through the server ( server and client exchages tables as shown in figure 1). After knowing the IPs of each other, the clients can instantiate a chat session among themselves. 3.4 State Diagram

Server Start request from

client S0 S1

S2

client startsend to endsession with

another client

S3 S4

S5

one client some client's

logs out IP changes

The state diagram explains the basic states of this archetecture. The server, initially idle, starts listening to clients. When any request occurs from any clients, the server upadtes its database and sends out a response to all present clients about the update. Any two clients, thus knows about the presence of other and knows their IPs as well. After that they can start a chat session among themselves. Once a node fails or crashes, the "am alive" message stops reaching the server and server assumes that the client has gone offline. Subsequently, the server updates its database and sends it out to all present clients.

Server:idle Server:Listening for users

Server: Updates list of usersClient:receives updated listWith IPs of all online users

Server: listening for pingsClient:opens port and sends/receives messages on it

Server: sends updated IP addressto every clientClient: directly receives updatedIP addresses from server

Other client notified by server when it sends

next list

4. Conclusion and Future Work

In this project, we have explored the Session Initiation Protocol(SIP) to develop an instant messaging(IM) application for android. During the course of this project , we have had the opportunity to implement our own version of SIP, which takes care of dynamic IP address assignment to the clients by maintaining and periodically updating the presence information of each of the clients. In developing this application, we have learned numerous protocols and witnessed the intricacies of developing a stand alone client server application first hand. This has been a very valuable learning opportunity for us and we intend on making this application more robust and bug free in the future. One other feature we are currently working on is cross language/locale instant messaging where two chat clients can communicate end to end in different languages. To achieve this, we are developing a translator module for the application which will translate between the desired languages, either on the sending side or the receiving side.

5 Sreenshots of Application

a) Login screeen b) Friends-list

c) Chat window

6 References

[1] http://en.wikipedia.org/wiki/Category:Instant_messaging_protocols

[2] SIP for Presence and Instant Messaging, Helsinki University of Technology, Networking Laboratory

[3] Standard SIP based Instant Messaging and Presence APIs for Networked Devices, Mourad Debbabi, Mahfuzur Rahman, Wanrong Lin, jay Gopal, Srikrishna Sridhar.

[4] Instant Messaging and Presence Management in Mobile Ad-Hoc Networks, Derek Green, Donal O' Mahony

[5] The War of Presence and Instant Messaging: Right Protocols and APIs, Mourad Debbabi and Mahfuzur Rahman[6] Instant Messaging and Presence Technologies for College Campuses, Samir Chatterjee, Tarun Abhichandani, Haiqing Li, Jongbok Byun, and Bengisu Tulu

[7] Comparison of SIP and H.323 Protocols, Ilija Basicevic, Miroslav Popovic, Dragan Kukolj

[8] Instant Messaging and Presence on the Internet, Harald Alvestrand

[9] IM: How Instant Messaging Systems Work, Xinran Wu, Clement Yuen

[10] IMS Presence Server: Traffic Analysis & Performance Modelling, C. Chi, R. Hao, D. Wang, Z. Cao

[11] Indigo Presence Server & SDKTM , Indigo Software.

[12] XMPP : Extended Presence Protocol Suite, Peter Saint-Andre

[13] Instant Messaging and Presence Services Using Simple, Zhigang Jin, Hui Jin, Lu Han

[14] http://en.wikipedia.org/wiki/Session_Initiation_Protocol

7 Appendix

Here are some code snippets and a brief explanation of each one's functionality:

- The server side code snippet below contains the method which the server uses to send the list of currently online users to the client after it receives an authentication request

public static void Reply(HashMap<String,InfoObject> serializedOnlinemap,String phoneIP){

Socket socket = null; Set<Entry<String, InfoObject>> onlines = serializedOnlinemap.entrySet(); Iterator<Entry<String, InfoObject>> onlineIterator = onlines.iterator(); while(onlineIterator.hasNext()){ Entry<String, InfoObject> online = onlineIterator.next(); sendableMap.put(online.getKey(), online.getValue().presence.toString() + " " + online.getValue().IP); }

try { socket = new Socket(phoneIP, SIGNINSENDPORT); ObjectOutputStream dataOutputStream = new

ObjectOutputStream(socket.getOutputStream()); dataOutputStream.writeObject(sendableMap); dataOutputStream.flush(); //socket.close();

} catch (UnknownHostException e) { System.err.println("could not resolve host");

e.printStackTrace(); } catch (IOException e) { System.err.println("could not establish IO connection to host

at " + phoneIP); e.printStackTrace();

}}

The server sends a serialized hashmap which contains usernames and their respective presence information to the client. The method argument also includes the phone's IP, which is extracted by the server from the client's authentication request. The following lines do this on the server side

Socket client = serverSocket.accept();String incomingAddress = client.getInetAddress().getHostAddress();

The server also spawns a two seperate threads in its main() method. One of them continuously listens to authorization request from the clients. Given below is the thread implementation:

public static class AuthorizationThread implements Runnable {DataInputStream dataInputStream = null;String[] AuthString;

public void run() { try { while (true) { // listen for incoming clients Socket client = serverSocket.accept(); String incomingAddress =

client.getInetAddress().getHostAddress(); try { DataInputStream in = new

DataInputStream(client.getInputStream());

String inputStream = in.readUTF().toString(); AuthString = inputStream.split(" "); InfoObject userInfo; if(authorizationMap.containsKey(AuthString[0]) &&

authorizationMap.get(AuthString[0]).equals(AuthString[1])){ userInfo = new

InfoObject(true,incomingAddress,System.currentTimeMillis()); onlineMap.put(AuthString[0], userInfo); Reply(onlineMap,incomingAddress); } else{ Reply("access denied",incomingAddress); } //break; } catch (Exception e) { e.printStackTrace(); } } } catch (Exception e) { e.printStackTrace(); }

}}

The other thread constantly listens to the clients for "am alive" messages, (10 second intervals in this case). Whenever it receives an "am alive" message from a client, it immediately updates it's map on currently online clients along with their changes IPs in case they change. Given below is the thread implementation:

public static class UpdateIP implements Runnable {DataInputStream dataInputStream = null;Collection<String> onlineMapEntries;Iterator<String> onlineMapIterator,onlineMapIterator2;String PhoneName;

public void run() { try { while (true) { // listen for incoming update messages Socket client = phoneUpdateSocket.accept(); String incomingAddress =

client.getInetAddress().getHostAddress();//contains the new ip address try { DataInputStream in = new

DataInputStream(client.getInputStream()); String PhoneName =

in.readUTF().toString();//contains the username eg. sandeep, ajith, etc. //System.out.println("Ping received from " +

PhoneName); if(onlineMap.containsKey(PhoneName)){ onlineMap.put(PhoneName, new

InfoObject(true,incomingAddress,System.currentTimeMillis())); } onlineMapEntries = onlineMap.keySet(); onlineMapIterator = onlineMapEntries.iterator(); String currName;

System.out.println("------------------------------------------"); while(onlineMapIterator.hasNext()){ currName =

onlineMapIterator.next().toString(); if((System.currentTimeMillis() -

onlineMap.get(currName).timeStamp) > 20000){

onlineMap.put(currName, new InfoObject(false,"nil",System.currentTimeMillis()));

} System.out.println(currName +" " +

onlineMap.get(currName).presence); /** * else send onlineMap to all present

clients */ }

System.out.println("------------------------------------------"); onlineMapIterator2 =

onlineMapEntries.iterator(); while(onlineMapIterator2.hasNext()){ currName =

onlineMapIterator2.next().toString();

if(onlineMap.get(currName).presence.booleanValue()){ String sendIP =

onlineMap.get(currName).IP; Reply(onlineMap,sendIP); } } } catch (Exception e) { e.printStackTrace(); } } } catch (Exception e) { e.printStackTrace(); }

}}

}

Once a client is authenticated by the server, the client spawns a thread which pings the server at a scheduled fixes rate with "am alive messages" so that the server has a way of knowing the client's current IP address, even if it is dynamic. The following two methods illustrate how this is done.

public static void startTimerTask(){int delay = 500; // delay for .5 sec.int period = 10000; // repeat every 10 secs.timer = new Timer();timer.scheduleAtFixedRate(new TimerTask() { public void run() { //getLocalIpAddress(); pingServerWithNewIP(); } }, delay, period);}

public static void pingServerWithNewIP(){Socket socket = null; try { socket = new Socket(SERVERIP, UPDATEIPSENDPORT); DataOutputStream dataToServer = new

DataOutputStream(socket.getOutputStream()); dataToServer.writeUTF(PHONENAME); } catch (UnknownHostException e) {

Log.i("IMPORTANT","Could not find host " + SERVERIP); e.printStackTrace();

} catch (IOException e) { Log.i("IMPORTANT","Could not establish IO Connection to " +

SERVERIP); e.printStackTrace(); }

}

Lastly, in Android , all modifications of UI components can only be performed in the UI thread. Since the present application made extensive use of multithreading, to ensure that the most recent data collected by each thread is transferred to the UI components , handlers were employed. A handler is basically a thread manager that takes care of the synchronization and message passing between the different threads. Here's one of the handlers used in the code:

private final Handler ListUpdater = new Handler(){ HashMap<String,String> updatedMap; public void handleMessage(Message msg) {//msg contains the

hashmap String[] updatedFriends = new String[5]; List<String> updatedOnlineFriends = new

ArrayList<String>(); updatedMap = (HashMap<String,String>)msg. obj ; Set<Entry<String, String>> onlines =

updatedMap.entrySet();Iterator<Entry<String, String>> onlineIterator = onlines.iterator();

while(onlineIterator.hasNext()){ Entry<String, String> online = onlineIterator.next(); if((online.getValue().toString().split(" ")

[0]).equals("true")){ updatedOnlineFriends.add(online.getKey() + "\t" + "is online"); } else{ updatedOnlineFriends.add(online.getKey() + "\t" + "is offline"); } } for(int i = 0;i < updatedOnlineFriends.size(); i++){ updatedFriends[i] = updatedOnlineFriends.get(i); }

setListAdapter(new ArrayAdapter<String>(FriendsList.this, R.layout.list_item, updatedFriends));

ListView lv = getListView(); lv.setTextFilterEnabled(true); lv.setOnItemClickListener(new OnItemClickListener() {

public void onItemClick(AdapterView<?> parent, View view,int position, long id){

String clickedFriend = getListView().getItemAtPosition(position).toString().split("\t")[0];

String clickedFriendIP = clickedFriend + " " + updatedMap.get(clickedFriend).split(" ")[1];

Intent dynamicIPIntent = new Intent();dynamicIPIntent.putExtra("friendIP",

clickedFriendIP);dynamicIPIntent.setClass(FriendsList.this,

Chat.class);FriendsList.this.startActivity(dynamicIPIntent);

} });

}};