Embed Size (px)
Citation preview
1
ANISA RAGALOANISA RAGALOANISA RAGALOANISA RAGALO
RGLANI001RGLANI001RGLANI001RGLANI001
Supervisor: Prof. Ken MacGregor University of Cape Town Date: 22 -October -2007
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
Table of contents:
Abstract ..............................................................................................................................1 Table of contents: .............................................................................................................2 Chapter 1: Introduction ....................................................................................................3 1.1 Overview .....................................................................................................................3 1.1.1 What is being implemented... 3
1.1.2 Why is it important?....................................................................................................4
1.2 Summary………….. ...................................................................................................4 Chapter 2: Background.....................................................................................................5 2.1 The Session Initiation Protocol….…........................................................................5 2.1.1 SIP and IP connectivity...............................................................................................6
2.1.2 SIP: Session Establishment, Modification and Termination…..............................9
2.1.3 SIP requests and responses……………………………………………..…………..12
2.2 Summary………….. .................................................................................................14 Chapter 3: Design............................................................................................................15 3.1 Middleware Server Side component......................................................................18 3.1.1 Wireless Messaging Classifications...................................................................18 3.1.2 Server side component lay out…........................................................................23 3.2 Middleware Client Side component.......................................................................27 3.2.1 Client Side component API..................................................................................30 Chapter 4: System implementation...............................................................................33 4.1 Server side considerations......................................................................................34 4.2 Client side considerations .......................................................................................34 4.3 System Evaluation……............................................................................................35 4.3.1 Discussion....................................................................................................37 Chapter 5: Conclusions..................................................................................................38 Chapter 6: Future work...................................................................................................39 Chapter 7: References....................................................................................................40
4
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
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
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
Figure 2.1: Resource wastage in the circuit switching paradigm (Adapted from [3])
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
Figure 2.2: IP networking (Adapted from [3])
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
� 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
200 OK
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
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
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
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.
JMS messaging is classified as a store and forward messaging protocol.
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
Figure 3.3: SIP Transmission disruption
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
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
Sip:[email protected] RabbitHole
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
sends the messages directly to the client.
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@domainB 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
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”
200 OK
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
information. It is used to send either a JMS or SIP message depending.
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
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
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
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
http://portal.acm.org/citation.cfm?doid=503376.503410 Accessed: 18 September 2007
