Ip multimedia subsystem

This dissertation has been submitted by a student. This is not an example of the work written
by our professional dissertation writers.

Introduction

IP Multimedia Subsystem (IMS) and Session Initiation Protocol (SIP) technology is behind
many popular next generation telecommunication services like Voice Over IP (VOIP), Call
Conferencing, Video calls, Presence and location based services, etc . One number service is
among such wonderful services that can revolutionise the whole concept of mobile phone
usage.

Due to the myriad of applications made possible by both cellular and internet
communication, many people today are bound to keep multiple contact devices (e.g. home
phone, oce phone, cell phone, e-mail address, soft-phone, etc) and hence multiple contact
numbers. Managing multiple numbers is no easy task and can become quite cumbersome,
especially when one has to distribute his contact info. It is common practice for people with
multiple contact numbers to use dierent visiting cards while distributing their contact info in
order to keep their privacy intact. For example, a mobile phone number to friends and close
relatives, oce phone number to business associates and colleagues and so on. Although
this is helpful to keep the work, friends and family numbers separate, it is not easy for users
to manage several visiting cards and contact lists for dierent people.

One Number Service is a panacea in such situations. It allows a user to keep his/her devices
and consolidates several numbers into one number which he/she can use and distribute. The
user can only be contacted via that single number and he/she does not need to worry about
managing multiple numbers any more.

In addition to combining several numbers, One Number Service is also capable of providing
the Find me/Follow me kind of service. Imagine a situation, you are having a late afternoon
tea with your colleagues in the oce cafeteria, you have just got your cell phone with you
and at that point in time your boss calls to check if you are at your desk, your desk phone
rings and your boss is upset that you are not there. This doesnt leave a very pleasant
impression on your boss and the last thing you would want to do is to make your boss
infuriated. This could have been avoided, had there been a setup which would instantiate a
call to both your cell phone and desk phone simultaneously. One number service facilitates
the user to segregate the callers in pre specied groups and set the preferences for each
group dening the ring pattern for each of his/her devices.

Reaching people with multiple contact numbers is an even bigger headache, just imagine a
friend trying to reach you; he/she will have to try on all of your numbers to get a hold of you
somewhere. In order to avoid this, one option would be to send all of your contacts an SMS
notifying them of your availability on cell phone for week days and on home phone for the
weekends. It is even worse when a person changes his job, cell phone operator, landline
number, etc; he has to notify all of his contacts about his new numbers. Not to mention the
frustration we feel when we get business calls on our home phones and calls from friends and
family on work phones. Such situations motivate the developer to create a service that can
eliminate the headaches of managing contact lists. Thanks to One Number Service
everything is taken care of. The callers no longer have to track you down by dialling each of
your numbers in turn. No longer does it matter if you are home, at work or in the cafeteria.
Nor it is the concern of the user to manage the contacts distinctively so that none of them
calls you at a place where you do not want to be contacted.

One Number Service allows the users to take care of just one number and leave everything
else on the service itself. When a user subscribes to the One Number Service he/she gets an
application on his/her mobile platform with an easy to use user interface that lets the user
manipulate his/her contacts in many ways. For example, a user can specify the group (Friend,
Family, Boss, Colleague, etc) while adding a new contact in the mobile phone and can set
rules for each group, dening where the calls should be directed. For instance, for Friends
only cell phone should ring, for Boss all phones should ring simultaneously and so on.

Literature Review

The text in this chapter presents the account of current practices to provide one number
service. The reasons why this service in its current form has not got much popularity and its
limitations will also be explained in this chapter. Eort will be taken to justify the One
Number Service developed during this project and the services already available in the
market.
One number service is not completely new innovation; the companies like Google [6],
GrandCentral [2] and LinxConnect [7] do provide sort of similar services. The subsequent
section discusses One Number Service provided by these companies.

GrandCentral One Number For Life Service:

Searching on the internet about one number service returns quite a few results, most
prominent being the GrandCentral One Number for Life service. GrandCentral [2, 3] (now
Google Voice) is a web application that lets the user combine all of their phone numbers into
one number, which essentially means someone can call the user of the service on his/her
GrandCentral phone number and all of their phones (cell phone, work phone, home phone)
will ring according to a set pattern. GrandCentral one number application also provides the
facility to x rules for four categories (friends, family, work, and others) prexing as to where
the calls should be routed in case a user belonging to any of the dened categories calls.

GrandCentral One Number For Life Features:

According to [4], GrandCentral one number application has following features:

i. Incoming phone calls rings on dierent phones according to which group youve placed a
callers phone number in.

ii. Voice mail can be listened to and replied to with just a few clicks.

iii. Voice mail messages can be listened to in real time and you can jump in to initiate a
conversation in real time with one click just like answering machine.

iv. Just like Jajah VOIP service [5], GrandCentral can place a call between both the person who
left a message on the voicemail and users phone with the click of the mouse.

v. GrandCentral allows seamless switching from one registered phone to another.

Google Voice

Google having taken over the GrandCentral, is intending to provide the one number service
in near future. Google Voice will provide its customers a Google number (a toll free number)
which will be attached to all of their devices. Google Voice will also provide an easy to use
web interface that will let the users to do any necessary amendments in the predened
settings. Google Voice is true extension of GrandCentral service with some advanced
features such as call conferencing, voicemail transcripts, call switching, etc. The website
mentioned in summarizes the features of Google Voice, some of them are;

i. A user can listen in the call before attending it.

ii. Unwanted callers can be blocked. Prank calls, or calls from telesales representatives can
be redirected to a spam folder and the user will never get calls from these callers again.

iii. Google Voice allows the users to answer a call on any of their devices.

iv. Google Voice lets the user to put his contacts into categories and set rules for each
category, making the phones to ring based on what category caller is in.

v. Google Voice converts the voice mail messages into text transcripts enabling the users to
read the voicemails.

Linx Connect:

Linx Communication provides a single toll free phone number which subscribers can use for
real-time access to calls, messages and faxes. LinxConnect also provides an easy to use web
interface (LinxWeb) that lets the user to manage his/her calls, faxes and messages from any
Internet connected computer. Some of the key features of LinxConnect service mentioned on
Linx Communication ocial site are;

i. It provides the facility to ring multiple devices simultaneously (parallel calls).

ii. LinxWeb, the web interface designed for LinxConnect can be used to make click-to-dial
based calls.

iii. Allows the users to send group messages, broadcast messages as well as multiparty
faxing.

iv. Allows, conference calling between maximum of nine users.

Although the services discussed above are very robust and feature rich, they all have some
limitations. For example, the user interface provided for users to make amendments in the
predened settings is web-based hence the user requires an internet enabled PC in order to
make amendments to the contact list, re-dene the ringing pattern for devices, etc. This is
not a very ecient solution from users point of view; they would rather want such interface
to be available to them in their mobile phones so that they can make amendments in the
settings whenever and wherever they want without connecting to the internet. The User
Interface for the one number service is a small software package designed and developed in
J2ME, that lets the user to dene settings as well as do changes in the settings.

Secondly, these services are only compliant with VOIP and none of above mentioned
companies provides the service on the cellular platform. This makes the use of the service
limited to a few numbers of users.

One number service is the among many wonderful features provided by Voice Over IP (VOIP)
today, though it has been in the market for quite sometimes but never really got full
recognition. This is due to the fact that the service providers have kept the service limited to
VOIP and soft phones and none of them has really tried to integrate this wonderful
application within the realm of cellular networks. This service would not have been possible in
a cellular outset few years back when we did not have the IMS and 3G/NGN networks but
today with operators more keen on integrating the cellular and internet communication, such
services can be made possible in the matter of days.

The subsequent chapter; discusses two key elements i.e. Session Initiation Protocol and IP
Multimedia Subsystem which have made possible the creation of One Number Service.

Discussion

IP Multimedia Subsystem and Session Initiation Protocol technology has made possible many
promising telecom services, like presence service, call conferencing, instant messaging and
push to talk over cellular PoC and so on. IMS and SIP are backbones of this project and it is
only fair that they are explained rst before moving on to the explanation of the design and
development aspects. Hence, in this chapter, a brief description of the IP Multimedia
Subsystem (IMS), its network architecture and the network components is presented. This is
followed by an overview of Session Initiation Protocol (SIP) functionality.
IP Multimedia Subsystem (IMS):

According to [9], IMS is a standardised all-IP and SIP based architecture for network operators
wishing to oer range of multimedia services especially real time services to enhance user
experience and increase revenues. IMS combines the traditional voice calls and emerging
new multimedia applications. IMS was initially introduced by 3GPP [10] in two phases- release
5 and release 6 [11] for UMTS networks. 3GPP has done the majority of work in dening the
core elements and their functions in IMS system as well as nalized the Session Initiation
Protocol (SIP) as the communication protocol.

IMS is an open, unied architecture that denes how applications and services can be
delivered to customers regardless of what network they are connected to.

According to [9], IMS can be considered as analogous of a router in IP layer. Unlike IP router,
IMS carries signalling and bearer trac over the IP layer and delivers the trac to a server in
accordance with the user prole and the application requirements instead of nding the best
route for transferring packets to the next hop as an IP router. IMS integrates the services in
single plane and is oblivious of underlying network technology enabling users to have
enriched experience with voice, video, and data happening simultaneously.

IP Multimedia Subsystem Network Architecture:

Ericsson the leading IMS solution provider explains the IMS architecture in [9]. According to
3rd Generation Partnership Project (3GPP) [11], IMS is composed of three layers-Connectivity
Layer, Control Layer and Service Layer. The gure: 3a shows three layers in IMS architecture.
Functional details of each layer as explained by Ericsson are described bellow;

Service (Application) Layer:

According to [9], the Service or Application Layer contains the application servers. These
servers execute the mobile multimedia application for end users and interface with the CSCF
using SIP Protocol.

Control Layer:

The Control Layer as dened in [9], is the core layer in IMS. It comprises a number of
controllers and function servers to control and manage calls, session set-up and resource
allocation.

Connectivity Layer:

Connectivity Layer consists of routers and switches both for the backbone and the access
networks. These routers deliver the IP packets to CSCF which routes the packets to their
destination.

IMS Network Components:

The architecture dened above is just a logical structure; there are network entities such as
HSS, CSCF and MGCF which actually form the IMS network. In the following, the description of
IMS functional component is provided. According to Ericsson [9], an IMS setup should at least
consist of the following functional components.

Home Subscriber Server (HSS):

As explained in [9], the Home Subscriber Server is the master database that contains the
subscriber information to support the network entities handling calls and sessions. It provides
the access authorization, authentication, service provisioning support and service
authorization support. When a user registers in the IMS domain, the users service prole
(services to which the user is subscribed) is downloaded from HSS to CSCF which is then used
by CSCF to serve the user.

Call Session Control Function (CSCF):

The author in [9] denes the Call Session Control Function as the heart of IMS network. CSCF
is used to process SIP signalling. There are three variants of CSCF, the details on how do they
function are provided bellow;

Proxy-Call Session Control Function (P-CSCF):

As explained in [12], the Proxy-Call Session Control Function is a SIP proxy that is the users
rst point of contact with an IMS domain. The main function of P-CSCF is to forward SIP
REGISTER requests received from the User Agent to an I-CSCF determined using the home
domain name (e.g. ericsson.com) provided by the user and forwards directly to the S-CSCF
when the users home network corresponds to the P-CSCF domain. P-CSCF determines the
addresses from registration process, if the address is already determined, P-CSCF hands over
the SIP requests and responses received from the user to an S-CSCF.

Interrogating-Call Session Control Function (I-CSCF):

According to [12], the I-CSCF acts as a SIP proxy located at the edge of the administrative
domain. The address of the I-CSCF is listed in the DNS. When the S-CSCF or P-CSCF tries to
nd out the next SIP hop in the destination domain for a particular message, the address of I-
CSCF is obtained from DNS.

Serving-Call Session Control Function (S-CSCF):

Ericsson Developers Guide [12] explains the Serving-Call Session Control Function (S-CSCF)
as an entity that communicates with the HSS to get the service prole for the user. The
service prole contains one or many Initial Filter Criteria (iFC). The iFC denes a condition for
the activation of a service and the application server to which the request is going to be
forwarded. Each iFC contains one or more Service Point Triggers (SPTs) that identify the types
of request that can trigger the iFC. The SPT applies to the Request-URI, the session-case,
headers, or SIP methods.

SIP AS:

According to [9], an IMS setup consists of one or more SIP Application Servers. All the
services in the IMS are executed in SIP Application Server.

Session Border Controller (SBC):

Session Border Controller is an IP to IP gateway deployed at the border of two dierent

networks. For a broadband access, the P-CSCF and the policy enforcement functionality can
be implemented as a SBC supporting the user to network interface. [9]

Media Gateway Control Function:

The Media Gateway Control Function is responsible for controlling the media resources used
when trac needs to ow between networks using dierent media. For example, between a
TDM network such as PSTN and an IP network. [9]

When these components described above, are put together to form an IMS setup, a feature
rich, seamless network is yielded as a product. The network can provide a highly ecient and
exible platform to integrate any type of network technology be it wired (PSTN, CSN) or
wireless (Wi-Fi, WiMAX, GSM, CDMA, etc) to provide attractive next-gen services.

Session Initiation Protocol SIP:

Session Initiation Protocol (SIP) is an application-level signalling protocol dened by Internet

Engineering Task Force (ETF) in [RFC 3261] [13] for the creation and management of
sessions over an IP network. RFC-3261 [13] denes the session initiation protocol (SIP) as;

An application-level control protocol for establishing, modifying, and terminating multimedia

sessions between one or more participants. SIP supports multimedia conferencing, Internet
telephone calls, registration and redirection services, and is easily extended.

RFC-3261 [13] describes the SIP to be based on an HTTP-like request/response transaction

model. Meaning, each SIP transaction consists of a request that invokes a particular method
on the server, the server in turn sends the response or forwards the request to another
server for further handling. SIP itself is not capable of providing services. Rather, SIP can
provide initiatives that can be used to make and implement dierent services.

SIP Addressing:

The SIP architecture supports SIP URI (Universal Resource Identier) based addressing to
identify dierent users in the network. [13, 15] A SIP URI identies communication resources
(domain) and contains enough information to initiate and maintain a communication session
with the resource to which that URI belongs.

As explained by Rogelio Martnez Perea in [14]. A SIP URI consists of an initial prex sip:
and is composed of two parts (user part and host/domain part) separated by the @ sign.

Example:
sip:[email protected]

Above example shows the basic SIP URI format. The prex sip: in SIP URI implies that the
user is a part of a network which uses SIP as an underlying protocol for session establishment
and tear down. Next, is the user part, which identies a particular resource (user, terminal or
service) at the host being addressed. In the above example kumar is the user part. The
address completes with the host part, which identies the source providing the resource. It
usually is a Domain Name or an IP address plus port value of the server serving the user. In
the example above this is shown as ericsson.com.

SIP Messages:

RFC-3261 [13] denes a SIP message as, Data sent between SIP elements as part of the
protocol. SIP is a text-based protocol and uses the character sets to form a message. A SIP
message is either a request from a client to a server, or a response from a server to a client.
Request and Response messages are further explained bellow;

SIP Requests:

Request is dened in RFC-3261[13] as a SIP message sent from a client to a server, for the
purpose of activating a particular operation or method on the server. Meaning SIP requests
are like method calls used to invoke particular method on the server.

As per RFC-3261 [13], a Request method is composed of three parts: a Method name, a
Request-URI, and the protocol version separated by a single space character. The format for
Request method as dened in [13] is shown bellow followed by the description of each eld

Request-Line = Method SP Request-URI SP SIP-Version

Request Method: RFC-3261 [13] denes six methods for Request message; REGISTER for
registering contact information, INVITE, ACK, and CANCEL for setting up sessions, BYE for
terminating sessions, and OPTIONS for querying servers about their capabilities.

Request-URI: As described in RFC-3261 [1], the Request-URI (also known as To address) is a

SIP or SIPS URI that indicates the user or service to which this request is being addressed.
This means RequestURI refers to the address of the called party in a SIP session.
SIP-Version: As described in RFC-3261 [1] both request and response messages should
include the version of SIP in use i.e. SIP/2.0, to be compliant with the specications set out
in RFC-3261.

SIP Responses:

RFC-3261 [13] denes the Response message as a SIP message sent from a server to a
client indicating the status of a request sent from the client to the server. The Response
method is analogous to the return value of the method invoked by the Request message.

The SIP responses as described in RFC-3261 [13] consist of three values, the protocol version,
a numeric Status-Code and its associated textual phrase called Reason Phrase. The format of
the SIP Response message as specied in RFC-3261 [13] is shown bellow followed by
description of each eld;

Status-Line = SIP-Version Status-Code Reason-Phrase

As explained earlier, SIP version is the protocol version of the SIP specication in use. The
Status-Code is a 3-digit integer result code that indicates the outcome of the request. The
Reason-Phrase gives a short description of the status-code. The Status-Code value denes
the class of response- it describes whether or not the request is being processed. According
to RFC-3261 [13], status code can have six possible values which are:

1xx: Provisional Response which means the server received the request received and is
trying to process it (e.g. 100 TRYING).

2xx: Success Response-the request was successfully received, understood, and accepted,
2xx Response is also called nal response. (e.g. 200, OK)

3xx: Redirection Response-meaning further action needs to be taken in order to complete the
request (e.g. 300 Multiple Choices).

4xx: Client Error Response- meaning the request contains bad syntax or cannot be fullled at
this server (e.g. 404 Not Found).

5xx: Server Error Response- meaning the server failed to full an apparently valid request
(e.g. 500 Server Internal Error).

6xx: Global Failure Response-the request cannot be fullled at any server (e.g. 600 Busy
Everywhere).

Important SIP Terms:

Before going into the details of SIP Sessions, it is necessary that the reader should be clear
about some commonly used SIP terms as they will be used very often in the discussion in
subsequent chapters. Hence, following is the list of signicant terms that are used very often
in SIP jargon.

User Agent Client (UAC): As per RFC-3261 [13], a user agent client is a logical entity that
creates a new request, and then uses the client transaction state machinery to send it. The
role of UAC lasts only for the duration of that transaction. In other words, if a piece of
software initiates a request, it acts as a UAC for the duration of that transaction. If it receives
a request later, it assumes the role of a user agent server for the processing of that
transaction.

User Agent Server (UAS): As per RFC-3261 [13], a user agent server is a logical entity that
generates a response to a SIP request. The response accepts, rejects, or redirects the
request. This role lasts only for the duration of that transaction. In other words, if a piece of
software responds to a request, it acts as a UAS for the duration of that transaction.

Call: RFC-3261 [13], describes a call as an informal term to refer to some communication
between two end devices, generally set up for the purposes of a multimedia conversation.

Dialog: As per RFC-3261 [13], a dialog is a peer-to-peer SIP relationship between two user
agents that persists for some time. A dialog is established by SIP messages, such as a 2xx
response to an INVITE request. A dialog is identied by a call identier, local tag, and a
remote tag.

SIP Server: SIP server or SIP Application Server (SIP A/S) is an entity that serves two or more
user agent clients. The SIP A/S is capable of accepting the requests, forwarding them to
target user agent clients, and sending the response back to the rst user agent client. A SIP
A/S can also generate one more provisional response before forwarding the nal response.
SIP Proxy: As per RFC-3261 [13], a SIP Proxy is an intermediary entity that acts as both a
server and a client for the purpose of making requests on behalf of other clients. A proxy
server primarily performs routing function; that is its main function is to route the incoming
requests to an entity as close to the targeted user as possible. Although Proxy servers do not
make changes in the received requests, they are capable of rewriting the parts of a request
message before forwarding them to another entity.

RFC-3261 [13] denes two avours of SIP proxy, Stateful and Stateless proxy. Stateful proxy
maintains the client and server transaction state machines during the processing of a
request. Whereas, stateless proxy does not maintain the client or server transaction state
whilst processing requests. A stateless proxy forwards every request it receives downstream
and every response it receives upstream.

Back-To-Back User Agent (B2BUA):

RFC-3261 [13] denes a B2BUA as a logical entity that receives a request and processes it as
a user agent server (UAS). In order to determine how the request should be answered, it acts
as a user agent client (UAC) and generates requests.

According to author in [16], a Back-to-Back User Agent (B2BUA) can be considered as a

network based application that achieves level of control over calls not attainable through
proxying and that requires client functionality as well. Unlike a proxy server, a B2BUA
maintains dialog state and must participate in all requests sent on the dialogs it has
established.

SIP Registrar:

RFC-3261 [13], denes a Registrar as a server that accepts REGISTER requests and places
the information it receives in those requests into the location service for the domain it
handles.

SIP Session:

SIP session can be termed as the logical agreement between two SIP entities. SIP session
denes the rules and regulations for the communication between two parties wishing to
communicate over an all IP network. According to author in [14], SIP session is dened in
Session Description Protocol (SDP) and usually includes the set of parameters needed for the
multimedia communication, such as transport addresses or media types on which two parties
in question agree before starting communicating. The SDP specication RFC-2327 [15]
denes a session as, A set of multimedia senders and receivers and the data streams
owing from senders to receivers. For example, a multimedia conference is a SIP session.

Basic SIP Session Setup Example:

Having known the basic details about SIP, let us now see how the sessions are actually
established. In the following paragraph, an example SIP session setup is described which
explains how SIP messages ow to establish a communication session between two entities.

In the simplest case, two users (User-A and User-B) want to communicate with one another
over an IP network. Each user is tied to a User Agent (UA) a software entity that enables the
communication between two users. The UA can be as simple as a soft-phone or as complex
as a 3G/IMS phone. As per RFC-3261 [13], the SIP messages traverse in the following fashion
to connect the two users.

The INVITE message rst ows to an intermediate server known as SIP Application Server
shown as SIP-AS in the gure:3a, which sends back a provisional response (non-nal
response, 180-RINGING response in this example) to the User-A indicating the progress of the
SIP session. The SIP A/S forwards the INVITE request to UserAgent-B. UserAgent-B having got
the INVITE request, can then decide on whether to accept or decline it. If accepted, a nal
response (200, OK) message is sent back to SIP A/S to indicate the agreement for the
session. SIP A/S forwards the OK response to UserAgent-A, UserAgent-A sends an ACK
message back to SIP A/S. SIP A/S forwards the ACK message received from UserAgent-A to
UserAgent-B. At this point the session is established between UserAgent-A and UserAgent-B.
Both parties (UserAgent-A and UserAgent-B) are aware of each others IP address and port
numbers where the data streams will be received, they can now transmit the data to the
corresponding receiver ports, via a separate media connection using an appropriate transport
protocol such as UDP. At the end of the communication, either UserAgent-A or UserAgent-B
can send a BYE message to indicate the session termination. When the other party responds,
the session is ended.
Design Principle Of One Number Service

This chapter elaborates the architecture and design principle chosen to develop one number
service. The chapter also contains the description of components used and their application
within the architecture. A full working principle of One Number Service is also described at
the end of this chapter.

HTTP Section:

As shown in gure:4a, the HTTP section consists of an HTTP server (Apache Tomcat Server
6.0), a Symbian OS compliant mobile platform and a database system (MySQL Server 5.0).
The mobile platform creates an HTTP session with the Apache Tomcat Server in order to
connect to the database system. Apache Tomcat Server in turn connects to MySQL database
system and stores, retrieves and amends the data in the database as requested by the
mobile platform (user). A complete detail of the components is described bellow;

Mobile Platform:

Mobile Platform is the Symbian OS [Appendix-2] based emulation colour phone provided by
Sun Wireless Toolkit 2.5 [Appendix-2]. The phone runs an application program
OneNumberService MIDlet suit designed and developed in Java 2 Micro Edition (J2ME). The
OneNumberService MIDlet is a Mobile Information Device Prole (MIDP2.0) [Appendix-2] and
Connected Limited Device Conguration (CLDC1.0) [Appendix-2] based MIDlet suit that can
run on any Symbian OS based mobile platform. One number service MIDlet suite consists of
four dierent forms developed in J2ME using LWUI (Light Weight User Interface) Toolkit API
[Appendix-3].

Role In One Number Service Architecture:

The main function of OneNumberService MIDlet suit is to provide an ecient Graphical User
Interface (GUI) that lets the user to make amendments in the main database through their
handheld devices. Following list describes the functions performed by the OneNumberService
MIDlet suit;

i. Provides an ecient and easy to use graphical user interface.

ii. Can create HTTP sessions with Apache Tomcat Server.

iii. Can send requests to and receive responses from Apache Tomcat Server.

iv. Allows the user to connect to MySQL database system via Apache Tomcat Server.

v. Allows the user to add his device numbers, contact numbers and the corresponding
preferences to the database.

vi. Allows the user to make amendments in the data already stored in the database.

Apache Tomcat Server:

Apache Tomcat Server [8] is an open source HTTP Servlet container used to test Servlets and
Java Server Pages (JSPs) code. Tomcat 6.0, the latest release of Tomcat, is an implementation
of the new Servlet 2.4 and JSP 2.0 API specications.

Features:

i. Open source, distributed under General Public Licence (GPL).

ii. Easy to congure with Eclipse and NetBeans IDEs.

iii. Supports JDBC Driver, hence, easy to connect with MySQL.

Role In One Number Service Architecture:

In One Number Service architecture, Tomcat Server is serving as an HTTTP servlet container.
The Tomcat Server hosts ve HTTP1.1 compliant servlets each for dierent data storage and
retrieval operations. Following are the main functions performed by Tomcat Server;

i. Hosts ve dierent HTTP servlets, each dierent for dierent database operation.
ii. Can create HTTP sessions with mobile platform.
iii. Establishes connection with MySQL database system using MySQL JDBC driver instance.
iv. Queries the MySQL database system according to the requests of mobile platform.
v. Responds to HTTP requests according to the response sent by MySQL database.
MySQL Server Database Management System:

MySQL Server is the most popular open source SQL database management system. MySQL is
a relational database system that runs as a server providing multi-user access to a number of
databases.

Features:

According to author in [23], MySQL has following features;

i. The MySQL is open source software distributed under GPL (GNU General Public License).

ii. MySQL is a relational database system i.e. it supports declarative method for specifying
data and queries.

iii. The MySQL Database Server is very fast, reliable, and easy to use.

iv. MySQL is a client/server system. There is a database server (MySQL) and many clients
(application programs), which query data from the server and save changes in the server.

v. Supports programming languages such as C, C++, Java, Perl, PHP, Python, etc.

vi. Supported by all major Operating Systems e.g. Windows, Linux, Mac OS, etc.

Role in One Number Service Architecture:

MySQL is the main database management system in one number service application. A
database named mainDataBase is dened within the MySQL server. The mainDataBase as its
name suggests is the central database where entire user related data i.e. Users device
numbers, their contact preferences, and call routing rules are stored. The key functions
performed by mainDataBase database are;

i. Can establish connection with the Apache Tomcat Server.

ii. Stores the SIP URIs of subscribers devices.

iii. Stores the call routing rules for dierent groups.

iv. Stores new contacts with their name, SIP URI and preferred group.

v. Allows connection with the SailFin Application Server.

vi. Can respond to the queries of SailFin Application Server.

vii. Can retrieve the stored data according to the queries of SailFin Application Server.

mainDataBase consists of three tables i.e. rules, numbers and contactperferences

respectively. The structure of the mainDataBase database is shown in gure 4b.

Figure:4b MySQL database mainDataBase Structure

Rules Data Table:

The rules data table holds the char values for call routing rules for a given group. There are
six groups dened in OneNumberService i.e. Friend, Family, Colleague, Boss, Customer and
Student. For a given group, rules data table holds the order in which the devices should be
ringed. It contains ve columns (Group, Home, Cell, Oce and PDA). First column, Group,
stores the name of the group for which the rules are being specied. Each of next four
columns corresponds to the devices registered by the user. These columns store a char value
which is actually a digit between 1 and 4 indicating the order of ringing for that particular
device. For example, if the user wants the Cell phone to ring rst and Home phone the
second when anyone from the Friends group calls then the values in the rules data table
would look like;

Group=Friends, Cell=1, Home=2.

Contactprefrences Data Table:

contactprefrences data table stores the SIP URI of new contacts in the database and the
corresponding group to which it belongs. The contactprefrences data table consists of three
columns (name, URI and Group). The name and URI columns hold the name and SIP URI value
of every new contact added to the mainDataBase database and Group column stores the
group to which this particular contact belongs.
Numbers Data Table:

numbers data table stores SIP URIs of all the devices, the subscriber of one number service
owns. There are currently four columns (Home, Cell, Oce and PDA) specied in the numbers
data table. Each column represents a device and stores a char value which is SIP URI for the
same device. For example, Home column stores the home phone SIP URI and Cell column
holds the cell phone SIP URI.

HTTP Working Principle:

When a new user subscribes for One Number service, he/she will be provided with a software
package that he/she can use to add phone numbers to the database, add/amend contacts
and set preferences for the calls, etc. A prototype software package, OneNumberService
MIDlet suit is designed for One Number Service that provides the database addition or edition
functionality. In order to allow the user to make amendments in the MySQL database,
OneNumberService MIDlet suit creates HTTP sessions with the Apache Tomcat server which
in turn connects the OneNumberService MIDlet suit to the database. This scenario is further
explained by gure: 4d;

1. When a subscriber wants to make the amendments in predened settings, he/she opens
the OneNumberService MIDlet suit available on his mobile platform. Subscriber makes the
amendments and hits the Save or Edit command as appropriate.

2. The OneNumberService MIDlet suit connects to the Apache Tomcat server running on the
port 8080 of the localhost. Having established the connection, the OneNumberService MIDlet
suit creates and sends an HTTP POST request to one of the HTTP servlets (servlet01,
servlet02, servlet03, servlet04, servlet05) running on the Apache Tomcat server. The choice
of HTTP servlet depends on the operation that needs to be performed on the database and
the data table that needs to be updated.

3. The HTTP servlet after conrming the operation to be performed on the data table;
connects to the MySQL Server 5.0 database system which is running on the port 3306 of the
local host.

4. The Server then enquires the data from or updates the data in the mainDataBase
according to the request of the subscriber. After performing the queries sent by the server,
the mainDataBase sends back the response to the server notifying it of whether or not the
data update process is complete.

5. Tomcat server having got the response from the MySQL server, sends the response to
OneNumberService MIDlet suit to let the subscriber know if the database update has been
successful.

SIP Section:

The SIP section completes the architecture of One Number Service. It consists of a SIP Server
(SailFin Application Server), and a virtual IMS setup as provided by Ericsson in Ericsson SDS
4.1 [12]. Main function of SIP section is the routing of incoming calls to one or more devices
registered by the subscriber. When the subscriber of One Number Service is called by an
outside caller, the call after moving through the IMS setup ends up at the SIP A/S which
decides on whether to ring one or all of his/her devices. SIP A/S also determines the pattern
in which the devices should be ringed. The Ericsson Virtual IP Multimedia Subsystem (IMS)
setup emulates the 3G core network functionality; hence, the calls are handled as if they
were from a real 3G cellular network. Further detail of the functions performed by SIP AS and
Ericsson Virtual IMS is provided bellow;

SailFin Application Server:

ProjectSailFin[1] is the only open source SIP container, based on robust and scalable SIP
servlets technology (JSR-289) and Sun Glasssh server. Vince Kraemer, a key developer
involved in the SailFin projectin [19] denes SailFin as a java.net project intended towards
the development of a container for SIP Servlets that implements JSR-289,interoperates with
the other containers and services in the GlassFish server, andtakes advantage of the
infrastructure of the GlassFish server for high availability and clustering.

Why SailFin?

i. Project SailFin is the only open source SIP servlet container.

ii. SailFin is extremely easy to install and congure.

iii. SailFin can easily be integrated with NetBeans IDE 6.1 and Ericsson SDS 4.0.

iv. Supports both .war and .jar based deployment.

Role In The One Number Service Architecture:

In this project, SailFin server is used to host a SIP servlet which is functioning as a Back to
Back User Agent (B2BUA). The main functions performed by SIP servlet and thus SIP A/S are;

i. The B2BUA receives the INVITE requests from the caller, creates a new request with
dierent parameters and forwards it to the callee.

ii. It can forward the callees response back to the caller.

iii. Can create and send ACK request to both caller and callee.

iv. Can perform both parallel as well as sequential forking based on the call routing rules.

v. Can establish SIP session between two user agents.

vi. Can establish connection with MySQL Server database system.

vii. Can query the mainDataBase for the subscribers preference for incoming calls.

viii. Can query the mainDataBase and retrieve the data such as call routing rules, SIP URI for
the subscribers devices, etc.

ix. Can create and send the BYE request to either of callee or the caller depending on who
initiates the session termination rst.

Ericsson Virtual IMS Setup:

Ericsson Service Development Studio (SDS) 4.0 [21] provides a simulated version of IMS core
network making SDS to act as a virtual IMS network for the developers.. As explained in
Ericsson SDS Developers Guide [12], Ericsson SDS supports functionality in the IMS Core
Network to handle registration, authentication, service triggers, routing, and many other
features.
The Ericsson SDS simulated environment consists of the following IMS components:

Home Subscriber Server (HSS):

According to [21], Home Subscriber Server (HSS) is the main data storage for all subscriber
and service-related data of the simulated environment. The data stored in the HSS includes
user identities, access parameters, and service-triggering information. The access
parameters are used to set up sessions and include parameters like user authentication. The
service-triggering information enables SIP service execution. Ericsson studios HSS
perspective, allows the developers to create Initial Filter Criteria (iFC: set condition to trigger
the services) and their corresponding Service Point Triggers (SPT); create, modify, and delete
user proles, service proles, and Public Service Identity (PSI) proles. [12]

Proxy-Call Session Control Function (P-CSCF):

As explained in Ericsson Developers Guide [12], The PCSCF is the rst point of contact of the
client with the network. The P-CSCF acts as a SIP proxy. It forwards messages to either
Interrogating-Call Session Control Function (I-CSCF) or Serving-Call Session Control Function
(S-CSCF) for further handling of messages.

Serving-Call Session Control Functions (S-CSCF):

As explained in Ericsson Developers Guide [12], the S-CSCF is the central point to trigger
services. S-CSCF acts as a SIP registrar, allowing the clients to register so that the network
can subsequently nd these clients and messages can be routed to them. The S-CSCF also
contains the service prole of the users and PSIs (Public Service Ids). The service prole links
a user or PSI with one or many Initial Filter Criteria (iFC).

Domain Name Server (DNS):

SDS includes the BIND DNS server [17]. The DNS maps text and numeric names to an
Internet address. The CSCF uses DNS procedures to resolve a SIP URI into the IP address,
port, and transport protocol of the next hop to contact. It also supports the translation from
telephone numbers to SIP URIs. Ericsson SDS Developers Guide [12] explains the DNS from
service point of view, the DNS resolves the general call ow sessions between users by
matching domain addresses, globalized telephone numbers, IP addresses, and transport
protocols.

These entities put together, provide a virtual IMS setup that allows the developer to develop
and test applications and services just like they would in a real 3G cellular network. In One
Number Service, the IMS setup is utilised for the following functions;

i. To register subscriber devices in HSS and Registrar.

ii. To create and set Service Prole as well as User Prole for new subscribers.

iii. Provides a virtual network domain (ericsson.com) where services can be hosted.

iv. Virtual DNS resolves the tel URI into SIP URI and vice-versa.

v. Automatically routes the call (both incoming and outgoing) through P-CSCF and S-CSCF.

vi. To set the initial Filter Criteria (iFC) and Service Point Trigger (SPT), the two set conditions
in order to invoke SIP servlets.

vii. To invoke the SIP servlet when incoming request meets the initial Filter Criteria (iFC).

SIP Working Principle:

The functionality of the HTTP session is limited only to adding or amending the data in the
database-the HTTP session cannot do much beyond that. For rest of the functionality i.e. call
routing and session establishment, SIP and Ericsson SDS based virtual IMS setup is deployed
in the architecture of One Number Service. Figure: 4e describes the SIP session
establishment based on One Number Service in the simulated environment.

1. The caller dials the one number (SIP URI) of the subscriber of the One Number Service.
The call rst comes at the Proxy Call Session Control Function (P-CSCF) which is the rst
point of contact in the virtual IMS setup.
2. The P-CSCF rst checks with DNS and Registrar if the requested SIP URI exists in the
current domain (ericsson.com).
3. If the intended SIP URI is found in the DNS and Registrar, the DNS noties the P-CSCF to
continue with call forwarding. P-CSCF routes the call to S-CSCF which performs the rest
 of call routing function.
4. The S-CSCF asks the HSS for the subscriber related parameters i.e. Service and User
Prole of the subscriber.

5. HSS checks the initial Filter criteria (iFC) and Service Point Trigger (SPT) in the service
prole of the requested subscriber. The parameter sent by the CSCF (Request-URI) of the
subscriber matches the one in the HSS, the HSS invokes the SIP servlet
(OneNumberSIPServlet) running on the SIP Application server and commands the CSCF to
forward the call to the OneNumberSIPServlet.

6. CSCF forwards the call to OneNumberSIPServlet acting as B2BUA running on SIP

Application server listening at port 5060 of local host.
7. B2BUA rst checks the caller of the call by inspecting the From header. B2BUA then
connects to the mainDataBase database to check the preferences of the subscriber for
this caller. In particular, B2BUA querys the mainDataBase for the data: call routing
rules and SIP URIs of the devices belonging to the subscriber.
8. The mainDataBase supplies the B2BUA with the requested data.
9. Based on the call routing rules, the call is routed to all or one of the devices belonging
to the subscriber. The session is established as soon as the subscriber picks any of his
devices.

The call ow diagram in the subsequent section; describes the SIP session establishment in
rather technical terms, detailing each and every SIP message as it traverses over the IMS
network to connect the caller and the subscriber of One Number Service.

SIP Session Call Flow:

The following call ow diagram illustrates the SIP messages as they ow over the network to
establish a SIP session based on One Number Service.

1. Caller initiates a call that is sends an INVITE request to the subscriber of One Number
Service.

2. B2BUA sends back a provisional response with the status code 100 Trying.

3. B2BUA then enquirys the database (mainDataBase) for the name of the group to which
this caller belongs and corresponding call routing rules. After getting the required info, it
forwards the INVITE request to proxy instance.

4. Proxy instance forwards the request to registered devices for the callee according to rules
specied by the callee.

5. Mean while, B2BUA sends back the 180 RINGING response to caller.

6. The callee picks up the phone on one of his devices (Cell phone in this case), sends the
200 OK response back to B2BUA.

7. The B2BUA forwards the 200 OK response to the caller.

8. Caller acknowledges the call and sends back an ACK response back to callee through
B2BUA.

9. Three way hand shake completes here and session is established between caller and
callee.

10. When any of either caller or caller hangs up, the BYE request is sent by the B2BUA from
callee to caller or vice-versa depending on who initiates the call termination rst.

Development Of One Number Service

This chapter includes a brief description of the development details. It rst explains the
Integrated Development Environment (IDE) used in the development of the One Number
Service. In addition, it also explains the process of the conguration of servers (Tomcat and
SailFin) as well as the MySQL database system, moving on to the explanation of
programming where a detailed description of each program dened in the One Number
Service is provided.

Development Environment:

Ericsson Service Development Studio (SDS) 4.1:

Ericsson Service Development Studio (SDS) 4.0 [12] is utilised as service development
environment. The Ericsson SDS is a development environment based on the Eclipse
[Appendix-3] platform. By using SDS; a developer can design, code as well as test SIP based
services in an IP Multimedia Subsystem (IMS) outset. A developer can hasten the
development process by using the templates and wizards available in Ericsson SDS.
Applications created with SDS can be deployed on a target commercial Service Execution
Environment (SEE).[12] The SDS with SEE enables the developer to rapidly develop attractive
telecom Value Added Services which can exploit full range of capabilities oered by next-
generation IMS networks.

Ericsson Service Development Studio (SDS) Features:

Ericsson SDS 4.1 Developers Guide [12] enlists following main features of Ericsson SDS;

1. Ericssons SDS provides an end-to-end support for design, coding, and testing of both
the client and server side IMS applications.
2. SDS contains emulation of deployment environments for both the terminal side (phones
based on Symbian Platform) and the server side (Session Initiation Protocol Application
Server SailFin AS).
3. Ericsson SDS provides a virtual IMS setup for developers to develop next-gen telecom
services.
4. SDS includes the IMS Client Platform (ICP), which is a client platform for open terminal
operating systems. ICP provides a high-level Application Programming Interface (API) to
develop client applications.
5. SDS includes the IMS Java Client Utility (IJCU), which implements a high-level API to
develop IMS client applications for devices.

The reason behind the selection of Ericsson SDS 4.1 as a development platform is, it provides
a virtual IMS setup in a ready to program environment. The One Number Service needed to
be deployed and tested in a next-gen cellular setup to nd out whether or not it is feasible to
create and oer such Value Added Services. Ericsson SDS, provides a Service Execution
Environment (SEE) which is a virtual cellular like network where value added services can be
deployed and tested and is as good as a real 3G network. The beauty of using Ericsson SDS is
that the developer only needs to worry about the programming part of the application and
rest of the formalities such as installation of servers (SailFin, CSCF, DNS, etc) and network
and deployment issues are taken care of by the studio itself.
Conguration of Ericsson SDS 4.1 For One Number Service
Development:

Before moving on to the details of programming, let us rst see how the Ericsson SDS is
congured as the development environment for One Number Service development. Ericsson
SDS comes with CSCF, HSS, DNS, SailFin-AS, etc. Although Ericsson SDS provides a ready to
use service development environment and everything is precongured, there are a few
entities such as database system or HTTP server which are not included in SDS package.
These functional entities need to be manually congured in the studio in order to use them
for service development. Following is the description of the third party entities used for one
number service development.

Conguring Tomcat Server In Ericsson SDS:

The Apache Tomcat Server is stand alone server that does not come with the Ericsson SDS
package. Tomcat Server needs to be installed on its own and congured in the Ericsson SDS.
Tomcat 6.0 Documentation site [27] explains the installation procedure for Tomcat Server.
Once Tomcat Server is installed successfully and the ENVIRONMENT variable is set to the
/CATALINA_HOME directory, it needs to be added into the Ericsson SDS to make SDS aware of
Tomcats installation path. Following is the list of steps taken to add the Tomcat Server in
SDS;

1. In the SDS create a new server instance by right clicking on the server tab in the
bottom pane of the SDS.
2. Click New and then Server.
3. Specify the name of the server as Tomcat v6.0 Server at localhost and click Next.
4. In the next window, expand the hierarchy of Apache and select the version of Tomcat
server installed on the system (for this development, it is Tomcat Server 6.0) and click
Next.
5. Fill in the parameters, address (local IP address), port (8080, the default HTTP port) and
domain name (domain.com) of the server in the next form and click nish, the icon of
Tomcat server can be seen in the Server tab of the SDS.
Conguring MySQL Server 5.0 In Ericsson SDS:

Since MySQL is not compatible with Ericsson SDS, MySQL Server needs to be congured in
the SDS before using it as a data source. Just like other IDEs, Ericsson SDS uses a third party
driver, MySQL JDBC driver [Appendix-3, 24] in order to connect to the MySQL database. The
Following list, enlists the steps involved in the creation of MySQL connection prole in the
studio environment. The connection prole once set; can be used over and over again to
connect to the MySQL database.

1. In the SDS, click on the Data Source Explorer.

2. Right click on the white space and then click on New.
3. Select MySQL as Connection Prole type from the list of available types, mention a
unique name for Connection Prole and click Next.
4. Select the driver name from the drop down list or browse to the location of the .jar le
for MySQL JDBC connector. The MySQL_JDBC_driver.jar library also needs to be placed in
the main package of the MIDlet suit that intends to use MySQL Server as a database
management system.
5. Specify the name of the database, corresponding URL, Admin name and Password.
6. Click on the Test Connection to check if the connection set is working ne.
7. Click nish. A complete hierarchy of the database will be shown in the Data Source
Explorer.

Conguring Tomcat Server 6.0 To Use MySQL Server5.0:

Since Apache Tomcat Server does not include the functionality to directly connect to the
MySQL Server so the developer needs a third part driver to connect to it. The most commonly
used and easily available driver is MySQL JDBC Driver. The MySQL JDBC Driver in a .jar le
can be downloaded from [24]. The Tomcat server needs to be made aware of the driver
before MySQL JDBC driver so that it can connect to MySQL Server database system. This can
be done by specifying the full path of installation directory of MySQL server in the PATH
ENVIRONMENT variable and putting in the MySQL_JDBC_driver.jar le into the
libCATALINA_HOME directory of the Tomcat installation folder. The MySQL_JDBC_driver.jar
library also needs to be placed in the main package of the MIDlet suit that intends to use
MySQL Server as a database management system.
Conguring SailFin A/S In Ericsson SDS:

Although SailFin Application Server comes with the Ericsson SDS bundle and is installed along
with the SDS, it needs to be congured with the studio before using it. Following is the list of
steps involved in addition process;

1. In the Server tab, create a new server instance by right clicking on the white space in
the bottom pane of the SDS.
2. Click New and then Server.
3. Specify the name of the server (Sailn v1 at local host in this case) and then click
Next.
4. Select the Sailn-v1 server from the list and then click Next.
5. Fill the parameters; Address (local IP address), Port (5060, the default SIP port) and
Domain name (ericsson.com) of the server in the next form and click nish, the icon of
SailFin server can be seen in the server tab of the SDS.

Conguring MySQL DataSource In SailFin Application Server:

In order to create and use MySQL data source in SailFin Application Server, a connection pool
needs to be created. The connection pool makes the SailFin Application Server aware of the
MySQL JDBC driver and sets a connection with the MySQL server, an instance of which can be
extracted in the code using the Context interface. Albin Joseph in [22] describes full
mechanism to congure a MySQL data source in SailFin Application Server. Steps mentioned
by him are;

1. MySQL JDBC driver can be downloaded from [5].

2. Extract the contents of the ziple and copy the mysql-connector-java-5.1.8-bin.jar to the
SailFin installation directory which for this development machine is
C:EricssonSDS4.1FD1Simulatorssailnlib.

3. Start the SailFin Application server in Ericsson SDS and login to Admin consol using the
default login name and password i.e. username=admin and password=adminadmin.

4. Select Common Task menu in Admin Consol, expand Resources and then select JDBC
underResources.
5. Click on Connection Pools under JDBC menu and click Next.

6. On the next page enter the name of the database, password and URL of the intended
database (mainDataBase) and click Finish.

7. Ping the Connection Pool just created to check if the connection pool is setup correctly, if
yes, a Ping Succeededmessage will appear.

8. Now click on JDBC Resources under JDBCmenu and click onNew.

9. Enter a JNDI Name for the data source i.e. mainDataBase Select the pool you created by
following the above steps as your PoolName.

Above process sets up a connection pool to the mainDataBase database, an instance of this
connection pool can be extracted in the main program using the Context interface which will
connect to database.

Once the conguration is successfully complete, a developer is ready to program in the SDS
environment without worrying too much about the rest of the matters.

One Number Service Program Structure:

Figure: 5a One Number Service Program Structure

The block diagram shown in gure:5a describes the programming model of One Number
Service program. As explained in the previous chapter One Number Service is composed of
two parts HTTP part and SIP part respectively, the two parts are not just separate from the
architecture point of view but they are programmed separately as well. Let us now go deep
into the programs and see how they are actually developed. There are actually three code
suits i.e. OneNumberService MIDlet Suit (for user interaction and database update), SIP
Servlet suit (for call routing and SIP session establishment) and HTTP servlet suit (for
database connectivity) developed in the One Number Service. The details of each suit are
provided in the following paragraphs.

OneNumberService MIDlet Suit:

Figure: 5b OneNumberService MIDlet suit structure

The OneNumberService MIDlet suit is Mobile Information Device Prole (MIDP2.0)

[Appendix-3] and Connected Limited Device Conguration (CLDC1.0) [Appendix-3] based
MIDlet suit that can run on any Java enabled, Symbian OS based mobile platform. The
OneNumberService MIDlet suit is designed and developed in Java 2 Micro Edition (J2ME)
[Appendix-3]. The main function of OneNumberService MIDlet suit is to provide an ecient
Graphical User Interface (GUI) that lets the user to make amendments in the database
through their handheld devices. One Number Service MIDlet suite consists of ve MIDlets
developed in J2ME using LWUI (Light Weight User Interface) Toolkit API [Appendix-3, 28]. The
details of each MIDlet are provided bellow;

LoginScreen.java MIDlet:

LoginScreen MIDlet is the rst page that a user comes across when he/she runs the
OneNumberService MIDlet suit. When OneNumberService MIDlet suit is run for the rst time,
the LoginScreen MIDlet asks the user to set Username and Password; the info entered is then
saved in a Record Management Store. When the same user revisits the OneNumberService
suit, the login info stored in the Record Management Store is extracted in order to
authenticate this user.

LoadingMidlet.java MIDlet:

LoadingMidlet.java does not have much functionality apart from showing a loading screen
and a progress bar indicating the loading progress. The MIDlet instantiates LWUI class and
uses its widgets to dene the visual interface of the MIDlet. Like any other basic MIDlet, there
are three methods dened in this MIDlet startApp(), destroyApp() and pauseApp(). startApp()
is the only working method in this MIDlet remaining two methods are stubs i.e. does not have
anything dened in them. The startApp() method is further explained bellow;

startApp(): The startApp method rst invokes init( MIDlet midlet) method of Display class
which creates the instant of LWUI. LWUI is used to create the graphical user interface in small
screen devices such as mobile phones. startApp() method then instantiates the Form Class
and appends an empty form on the mobile screen. The instant of Form class (mainForm) is
actually an empty container that holds the LWUI widgets like buttons, labels, textelds, etc.
In this case, the mainForm holds a loadingLabel (an instance of Label class),
backgroundImage (an instance of Image class) and animatedButton (an instance of Button
class). An array of six images (animationImages) is also dened within this method which is
used by animatedButton to create the animation. animatedButton is registered as animation
in the mainForm meaning every time startApp( ) is invoked, the animatedButton extracts and
draws the images from the animationImages array one by one on itself. animatedButton
leaves a delay of 0.5 seconds between two images. This process continues until
animationImages runs out of the images. The combination of images and delay create an
animated eect which is similar to progress bar shown when system loads something.

MainForm.java MIDlet:

The MainMidlet MIDlet as the name suggests is the main MIDlet in the OneNumberService
MIDlet suit and plays the role of centre MIDlet that allows other MIDlets to communicate with
each other. MainMidlet MIDlet is used to call other MIDlets (MyNumbers, Contacts, EditRules,
EditNumbers) dened in the OneNumberService MIDlet suit. The startApp( )is the only
working method, the functional details of startApp( ) method are provided bellow;

StartApp( ): When startApp( ) method is invoked, a menu of commands appears on the

mobile screen. There are ve commands displayed in the menu; My Numbers, Contacts,
Show Rules, Show Numbers and Exit. Each corresponds to an inner class which listen to the
action events and is capable of reacting accordingly. Each inner class inherits
actionPerformed (ActionEvent event) method which is invoked each time the user hits the
corresponding command button and takes him to the relevant MIDlet. For example, hitting on
the Edit Rules will call the actionPerformed( ) method of the Edit Rules inner class which will
take the user to EditRules MIDlet. And, pressing the Exit command will exit the application.

Contacts.java MIDlet:

The Contacts.java MIDlet is used to add new contacts to the MySQL database mainDataBase.
The Contacts MIDlet consists of two working methods startApp and callThread. In addition, a
Thread called MyContactsStoringThread is also dened in this MIDlet which is used to
establish HTTP sessions with the Tomcat server. The methods dened in Contacts MIDlet are
further explained in the following paragraphs.
StartApp( ): The startApp( ) rst invokes init( MIDlet midlet) method to create the instant of
LWUI Display class. In the Contacts MIDlet, startApp( ) consists of mainForm (an instant of
Form Class) which holds name (an instant of TextField Class), SIP URI (an instant of TextField
Class) and group (instant of ComboBox Class). When the startApp( ) method is invoked, the
LWUI widgets i.e. name texteld, SIP URI texteld, and group combobox is displayed on the
mainForm. These widgets are used to take user input when a new contact is being added to
the database. Having got the user input, the startApp( ) method invokes the callthread ( )
method.

CallThread( ): callThread( ) method collects the user input entered in the name and SIP-URI
textelds and group combobox by using getText( ) and getSelectedIndex( ) methods of the
TextField and ComboBox classes respectively. After getting the user input, the callThread
method then initializes the constructor of MyContactsStoringThread Thread with the values
entered by the user. Once the MyContactsStoringThread is initialized, callThread method
then runs the thread by using the start( ) method of MyContactsStoringThread Class.

MyContactsStoringThread( ) **:

MyContactsStoringThread extends Thread interface and implements Runnable interface

which means it can be started and stopped at any time within the main program. The
MyContactsStoringThread Thread is used to create HTTP sessions with the Tomcat Server. It
inherits the run method which corresponds to the start method of MyContactsStoringThread
Thread. Hence each time start method is invoked; the run method is invoked too.

Run( ) method: The run method is developed to create HTTP sessions with Tomcat Server. For
this, run method creates instances of HttpConnection Class (used to connect to the Tomcat
server) and DataInputStream Class (used to get server response). run method creates the
HTTP connection with the server using the open method of Connector Class. The open
method takes one parameter, the URL of the servlet to which the connection is desired. The
URL specied in the open method for the Contacts MIDlet is
http://localhost:8080/ServerProgrammz/ServletServer01.

This URL species that the connection is desired to the HTTP servlet (ServletServer01),
running at the port 8080 of the local host. The ServletServer01 is capable of storing the
contacts into the database. Functionality of ServletServer01 is further discussed in the HTTP
servlet suit section of this chapter.

Having established the HTTP connection with the desired HTTP servlet, the run method
creates a POST request using the setRequestMethod(String) method of HttpConnection Class
that takes an String argument to specify the type (POST/GET) of request being created . In
order to set the properties of the HTTP request such as (User-Agent, Content Type, etc), the
run method invokes the setRequestProperty( String, String) method of HttpConnection Class-
the String arguments specify the name and corresponding value of the property.

The run method then calls the DataOutputStream method of the HttpConnection Class-this
generates an OutputStream instance which is used to send the requests to the server by
calling its writeUTF method. The writeUTF method takes a String argument which is the data
value to be sent over the OutputStream. Once the data is sent to the server, the server
responds with a response code notifying the sender if the server received the data
successfully. In order to conrm this, the run method invokes the getResponseCode method
of the HttpConnection Class which receives the response code sent by the server. If the
response code is equal to HTTP.OK meaning data is correctly received by the server or else
the data is not received by the server properly in which case the user has to reattempt data
transmission.

MyNumbers.java MIDlet:

The MyNumbers.java MIDlet can be used to add the SIP URI of the subscriber devices to the
MySQL database mainDataBase. The MyNumbers MIDlet consists of two working methods
startApp and callThread

StartApp( ): The startApp( ) rst invokes init( MIDlet midlet) method of Display class which
creates the instant of LWUI. In the MyNumbers MIDlet, startApp( ) consists of mainForm (an
instant of Form Class) which holds a Home Phone (an instant of TextField Class), Cell Phone
(an instant of TextField Class), Oce Phone (an instant of TextField Class) and PDA (an
instant of TextField Class). When the startApp method is invoked, the LWUI widgets i.e. Home
Phone texteld, Cell Phone texteld, Oce Phone texteld and Voicemail texteld are
displayed on the mainForm. These widgets are used to take user input when new devices
are being added to the database. Having got the user input, the startApp( ) method then
invokes the callthread method which in turn initializes the constructor of
MyNumbersStoringThread Thread.

CallThread( ): callThread( ) method collects the user input entered in the Home Phone, Cell
Phone, Oce Phone and Voicemail Textelds by using getText( ) method of the TextField
class and initializes the constructor of MyNumbersStoringThread Thread with the obtained
values. callThread method then runs the MyNumbersStoringThread Thread by using its start
method.

MyNumbersStoringThread(): The MyNumbersStoringThread Thread is also used to create

HTTP sessions with the Tomcat Server. The MyNumbersStoringThread inherits the run( )
method which corresponds to the start( ) method of MyNumbersStoringThread Thread.
Hence, each time start method is invoked, the run method is invoked too.

Run( ) method: The run( ) method obtains instance of HttpConnection by using the open
method of Connector Class. The open method takes the URL of the servlet to which the
connection is desired. For MyNumbers MIDlet, the URL specied in the open method is
http://localhost:8080/ServerProgrammz/ServletServer02.

Meaning the connection is desired to the HTTP servlet (ServletServer02), running at the port
8080 of the local host.

Once the connection with a desired HTTP servlet (ServletServer02) is established, the run
method creates a POST request using the setRequestMethod(String) method of
HttpConnection Class that takes an String argument to specify the type of request
(POST/GET) being created . It is important to set the properties of the HTTP request such as
(User-Agent, Content Type) to let the servlet know the originator of the request and the type
of data expected, in order to do so the run method invokes the setRequestProperty(String,
String) method of HttpConnection Class.

The run method then calls the openDataOutputStream method of the HttpConnection Class-
this generates an OutputStream instance which is used to send the requests to the server by
calling its writeUTF method. The writeUTF method takes a String argument which is the data
value to be sent over the OutputStream. Once the data is sent to the server, the server
responds with a response code notifying the sender whether or not the server received the
data successfully. In order to conrm this, the run method invokes the getResponseCode
method of the HttpConnection Class which gets the response code sent by the server. A
HTTP.OK response means data is sent correctly.

EditNumbers.java MIDlet:

The EditNumbers.java MIDlet is used to edit the device numbers already stored in the MySQL
database mainDataBase. The EditNumbers MIDlet consists of four working methods
startApp( ), dialogShow( ), split( ) and callThread( ). A Thread called EditNumbersThread is
also dened in this MIDlet which is used to establish HTTP sessions with the Tomcat server.
The methods dened in this MIDlet are further explained in the following paragraphs.

StartApp( ): In the EditNumbers MIDlet, startApp( ) consists of mainForm (an instant of Form
Class) which holds numberList (an instant of List Class). When the startApp( ) method is
invoked, the LWUI List (numbersList) List is displayed on the mainForm. The numbersList
List enlists the devices and their corresponding SIP URIs with the commands Cancel and
Edit being displayed in the soft button panel of the mainForm. startApp( ) creates an HTTP
session with the HTTP servlet (ServletServer03) in order to extract the SIP URIs of the devices
from the mainDataBase database. The code to establish HTTP connection is given bellow;

Setting up the HTTP connection

httpConn= (HttpConnection)
Connector.open(http://localhost:8080/ServerProgrammz/ServerServlet04);

Creating the POST Request.

httpConn.setRequestMethod(HttpConnection.POST);

Setting the Request Property (user Agent) to the Sun wireless toolkit 2.5 emulation device
prole. This tells the server abut the originator of the request.

httpConn.setRequestProperty(User-Agent, Prole/MIDP-2.0 Conrguration/CLDC-1.0);

Setting the Request Property (Content-Type) to text/html which tells the servlet the type of
data expected.
httpConn.setRequestProperty(Content-Type, text/html);

Obtaining new instance of String Buer to hold the values received from the server.
StringBuer sb = new StringBuer();

Obtaining new instance of DataInputStream to extract the stream of chars from the server.

is = httpConn.openDataInputStream();

int chr;

Loop that keeps on adding the chars received in the data input stream from the server until
the input stream runs out of the chars.

while ((chr = is.read()) != -1)

sb.append((char) chr);

converting the chars stored in string buer into a large string

String numbersString=sb.toString();

Passing the large string (numbersString) to the split() method to get the array (allStrings) of
separated strings.

allStrings=split(numbersString0);

The allStrings array holds the SIP URI of the devices stored by the user in the mainDataBase
database. The allStrings array is passed to the numberList List constructor which appends its
elements on to the numberList List. When a user wants to edit a number, he/she will have to
select that particular number from the numbersList List and hit the Edit command. As soon
as the Edit command is pressed, the startApp( ) method calls the dialogShow method and a
dialog box appears on the mobile screen.

DialogShow( ): When dialogShow method is invoked a user is shown a dialog box holding a
texteld with commands Save and Cancel being shown in the soft button panel of the mobile
screen. When the user enters a new value of SIP URI of the device being edited in the
Texteld shown and hits the Save command, the dialogShow( ) method calls the callThread
method which in turn initializes the constructor of EditThread Thread. Hitting on the Cancel
command will make the dialog box disappear.

CallThread( ): callThread method takes the user input entered in the editNumbers TextField
and initializes the constructor of EditThread Thread with the obtained value. callThread
method then runs the EditThread Thread by using the start( ) method of EditThread Thread.

Split(String): The split(String) method takes a large string and returns the array of strings
after separating the large string into many smaller strings. The split method is created
because the device numbers retrieved from the mainDataBase database are in the form of a
large string separated by (-) separator. The split( ) method takes the large string
(concatenated strings of SIP URIs) sent by Tomcat server and separates it into individual
strings which are actually the SIP URIs of the devices registered by the user. The logic behind
split of strings is very simple. The split method rst determines the index of separator - in
the large string and then keeps on storing the individual strings in an Array of strings which is
returned at the method call.

EditThread**: The EditThread Thread is used to create HTTP sessions with the Tomcat Server.

Run( ) method: The run( ) method obtains instance of HttpConnection by using the open( )
method of Connector Class. The open() method takes the URL of the servlet to which the
connection is desired. For EditNumbers MIDlet, the URL specied in the open ( ) method is

http://localhost:8080/ServerProgrammz/ServletServer03

Meaning the connection is desired for the HTTP servlet (ServletServer02), running at the port
8080 of the local host.

Having established the HTTP connection with HTTP servlet (ServletServer05), the run method
creates a POST request using the setRequestMethod(String) method of HttpConnection Class
that takes an string argument to specify the type of request (POST/GET) being created.

The run method then calls the open DataOutputStream method of the HttpConnection Class-
this generates an OutputStream instance which is used to send the requests to the server by
calling its writeUTF method. The writeUTF method takes a String argument which is the data
value to be sent over the OutputStream. Once the data is sent to the server, the server
responds with a response code notifying the sender whether or not the server received the
data successfully. In order to conrm this, the run method invokes the getResponseCode
method of the HttpConnection Class which gets back the response code sent by the server. If
the response code received is equal to HTTP.OK meaning data is correctly received by the
server else the data is not received by the server properly in that case the user has to
reattempt the data.

EditRules.java MIDlet:

The EditRules.java MIDlet is used to set and/or edit the call routing rules for the groups
(Friend, Family, Boss, etc) and stores them in the mainDataBase database. The EditRules
MIDlet consists of four working methods startApp( ), editRulesDialog( ), split( ) and
callThread( ). In addition, a Thread called EditRulesThread is also dened in this MIDlet
which is used to establish HTTP sessions with the Tomcat server. The methods dened in this
MIDlet are further explained in the following paragraphs.

StartApp( ): In the EditNumbers MIDlet, startApp method consists of mainForm (an instant of
Form Class) which holds a rulesList (an instant of List Class). When the startApp( )method is
invoked, the LWUI List i.e. rulesList List is displayed on the mainForm. The rulesList List
enlists the call routing rules for dierent groups and the ringing pattern of the devices for
that particular group with the commands Cancel and Edit being displayed in the soft
button panel of the mainForm. When a user wants to edit a rule, he/she will select that
particular rule from the rulesList and hit the Edit command. As soon as the Edit command is
pressed, the startApp method calls the editRulesForm method and a new Form class is
created that displays the ComboBoxes (Home, Cell, Oce and PDA). The user can select the
values in the ComboBoxes according to his wishes for the devices to ring.

CallThread( ): callThread method takes the user input entered in the Home, Cell, Oce and
PDA ComboBoxes and initializes the constructor of EditRulesThread Thread with the obtained
values. callThread method then runs the EditRulesThread Thread by invoking its start( )
method.
EditRulesThread **:

The EditRulesThread Thread is used to create HTTP sessions with the Tomcat Server.

Run( ) method: Using open method of HttpConnection class, the run method creates a
connection with (ServetServler05). Having established the connection, the run method
creates a POST request using the setRequestMethod(String) method of HttpConnection Class.
The run method then calls the open DataOutputStream method to generate an OutputStream
instance which is used to send the requests to the server by calling its writeUTF method.
Once the data is sent to the server, the server responds with a response code notifying the
sender whether or not the server received the data successfully. The getResponseCode
method of the HttpConnection Class does just that, it retrieves the response code sent by the
server. An HTTP.OK response from the server conrms the data reception.

Note: The HTTP session is created in a separate thread because the Sun Wireless Tool Kit 2.5
does not allow the communication session to be created within the command methods.
Establishing HTTP session within the command methods create potential deadlock and the
program gets stuck.

HTTP Servlet Suit:

Hyper Text transfer Protocol Servlet suit is HTTP 1.1 compliant HTTP servlets that run on the
web server (Tomcat Server) and are used to respond to the HTTP requests sent by
OneNumberService MIDlet suit. The Servlets dened in the HTTP suit are capable of
connecting to MySQL database mainDataBase, querying the mainDataBase database
according to the requests sent by the OneNumberService MIDlet suit and respond to the
OneNumberService MIDlet suit according to the response got from the mainDataBase.

As shown in gure:5c, there are ve Servlets dened in the HTTP suit each performing
dierent operation on the MySQL database mainDataBase. Function of each is detailed
bellow.

ServletServer01:

OneNumberService MIDlet suits HTTP POST requests for addition of contacts in the
mainDataBase database are dealt in ServletServer01. Each time Contacts MIDlet of
OneNumberService MIDlet suit requests the Tomcat Server to add a new contact to the
mainDataBase database; the request rst ends up in ServletServer01.

DoPost method():

The only method dened in the ServletServer01 is doPost(HttpServletRequest,

HttpServletResponse). The doPost method is used to respond to the HTTP POST requests sent
by Contacts MIDlet. The doPost method rst gets the instance of DataInputStream
(inputStream) by invoking getInputStream( ) method of HttpServletRequest Class.
DataInputStream instance is used to read the data from input stream sent by Contatcs
MIDlet. Once the data is read, the doPost method then establishes connection with the
MySQL database mainDataBase. As explained earlier Apache Tomcat Server does not have
the functionality to directly connect to the MySQL Server so it needs a third party driver such
as MySQL JDBC Driver to connect to it. The Driver instance can be extracted by using
foName(String) method of Class class. The forName method takes a String argument (the
name of the driver) to create the Driver instance. doPost( ) method then establishes
connection with the MySQL server by using the getConnection(connectionURL, loginName,
password) method of DriverManager class. For mainDataBase database, connectionURL is;

jdbc:mysql://localhost:3306/mainDataBase

Jdbs:mysql= name of the driver

IP address, port= local host:3306

name of the database=mainDataBase

loginName =root

password =adminadmin

Having established connection with the mainDataBase, the doPost method instantiates
Prepared statement class which is used to create a query written in System Query Language
(SQL) in order to save the data values (name, SIP URI and group) in the mainDataBase. For
ServletServer01 the prepared statement is;
INSERT INTO contactperferences VALUES(?,?,?)

This statement will insert/store three data values (name, SIP URI and group) in the
contactperferences data table of the mainDataBase database. doPost( ) calls the
executeUpdate method of preparedStatement to send the query to the MySQL Server. The
executeUpdate returns an integer value of greater than 0 if the database update is successful
and 0 otherwise. The doPost( ) nally creates a HttpServletResponse and sends it back to the
Contacts MIDlet to notify it of whether or not the database update was successful.

ServletServer02:

ServletServer02 deals with the addition of SIP URIs of the devices in the mainDataBase
database. Each time MyNumbers MIDlet requests the Tomcat Server to store the SIP URI of
one or more devices in the mainDataBase database; the request rst ends up in
ServletServer02. The function of ServletServer02 is similar the only dierence is in the
prepared statement. For ServletServer02, the prepared statement is

INSERT INTO numbers VALUES(?,?,?,?)

The statement commands the MySQL server to store the data values (Home Phone SIP URI,
Oce Phone SIP URI, Cell Phone SIP URI and Voicemail SIP URI) into the numbers data table
of mainDataBase.

ServletServer03:

ServletServer03 performs the edit function in the mainDataBase database. Each time
EditNumbers MIDlet requests the Tomcat Server to edit or update the SIP URI of one or more
devices in the mainDataBase database; the request rst ends up in ServletServer03. Like
previous two servlets, the function of ServletServer03 is pretty much the same, only
dierence is in the preparedStatement. For ServletServer03, the preparedStatement is;

UPDATE numbers SET home=++number+;

Where, number is the new value of SIP URI for this particular device. The statement
commands the MySQL server to replace the data value stored in Home column of the
numbers data table of mainDataBase database with the value number.
ServletServer04:

ServletServer04 deals with the addition of call routing rules for a particular group in the
mainDataBase database. Each time EditRules MIDlet requests the Tomcat Server to store the
call routing rules for one or more groups in the mainDataBase database; the request rst
ends up in ServletServer04. Like other three servlets, the function of ServletServer04 is
pretty much the same the only dierence is in the preparedStatement. For ServletServer02,
the preparedStatement is

INSERT INTO rules VALUES(?,?,?,?,?)

The statement commands the MySQL server to store the data values
(ringingOrderHomePhone, ringingOrderOcePhone, ringingOrderCellPhone,
ringingOrderVoicemail and GroupName) into the rules data table of mainDataBase.

ServletServer05:

ServletServer05 performs the edit function in the mainDataBase database. Each time
EditRules MIDlet requests the Tomcat Server to edit or update the call routing rules for any
particular group; the request ends up in ServletServer03. Like previous servlets, the function
of ServletServer05 is pretty much the same, only dierence is in the preparedStatement. For
ServletServer05, the preparedStatement is;

UPDATE rules SET Friend=++ringingOrder+;

Where, ringingOrder is the new order at which this particular device will be ringed. The
statement commands the MySQL server to replace the data value stored in Friend column of
the rules data table of mainDataBase database with the value ringingOrder.

5.3.3 SIP Servlet Suit:

SIP Servlet Suit is the heart of One Number Service. There is currently only one servlet
dened in the SIP servlet suit which performs the call routing and SIP session establishment
functions.
OneNumberSIPServlet Servlet:

OneNumberSIPServlet servlet acts as a Back 2 Back User Agent. A B2BUA has the capability
of acting as both a server and a client. This means OneNumberSIPServlet is not only capable
of responding to the requests but can create and send requests as well. The
OneNumberSIPServlet can currently respond to the INVITE, BYE and CANCEL requests and
Provisional (1xx) and Success (2xx) responses. The requests and responses are handled in
various doXX( ) methods which are invoked as soon as the OneNumberSIPServlet servlet gets
the corresponding request or response. The detailed working principle of these methods is
given bellow;

Init(ServletCong):

The init(ServletCong) method initializes the OneNumberSIPServlet class. The ServletCong

is used to get an instance of ServletContext. According to JSR-289 specications [1], the
Servlet Container (SailFin Application Server) must always enforce a one-to-one
correspondence between a servlet application and a ServletContext. SIP servlet container is
also required to make a SipFactory instance available to OneNumberSIPServlet servlet
through a ServletContext attribute, the SipFactory is the factory interface used to create
requests, responses, SIP URIs, etc. An instance of SIP Proxy is also extracted from the
ServletContext. The SIP Proxy instance represents the operation of proxying (readdressing) a
SIP request.

DoInvite(SipServletRequest):

The INVITE Request is used to initiate a SIP session between two users (Caller and Callee).
The OneNumberSIPServlet servlet captures all subsequent SIP messages in the session and
sends them to the other end (Callee). Since the OneNumberSIPServlet servlet is acting as a
B2BUA, the requests are rst received and handled by it before recreating in the related SIP
session. The detailed working procedure of this method is given bellow.

When a Caller initiates a session i.e. creates and sends INVITE request to the Callee
(subscriber of One Number Service), the doInvite( ) gets invoked on the
OneNumberSIPServlet. The doInvite method has a SipServletRequest argument which is
composed of three basic parameters: a From Address (the address of the person who
initiated the request), a To Address (the address of the person for whom the request is
destined) and Call Id (a unique id indicating the call). Following enumeration describes the
steps performed by doInvite( ) method to route the request to Callee.

1. doInvite method rst creates TRYING response using the createResponse( ) method of
SipServletRequest class. The createResponse( ) takes an integer attribute which species the
status code of response (100, TRYING in this case). The TRYING Response created is sent
back to the Caller to notify him of the progress of session establishment.

2. doInvite method nds out the originator of INVITE request by calling the getFrom( ) method
of the SipServletRequest class.

3. The From Address is passed to the dataSourceLookup method which in turn querys the
mainDataBase database for the name of the group to which the Caller belongs and returns an
ArrayList of Strings containing the SIP URIs of the devices registered for the subscriber in the
database.

4. The doInvite then invokes the rulesLookup method to get call routing rules for the group to
which the Caller belong. The rulesLookup returns an ArrayList of strings containing the order
in which the devices should be ringed.

5. Having got the device SIP URIs and the call routing rules, the doInvite then creates a new
INVITE request to forward the request to Callees devices. This is done using the
createRequest( ) method of the SIPFactory Class. The createRequest method requires four
parameters; name of the Application Session (SIP dialog to which this new request belongs).
In this case, it belongs to the SIP dialog initiated by the caller. The request Method (INVITE), a
From Address and a To Address are the remaining three parameters for the request.

6. Using addAssertedIdentity(SipServletRequest, String id ) sets the P-Asserted Identity

Header in the request created above to the address of the caller (From Address). The P-
Asserted Identity is required by Proxy Call Session Control Function (P-CSCF) to validate the
request and noties the Serving-Call Session Control Function (S-CSCF) that the request is
from a trusted domain.

7. The doInvite method then calls the addCscfRoute(SipServletRequest) to add the S-CSCF in
the request path. The S-CSCF forwards the request to Home Subscriber Server (HSS) which
checks the Service Prole of the intended user and sends the request back to the SailFin
Application Server after validating the requests.

8. doInvite method then proxys the request to the devices subscribed by the subscriber
according to the call routing rules set for this caller. This is done using the
proxyTo(SIP_URI_ArrayList) method of Proxy class. The attribute SIP_URI_ArrayList is an
ArrayList of SIP URIs of the devices extracted by calling numbersLookup method. The proxyTo
method can proxy the call either in parallel (simultaneous ringing of all the devices) or in
sequential (ringing each device one by one) manner. In order to decide whether to proxy the
call in sequential or in parallel, doInvite( ) method applies following logic;

a). Parallel Proxying: The rules extracted for a parallel call would be such that the ringing
pattern for each device is 1. For example, if the caller belongs to Boss group, the ring
pattern set for this caller is;

Caller: Caller-1 Group: Boss

Device: Home Ring Pattern: 1

Device: Cell Ring Pattern: 1

Device: Oce Ring Pattern: 1

doInvite() method in this case, employs an if statement to check if the the ring pattern for
each device is 1, if that is the case the call is forwarded in parallel using the setParallel(true)
method of Proxy Class.

b). Sequential Proxying:

The rules extracted for a call that requires sequential forking would be such that the ringing
pattern for each device would be in order of increasing. For example, if the caller belongs to
Friend group, the ring pattern set for this caller is;

Caller: Caller-2 Group: Friend

Device: Cell Ring Pattern: 1

Device: Home Ring Pattern: 2

Device: Oce Ring Pattern: 3

doInvite() method in this case, checks if the ring pattern for all the device is unique, if that is
the case the call is forwarded in sequential manner using the setParallel(false) method of
Proxy Class. In this case, the call is rst directed to the device with ring pattern 1, and then
to the device with ring pattern 2only if the user fails to pick the call at rst device. The
gure: 5c further illustrates this concept.

8. After sending the request to intended devices, the doInvite method saves the original
INVITE request with the name originalInviteRequest sent by the caller in an Application
Session applicationSession so that it can be retrieved at later stage to respond to the Caller.

Do Provisional Response(SipServletResponse): doProvisionalResponse(SipServletResponse)

method handles the provisional responses (any response with status code 1xx). Provisional
response is the non-nal response that noties the caller of the progress of the call. TRYING
or RINGING response is an example of provisional response. In OneNumberServiceB2BUA
Servlet, doProvisionalResponse( ) method rst checks the status code of the response sent
from the caller and if the status is RINGING then forwards the RINGING response to the caller.
In order to do so, the doProvisionalResponse( ) method needs to know the SIP dialog to which
this response belongs-this can be achieved by invoking the getApplicationSession( ) of the
SipServletResonse Class. The originalInviteRequest logged in the applicationSession in the
doInvite( ) method, needs to be retrieved. Once the original INVITE is known, the
doProvisionalResponse( ) method then creates and sends the response back to the caller by
using the createResponse( ) and send( ) methods respectively of the SipServletRequest
Class. Figure: 5f illustrates the concept.

Do Success Response(resposnse): In OneNumberServiceB2BUA servlet the

doSuccessResponse( ) method forwards the Success Response (Response with status code
200) received from Callee to the Caller The gure:5g shows the SIP message ow for this
process.To forward the OK Response to the Caller, doSuccessResponse( ) determines the SIP
dialog to which INVITE Request (request) belongs-this is achieved by invoking the
getApplicationSession( ) method on the received SipServletResonse resposnse. Once the
original INVITE request is known, the doSuccessResponse method then creates the Response
with the status code 200 by invoking the createResponse method of the SipServletRequest
Class which is later sent to the Caller to notify him/her of the session establishment. Before
sending the 200 OK response to the Caller, the original success response sent by the Callee is
logged in the Application Session so that it can be retrieved at a later stage by the doAck()
method to ACK it.

DoAck( ): When the Caller sends an ACK request back to the B2BUA to acknowledge the 200
OK response, the B2BUA agent has to forward the ACK request the Callee in order to
complete the Three-way handshake and hence the session establishment. The ACK request is
handled in the doAck method which retrieves the successResponse logged in the Application
Session and creates a new request using createAck() method of SipServletResponse class to
direct the ACK request to the Callee.

DoBye( ): The doBye( ) method is called when either of the Caller or the Callee hangs up.
According to SIP specications (RFC-3261 [13]), a BYE request needs to be sent to terminate
the session. The doBye( ) method does just that, it rst checks the initiator of the BYE
Request and creates and forwards the BYE Request to the other end of the dialog. For
example, if the BYE Request was sent from the caller the doBye( ) method forwards the
Request to the Callee and vice-versa.

DoCancel( ):The doCancel( ) method handles the CANCEL Requests. The CANCEL Request can
be sent by either the Caller or the Callee to withdraw the session establishment process.
When either party (Caller or Callee) is no longer willing to continue with the session
establishment, it sends the CANCEL Request to OneNumberServiceSIPServlet servlet which in
turn invokes the doCancel( ) method and calls o the session establishment.

AddAssertedIdentity( ): S-CSCF processes only asserted Requests (the requests from a

trusted domain). When a request is sent without a P-Asserted-Identity header, it is rejected
with a 403 Forbidden. The addAssertedIdentity( ) method adds the P-Asserted-Identity
header to the requests which arms the S-CSCF that the request is from a trusted domain.

AddCscfRoute( ): Every request needs to be routed through CSCF node of the IMS setup.
addCscfRoute( ) method pushes the request to the S-CSCF which handles the routing of the
Requests in the IMS setup. addCscfRoute( ) method sets the Route Header in the Request to
the IP address (Default IP address: 127.0.0.1 and Port: 5082 ) of the S-CSCF.

DataSourceLookup(String fromAddress):

The dataSourceLookup(String fromAddress) method performs the function of retrieving the

name of the group to which the Caller with SIP URI formAddress is associated. Besides, this
method can also extract the SIP URIs of all the devices registered by the subscriber. This,
requires a connection with the MySQL Server and mainDataBase database in particular-the
Context instance is useful in this regard which can connect the OneNumberServiceB2BUA SIP
servlet to the MySQL database mainDataBase provided the DataSource and the MySQL driver
(JDBC driver) are already set [as explained in section (5.2.2)]. By using the lookup( ) method
of the Context Class the DataSource instance can be obtained. The DataSource instance can
be used to establish the connection with the mainDataBase by calling its getConnection( )
method.

Having established the connection with the mainDataBase database, the

dataSourceLookup(String fromAddress) method creates two SQL query statements to nd out
the group for the Caller (having SIP URI=fromAddress) and the SIP URIs of the devices
registered by the user. Hence, there are two SQL statements dened in this method- the
details of each are provided bellow;

dataSourceLookup SQL Statement-1:

In order to extract the group for the Caller (having SIP URI=fromAddress) from the
mainDataBase, the dataSourceLookup method uses following SQL statement;

SELECT group FROM contactpreferences WHERE number =++fromAddress++;

The statement extracts the value of group column from the contactperferences data table for
the person with SIP URI fromAddress.

dataSourceLookup SQL Statement-2:

In order to extract the SIP URIs of the devices registered for the requested subscriber
(subscriber with toAddress), the dataSourceLookup() method uses the following SQL
statement;

SELECT * FROM numbers;

The statement commands the MySQL server to extract all the values stored in the numbers
data table.

RulesLookup(String group): Once the group for the Caller is determined from the
mainDataBase, the OneNumberServiceB2BUA SIP servlet then utilizes the rulesLookup( )
method to nd out the call routing rules for the given group. The rulesLookup( ) method
function very much similar to the dataSourceLookup( ) except the SQL statement. The SQL
statement created in the rulesLookup( ) method is;

rulesLookup SQL Statement:

In order to extract the call routing rules for the given Group from the mainDataBase,
dataSourceLookup( ) method uses the following SQL statement;

SELECT * FROM rules WHERE group =++group++;

The statement commands the MySQL server to extract all the values stored in the rules data
table for the Group column is equal to group.

One Number Service User Interface:

The only way user can interact with the one number service is through the
OneNumberService MIDlet running on a mobile platform. Hence, user interface is only
designed for the OneNumberService MIDlet. The user interface for the OneNumberService
MIDlet suit is designed using LWUI Toolkit [25]. The Lightweight User Interface Toolkit library
is an Application Programming Interface (API) that can be used to create attractive graphical
user interface (GUI) applications for mobile phones that support MIDP 2.0 [Appendi-3].
Lightweight UI Toolkit is like stripped down version of Swing library in Java 2 Standard Edition;
hence, supports visual components called widgets (Buttons, Labels, Textelds, etc) and other
user interface (UI) features such as themes, transitions, animations, etc. This section
describes the user interface for the OneNumberService MIDlet suit.
Integrating LWUI In OneNumberService MIDlet suit:

In order to use the LWUI Toolkit library, the LWUI API needs to be placed in the main package
of the OneNumberService MIDlet suit. The LWUI Toolkit API can be downloaded from [25].
Once downloaded, the LWUI.jar le within the LWUI archive needs to be placed in the libraries
folder of OneNumberService MIDlet suit. This is important as otherwise; the
OneNumberService MIDlet suit will not be able to use any of the features provided by LWUI
toolkit API.

Styling:

The style object in LWUI API sets the colour, font, border, transparency and padding of the
components used in the MIDlet. The styling in the OneNumberService MIDlet suit is done
using the instance of Style Class. The Style object can completely transpire the basic look of
any widget. There are three styles dened in the OneNumberService MIDlet suit. An example
code statement to dene a Style object is explained bellow;

Style style1= new Style(); Gets the instance of Style class

style.setBgColor(0x999999); Sets the background colour of widget to 0x999999 (Light Grey).

style.setBgImage (image); Sets the background of widget or container to an Image image.

style.setBorder(border); Sets the border of the widget to border which is an instance of

Border class and is dened as; border=Border.createRoundBorder(16,6, 0x450085); Creates
a round border around a widget with width, height and colour parameters set to 16pixles, 6
pixels and 0x450085 (medium purple) respectively.

style.setFgColor(0x000000); Sets the colour of text on the widget to 0x000000 (Black).

style.setFgSelectionColor(0xFFCCFF); sets the colour of text on the widget to 0xFFCCFF (Light

Pink) when the widget text is selected.

style.setFont(font); Sets the font of text on the widget to font an instance of Font class which
is dened as
font= Font.createSystemFont(Font.FACE_MONOSPACE, Font.STYLE_BOLD,
Font.SIZE_MEDIUM);

Font type is Face_MONOSPACE, Style is Bold and Size is Medium.

style.setPadding(1,1, 1, 1); Sets the alignment of the widgets on the mobile screen.

Look and Feel: LookAndFeel, an instance of which may be obtained from the UIManager is a
Class that allows the developer to customize or redraw any of the widgets already dened in
the LWUI toolkit API. The LookAndFeel of the OneNumberService MIDlet is set to
DefaultLookAndFeel which means the OneNumberService MIDlet uses the widgets as they are
dened in the LWUI toolkit and does not make any amendments to them.

Transitions: The Transition object denes the motion of widget or container. For
OneNumberService MIDlet suit the transition is set to Horizontal Transition which means each
time a user navigates through the forms, opens the menu or a widget appears on the screen,
its transition will be from left of the screen to the right of screen.

ListRenderer Class: The ListRenderer class denes the way items are displayed on the list.
The ListRenderer extends the Label class, the label component is initialized with the item to
be displayed on the list. The ListRenderer uses the isSelected() method to check if the item
on the list is selected, if so, the ListRenderer constructor changes the visibility of the
component. For example, the image appended on the Label will change from a Black dot to
an Orange dot and the font face of text will change from Normal to Bold.

Tests And Results

This chapter outlines the tests and verication procedures taken to test the working principle
of one number service.

Test Approach

One Number Service is a telecom Value Added Service that consolidates users multiple
numbers and promises the connectivity between the subscriber of the service and an outside
caller according to the preferences of the subscriber. Hence, the approaches taken to test
this service are;
i. To establish SIP session between the subscriber and a caller in Ericsson virtual IMS network
and verify whether or not it is possible to rout the call according to preferences of the
subscriber.

ii. To implement the service into an Integrated Services Digital Network (ISDN)-Circuit
Switched network to test the service in a real world network scenario.

iii. The database connectivity, data storage, data retrieval and data edition is tested by
establishing HTTP sessions with MySQL Server through Tomcat server.

Test Plan

Features To Be Tested

i. Numbers Addition in the database

ii. Preference Addition in the database

iii. Setting Rules for the groups

iv. Parallel Forking

v. Sequential Forking

vi. Alternate (1 parallel, 1 sequential) Forking

vii. SIP Session setup in ISDN network environment

Testing Tools and Environment:

Test Environment-1:

Ericsson SDS Test Environment:

Since one number service is specically designed for IMS and 3G cellular setup hence it
needs to be tested in a cellular outset to fully verify its features and downfalls. Luckily,
Ericsson SDS provides SEE (Service Execution Environment), a virtual framework to test
Telecom Value Added Services and is almost as good as a real 3G network. While,
OneNumberService MIDlet suit is tested on Sun Wireless Toolkit 2.5 based emulation colour
phone.

Ericsson SDS allows the developers to do two types of testing on the developed applications
or services- Test Agent based testing and ATF (Automatic Testing Framework). Former is the
SIP compliant soft phone based testing which can ONLY show the SIP messages as they
traverse the IMS setup. Whereas, later is an automatic procedure which requires a test script
(written in XML), testing variables and user agents to automatically test the application and
can produce the results in call ow diagrams. In order to test One Number Service, Test
Agent based testing is chosen.

Test Tools:

Tools used for testing are;

Ericsson SDS Test Agent:

Ericsson SDS 4.1 provides an emulation of SIP compliant soft phone called Test Agent which
can be used to create any kind of real or fake SIP messages. The SDS Test Agent tests SIP
nodes. A developer may create one or more test clients that can send, receive, and respond
to SIP requests. In order to One Number Service, SDS Test Agents are instantiated which
imitate the caller and the callee devices.

Sun Wireless Toolkit 2.5:

Since the User Interface for the One Number Service is designed in Java 2 Micro Edition
(J2ME), it needs a Java enabled-Symbian OS based mobile phone to test it. Sun Wireless
Toolkit 2.5 provides one such emulator called colour phone, for testing purposes this device
emulator is utilised.

Provisioning Of Ericsson SDS:

Before beginning the testing process, the OneNumberSIPServlet SIP servlet needs to be
provisioned in the Ericsson IMS setup to make the IMS nodes i.e. HSS (Home Subscriber
Server) and DNS (Domain Name server) aware of the OneNumberSIPServlet SIP servlet so
that they can be able to invoke the servlet should the need arise.
This section outlines the process involved in provisioning of OneNumberSIPServlet SIP servlet
in the Virtual IMS setup. Ericsson SDS provides a GUI Provisioning perspective which can be
used to set the services, virtual domains, initial Filter criteria (iFC), Service Point Triggers
(SPT), service proles of the users, etc. Figure: 6a shows a provisioning perspective as
available in Ericsson SDS.

Figure: 6a Ericsson SDS Provisioning Perspective

Provisioning The DNS:

The DNS provisioning perspective is used to set virtual domains for the application servers
(SailFin server) used in IMS setup. The DNS also determines the next hop address (IP
address/port/protocol) in general call ow sessions. For one number service, a virtual domain
(ericsson.com) is created in SailFin Application Server which hosts the OneNumberSIPServlet
servlet.

In Ericsson SDS, DNS perspective can be opened by clicking on the SDS then Server and then
Provisioning. Once in Provisioning perspective, DNS tab can be selected to get into DNS
Provisioning perspective. A DNS perspective looks like the one shown in gure: 6b

For one number service, the provisioning of DNS involves the setting of SIP URIs of the
devices owned by the subscriber and a virtual domain of application server which is hosting
the OneNumberSIPServlet SIP servlet. Following steps are involved in the provisioning of DNS.

1. In DNS provisioning view, select the SIP/URI tab. The SIP/URI tab contains two sections
URI and DNS Record. The URI section is used to set SIP URI of the subscriber which is
then mapped to the DNS Record (a virtual domain of AS).
2. Clicking on the Add Button will let the developer to enter an address in the SIP URI (sip:
[email protected]) format.
3. Enter the ericsson.com in the SIP URI and click Save button to save the changes.

Note: The DNS provisioning also allows mapping of telephone numbers (tel URI) instead of SIP
URIs but one number service is only programmed with SIP URIs so this feature is currently not
used.
Provisioning The HSS:

As explained in the chapter-3, Home Subscriber Server (HSS) holds the subscribers service
related parameters which are used by Call Session Control Function (CSCF) to trigger the
services the subscriber is authorised to use. These parameters include; Initial Filter Criteria
(iFC), Service Point Triggers (SPT), Service Proles, User Proles, and Public Service Identity
(PSI) Proles.

OneNumberSIPServlet SIP servlet needs to be provisioned in the HSS in order to allow the
CSCF to route the calls to it. This section will explain the steps involved in provisioning of HSS
for OneNumberSIPServlet SIP servlet.

Figure 6.c shows the HSS provisioning perspective as provided by Ericsson in Ericsson SDS
4.1. For OneNumberSIPServlet SIP servlet, the parameters iFC, SPT, User Prole, and PSI
Prole need to be set to make the servlet known to the HSS and thus CSCF. The detailed
provisioning procedure for each is outlined bellow;

Setting iFC (Initial Filter Criteria):

The Initial Filter Criteria (iFC) is used to set the condition to prompt a stored Service Point
Trigger (SPT) and the information about the application server (SIP container SailFin in this
case) to contact. When CSCF asks the HSS for the subscribers service related parameters,
the HSS rst checks the initial lter criteria which trigger the SPT. The process to provision
the iFC in Ericsson SDS is detailed bellow;

1. In Provisioning perspective, select the HSS tab. The HSS tab contains four tabs iFC, SPT,
Service Prole and User Prole and PSI Prole.
2. Select the iFC tab. The iFC contains two tabs; Denition tab where iFCs are dened and
SPT tab where services are dened which iFC triggers.
3. In the Denition tab, click Add and enter the information asked on the right side to
dene a new iFC.
4. The name mentioned for this iFC is OneNumberiFC and priority is 0 (highest priority).
5. The condition to prompt the SailFin Application Server is All triggers true in a group or
at least one trigger true. This means whenever this iFC is invoked, the server will be
triggered and OneNumberSIPServlet will be invoked.
 6. Application Server is the SIP URI of the SailFin Application Server which is contacted as
soon as the set trigger point conditions are met. By default this is IP address and port
number of the local host.
7. Once information is entered, click on the Save button to save the changes.

Setting SPT (Service Point Trigger):

The Service Point Triggers are the rules that determine situations in which SailFin server is
contacted. For OneNumberSIPServlet SPT is left blank because OneNumberSIPServlet is
provisioned in PSI prole which means there is no set rule to trigger this servlet.

Setting Service Prole:

The service tells the CSCF about the iFC set for the given subscriber. There can be more than
one iFC dened in the service prole. The iFC set for OneNumberSIPServlet is included in the
service prole perspective so that the PSI prole can use it to invoke the services authorised
for the given subscriber. Service Prole is provisioned as follows;

1. In the HSS perspective view, click on the Service prole tab.

2. Click on Add button and dene a new service prole.
3. Enter the name of the new service prole. The name entered for the service prole is
OneNumberService Prole.
4. Check the name of the iFCs that needs to be included in this service prole and Click on
Save button to save the information. OneNumberiFC is checked in this case.

Setting User Prole:

The User prole holds the addresses (both SIP URI and Tel URI) of the subscriber associated
with a specic service prole. S-CSCF needs this subscriber information to authenticate and
serve them. For OneNumberSIPServlet, the user prole contains the addresses (SIP URIs) of
the devices (Home phone, Cell phone, Oce phone, etc) registered by the subscriber. The
device addresses need to added to the user prole so that a SIP call/session can be
established with the devices. Following is the process of the adding the User prole in the
HSS perspective;

1. In the HSS perspective view, click on the User prole tab.

 2. Click on the Add button and enter the information requested.
3. Enter the public user id i.e. the SIP URI of the device being entered.
4. Enter the tel URI (the URI in the telephone number format) if the device has one. For
OneNumberSIP servlet this is left blank.
5. Enter the Service prole to which this device is associated, for OneNumberSIP servlet
the device is associated with default service prole prole.

Setting PSI Prole:

The Public Service Identity (PSI) tells the CSCF that One Number Service is hosted by
Application Server (SailFin). The PSI treats the device addresses entered in the user prole as
a group belonging to one subscriber and lets the A/S to route the requests to one or more of
the devices with that particular PSI. The PSI is the essence of one number service that
actually consolidates multiple device addresses into single address called PSI. PSI for
OneNumberSIPServlet is dened as follows,

1. In the HSS perspective view, click on the PSI Prole tab.

2. Click on Add button to enter a new PSI prole in the HSS.
3. Enter the Public ID value which is actually one number (SIP URI) assigned to the
subscriber.
4. Enter the name of the Service Prole (the services this user authorised to use)
associated with this PSI prole and click on Save to save the changes.
5. The gure:6f shows the sip:[email protected] as the PSI set for a test user.

Once the provisioning part is done, we are all set to test the one number service. In the next
section, the test cases and their results are presented to verify the feature and aws of one
number service.

Pass/Fail criteria:

In order to conrm whether or not a certain test has produced what it should have, a
Pass/Fail criterion has been set which will help us decide on the outcome of the tests. The
criteria set is enlisted bellow;

i. Successful SIP session/call establishment, compliant with Three-way handshake scheme

as specied in SIP specication (RFC-3261).
 ii. Successful SIP session/call termination, as specied by SIP specication (RFC-3261).
iii. Successful database update.
iv. Successful database edit.

Test Cases:

Testing The Database Connectivity:

Adding Numbers In The Database

When a subscriber starts the one number service for the rst time, he/she has to add the SIP
URI of all of his/her devices to the mainDataBase database. The rst test case is to check if
this can be done successfully. Since the User Interface for one number service is through a
mobile application (OneNumberService MIDlet suit), rst test will also conrm whether or not
the User Interface works as planned.

1. Start the Tomcat server in Ericsson SDS and run the HTTPServlet suit on it.

2. Run the OneNumberService MIDlet suit on the emulation device provided by Sun Wireless
toolkit 2.5.

3. First form (LoginScreen MIDlet) appears on the mobile screen. If the user is using the
service for the rst time he/he will be asked to set a user name and a password which will be
used to let the user in when he/she logs in the next time. Figure: 6g(i) shows the Login screen
for a revisiting user.

4. User enters the login and password and clicks Enter; Loading MIDlet is shown (Figure:
6g(ii)) while the system loads the rest of the MIDlets. Once loaded, main screen is shown
Figure: 6g(iii).

3. Click on the Menu and select My Numbers. The program will lead to the My Numbers
screen where the SIP URIs of four devices cell phone, home phone, oce phone and PDA can
be added to the database.

4. Enter the SIP URIs of the devices and hit the Add button. This is shown in Figure: 6h(i)

A dialog will appear on the screen showing the server response notifying whether or not the
data is successfully added in the database. If the SIP URIs are successfully added in the
database, the dialog will show a success response. The added SIP URIs can then be seen in
the Show My Number form.

Editing Numbers In The Database

A subscriber of the one number service may want to edit the SIP URI of the devices added in
the database. For this, an option (Edit Numbers) is available in the OneNumberService MIDlet
suit that lets the user to edit the SIP URI of the devices stored in the database. Let us now
verify if this option actually works.

1. Run the OneNumberService MIDlet suit in the Sun Wireless Toolkit 2.5.
2. Click on the Menu option and select the Show My Numbers option, a list of SIP URI of
devices will appear as shown in gure.6i(i).

3. Select the device that needs to be edited; a dialog box will appear asking you to enter a
new SIP URI for the selected device (gure:6i(ii)).

4. Enter new SIP URI for this device and click save, a dialog box will appear conrming the SIP
URI update (gure:6i(iii)).

Adding Contacts And Setting Preferences For The Calls:

New contacts can be added to the database and each contact can be segregated in terms of
groups. This feature lets the user to add new contacts and place them in predened groups
so that when the contact in question tries to reach the user, the user should only be
contacted according to call routing rules set for that particular group. In order to do this,
Contacts option available in OneNumberService MIDlet can be used. Let us see if it really
works;

1. Run the OneNumberService MIDlet suit in the Sun Wireless Toolkit 2.5.

2. Click on the Menu option and select the My Contacts option, a form will appear asking you
to enter the name, SIP URI and group of the contact to be saved- this is shown in gure:6j(i).

3. Enter the information asked and click on Add (gure:6j(ii)), a dialog box will appear
showing the database update success as show in (gure:6j(iii))

Editing Rules

The group set for a contact in Contacts MIDlet actually consists of preset call routing rules
which determine how the devices should be ringed. The option Edit Rules allows the
subscribers to amend these call routing rules so that the user can set their own call routing
rules specifying which devices to ring? and when?

1. Run the OneNumberService MIDlet suit in the Sun Wireless Toolkit 2.5.

2. Click on the Menu option and select the Edit Rules option, a list will appear showing
available groups,

3. Select the option according to your preferences and click on Add , a dialog box will appear
showing the database update success as shown in

Testing The SIP Session Establishment:

Previous ve test cases substantiate that the OneNumberService suit is able to add or update
the user values in the database. The information entered in the database can now be used by
OneNumberSIPServlet SIP Servlet to rout the calls. Let us now analyse if
OneNumberSIPServlet can successfully make calls according to set settings.

Parallel Forking (A Call From Boss):

First case to test the OneNumberSIPServlet is to establish a call (SIP session) between the
subscriber of the one number service and a caller who belongs to Boss group. The
preferences set by the subscriber for this caller are such that all of his devices would ring
simultaneously (A Parallel call). Let us get on with the test process;

1. Start the SailFin A/S in Ericsson SDS and run the OneNumberSIPServlet on it.

2. Start the CSCF server by clicking on SDS then Server and then Start CSCF.

3. Start the DNS server by clicking on SDS then Server and then Start DNS.
4. Click on SDS then Client and then Start Test Agent to start the test agent. Since we need
to test the parallel forking (simultaneous ringing of all the devices) we need to start four
instances of Test Agent in order to imitate the devices registered by subscriber.

Let us assume the subscriber (Kumar-sip:[email protected]) owns three devices; home phone,
cell phone and oce phone. In this test case, these devices are imitated by Test Agent 2,
Test Agent 3 and Test Agent 4. For convenience purpose, the SIP URI for these test agents
are set sip:[email protected], sip:[email protected] and sip:[email protected] respectively in
the SIP Registrar and are listening at ports 5062, 5063 and 5064 respectively of local host.
The Public Service Identity (one number) for Kumar that consolidates all these devices is set
to sip:[email protected] These test agents are shown in gure:

The Test Agents need to send a Register request to the P-CSCF in order to register
themselves in the SIP Registrar. For this, the test agents create and send a REGISTER request
to P-CSCF which in turn registers them in the SIP Registrar in the specied domain
(ericsson.com).

From Test Agent 1 (Alices soft phone) create a new INVITE request by clicking on the New
Request, a window will pop up asking for info about the new request as show in gure:6m.

Enter the following information in the window and click OK.

Request Method: INVITE

Request URI: sip:[email protected]

From: sip:[email protected]

To: sip:[email protected]

An INVITE Request in its complete form looks like the one shown in message preview;

In the Test Agent 1 (Alice) start-up window, click Send to send the INVITE request created, to
the callee (Kumar). The OneNumberSIPServlet sends back a TRYING response which can be
seen in the Message History pane of the Test Agent 1 as shown in gure:6p(1).
Based on the preferences set for this caller (Boss), the Test Agent 2 (Home phone), the Test
Agent 3 (Cell phone) and the Test Agent 4 (Oce Phone) get the INVITE request sent by the
Test Agent 1 simultaneously. This is shown in gure: 6p(ii), 6p(iii) and 6p(iv) .

The callee (Kumar) picks the call by creating and sending a 200 OK response back to the
caller on the Test Agent 2 (Home Phone), shown in gure:6p(v).

The OneNumberSIPServlet forwards the 200 OK response from Test Agent 2 (Kumar) to the
Test Agent 1 (Alice), Alice gets the 200 OK response, as shown in gure:6p(vi).

The OneNumberSIPServlet sends the ACK request to the Test Agent 2 (Kumar), as shown in
gure:6p(vi). The INVITE request at other two Test Agents are cancelled and

When Test Agent 1 gets a 200 OK response,

Alice sends an ACK request back to the Kumar to complete the Three-Way handshake and a
SIP session is established between Alice and Kumar.

Test Case-1 Result:

A call is successfully established between the caller (Alice) and the callee (Kumar) on callee
Kumars Home phone.

Testing Sequential Forking (A Call from Friend):

The second case tests the sequential forking feature of One Number Service. A call from a
Friend, for example, requires sequential ringing of devices which means each of devices
registered by the subscriber will ring one at a time, forwarding the call to the next only if the
subscriber is unable to pick the call on the rst device.

The Test Case-2 is similar to test case-1, only dierence in this test and previous test is the
caller belongs to Friend group. Let us start the testing process.

1. Start the SailFin AS in Ericsson SDS and run the OneNumberSIPServlet on it.

2. Start the CSCF server by clicking on SDS then Server and then Start CSCF.
3. Start the DNS server by clicking on SDS then Server and then Start DNS.

4. Click on SDS then Client and then Start Test Agent to start the test agent.

5. Register the Test Agent 1 as Alice (sip:[email protected]) by creating the REGISTER request
to the P-CSCF (ericsson.com). The Test Agent 1 imitates the Caller but this time the caller
(Alice) belongs to Friend group.

6. Start three more instances of Test Agent (Test Agent 2, Test Agent 3 and Test Agent 4) in
order to imitate the devices registered by subscriber.

7. Register the Test Agent 2, Test Agent 3 and Test Agent 4 as Home-sip:[email protected],
Cell- sip:[email protected], Oce- sip:[email protected] respectively in SIP Registrar. Three
registered Test agents are shown in gure 6m, 6n and 6o respectively.

8. Create a new INVITE request from Test Agent 1 (Alice) to the Kumar sip:[email protected]
(PSI for Kumar) by clicking on the New Request in the Test Agent 1.

9. Click on Send to send the INVITE request to Kumar.

10. According to the rules set for this caller, the Test Agent 3 (Cell phone) gets the call rst,
this is shown in gure: 6q(i).

11. Callee (Kumar) does not pick the call at Test Agent 3, the call is redirected to Test Agent
4 (Oce phone) where the call is picked and 200 OK response is sent to the caller (Alice).

12. The caller (Alice) receives an 200 OK response from callee Kumar from the device
Oce.

13. Caller (Alice) creates and sends an ACK request back to the Callee Kumar.

14. Three-Way hand shake completes here and a call session is established between the
Caller Alice and Kumar at device Oce.

Test Case-2 Result:

A call is successfully established between the caller (Alice) and the callee (Kumar) on callee
Kumars Oce phone.

Alternate Forking:

In alternate forking, users rst two devices are ringed in parallel and if the user is not able to
answer on any of the rst two devices, the call is forwarded to the next one in sequential
manner.

In this test case caller belongs to Colleague group. Let us start the testing process.

1. Start the SailFin AS in Ericsson SDS and run the OneNumberSIPServlet on it.

2. Start the CSCF server by clicking on SDS then Server and then Start CSCF.

3. Start the DNS server by clicking on SDS then Server and then Start DNS.

4. Click on SDS then Client and then Start Test Agent to start the test agent.

5. Register the Test Agent 1 as Alice (sip:[email protected]) by creating the REGISTER request
to the P-CSCF. The Test Agent 1 imitates the caller.

6. Start three more instances of Test Agent (Test Agent 2, Test Agent 3 and Test Agent 4) in
order to imitate the devices registered by subscriber.

7. Register the Test Agent 2, Test Agent 3 and Test Agent 4 as Home-sip:[email protected],
Cell- sip:[email protected], Oce- sip:[email protected] respectively in SIP Registrar. Three
test agents are shown in gure: 6m, 6n, 6o respectively. Three test agents are shown in
gure: 6m, 6n, 6o respectively.

8. Create a new INVITE request from Test Agent 1 (Alice) to the callee Kumar
sip:[email protected] (PSI for Kumar) by clicking on the New Request in the Test Agent 1.

9. According to the rules set for this caller, the Test Agent 2 (Home phone) and Test Agent 3
(Cell phone) gets the INVITE request simultaneously. This is shown in gure: 6r(i).

10. Callee (Kumar) does not pick the call at rst two phones i.e. at Test Agent 2 and Test
Agent 3, the call is redirected to Test Agent 4 (Oce) where the call is picked and 200 OK
response is sent to the caller (Alice).

11. The callee (Kumar) sends 200 OK response to the callee (Alice) from the device Oce.

12. The caller (Alice) sends an ACK request back to the callee (Kumar).

13. Three-way hand-shake completes here and call session is established between caller
(Alice) and callee (Kumar).

Test Case-3 Result:

A call is successfully established between the caller (Alice) and the callee (Kumar) on callee
Kumars Oce phone.

One Number Service in Integrated Services Digital Network (ISDN):

IMS Next-Gen lab in University of Glamorgan:

The IMS Next-Gen lab in University of Glamorgan is facilitated with many amazing cellular
and circuit switched network resources for the creation and testing of next-gen services. The
lab consists of a cellular test bed that is almost akin to the next-generation mobile operators
network. The service creation plane is the main feature of this lab which is facilitated with
advanced equipment donated by many top mobile operators and vendors in UK and Europe.
The service plane enables the developer to create and test next-gen services in a real world
cellular network. The facilities available in the lab include; ISDN connection, Media Gateway
Server, IP Multimedia Subsystem, 3G Node-B, etc. One number service is also implemented
on a real time Integrated Service Digital Network platform in IMS Next-Gen Lab to test if it is
possible to provide such services on circuit switched networks. Following is the details of test
conducted and results obtained.

The IMS Next-Gen Lab facilitates the British Telecom (BT) ISDN 30 Line Termination which is
connected to the Media Gateway Server in order to provide the call routing functionality.
Using these facilities, a small network was formed to test the One Number Service in a circuit
switched network. The details of tests and results are given bellow;
Test Environment-2 Architecture:

Architecture in the following gure shows the test environment-2.

Test environment-2 is almost similar to test environment-1, the dierence lies in the carrier
(the way the call is carried to the user). Here, in test environment-2, the carrier is an ISDN
line whereas, the carrier in the test environment-1 was Ericsson SDSs IMS based virtual
Service Execution Environment (SEE). For one number service testing, the Media Gateway
(MGW) in IMS Next-Gen Lab has been congured to rout the calls straight to SailFin
Application Server running at IP address: 193.63.130.184. The SIP servlet
(OneNumberSIPServlet) is deployed on the SailFin A/S which after getting the calls does the
rest of the call routing.

Media Gateway (MGW) Conguration:

The media gateway is employed to do interworking function between acircuit switched

network and packet switched network and vice-versa. This essentially means that the SIP
based calls are rst converted to a Signalling System 7 media format in order for the calls to
be routed in a circuit switched network. The gure: 6s(ii) shows the Call Rout Provisioning
perspective in Media Gateway server. The media gateway is provisioned in such a way that it
will rout all the calls to SailFin Application Server running at IP address 193.63.130.186:5060.

Conguration of Ubiquity Test Agent:

In order to imitate the caller in this test bed, a separate machine is dedicated at (IP address:
193.63.130.180). This machine runs a User Agent donated by Ubiquity. The User Agent is
congured with the name Alhad and SIP URI: sip:[email protected]:5060. Figure: 6s(iii) shows
the conguration of Ubiquity SIP User Agent. Note the Outbound Proxy of this User Agent is
pointing to IP address: 193.63.130.186:5060 which is actually the machine hosting SailFin
Server (B2BUA).

Test Devices:

To test one number service, three devices (an ISDN phone and two cell phones) are
congured on three dierent ISDN channels. Each phone represents one of subscriber
devices. The details of the devices used in this test scenario are;
ISDN phone: sip:[email protected]:5061, an ISDN phone set in the lab

Cell-1: sip:[email protected]:5060, a mobile phone with Vodafone connection.

Cell-2: sip:[email protected]:5060, a mobile phone with Orange connection.

Modication in SIP Servlet to rout the ISDN Calls:

In order to route the calls to ISDN clients (mobile phones), the address scheme used in
OneNumberSIPServlet is modied from SIP URI to Tel URI scheme (telephone numbers of
ISDN clients). This enables the Application Server to rout the calls to ISDN clients through the
Media Gateway Server (MGW).

Note: Due to time limitations only parallel forking has been tested on the ISDN setup, the
work is still continued to perform the rest of the two call routing mechanisms.

A call to Boss (A Parallel Call):

Following is the list of process involved to test parallel forking in ISDN test environment.

1. The User Agnet (Alhad-sip:[email protected]:5061) dials the one number

(sip:[email protected]:5061) of the subscriber Khalid. The caller (Alhad) is saved in the
Boss group in subscriber Khalids database.
2. The call is rst routed to the MGW which determines where to rout the call, the rout in
the Media Gateway is set to (sip:[email protected]:5060) which means all the calls on
ISDN Line -1 are routed to port; 5060 of the machine at IP address 193.63.130.186. The
machine at 193.63.130.186 is actually the SailFin Server with OneNumberSIPServlet
Servlet deployed on it. This machine is acting as B2BUA in this test scenario.
3. The B2BUA checks the group of the caller from the MySQl database which is running on
the same machine as the sailFin A/S and forwards the call to subscriber Khalids devices
simultaneously.
4. The devices (Cell-1 sip:[email protected]:5060), (Cell-2 sip:[email protected]:5060) and
(ISDN phone sip:[email protected]:5060) ring simultaneously. This is conrmed by the
RINGING response received at Ubiquity user Agent at (sip:[email protected]:5061).

5. Subscriber Khalid picks the call at ISDN phone-sip:[email protected]:5060 , other two
 phones stop ringing and a 200 OK response is sent to the caller Alhad-
sip:[email protected]:5061.

6. The caller Alhad gets OK response and an ACK request from the B2BUA
(193.63.130.186:5060 ) . This conrms the call establishment. This is shown in gure: 6s(vi).
Note the State of the call as Connected.

Test Result: The B2BUA in One Number Service successfully rings all the devices registered
by subscriber Khalid and a call session is established between the caller (Alhad) and
subscriber (Khalid) when Khalid answers the call on any of his devices.

Conclusion And Recommendation For Future Work

Conclusion:

The project was started with the intention to develop a telecom Value Added service that can
consolidate users multiple contact numbers into one number and relieves him/her from
maintaining and distributing multiple contact numbers. The main objective was to develop an
application that can allow the user to keep and distribute one number for all of his/her
devices and let him/her set the preferences for the calls dening where the should calls be
directed if a certain caller tries to reach him/her.

The product obtained at the end of this project complies with the objectives set at the
beginning of this project. Outcomes of the project can be summarised as follows;

User can save his device numbers into the database in order for One Number Service to
be able to rout the calls to them.
User can save his/her contacts and can place them in predened groups.
User can set the call routing rules for dierent groups.
Sessions can be established according to call routing rules set, sessions can be
maintained, and terminated when either of caller or call hangs up.

The test results obtained on both test beds i.e. Ericssons Service Execution Environment as
provided in Ericsson SDS 4.1 and the Integrated Services Digital Network (ISDN) in IMS Next-
Gen Networking Lab in University of Glamorgan proves that the service created delivers what
it promised.
One number service simplies users life and the lives of his/her callers by reforming the
communication process.

Recommendations For Future Work:

Although almost all aspects are taken into account while designing and developing this
project, there are areas that might have been touched if the time had permitted. Following
aspects can be considered in order to extend the work done.

Single Database For All Subscribers:

The database developed for one number service is based on (one database per subscriber)
architecture, which although works quite well in terms of prototype application, it is not a
very elegant solution from service providers point of view. For future work, single database
architecture is suggested. A universal database for all the subscribers subscribed to One
Number Service. Such database should be able to store and manage subscriber info without
assigning a separate database to each subscriber.

Integration With A Presence And Location Based Service.

Location based services are the most attractive features provided by IP Multimedia
Subsystem (IMS). One Number Service in its current form forwards the SIP calls to the
subscriber completely oblivious of subscribers current location; there is no mechanism that
can nd out the current location and availability of subscriber. For future work, a location
based service is suggested that can nd out the subscribers most recent location and
availability and forwards the calls accordingly. For instance, if the presence of subscriber is
on oce phone, all other devices registered by the subscriber should be put on voicemail
mode. Hence, the subscriber can only be contacted for most important calls and calls of less
importance can be redirected to voicemail which can be answered at a later time.

Allowing Users To Call According To Their Preferences.

One Number Service is a passive application, meaning a user can only receive the calls
according to his/her set preferences and it does not involve any mechanism that can t in the
preferences of the user when he is calling to another user subscribed for the same service.
One Number Service can be further polished to include such a feature that can enable the
user to make calls according to his/her preferences. For example, a user might be enabled to
make calls to a specic user according to his wish of reaching him only at home, because the
call is a personal call or he probably knows his availability there. Based on this example, One
Number Service can be modied to include the SIP servlet that can process users request
according his/her preferences. RFC-3841 [26], an extension of RFC-3261 allows such request
handling mechanism by the SIP server. RFC-3841 [26], denes three Header elds i.e.
Request Disposition, Accept Request and Reject Request which can be used to command the
SIP server to route the call based on users preferences.

References:

[1] Session Initiation Protocol SIP Servlet 1.1 Final Release Java Specication Request (JSR)
-289, Java community Process. http://jcp.org/en/jsr/detail?id=289 [Accessed 12th June 2009]

[2] GrandCentral One Number for Life Service. [Internet] http://grandcentral.com/

[Accessed September 2nd 2009]

[3] Web Article-Adam Pash, One Phone Number to Rule them All Published on 27th
September 2009. [Internet] Available from
http://lifehacker.com/203629/one-phone-number-to-rule-them-all. [Accessed September 2nd
2009]

[4] Marshall Kirkpatric, GrandCentral couls make phones lovable again, September 25,
2006. . [Internet]Available from
http://www.techcrunch.com/2006/09/25/grandcentral-could-make-phones-lovable-again/
[Accessed September 2nd 2009]

[5] Jajah Global phone to phone service, http://www.jajah.com/ [Accessed September 2nd
2009]

[6] Google Voice ocial website. [Internet] http://www.voice.google.com [Accessed

September 2nd 2009]

[7] LinxComs ocial web page for LinxConnect One Number Service. [Internet]
http://linxcom.com/solutions/linxconnect.htm [Accessed September 2nd 2009]
[8] A high level Introduction to Apache Tomcat Server, Apache Tomcat Server 6.0
Documentation. [Internet] Available from http://tomcat.apache.org/tomcat-6.0-doc/index.html
[Accessed September 18th 2009]

[9] Web Article-Ericsson Technology in Brief IP Multimedia Subsystem (IMS). Published: May
2009 [Internet] Available from
http://www.ericsson.com/developer/sub/open/technologies/technologyinbrief/index/IMS
[Accessed September 18th 2009]

[10] 3rd Generation Partnership Project 3GPP, IMS release 6. [Internet]

http://www.3gpp.org/article/ims [Accessed September 2nd 2009]

[11] UMTS Forum Ocial web-site www.umts-forum.org [Accessed September 4th 2009]

[12] Ericsson SDS Developers Guide- dispatched with Ericsson Service Development Studio
FD 4.1. [Internet] Available from
http://www.ericsson.com/developer/sub/open/technologies/ims_poc/tools/sds_40 [Accessed
Aug 2nd 2009]

[13] Internet Engineering Task Force (IETF) Request for Comments (RFC)-3261, April 1998.
[Internet] http://www.ietf.org/rfc/rfc3261.txt [Accessed June 2nd 2009]

[14] Peter Granstr.m, Sean Olson and Mark Peck, The future of communication using SIP.
Published in Ericsson Review no. 01, 2002. [Internet] Available from
http://www.ericsson.com/ericsson/corpinfo/publications/review/2002_01/155.shtml [Accessed
on 10th September 2009]

[15] M. Handley, V. Jacobson , SDP: Session Description Protocol, Internet Engineering Task
Force (IETF) Request For Comments (RFC) 3227. April 1998.
http://www.ietf.org/rfc/rfc2327.txt

[16] Rogelio Martnez Perea, Internet Multimedia Communications Using SIP A Modern
Approach Including Java Practice Morgan Kaufmann Publishers, 2008.

[17] Berkeley Internet Name Domain (BIND) Domain Name Server (DNS) ocial web site
(http://www.isc.org/index.pl?/sw/bind/index.php). [Accessed September 10th-2009]
[18] SailFin Server Documentation https://sailn.dev.java.net/documentation/ [Accessed
August 20th-2009]

[19] Geertjan Wielenga, SailFin: When Java EE Met SIP Submitted March 3rd 2008.
http://netbeans.dzone.com/news/sailn-when-java-ee-met-sip [Accessed August 22nd -2009]

[20] Prasad Subramanian, SailFin and GlassFish September, 29th 2007. [Internet-Site is
Web Blog of Prasad Subramanian who happens to be SailFin projects technical lead]
http://blogs.sun.com/prsad/entry/sailn_and_glasssh [Accessed August 22nd -2009]

[21] Albin Joseph, Creating and Conguring a mysql-datasource in glasssh-application

server, 6th August 2008 [Internet]
http://www.albeesonline.com/blog/2008/08/06/creating-and-conguring-a-mysql-datasource-i
n-glasssh-application-server [Accessed August 8th 2009]

[23] MySQL Server 5.0 ocial web site. [Internet]

http://dev.mysql.com/downloads/mysql/5.0.html [Accessed July 22nd 2009]

[24] MySQL Connector/J, the ocial Java Database Connectivity (JDBC) driver for MySQL.
[Internet] Download Site: http://dev.mysql.com/downloads/connector/j/3.1.html [Accessed
August 8th 2009]

[25] Light Weight User Interface Toolkit (LWUI) Toolkit: Java.nets ocial page for Light
Weight User Interface Toolkit (LWUI Toolkit). [Internet] https://lwuit.dev.java.net/ [Accessed
2nd September 2009]

[26] Internet Engineering Task Force (IETF)-Request for Comments (RFC)-3841, August 2004.
[Internet] http://www.ietf.org/rfc/rfc3261.txt [Accessed September 22nd 2009]

[27] Tomcat Installation Procedure, Tomcat 6.0 Documentation, Tomcat 6.0 Ocial Site.
[Internet] http://tomcat.apache.org/tomcat-6.0-doc/setup.html [Accessed July 12th 2009]

[28] Suns Ocial webpage for Java 2 Micro Edition. [Internet]

http://java.sun.com/javame/index.jsp [Accessed September12th 2009]
Appendix-1 List Of Acronyms

IMS: Internet Protocol Multimedia Subsystem

SIP: Session Initiation Protocol

DNS: Domain Name Server

HSS: Home Subscriber Server

S-CSCF: Serving Call Session Control Function

P-CSCF: Proxy Call Session Control Function

I-CSCF: Interrogating Call Session Control Function

URI: Uniform Resource Identier

MIDlet: Mobile Information Device toolkit

MIDP: Mobile Information Device Prole

J2ME: Java Platform, Micro Edition

J2SE: Java Platform, Standard Edition

JSR: Java Specication Request

RFC: request For Comments

CLDC: Connected Limited Device Conguration

3GPP: 3rd Generation Partnership Project

A/S: Application Server

SBC: Session Border Controller

MGWCF: Media Gateway Control Function

MGWS: Media Gateway Server

UAC: User Agent Client

UAS: User Agent Server

B2BUA: Back to Back User Agent

HTTP: Hyper Text Transfer Protocol

SQL: System Query Language

SDS: Service Development Studio

SEE: Service Execution Environment

iFC: Initial Filter Criteria

SPT: Service Point Trigger

PSI: Public Service Identity

LWUI: Light Weight User Interface

Appendix-2

Some Useful Terms:

Servlets: Servlets are a certain type of Java application that plugs into special Web servers,
called Servlet containers.

Servlet Engine: An Engine is a request-processing component. It examines the HTTP headers

to determine the virtual host or context to which requests should be passed.

Connectors: Connectors connect the applications to clients. They represent the point at which
requests are received from clients and are assigned a port on the server.
MIDP: The Mobile Information Device Prole (MIDP) lets a developer write applications and
services for network-connectable mobile devices. When combined with the Connected
Limited Device Conguration (CLDC), MIDP is the Java runtime environment for todays most
popular compact mobile information devices, such as cell phones and mainstream PDAs.
[http://java.sun.com/products/midp/]

CLDC: The Connected Limited Device Conguration (CLDC) denes the base set of application
programming interfaces and a virtual machine for resource-constrained devices like mobile
phones, pagers, and mainstream personal digital assistants. When coupled with a prole
such as the Mobile Information Device Prole (MIDP), it provides a solid Java platform for
developing applications to run on devices with limited memory, processing power, and
graphical capabilities. [http://java.sun.com/products/cldc/]

Midlet: A Mobile Information Device toolkit is a Java application framework for the Mobile
Information Device Prole (MIDP) that is typically implemented on a Java-enabled mobile
phones or other or emulator. MIDlets are applications, such as games for small devices such
as mobile phones. [http://today.java.net/pub/a/today/2005/02/09/j2me1.html]

LWUI Tollkit: LWUIT is a UI library that is bundled together with applications and helps
content developers in creating compelling and consistent Java ME applications. LWUIT
supports visual components and other UI goodies such as theming, transitions, animation and
more. [25]

J2ME: As described on Sun website [28] Java Platform, Micro Edition (Java ME) provides a
robust, exible environment for applications running on mobile and other embedded
devicesmobile phones, personal digital assistants (PDAs), TV set-top boxes, and printers.
Java ME includes exible user interfaces, robust security, built-in network protocols, and
support for networked and oine applications that can be downloaded dynamically.
Applications based on Java ME are portable across many devices, yet leverage each devices
native capabilities. [http://java.sun.com/javame/index.jsp]

Sun Wireless Toolkit 2.5: The Sun Java Wireless Toolkit (formerly known as J2ME Wireless
Toolkit) is a set of tools for creating Java applications that run on devices compliant with
theJava Technology for Wireless Industry (JTWI, JSR 185) specication and the Mobile Service
Architecture (MSA, JSR 248) specication. It consists of build tools, utilities, and a device
emulator. [http://java.sun.com/products/sjwtoolkit/download-2_5.html]

Eclipse IDE: Eclipse is an open source community that provides development platform,
runtimes and application frameworks for building, deploying and managing software across
the entire software lifecycle. The Eclipse IDE is very popularly used as Java development
environment. []

MySQL JDBC driver: MySQL provides connectivity for client applications developed in the Java
programming language via a JDBC driver, which is called MySQL Connector/J. MySQL
Connector/J is a JDBC Type 4 driver. [24]

Forking: RFC-3261 denes Forking as a type of parallel search in which a proxy server can
also send an INVITE to a number of locations at the same time.

Parallel Forking: As per RFC-3261[13], in a parallel fork or parallel search a proxy issues a
several requests to possible user locations upon receiving an incoming request. A parallel
search issues without waiting for the result of previous requests.

Sequential Forking: As per RFC-3261[13], in a sequential fork or sequential search attempts

each contact address in sequence, proceeding to the next only after the previous granted a
nal response.