CHAPTER 1: Introduction

(1)

ANISA RAGALO

RGLANI001 RGLANI001 RGLANI001 RGLANI001 [email protected]

Supervisor: Prof. Ken MacGregor University of Cape Town

(2)

2

ABSTRACT

This report is an investigation into the development of a middleware platform that facilitates interoperability between two application layer protocols (as classified by the TCP/IP protocol suite) for wireless messaging. The protocols are SIP: The Session Initiation Protocol and JMS: The Java Messaging Service. An interoperability/middleware platform is developed and consists of client side as well as server side infrastructure.

The client side is characterised by a novel API stack developed through the integration of the SIP and JMS API stacks. An application running on top of the novel API stack can be configured to use either SIP or JMS without the need to be rewritten.

The server side consists of an entity that converts messages from one protocol to another as they are routed through the server infrastructure. This means that an application running SIP at one end can communicate with an application running JMS on another end.

Interoperability between SIP and JMS is therefore achieved at the client side, in being able to port the same application from one protocol to the other.

Further, interoperability between SIP and JMS is achieved at the server side as messages can be converted from one protocol to another. More precisely messages leaving a sender entity can be translated into another protocol as they pass the server architecture en-route to a recipient entity.

(3)

CHAPTER 1: Introduction

This project is centered on building a middleware toolkit for mobile devices. The middleware’s principal function is the integration and interoperability of two application layer protocols, namely SIP: The Session Initiation Protocol, and JMS: The Java Messaging Service.

1.1 Overview

1.1.1 What is being implemented?

A mobile middleware toolkit that facilitates the portability of an application from one protocol to another.

Specifically, the principle aim of this project is to achieve interoperability between two protocols that are classified as application layer protocols in the TCP/IP protocol suite. The two protocols are SIP: The Session Initiation Protocol, and JMS: The Java Messaging Service.

Achieving interoperability takes place in two primary steps. Step one involves developing an Application Programming Interface (API) which is in essence the integration of the SIP and JMS APIs for wireless messaging. An application written using the novel API can use either SIP or JMS without having to be rewritten. Step two involves implementing a mechanism to convert messages from one protocol to another as they travel from the sending entity to the recipient entity.

(5)

1.1.2 Why is it important?

Interoperability is a fundamental concept in computer science. The integration of two protocols as atypical as SIP and JMS can and indeed, as established here, does lead to an expansiveness of the services provided by the individual protocols.

Current communication between mobile devices requires knowledge of the specific protocol with which the devices will communicate. Consequently mobile messaging applications are protocol specific. This means that in order for the same mobile messaging application to run on a different protocol, the application must be rewritten using method calls specific to the protocols Application Programming Interface.

Another consequence of protocol specificity is that communication cannot occur across different protocols. To elaborate, applications that are programmed to use protocols that are fundamentally different cannot communicate explicitly. Such communication would have to be facilitated by some infrastructure that converts data from one protocol to another. The latter is an additional deliverable of this project.

1.2 Summary

The primary aim of this project in a nutshell is to integrate SIP and JMS messaging for mobile devices in aiming to produce a new service provision platform that will enhance the functionality/services offered by the protocols.

(6)

6

CHAPTER 2: Background

This project aims to integrate SIP and JMS functionality for mobile communication.

In order to achieve this objective a thorough dissection of the nature of messaging in each of these protocols is essential.

At surface level, SIP and JMS are fundamentally different as the former is a real-time, synchronous communication protocol while the latter is a store and forward, asynchronous communication protocol.

This report primarily conducts an investigation into how messaging occurs in SIP. A detail of messaging in JMS can be obtained from the accompanying report by my project partner Lekometsa Mokhesi.

2.1 The Session Initiation Protocol

The Session Initiation Protocol was designed with three principal functions in mind: the creation, modification and termination of internet sessions [1].

A session in turn is described as the exchange of data between/among associated participants. The exchange of this data is complicated by the behaviour of these participants. Some of these behaviour patterns are described below:

Mobility

Participants have a tendency to be mobile in the sense that they move from one end point to another.

(7)

The Session Initiation Protocol addresses this issue by using allocating SIP Uniform Resource Identifiers (SIP URIs) to SIP session participants. A participant’s URI is bound to their current IP address such that a SIP server can facilitate contacting the user by proxy-ing or redirecting his/her messages.

Multiple Media

Participants may desire to use different media to communicate within a session, sometimes even simultaneously e.g. audio-visual sessions.

Several protocols exist that carry different forms of real-time multimedia session data.

SIP is completely independent of the type of multimedia session being handled and of the mechanism used to describe the session. SIP merely facilitates the negotiation of multimedia session parameters. It does this by carrying session descriptions within the message bodies of SIP messages that initiate the multimedia session. In essence session description is decoupled from session establishment which is the primary function of SIP. Consequently SIP is equally useful for most of these existing protocols and works in concert with them by enabling potential session participants to discover one another and negotiate the characterization of the session they would like to share.

SIP is part of the internet multimedia conferencing architecture [2] and is built on top of IP. In order to enhance our understanding of SIP, an examination of the fundamentals of IP and End-to-End protocols is pertinent.

2.1.1 SIP and IP Connectivity

IP came onto the scene of computing at a time when a paradigm shift was occurring in the mode in which data was transmitted from one point to another [3]. Formerly, a circuit switching approach was applied to data transmission, which involved

(8)

8 providing a dedicated channel between points for a period of time in which data was passed on from point A to B. During the time in which such a channel is dedicated to particular end points it cannot be freed up for use by other end points.

The circuit switching approach to data transmission was found to be exceedingly inefficient due to the bursty and non-uniform nature of data transmission. This is depicted in Figure 2.1 where a circuit provides 64 Kbps continuously, yet the data rate actually reached by the communicating systems is rarely this high.

Packet switching was designed to resolve this problem. Packet switching employs a data driven approach to data transmission in the sense that the contents of the data being transmitted determine how switching in the transmitting network occurs (Figure 2.2). A source node gathers the information to be transmitted into distinct packets. The information needed to transmit the packet to its destination is appended to the packet, constituting the packet header. Subsequently the packet is sent to the first network node (router) which forwards it to the next router based on the information discerned from the packet header. This process continues and is performed by

(9)

subsequent routers until the packet reaches its destination address. At the destination, the destination node removes the packet header and is able to obtain the original data.

IP is characterised as a packet switched end to end connectivity protocol.

The inner workings of IP have direct repercussions on SIP, because the latter is built on top of IP. These repercussions are explored below:

i) Intelligence occurs at the end systems

An IP network is constituted by intelligent hosts and a “dumb” network of routers. The end systems are responsible for controlling network traffic while routers have only the simple task of delivering the message to its destination.

SIP having been built on top of IP mirrors this behaviour by implementing intelligent end systems and a fairly unintelligent network. The intelligent entities in a SIP environment are called SIP User Agents and they are based on the SIP client devices. User agents are the entities that provide an interface between the user and the SIP

(10)

10 protocol. More specifically, in client side SIP programming user agents are the entities that execute the code embedded in the SIP client.

ii) Homogenous connection of networks that use different data link layer technologies

The IP infrastructure facilitates this and therefore SIP services can be integrated irrespective of any heterogeneous underlying link layer technology. Within the scope of this project JMS and SIP connections are evaluated over 802.11 and GPRS links.

2.1.2 SIP: Session Establishment, Modification and Termination

The basic functions of SIP are: the location of communication end points, facilitation of the negotiation of session parameters used to establish a session, and the teardown of the session once it is established.

SIP is based on a request response transaction model similar to that of HTTP. Each transaction is initiated by a request, which in turn invokes a method on the server and at least one response.

Typically SIP sessions are mediated by a SIP trapezoid architecture (Figure 2.3). A trapezoid is constituted by the caller and callee end points as well as their SIP domain servers. In Figure 2.3 on the next page Alice belongs to the domain atlanta.com while Bob belongs to biloxi.com.

(11)

atlanta.com . . . biloxi.com . proxy proxy . . .

Alice's . . . Bob's softphone SIP Phone | | | | | INVITE F1 | | | |--->| INVITE F2 | | | 100 Trying F3 |--->| INVITE F4 | |<---| 100 Trying F5 |--->| | |<--- | 180 Ringing F6 | | | 180 Ringing F7 |<---| | 180 Ringing F8 |<---| 200 OK F9 | |<---| 200 OK F10 |<---| | 200 OK F11 |<---| | |<---| | | | ACK F12 | |--->| | Media Session | |<================================================>| | BYE F13 | |<---| | 200 OK F14 | |--->| | |

Figure 2.3: The SIP trapezoid (Adapted from [4]).

The procedure for setting up a SIP session is detailed in the example above. Alice uses her sip application to contact Bob over the internet. She “calls” Bob using his unique SIP identity, a Uniform Resource Identifier (URI). In this case Bob’s URI is sip:[email protected] and similarly Alice’s URI is sip:[email protected].

Prior to session establishment, in order for a SIP trapezoid to be set up:

Both clients must initially acquire IP addresses. This could occur through network configuration via a DHCP server.

(12)

12 Each client must register with their corresponding domain SIP server to indicate that they are online and can be contacted. The IP address of the domain SIP server is usually configured into the registering soft phone. If not the domain server could be discovered by DHCP.

Registration occurs through the initiation of a REGISTER request by a SIP client addressed to a SIP registrar server (Figure 2.4). The SIP registrar sends back a SIP OK response confirming registration. Registration in essence binds a user’s SIP Uniform Resource Identifier to his/her current IP address.

Figure 2.4: SIP registration (adapted from [3])

A detail of the different SIP requests and responses is provided in the next session. SIP

Registrar

REGISTER

(13)

2.1.3 SIP requests and responses

There are six methods for SIP requests: The INVITE, ACK, OPTIONS, BYE, CANCEL and REGISTER requests.

INVITE requests are used to initiate SIP sessions. The invite request is therefore the first SIP message delivered from a SIP caller to a callee before a SIP multimedia session can be established between the two. Sending an invite is like dialing somebody’s number in a Packet Switched Telephone Network. It makes the other party aware of your desire to start communicating.

ACK requests are used to acknowledge the reception of a final response to an INVITE. SIP uses a three way handshake in the commencement of a session as shown below.

Figure 2.5: SIP three way handshake (adapted from [3])

The three way handshake is used to guarantee that both users are (still) available before the actual conversation begins. It is constituted by an INVITE, an OK response to the invite and an ACK.

(14)

14 OPTIONS requests are used by SIP clients to obtain information about what services are available to them from a SIP server. This request is therefore usually directed to a SIP server.

BYE requests are used to exit existing SIP sessions.

CANCEL requests have to be used within the context of a SIP transaction for them to have any effect. A SIP transaction is defined as a series of SIP messages: An initial request, which may be followed by some provisional responses and finally, the transaction is concluded by the receipt of a terminal response. SIP responses are described in more detail in this section. Sending a CANCEL request within a SIP transaction terminates the transaction.

REGISTER requests are used by SIP clients to alert SIP servers of the current IP address at which a user is based.

SIP responses carry a status code indicating the class to which the response belongs as well as a human readable sub-text giving a reason to explain the meaning of the response code. The classes of response codes are listed below.

Range Response Class

100—199 Informational 200—299 Success 300—399 Redirection 400—499 Client error 500—599 Server error 600—699 Global failure

A full list of SIP responses is provided in the appendix of this report.

(15)

2.2

Summary

We have seen that the SIP protocol is an application layer protocol that runs on top of IP which characterises it as and end to end protocol and gives it the ability to run on any layer link technology.

SIP messaging follows a transactional model. A SIP transaction is constituted by a SIP request and one or more responses.

(16)

16

CHAPTER 3: System Design

The project aim is the creation of an API for mobile messaging that unifies the SIP and JMS application layer protocols.

This API translates to a library that constitutes middleware for mobile devices. The middleware allows the same application to be ported from one of these protocols to another without having to be rewritten.

More specifically, porting the application from SIP to JMS or vice versa would involve reconfiguring the middleware while maintaining the application as it was originally written.

A further feature incorporated into this project is a server side conversion of messages from SIP to JMS and vice versa. A deeper understanding of this concept is gleaned from a detailed dissection of wireless messaging classification. (See section 3.1.1).

The novel API is built by combining existing SIP and JMS APIs. Since both SIP and JMS are application layer protocols according to the classification of the TCP/IP protocol suite, the resulting API stack can be classified as belonging to the same category. Therefore, likewise to JMS and SIP, an application implementing the API stack can run over any data-link layer technology. The scope of this project is restricted to GPRS and WI-FI serving as data link technologies.

(17)

An outline of the proposed system is illustrated below.

Figure 3.1: Proposed Middleware Components

SIP logical server JMS logical server GPRS/ WI-FI GPRS/ WI-FI SIP to JMS JMS to SIP conversion entity KEY Middleware component SIP Message flow JMS Message flow Client Side component Client Side component Server Side component

(18)

18 A message initiated for transmission by an application running on top of the API stack is either a SIP message or a JMS message depending on how the application is configured. As the message is routed through the server side it may or may not be transformed from its original protocol to the other protocol (i.e. SIP to JMS or JMS to SIP before delivery to the recipient.

The middleware delivered by this project can be classified into two distinct components: the server side component and the client side component.

(19)

3.1 Middleware Server Side component

This component implements conversions of messages from SIP to JMS and vice versa. SIP and JMS fall under two distinct wireless messaging classifications.

3.1.1 Wireless Messaging classifications

There are three types of messaging that occur in wireless environments [5].

I. Instant Messaging (IM):

Instant messaging allows real-time or nearly real-time interaction between users and can be used to exchange images, audio and video files, and other attachments. It is best classified as a hybrid genre – its niche lying somewhere between written communication and verbal communication. Instant messaging is nearly synchronous; a property it shares with verbal communication, but at the same time can be attended to when opportune as is the case with verbal communication [6].

This project’s scope of SIP is specific to its use in facilitating Instant Messaging for simple text messages. The reason for this restricted view of SIP capabilities is provided in section 3.2. In the space of this project, the SIP messaging aspect of the middleware falls in this category.

II. Store and Forward Messaging:

The principle behind store and forward messaging is the asynchronous transmission of messages between clients and the use of server infrastructure to facilitate storage of the messages as they are routed from one client to another. This is described more elaborately in the accompanying JMS report by Lekometsa Mokhesi.

(20)

20 III. Unified Messaging:

Unified messaging defines a concept of a single mechanism that unifies other messaging systems. Users can access all messaging services from a single access point [5].

This principle is essentially implemented by the middleware server side component (Figure 3.1). In detail, the server side component achieves interoperability between instant messaging and store and forward messaging.

In executing the conversion of a message from a SIP message to a JMS message, the server side component is actually receiving an instant message from one client, storing it in the JMS server and eventually forwarding it to the recipient client.

Similarly, in the conversion of a JMS message to a SIP message, the server side component is receiving a forwarded message from one client, which it may or may not store on JMS server for a period of time before relaying it as an instant message to the recipient client.

Use cases that justify the above scenarios are listed below.

Use case 1: SIP message recipient is disconnected before SIP message can be routed to him/her (SIP to JMS conversion).

The approach we took in using SIP to implement Instant Messaging relies on a SIP server proxy-ing all messages and their subsequent responses between clients. This is illustrated on the next page (Figure 3.2).

(21)

This implementation is described in more detail in the client side middleware component architecture (Section 3.2).

In a situation where Laura’s connection to the proxy server is interrupted before the message reaches her from the proxy server, the message could be stored in order for it to be forwarded to her later when connectivity with her is resumed (Figure 3.3).

In this case the SIP proxy server cannot be completely stateless. This is because the SIP server needs to operate on feedback from proxy-ing the message to the recipient client. According to the SIP reliability mechanism, the SIP proxy server will keep

SIP proxy server MESSAGE “Hi Laura” MESSAGE “Hi Laura” 200 OK 200 OK

SIP Client SIP Client

SIP proxy server

MESSAGE “Hi Laura”

Laura was connected to the proxy at the time the message was generated by disconnects abruptly before the message reaches her

Figure 3.2: SIP Instant Messaging

(22)

22 retransmitting the message to the recipient client if it does not receive a response within a certain time frame.

The SIP reliability mechanism is built to cater for the fact that in multiple hops between two end points data packets could be lost because a reliable transport mechanism cannot be guaranteed from one end point, across multiple hops, to another. Therefore in order to ensure that SIP messages reach their destination, a SIP entity, be it a SIP client or a SIP proxy server, will keep retransmitting a request until it receives a response.

A time out scheme can be implemented at the SIP proxy server here such that after a certain period of not receiving a response from Laura the message can be stored for retransmission when connectivity with Laura is re-established.

Since SIP is a real-time protocol it has no provision/functionality for message storage. This is where a JMS server comes in. The JMS server and the SIP server are two distinct logical servers but could in fact sit on the same physical server.

Laura can re-establish connection with the server side architecture by either a SIP or a JMS connection. If she is connected via JMS the stored message should be relayed to her. If her connection is a SIP connection, the stored JMS message would first have to be converted to a SIP message before it is transmitted to her.

Use case 2: JMS message sitting on server infrastructure awaiting user connection (JMS to SIP conversion).

As previously mentioned, the SIP and JMS servers can sit on the same physical server and this is the case in our implementation.

Consider a case where a JMS message was sent to Laura’s JMS queue in the absence of a JMS connection between her and the JMS server. JMS does not provide any form of notification for its clients about messages that are waiting for them on the server. Clients can only receive their messages when they acquire a JMS connection to the server. Because there is no notification of a message waiting for a client, a client cannot know to log onto the JMS server and might not do so for a long time.

(23)

The conversion of messages from SIP to JMS comes in handy in facilitating the speed up of the flow of messages through the server infrastructure. In the context of the aforementioned example, Laura can receive the messages on her JMS queue regardless of which protocol she uses to log on to the server infrastructure. More specifically, if Laura logs on to the SIP server which is on the same machine as the JMS server where some messages are waiting for her, she should still be able to retrieve the messages. This would involve the conversion of the messages to SIP messages which are subsequently transmitted from the SIP server to Laura.

(24)

24 3.1.2 Middleware Server side Component lay out

Physical server

Figure 3.4 Middleware server side component

The database server in Figure 3.4 above contains information that binds an individual’s SIP URI to their JMS queue name. A JMS queue name identifies an individual’s queue at the JMS server where messages are stored exclusively for their retrieval. This mapping facilitates a conversion between SIP and JMS because it is possible to identify an individual’s unique SIP address and JMS queue as belonging to the same entity. Let us observe how the infrastructure functions in Use Cases 1 and 2 mentioned above.

Use Case 1

Here the SIP message originally destined for Laura is retained on the SIP server as a result of failure to receive a response from Laura confirming receipt. The SIP server, after a reasonable time lapse of failure to receive a confirmation from Laura can call the entity conversion class.

The entity conversion class implements both the SIP and JMS APIs and therefore both libraries are available for method calls within the same class. The SIP message is passed to the entity conversion class as a parameter. Once the SIP message is

JMS logical server

SIP logical server

Database logical server Conversion Entity class Database calls

(25)

obtained, the entity conversion class can converts it to a JMS message in a series of steps.

STEP 1: Obtain corresponding JMS queue name

This step is necessary so that the JMS server knows where to store the message for exclusive retrieval by Laura.

This step is achieved by obtaining Laura’s SIP URI from the headers of the message it is passed. The class then performs a database call to the Database logical server. For our testing purposes, the database contains a table that maps SIP URIs to JMS queue names as shown below.

Figure 3.5 Database mapping of SIP URI to JMS queue

As a point of note, let us be aware that the entity conversion class implements a desktop JMS client. The reason for this is the fact that JMS servers are passive entities in JMS messaging and therefore cannot actively send any messages to JMS clients. The Conversion Entity class requires this active messaging capability as we will see in subsequent steps.

SIP URI JMS QUEUE

(26)

26 STEP 2: Creating a JMS message with a body identical to that of the SIP message

The Conversion Entity reads the SIP message body and uses this data to create an identical JMS message.

STEP 3: Sending the JMS message out to the JMS server for storage

The Conversion entity uses its desktop JMS client implementation to act like any other JMS client and send the message to the correct JMS queue on the server.

The message is stored on the JMS server and is retrieved like a normal JMS message when Laura instantiates a JMS connection with the server side architecture.

Use Case 2

For the purpose of refreshing our memories, let us re-note that this use case involves conversion of messages from JMS to SIP to facilitate the faster flow of JMS messages through the server side. If the messages are equally obtainable for both SIP and JMS connections then they are more likely to be retrieved.

When a client logs on to the server side infrastructure of our system using a SIP connection, he has the option to specify whether he would like to retrieve any JMS messages that might be waiting in his queue while he embarks on a SIP session with a third party (not necessarily the original sending party) mediated by the SIP server.

If he opts for this then the SIP server calls the Conversion Entity class passing the client SIP URI as a parameter. The Conversion Entity class executes the steps subsequently listed.

(27)

STEP 1: Obtain corresponding JMS queue name

This occurs exactly as in step 1 for use case one. This time our intention is to listen to the JMS queue and not to send a message to it.

STEP 2: Listen to the client’s JMS queue on behalf of them to receive any JMS messages

The desktop JMS client is invoked and does this

STEP 3: Messages retrieved by the desktop client converted to SIP messages

The Conversion Entity class copies the body of a retrieved JMS message and writes this content to the body of a new SIP message. The Conversion Entity class returns the SIP message to the SIP servlet class that called it.

STEP 4: Messages delivered to client

Fortunately SIP servlets can be used to actively send SIP messages. The SIP servlet

(28)

28

3.2 Middleware Client Side component

The client side component of our middleware toolkit consists of an API stack which is an integration of the SIP and the JMS API stacks for wireless messaging.

Specifically SIP is used here to implement instant messaging for simple text messages. This restricted integration of SIP functionality into our toolkit is necessitated by the narrower scope of JMS. The latter protocol is used strictly for sending text messages. Therefore the two protocols can only be integrated effectively in order to facilitate text messaging.

As aforementioned, SIP is used to facilitate instant messaging while JMS represents store and forward messaging. JMS client side messaging is discussed in detail in Lekometsa Mokhesi’s accompanying thesis.

SIP can be used to implement instant messaging in two variant ways. These are explained below.

I. Using SIP to create a multimedia session to envelope Instant Messaging

As previously mentioned, SIP is used to distribute session description parameters among potential session participants. SIP is therefore not directly involved in specifying the type of multi media session but merely facilitates this by carrying this information inside the bodies of SIP messages that commence the SIP session. Thus the description/specification of a real time multi media session is decoupled from its facilitation by SIP.

In this respect, SIP can be used to establish a session that distributes client parameters for Instant Messaging.

For example, Instant Messaging could be implemented using simple socket programming. In such a scenario the clients can specify their socket parameters inside

(29)

the bodies of the INVITE and 200 OK SIP messages that initiate the SIP session (Figure 3.6).

Figure 3.6: Instant Messaging within the context of a SIP session

The invite in Figure 3.6 above could look something like this

Figure 3.7: Invite request with media session parameters socket://137.158.59.74:3333

INVITE sip:LAURA@domainB SIP/2.0 Call-ID: c88e5d019641c7cac1382de09f9f8c52@domain B CSeq: 1 INVITE To: <sip:LAURA@domainB:9000> From: <sip:BOB@ domainA:9090>;tag=1272335096 Content-Type: text/plain Content-Length: 23 INVITE 180 RINGING 200 OK ACK

INSTANT MESSAGING SESSION BYE

OK

Message header

Message body containing Bob’s client socket parameters

(30)

30 The 200 OK response would appear as below

Figure 3.8: Invite request with media session parameters

In specifying his client socket parameters Bob’s SIP User Agent lets Alice’s SIP User Agent know which socket he is listening on for instant messages. Similarly, Alice’s socket information becomes available to Bob.

II. Using SIP as the Instant Messaging protocol itself

This approach to using SIP in Instant Messaging involves a less formal approach to SIP utilisation that may or may not involve the actual establishment of SIP sessions.

A new SIP method called MESSAGE was defined in the extensions to the SIP toolkit. The purpose of this new method is to carry in its body the message that a sender writes. When a MESSAGE request is received at its destination its message body can be extracted and read (Figure 3.9).

SIP/2.0 200 OK Via: … To: <sip:BOB@domainA:9000> From: <sip:LAURA@ domainB:9090>;tag=1272335096 Content-Type: text/plain Content-Length: 23 socket://137.158.59.74:2020 Message header

Message body containing Alice’s client socket parameters

(31)

In the example below Bob and Alice wish to communicate text messages via an Instant Messaging facility. Bob keys in the message “How now brown cow” at his end point and sends it in the body of a SIP MESSAGE request. Laura receives the SIP request and can obtain the instant message by reading its message body. Instant Messaging can therefore take place back and forth between Laura and Bob utilising the same approach.

Figure 3.9: Invite request with media session parameters

In the development of our toolkit we decided to opt for the second approach where SIP is the actual instant messaging protocol. This introduces reliability into our system as we know the instant messaging protocol is always SIP.

3.2.1 Client side Component API

The client side component is comprised by our middleware API stack which is an integration of the SIP and JMS APIs. The new API contains the following classes.

I. Class: JMSIPConnector

This class returns a generic connector object.

I.1 Methods

It has one important method: JMSIPConnector.Open. This method takes a string representing the desired connection type (whether SIP or JMS) as well as the IP

MESSAGE “How now brown cow”

(32)

32 address of the SIP/JMS server. It returns a connection object to the specified server. If SIP was specified as the desired protocol in the JMSIPConnector.Open method call returns a connection to the SIP logical server. If JMS was specified as the desired protocol the method call returns a connection to the JMS logical server. In our system implementation these are on the same machine.

II. Class JMSIPMessage

This class defines a generic structure called a JMSIP message. This structure has a JMS message object as well as a SIP Client Connection object which is used to generate SIP messages.

II.1 Methods The class contains:

II.1.1 Get and Set methods for accessing and modifying the JMS message object. II.1.2 Get and Set methods for accessing and modifying the SIP Client Connection

object

II.1.3 Get and Set methods for accessing and modifying the configuration of the JMSIP Message. If this configuration is set to SIP then the class knows that it essentially represents a SIP Client Connection object. If a JMSIPMessage object is JMS configured then it knows it represents a JMS message.

II.1.4 Get and set messages for accessing and modifying the content of a JMS/SIP message body. These are the getPayload and setPayload methods.

Example: Configuring a JMSIPMessage object to JMS and subsequently calling the setPayload method will set the message body of the JMS message object associated with it.

II.1.5 setHeader and addHeader methods used to modify the headers of SIP messages.

(33)

III. Class JMSIPFactory

This class defines an object that is used to generate JMS/SIP entities.

III.1 Methods

III.1.1 Get and Set methods for accessing and modifying a parameter that specifies the type of JMSIP factory object, whether SIP or JMS.

III.1.2 A createMessage method. This method returns a JMSIPMessage object. III.1.3 A send method that takes a JMSIP message parameter as well as IP connection

(34)

34

CHAPTER 4: System Implementation

This chapter provides a specification of the software that was used in the development of the API and middleware platform. The entire platform is written in the Java programming language and is therefore useful for the development of Java based messaging applications.

Software components

Component Software used

SIP Server BEA Weblogic SIP server 30

JMS Server Jboss JMS server

Database Server

MySQL Server 5.0

Database Driver MySQL Connector/J

Software development tools

Component Software used

Interactive Development Environment Netbeans IDE 5.5.1

Java SDK JDK 1.5

Java build tool Apache ant version 2.0

SIP APIs The SIP Servlet Specification (Java

Specification Request 116)

SIP API for J2ME (Java Service Request 180)

(35)

4.1 Server side considerations

In order to run a SIP Servlet application on the BEA Weblogic SIP server the source code is written IDE like Netbeans using JSR 116. We then have to create a new domain on the Weblogic SIP server into which the SIP Servlet will be deployed and from which the Servlet application will run.

In our case we used an already existing SIP Servlet example that comes with the Weblogic SIP server installation. Assuming the Weblogic server is located on C:\ the

example would be available at

C:\bea\sipserver30\samples\sipserver\examples\src\registrar. The key features of this implementation that were important to us are the registrar and location service components that they implement which handle REGISTER requests and communicates bindings (of SIP URIs to IP addresses) to and from a database.

Modifications were made to the SIP servlet java file to incorporate features that our server side infrastructure required. We then used ANT to re-build the code and deploy it onto a running Weblogic SIP server for the appropriate domain.

Jtom server connectivity and configuration issues are discussed in Lekometsa Mokhesi’s thesis.

4.2 Client side considerations

Since the API that we are supposed to deliver is for use in developing wireless mobile applications, it is derived from client side wireless mobile JMS and SIP APIs. With respect to SIP this refers to the SIP API for wireless mobile devices JSR 180.

Initially we developed a purely SIP application using JSR 180 and observed it running over 802.11 as the link layer technology and then over GPRS. We did the same for a strictly JMS application.

(36)

36 Once the API had been fully developed, we rewrote the SIP application with method calls and libraries included from the new API. Likewise, we rewrote the JMS application.

4.3 System Evaluation

Test scenarios were implemented in which a comparison was made between the protocol specific applications and the same applications written using our API. Because SIP is a real time protocol facilitating instant messaging, delay is a factor we wish to avoid. We evaluated the potential delay induced by our API method calls. This is because our API is built on top of existing SIP and JMS method calls and therefore uses additional method calls in order to integrate the two protocols successfully.

We evaluated this delay by comparing a purely SIP application with an application that uses our API and is SIP-configured. Particularly, in order to make this comparison, we evaluated the time it took for a SIP request of type MESSAGE to receive a request confirmation (200 OK). We can call this time T and it is obtained by summing t1, t2, t3 and t4 as illustrated below.

SIP client A SIP client B

SIP proxy MESSAGE MESSAGE 200 OK 200 OK Time t t1 t2 t4 t3 T=t1+t2+t3+t4

(37)

Note:

A timer is run on SIP client A and is initiated immediately SIP client A presses a button on their interface to send a message to SIP client B. The timer is stopped by the receipt of the 200 response from SIP client A.

T can then be divided by two in order to obtain an estimate for point to point communication.

The system was evaluated over both GPRS and 802.11 data links. Results from this experiment are shown below.

Average Point to point time elapsed (T/2) over GPRS (s)

Average Point to point time elapsed (T/2) over 802.11 (s)

Purely SIP application 13.89 8.59

Integrated API SIP-configured application

14.01 10.88

For a particular data link layer technology, the 5 simulations from each API were run alternately e.g. for GPRS we first run a purely SIP simulation, then an Integrated SIP simulation, then a purely SIP simulation, then an Integrated SIP simulation… and so on and so forth. This ensured that any significant difference in results was not attributable to different bandwidth availability conditions.

From the results above are very subjective to the networking conditions. A better evaluation metric is a ratio between the results of a Purely SIP simulation and an integrated SIP simulation for each link layer technology. These are:

GPRS: 14.01/13.89=1.009 802.11: 10.88/8.59=1.267

(38)

38 4.3.1 Discussion

Experimental results show that our API stack does not contribute to any significant delay in SIP instant messaging (increase is by small factor).

(39)

CHAPTER 5: Conclusions

The project met its deliverables:

I) A mobile middleware platform that enables an application to run on either SIP or JMS without being changed. The protocol that the application uses to communicate depends on the configuration of the middleware.

II) An API that can be used to write such an application.

III) Server side component-ware that facilitates conversion from one protocol to another as data travels from sender to recipient.

(40)

40

CHAPTER 6: Future Work

It was noted in this report that SIP application developers might find the toolkit delivered by the project a bit restrictive because it narrows the scope of SIP (restricts usage to text based Instant Messaging) in order to facilitate compatibility with JMS, which is text based. Perhaps it follows that SIP should be combined with a more versatile store and forward protocol (capable of transmitting media – audio and voice components). This would clearly offer more services to application developers.

(41)

CHAPTER 7: References

[1] Wikipedia, The Free Encylopedia. Session initiation protocol .

http://en.wikipedia.org/wiki/Session_Initiation_Protocol. Accessed: 18 September 2007

[2] M. Handley, J. Crowcroft and C. Bormann. “The Internet Multimedia Conferencing Architecture”. Internet Engineering Task Force INTERNET-DRAFT. Accessed: 18 September 2007. Available online:

http://citeseer.ist.psu.edu/cache/papers/cs/1033/http:zSzzSzwww.cse.ucsc.eduzSz~peterz Sz252paperszSzconfarch.pdf/internet-engineering-task-force.pdf. Accessed: 18

September 2007

[3] G. Camarillo. “SIP Demystified”. McGraw-Hill Telecom.

[4] SIP RFC Available online: http://www.faqs.org/rfcs/rfc3261.html Accessed: 18 September 2007

[5] A. K. Adesemowo and W. D. Tucker. “Instant Messaging on Handhelds: An Affective Gesture Approach”. Available online:

http://portal.acm.org/citation.cfm?id=1145675.1145702 Accessed: 18 September 2007

[6] A.Voida1, Wendy C. Elizabeth D. Mynatt1. “When Conventions Collide: The Tensions of Instant Messaging Attributed”. Available online

CHAPTER 1: Introduction

ANISA RAGALO

ANISA RAGALO

ANISA RAGALO

ANISA RAGALO

ABSTRACT

Table of contents:

CHAPTER 1: Introduction

1.1 Overview

1.2 Summary

CHAPTER 2: Background

2.1 The Session Initiation Protocol

Summary

CHAPTER 3: System Design

3.1 Middleware Server Side component

3.2 Middleware Client Side component

CHAPTER 4: System Implementation

4.1 Server side considerations

4.2 Client side considerations

4.3 System Evaluation

CHAPTER 5: Conclusions

CHAPTER 6: Future Work

CHAPTER 7: References